Key takeaways
- Google processes JavaScript pages in three phases: crawling, rendering and indexing.
- Server-side or static rendering is still the safer default; dynamic rendering is only a workaround.
- Most problems are simple: links without href, fragment URLs, wrong status codes, noindex or canonicals set by script.
- Test the rendered HTML with URL Inspection before launch, not after traffic drops.
JavaScript SEO is the part of technical SEO that makes sure search engines can find, render and index content built with JavaScript. It matters most to web design and development agencies, because they choose the framework. If that is you, our page on white label SEO for web design agencies explains how we fit into your builds. This guide covers what to check, in the same way we deliver it through white label SEO.
How does Google process JavaScript?
In three phases: crawling, rendering and indexing. Googlebot fetches the URL, queues pages that return a 200 status for rendering, runs the JavaScript in a headless browser, then indexes the rendered HTML. Google says a page may wait in the render queue for a few seconds, but it can take longer. Links found in rendered HTML go back into crawling.
All of this comes from Google's JavaScript SEO basics. Two details have practical consequences. Rendering may be skipped for pages that do not return 200, so error pages and redirects are judged on the initial response. And Google says it may skip rendering entirely when it finds a noindex tag in the original HTML, so a script that removes noindex later will not help.
Is JavaScript bad for SEO?
No. Google can render JavaScript, and many JavaScript sites rank well. The risk is in how it is used: content, links or tags that only exist after scripts run, routes that do not return proper status codes, or heavy bundles that slow the page. Built with care, a JavaScript site can be as search-friendly as a static one.
Google still recommends server-side or pre-rendering in the same guide, because it makes sites faster for users and crawlers and because not all bots run JavaScript. That last point matters more now that clients ask about AI search tools, which use their own crawlers.
What is the difference between client-side and server-side rendering for SEO?
With client-side rendering, the server sends a mostly empty HTML shell and the browser builds the page with JavaScript. With server-side or static rendering, the server sends complete HTML and JavaScript adds interactivity afterwards. For SEO, complete HTML is safer: content and links are visible on the first request, without waiting for rendering.
| Approach | What the first response contains | SEO notes |
|---|---|---|
| Client-side rendering (CSR) | An app shell; content arrives via JavaScript | Depends on rendering; riskiest for content pages |
| Server-side rendering (SSR) | Full HTML per request | Content and links visible immediately |
| Static generation | Pre-built HTML files | Fast and simple for pages that change rarely |
| Hydration | Server HTML, then JavaScript takes over | Common in Next.js and similar frameworks |
| Dynamic rendering | Different HTML for bots than for users | Google calls it a workaround, not a recommended solution |
Google's page on dynamic rendering says it creates additional complexity and resource requirements and recommends server-side rendering, static rendering or hydration instead. If a client's site still relies on a prerendering service for bots, plan the move to one of those.
What are the most common JavaScript SEO issues on React and Next.js sites?
Navigation built with click handlers instead of a elements with href, routes that use URL fragments, every URL returning 200 even when the page does not exist, titles and canonicals set inconsistently by script, content loaded only after a click or scroll, and images lazy-loaded in ways crawlers never trigger. Each one is easy to fix if caught early.
- Links: Google can only discover links that are a elements with an href attribute.
- Routing: use the History API, not fragments such as #/products, for separate pages.
- Status codes: missing pages must return 404 or a noindex, not a soft 404 with status 200.
- Noindex: do not ship noindex in the initial HTML of a page you want indexed and remove it with script.
- Canonical: set it in the HTML; if JavaScript sets it, it must match and must not duplicate the tag.
- Titles and descriptions: unique per route, not one value for the whole app.
- Lazy-loading: load images when they are about to be visible, without needing a user action.
Every item on that list is taken from Google's JavaScript SEO basics. In Next.js and similar frameworks, most of them are solved by using the framework's own link component, metadata features and server or static rendering for content pages. The problem is usually not the framework but a page or component someone built to run only in the browser.
How do you test JavaScript SEO with URL Inspection?
Inspect the URL in Search Console, run the live test, then open the tested page. Compare the rendered HTML and screenshot with what users see: main text, links, title, canonical and structured data should all be there. Check the JavaScript console messages and blocked resources under More info. Repeat for each template, not only the home page.
The URL Inspection tool shows the HTML, HTTP headers, JavaScript console output, loaded resources and a screenshot for live tests. Google's JavaScript guide also points to the Rich Results Test for viewing rendered HTML, which helps before a site is verified in Search Console, for example on a pre-launch domain. Run the tests before launch as part of the website redesign SEO checklist and as part of every page's SEO QA checklist.
Does JavaScript affect Core Web Vitals?
Often, yes. Large bundles and long tasks on the main thread delay rendering and make the page slower to respond to taps and clicks, which shows up in Largest Contentful Paint and Interaction to Next Paint. Splitting code, deferring scripts that are not needed for the first view and rendering content on the server all help.
How to explain those metrics to clients is in our guide to INP and Core Web Vitals for agencies.
How should web design agencies build JavaScript SEO into projects?
Decide the rendering approach for content pages at the start of the project, write the SEO requirements into the technical brief, and test the rendered HTML of each template on staging. Then test again on the live domain after launch. Fixing a routing or rendering decision after launch costs far more than choosing correctly before the build.
Brief
Rendering method, URL rules, metadata and status codes agreed before design is final.
Staging tests
Rendered HTML and links checked for every template.
Launch
URL Inspection on key pages, sitemap submitted, redirects verified.
After launch
Indexing and crawl checked in Search Console in the following weeks.
We review JavaScript builds under your agency's brand and hand the developer a list of exact fixes. To discuss a project, book a 30-minute call.
Frequently asked questions
Can Google index single-page applications?
Yes, if links, routes, status codes and content follow Google's JavaScript guidelines. Server rendering makes it more reliable.
Do other search engines and AI crawlers run JavaScript?
Not all of them. Google notes that not all bots run JavaScript, which is a reason to serve complete HTML.
Is Next.js good for SEO?
It can be, because it supports server and static rendering. Results depend on how each page is built.
Should we use dynamic rendering?
Only as a temporary fix. Google recommends server-side rendering, static rendering or hydration instead.
How do we check a page before it is live?
Use the Rich Results Test on a reachable staging URL to see the rendered HTML, then URL Inspection after launch.
About the author
Juan José Giraldo is a senior SEO specialist with 5+ years of experience. He works on technical and local SEO for 600+ US car dealerships and supervises the SEO of 18 US e-commerce stores. He runs White Label SEO LATAM from Medellín, Colombia, and delivers white label SEO for agencies in the US, UK, Canada and Australia. Read more · LinkedIn.