JavaScript Rendering Diagnosis for React and Next.js Sites

The only question worth asking is whether Googlebot has the content and the links in the first response, and the way to answer it is a diff: raw HTML from a plain request against the DOM after a headless Chrome render, across a stratified sample of every template you own. On a typical Next.js app router build I find two or three templates where something load-bearing is client-only, usually the structured data, the category filter links, or the head tags after a client-side route change. How I run it: A crawl of production over the Chrome DevTools Protocol, one pass with JavaScript disabled and one with it on, matched URL by URL. I compare title, canonical, hreflang, structured data, body copy and outbound internal links, and score each template by what is missing before hydration. Then I check what Google itself did: rendered HTML from the URL Inspection API on the same sample, and, where edge logs exist, whether the rendering service came back for those pages at all and how long after first crawl. The failures that keep recurring: Components imported with ssr set to false because something touched window during a build fix eighteen months ago, and nobody has looked since. Structured data injected by a tag manager, which renders eventually and is worth nothing when it is absent from the first response. Soft navigations that swap the body but never the title or canonical, so every route a user enters after the first is described by the wrong head. Category filters built as buttons with click handlers and no href, which means those pages are not linked from anywhere. Chunk paths disallowed in robots.txt, rarer than it was and still turning up. Streaming and Suspense are usually fine. I do not treat React Server Components as suspect by default. The interesting question is which boundaries fall back to client-only content and whether anything indexable lives inside them. What you get: A template-by-template table of what is missing pre-hydration and what it costs, then the changes as pull requests: structured data moved server-side, real hrefs on links, head updated on route change, ssr disabled only where the original reason still holds. Each fix ships with the diff test that proves it, so your CI keeps it fixed after I leave. What I refuse: Dynamic rendering. I will not put a rendering proxy in front of your site to serve Googlebot a different response from the one users get. It creates a second codepath that drifts from the first, it hides the defect rather than removing it, and I have been hired twice to take one out that somebody else installed. If the honest conclusion is that your framework choice cannot serve indexable HTML, I will say that, and the discussion becomes an architecture one with your CTO rather than an SEO project. Also not included: Rewriting your front end. Performance work, which is a separate engagement with separate evidence. App deep links. Any site I cannot reach a staging copy of. Who should not buy this: Anyone whose pages already index and rank, looking for reassurance. Sites built as static output, where the answer is knowable in an afternoon and I would be charging you for a foregone conclusion. Teams without a front-end engineer to receive the pull requests, because a diagnosis nobody implements changes nothing at all.