If your public pages rely on JavaScript to reveal internal links, some AI systems may never discover them. That’s a technical SEO issue, but for B2B SaaS teams in 2026 it’s also a pipeline issue, because the pages most likely to influence buying decisions, pricing, integrations, comparisons, security, docs, are often the same pages AI search needs to find and cite.

The uncomfortable part is that many teams still work from an old assumption: Google can render JavaScript, so the site is probably fine. That was never a full guarantee. Now it’s even less useful, because AI crawlers often fetch raw HTML and stop there.

A 41-day experiment reported by Search Engine Land made the gap hard to ignore. In that test, one set of pages was linked with standard HTML, while another relied on JavaScript-injected links. Googlebot reached only 2% of the JavaScript-linked pages, versus 5% of the HTML-linked pages. Tracked AI bots, including GPTBot, ClaudeBot, PerplexityBot, Meta’s crawler, and Amazon’s crawler, found zero of the JavaScript-linked hierarchy pages.

Why this matters now

Growth leaders are dealing with two shifts at once. First, AI search experiences are answering more questions inside the interface, which can reduce click-through traffic to websites. Second, if AI crawlers can’t reach your core pages in the first place, your brand has less chance of being named, cited, or used as a source in those answers.

That changes the measurement model. Sessions still matter, but they’re no longer the whole story. Brand presence inside ChatGPT, Perplexity, Gemini, and Google AI Mode is becoming a leading indicator, especially for assisted conversions and high-intent research behavior.

For B2B SaaS, the exposure risk is pretty specific. If pricing, feature, integration, security, or comparison pages are only reachable through JavaScript-driven navigation, they can become effectively invisible to crawlers that only read the initial server response. Public acquisition content disappears. Your app can stay modern and client-rendered; your revenue pages shouldn’t gamble on that same setup.

What the crawl data actually says

The experiment’s setup was clean enough to isolate the variable that matters: discovery through links. One group of sections used hard-coded HTML links. The other used JavaScript to inject child links after page load, with other discovery paths removed. A crawler that didn’t execute JavaScript would see an empty container, not a navigable path.

But the data tells a different story than the usual “Google handles JS” line. Google’s crawler stack was the only one that showed meaningful JavaScript execution, and even there the split mattered. GoogleOther crawled far more of the JavaScript-linked set than Googlebot did. That distinction matters because GoogleOther’s activity doesn’t tell you what will reliably make it into Google Search. Googlebot is the row to watch for search visibility, and in that test it barely moved: 2% coverage for JS-linked pages.

There was another signal worth paying attention to. In the JavaScript-linked group, coverage fell with depth. One cited example showed GoogleOther dropping from 67% of division pages to 42% of class pages. Six of ten JavaScript-linked sections received no Googlebot hierarchy crawl over 27 days. Discovery also lagged: JavaScript-linked pages were found 18% to 27% later than HTML-linked pages at each depth level.

That lag is operationally important. Discovery through raw HTML is immediate. Discovery through JavaScript adds extra steps: fetch, render, extract URLs, queue children, then crawl them. Some branches make it through. Some don’t. The pages that fail discovery aren’t ranking slowly. They’re absent.

What to change on a B2B SaaS site

The practical fix isn’t “rebuild the whole site.” It’s a rendering split based on commercial importance. Public, revenue-linked pages should be server-rendered, statically generated, or prerendered so that the initial HTML response already contains crawlable links and page content. Authenticated product areas can remain client-rendered.

That hybrid model fits how most SaaS teams already work. Use SSR or SSG for pricing, features, integrations, comparisons, security, and key documentation. Use SSG or ISR for blog and help content that changes on a predictable cadence. Keep CSR for logged-in dashboards and personalized app views where public discovery isn’t the goal.

There’s a second layer here. AI visibility isn’t only about crawlability. Extraction matters too. Pages that answer questions directly, use clear information architecture, include comparison tables where appropriate, and publish structured data are easier for AI systems to interpret and cite. Crawlability gets you into the room. Content structure helps you stay in the conversation.

How to audit this without a long rewrite cycle

Start with the source HTML, not the rendered browser view. If critical internal links only appear after JavaScript runs, that’s the problem to fix first. Compare raw HTML against the rendered DOM. Validate that priority pages are reachable through real links in the initial response, not click handlers or injected components.

Then spot-check visibility across AI systems. Search for the categories where you expect to be discovered, integrations, alternatives, security requirements, pricing comparisons, and record whether your brand is named or cited in ChatGPT, Perplexity, Gemini, and Google AI Mode. This is directional attribution, not proof of incrementality. Still, it gives marketing, product, and RevOps a shared baseline.

The broader lesson is simple. JavaScript itself isn’t the enemy; relying on JavaScript-only discovery paths is. For years, “Google renders JS” was enough to end the conversation. In 2026, that answer is too narrow for how buyers actually find vendors. If your most valuable pages aren’t present in raw HTML, they may exist for users and still be missing for the systems now shaping demand.