JavaScript SEO Basics: How Google Renders JS Sites

Many modern websites are built with JavaScript frameworks like React, Vue, Angular or Next.js. A beginner often hears two opposite things: "Google can't read JavaScript" and "Google handles JavaScript just fine." Both are half true, and the confusion causes real problems, like pages that look perfect to people but appear almost empty to Google.

In this lesson, I will explain how Google processes JavaScript, the difference between client-side and server-side rendering, the common traps that hide content or links from Google, and how to test your own pages. You don't need to be a developer. You just need to know enough to ask the right questions and spot trouble.

How does Google handle JavaScript pages?

Let me start with a quick refresher. In the lesson on how search engines work, you learned that Google crawls pages and then indexes them. For JavaScript pages, Google adds a step in the middle. Its JavaScript SEO basics guide describes three phases:

Crawling: Googlebot downloads the page's HTML, the raw code your server sends.
Rendering: Google runs the page's JavaScript in a headless Chromium browser (a version of Chrome with no screen) to build the final page, just like a visitor's browser would.
Indexing: Google uses the rendered HTML, the page after JavaScript has run, to understand and store the content.

Here is the catch. Pages wait in a render queue before rendering. Google says this can take a few seconds or longer. Also, anything Google sees in the raw HTML before rendering, like a noindex tag, can affect whether rendering happens at all.

An everyday example: imagine a recipe card that arrives as a blank card plus a set of instructions for writing the recipe on it. A person (the browser) follows the instructions and reads the recipe. Google also follows them, but only after the card has waited in a pile for its turn. If the instructions fail, Google is left with a blank card.

Why does this matter for you? Two reasons. First, anything that breaks during rendering, such as a script that times out or a file Google can't load, can leave Google with less content than your visitors see. Second, links that only appear after JavaScript runs can only be found once the page has waited its turn and been rendered, which adds a step before Google discovers the pages they point to. Neither is a disaster on its own, but together they explain why JavaScript sites need a little more care.

For a closer look at the crawling side, see my post on how Googlebot works.

Client-side vs server-side rendering: what is the difference?

Rendering simply means turning code into the page people see. The big question is where that happens.

Client-side rendering (CSR): the server sends a mostly empty HTML shell, and the visitor's browser runs JavaScript to build the content.
Server-side rendering (SSR): the server runs the code and sends complete HTML, with the content already in place.
Static rendering (pre-rendering): complete HTML pages are built ahead of time, often when the site is published, and served as ready files.
Hydration: the page arrives as full HTML from the server, and JavaScript then "wakes it up" to make it interactive.

Approach	What Google gets in the first HTML	SEO risk
Client-side rendering	An empty shell; content appears only after rendering	Higher: content depends on JavaScript running correctly
Server-side rendering	Full content and links	Low
Static rendering	Full content and links	Low
SSR or static with hydration	Full content, with interactivity added after	Low
Dynamic rendering	Full HTML for bots, JavaScript version for people	Workaround that Google no longer recommends

Google's page on dynamic rendering calls it "a workaround and not a recommended solution," and recommends server-side rendering, static rendering or hydration instead. So if your developer is choosing an approach for a new site, I suggest asking for one of those.

Server-rendered HTML also helps beyond Google. Many AI crawlers don't run JavaScript the way Googlebot does, which I explain in my post on whether AI crawlers render JavaScript. And my deeper comparison of server-side vs client-side rendering goes into the trade-offs.

Can Google follow links that JavaScript creates?

Links are how Google discovers your pages, as you saw in the lesson on internal linking. Google is clear about this: it can only reliably find links that are <a> elements with an href attribute. JavaScript can add these links to the page, and that's fine, as long as they are real links.

Here are good and bad examples:

Code	Can Google follow it?
`<a href="/shoes/running/">Running shoes</a>`	Yes, a real link with a URL
`<span onclick="goTo('/shoes/running/')">Running shoes</span>`	No, there is no href
`<a onclick="goTo('/shoes/')">Shoes</a>`	No, there is no href
`<a href="#/shoes/running">Running shoes</a>`	Not reliably; hash (#) URLs are not treated as separate pages

That last example matters for single-page apps (SPAs), sites where JavaScript swaps content without loading a new page. Older SPAs used the part after the # (the "fragment") to change views. Google says it can't reliably resolve these URLs and recommends the History API, which lets JavaScript change the address bar to a real path like /shoes/running/.

What JavaScript traps hide content from Google?

Most JavaScript SEO problems come from a handful of patterns. Here are the ones I would check first.

Content that only loads after a click or scroll

Google doesn't click buttons or scroll like a person. Its guide on lazy loading says your content should load when it becomes visible in the viewport, without relying on user actions such as scrolling or clicking. Lazy loading itself is fine, and helpful for speed, when it uses the browser's built-in lazy loading or the IntersectionObserver API. For "infinite scroll" lists, give each chunk its own unique URL, like ?page=2, and link those pages so Google can find them.

Error pages that return "200 OK"

In an SPA, a missing product can show "Sorry, not found" while the server still says everything is OK (a 200 status code). Google may treat that as a soft 404 or even index the error page. Google suggests either sending a JavaScript redirect to a URL that returns a real 404, or adding a noindex tag with JavaScript on the error view.

Changing noindex with JavaScript

If the original HTML contains noindex, Google may skip rendering that page entirely. So removing noindex with JavaScript later may never be seen. If you want a page indexed, keep noindex out of the original code. My lesson on indexing covers noindex in more detail.

Canonical tags set by JavaScript

Google prefers the canonical tag in the original HTML. If JavaScript must set it, it should match what the HTML says, and there should be only one canonical tag on the page.

Other things Google won't do

Google's JavaScript troubleshooting guide adds a few more points:

Googlebot declines permission prompts, like camera or location access. Don't hide content behind them.
Rendering is stateless. Cookies, local storage and session storage are cleared between page loads, so content shouldn't depend on them.
Googlebot caches files aggressively and may use an old version of your JavaScript or CSS. Putting a content-based code (a "fingerprint") in file names, like main.2bb85551.js, forces a fresh download when files change.
Blocking JavaScript or CSS files in robots.txt can stop Google from rendering the page properly.

How do you test whether Google sees your JavaScript content?

You don't have to guess. Google gives you two free tools that show the rendered page as Google sees it: the URL Inspection tool in Google Search Console and the Rich Results Test. Both show the rendered HTML, and the URL Inspection live test also lists page resources and JavaScript console messages.

Here is a quick way to compare what people see with what Google gets:

Pick one important page, such as a product or service page.
In Chrome, right-click and choose "View page source." This is the raw HTML, before JavaScript. Search it (Ctrl+F or Cmd+F) for a sentence from the main content.
In Search Console, paste the URL into URL Inspection and click Test live URL, then View tested page.
Look at the HTML tab and search for the same sentence. If it appears there, Google can see it after rendering.
Check the screenshot and the "More info" panel for resources that failed to load and JavaScript errors.
Finally, search Google for the exact sentence in quotes, plus site:yourdomain.com, to see whether that text is indexed.

If the sentence is missing from the raw HTML but present after rendering, your page relies on rendering. That can work, but server-side or static rendering is the safer choice for important pages. My longer guide on making JavaScript sites search-friendly covers more fixes.

Try it: test one JavaScript-heavy page on your site

Now do it yourself. Choose the page on your site that relies most on JavaScript, often a product listing, a filter page, a booking widget or a page built with a page builder. Then run through this mini checklist and note the answers:

Is the main heading and first paragraph in the raw page source?
Does the URL Inspection live test show the same content you see in your browser?
Are menu and category links real <a href> links? (Right-click a link: if "Open link in new tab" works, it usually is.)
Do lazy-loaded sections appear in the rendered HTML without scrolling?
Does a made-up URL like /this-page-does-not-exist/ return a real 404 or a "not found" page with a 200 status?

If any answer is "no," send your notes to your developer along with the Google guides linked in this lesson. That's usually enough to start the right conversation. If your site runs on Next.js, my Next.js SEO guide has framework-specific tips.

Questions beginners ask about JavaScript SEO

Can Google index JavaScript websites?

Yes. Google renders JavaScript in a headless Chromium browser and indexes the rendered result. Problems come from how a site is built, such as missing links, content behind clicks or errors during rendering.

Is client-side rendering bad for SEO?

Not automatically, but it adds risk because your content depends on JavaScript running correctly in Google's renderer. For important pages, server-side rendering, static rendering or hydration is safer.

Should I use dynamic rendering?

Google describes dynamic rendering as a workaround and not a recommended solution. It suggests server-side rendering, static rendering or hydration instead.

Do other search engines and AI tools render JavaScript too?

Not all of them do it as fully as Google. Serving your key content in the initial HTML is the safest way to make sure every crawler can read it.

Is a WordPress site a "JavaScript site"?

Usually not. Most WordPress pages are built on the server and arrive as full HTML. Some plugins, sliders, tabs and page builders do load content with JavaScript, so it is still worth testing key pages.

Make your content visible before JavaScript runs

In brief, Google crawls, renders and then indexes JavaScript pages. It can handle JavaScript, but rendering adds a delay and extra places for things to go wrong. Use real <a href> links, real URLs instead of # fragments, lazy loading that doesn't need clicks or scrolls, proper 404s, and keep noindex and canonical tags right in the original HTML. When in doubt, test with URL Inspection.

In the next lesson, we cover international SEO and hreflang, for sites that serve more than one country or language. If your site is built on a JavaScript framework and you want an expert to check how Google sees it, feel free to ask us for a quote.

JavaScript SEO Basics