Is JavaScript Bad for SEO? How to Tell If Google Sees It

Someone told you your site is 'built in JavaScript' and that this is why you are not ranking. That diagnosis is usually wrong, and it usually costs you a rebuild you did not need.

The honest answer is no, but. Google does run your JavaScript. It just runs it late, and it will not click anything. Those two facts explain almost every real case of missing content on a service-business website.

Does Google actually index JavaScript content?

Yes. Google processes JavaScript pages in three phases — crawling, rendering, and indexing — and executes the JavaScript with an evergreen version of Chromium before indexing what comes out. That is straight from Google's JavaScript SEO documentation.

The catch is timing. Google says pages get queued for rendering, and that a page may stay on this queue for a few seconds, but it can take longer than that. Rendering happens once Google's resources allow. Nobody outside Google can tell you how long that is for your site.

So client-side rendering is a delay tax, not a death sentence. Google's own doc still says server-side or pre-rendering is a great idea, because it is faster for users and crawlers, and because not every bot runs JavaScript at all — which increasingly matters when AI crawlers are fetching your pages.

The rule that actually decides your fate is one line in Google's web-components guidance: if the content is not visible in the rendered HTML, Google cannot index it. Everything below is a way that rule bites you.

How do you check what Googlebot really sees on your page in 60 seconds?

Open Search Console, run URL Inspection on the page, click Test Live URL, then View Tested Page, then the HTML tab — that is the rendered HTML Google actually got. Ctrl+F for a sentence from your own service copy. If it is not there, Google does not have it.

The Rich Results Test does the same job and does not need Search Console access, so it works on a prospect's site. Google names both tools as the way to check rendered output.

Do not use your browser's View Source for this. View Source shows the HTML your server sent. Right-click, Inspect shows the DOM after your browser ran the JavaScript. Neither one is what Google stored. Only the rendered HTML in Search Console is. This is step one of any real technical SEO audit.

Is your service copy hidden behind a tab or accordion?

Content inside a tab or accordion is fine — as long as the text is already in the rendered HTML and the click only shows or hides it with CSS. Google explicitly permits moving content into accordions or tabs, provided the content is equivalent to your desktop version.

The version that kills you is the one where the tab fetches its copy on click. Your 'Root Canals' tab is empty markup until someone taps it, and then JavaScript pulls the text from an API. Googlebot never taps. Google's guidance is blunt: it will not load content that requires user interactions such as swiping, clicking, or typing.

You cannot tell these two apart by looking at the page. They look identical in a browser. The only way to know is the rendered-HTML check above: open the tab-hidden text, copy a sentence, and search for it in Google's rendered HTML.

This is the single most expensive pattern for service businesses, because the tabs are almost always where the service descriptions live — the exact copy that is supposed to rank you for 'emergency AC repair' or 'estate planning attorney'.

Why are your client-side review widgets invisible to Google?

Most review widgets fail one of two ways: they render inside an iframe, which means the review text belongs to the widget vendor's page and not yours, or they inject the text only after a scroll or click event, which Googlebot never fires.

A widget that writes review text straight into your page's DOM on load is fine — Google renders it and can index it. Check with the same Ctrl+F test: search the rendered HTML for a reviewer's first name. If the name is missing, your testimonials contribute nothing to the page.

One more trap: if you add Review or AggregateRating structured data, Google's guidance is that your structured data must match the visible text on the page. Marking up reviews that are not in the rendered HTML is not a clever workaround — it is a mismatch.

The lazy fix is boring and it works: publish a handful of real reviews as plain text in your page's HTML, and let the widget be a bonus on top.

Do load-more buttons and JS location lists get crawled?

No — not unless each item has a real link. Google can only crawl a link if it is an anchor element with an href attribute. Google's link best practices doc lists what fails, including span elements pretending to be links and anchors that only carry an onclick handler.

So a Load More button that appends the next 10 service areas is a dead end for crawling. Same with a locations map that pulls its list from an API and prints city names as div elements. Every one of those city pages is orphaned unless another page links to it.

For anything paginated, Google asks for the same three things: give each chunk a persistent unique URL, keep the content on that URL stable, and link sequentially to those URLs so a crawler can walk the set. If your locations list has 40 cities, you need 40 anchor tags in the rendered HTML. That is the whole requirement.

Which platforms cause this most — Wix, Webflow, or custom React?

Custom React and Vue builds cause it most, by a wide margin. Wix and Webflow serve your main body copy in HTML by default; the risk on those platforms lives in the widgets and apps you bolt on, not in the platform itself.

Verdict: the platform is almost never the problem — the pattern is. A React site rendered on the server is fine. A Webflow site whose entire service list is a third-party embed is not. Judge the rendered HTML, not the logo in the footer. If you are choosing a stack now, we lay out the tradeoff in Next.js vs WordPress for a marketing site.

Two more limits worth knowing on custom builds. Google's rendering service clears cookies, local storage, and session storage between page loads, so anything gated behind saved state will not render. And Googlebot declines browser permission requests, so a page that demands camera or location access before showing content shows Googlebot nothing.

When is JavaScript actually the wrong tool for a marketing page?

When JavaScript is the only way your primary content exists. Client-side rendering is the wrong choice for the four page types that carry your revenue: service pages, location pages, pricing, and the blog posts feeding them.

Everything on those pages that a search engine — or an AI engine — needs to read should arrive as HTML from the server. Use JavaScript for what it is good at: booking widgets, chat, form validation, image galleries, maps. None of that has to be indexable.

If your primary content is client-side today, you do not need a rebuild. You need server-side rendering or static pre-rendering for the templates that matter. We walk through the choice in static generation vs server rendering for a marketing site, and it is usually a week of work, not a quarter.

Do the 60-second check first. Half the sites accused of a JavaScript problem do not have one, and the other half have one specific broken widget. Either way, you now know which.

If the rendered HTML is missing your service copy and you would rather someone else own the fix, our technical SEO service starts with exactly this render audit — month-to-month, no lock-in, no ranking guarantees. Get my free audit.