Key takeaways
- Google crawls HTML, then renders JavaScript in a later step. A Vercel and MERJ study found a median delay of about 10 seconds, but roughly 18 hours at the 99th percentile.
- Most AI crawlers do not render JavaScript at all, including OpenAI’s GPTBot, Anthropic’s ClaudeBot and PerplexityBot, so client-side content can be invisible to them.
- Server-side rendering and static generation deliver full HTML on the first request and remove most risk.
- Links must be real anchor tags with href attributes for Google to follow them reliably.
- A rendering audit with URL Inspection and a non-JavaScript crawl shows how much content crawlers miss.
| Question | Short answer |
|---|---|
| How do you run a rendering audit to find what crawlers miss? | Compare the raw HTML your server sends with the rendered result. |
| Which rendering strategy should enterprise sites use? | Server-side rendering or static generation for any page that needs to rank or be cited. |
| How do you protect internal linking when content depends on JavaScript? | Make every important link crawlable in the HTML. |
If your site relies on JavaScript to display its main content, search engines and AI tools may not see everything you intend. This Emulent guide explains how rendering works, how to audit it and which rendering strategy protects your visibility.
How does Google’s rendering process create content gaps?
Google fetches the raw HTML first, then queues the page for rendering in a headless Chrome before indexing the result. On a server-rendered site the HTML already holds the text, links and metadata. On a client-rendered site the HTML is often a shell with a root div and script references, and the content appears only after JavaScript runs.
Rendering is faster than old advice suggested. Vercel and MERJ’s 2024 study found Google attempts to render all HTML pages, with a median delay of about 10 seconds, though the slowest 1% waited around 18 hours. The gaps come from what goes wrong during rendering:
- Partial indexing when scripts error out, time out or depend on slow third-party APIs.
- Links generated only by JavaScript click handlers, which Google cannot follow.
- Titles, canonicals or robots meta tags set by JavaScript that conflict with the raw HTML.
- Content behind user actions, such as tabs that load on click, which Google does not trigger.
AI crawlers are a bigger gap. A second Vercel and MERJ analysis found none of the major AI crawlers it tracked render JavaScript, including GPTBot, ClaudeBot, PerplexityBot and Meta’s crawler. Gemini uses Googlebot’s infrastructure and does render.
How do you run a rendering audit to find what crawlers miss?
Compare the raw HTML your server sends with the rendered result.
- Use the URL Inspection tool in Search Console to view the rendered HTML and a screenshot of how Google sees the page.
- Crawl the site with JavaScript rendering off in Screaming Frog or a similar tool, then crawl again with it on, and compare word counts, links and metadata.
- Run curl or “view source” on important templates to see what non-rendering AI crawlers receive.
- Check Chrome DevTools for console errors that stop content from loading.
A “site:” search for a phrase found only in JavaScript content can give a rough signal, but Google’s site: results are not a complete index report. In one Emulent client engagement, about 40% of a SaaS company’s feature pages were missing from Google’s index because content loaded from a slow API after render. Your gap may be smaller or larger.
Which rendering strategy should enterprise sites use?
Server-side rendering or static generation for any page that needs to rank or be cited.
- Server-side rendering (SSR) runs JavaScript on the server and returns full HTML to every visitor and crawler. It costs more server work but gives crawlers the most complete view.
- Static site generation (SSG) pre-builds pages as HTML, giving fast loads and full content, but needs rebuilds or incremental regeneration when content changes.
- Hybrid setups use SSR or SSG for product, landing and blog pages and client-side rendering for logged-in dashboards.
Google describes dynamic rendering, which serves crawlers a different version than users, as a workaround rather than a long-term solution and recommends server-side rendering, static rendering or hydration instead. Many marketing sites avoid the issue by using a server-rendered CMS. Rendering choices also shape speed and Core Web Vitals across your enterprise SEO program.
How do you protect internal linking when content depends on JavaScript?
Make every important link crawlable in the HTML.
- Use standard anchor tags with href attributes. Google does not follow links that exist only as onclick handlers or buttons.
- Render primary navigation, breadcrumbs and footer links on the server even if other parts load client-side.
- List all indexable URLs in XML sitemaps as a backup discovery path.
- Compare URLs discovered in a non-JavaScript crawl with your full list of indexable pages to find orphaned sections.
Internal links carry relevance and authority between pages and support your content strategy. When crawlers cannot follow them, whole sections can go undiscovered.
How can the Emulent team help?
Emulent runs rendering audits as part of enterprise SEO engagements, identifying content gaps and working with your developers on SSR, SSG or hybrid fixes. A caveat: crawler behavior changes, and AI crawler rendering may change too, so re-test after major releases. Contact the Emulent team to check what crawlers see on your site.