\nyou may have a crawlability problem.\nThat does not mean Google can’t render the page. Google can render JavaScript. The issue is that rendering is not the same as clean, fast, reliable discovery. Rendering can be delayed, fail, depend on blocked resources, or be incomplete. Other crawlers may not handle your JavaScript the same way Google does. AI crawlers may be even less patient.\nFor a serious crawlability audit, gather Google Search Console access, a JavaScript-rendering crawler, server logs if available, XML sitemap access, robots.txt access, framework context, deployment context, and a list of priority URLs by business value.\nDon’t audit random URLs first. Audit the pages that make money.\n1. Discovery and Internal Linking\nCrawlers need paths. SPAs often hide those paths behind client-side behavior, especially when navigation is handled with JavaScript instead of normal links.\nCheck:\nImportant pages have unique, crawlable URLs.\nInternal links use standard anchor tags, like .\nNavigation does not rely only on onClick, buttons, spans, or JavaScript-only route changes.\nImportant pages are not only reachable through filters, tabs, search boxes, or infinite scroll.\nPagination uses crawlable URLs where needed.\nFaceted pages that should be indexed have distinct URLs.\nURLs do not rely on hash fragments like #section or old #! patterns for primary page discovery.\nXML sitemaps include canonical, indexable, 200-status URLs.\nSitemap URLs do not require JavaScript execution to become meaningful.\nOrphan pages are identified, especially product, service, blog, and comparison pages.\nBad pattern:\nPricing\nBetter pattern:\nPricing\nThis sounds basic, but it breaks all the time. If crawlers can’t find the URL, they can’t rank the URL. If AI systems can’t discover the page, they can’t use it as a source.\n2. Raw HTML vs Rendered HTML\nThis is the heart of JavaScript crawlability. You need to know what exists before JavaScript runs and what only appears after rendering.\nCheck:\nThe raw HTML contains the main topic of the page.\nThe primary heading is present in the initial HTML.\nCore body copy is present without waiting for client-side rendering.\nInternal links are visible in raw HTML or reliably available after render.\nProduct, service, pricing, author, FAQ, and location content is not hidden behind inaccessible API calls.\nThe rendered HTML does not remove important content from the initial HTML.\nThe page still makes sense if JavaScript execution is delayed.\nThe first meaningful content is not just a blank shell, loading spinner, or placeholder.\nLook for missing H1s, intro copy, product descriptions, pricing details, reviews, FAQ content, internal links, breadcrumbs, schema markup, canonicals, and robots directives.\nIf the rendered page is strong but the raw HTML is empty, you may need server-side rendering, static generation, pre-rendering, or a framework-level fix.\n3. Rendering and Hydration Risks\nHydration is where a server-rendered or pre-rendered page becomes interactive. It’s also where SEO signals can quietly break.\nCheck:\nServer-rendered content matches client-rendered content.\nHydration does not erase headings, body copy, links, or schema.\nThe app does not flash one version of metadata and then replace it with another.\nClient-side state does not rewrite canonical tags incorrectly.\nLazy-loaded components containing SEO-critical content are rendered early enough to be seen.\nError states are not served to bots because of blocked APIs or missing headers.\nImportant content is not dependent on user interaction.\nRendering does not require cookies, local storage, or logged-in state for public pages.\nPages do not produce different SEO-critical output across refreshes.\nA common failure mode: the page appears server-rendered, but hydration fails. Users still see something, so nobody panics. But crawlers may see broken, incomplete, or inconsistent markup.\nThat’s the kind of issue that wastes weeks because everyone says, “It works on my machine.” Maybe it does. Your machine isn’t the crawler.\n4. Metadata and Robots Directives\nMetadata gets messy in SPAs because the client app often controls the document head. Titles, descriptions, canonicals, robots tags, and social metadata may be injected, changed, or removed after load.\nCheck:\nEach indexable page has a unique