JavaScript rendering
JavaScript rendering — where sites go invisible to AI.
The crawlers behind AI assistants fetch your page once, read the raw HTML, and move on. No rendering, no waiting, no second pass. Whatever only appears after JavaScript runs — content, prices, reviews, tags injected client-side — is not in what they read. Here is how to find what is invisible on your site, and the four ways to fix it.
What machines do
One fetch, raw HTML, no browser.
Joint public analyses by Vercel and MERJ, across hundreds of millions of fetches, found no JavaScript execution by any major AI crawler — GPTBot, ClaudeBot and PerplexityBot included. They sometimes download script files; they do not run them. Google is the documented exception: Gemini leans on Googlebot’s rendering infrastructure, with its own queue and timing caveats. The full roster is on the AI crawlers page.
The consequence: a single-page app that looks perfect in a browser can serve a machine reader a near-empty shell — a loading spinner, dressed as a website.
Diagnose
Find your invisible content in one minute.
Fetch a page the way a machine does, then search the response for words you can see on screen. Zero matches means invisible. Browsing with JavaScript disabled shows the same truth — and note that “view source” shows the served HTML while the browser inspector shows the rendered result, which is exactly the gap a machine reader falls into.
# Fetch like a machine reader: no browser, no scripts
curl -s https://yoursite.com/product > served.html
# Search for a sentence you can SEE on the page in a browser
grep -c "Handmade in Sweden" served.html
# 0 -> that sentence is not in the served HTML.
# A reader without a browser cannot see it.Where stacks stand
Your stack decides your default.
| Your stack | What a no-browser reader gets | Risk |
|---|---|---|
| React / Vue / Angular SPA (client-side rendered) | A near-empty shell — the content arrives only after scripts run. | High |
| Next.js / Nuxt / SvelteKit with SSR or SSG | Full content in the response — where pages actually use it. Verify per page. | Low |
| WordPress / Shopify themes | Server-rendered templates; the content is typically in the HTML. | Low |
| Wix / Squarespace / Webflow | Published pages are typically server-rendered — but verify with the check above. | Medium |
| JS-injected fragments: review widgets, live prices, tabs, “load more” | Missing — even on pages that are otherwise readable. | High |
Defaults, not verdicts — a stack is only as readable as the page it serves. Run the one-minute check on your highest-value pages.
The fixes
Four fix paths, with their real costs.
Server-side rendering or static generationRender the content into the HTML at the source — Next.js, Nuxt, SvelteKit, or a static build.Cost: The deepest fix and the most expensive: a build-level change, plus rendering infrastructure to run and keep fast.Prerendering for botsServe a rendered snapshot to crawler user agents while humans get the SPA.Cost: A second pipeline to keep truthful. Snapshots drift from the live page, and the user-agent list never stops changing.Semantic disciplineKeep what is already in the HTML legible: real text instead of text-in-images, real headings, alt text, meaning in the markup.Cost: Editorial work. It sharpens what is served — it cannot recover content that is not in the response at all.A readable copy served beside the pageA clean Markdown version of each page at a direct URL over plain HTTP, plus an llms.txt index. Seogence renders the page in a real browser when it captures it, so the copy contains what your HTML never served — the client-rendered content included.Cost: One tag. Nothing rebuilt, and your served HTML is untouched: the readable version lives beside your site rather than inside it.
With Seogence
The no-rebuild path is the fourth fix.
Add the Seogence tag once and the Knowledge Layer serves the readable copy beside your pages: clean Markdown per page at a direct URL, a per-domain llms.txt index, and a discovery link that points readers at it — over plain HTTP, no JavaScript required to read any of it, on any host. Your site ships unchanged; machine readers get a URL they can actually read.
The part that matters on this page: we capture your page by rendering it in a real browser, so the Markdown carries the content that only exists after your JavaScript runs. The invisible content is not fixed in your HTML — it is recovered into a copy a no-browser reader can fetch.
We are our own worst case, which makes the proof easy to check. This site is a client-rendered single-page app: fetch any page and its <body> comes back with no readable text at all. Its Knowledge Layer entry for the same URL carries the full page.
# Our served HTML: a shell. Strip the tags and the body has no text.
curl -s https://seogence.com/docs/knowledge-layer
# The same page in our Knowledge Layer: the whole document, as Markdown.
curl -sL -H "Accept: text/markdown" \
"https://seogence.com/KnowledgeLayer/seogence-com-4huww9k/by-url?u=https://seogence.com/docs/knowledge-layer"This is check 1’s escape hatch in the AI readability checklist: you do not have to win the served-HTML battle inside your own stack to be readable.
Questions
Common questions.
Do AI crawlers render JavaScript?
No major AI crawler does. Joint public analyses by Vercel and MERJ, across hundreds of millions of fetches, found no JavaScript execution by GPTBot, ClaudeBot or PerplexityBot — they sometimes download script files, but they do not run them. Google is the exception: Gemini leans on Googlebot’s rendering infrastructure.
How do I find what AI cannot see on my page?
Fetch the page without a browser and search the response for your own words: curl the URL and grep for a sentence you can see on screen. Zero matches means that content is invisible to a no-browser reader. Browsing with JavaScript disabled shows the same thing, and the Seogence analyzer runs the check for you.
Do I have to rebuild my site with server-side rendering?
SSR is the at-source fix and the most expensive one — a build-level change plus ongoing infrastructure. A readable copy served beside the page fixes machine visibility without the rebuild: Seogence renders your page in a real browser, then serves what it saw as clean Markdown at a direct URL. Our own site is the proof — its served HTML body is empty, and its Knowledge Layer is not.
Does Google see JavaScript-rendered content?
Googlebot can render JavaScript in a second pass, with documented queue and timing caveats, and Gemini draws on that same infrastructure. Treat Google as the exception, not the rule: the other major AI readers take the raw HTML once and move on.
Try it
See what survives without a browser.
Enter any live page. Seogence fetches it the way a machine reader does and shows the readable copy — so you can see what is actually there when the scripts never run.