If a crawler must run your app to see the page, you’ve lost.

Yes, with caveats that decide outcomes. Google renders JavaScript, but rendering is queued and resource-limited, so heavily client-rendered sites get discovered slower, re-crawled less generously, and are more fragile to errors that would be invisible in a server-rendered build. Other crawlers matter too: many AI and social crawlers execute little or no JavaScript, so a client-rendered site can be effectively blank to the engines increasingly deciding citations. Server-side rendering or static generation removes the entire class of problem.

Static generation for content that can be pre-built (marketing pages, blogs, most catalogue pages), server-side rendering for genuinely dynamic content, and client-side rendering only for post-interaction UI that search never needs. In Next.js terms: prefer static and server components, use client components deliberately, and never let a framework default decide what your money pages ship as. The rule of thumb: if a crawler must execute JavaScript to see your primary content, the architecture is wrong.

Five recur. Content only present after hydration (crawlers see shells). Links rendered as click handlers rather than anchor tags, so nothing is discoverable. Metadata set client-side, so titles and descriptions appear generic in the index. Hydration mismatches that break rendering intermittently. And soft 404s from client-side routing where missing pages return 200 with an error message. Each is a code-level fix, which is why this work needs a developer, not a checklist.

By looking at what crawlers actually receive: rendered-HTML comparison (raw response versus post-JavaScript DOM), Search Console URL Inspection screenshots and HTML, crawling with JavaScript execution disabled to reveal the crawler-visible baseline, log-file evidence of what Googlebot fetched and when, and Core Web Vitals field data to catch hydration cost. Guessing from Lighthouse alone is how these issues persist for quarters.

Yes when used correctly, and this site is built on it: static generation, server components, proper metadata APIs, streaming where sensible, and route-level control give you clean crawlable output with modern developer ergonomics. The failure mode is the same as any framework, defaults left unexamined and client components used where server ones belonged. Framework choice matters far less than rendering discipline.

Headless is fine for SEO and dangerous for governance: the front end can be perfectly optimised while nothing enforces titles, canonicals, redirects or structured data at the content layer, because the CMS no longer owns the page. Successful headless builds define the SEO contract explicitly (which fields are mandatory, where redirects live, how sitemaps generate, who validates schema) before launch. We write that contract as part of the engagement.

Rendering audits from £1,200 (crawler-visibility diagnostics, rendering strategy assessment, prioritised remediation with code-level notes). Implementation work quoted by scope, and we can implement directly rather than handing you a document: this practice builds production React and Next.js. Ongoing technical retainers from £1,500/month for teams shipping continuously.