JavaScript SEO: why Google sometimes cannot see your content

Google renders JavaScript, but not always the way you think. When rendering fails, your content isn’t indexed: on Zoom’s Learning Center the raw title read “Loading” and the H1 was missing.

And 98.9% of websites use JavaScript, according to W3Techs, so this affects almost everyone.

The biggest rendering risk isn’t Google’s renderer. It’s the JavaScript files you block yourself in robots.txt.

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

What does “JavaScript not rendered” mean for SEO?

It means Google only sees the bare HTML, not the content your JavaScript adds. 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) gets bare HTML first and has to run the JavaScript itself to finish the page.

That second approach puts the work on the client, and it’s more fragile. web.dev’s advice is to provide as much HTML from the server as possible.

So if JavaScript doesn’t render for your visitor, it won’t render for Google’s crawler either.

What Google can’t render, it can’t index or rank. That’s why JavaScript SEO belongs in your website strategy, alongside your content and your technical SEO.

For a B2B site, an invisible page isn’t a missed click. It’s a missed lead.

Can Google read JavaScript?

Yes, but with a catch. Google doesn’t crawl JavaScript, but it can render it.

It turns your JavaScript into rendered HTML, then crawls and indexes that HTML. In theory, your content still makes it in.

In practice, 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 don’t count on Google always “sorting it out”: check it yourself.

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

How do you check whether Google renders your JavaScript, with a real example?

Compare your raw HTML with your rendered HTML. That core test never changes.

If they differ on things that matter, such as the page title, the H1, the body text, links or hreflang, you’re at risk the moment rendering falters.

Three ways to check:

• Google Search Console. The URL inspection shows you the rendered HTML and a screenshot of the page as Google fetches it. Google’s own JavaScript SEO basics tell you to look at the rendered HTML in that tool. If your content isn’t there, Google doesn’t see it either. How to read it 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’s 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 aren’t there, they only arrive via JavaScript.

Big brands get this wrong too. An analysis of three well-known SaaS sites (Zoom, Asana and a marketing blog) found this on Zoom’s Learning Center:

That’s often harmless while rendering works.

But every difference is a leak the moment 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

Fix this one first. If you block your JavaScript files in robots.txt, Google can never fetch them, so it never renders them and never indexes the content behind them.

Google says it plainly: its search “won’t render JavaScript from blocked files or on blocked pages”.

In the SaaS analysis, all three sites had blocked JS resources to some degree. On the best-performing site, the damage was limited to a handful of URLs.

The fix is surprisingly simple: adjust your robots.txt so critical resources (your JavaScript files) are no longer blocked.

After that, you don’t have to wait weeks for Google to come back on its own. You can request a recrawl of your URLs in Search Console.

Conflicting directives

Directives are instructions to crawlers, such as noindex (don’t index) and nofollow (don’t pass link value).

The problem arises when your raw HTML contains a different directive than your rendered HTML. Google notes that when it finds noindex, it may skip rendering altogether.

If noindex appears in one version and not the other, Google doesn’t know what to do. Often neither version gets indexed, and it can even show up as a timeout error in your performance reports.

The solution: make your intent unambiguous. If you want a page 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 don’t render

Links that only exist in JavaScript can fail to render, for instance because a plugin is disabled or a theme file was deleted.

If the link doesn’t render, Google can’t follow it. You pass no internal link value to the destination page.

On a B2B site where you want to strengthen your key service pages with internal links, that’s exactly where authority leaks away. Regular checks also help you prevent script bloat.

Check which JavaScript links fail to render, and clean them up.

Is server-side rendering better for SEO than client-side rendering?

For most B2B sites, yes. It’s the most important structural choice you’ll make here.

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 break in Google’s browser.

With client-side rendering, you push that work to the client, with all the risks that brings.

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’s the cleanest way to rule out rendering problems up front. And it fits your Core Web Vitals.

Less client-side JavaScript usually means a faster, more stable page.

Which pages should a B2B company check first?

The pages that make money: your service pages and main landing pages. Start there, not with a checklist.

You don’t need to panic about this. But do check it properly, once.

Most rendering errors have no visible effect until the moment they suddenly do. 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 isn’t worth fixing.

A rendering problem on your service page or main landing page is a direct threat to your lead flow.

We’re 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 isn’t a webshop. You don’t have ten thousand product pages that all need to render, just a handful that really count.

That makes it manageable. A technical SEO checklist or an SEO audit tells you within a few hours whether Google really sees your money pages.

That check belongs in ongoing SEO maintenance, not a one-off clean-up.

Frequently asked questions

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 don’t take it on faith: check it with 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 even 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 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’s also good for load speed. For most B2B sites it’s the safest choice.

What’s an example of JavaScript not being rendered for SEO?

Zoom’s Learning Center: the raw HTML had “Loading” as its title, no H1 and no hreflang. All three only appeared after rendering, so a failed render would hide them from Google.

Does Google really see your most important pages?

If Google doesn’t render your service page, you lose leads without noticing. We look at the pages that bring in revenue first and tell you straight whether there’s a real problem.

No list of 200 cosmetic fixes. Just a site Google can read in full.

Send us your most important service pages and we’ll tell you whether Google really sees them. Get in touch