JavaScript Loaded Content

Element Code: PE-019

What this check actually flags

This check compares the raw HTML your server sends with the DOM after JavaScript has executed. When the meaningful stuff, body copy, product data, headings, internal links, titles, canonicals, only shows up in the rendered version, the page is flagged. The initial response is a shell: a root div, a bundle of script tags, and a promise that content will arrive once the browser does its part.

That architecture is fine for a logged-in dashboard. On a public page that needs to rank, it means every system consuming your site has to run a full browser to see anything, and most of them simply do not.

How Google actually handles JavaScript

Google can render JavaScript, and it is genuinely good at it. Googlebot renders pages with an evergreen version of Chromium, so modern JS features are not the problem. The catch is the pipeline: crawling and rendering are separate steps. Googlebot fetches your HTML first, and pages needing JS go into a render queue before the Web Rendering Service executes them. Google's Martin Splitt has said most pages get rendered within minutes, but it is still a deferred second pass that can fail on timeouts, blocked resources, or script errors, and when rendering fails, whatever only existed client-side simply does not exist.

Two hard limits people keep forgetting. First, Googlebot does not click, so content fetched only after a tap on "Load more" or a tab that pulls data on demand is never seen. Second, links that are not real anchor elements with an href, the classic div-with-onclick navigation, are not reliably followed, which quietly starves whole sections of a site of internal links.

Google is the best case. Everyone else is worse

Optimizing JS rendering for Google alone made sense in 2019. It does not anymore, because the crawlers that increasingly decide whether you get cited do not render at all. Research published by Vercel and MERJ in late 2024 tested the major AI crawlers and found that GPTBot, ClaudeBot and PerplexityBot fetch the raw HTML and do not execute JavaScript. If your product specs, article body or pricing only materialize client-side, you are handing AI assistants a blank page while your server-rendered competitor gets quoted. Social link previews and smaller search engines behave the same way. Bing does render JavaScript, but nobody outside Redmond will promise you the same coverage and patience Google shows.

How to detect it

1. Disable JavaScript and reload: in Chrome DevTools, hit the command menu, type "Disable JavaScript", reload the page. Whatever vanished is your exposure. Thirty seconds, no tooling budget required.
2. View source versus rendered DOM: compare the actual server response (view-source or curl) with the Elements panel. If the body copy is in the second and not the first, it is JS-loaded.
3. Search Console URL Inspection: run a live test and open the rendered HTML and screenshot. This shows what Googlebot itself produced, including anything that failed to render.
4. Screaming Frog in JavaScript rendering mode: enable rendering under Config, then use the JavaScript tab, which flags pages where word counts and links differ between raw and rendered HTML. This is how you find the problem at template scale instead of page by page.

How to fix it, step by step

1. Inventory the damage. List what is JS-only: main copy, titles, meta robots, canonicals, structured data, internal links, product data. Meta signals living only in the rendered DOM are a special kind of footgun, since a client-side canonical can flip after the HTML one was already processed.
2. Pick a rendering strategy per template. Static generation for stable marketing and blog pages, server-side rendering for pages that change per request, and keep pure client-side rendering for authenticated views that should not be indexed anyway.
3. Use the framework's server mode. Next.js, Nuxt and SvelteKit all ship server rendering with client hydration, so you keep the interactive feel while the first HTML response carries the full content.
4. Make navigation real. Every crawlable destination gets a genuine anchor with an href. Router libraries support this; teams just forget to use it.
5. Do not block the machinery. If some content must stay client-rendered, never block the JS, CSS or API endpoints it needs in robots.txt, or Google's renderer produces the same blank shell as everyone else.
6. Retest. URL Inspection on the fixed templates, a fresh Screaming Frog rendering crawl, and a diff of raw HTML before and after. The win condition: content visible with JavaScript off.

On that last row: Google's own documentation now describes dynamic rendering as a workaround rather than a recommended long-term solution. It buys time for an old single-page app; it is not an architecture to build toward in 2026.

What good looks like

Load any public page with JavaScript disabled and the headline, body content, and navigation are all there. Titles, canonicals and structured data live in the server response, not in a script's side effects. The Screaming Frog JavaScript report shows near-zero difference between raw and rendered word counts on indexable templates. JS still runs, the site still feels like an app; it just stops being the only place your content exists.

FAQ