Key takeaways
- Google renders pages in an up-to-date headless Chromium, and a Vercel and MERJ study found it attempts to render all HTML pages, with a median delay of about 10 seconds.
- Google Search does not click, scroll or type, so content that loads only after a user action may never be seen.
- Content already in the HTML or DOM, including text in tabs and accordions, can be indexed; content fetched only on click cannot.
- JavaScript errors, slow or failing API calls and blocked resources cause most rendering gaps.
- URL Inspection in Search Console shows Google’s rendered HTML and is the most direct diagnostic.
| Question | Short answer |
|---|---|
| How do you run a rendering audit? | Compare raw server HTML with the rendered result, template by template. |
| What should you look for in the rendering output? | The elements that drive indexing and rankings. |
| How do you fix rendering gaps? | Match the fix to the cause. |
What visitors see and what Google renders are not always the same. When the two differ, Google may index a partial page, miss links or lose structured data, and other crawlers that do not run JavaScript may see even less. This Emulent guide covers what goes wrong during rendering, how to audit it and how to fix the gaps.
What can go wrong during Google’s rendering process?
Google’s Web Rendering Service runs JavaScript in Chromium, and Vercel and MERJ’s 2024 study found it attempts to render every HTML page, usually within seconds. Gaps come from how pages behave, not from rendering being skipped.
- No interaction. Google’s lazy-loading guidance says Search does not interact with pages, so content that loads only on click, hover or scroll events can be missed. Lazy loading that triggers when content enters the viewport works.
- Slow or failing scripts and API calls, which can leave content unloaded when Google captures the page.
- Blocked resources, such as scripts or APIs disallowed in robots.txt.
- Content behind logins, paywalls or user-specific API keys.
- Code relying on browser features or permissions Googlebot does not grant, such as geolocation prompts.
Partial failures are the most dangerous: a page that renders 90% correctly but drops its main heading or product details still looks fine in a quick check.
How do you run a rendering audit?
Compare raw server HTML with the rendered result, template by template.
- Pick representative URLs from every template: products, categories, articles, locations and landing pages.
- Run “Test live URL” in URL Inspection and review the rendered HTML, screenshot and any page resources that failed to load.
- Compare word counts in raw and rendered HTML; a large difference shows JavaScript dependence.
- Compare internal links in raw and rendered HTML; links that appear only after rendering depend on JavaScript.
- Crawl the site twice in Screaming Frog or a similar tool, once with rendering on and once off, and compare.
What should you look for in the rendering output?
The elements that drive indexing and rankings.
- Main body content, such as product descriptions or article text.
- Title, meta description, canonical and robots meta tags, especially if JavaScript sets or changes them.
- Heading structure.
- Navigation, breadcrumb, footer and in-content links as real anchor tags with href attributes.
- JSON-LD structured data, if it is injected by JavaScript.
- Images with real src attributes and alt text, loaded without requiring a scroll event.
Also check the raw HTML on its own. A second Vercel and MERJ analysis found major AI crawlers such as GPTBot and ClaudeBot do not execute JavaScript, so anything missing from raw HTML is invisible to them.
How do you fix rendering gaps?
Match the fix to the cause.
- Move main content, headings and links to server-side rendering or static generation.
- Keep tab and accordion content in the HTML on page load rather than fetching it on click.
- Use viewport-based lazy loading, and give each chunk of infinite scroll its own URL.
- Fix JavaScript errors, reduce bundle sizes and make critical API calls fast and public.
- Treat bot-only prerendering (dynamic rendering) as a temporary workaround; Google recommends server-side rendering, static rendering or hydration instead.
Server-rendered CMS sites avoid most of these issues. Rendering checks belong in your regular enterprise SEO reviews, since template and script changes can break them at any time.
How can the Emulent team help?
Emulent runs rendering audits as a standard part of technical SEO, comparing Google’s rendered view with what users see and working with developers on fixes. A caveat: rendering behavior and third-party scripts change, so repeat checks after major releases and new integrations. Contact the Emulent team to audit your rendering.