Raw versus rendered comparison
What a crawler receives against what a browser displays, per route type. The single diagnostic that exposes everything else in this discipline.
Why headless sites fail invisibly
Because developers verify in a browser, which executes JavaScript perfectly. Crawlers may render later, partially, or not at all. A page that looks complete in Chrome can reach a crawler as an empty shell, and nothing in the development workflow surfaces that difference at any point.
Next.js makes this manageable, which is why it is a reasonable default for content sites. Static generation and server rendering both deliver complete HTML, so the crawler receives what the visitor receives. The problems arrive when a route silently falls back to client-side rendering because of a data dependency nobody accounted for.
Those fallbacks are the recurring failure. A component fetching in an effect, a personalised block, an experimentation wrapper, a consent gate — any of them can push a route into client rendering, and the page keeps looking correct to everyone reviewing it. The only reliable detection is comparing raw HTML against the rendered DOM.
The second failure is metadata assembled client-side. Titles, descriptions and canonical tags injected after load may be picked up eventually or not at all, and they are frequently wrong in the initial response. Because browsers show the corrected version, this survives review indefinitely.
The third is that rendering strategy is usually chosen once, globally, and then never revisited per route. A marketing page, a product listing and a logged-in dashboard have genuinely different requirements, and treating them identically means either over-rendering things nobody crawls or under-rendering things that matter.
What the engagement covers
The engagement covers a raw-versus-rendered comparison across every route type, identification of any routes silently falling back to client rendering, a per-route rendering recommendation, metadata and canonical verification in the initial response, and monitoring that catches regressions after each deployment.
Client-fallback detection
Routes that silently drop to client rendering because of a data dependency, an experiment wrapper or a consent gate nobody accounted for.
Per-route rendering strategy
Static, server-rendered or client, decided per route type against what actually needs crawling rather than applied globally as one default.
Metadata verification
Titles, descriptions and canonicals confirmed present and correct in the initial HTML response rather than injected after load.
Structured data in source
Schema emitted server-side rather than assembled client-side, since markup that only exists after hydration is unreliable for extraction.
Regression monitoring
Automated raw-HTML checks after deployment, because the next feature can push a route back to client rendering with nobody noticing.
How the engagement runs
The engagement compares raw HTML against rendered output across every route type, identifies routes falling back to client rendering, recommends a strategy per route, verifies metadata appears in the initial response, then installs monitoring so regressions surface at deployment rather than months later.
- 01
Compare raw against rendered
Fetch each route type without JavaScript and compare against the rendered DOM. This single check exposes almost every problem headless sites have.
→ A raw-versus-rendered report per route
- 02
Find the client fallbacks
Routes that drop to client rendering because of a data dependency or wrapper. These look correct in every browser review and are invisible without this test.
→ A list of routes rendering client-side
- 03
Decide strategy per route
Static, server-rendered or client, chosen against what needs crawling. A dashboard and a marketing page should not share one global rendering decision.
→ A per-route rendering specification
- 04
Verify metadata in source
Titles, descriptions, canonicals and schema present and correct in the initial response, not injected after hydration where they may never be read.
→ Verified metadata in raw HTML
- 05
Monitor for regressions
Automated raw-HTML checks in the pipeline, so a future feature that pushes a route back to client rendering fails the build rather than the quarter.
→ Rendering checks in CI
Rendering strategies and what each suits
The decision belongs per route rather than globally, because a marketing page and an authenticated dashboard have genuinely different requirements. Applying one strategy everywhere means either rendering things nobody will ever crawl, or under-rendering the pages that actually carry your search performance.
| Strategy | What a crawler gets | Suits |
|---|---|---|
| Static generation | Complete HTML, instantly | Marketing, blog, documentation, service pages |
| Server rendering | Complete HTML, generated per request | Personalised or frequently changing content |
| Incremental regeneration | Complete HTML, refreshed on a schedule | Large catalogues that change steadily |
| Client rendering | An empty shell, possibly filled later | Authenticated areas nobody needs crawled |
Signals you need this now
You need this when pages look correct in a browser but rank as though empty, when Search Console shows indexed pages with no content, when metadata is assembled client-side, or when nobody has checked what a route returns with JavaScript disabled.
- Pages look right in a browser but rank as though empty
- Search Console reports indexed pages with no visible content
- Titles and canonicals are injected after page load
- Nobody has checked routes with JavaScript disabled
- Rendering strategy was chosen once and never revisited
- An experiment or consent wrapper sits above your content
- Structured data only appears after hydration
What clients see
Fixing a route that was rendering client-side produces some of the fastest gains available, because the content was already good and simply unreachable. Once corrected, the durable value is the monitoring — headless rendering regressions recur, and catching them at deployment is far cheaper.
Where this fits
Related SEO services
Common in these sectors
The adjacent disciplines
Deciding between options
Questions about Next.js SEO
Each answer is written to stand alone in 40 to 60 words — the shape an AI Overview or Perplexity citation lifts. Ships with FAQPage schema.
Is Next.js good for SEO?
Yes, when its rendering options are used deliberately. Static generation and server rendering both deliver complete HTML to crawlers. Problems arise when a route silently falls back to client rendering because of a data dependency nobody accounted for.
How do we know if our pages render for crawlers?
Fetch the route without JavaScript and compare against the rendered DOM. If the raw HTML is an empty shell, crawlers may be receiving that. This single check exposes almost every problem headless sites have and takes minutes.
Does Google render JavaScript?
It can, in a second pass that may be delayed and is not guaranteed to complete. Other crawlers and most AI retrieval passes are considerably less capable. Relying on client rendering means depending on the least reliable path to your content.
Should every route be statically generated?
No. Authenticated areas and genuinely personalised content do not need crawling and should not be rendered as though they do. The decision belongs per route type, which is precisely what most implementations never revisit after the initial build.
Why did our rendering break after a release?
Usually a new component fetching data in an effect, or a wrapper added above the content — an experiment framework or a consent gate. Both push a route into client rendering while looking perfectly correct in every browser review.
Does this affect AI crawlers differently?
Yes, and more severely. AI retrieval passes are generally less capable at executing JavaScript than Googlebot, so a client-rendered page that eventually gets indexed by Google may be entirely invisible to assistants that would otherwise cite it.
Find out whether this is your constraint.
Thirty minutes with a senior strategist. We pull your live visibility while we talk and tell you plainly whether a Next.js SEO is what you need — or whether your problem sits somewhere else.