JavaScript Rendering Diagnosis for Googlebot Discovery

About three quarters of what arrives labelled "Googlebot cannot render our JavaScript" turns out not to be a rendering failure. The DOM renders. What fails is discovery: navigation built from div elements with click handlers instead of anchors, content behind a fetch triggered by an IntersectionObserver that never fires because nothing scrolls in a headless viewport, or a route change that swaps the body and leaves the title element alone. Rendering and discovery break differently and get fixed by different people. The first week separates them. How the test is actually run: Three fetches of the same URL, compared. A raw fetch with no JavaScript, serialized and normalised. A headless Chromium render under Googlebot's real constraints: no cookies carried between requests, no localStorage or sessionStorage persistence, no service worker surviving from a previous visit, permission prompts auto-denied, no user gesture ever. And Google's own live test through the URL Inspection API, which returns the rendered HTML the Web Rendering Service produced, sampled per template rather than on one hero URL. Where those three disagree is where the answer is. Most in-house diagnoses fail because only the second one was run, in a browser that still held the developer's session cookie. What this actually finds: Content inside a Suspense boundary that resolves after the render budget, so it is present in your browser and missing in Google's. Dynamic imports with server rendering disabled applied to a component that turned out to hold the internal link graph. Hydration mismatches where the client discards correct server HTML and replaces it with an empty state. Canonical or hreflang injected by a tag manager, which is the least reliable place to put either. Soft navigations on History API route changes where the title, canonical and structured data still belong to the previous page. Filter results that exist only after a click Google will never perform. What I give you: A per-template verdict naming which of rendering or discovery is broken, with the three-way diff attached as evidence rather than described in prose. The scripts that produced it, so the check runs in your CI on every release instead of once during an engagement. And a specification of the change: which component needs server rendering, which div becomes an anchor, which element needs a real href even if it also carries a click handler. Not included: I do not rewrite your application. I do not recommend dynamic rendering or prerendering services as a permanent architecture; they are an evacuation route, and they carry failure modes that surface eighteen months later when nobody remembers the service exists. No content work, no crawl budget analysis, no vitals. If the rendering suspicion turns out to be a crawl allocation problem, I will say so and point you at the other engagement rather than billing this one for it. Who this is not for: Teams already committed to a rebuild in the next two quarters. Diagnosing an application you are about to delete is an expensive way to feel informed, and I would rather review the new architecture before it ships. Sites that server-render everything and index fine, where the suspicion is usually misplaced and two hours of your own testing would settle it. And anyone who wants me to conclude that the framework is at fault. Sometimes the framework is fine and the implementation put a link inside an onClick handler. What I need: Repository read access or a staging deployment with source maps. I can diagnose from the outside, but against minified bundles I can tell you what is missing and not which line removed it, which turns a one-week engagement into a three-week one and blunts the specification exactly where precision matters.