Many modern websites rely on JavaScript to build what visitors see. Menus, product filters, booking tools and even whole pages can be created in the browser. This can make a site feel quick and interactive. It also raises a fair question for business owners about whether Google can read it all.
The short answer is that Google can run JavaScript, but there are limits and delays. Google explains how this works in its Search Central documentation for developers. Knowing the basics helps you ask the right questions of whoever builds your site. It can also explain why some pages take longer to show up in search than others.
The three stages Google works through
Google’s guide to JavaScript SEO basics describes three main phases. These are crawling, rendering and indexing. Crawling is when Googlebot fetches a page address. Rendering is when it runs the JavaScript to see the finished page, and indexing is when that content is stored so it can appear in search.
Google uses an up to date version of the Chromium browser to do the rendering. Before fetching any address, Googlebot checks the site’s robots.txt file. If a page or a script file is blocked there, Google will not fetch it. Blocking the JavaScript files a page depends on can leave Google with an empty or broken version of the page.
Why some pages wait in a queue
Pages that return a normal 200 status are placed in a queue for rendering. Google says a page may stay there for a few seconds, but it can take longer. Once resources allow, the JavaScript runs and Google reads the rendered HTML. Any new links it finds there are added to the crawl queue.
This is why server rendering is still worth considering. Google’s documentation says server side rendering or prerendering makes a website faster for users and crawlers. It also notes that not all bots can run JavaScript. If the main content is already in the HTML the server sends, nobody has to wait for scripts to fill it in.
The same thinking applies to the people who build sites. Our article on the technical skills you need to become a web designer is a good starting point for anyone learning this side of the work. A developer who understands rendering can choose the right setup at the start. Changing it later is usually harder and more expensive.
Use real links that Google can follow
Google finds new pages by reading links in the HTML. Its guidance says it can only reliably discover links that are standard anchor elements with an href attribute. Buttons or other elements that change the page through a script are not treated as links. If your menu is built that way, Google may never find some of your pages.
Some single page apps load different content using fragments, the part of an address after a hash sign. Google advises against this and recommends the History API for changing the address as people move around the site. Each piece of content then has a proper URL that can be crawled, shared and bookmarked. Ask your developer which approach your site uses if you are unsure.
Titles, descriptions and canonical tags
Every page needs a clear title and meta description so people can pick the right result. Google confirms that JavaScript can set or change both. Still, having them in the original HTML is simpler and less likely to go wrong. Each page should have its own wording rather than repeating the same text everywhere.
Canonical tags tell Google which version of a page is the main one. Google prefers the canonical tag to be set in the original HTML. If JavaScript does set it, the value should match the HTML version. Google also advises against adding several canonical tags or having scripts change an existing one.
Good titles only help if the content behind them is worth reading. If you publish articles, our guide on writing SEO optimised blog posts for a law firm covers ideas that suit many other industries too. Clear writing and sound code work together. One without the other tends to hold a site back.
Status codes and missing pages
Servers send a status code with every page. A 404 tells search engines a page does not exist, and a redirect tells them it has moved. In a site that handles its routing in the browser, the server may send a normal status code for every address. That can create a soft 404, where an error page looks like a real page to Google.
Google suggests two fixes for JavaScript sites. One is to redirect to a server address that returns a proper 404. The other is to use JavaScript to add a robots noindex tag to error pages. Either way, missing pages stop competing with your real content in search.
Be careful with noindex
The robots noindex tag tells Google not to index a page. Google notes that when it sees noindex in the original code, it may skip rendering altogether. That means removing the tag later with JavaScript may not work. If you want a page in search, leave noindex out of the original HTML.
This can catch out sites that launch from a staging copy. A noindex tag added during the build can stay in place long after the site goes live. It is one of the first things to check if new pages are not appearing. If you are weighing up outside help, our article on spending money on SEO looks at that decision.
Old files and caching
Googlebot caches files heavily and may ignore caching headers. That can leave it using an old copy of your JavaScript or CSS after you update the site. Google recommends content fingerprinting, where the file name changes whenever the content changes. Ask your developer whether your build process does this already.
Structured data, web components and lazy loading
JSON-LD structured data can be created with JavaScript and added to the page. Google asks that you test it so you know it is working. Web components are handled by flattening their content into the rendered HTML. Only content that is visible in that rendered HTML can be indexed.
Lazy loading delays images until a visitor scrolls near them. It can save bandwidth and help pages load faster. Google describes it as a good approach for images, provided it is set up in a search friendly way. Test the page afterwards to check that the images still appear in the rendered version.
How to check what Google sees
You do not have to guess. The URL Inspection tool in Search Console shows the rendered HTML Google has for a page. The Rich Results Test can show rendered HTML as well. Compare that with what you see in your browser, and look for missing text, links or images.
SEO advice changes over time, and older articles can date quickly. Our look back at the top SEO trends in 2019 shows how much has moved on in a few years. For JavaScript sites, the current Google documentation is the best reference. Check it whenever your site is rebuilt or a new framework is chosen.
Frequently asked questions
Can Google read websites built with JavaScript?
Yes, Google runs JavaScript using an up to date version of Chromium. It does this in a separate rendering step after crawling. That step can be delayed, so content already in the original HTML avoids the wait.
Is server rendering better for SEO?
Google says server side rendering or prerendering is still a great idea. It makes sites faster for users and crawlers. It also helps bots that cannot run JavaScript.
Why are my JavaScript pages not showing in Google?
Possible causes include blocked script files, links that are not real anchor elements and a leftover noindex tag. Addresses built on fragments can also stop pages being found. The URL Inspection tool is a good place to start looking.
What is a soft 404?
It is an error page that sends a normal status code instead of a 404. Search engines can mistake it for a real page. Google suggests a redirect to a proper 404 or a noindex tag added by JavaScript.
JavaScript and search can work well together. The main thing is giving Google clean links, sensible status codes and content it can actually see. A quick check in Search Console after each major change will catch most problems early.