JavaScript SEO: diagnose it before you brief a developer
Most sites blame JavaScript for problems it did not cause. Here is the ten-minute test, and the exact ask when it really is JS.
A page is not ranking, someone said "it's a JavaScript thing", and now you have to talk to a developer.
This page is written for that conversation, not for the developer. It is the diagnosis path — how to prove JavaScript is or is not your problem — plus the brief to hand over when it is. For the wider picture, start at our SEO guide hub, and use technical SEO for issues that have nothing to do with rendering.
What does Google actually do with your JavaScript?
Google's own documentation is unusually clear on this. It processes JavaScript sites in three phases: crawling, rendering, indexing.
- Crawl. Googlebot checks robots.txt, fetches the URL, and parses the response for more URLs in the
hrefattribute of links. - Render. The page joins a queue. A headless Chromium runs your scripts and builds the page. Google says it "runs JavaScript with an evergreen version of Chromium" — so modern syntax is generally fine.
- Index. Google indexes what the rendered page contains, not what the server sent.
Two sentences from that JavaScript SEO basics page (last updated 4 March 2026) do most of the work in any dev conversation:
- "If the content isn't visible in the rendered HTML, Google won't be able to index it."
- "Google can only discover your links if they are
<a>HTML elements with anhrefattribute."
And rendering is still deferred, in Google's own words: "The page may stay on this queue for a few seconds, but it can take longer than that." Google publishes no promised timing. So treat rendering as a delay of unknown length, not an instant step — which matters for anything time-sensitive, like a launch or a news page.
Google's Googlebot documentation (last updated 3 February 2026) adds one detail: every CSS and JavaScript file "is fetched separately", each subject to the same file size limit as the page. A giant single bundle is a real risk.
Content in neither column is the actual bug.
The ten-minute test: is JavaScript really your problem?
In our own work on client sites, this is the first thing we do — before any tool, any crawl, any ticket. It needs a browser and nothing else.
- Open the page, then open view-source: on the same URL. That is the raw HTML the server sent — roughly what Googlebot receives at the crawl stage.
- Press Ctrl+F and search for one full sentence of your main body copy. Note whether it is there.
- Go back to the live page, right-click the same sentence and choose Inspect. The Elements panel is the rendered DOM, after your scripts have run. Search for the sentence again.
- Compare the two answers against the table below.
| In raw HTML? | In rendered DOM? | What it actually means |
|---|---|---|
| Yes | Yes | JavaScript is not your problem. Stop here. Look at intent, internal links, duplication or authority instead. |
| No | No | The content does not exist for anyone. This is a content gap, not a rendering fault. |
| No | Yes | JavaScript builds it. That is normal and often fine — now go and check whether Google can see it too. |
| Yes | No | Your scripts are removing server content. Rare, and worth a ticket on its own. |
Only the third row justifies the next five minutes. Content found solely in the rendered DOM does not prove a problem — Google renders JavaScript. It only moves the question to "does Google's renderer get the same result as my browser?"
How do you confirm it with Google's own tools?
Google names two tools for this in its fix search-related JavaScript problems guide (last updated 18 December 2025), and says they show "loaded resources, JavaScript console output and exceptions, rendered DOM, and more information".
| Tool | Use it for | Limit worth knowing |
|---|---|---|
| URL Inspection → Test live URL | A real-time fetch. Open "View tested page" for the HTML, HTTP headers, page resources and JavaScript console messages — plus a screenshot of the rendered page. | The screenshot is live-test only. Google's Help page describes that HTML as "the raw HTML returned", so read the screenshot for proof of rendering. |
| URL Inspection → View crawled page | What Google last indexed. Same data, minus the screenshot. | Not live. It reflects the most recently indexed version, which may be weeks old. |
| Rich Results Test | Its code explorer uses "the rendered source code" — the closest public view of the post-render HTML. Also warns when resources will not load. | Defaults to the smartphone user agent, and accesses the page as Google-InspectionTool, not Googlebot. |
Run the live test, then search the rendered source for your sentence. Present in your browser but missing there, with console errors or blocked resources listed, is the finding that earns a dev ticket. Our Google Search Console guide covers where these panels sit.
The handful of ways JavaScript genuinely breaks indexing
It is a short list, and it has barely changed in years. Every row below comes from Google's own documentation.
| Failure | What it looks like | The fix to ask for |
|---|---|---|
| Blocked resources | A disallowed /js/ folder or data endpoint. Google will not render JavaScript from blocked files. | Unblock the scripts and APIs the page needs. See our robots.txt guide. |
| Content behind interaction | Tabs, accordions, "load more", infinite scroll. Google states plainly: "Google Search does not interact with your page." | Load it on page load, or give each chunk its own URL. |
| Links that are not links | Router buttons and onclick handlers. No href, no discovery — a common cause of orphan pages. | Real <a href> elements pointing at real URLs. |
| Fragment URLs | Routes like /#/products/shoes. Google cannot reliably resolve them. | The History API, so every view has a crawlable URL. |
| Soft 404s in a single-page app | A deleted product shows "not found" but the server still returns 200. | Redirect to a URL that returns a genuine 404, or add noindex with JavaScript. More in 404 errors. |
| Reliance on browser storage | Content that depends on Local Storage, Session Storage or cookies. Google's renderer clears them across page loads. | Put the data in the page or fetch it server-side. |
A seventh is quieter: stale files. Google's renderer "may ignore caching headers", so it can run an old bundle. Ask for a hash in the filename, so a new deploy forces a new fetch.
Which rendering option should you ask for?
This is the decision that gets made in the meeting. The definitions and trade-offs below follow Google's Rendering on the web article (updated 5 January 2026).
| Option | In one line | Honest trade-off | Ask for it when |
|---|---|---|---|
| Static rendering | Pages built in advance, one HTML file per URL. | Fastest and most reliable, but every URL must be known at build time. Personalisation is awkward. | Blogs, service pages, location pages — anything that changes on a schedule. |
| Server-side rendering | The server builds the HTML for each request. | Content is always in the response, but on-demand generation can raise time to first byte and needs caching work. | Large catalogues, filters, logged-in or frequently changing pages. |
| Hydration | Server HTML first, then client scripts add interactivity. | Google's recommended middle path. But it can badly hurt responsiveness — a page that "looks ready" while nothing responds yet. | App-like interfaces that still need indexable content. |
| Client-side rendering | The browser builds everything with JavaScript. | Workable — Google renders it — but you are depending on the render queue, and the JavaScript tends to grow. | Dashboards and tools behind a login, where indexing does not matter. |
| Dynamic rendering | Serving crawlers a pre-rendered copy. | Do not ask for this. See below. | Legacy setups you are migrating off. |
A stack that cannot server-render is a platform conversation, not a plugin one. Our notes on headless CMS choices and redesign SEO cover when the move is worth it — and it belongs in a replatforming budget, not a monthly retainer.
What to put in the developer ticket
Developers do not need SEO theory. They need the route, the evidence and the acceptance criteria. Paste this shape:
TICKET: Make /category/<route> content present in the server response Evidence: body copy and product links appear only in the rendered DOM. Search Console live test screenshot shows the page body empty. Ask: server-side rendering or static generation for this route. Title, meta description, H1, body copy, canonical and internal links must be in the initial HTML response. Also required on this route: - Internal links as <a href="/real/url/">, not onclick handlers - Real URLs via the History API, no #/fragment routes - Missing items return a 404 status, not 200 with an error view - Nothing important behind a click, a tab or a scroll event - Unblock /assets/js/ and the data endpoints in robots.txt - Hashed filenames on JS and CSS bundles Done when: the Rich Results Test rendered source contains the body copy, and the live-test screenshot shows the full page.
Scope by template, not by page — fixing one template usually fixes hundreds of URLs. Then add the fixed routes to your XML sitemap and confirm canonical tags survive rendering, because a canonical injected by JavaScript is one more thing that can go missing.
Where JavaScript is not your problem
Rendering gets blamed for four problems it does not own:
- Slow pages. Heavy JavaScript hurts speed, but that is a performance project with its own measurements — see page speed optimisation and Core Web Vitals. A slow page that indexes fine does not have a rendering fault.
- Pages not getting crawled. If Google never requests the URL, rendering never happens. That is a discovery and crawl budget question.
- Content missing on mobile. Google indexes the mobile version, so content hidden only on small screens is a parity issue — mobile-first indexing covers it.
- Thin or duplicated content. Rendering perfectly will not fix two pages chasing the same query. Keyword mapping and duplicate content are their own decisions, and we have separate posts coming on both.
Work through our SEO audit checklist first and most "JavaScript problems" resolve into one of these instead.
What a render-clean site gets you next quarter
The payoff is not a ranking jump. It is that your content stops depending on a queue you do not control.
When the response already contains the copy, the links and the tags, every downstream system gets a straight answer — Google's indexer, your own crawls, and the AI surfaces that reuse indexed pages. Google says those need no extra requirements and no special markup; the page simply has to be indexed and eligible for a snippet. Rendering is how it earns that eligibility.
Fix it by template, re-test, then go back to the work that actually moves rankings. Organic results move meaningfully in roughly three to six months and compound after that — rendering fixes just stop you starting from zero.
Frequently asked questions
Can Google index JavaScript content at all?
Yes. Google runs your scripts in a headless, evergreen version of Chromium and indexes the rendered result. The condition it states is simple: if the content is not visible in the rendered HTML, Google cannot index it. So JavaScript content is indexable, but only what rendering actually produces.
Is client-side rendering bad for SEO?
Not automatically. Google renders it. The real costs are that you depend on a render queue with no published timing, that debugging is harder, and that JavaScript weight tends to grow and hurt responsiveness. If a route matters for search, server-side or static rendering removes the risk entirely.
How long does Google take to render a JavaScript page?
Google does not publish a figure. Its documentation says a page may sit in the render queue "for a few seconds, but it can take longer than that". Plan as if rendering is delayed by an unknown amount, which is why time-sensitive pages should not depend on it.
Should we use dynamic rendering or prerendering for Googlebot?
No, not as a long-term solution. Google's own page now describes dynamic rendering as a workaround and not a recommended solution, and points to server-side rendering, static rendering or hydration instead. Treat an existing prerender setup as technical debt to migrate off.
How do I check what Google sees on my page?
Use Search Console's URL Inspection tool, choose Test live URL, then open View tested page for the HTTP headers, page resources, JavaScript console messages and a screenshot of the rendered page. The Rich Results Test code explorer shows the rendered source code for the same URL.
Find out whether rendering is really the issue
We run the render check, tell you honestly if JavaScript is innocent, and write the ticket when it is not.
Make Digital Hangover a preferred source
One tap tells Google to show more of our SEO and marketing coverage in your Top Stories.