# JavaScript SEO: How Googlebot Renders Your Site **URL:** https://mettevo.com/blog/article/javascript-seo **Published:** 2026-09-28 **Updated:** 2026-09-28 **Author:** Oleg Silin **Category:** Blog | Mettevo > Learn how JavaScript affects SEO, including crawling, rendering, indexing, and common technical issues that can impact your website’s search visibility. ![JavaScript SEO](https://stage.mettevo.com/wp-content/uploads/2026/09/Developer_working_at_modern_work…_20260928132928.jpg) --- JavaScript SEO is the practice of making a JavaScript-rendered site's content, links, and metadata visible to search engines. Crawlers read the raw HTML response first and see script-generated content only after a separate rendering step. Google's own documentation splits this process into three sequential phases, crawling, rendering, and indexing, rather than a single pass. ## TL;DR - Google's own documentation splits the process into three phases, crawling, rendering, then indexing, not the "two waves" model older guides still teach. - Client-side JavaScript is not blocked from ranking, but it waits in a render queue that Google says "can take longer than" a few seconds to clear. - Seven checks, from the URL Inspection Tool to server log analysis, show what Googlebot saw on one URL, not what the page looks like in a browser. - A 60-page crawl of [Mettevo's own site](https://mettevo.com/) on August 27, 2026 found WordPress and Next.js signals on every page, a hybrid render path most guides never mention. - Google recommends server-side rendering, static rendering, or hydration over dynamic rendering, which it now calls a workaround, not a long-term fix. ## What Is JavaScript SEO? JavaScript SEO exists because two consumers read the same page differently. A browser downloads the HTML (HyperText Markup Language) and runs any JavaScript immediately, so a visitor sees the finished page at once. A crawler treats JavaScript execution as a separate, queued step, so what gets indexed depends on whether that step happens. Google's own fundamentals documentation folds rendering into the crawl itself. It states that Google "[renders the page and runs any JavaScript](https://developers.google.com/search/docs/fundamentals/how-search-works) it finds using a recent version of Chrome, similar to how your browser renders pages you visit." In practice, JavaScript SEO covers three separate failure points: - Content that only appears after a script runs. - Internal links a script builds at runtime instead of plain tags already in the HTML. - Metadata, such as title tags or canonical URLs, that a script rewrites after the page loads. Each failure point needs its own check. A single "does Google run JavaScript" answer covers none of them. ## Can Google Crawl JavaScript? Yes. Google has crawled and rendered JavaScript for years, and its documentation treats this as standard behavior. Crawling and rendering are not the same step, though, and that distinction is where most JavaScript SEO problems start. Crawling fetches the raw HTML response. Rendering, a separate pass, executes the JavaScript and produces the Document Object Model (DOM) that Google actually indexes. The gap between those two steps is where content disappears. Google documents two causes directly. A required script can be blocked in robots.txt, which [Google's JavaScript basics guide](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) calls out explicitly, and a script can throw an error during rendering, which [Google's troubleshooting guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) covers. In practice a slow or failing application programming interface (API) call produces the same outcome, since whatever has not resolved by the time the page is rendered is not there to index. Any of those leaves rendering with less content than what a visitor sees. ## How Googlebot Renders JavaScript, Step by Step Google's [JavaScript SEO documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) breaks the process into three phases. 1. Crawling fetches the page's HTML document. 2. Rendering executes the JavaScript and produces the DOM Google will use. 3. Indexing processes that result and decides how the page enters Search. If the crawled document returns a 200 status code and nothing blocks indexing, Googlebot queues the page for rendering instead of rendering it immediately. Once capacity allows, a headless Chromium instance loads the page and executes the JavaScript. Googlebot then parses the HTML for links again, queues any new URLs, and uses that rendered HTML to index the page. ### What Is the Render Queue in Google Search? The render queue is the holding stage between crawling and rendering. After Googlebot fetches a page's HTML with a 200 status code, the URL does not render immediately. It waits until Google's infrastructure has spare capacity, and the documentation is specific about it. It states that a page "may stay on this queue for a few seconds, but it can take longer than that." Google does not publish a maximum wait time or a queue position you can check. What you can check is whether one URL has already cleared the queue, using check 1 below. ### Why "Two Waves of Indexing" Is the Wrong Mental Model Now Many JavaScript SEO guides still describe two indexing passes, where Google indexes the raw HTML first and returns later once compute allows. Martin Splitt, a Google developer advocate, pushed back on that framing. In a JavaScript SEO video in March 2020, he said "there's no such thing as the second wave of crawling-ish." That same month, in posts reported by [Search Engine Roundtable](https://www.seroundtable.com/google-no-two-waves-indexing-29225.html), he called indexing "more complex than two waves of indexing." The three-phase model above treats rendering as one queued step, not a second indexing run on a fixed delay. Google's current documentation does not use the phrase "two waves" anywhere. Planning an audit around a second wave arriving weeks later means debugging a model Google's advocate dismissed years ago. What actually determines whether your JavaScript renders is the queue described above. ## Rendering Strategies Compared Not every JavaScript site puts the same weight on the render queue. The table below compares what Googlebot receives in the initial HTTP (Hypertext Transfer Protocol) response under each strategy, before any script runs. **Strategy** **What Googlebot gets in the raw HTML** **Extra render step needed for the main content** **Where you see it** Client-side rendering (CSR) A near-empty shell plus a JavaScript bundle Yes, content appears only after the render queue runs the script Plain single-page apps built with React or Vue alone. Server-side rendering (SSR) Full HTML with the content already filled in No, though hydration still runs afterward for interactivity Next.js pages rendered per request. Static site generation (SSG) Full HTML generated at build time No Marketing pages and docs sites, including Next.js static export. Incremental static regeneration (ISR) Full HTML from a cached page rebuilt on a schedule No, for the cached version Googlebot fetches Next.js catalogs and blogs that update periodically. Dynamic rendering A separate, bot-only HTML snapshot generated on request No for bots, yes for users A legacy fix Google now calls a workaround, not a recommended solution. Google's guidance is specific about that last row. Its [dynamic rendering documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) calls it "a workaround and not a long-term solution for problems with JavaScript-generated content in search engines," and recommends server-side rendering, static rendering, or hydration instead. ## Does Client-Side Rendering Hurt Rankings? Client-side rendering does not disqualify a page from ranking. Googlebot can execute JavaScript and index what it finds, using the same Chrome build described earlier. The risk is indirect. Every dependency between the raw HTML and the final content is a place the process can fail, from a blocked script to a render that times out before your JavaScript finishes. Google's [Core Web Vitals thresholds](https://web.dev/articles/inp) put a good INP at or below 200 milliseconds and a poor one above 500. The same documentation names long tasks, input delay and heavy rendering work as the drivers of a poor score, and JavaScript execution produces most of them on a script-heavy page. ## How to Audit a JavaScript Site for SEO: Seven Checks These seven checks each target a point where rendering can fail. Run them against one real URL, not a generic homepage, since templates render differently across a hybrid stack. 1. **URL Inspection Tool (Search Console).** Paste the URL, click Test Live URL, then open View Tested Page. Compare the rendered HTML tab and screenshot against what a visitor sees. Matching content means the render worked. A blank screenshot or missing text means it failed, and that content will not be indexed. 2. **Rich Results Test.** Paste any public URL, including a competitor's, without Search Console access. It uses the same rendering path as the URL Inspection Tool, so it works on unverified pages. Same read: full content in the rendered HTML tab means success. 3. **View source versus the DOM.** Fetch the raw HTML with curl or view-source, then compare it against the rendered DOM in Chrome DevTools' Elements panel. If your heading, body copy, or internal links exist only in DevTools, that content depends entirely on the render queue succeeding. 4. **robots.txt against the Network tab.** Open DevTools, filter the Network tab to JavaScript and Fetch/XHR (XMLHttpRequest) requests, then check each path against your live robots.txt. A Disallow rule matching a script the page needs means Googlebot fetches the HTML shell but never the code that fills it. 5. **Disable JavaScript in DevTools.** Open the command menu with Ctrl or Cmd plus Shift plus P, run "Disable JavaScript," then reload. That simulates the worst case, a render that never completes. If primary content and internal links vanish, the page depends entirely on Google finishing the render step. 6. **Server log analysis.** Filter access logs, or Screaming Frog Log File Analyser, for the Googlebot user agent. Check whether it requested the page's JavaScript bundles and API endpoints, not only the HTML document. Logs showing only the HTML request mean Googlebot may not execute your JavaScript there at all. 7. **PageSpeed Insights for hydration cost.** Run the URL and check Total Blocking Time in the lab data alongside INP in the field data. A page stuck in the "poor" INP band carries JavaScript weight heavy enough to risk the same delays that slow the render queue. Fixes are covered in Core Web Vitals optimization. ## The Hybrid Stack Problem: When WordPress and Next.js Share One Site Most JavaScript SEO guides assume a single stack: plain React or Vue, or Next.js alone. A large share of agency-built sites run neither in isolation. WordPress still serves as the content backend and admin interface, while a Next.js layer handles the front end, pulling content through its REST (Representational State Transfer) API. Neither layer shows up in most audits, since each checks for one CMS (content management system) fingerprint. We checked this on mettevo.com. A technical crawl covered 60 pages on August 27, 2026. The sitemap held 416 URLs when we counted it on September 14, 2026. Each page was checked for WordPress fingerprints (a generator meta tag, /wp-json/ paths) and Next.js ones (a **NEXT\_DATA** script tag, /\_next/ asset paths). All 60 pages returned both signals, one hybrid render path running underneath every page in the sample. This tells us both layers touch every page checked. It does not tell us which layer's version Googlebot indexes when the two disagree, and we did not isolate ranking impact from this pattern. Sixty pages is a sample of a larger site taken on one day, not a full-site audit, and a template change since would shift the mix. The practical risk shows up in metadata. If WordPress sets the canonical tag or Open Graph data first and a Next.js layer overwrites it after hydration, the crawled HTML and the rendered DOM disagree. Check 1 catches that on a real URL. We cover the failure modes in [our article](https://mettevo.com/blog/article/next-js-seo-metadata-changes-that-break-indexing) Next.js SEO metadata changes that break indexing. The same crawl also found 10 of the 60 pages loading slower than two seconds, the slowest at 4,197 milliseconds. We did not isolate how much came from JavaScript execution specifically, so treat it as a reason to run check 7, not a diagnosis on its own. ## JavaScript SEO Tooling The checks above work for one URL at a time. Running them at scale needs a small toolkit. **Tool** **What it checks** **Access** Search Console URL Inspection Live render versus indexed version Free, needs a verified property. Rich Results Test Live render for any public URL Free, no login. Chrome DevTools Raw HTML versus DOM, blocked requests, the JavaScript toggle Free, built into Chrome. PageSpeed Insights Hydration cost, INP, Total Blocking Time Free. Screaming Frog, JavaScript rendering mode Rendering differences across many URLs in one crawl Paid above 500 URLs. Log file analyzer What Googlebot actually requested, not a simulation Varies by tool. A crawl-scale tool answers a different question than the URL Inspection Tool. It tells you how many templates share the same rendering risk, not just whether one URL passed. Running that full checklist on every release is realistic for a one-time audit, not a monthly cadence. That is the case for handing the JavaScript layer to a web development team that treats rendering as part of the deploy process. ## FAQ ### Is dynamic rendering still a good solution for JavaScript SEO? No. Google's own documentation calls dynamic rendering "a workaround and not a long-term solution for problems with JavaScript-generated content in search engines," and points to the alternatives covered above. A guide that still recommends dynamic rendering as a primary fix in 2026 is citing advice Google has retired. ### Do single-page applications get indexed by Google? Yes. Googlebot renders single-page applications in the same three-phase pipeline as any other JavaScript site. The common failure is routing, not indexing. Google's rendering service does not reliably support URL fragments for navigation, so each view needs a real, unique URL, not hash-based routing. ### How long does Google take to index a page after rendering? Google's documentation does not give a fixed number. A page may stay in the render queue for a few seconds, though it can take longer, and indexing follows only once the rendered HTML is parsed. Treat any guide that promises a specific day count as an estimate, not a documented Google commitment. ### Should I choose server-side rendering over client-side rendering? For content that needs to rank, yes, wherever the stack allows it. Google's own guidance favors rendering content on the server, or generating it statically, over workarounds such as dynamic rendering. Client-side rendering is not banned from ranking, but it adds a dependency on the render queue and on every script loading without error, so fewer steps between crawl and content means fewer places to fail.