JavaScript SEO: How Google Renders JavaScript and How to Avoid Indexing Problems

Google can render JavaScript, but rendering adds a step that static HTML doesn’t need. Content, links and metadata that only appear after scripts run can be delayed, missed or interpreted differently from what visitors see.

This guide explains Google’s three-phase process, the problems that come up most on React, Vue, Angular and heavily scripted WordPress or Shopify themes, and a testing routine that shows exactly what Googlebot sees.

How Google processes JavaScript

1. Crawling: Googlebot fetches the URL and reads the HTML response. It checks robots.txt first; blocked files aren’t fetched.
2. Rendering: pages that return 200 are queued for rendering. Google’s documentation says a page may stay in the queue for a few seconds, but it can take longer. A headless Chromium runs the JavaScript.
3. Indexing: Google uses the rendered HTML to index content and discover more links.

If a page returns an error status, or a noindex is present in the initial HTML, Google may skip rendering altogether. That’s why the initial response matters even on JavaScript sites.

Problem 1: links Google can’t follow

Google can only reliably discover links that are <a> elements with an href. Navigation built from buttons, divs with click handlers, or href="javascript:..." may not be followed.

Pattern	Crawlable?
<a href="/products/shoes">Shoes</a>	Yes
<a href="/products/shoes" onclick="…">	Yes (href present)
<span onclick="goTo(‘/products’)">	Not reliably
<a onclick="goTo(‘/products’)"> (no href)	Not reliably
<a href="javascript:goTo(‘products’)">	Not recommended

For single-page apps, use the History API for routing so each view has a real URL, not a #fragment. Links inserted by JavaScript are fine as long as they use normal <a href> markup. See Google’s link best practices.

Problem 2: titles, meta and canonicals set by script

JavaScript can set the title and meta description, and Google can use them. Canonicals are riskier: Google advises putting the canonical in the HTML source and not using JavaScript to change it to something else. Make sure only one rel=canonical exists after rendering.

Problem 3: noindex and JavaScript

If the initial HTML contains noindex, Google may skip rendering, so a script that later removes the noindex may never run for Google. If you want a page indexed, don’t include noindex in the original page code. Adding noindex with JavaScript to error views is acceptable, but test it.

Problem 4: soft 404s in single-page apps

Client-side routing often returns 200 for every URL, including views that show “not found”. Google reports these as soft 404s. Google’s documentation suggests two fixes: redirect with JavaScript to a URL where the server returns 404, or add a noindex robots meta tag to error views with JavaScript. See how to find crawl errors.

Problem 5: stale or blocked resources

• Blocked files: scripts and styles disallowed in robots.txt aren’t used when rendering. Check your robots.txt, especially old rules for /wp-includes/ or asset folders.
• Aggressive caching: Google may ignore caching headers and use an older copy of a script. Use content fingerprinting (a hash in the file name, like main.2bb85551.js) so a new version means a new URL.
• Lazy-loaded content: content loaded only on scroll or click may not be seen. Lazy-load images properly and keep main text in the page.

Problem 6: structured data and web components

JSON-LD injected by JavaScript is supported, but test it with the Rich Results Test or URL Inspection. Google flattens shadow DOM and light DOM content when rendering, so content in web components is indexable only if it appears in the rendered HTML.

Rendering strategies compared

Approach	What Google receives	SEO notes
Server-side rendering (SSR)	Full HTML on first response	Most reliable; content and links visible without rendering
Static generation / pre-rendering	Pre-built HTML files	Very reliable for content that doesn’t change per request
Client-side rendering (CSR)	Mostly empty HTML plus scripts	Works for Google when done carefully; other crawlers may see little
Hybrid (SSR + hydration)	HTML first, then interactive	Common in modern frameworks; check hydration doesn’t change key content

Google still recommends server-side rendering or pre-rendering because not all bots run JavaScript. That includes many social media crawlers and, in our experience, a number of AI crawlers.

How to test what Google sees

1. Open the page in Search Console’s URL Inspection and click Test live URL.
2. Open View tested page: check the rendered HTML for your main text, headings, internal links, canonical and structured data.
3. Check the screenshot for missing sections and the JavaScript console for errors.
4. Compare with the raw HTML (view-source) to see what depends on rendering.
5. Repeat for each template: home, category, product or article, and an error page.

JavaScript issues often surface as indexing problems; see how to fix indexing problems. For platform-specific work, see our technical SEO service.

Frequently asked questions

Sources

• Google Search Central: Understand JavaScript SEO basics
• Google Search Central: Link best practices for Google
• Search Console Help: URL Inspection tool
• Google Search Central: How Google interprets the robots.txt specification
• Search Console Help: Page indexing report

Last reviewed October 12, 2026.