JavaScript SEO Basics 2027: How Google Crawls and Renders Your Pages

JavaScript is code that runs in the visitor’s browser. Many modern sites use it to build the page after it loads, so the first HTML a crawler gets can be almost empty. If Google never runs the code, the page stays empty to Google too.

Evergreen simply means the Chromium browser Google uses stays up to date. So “Google can’t run JavaScript” is an old myth. The real risks are smaller and more practical, and they are listed below. For the general process, see how Google Search works.

• Crawling. Googlebot checks robots.txt before it fetches anything. Google says it won’t render JavaScript from blocked files or on blocked pages.
• Rendering. Googlebot queues all pages with a 200 status code for rendering. Pages with other statuses, such as 404, may skip it.
• Indexing. Google indexes what it sees after rendering. Only content visible in the rendered HTML can be indexed.

So when someone says “my content is there in the browser”, the question is: is it there in the rendered HTML Google sees? That is a different question, and you can test it below.

// source: Google Search Central, JavaScript SEO basics. The “Do this” column is my summary.

Links deserve a second look. Google says it is fine to use JavaScript to inject links into the page, as long as they follow crawlable-link practices. A button with an onclick event that changes the page is not a crawlable link. Make it an anchor with a real address. My robots meta tag guide covers the noindex rule in detail.

1. Confirm nothing is blocked. Make sure robots.txt doesn’t block the scripts or pages you need.
2. Check the rendered HTML. Use the URL Inspection tool to view what Google rendered. Compare it with what you see in your browser.
3. Fix the links. Every navigation link should be an anchor with an href, including menus and pagination.
4. Give each view its own URL. Use the History API, not fragments.
5. Set titles, descriptions and canonicals. Keep them in the HTML where you can.
6. Handle errors properly. Return a real 404 where you can. Otherwise follow Google’s single-page app options: a JavaScript redirect to a 404 URL, or a noindex tag on error views.
7. Consider server-side rendering. Google says it is still a great idea. It also helps other crawlers.

Two smaller notes from Google’s page. Googlebot caches aggressively and its rendering service may ignore caching headers, so use content fingerprinting in file names to avoid stale scripts. And follow Google’s lazy-loading guidelines so images and content still get indexed.

A sixth one is noindex in the original HTML, “to be removed by JavaScript later”. Google warns that when it sees noindex it may skip rendering and JavaScript execution. So the page may never reach the step where your script removes it. If you want a quick refresher, the noindex tag explained shows safe use.

1. Open the URL Inspection tool and inspect the page. Check the rendered HTML for your main text and links.
2. Run the Rich Results Test on the same address. Google names it, with URL Inspection, as a way to verify rendered output.
3. Search for a distinctive sentence from the page, in quotes, a few weeks after it goes live. It is a rough check, not proof.
4. Check Search Console for indexing problems on key templates.

If this sounds like a lot, it is a good fit for my technical SEO service. A cheap SEO service for small business can include a rendering check, and I’ll explain the findings in plain English.

• Google Search Central: JavaScript SEO basics (phases, links, URLs, canonicals, robots meta, status codes, testing)

// last checked 11 Nov 2026. The seven-step order and the plain-English notes are my own.