Should you really prioritize critical content server-side before metadata in SSR?

What causes Google to reverse the classic SSR/CSR priority?

Splitt's statement breaks a deeply rooted habit among developers: we no longer start with the head, we dive straight into the body. The explanation lies in a brutal observation — if your main content is stuck client-side while metadata happily displays server-side, you end up with a catastrophic Signal/Noise ratio for Googlebot.

The bot crawls, loads the initial HTML, sees a neat title, a well-crafted meta description… and an empty body waiting for JavaScript. If JS takes 4 seconds to execute or fails for some reason, Google indexes nothing. And that’s precisely what Splitt wants to avoid: maximizing the chances that critical content is visible even if client hydration fails.

What counts as “critical content” according to this logic?

Splitt explicitly mentions title, meta description, canonical, and main content. The main content includes everything that carries the semantics of your page: intro paragraphs, H1-H2 headings, first blocks of text, hero images with descriptive alt text. “Secondary” elements — complex navigation, sidebars, widgets, product recommendations — can remain in CSR without impacting indexing.

This hierarchy raises a conceptual issue: in practice, metadata is part of critical content. Splitt mentions them as well. What he means is that we shouldn’t just SSR these tags hoping that the body will follow. We need to ensure that the initial HTML stream already contains indexable text, not just meta signals.

How does this affect Google’s perceived performance?

The Time to First Byte (TTFB) remains critical, but the Largest Contentful Paint (LCP) becomes crucial for indexing. If your LCP relies on a client fetch to load the main content, you’re taking a double risk: network latency + JS execution time. By SSR’ing the main content, you ensure that the LCP corresponds to an element already present in the initial HTML.

Googlebot does not wait indefinitely. Real-world tests show that it allocates about 5 seconds of JS execution per page on average — sometimes less on sites with tight crawl budgets. If your main content arrives after this delay because it relies on a third-party API or a too-heavy React bundle, it will never be indexed.

• Main content in SSR: visible in the source HTML, immediately indexable even if JS fails
• Metadata without content: Google indexes an empty shell with nice SERP snippets… that lead to nothing
• Progressive hydration: SSR content remains functional while JS enhances interactivity without blocking indexing
• Resilience to JS timeout: if Googlebot cuts execution, critical content is already captured
• Consistency between mobile/desktop rendering: fewer discrepancies if the initial HTML already contains essential content

Does this recommendation contradict best practices observed in the field?

Not really. The top-performing sites in SEO using modern JS stacks already perform complete SSR of main content — Next.js, Nuxt, SvelteKit, all offer server rendering of the entire page by default, not just metadata. What’s new is that Splitt explicitly states this as an absolute priority.

The problem arises primarily with DIY hybrid architectures where developers have SSR’d only the head to “please SEO” without touching the body of the page. These semi-SSR implementations are a pitfall: they create the illusion of crawlable content while Googlebot sees an almost empty document. Splitt is specifically targeting this pattern.

What are the grey areas of this statement?

Splitt does not clarify where to draw the line between “critical” and “secondary”. Is a product carousel on an e-commerce homepage critical or secondary? Is a collapsed FAQ block indexable in CSR, or should it be SSR? These questions remain unanswered officially. [To be verified] with your own tests using the Mobile-Friendly Test and the URL Inspection Tool.

Another ambiguity: the phrasing “maximize performance” is vague. Performance for whom? If you SSR 100% of the content, you increase TTFB and server load, which can degrade Core Web Vitals. Splitt implies that a balance must be struck, but provides no quantified metrics. In practice, you need to monitor the compromise between SSR generation time and client rendering time.

In what cases does this rule not apply?

Pure SaaS applications behind login have no need for SSR for Google — no page is intended to be indexed. Purely transactional pages (checkout, cart) can remain in full CSR without SEO impact as long as they are noindexed.

Static generated sites (Gatsby, Hugo, Jekyll) already render everything at build time, so the SSR/CSR question doesn’t arise. And traditional full SSR sites (WordPress, Drupal, Rails) have never encountered this issue. This recommendation exclusively targets modern JS stacks in hybrid mode — React, Vue, Angular with mixed rendering.

What should you concretely modify in a Next.js or Nuxt stack?

If you’re using getServerSideProps (Next) or asyncData (Nuxt), ensure you’re fetching main content data server-side, not just metadata. A common pattern that causes issues: SSR’ing the title/description via props, but allowing the body to load with a client useEffect. That’s exactly what Splitt condemns.

In Next 13+ with App Router, favor Server Components by default for all critical text content. Mark 'use client' explicitly only for interactive components (forms, carousels, accordions). Do not switch a component to client just because it contains a useState — extract the interactive logic and leave the text rendering server-side.

How can you verify that Google is correctly crawling the SSR content and not empty?

Use the URL Inspection Tool in Search Console, “Crawled page” tab. Compare the raw HTML with the final rendering. If the source HTML already contains your H1, first paragraphs, and hero images, you’re good. If these elements only appear in the final rendering, they depend on JS — thus risking partial indexing.

Also test with curl or wget with JavaScript disabled: curl -A "Googlebot" https://yoursite.com. The main content should be visible in the raw HTML output. If you see empty <div id="root"></div> tags, your SSR is insufficient. Complete this with a Mobile-Friendly Test using the URL Inspection API to see exactly what Googlebot renders.

What errors should you avoid during the SSR/CSR migration?

Don’t fall into the trap of “SSR everything at 100%” out of dogma. SSR’ing a megamenu of 500 categories or a sidebar of complex product filters will inflate your TTFB without any tangible SEO gain — these elements do not carry primary semantics. Keep them in CSR or lazy load.

Another classic mistake: SSR’ing content but forgetting alt attributes, aria-labels, and structured data. These signals must also be present in the initial HTML, not injected later via JavaScript. Ensure that your JSON-LD is present in the source HTML, not dynamically added via a client script.

• Audit the source HTML (curl/wget) to identify missing content server-side
• Progressive migration: SSR first H1, intro, first screen of content
• Measure TTFB before/after to avoid degrading Core Web Vitals
• Test Mobile-Friendly Tool and URL Inspection on a representative sample of pages
• Monitor JS errors in production: if CSR fails, SSR should hold up
• Document SSR/CSR choices for each component type (menu, sidebar, CTA, main content)