JavaScript SEO: How Does Google Process JavaScript Pages?

At Talha Aslan and team, this is where technical audits surprise our clients most often. For example, a product grid that looks perfect in Chrome can arrive almost empty in the first HTML response Google receives. In this guide we walk through JavaScript SEO step by step, based on Google's official documentation. We also show you how to check what Google actually sees with the URL Inspection tool in Search Console.

What are the three phases Google uses for JavaScript pages?

Google's JavaScript SEO basics documentation splits the process into crawling, rendering, and indexing. The split matters because each phase fails in a different way. Therefore you cannot fix a JavaScript SEO problem until you know which phase it belongs to.

• Crawling: Googlebot requests the URL, checks robots.txt, and receives the raw HTML from your server.
• Rendering: Google runs the page's JavaScript in an evergreen, Chromium based environment and builds the resulting DOM.
• Indexing: Google evaluates the text, links, and tags in the rendered HTML. Then it decides whether to index the page.

In short, the page you see in your browser and the first response Google receives are not the same thing. A rendering step sits between them, and that step costs time and resources. So the core of JavaScript SEO is shrinking the gap between those two versions.

What does Googlebot see first during crawling?

On the first request, Googlebot only gets the raw HTML your server sends. If that HTML already contains the title, meta tags, links, and body text, Google understands the page right away. However, when the browser builds the content entirely, the raw HTML is often just an empty container and a few file references.

During crawling, Googlebot checks robots.txt first. If robots.txt disallows the URL, Google never requests it, so the page never reaches rendering. Next, Googlebot extracts the href values in the raw HTML and adds new URLs to its crawl queue. That is why links in the initial HTML speed up discovery.

Here is an example scenario. A store on example.com loads its category products through an API call after the page opens. On the first crawl, Googlebot sees neither product names nor product links. The products only appear once rendering finishes. As a result, Google discovers new products more slowly.

What is the render queue and why does it cause delays?

According to Google's documentation, Googlebot queues all pages that return a 200 HTTP status code for rendering. The exception is a page where a robots meta tag or header tells Google not to index it. Pages wait in the queue until Google has resources available, and that wait varies from site to site.

Google does not publish a fixed rendering delay. Therefore we cannot give you a reliable number for how long Google takes to render JavaScript. What we do know is that rendering happens separately from crawling. Also, it is not always obvious from the outside which phase a page is currently in.

In practice, this means one thing. When you leave critical content and links to JavaScript, discovery and indexing take an extra step. You feel that gap most on fast moving content such as news, campaigns, or stock levels. In addition, a script that throws an error during rendering can leave the content missing entirely.

Why does the rendered HTML decide indexing?

After rendering, Google makes its indexing decision based on the rendered HTML. In other words, the version that competes for rankings is the one built inside Google's rendering environment. It is not necessarily the final state in a visitor's browser. Usually the two match, but timeouts, blocked files, or broken code can widen the gap.

Google also extracts links from the rendered HTML again and sends any new URLs to crawling. Because of this, Google can still discover links that JavaScript injects. That said, this discovery happens in a second pass. The only thing Google reliably sees is the content that actually exists in the DOM once rendering finishes.

General diagnosis of unindexed pages is outside the scope of this article. For that, see our guide on how to find unindexed pages in Search Console. Here we focus only on causes that come from JavaScript.

What is the difference between client side and server side rendering?

Client side rendering (CSR) builds the HTML inside the visitor's browser with JavaScript. Server side rendering (SSR) builds the HTML on the server and sends a complete page. Static rendering generates pages ahead of time at build. Hydration then takes server generated HTML and makes it interactive in the browser.

The takeaway is simple. On pages that should earn search traffic, sending the content in the first response removes most JavaScript SEO risk from the start.

Which rendering method fits your site?

The right method depends on what the page is for. For example, an admin dashboard behind a login will never appear in search results, so client side rendering works fine there. Category, product, service, and blog pages carry organic traffic, however. For those, building the HTML on the server or at build time is the safer choice.

We covered server side rendering for Vue projects in our article on what Nuxt is and when you need Vue SSR. If you use React or another framework, the logic stays the same. Pages that matter for search should return meaningful HTML in the first response.

When we make this call, we ask three questions. First, does this page expect visitors from search? Second, how often does its content change? Third, can the development team maintain server side code over time? The answer usually sits where those three overlap. That way, you also limit technical debt from day one.

Should you still use dynamic rendering?

Dynamic rendering means serving server rendered HTML to bots while users get the JavaScript heavy version. In its dynamic rendering documentation, Google calls this a workaround and not a recommended solution. The stated reason is the extra complexity and resource requirements it creates.

Instead, Google recommends server side rendering, static rendering, or hydration. Google also says it generally does not consider dynamic rendering to be cloaking on its own. However, serving completely different content to users and crawlers can count as cloaking. So the two versions need to stay similar.

If you already run an older dynamic rendering setup, you do not need to switch it off tomorrow. Still, choosing it for a new project makes little sense when a permanent fix exists. Otherwise you end up keeping two versions in sync forever, and bugs tend to appear in the gaps between them.

Why should every link be an a element with an href?

Google can reliably discover links only when they are a elements with an href attribute. According to the crawlable links documentation, links that JavaScript inserts later also work, as long as they keep that markup. Problems start with elements that respond to clicks but carry no real URL.

Based on the examples in Google's documentation, these are the patterns to use and avoid:

• Recommended: an a element whose href holds a real URL, such as a link to /products/category/shoes.
• Recommended: an a element with both a real href and an onclick handler. The browser runs the handler, and Google follows the URL.
• Avoid: an a element that navigates through onclick alone, with no href.
• Avoid: an href on a span or similar element, or framework specific attributes such as routerLink.
• Risky: an href value that starts with javascript:.

For example, if a menu codes its categories as buttons only, Google struggles to find the path to those categories. The fix is straightforward. Give every navigation item a real URL, then handle the click behavior with JavaScript.

How should you structure URLs in a single page application?

A single page application (SPA) swaps views inside one HTML document. Older setups separated those views with the part of the URL after the # sign, such as example.com/#/products. Google advises against using these fragments to load different page content.

Instead, Google recommends the History API. With it, every view gets its own real URL, such as example.com/products/. You also write links with a real href and handle navigation with pushState. As a result, a visitor who refreshes the page or shares the URL lands on the same content.

Then run one more check. When someone opens a view's URL directly, does the server return the right content? In some setups, every URL except the homepage shows a blank page or an error on direct access. In that case Googlebot cannot render those URLs, so it cannot index them either.

Why might a noindex added or removed by JavaScript fail?

Google states that when it encounters a noindex tag, it may skip rendering and JavaScript execution. Therefore, if the raw HTML contains noindex, removing it with JavaScript may not work. Google can drop the page without ever rendering it.

The reverse direction is risky too. If the raw HTML has no noindex and JavaScript adds one later, it becomes unclear at which phase Google will see it. In short, pages you want indexed should not contain noindex in their original code. For pages that must stay out of the index, put the tag directly in the server response.

If Search Console shows this status for your pages, our article on the "Excluded by noindex tag" status explains it step by step. The key point here is to tell whether the tag comes from the server or from a script.

How do you prevent soft 404 errors in a single page application?

A soft 404 happens when a page that does not exist still returns a 200 status code. This is common in SPAs, because the server sends the same app file for every URL and client code shows the error message. Google's documentation admits that meaningful status codes can be impossible or impractical in this setup.

For this case, Google suggests two approaches:

1. Use JavaScript to redirect the visitor to a URL where the server really returns a 404 status code.
2. Add a noindex robots meta tag to the error view with JavaScript.

The second option may seem to contradict the noindex warning above. However, here the goal is already to keep the page out of the index, and Google drops it once it sees the tag. That said, returning a real 404 or 410 from the server is always the cleanest fix whenever you can.

Can JavaScript set titles, meta descriptions, and structured data?

Yes. Google's documentation says you can use JavaScript to set or change the title element and the meta description. Likewise, you can use JavaScript to generate JSON-LD structured data and inject it into the page. Google asks you to test that implementation either way.

In practice, though, shipping these elements in the initial HTML carries less risk. Social media previews and some other crawlers may not run JavaScript at all. In addition, mistakes like the same title on every page show up more often in apps that route on the client side.

Here is an example scenario. An SPA on example.com forgets to update the title when a visitor moves to a product page. As a result, every product page carries the homepage title. We catch these bugs quickly by checking the rendered HTML in the URL Inspection tool. The check takes a few minutes and prevents real losses.

What happens if robots.txt blocks your JavaScript files?

Google won't render JavaScript from blocked files or on blocked pages. So if robots.txt blocks the script that builds your content, the rendered page comes out incomplete. The same thing happens when robots.txt blocks the API endpoints that deliver your data.

Teams usually make this mistake with good intentions. For example, someone blocks the /api/ or /assets/ folder to save crawl budget and does not notice that the page content depends on it. The page looks full in the browser, yet Google sees it empty.

To check, look at the loaded page resources in the URL Inspection tool, where any blocked resource shows up. We collected other frequent robots.txt problems in our article on common robots.txt mistakes and fixes. In short, never block a resource that produces content.

How do you see the rendered HTML in the URL Inspection tool?

The URL Inspection tool in Search Console is the official way to check how Google sees your page. According to the Search Console Help page, it shows the raw HTML returned, the HTTP headers, JavaScript console output, and any page resources loaded. Follow these steps for JavaScript SEO diagnosis:

1. Open the property in Search Console and paste the full page URL into the inspection bar at the top.
2. To see the indexed version, open "View crawled page."
3. To see the current state, click "Test live URL," then open "View tested page."
4. In the HTML tab, search for critical content such as the product name, main copy, and links.
5. Review the screenshot. The Help page notes that a screenshot of the rendered page is available only in a live test.
6. Under "More info," check for resources that failed to load and for JavaScript console output.

This extra response data does not appear in every case. For the indexed version, the Help page says it appears only when the URL is on Google. For the live test, it appears only when the URL is available to Google.

How do you compare raw HTML with rendered HTML?

The goal of the comparison is to confirm that the content Google sees after rendering matches what you see in the browser. First, open the page source in your browser, which is the raw HTML the server sent. Then look at the HTML output of the tested page in the URL Inspection tool, which is the rendered state.

During the comparison, we check these elements one by one:

• Are the title and meta description correct in both versions?
• Do the main copy, product names, and prices appear in the rendered HTML?
• Do the canonical and robots meta tags conflict with the server response?
• Are navigation and internal links real a elements with an href?
• Does the structured data appear complete in the rendered HTML?

When JavaScript changes the canonical tag, Google may choose a different version of the page. We covered these conflicts in detail in our guide to canonical issues in Search Console. Running the comparison once per template is usually enough.

Why do caching and content fingerprinting matter?

Google's documentation says Googlebot caches aggressively in order to reduce network requests and resource usage. In addition, the Web Rendering Service (WRS) may ignore caching headers. As a result, Google can render your page with an outdated JavaScript or CSS file.

The fix Google recommends is content fingerprinting. With this approach you put a hash of the file content into the file name, such as main.2bb85551.js. When the file changes, the name changes too, so Google fetches it as a new resource. Most modern build tools already do this by default.

Here is an example scenario. Example.com ships a new release, but the script keeps the same file name. The new HTML no longer matches the old script, so rendering throws an error and content goes missing. Generating fingerprinted file names largely removes this risk.

Which browser features does Googlebot not use?

Google's JavaScript troubleshooting documentation explains that Googlebot does not keep certain browser behaviors the way a user does. If your content depends on them, Google may not see it. Therefore you should plan for the following points at the design stage:

• Permission requests: Googlebot declines prompts such as camera access, so content should never depend on them.
• State: Local Storage, Session Storage, and HTTP cookies do not persist across page loads.
• Connection types: Googlebot does not support WebSockets or WebRTC, so provide an HTTP fallback.
• Feature support: WebGL, for instance, is not supported. Use feature detection and fallbacks for critical APIs.
• Web components: Rendering flattens the light and shadow DOM. Components that do not use slots can lose content.

For example, a site that saves a language choice in storage and shows content based on it will show Googlebot the first screen every time. So the main content should exist on the page without any user interaction.

Do lazy loading and infinite scroll hide content from Google?

Lazy loading delays images and some content until the visitor is about to see them. Google calls this a good strategy for bandwidth and performance, but it asks you to follow its lazy loading guidelines. The trouble starts when content appears only after an interaction such as scrolling or clicking.

Googlebot does not browse a page like a person. Because of this, products behind a "show more" button or reviews that load on scroll may not appear in the rendered HTML. Instead, give each page of a paginated list a real URL and link to those URLs with a href.

We explained the correct lazy loading setup for images in our article on what lazy loading is and how it affects SEO. The speed side of JavaScript lives in our guide on how JavaScript affects site speed. Here we focus on visibility, not speed.

Is using JavaScript bad for SEO?

No, JavaScript on its own is not bad for SEO. Google runs JavaScript in an evergreen Chromium based environment, and many sites built on modern frameworks rank without trouble. The problem is not the language. It starts when content and links exist only in the browser.

In audits, we split JavaScript into two groups. The first group enhances interaction: filter animations, cart drawers, and form validation. That code rarely carries SEO risk. The second group builds content and navigation. This second group needs real attention, because the text Google sees depends directly on it.

So "let's remove JavaScript" is usually the wrong decision. Instead, ship the main content in the first response and leave interactivity to JavaScript. That protects both the user experience and search visibility. For the other technical basics, see our list of technical SEO tips.

How do you log JavaScript errors that affect Google?

Google's troubleshooting documentation says you can use a global onerror handler to log JavaScript errors from users and from Googlebot. However, the same page notes that some error types, such as parse errors, never reach this kind of log. So treat that log as a useful hint, not a complete list.

The Rich Results Test and the URL Inspection tool also show loaded resources, JavaScript console output, and the rendered DOM. In routine maintenance we check those tools first and then the server logs. That way we can tell whether an error comes from the script or from the server.

After a fix, run the same test again, which is also the final step Google recommends. If you want a quick look at a page's general technical state, our SEO checker reviews titles, meta tags, and link structure.

What does a step by step JavaScript SEO checklist look like?

We follow this order before every new template or major release. The order matters, because a problem in an early step distorts the results of later steps.

1. List the page types that should earn search traffic: homepage, category, product, service, and blog.
2. Check the raw HTML for each type. Confirm that the title, main copy, and links exist in the first response.
3. If content is missing from the first response, plan a move to server side or static rendering.
4. Make sure every navigation item is an a element with a real href.
5. Move views separated by # to real URLs with the History API.
6. Confirm that robots.txt allows the scripts and API endpoints that build content.
7. Send noindex, canonical, and title tags correctly in the raw HTML.
8. Set up a real 404 or a noindex solution for pages that do not exist.
9. Use content fingerprinting in file names.
10. Run a live test in the URL Inspection tool and compare rendered HTML with raw HTML.

For a fast single page review, our guide on a 10 minute SEO check of a page also helps.

Who fixes and monitors JavaScript SEO issues on your site?

JavaScript SEO problems rarely disappear with a single setting. Developers, content people, and SEO need to look at the same picture. That is why we at Talha Aslan and team first map the gap between raw and rendered HTML for each template. Then we hand developers a fix list they can actually ship.

The work does not end at deployment. We monitor indexing status, crawled pages, and rendering errors in Search Console for weeks afterward. You can find the full scope of that process on our SEO consulting services page. We do not promise rankings. We do build the technical foundation Google needs to see your pages completely.

If you suspect a similar issue on your site, send us a few example URLs. You can request a proposal with a scope and process tailored to your site through our SEO consulting page. Together we then confirm whether the problem comes from JavaScript or from another technical cause.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.