Your content is invisible to AI if it needs JavaScript: how to test and fix

Your content is invisible to AI when it only appears after JavaScript runs, because as of mid-2026 the major AI crawlers — GPTBot, OAI-SearchBot, PerplexityBot and ClaudeBot — fetch your raw HTML and never execute a line of your scripts. The ten-second test settles it: open your page's view-source (Ctrl+U), search for a sentence you know is in your article, and if the words aren't in that source, there's nothing an assistant can read or quote.

We build Contexta, our WordPress plugin, and the misread we run into most is owners assuming this is a "React problem" that never touches a normal WordPress site. A classic server-rendered theme isn't a single-page app, yet it still goes dark in the precise spots WooCommerce and page builders reach for JavaScript: the AJAX "load more" on a shop page, a client-hydrated FAQ block, reviews that fetch after the page paints, a variation price the script writes in. That partial, selective invisibility is worse than a total blackout, because it slips past a casual look at your live page.

Why can't AI assistants see JavaScript-rendered content?

AI assistants can't see JavaScript-rendered content because their crawlers make a plain HTTP request, read the HTML that comes back, and stop — they don't run scripts, wait for hydration, or fetch anything a script would have loaded afterward. A widely-cited Vercel analysis of over 500 million GPTBot fetches found no JavaScript execution at all; GPTBot downloads JavaScript files roughly 11.5% of the time but never runs them. So whatever your scripts build after that first response — text, prices, reviews — simply isn't on the page the crawler reads.

This is the one place Google and AI genuinely diverge, which is what makes it a trap. Googlebot renders JavaScript through its Web Rendering Service, so a client-rendered page can rank in Google — and even surface in AI Overviews, which ride Google's index — while being a blank shell to ChatGPT, Perplexity and Claude. It's the third rung on the wider ladder of why AI assistants never cite your blog: reachable, index-eligible, and readable-without-JavaScript all have to be true before a single well-written sentence can earn a citation.

I'm on WordPress, not a single-page app — does this still affect me?

Yes — a server-rendered WordPress site still loses content to JavaScript in specific, selective spots, even though your post body sits in the HTML. The whole-page-is-a-SPA framing you'll read elsewhere is the rare case; the common case is a normal theme where one important block is client-side, and that block happens to be the part an AI shopping agent or answer engine most needs.

The usual offenders on WordPress and WooCommerce are predictable once you know to look:

• AJAX "load more" and infinite scroll on shop and archive pages — the crawler gets the first batch of products and never the rest, because it doesn't press the button that fetches page two.
• Variable-product prices and variation data written into the page by the variation script after selection, so the raw HTML shows a price range or nothing where a single number should be.
• Reviews and star ratings fetched by AJAX after paint, which leaves your social proof out of the crawler's copy entirely.
• Client-hydrated FAQ, tab and accordion blocks from a page builder that inject their text on load rather than printing it server-side.
• Opening hours, booking widgets and click-to-call blocks on service-business themes, where the facts a local recommendation actually depends on are drawn by a script instead of printed as text.

Each of these is a place where the fact an assistant would quote — a spec, a price, a rating — lives only in the rendered page a human sees. The variation-price case matters most for stores, because that number is exactly what an AI shopping agent reads from your product data to decide whether to surface you at all.

How do you test whether your content needs JavaScript?

Compare what's in your raw HTML against what's in the rendered page — the difference is precisely what an AI crawler can't see. The definitive, no-tools version: open the page, press Ctrl+U to view source (the raw HTML, before any script runs), then Ctrl+F for a sentence you know is in your article. If it's there, crawlers can read it; if it isn't, a script is injecting it and the crawler never gets it.

Two cautions make the test reliable. First, use view-source, not "Inspect element" — the inspector shows the rendered DOM after JavaScript has already run, so your content looks present even when the crawler never sees it, while view-source shows the actual response. Second, test as the bot: run curl -s -A "OAI-SearchBot" https://yoursite.com/your-post and search the output, because a few sites serve different HTML to unfamiliar user-agents, and the crawlers that matter are the named ones — OAI-SearchBot, PerplexityBot and Claude's fetcher — not a generic browser string. Knowing which AI crawlers to allow and test by name keeps you from checking the wrong one.

Is CSS-hidden content also invisible to AI crawlers?

No — content hidden with CSS is fully readable by AI crawlers, because it's present in the raw HTML and merely styled out of view. A FAQ answer inside a display:none accordion, a spec table in a collapsed tab, "read more" body text clipped by CSS — all of it is in the response the crawler reads, and it gets extracted normally. What's invisible is the narrower case where the text doesn't exist in the HTML at all until a script writes it in.

This is the distinction people get backwards, and it changes what you fix. The two states look identical to a shopper — both are "hidden behind a click" — so owners either panic over safe CSS-collapsed content or wave off genuinely absent content because "it's right there on the page." The reliable way to tell them apart is to load the page with JavaScript switched off: CSS-hidden text is still in the source, just not shown, while JavaScript-injected text disappears completely. That JavaScript-off render is exactly what Contexta's AI Visibility test runs for every page at once — it shows the shell a crawler receives and flags which text survives without scripts, so you're not opening view-source on one template at a time. Run the check before you rebuild anything — most of what looks broken is fine, and the real gap is usually smaller and more specific than it first appears.

How do you fix JavaScript-dependent content without rebuilding your site?

Move the specific facts an assistant needs from the JavaScript layer into the initial HTML — you rarely have to rebuild the site, just the few blocks that go dark. The stock advice is "switch to server-side rendering," which is the right answer for a true SPA and the wrong scale of fix for a WordPress site where most of the page is already in the HTML and four blocks aren't.

The concrete moves map to the offenders: replace AJAX "load more" with real paginated links a crawler can follow — an anchor to page two, not a click handler — because crawlers follow links, not buttons; server-render or pre-render the theme blocks that currently hydrate on load; and for WooCommerce, make sure a base price and the key specs sit in the server HTML and the Product JSON-LD even if the interactive variation selector stays JavaScript-driven — and in that order, because schema confirms facts rather than delivering them, so a value that exists only in the markup is lost to any extractor that strips script tags. This is also the moment to rule out the other two invisibilities on the same page, since fixing the JavaScript is wasted if the crawler is blocked by Cloudflare or robots.txt before it reads a word.