JavaScript SEO for AI Search: 9 Rendering Failures That Hide SaaS Content From LLM Crawlers

JavaScript SEO for AI search fails at three separate layers: crawler access, raw HTML and rendered DOM. DerivateX tests all three on every technical audit, because 28% of ChatGPT-cited pages have zero organic Google visibility, and a page Googlebot renders fine can still return an empty shell to an AI crawler fetching the same URL.

• “It works in Chrome” and “Google indexes it” are two different tests, and neither tells you what an AI crawler received when it fetched your pricing page.
• The failure is almost never the whole site. It is specific commercial content: pricing, feature matrices, integration lists, comparison tables, security pages.
• Every fix in this article has the same shape: reproduce the failure, capture evidence in raw HTTP or logs, ship a change, then re-test the same way.
• Raw HTML is the safest assumption. If your commercial claims exist only after hydration, you are betting your retrievability on rendering behavior that no engine contractually commits to.
• Fixing rendering does not create citations. It removes the reason you cannot earn them.

---

Why can Google see a page that ChatGPT cannot?

Because Google runs a rendering step that it documents, and most AI retrieval paths are not built the same way. Google describes its own process for JavaScript sites in three stages, crawling, rendering and indexing, and notes that rendering can be deferred until resources are available. That is written down in the Google Search Central documentation on JavaScript SEO basics. Google invested years and a lot of compute in a headless rendering pipeline so that single page applications would still index.

An AI answer, by contrast, is assembled from several different mechanisms. Some of it comes from a model’s training data. Some comes from a live fetch by a search-oriented crawler. Some comes from a third-party index the vendor licenses. Some comes from a user-triggered browse of one URL. Those paths have different budgets, different timeouts and different levels of JavaScript support, and vendors change them without announcement.

DerivateX treats that as an engineering constraint rather than a debate. When four retrieval paths can each see something different, the only content you can rely on is content present in the first HTTP response. The approved evidence for divergence is already sitting in public data: 80% of URLs cited by ChatGPT and Perplexity are not in Google’s top 100, and only 11% of domains are cited by both ChatGPT and Perplexity. Those two numbers describe surfaces that overlap far less than most SEO teams assume.

This is where the reader with strong Google rankings gets unfairly blamed. Nothing you did caused this. Your site was built for a crawler that renders, and it does render, and your rankings prove it. A second class of consumer arrived that reads the document more literally, and nobody told engineering. The wider DerivateX work on technical SEO fixes that change AI search visibility covers the non-JavaScript half of the same problem.

---

How do you test JavaScript SEO for AI search in 20 minutes?

Run the same URL through three fetches and compare what each one contains. DerivateX calls this the three-fetch diagnostic, and it takes about twenty minutes per template, not per page. Pick your five highest-intent URLs: pricing, the main product page, one integration page, one comparison page, and the security or compliance page.

1. Start with raw HTML and no JavaScript. Fetch with curl and read the body: curl -sL -A "OAI-SearchBot" https://yoursite.com/pricing -o raw.html. Then check whether your prices, plan names, feature rows and product claims are literally in that file. Search it: grep -io "per seat" raw.html.
2. Capture the rendered DOM next. Open the same URL in Chrome DevTools, run the page, then copy the full DOM from the Elements panel. This is what a rendering crawler could see, at best.
3. Run a bot-agent fetch from outside your network. Repeat step one from a cloud IP with the user agents for the crawlers you care about, including GPTBot, OAI-SearchBot and PerplexityBot, and record the status code and byte count for each.

Then diff the three captures against each other. If raw HTML has 400 words and the rendered DOM has 2,400, you have found the gap, and the missing 2,000 words are usually the part your buyer needs. Use the pass and fail grid below to name the failure before you argue about fixes.

Raw HTML (no JS)	Rendered DOM	Bot-agent fetch status	Diagnosis	Owner
Content present	Content present	200	Rendering is not your problem here, look at content and corroboration.	Content and off-site
Shell only	Content present	200	Client-side injection. Commercial content depends on hydration.	Front-end engineering
Content present	Content present	403, 401, 429 or a challenge page	Access block at the edge, not a rendering issue.	Infrastructure or security
Shell only	Shell only until a click or scroll	200	Interaction-gated content. No crawler clicks tabs.	Front-end engineering
Content present, wrong canonical or title	Correct canonical and title	200	Metadata injected client-side. Identity signals unreliable.	Front-end engineering
Content present for Googlebot only	Content present	Shell for AI user agents	Prerender or dynamic rendering with a stale user agent whitelist.	DevOps team
Nothing at target URL	Content reachable only via in-app navigation	200 on home, 404 or shell on deep URLs	Discovery failure. Routes are not addressable or not linked with real hrefs.	Front-end engineering

---

The 9 rendering failures that hide SaaS content from LLM crawlers

These are the nine patterns DerivateX finds most often on B2B SaaS sites at $5M to $50M ARR, ordered roughly by how much commercial content they hide. Each one gets the same treatment: the failure, the test, the evidence that proves it, the fix, and the re-test that closes it.

Failure one: pricing and feature data injected after hydration

The failure is that plan names, prices, seat limits and feature rows are fetched from an API on the client, so the first response contains a heading and an empty container. Test it with the raw HTML fetch and grep for a price string. The evidence of failure is a body where <div id="root"></div> or a skeleton loader is followed by a bundle script and nothing else. The fix is server-side rendering or static generation for that route, so the price is a string in the HTML, not a promise. Re-test by fetching the URL again and confirming that grep returns the price and the plan names. DerivateX treats pricing pages as the single highest priority template, because pricing and plan comparison is one of the most common prompts a buyer types before they ever visit a vendor site.

Failure two: content locked behind tabs, accordions and modals

Interaction-gated content is the most under-diagnosed failure on software company sites. Feature detail lives behind five tabs, security answers live in an accordion, and the integration list opens in a modal. Test by loading the page with JavaScript disabled in DevTools, then by capturing the rendered DOM without clicking anything. Evidence of failure is content that appears in the DOM only after a click handler fires, or panels rendered with display:none and empty children. The fix is to render all panel content into the DOM on load and hide it with CSS, or to give each tab its own addressable URL. Re-test by searching the rendered DOM before any interaction for text from tab four. DerivateX has seen entire security and compliance answers, the exact content that decides enterprise deals, sitting in an accordion that no crawler ever expanded.

Failure three: routes that are not crawlable links

Client-side routers can produce navigation that a human can use and a crawler cannot follow. Buttons with click handlers, div elements with router pushes, and hash fragments all break discovery. MDN Web Docs documents the Navigation API as the successor to the History API and window.location, aimed specifically at the needs of single page applications, so this is well-trodden ground for your engineers. Test by fetching raw HTML and counting anchors: grep -o '<a [^>]*href="[^"]*"' raw.html | wc -l. Evidence of failure is a low anchor count on a page that visibly has twenty navigation items. The fix is real <a href> elements pointing at real server-resolvable URLs. Re-test the anchor count and confirm each target returns 200 on a direct fetch with no referrer. DerivateX counts anchors in raw HTML on every template it audits, because a site with dense internal linking in the browser can carry almost none in the document a crawler actually receives.

Failure four: lazy loading that never triggers

Content loaded on scroll through IntersectionObserver assumes a viewport that scrolls. A crawler fetch does not scroll, and a headless render may not either. This commonly hides comparison tables, customer logos, testimonial blocks and long-form sections below the fold. Test by capturing the rendered DOM immediately after load without scrolling, then comparing it to the DOM after a full scroll to the bottom. Evidence of failure is content that only exists in the second capture. The fix is to server-render text content and reserve lazy loading for images and heavy media. Re-test with a no-scroll DOM capture. DerivateX applies one rule here: lazy load pixels, never lazy load claims.

Failure five: canonicals, titles and meta injected client-side

Many SaaS front ends set the title, description and canonical through a head-management library after mount. Google usually reconciles this. A literal reader of the first response may not. Test with curl -sL URL | grep -iE '<title>|canonical|og:title' and compare against the rendered head. Evidence of failure is a template default such as “React App” in raw HTML, a canonical pointing at the home page, or no canonical at all. The fix is to emit title, description and canonical server-side per route. Re-test with the same grep and confirm the values match the rendered head exactly. DerivateX scores metadata parity between the raw head and the rendered head as a pass or fail item rather than a refinement, because when an engine quotes you, the title in the raw response is often the label attached to your brand.

Failure six: edge blocks you did not know you had

Access failures masquerade as rendering failures. A WAF rule, a bot management setting, a rate limit or a plugin can return 403 to a specific user agent while a browser sails through, which means your effective bot policy may live in an edge dashboard rather than in your repository. On WordPress, security tooling does this deliberately: Hide My WP Ghost lists AI crawler blocking, plus automatic robots.txt disallow rules for AI crawlers, among the Pro features on its pricing page. Test with bot-agent fetches from an external IP and record status codes per agent. Evidence of failure is any non-200 for GPTBot, OAI-SearchBot or PerplexityBot while a Chrome user agent gets 200. The fix is an explicit allow rule at the edge and a plugin setting review. Re-test the same fetch matrix and confirm 200 across every agent you want reading the site. DerivateX asks for the edge configuration and the installed plugin list before it will sign off on any rendering diagnosis, because a policy nobody remembers setting is the most common single cause of a silent AI visibility gap.

Failure seven: prerender served only to a stale user agent whitelist

Dynamic rendering solves the problem for the bots on the list and quietly recreates it for everyone else. Most whitelists were written when the list was Googlebot, Bingbot and a few social scrapers. Test by fetching the same URL with three agents and comparing byte counts: Googlebot, an AI crawler agent, and plain curl with no agent string. Evidence of failure is a large response for Googlebot and a small one for the others. The fix that DerivateX recommends is to stop maintaining the list and render server-side for all requests, because user agent lists rot and nobody owns them after the engineer who wrote it leaves. If you must keep dynamic rendering, add the AI crawler agents and set a quarterly review. Re-test with the byte-count comparison until all three responses are within a few percent of each other.

Failure eight: commercial answers that live inside third-party widgets

Pricing calculators, review widgets, docs embedded in an iframe and chat assistants all hold real answers that are not in your document. Support tooling makes this explicit: a website assistant such as ChatBot.com positions itself as answering buyer questions inside the widget, generated at conversation time from a knowledge base you control. That is useful for visitors and invisible to retrieval, because the answer never becomes part of the page. Test by fetching raw HTML and searching for the text of the answer, then checking whether it appears anywhere outside the widget’s script. Evidence of failure is a question your buyers ask constantly, answered nowhere in your HTML. The fix is to publish the same answers as indexable page content and let the widget keep serving them too. Re-test with grep on raw HTML for three of your top support questions. DerivateX counts widget-only answers as missing content rather than as content, which is usually the fastest argument to win with a product team.

Failure nine: sitemaps and soft failures under bot conditions

The last cluster survives every audit because it only breaks under conditions humans never experience. Sitemaps generated client-side or exported nightly from a stale database list URLs that no longer resolve. Consent scripts block the bundle when no cookie is set. Geo-gating serves a different page to a data center IP. Slow time to first byte pushes a render past its budget. Test by fetching the XML sitemap directly and spot-checking 20 URLs for 200 status, then fetching key pages with no cookies, from two regions, and logging response times. Evidence of failure is any mix of 404s in the sitemap, an empty body without a consent cookie, or a first byte beyond a couple of seconds. The fix is server-generated sitemaps tied to publish state, consent logic that never gates content, and caching in front of your render path. DerivateX re-runs this check monthly on retainer sites, because deploys reintroduce it.

---

Which bot assumptions are actually documented?

Fewer than the internet claims. DerivateX writes assumptions down in two columns, documented and observed, and never lets an observed behavior become a design decision. OpenAI maintains a publishers and developers reference covering its crawlers and how publishers can control them, which you can read in the OpenAI publishers and developers FAQ. Google’s rendering behavior is documented in its own developer guidance. Beyond that, most confident statements about which AI crawler executes JavaScript are inference from someone’s log sample, on some date, for some site.

That matters because inference expires. A vendor can add rendering, remove it, change timeouts or route requests through a different index in a release you will never read about. Most software companies inherit these constraints from a stack choice made years before AI crawlers existed, so the rule DerivateX applies for software firms is simple: design for the documented floor, which is the first HTTP response, and treat any rendering that happens above that as a bonus. If your commercial content survives with JavaScript switched off, you are correct under every possible vendor behavior. If it does not, you are correct only while a particular pipeline keeps behaving the way it behaved last quarter.

The second discipline is naming the agents you care about rather than talking about “AI crawlers” as one thing. Search-oriented fetchers, training crawlers and user-triggered browse agents have different jobs, and blocking or allowing them are separate business decisions. The DerivateX LLM SEO checklist for B2B SaaS covers the allow and block decision in more depth than this page should.

---

What should engineering check first, and what will it cost?

DerivateX sequences this by commercial exposure, not by technical elegance. Access blocks come first, because a 403 makes everything else moot, then raw HTML on the five highest-intent templates, then discovery, then metadata, then the long tail of soft failures. Here is the order we hand to engineering teams, with the evidence that closes each ticket.

Order	Check	Test	Evidence that closes the ticket	Typical effort
Step 1	Crawler access at the edge	External fetch per bot user agent	200 status for every allowed agent, logged	A few hours
Step 2	Raw HTML on pricing, product, integrations, comparison, security	curl plus grep for commercial strings	Every claim present in the first response	Days to weeks
Step 3	Crawlable links and addressable routes	Anchor count in raw HTML, direct fetch of deep URLs	Real hrefs, 200 on cold direct fetch	Several days
Step 4	Canonical, title, description per route	grep the raw head, compare to rendered head	Identical values in both	Several days
Step 5	Interaction and scroll-gated content	No-click, no-scroll DOM capture	Full text present before any event	Several days
Step 6	Sitemaps, consent, geo, TTFB	Sitemap sample, cookieless multi-region fetch	Clean sample, content served cold	Ongoing each month

The cost objection usually arrives at step two, because server-side rendering means running a server. For a marketing site with a handful of server-rendered templates, hosting is a rounding error against a single lost enterprise deal. Engineering time is the real cost, which is exactly why the priority order above exists.

---

How do you verify the fix in logs or rendered HTML?

Two artifacts count as proof, and a screenshot of a browser is not one of them. DerivateX accepts a fix as verified only when both exist. The first is a stored raw HTTP response, captured with the bot user agent from outside your network, containing the commercial text. Save the file, note the date, attach it to the ticket. The second is server log evidence that the crawler came back, requested the URL, and received a 200 with a body size consistent with the fixed template.

Log file analysis is the part most SaaS teams skip, and it answers the question nobody else can answer: did the fix change behavior, or did it just change the page. Pull raw access logs, not a sampled analytics view, and group by user agent, path, status code and response size. What you want to see in the four weeks after a fix is a rising count of successful fetches on the templates you repaired, fewer non-200 responses for the agents you allowed, and response sizes that match server-rendered output rather than the old shell. If the crawler never returns, the block was never the only problem, and discovery is your next ticket.

DerivateX runs this loop on a fixed cadence rather than as a one-time audit, because deploys undo fixes. A component library upgrade moves content back behind hydration. A security review adds a bot rule. Verito is the clearest example in our own work of technical and retrieval work compounding: Verito moved from an average position of 40 on Google to first page, and is cited and recommended on ChatGPT and Google AI Overviews for 40 of their commercial hosting queries. That came from a repeated cycle, not one fix. The full method sits in the DerivateX technical SEO service for SaaS.

---

How does DerivateX turn a rendering fix into citations?

A rendering fix makes you readable, and it does not make you recommended. Those are two different pieces of work, and conflating them is why so many technical audits end in a PDF and no change in pipeline.

Citation Engineering is the methodology DerivateX uses to make language models recommend a brand deliberately rather than accidentally, and readability is its precondition, not its content. The Citation Surface Map is the inventory DerivateX builds of every URL, third-party page and community thread that currently supplies evidence about a brand to an answer engine, which is how we decide whether the gap is technical, on-page or off-site. When a client’s pricing page returns a shell to an AI crawler, the map shows a hole where their own evidence should be, and competitor pages filling it. The DerivateX B2B SaaS AI search visibility guide sets out how that inventory feeds the wider program.

The order matters because AI answers are winner-take-few. Roughly 3 to 4 brands get recommended per AI category query, and 46.7% of Perplexity’s top sources come from Reddit, which tells you that corroboration off your own domain carries real weight. Fixing rendering gets your own claims into the pool. Corroboration decides whether they get chosen. Gumlet is our strongest revenue proof of the combined effect: more than 20% of monthly inbound revenue attributed to AI discovery. REsimpli became the most cited and recommended real estate CRM for investors in ChatGPT within 90 days. Neither result came from JavaScript work alone, and we do not present targets as guarantees.

Engagements start at $6,000 to $6,200 all in per month for Rank and Get Found, listed on the DerivateX pricing page, which is a $5,000 retainer plus $1,000 to $1,200 of off-site budget, on a 90-day pilot with no lock-in afterwards. Own Your Category runs $9,500 to $10,000 all in, and Market Leader runs $14,000 to $15,000 all in on a six-month minimum. The same page lists a $3,500 one-time diagnostic delivered in two weeks, which credits in full against month one if you convert within 30 days. All four figures are the published DerivateX rates at the time of writing in 2026.

---

When you should not hire anyone for this

There are three situations where paying DerivateX for this specific work is the wrong call, and saying so is more useful than pretending otherwise.

If your site is already server-rendered and your raw HTML contains your commercial content, you do not have a JavaScript SEO for AI search problem. Run the three-fetch diagnostic, confirm it passes, and spend the money on content and corroboration instead. If you need a one-time technical diagnosis and you have engineers who can read a curl response, do it yourself this week with the Google documentation and the tests in this article, at no cost beyond an afternoon. If you would rather hand it over, a specialist technical SEO contractor for a few days, or an established agency such as SimpleTiger, which positions itself as a SaaS-focused SEO firm and does solid technical and keyword work for software companies, will handle a one-off rendering fix well and for a fraction of a $6,000 per month retainer. That is a better buy than DerivateX when the job really is one deploy long.

If you are below $5M ARR, our floor of $6,000 all in per month is likely the wrong allocation of a small budget, and a fractional technical hire will serve you better. DerivateX works with B2B SaaS companies at $5M to $50M ARR because that is where a category position is still winnable and where a rendering fix can be traced to pipeline. Where a retainer does earn its keep is the repeated case: multiple front-end teams shipping weekly, a large template surface, and a category where 3 to 4 competitors are already being named in AI answers. If your problem is measurement rather than access, note that 64% of marketing leaders are unsure how to measure AI search, and the DerivateX comparison of AI search tracking tools for B2B SaaS is a better starting point than any technical engagement.

---

Frequently asked questions

How do I test if AI crawlers can see my JavaScript site?

Fetch the URL with curl using an AI crawler user agent, save the raw response, and search it for your prices and product claims. Then compare that file to the rendered DOM in Chrome DevTools. If the claims exist only in the rendered version, AI retrieval may never see them. DerivateX runs this on five templates per site.

Do I need server-side rendering for ChatGPT to cite my pages?

You need your commercial content in the first HTTP response, and server-side rendering is the most reliable way to get it there. Static generation and prerendering for all user agents also work. What fails is depending on client-side hydration, because 80% of URLs cited by ChatGPT and Perplexity are not in Google’s top 100, so Google’s rendering is not a proxy.

Why does Google index my page but ChatGPT never mentions it?

Google runs a documented rendering step for JavaScript, and AI answers are assembled from several retrieval paths with different budgets and different JavaScript support. A page can pass Google’s pipeline and still return an empty shell to a direct crawler fetch. Test raw HTML, rendered DOM and a bot-agent fetch separately before assuming the content is the problem.

Should I block GPTBot and other AI crawlers?

Only if you are certain you do not want your content in AI answers, because 200M or more weekly ChatGPT Search users and 4.4x higher conversion from AI-sourced visitors are the trade. Check whether a block already exists that you did not choose: many WAF rules and WordPress security plugins ship AI crawler blocking as a default or paid feature.

How do I prove to my CMO that a rendering fix worked?

Show two artifacts, a stored raw HTTP response with the bot user agent containing the commercial text, and server log evidence that the crawler returned and received a 200 with a full-size body. Then track citation frequency on your target prompts over the following 60 to 90 days, alongside demo requests from AI referrers.

---

The mental model to keep

Treat your website as four different documents, not one. There is the document a human sees, the document Googlebot renders, the document that exists in the first HTTP response, and the document your edge decides to serve a given user agent. They are allowed to disagree, they frequently do, and the only one DerivateX will count on across every AI retrieval path is the third. The working question for any commercial page stops being “does this look right” and becomes “is this claim a string in the raw response, and can I prove a crawler received it.” The downside is silent: there is no error message when a language model reads your pricing page, finds a skeleton loader, and recommends someone else. With 73% of B2B sites losing significant traffic between 2024 and 2025 and 40% of Google queries now showing AI Overviews, the pages that hold your commercial argument are the ones that cannot afford to be unreadable.

DerivateX runs a free AI visibility audit with a 48-hour turnaround, and it comes back with which of your commercial pages return content to AI crawlers, which return a shell, and where competitors are being cited instead. Request the free AI visibility audit.