Revain review platform moves to SSR and goes to the Moon! | Revain

Rendering strategy is one of the few architectural decisions in SEO that you make once and live with for years. Revain's case study documents the version of that decision most likely to hurt: a content heavy review platform launched as a client rendered application, then migrated to server side rendering after the indexing consequences became clear.

The reason review platforms suffer disproportionately is structural. Their traffic does not come from a handful of hero pages. It comes from thousands or millions of individual product and review URLs, each targeting a narrow query, each individually low value but collectively the entire business. That is precisely the shape of site where a per page rendering tax compounds into something serious.

Revain reports a substantial improvement after moving to SSR. We have deliberately not reproduced specific figures here, because the original post is the authoritative record for its own numbers and we do not restate metrics we cannot independently verify. The link at the foot of this page goes straight to it. What follows is the practitioner reading of why this class of migration works, and how to run one without breaking things.

What client side rendering costs a content platform

Google can render JavaScript. That fact is often used to close the argument, and it should not, because "can render" and "renders promptly at your scale" are different claims. Indexing a client rendered page happens in two stages: the crawler fetches the HTML and indexes what is there, then the URL is queued for rendering, and only after that pass does the executed content become available for indexing.

For a small brochure site, the queue delay is an irrelevance. For a platform adding review pages continuously, it introduces several compounding problems:

• Discovery stalls. If your internal links only exist after JavaScript executes, the crawler cannot follow them on the first pass. Link discovery becomes dependent on the render queue too, so each layer of the site waits on the layer above it.
• Metadata is unreliable. Titles, descriptions, canonical tags and hreflang annotations injected by script are read late. A client set canonical is the single most dangerous item on that list, because getting it wrong at scale causes consolidation onto the wrong URLs.
• Social and AI crawlers see nothing. This is not a Google problem, it is everyone else's. Most social preview crawlers and a number of AI crawlers do not execute JavaScript at all. A shared review link that renders as an empty shell kills the referral loop that review platforms depend on.
• Crawl budget is spent on the shell. Fetching a near empty document plus a large bundle for every URL is a poor use of the budget you have, particularly on a large site.
• Failures are silent and partial. A timeout, a blocked resource or a script error on the render pass does not produce an error page. It produces a thin or blank indexed document, which looks like a content quality problem in your reporting rather than a rendering problem.

Diagnosing a rendering problem before you rebuild

Migrating rendering strategy is expensive, so confirm the diagnosis first. The single most common mistake here is auditing in the browser's Elements panel, which shows the fully executed DOM and will therefore look perfect no matter how broken your delivery is.

1. Read the raw response. curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/review/acme and look for the review text, the H1, the canonical and the anchors. If they are absent, that is your answer.
2. Use Search Console URL Inspection on a live URL, then open View crawled page and read the HTML tab plus the screenshot. This shows what Google actually got after rendering, which is the other half of the picture.
3. Check the Page indexing report for "Crawled, currently not indexed" and "Discovered, currently not indexed" at template level. A rendering bottleneck usually shows as a large discovered but unindexed population, because the URLs are known and queued but never processed.
4. Disable JavaScript in a clean browser profile and navigate the site. Anything you cannot reach or read is at risk.
5. Check log files for whether Googlebot is fetching your JavaScript bundles at all, and whether those responses are 200. Bundles blocked by robots.txt are a classic self inflicted wound.
6. Compare submitted against indexed counts per sitemap. Split your sitemaps by template so the ratio is diagnostic rather than an aggregate.

Our walkthrough of JavaScript rendering SEO diagnosis covers each of these checks in more depth, including how to read the crawled HTML output.

Prerendering deserves a note of caution. It solves the symptom quickly and it is legitimate when the served content matches what users get, but it adds a parallel output path that will drift unless someone owns it. Treat it as a bridge, as covered in our piece on prerendering as a JavaScript SEO stopgap, not a destination.

Executing the move to server side rendering

A rendering migration is a replatform of the delivery layer, and it fails in predictable ways. Sequence it like this:

1. Freeze the URL structure. Change rendering or change URLs, never both at once. If you conflate them you will not be able to attribute any subsequent movement.
2. Move metadata to the server first. Titles, meta descriptions, canonical, robots directives, hreflang and Open Graph tags should be emitted server side before anything else ships. This is the highest value, lowest risk portion of the work.
3. Make anchors real. Every internal link must be an <a href> with a crawlable URL in the server response. Click handlers on divs and router pushes without an href are invisible on the first pass.
4. Render the primary content, not the chrome. The review body, rating, product name and structured data belong in the server output. Deferred loading of comments, recommendation carousels and personalised modules is fine.
5. Watch hydration. A mismatch between server markup and client expectations causes React and similar frameworks to discard and re render, which can blank content and hurt interactivity metrics. Test with throttling on.
6. Stage behind a canary. Ship SSR for one template to a fraction of traffic, verify with URL Inspection on live URLs, then widen. Do not migrate the whole estate in one release.
7. Keep response times honest. SSR moves work to your servers. Cache aggressively at the edge and monitor time to first byte per template, because a slow server render can undo the crawl efficiency you gained.

Measuring the recovery

Rendering migrations produce a characteristic recovery curve: indexation moves first, impressions follow, clicks last. Track them in that order or you will call the project a failure two weeks in.

• Indexed URL count per template from split sitemaps. This is the leading indicator and should move within weeks.
• Movement out of "Discovered, currently not indexed" in the Page indexing report. This is the specific bucket a rendering fix should drain.
• Time from publish to first impression for newly created review pages. On a working SSR setup this collapses dramatically, and it is the metric that best expresses the business value.
• Impressions and clicks by template, not sitewide, so a recovering long tail is not masked by flat head terms.
• Crawl stats in Search Console, watching average response time and the ratio of HTML to script fetches.

Annotate the deploy date in every report. Rendering migrations often coincide with framework upgrades and template changes, and without an annotated timeline the causal story dissolves within a quarter. For the background theory, our server side rendering definition and the fuller JavaScript SEO and rendering guide cover the mechanics in detail.

Frequently asked questions

The strategic takeaway from Revain's migration is not that SSR is universally correct. It is that rendering strategy should follow the shape of your content. A platform whose value lives in a large, constantly growing long tail cannot afford to make every one of those pages wait for a second pass.

Source: https://revain.org/blog/review-platform-moves-to-ssr-and-goes-to-the-moon