JavaScript SEO: why Google sometimes cannot see your content

JavaScript SEO is about making sure search engines see the content your JavaScript conjures up on screen. The short answer: Google does render JavaScript, but not always the way you think, and when rendering goes wrong, Google does not index your content. Almost every modern site runs on JavaScript (according to W3Techs, 98.9% of all websites use it), so this affects practically everyone. In this article you will learn which rendering problems are most common, how to spot them, and how to fix them without waiting for months.

Measure it yourself: run your page through our free website speed test and check your Core Web Vitals.

What is JavaScript rendering and why does it matter for SEO?

A page exists in two versions. The raw HTML is what the server sends before JavaScript runs. The rendered HTML is what you see after JavaScript has executed. The difference between the two is exactly what JavaScript SEO is about.

There are two ways to handle that rendering. With server-side rendering, the server builds the complete page up front and sends it ready-made to the browser. With client-side rendering, the browser (or the crawler) first gets bare HTML and has to execute the JavaScript itself to finish the page. That second approach is slower and more error-prone, and it is inadvisable for most sites, as web.dev on client-side rendering also explains.

Here is the point: if JavaScript does not render for your visitor, it certainly will not render for Google’s crawler. And what Google cannot render, it cannot index or rank. For a B2B site, an invisible page does not mean a missed click, but a missed lead. That is why JavaScript SEO belongs in your website strategy, alongside your content and your technical SEO.

Can Google actually read JavaScript?

An important nuance: Google does not crawl JavaScript, but it can render it. It converts your JavaScript into rendered HTML, and then crawls and indexes that HTML. In theory, your content still makes it in.

In practice, there is a catch. That rendering costs Google extra time and resources, it happens in a separate step after the first crawl, and it can go wrong in dozens of ways. One blocked file, one conflicting directive, and your content falls through the cracks. So do not count on Google always “sorting it out”. You check it yourself.

Think of Google’s processing as a chain your page has to pass through step by step. Every step after crawling is another place where a JavaScript page can quietly drop out.

How do you spot rendering problems?

The core is always the same test: compare your raw HTML with your rendered HTML, an approach that Semrush also puts front and centre in its explainer on JavaScript rendering. If they differ on things that matter (the page title, the H1, the body text, links, hreflang), you are at risk the moment rendering starts to falter.

A few concrete ways to check this:

• Google Search Console. The URL inspection shows you the rendered HTML and a screenshot of the page as Google fetches it. It is part of the basics Google describes in its documentation on JavaScript SEO. If you do not see your content there, Google does not see it either. How to read this is covered in Google Search Console explained.
• A crawler such as Screaming Frog. It can put both versions side by side and shows exactly where JavaScript adds content that is missing from the raw HTML.
• Viewing the source code. Open your page, view the page source, and search for your most important text and titles. If they are not there, they only arrive via JavaScript.

An analysis of three well-known SaaS sites (Zoom, Asana and a marketing blog) showed that even large, technically mature brands suffer from this. At Zoom, the hreflang attribute was missing from the raw HTML, the H1 was not there, and the raw title read “Loading” while the rendered title was “Zoom Learning Center”. In itself often no disaster as long as rendering succeeds, but every difference is a potential leak the moment that rendering fails.

Which JavaScript rendering problems are most common?

Three problems keep coming up. The good news: all three are fixable.

Blocked .js files in robots.txt

If I could highlight just one, this is it. If you block your JavaScript files in your robots.txt, Google can never fetch them, so never render them, so never index the content behind them. In the SaaS analysis, all three sites had blocked JS resources to a greater or lesser extent; on the best-performing site the damage was limited to a handful of URLs.

The fix is surprisingly simple: have your robots.txt adjusted so critical resources (your JavaScript files) are no longer blocked. After that you do not have to wait weeks for Google to come back on its own; you can explicitly request a recrawl of your URLs via Search Console.

Conflicting directives

Directives are instructions to crawlers, such as noindex (do not index) and nofollow (do not pass link value). The problem arises when your raw HTML contains a different directive than your rendered HTML. If noindex appears in one version and not in the other, Google does not know what to do, and the result is often that neither version gets indexed. It can even produce a timeout error in your performance reports.

The solution: make your intent unambiguous. If you want a page to be indexed, remove the noindex from both the raw and the rendered HTML. If you want to keep it out of the index, make sure noindex appears in both versions.

Links that do not render

Links that only exist in JavaScript can fail to render, for instance because a plugin is disabled or a theme file has been deleted. The consequence: if the link does not render, Google cannot follow it, and you pass no internal link value to the destination page. On a B2B site where you want to strengthen your most important service pages with internal links, authority leaks away right there. Check regularly which JavaScript links fail to render and clean them up, also to prevent script bloat.

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

For most B2B sites, this is the most important structural choice. With server-side rendering (SSR), the crawler gets a complete page: the server fetches the data, builds the HTML, and sends it off. No extra render step, no waiting, nothing that can go wrong in Google’s browser. With client-side rendering, you push that work to the client, with all the risks that entails.

If you are building a new site or planning a migration, choose server-side rendering or a variant that already puts the most important content in the raw HTML. It is the cleanest way to rule out rendering problems in advance. And it fits your Core Web Vitals: less client-side JavaScript often means a faster, more stable page.

What should you do with this as a B2B company?

Honest advice: you do not need to get paranoid about this, but you do need to check it properly once. Most rendering errors have no visible effect until the moment they suddenly do, and then you lose an important page from the index without noticing.

Our stance is simple: steer on customers and revenue, not on vanity numbers. A rendering problem on a blog nobody visits is not worth fixing. A rendering problem on your service page or your main landing page is a direct threat to your lead flow. We are a small team, so we always start with the pages that make money, not with a checklist that saddles you with 200 trivial fixes.

A B2B site is not a webshop either. You do not have ten thousand product pages that all need to render; you have a handful of pages that really count. That makes it manageable. Working through a technical SEO checklist or having an SEO audit done gives you clarity within a few hours on whether Google really sees your money pages correctly. That kind of check belongs in ongoing SEO maintenance, not in a one-off clean-up.

Frequently asked questions about JavaScript SEO

Can Google index my JavaScript content?

Yes, Google can render JavaScript and index the resulting HTML. But that happens in a separate step that can fail, for example because of blocked files or conflicting directives. So do not trust it blindly and check it via the URL inspection in Search Console.

What is the difference between raw and rendered HTML?

Raw HTML is what the server sends before JavaScript runs. Rendered HTML is what you see after JavaScript has executed. Important elements that only appear in the rendered version (title, H1, text, links) are at risk if rendering fails once.

How do I know whether my site has a rendering problem?

Compare the two versions. Use the URL inspection in Google Search Console or a crawler such as Screaming Frog and check whether your most important content, titles and links appear in the rendered HTML that Google fetches.

Is server-side rendering always better?

For SEO usually yes: the crawler gets a complete page without an extra render step, so less can go wrong. It is also good for load speed. For most B2B sites it is the safest choice.

Have it checked whether Google really sees your most important pages

JavaScript SEO is not an academic exercise: if Google does not render your service page, you lose leads without noticing. We look first at the pages that bring in revenue, tell you honestly whether there is a real problem, and only fix what matters. No list of 200 cosmetic fixes, but a site Google can read in full.

Book your free intake