On this page
Your website looks complete in Chrome.
The homepage has text, headings, pricing, internal links and product information. When a crawler requests the same URL, the initial HTML may tell a different story.
This is common on websites built with React, Vue, client-side app frameworks and many AI website builders. The browser loads a small HTML shell, downloads JavaScript, then constructs the page. For human visitors that can work perfectly. For AI visibility, the question is: what does the crawler actually receive?
If the brand is missing from ChatGPT, Perplexity, Gemini or other recorded answers, do not automatically assume you need more blog posts. First rule out a technical content-delivery problem.
The JavaScript delivery mechanics are already covered in JavaScript SEO and how to check what bots see. This article is the diagnostic sequence that connects those checks to AI visibility measurement.
We build Prerender Buddy. Details were checked on September 11, 2026 and can change. Fixing an early step in the chain does not force a citation or recommendation later.
AI visibility has an upstream dependency
AI visibility tools measure outcomes such as brand mentions, recommendations, competitors, citations and source mix. Those metrics are useful. Your own website can only contribute as a source if machines can access and understand its public content.
The simplified chain is:
Page exists → crawler reaches it → useful content is delivered → content can be processed or retrieved → source may influence an AI answer
Each arrow is a dependency, not a guarantee. If an early step is broken, another dashboard report will not repair it. GEO and AEO framing of the same point: GEO for JavaScript websites and AEO for JavaScript websites.
Why JavaScript creates uncertainty
A client-rendered application may initially send something closer to:
<!doctype html>
<html>
<head>
<title>My App</title>
</head>
<body>
<div id="root"></div>
<script src="/assets/app.js"></script>
</body>
</html>A browser then runs the script and creates the H1, product descriptions, pricing, FAQs, links and structured data. The visible page and the first HTTP response are therefore not the same document.
Some crawlers execute JavaScript. Some render selectively. Some rely on retrieval systems or indexes with different behavior. Instead of arguing about what every bot might do, inspect your own page. Crawler support lists recognized families; it does not claim every operator renders JavaScript the same way.
Six checks before you blame the content
1. What is in the initial HTML?
Look for a page-specific title, meta description, canonical, H1, main copy, important links, product or category language, and structured data where relevant. If these are already present, you may not have a rendering problem.
2. Compare raw and rendered HTML
A raw-versus-rendered comparison is the fastest way to identify a JavaScript visibility gap. Large differences in readable text, headings, links or metadata are a technical fact you can act on. They do not prove that a particular AI crawler failed to render the page.
Use the raw vs rendered HTML tool or Evidence.
3. Test crawler-style requests
Do not test only with your normal browser. Check HTTP 200 versus 403/404/5xx, redirects, WAF or bot-protection blocks, different content, missing metadata, thin HTML and unexpected login or challenge pages. Start with the Bot View Checker. After setup, verify crawler requests.
4. Review robots.txt and discovery files
Check whether important paths are disallowed, the sitemap is reachable, canonical URLs are correct, noindex directives are accidental, and crawler-specific rules conflict. An optional llms.txt file can provide extra machine-readable guidance. It is not a substitute for an accessible website. Use the robots.txt / llms.txt analyzer.
5. Look at real crawler activity
Testing tells you what a controlled request receives. Logs and visit records tell you what requests happened.
Useful questions: has GPTBot requested the site? Which pages are AI crawlers visiting? Are they receiving 200 responses? Are some paths failing? Are important pages never requested? Is rendered delivery being used?
Peec Agent Analytics and Scrunch Agent Traffic provide this through CDN, hosting or log integrations. Prerender Buddy records recognized crawler activity for connected sites and can show request-level delivery evidence, including cache hits, fresh renders and failed requests. See search and AI visits and AI visibility and crawler monitoring.
6. Keep crawler evidence separate from AI-answer evidence
A crawler visit is not a citation.
If GPTBot requests /pricing, you know a request occurred. You do not know that the page was indexed, entered a retrieval system, was cited by ChatGPT, caused a recommendation, or will affect future answers.
Compare both layers. Crawler access vs AI visibility is the short version of that rule.
Example: a React SaaS is invisible for a category prompt
You sell time-tracking software and monitor "Best time tracking software for small agencies."
Across several collection runs, the company is absent. Competitors are repeatedly mentioned. One review site and two competitor pages are repeatedly cited.
You inspect /agency-time-tracking. Humans see about 1,800 words, screenshots, feature sections, FAQ and customer examples. The raw HTML contains 700 readable characters and no H1. The rendered HTML contains the full page.
Now you have two independent findings:
Visibility finding: the brand is repeatedly absent for an important prompt.
Technical finding: the initial HTML for the relevant page is materially incomplete.
The next step is not to claim that one caused the other. Repair the technical issue because it is real, then continue monitoring the same visibility question.
When prerendering makes sense
Prerendering is useful when important public content depends on client-side JavaScript, rebuilding for SSR is not practical, crawlers receive a thin shell, you want eligible bots to receive a complete HTML snapshot, and human visitors should keep using the existing app.
A managed prerendering service can intercept eligible crawler requests and return rendered HTML while normal users continue receiving the original application. Prerender Buddy is built around that use case, and it can show whether requests received rendered or cached content. Start with does my website need prerendering? and setup. For React and Vue specifically, see React SPA prerendering and Vue SPA prerendering.
Starter is $39/month for three websites and 25,000 fresh renders, with 15 weekly AI prompts. Rendering without AI visibility is also available on the $19 Render plan. Ongoing prompt tracking starts on Starter, Growth or Pro.
When prerendering does not make sense
Do not add rendering infrastructure because a checklist told you to.
You probably do not need prerendering when server HTML already contains the important content, Next.js/Nuxt/SSR/SSG is working correctly, pages are static HTML, the problem is authority rather than access, the content does not answer the tracked questions, competitors dominate because of stronger third-party coverage, or the page is blocked for another reason.
The correct first step is diagnosis. Thin crawler output troubleshooting: thin crawler response.
React, Vue, AI builders and hosting
The same principle applies across stacks. The builder or host name does not tell you what crawlers receive.
React SPA: check whether meaningful route content exists in the first response or only after React mounts.
Vue SPA: inspect server HTML separately from the hydrated browser view.
Lovable / Bolt / Base44 / v0 / Replit-style generated sites: do not assume the builder preview reflects crawler-readable output. Run the same raw-versus-rendered and crawler-access checks. Stack-specific starting points live under the JavaScript SEO topic hub.
Vercel / Netlify deployments: hosting alone does not tell you whether a route is server rendered. A React SPA deployed to Vercel is still a React SPA.
What to monitor after fixing rendering
Avoid looking for instant causality.
Continue tracking crawler response status, raw/rendered content, important page health, recognized AI crawler visits, brand mentions, recommendations, citations and competitor presence. Look for changes over multiple observations.
If visibility improves, that is useful evidence. It still does not prove rendering was the only factor. If visibility does not improve, you have still fixed a real accessibility problem and can move to the next hypothesis.
Paid PB prompt tracking is weekly, which is usually enough for this kind of before/after check. Daily tools collect more observations if you need them. See weekly or daily tracking.
The next hypothesis is usually content, authority or distribution
After technical access is clear, ask:
- Does the page answer the question directly?
- Is the product genuinely relevant to the prompt?
- Are claims specific and verifiable?
- Does the website provide original information?
- Are comparison and category pages useful rather than promotional?
- Do credible third-party sources mention the brand?
- Is the content current?
Technical accessibility is the foundation. It is not the whole strategy. Choose AI visibility prompts and find visibility gaps help with the editorial half.
A practical checklist
Before creating another "AI-optimized" article for a JavaScript website:
- Fetch the raw HTML.
- Render the page and compare.
- Check title, H1, body copy and links.
- Test crawler-style requests.
- Review robots.txt, sitemap and directives.
- Inspect real crawler activity where available.
- Identify the important AI prompts.
- Record mentions, citations and competitors.
- Fix technical gaps separately from editorial gaps.
- Track the same questions after the change.
Frequently asked questions
Can ChatGPT read JavaScript websites?
Different AI-related crawlers and retrieval systems have different capabilities. Do not assume universal JavaScript execution. Check the content your own site returns to crawler-style requests.
Does React hurt AI visibility?
React itself is not the problem. The issue is whether important public content is present and accessible in the responses crawlers receive.
Should every React website use prerendering?
No. If server-side rendering, static generation or another architecture already provides complete HTML, additional prerendering may be unnecessary.
How can I check whether my website has a JavaScript rendering gap?
Compare raw server HTML with the rendered browser document. Large differences in readable content, headings, links or metadata are evidence worth investigating.
Will fixing rendered HTML make ChatGPT recommend my company?
There is no guarantee. It can remove an accessibility problem, but recommendations and citations also depend on relevance, authority, source availability, model behavior and other factors.