JavaScript SEO: Why Your Pages Go Invisible to Google
By Toy Wen Da, Co-Founder · Updated · 13 min read · scored 99/100
JavaScript SEO is the practice of making sure Google and other search engines can crawl, render and index content that a browser builds with JavaScript instead of plain HTML. Google renders pages in a separate, delayed step after the initial crawl, so content can go unseen for weeks.
If you've built your site with React or Vue, or with a framework like Next.js, the gap between "crawled" and "rendered" is probably the biggest reason pages sit unindexed. The fix usually isn't complicated once you know where the breakdown happens.
What is JavaScript SEO, and why does it trip up Google?
JavaScript SEO is a branch of technical SEO focused on one problem: making JavaScript-built pages as crawlable and indexable as plain HTML pages. A traditional HTML site hands Google everything it needs in one response. A JavaScript site often hands over an almost empty shell and builds the real content in the browser.
Google can execute JavaScript and has said so for years. Doing it costs computing resources, though, and Google has to ration them across billions of pages. That rationing is where the trouble starts.
How Google crawls and indexes a JavaScript page
Google's documentation on Search Central describes rendering as a distinct step from crawling rather than something that happens during the first visit. The process runs in three parts:
- Crawling: Googlebot requests the page and reads the raw HTML. For a JavaScript-heavy page, that HTML might hold little more than a
<div id="root"></div>and a script tag. - Rendering: the page goes into a rendering queue, where Google's Web Rendering Service, built on an evergreen Chromium engine, runs the JavaScript to build the final page.
- Indexing: only after rendering completes does Google index the content, links and metadata it finds.
The Web Rendering Service now attempts to render close to 100% of the HTML pages Google crawls. Attempting to render isn't the same as rendering fast. The gap between crawl and render can run from a few hours on an established site to several weeks on a lower-authority one, and for a new product page or a time-sensitive article that can mean missing the traffic window.
The two-stage indexing problem
This is the part that catches most site owners off guard. Your page gets crawled almost immediately, but the content inside it isn't seen until much later, if it's seen at all.
| Stage | What happens | Typical timing | SEO impact |
|---|---|---|---|
| Initial crawl | Googlebot fetches the raw HTML and pulls out any static text, links and tags | Immediate | Only JS-independent content gets indexed right away |
| Rendering queue | Chromium executes the JavaScript and builds the final page | Hours to several weeks, longer on low-authority sites | Script-built content, links and structured data stay invisible until this finishes |
| Rendering failure | A script error, a blocked resource or a timeout stops rendering from completing | Unpredictable | Content never gets indexed at all |
Several factors push a page toward the slow end of that range: large JavaScript bundles, scripts blocked in robots.txt, uncaught JavaScript errors, third-party scripts that fail to load, and low site authority. Crawl budget is allocated unevenly, so bigger or newer sites often wait longer in the queue.
Client-side vs. server-side rendering: which one should you use?
Use server-side rendering (SSR) or static site generation (SSG) rather than client-side rendering (CSR) for any page you want indexed. With CSR, Google has to wait for the rendering queue. With SSR or SSG, Google receives finished HTML on the first request and there is no wait at all.
| Approach | How content reaches the browser | SEO fit | Best used for |
|---|---|---|---|
| Client-side rendering (CSR) | The browser (or Googlebot) runs JavaScript to build the page after load | Weak for public pages; depends on the rendering queue | Logged-in dashboards, internal tools |
| Server-side rendering (SSR) | The server builds full HTML for every request | Strong; content is in the first response | Product pages, blogs, landing pages |
| Static site generation (SSG) | HTML is pre-built at deploy time | Strong, and fastest to serve | Marketing sites, documentation, portfolios |
| Incremental static regeneration (ISR) | Static pages that refresh on a schedule or on demand | Strong | E-commerce catalogs, frequently updated content |
| Pre-rendered snapshots for bots | A separate HTML snapshot is served only to bots | Acceptable as a bridge, not a long-term fix | Legacy CSR sites mid-migration |
Google has said that serving bots a pre-rendered snapshot isn't cloaking as long as bots and users eventually see equivalent content. It is explicit, though, that this should be a temporary workaround. Running two rendering paths side by side means extra complexity that you have to keep in sync indefinitely.
Most development teams end up with a hybrid: SSR or SSG for anything search engines or AI answer engines should find, and CSR for logged-in experiences where indexing was never the goal. A Next.js project makes this choice at the page level, and the details are covered in this guide to Next.js SEO settings.
Signs your site has a JavaScript SEO problem
You don't need a developer to spot the early warning signs. Look for these patterns in Google Search Console and your analytics:
- Pages stay "Discovered, currently not indexed" for weeks after publishing.
- The rendered view of a page in Search Console is missing text, links or images that are plainly visible in the browser.
- Internal links built as JavaScript
onClickhandlers instead of real<a href>tags don't show up as "linked from" in Search Console. - Title tags or meta descriptions in search results don't match what's on the page.
- Structured data injected client-side doesn't validate in the Rich Results Test.
- Pagination built from JavaScript state instead of unique URLs stops deeper pages from being crawled.
When several of these appear together, the cause is almost always a rendering gap rather than a content or keyword problem. A technical SEO audit that compares rendered and raw HTML will confirm it quickly.
What has to be in your initial HTML
However much JavaScript enhances the page later, certain elements need to exist in the first HTML response. Without them, Google may treat the page as near-empty during the crawl even if the rendered version looks complete.
| Element | Why it matters for JavaScript SEO | Risk if JS-only |
|---|---|---|
| Title tag and meta description | Core ranking and click-through signal | May not appear in search results for weeks |
| H1, H2 and H3 headings | Give Google the page's topical structure | Delayed indexing, missed snippet eligibility |
| Body copy | Establishes relevance and topical depth | Page reads as empty on first crawl |
Internal links (<a href>) |
The crawl path Googlebot follows to other pages | Linked pages may never be discovered |
| Structured data (JSON-LD) | Eligibility for enhanced results and AI answer citations | Excluded from enhanced results entirely |
| Canonical tags | Prevent duplicate-content confusion | The wrong URL version gets indexed |
Run a schema markup audit alongside your rendering checks. JSON-LD injected purely by client-side JavaScript is one of the most common things to vanish from the version Google indexes.
Core Web Vitals: where JavaScript does the most damage
Heavy JavaScript delays indexing, and it also slows the page for real visitors, which counts against you as a ranking input. Google's Core Web Vitals measure the kind of lag that unoptimized scripts cause.
| Metric | What it measures | Good threshold | Common JavaScript cause |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content appears | Under 2.5 seconds | Large JS bundles delay rendering of visible content |
| Interaction to Next Paint (INP) | How responsive the page is to clicks and taps | Under 200 milliseconds | Long JavaScript tasks block the browser's main thread |
| Cumulative Layout Shift (CLS) | How much the layout jumps around while loading | Under 0.1 | Elements injected late by JavaScript push content around |
INP replaced First Input Delay as an official Core Web Vital in March 2024, a change covered in Google's web.dev documentation. It is a stricter and more realistic measure of responsiveness than its predecessor, and it penalizes the long-running scripts that JavaScript-heavy sites tend to ship.
A commonly cited target is an initial compressed bundle under 200KB, with any task longer than 50 milliseconds split into smaller chunks so it doesn't block the main thread. Google doesn't enforce either number as a hard cutoff, but both track closely with sites that pass Core Web Vitals comfortably. A short checklist covers most of the work:
- Defer scripts that aren't needed for the first paint.
- Trim unused JavaScript from the bundle.
- Split long tasks so the main thread stays free for clicks and taps.
- Fix script errors and unblock resources that robots.txt currently hides from Googlebot.
Why this matters more for SaaS and B2B sites
SaaS platforms, enterprise portals and tech marketplaces are often built as JavaScript applications from the ground up. Delayed indexing of product pages, invisible structured data and weak Core Web Vitals all hurt them at once, and they push the site below competitors on the high-intent searches where deals are won or lost.
The usual failure is a marketing site and a product app sharing one client-rendered codebase. A safer layout renders the public pages (pricing, features, docs, blog) on the server or at build time, and keeps CSR for the logged-in app where indexing doesn't matter.
Platform-by-platform fixes
The right fix depends on what you're building on.
- Shopify themes lean on JavaScript for filtering, variant selection and cart updates. That's mostly fine for SEO as long as product titles, descriptions and canonical tags stay in the server-rendered HTML. The settings worth checking are laid out in this Shopify SEO guide.
- Wix has improved its rendering handling significantly, but editor-generated interactive sections can still delay indexing if they load content asynchronously. Walk through the relevant settings in this Wix SEO guide.
- Lovable apps are often built as single-page React apps by default, which puts them in CSR territory unless you configure otherwise. This guide to SEO for Lovable sites covers how to get blog content indexed from a single prompt-built site.
- WordPress sites are usually HTML-first already, but JavaScript-heavy themes, page builders and some plugins reintroduce the rendering risk. The fixes are covered in this WordPress SEO settings guide.
- Git-based sites built with static site generators and deployed via GitHub tend to default to SSG, which is the safest rendering choice available. Deployment and indexing specifics are in this guide to SEO for GitHub-deployed sites.
- Next.js gives you the most control, letting you choose SSR, SSG or ISR per page. Metadata, sitemaps and robots.txt matter as much as the rendering mode, and the Next.js SEO guide covers them.
AI search changes the stakes
JavaScript SEO used to be a Google-only concern. Most AI crawlers, including the bots behind ChatGPT, Claude and Perplexity, do not execute JavaScript at all. Gemini is the notable exception because it uses Google's own rendering stack, though that is described as experimental and not something to rely on.
A page that depends on client-side JavaScript to show its content may therefore be invisible to AI answer engines even when Googlebot eventually sees it. To be eligible for citation in AI-generated answers, the content has to exist in the raw HTML. The same principle runs through answer engine optimization: write the answer where any crawler, human-built or AI, can read it.
How to test and monitor JavaScript SEO
You can check whether Google sees your page the way you intend without guesswork.
- Compare raw and rendered HTML. View source for the raw version, then set it beside what Chrome DevTools shows after the page fully loads. Large gaps point to a rendering dependency.
- Use Search Console's URL Inspection tool. It shows the rendered screenshot and HTML Google used, plus any JavaScript console errors it hit.
- Crawl with JavaScript disabled. A "text only" crawl mode reveals what a non-rendering bot sees, which matters given how many AI crawlers skip JavaScript.
- Watch server log files over time. Reviewing crawl frequency across a three- to six-month window shows whether important templates are revisited often enough, and whether rendering fixes improved crawl activity afterward.
- Re-run a technical audit after major framework changes. A migration to a new framework is the moment rendering regressions slip in unnoticed, and a technical SEO audit before and after catches them while they're cheap to fix.
Can you fix JavaScript SEO yourself?
Some of it, yes. Checking whether your title tags and headings appear in the raw HTML takes five minutes and a "view source" click. Adding the defer attribute to non-critical scripts, trimming unused JavaScript and making sure internal links use real <a href> tags are all changes a site owner can ask a developer for without a rebuild.
Moving a CSR app to SSR, or setting up pre-rendered snapshots as an interim fix, is a bigger project. It usually needs a developer who knows your framework, because a wrong implementation can break the functionality you're trying to preserve. If rendering architecture is the suspected culprit, bring a developer in before anyone touches production code, and use a structured SEO plan to sequence the fixes so one doesn't undo another.
Where this fits in your broader SEO work
A site with rendering problems often has gaps in local visibility, structured data or general technical health too. If you serve specific areas, pair your rendering fixes with local SEO pages built around the neighborhoods you want to rank in. If your framework also generates duplicate URLs or inconsistent canonicals, which client-side routers commonly do, catch that in the same technical pass instead of treating it as a separate project later.
FAQs
Does Google penalize JavaScript websites?
No. Google doesn't penalize a site for using JavaScript. The issue is indirect: if JavaScript delays rendering or hides content, pages get indexed late or not at all, which looks like a ranking problem but is an indexing one.
How long does it take Google to index a JavaScript page?
It varies widely. Well-established, high-authority sites can see rendering happen within hours, while newer or lower-authority sites can wait weeks for the same page to move through the queue, according to Google's own description of the process.
Is React bad for SEO?
React itself isn't, but a React app rendered entirely client-side is. Pairing React with a framework that supports server-side rendering or static generation, such as Next.js, removes most of the risk.
What's the difference between SSR and pre-rendering?
SSR builds full HTML on the server for every request, in real time. Pre-rendering generates a static HTML snapshot ahead of time (or on a bot's first request) and serves that cached version to crawlers. It is cheaper to run but needs refreshing to stay accurate.
Do AI chatbots like ChatGPT read JavaScript content?
Generally not. Most AI crawlers don't execute JavaScript, so content that appears only after a script runs is typically invisible to them. Google's Gemini is the exception because it uses Google's own rendering infrastructure, though it's still considered an edge case.
Get your rendering checked before it costs you more rankings
JavaScript SEO problems are quiet. Pages don't throw errors, they just don't show up, and nothing in your dashboard flags a rendering delay until you know to look. The fastest way to see where you stand is to compare what Google renders with what your site serves. Talk to the team and get a sample SEO report that shows what's happening on your pages right now.
Resources / References
Sources
About the author
SearchBlueprint researched, wrote and scored this article with the content pipeline our customers run on their own sites. The score in the byline is what our content engine gave this page before it published. Nothing here is reviewed by hand, which is the point: it is the product's output, published where anyone can check it.