Can AI Search Read JavaScript Websites? What the Evidence Shows

Can AI search read a JavaScript website?

There is no single answer for every AI product. Google documents JavaScript rendering. Current OpenAI, Anthropic and Perplexity crawler guides explain access and bot purposes, but the pages reviewed here do not promise a particular JavaScript rendering capability. Treat a successful test in one system as evidence about that system, not all of them. 2 3 4 5

Our recommendation is to make your essential business information readable in the first HTML response, then test the rest of the experience. That means the words explaining what you sell, who you serve and how someone can buy. A homepage that looks complete in your browser deserves a closer look if its underlying response contains little more than a loading screen.

This is a research review and an original diagnostic framework. We did not run a new crawler experiment or measure a ranking improvement. The useful question is more specific than whether your site is “AI ready”: which reader can reach which information, and what evidence do you have?

What the evidence actually says

Vercel and MERJ published their analysis on December 17, 2024, drawing on Vercel network traffic, nextjs.org and two job boards. They reported 569 million monthly GPTBot fetches and 24.4 million PerplexityBot fetches. Those are requests, not people, referrals or citations; the report described recent months and a preceding-month count without exact collection dates. 1

The distinction matters for spending decisions. A large crawl count can establish that a network saw considerable automated activity. It cannot tell a small company how many prospective buyers saw its name. And an older observation should not be presented as a current test of every AI browser or assistant.

Know which bot you are making a decision about

These names and purposes come from the providers' own guides. OpenAI describes independent search and training controls; ChatGPT-User is not its Search opt-out control. Anthropic says its bots respect robots.txt. OpenAI and Perplexity publish IP information for verification, and Perplexity explains firewall configuration. 3 4 5

Before asking a developer to “allow AI,” decide what that means for your business. You might want public pages accessible for search while choosing a different policy for training. Put that decision in writing. Avoid asking someone to change a broad firewall rule when the actual requirement concerns one named service.

A practical five-page check

The following workflow is our recommended way to investigate a small business website. It is not a validated scoring system, and five pages are a starting sample, not a complete audit. Choose pages that represent different templates: the homepage, a core service or product page, a pricing or contact page, an article and one page you particularly want buyers to find.

1. Write down what each page must communicate

For a service page, that could be the service name, customer type, location served, important exclusions and a way to enquire. For an article, it could be the question, direct answer, explanation and supporting sources. Keep the list short enough that someone can check it without reading a strategy document.

Do this before inspecting code. Otherwise, it is easy to celebrate finding a title and overlook that the actual offer is missing. The page's job should define the check, rather than whichever details happen to be easiest to extract.

2. Compare the initial response with the visible page

Ask your developer for the HTML returned by a normal, signed-out request to each public URL. Compare it with what the browser shows after loading. Look for the essential text as actual page content, not merely words buried in a script or configuration object.

Record “present,” “missing” or “uncertain” for each item. A marketer does not need to diagnose the entire application. An uncertain result is a useful handoff: attach the URL and the exact sentence you could see on screen but could not locate in the response.

If important content is missing, ask whether the site's server or static build can deliver it directly. Google recommends server-side or pre-rendering partly because not all bots execute JavaScript. 2 You do not need to remove interactive features simply to make the main explanation available.

3. Check Google's view separately

Search Console's URL Inspection distinguishes information about Google's indexed version from a live test. Passing the live test does not guarantee indexing. 6 Google's troubleshooting guide also shows how to inspect rendered content, loaded resources and JavaScript errors. 7

Save the date and identify which test you used. “It works in Search Console” is too vague for a developer to reproduce. Note whether the offer text appeared, which important resources failed and whether the result concerns the current page or a previously indexed version.

4. Investigate access without weakening security

Have the person responsible for your hosting check the intended bot rules and any relevant blocked-request logs. Our recommendation: a user-agent string alone should not be your basis for granting special access. Where a provider publishes verification information, use it. 3 4

Make the smallest change that addresses a confirmed block. Keep unrelated protections in place. Test only sites you own or manage, and do not turn this into an attempt to bypass another website's restrictions. If there is no verified request to investigate, label the result unknown instead of inventing a firewall problem.

5. Recheck the same page and save the difference

Use the same URL and content checklist after the change. Record what changed in the response, what changed in the rendered page and what still needs investigation. Check the normal customer experience too: navigation, enquiries, checkout or booking should still work.

This is the point at which a technical repair can be called verified. Search performance is a separate follow-up. Keep the repair date so later traffic comparisons have context, but do not attribute every change in impressions or enquiries to the repair.

Turn observations into useful work tickets

The last two rows are deliberately different from fixing delivery. An accessible page may still be unhelpful, irrelevant to the question or uncompetitive. A technical test cannot decide those questions on its own.

We would prioritize an unreadable core service page ahead of a cosmetic change to a low-value archive page. Among comparable delivery problems, group work by template. If several articles share the same missing-content behavior, ask whether one template correction can address the group, then verify multiple examples rather than assuming it did.

A fictional example: the service page that looked finished

Imagine Harbor Lane Plumbing, an invented business used only to explain the workflow. Its owner opens a service page and sees a detailed description, service area and phone number. The developer's initial-response check finds the navigation and a loading placeholder, but not those details. A separate Google live test displays them.

The team has two observations, not a contradiction: the initial response is incomplete for a reader that does not execute scripts, while that Google test renders the page. They choose to deliver the core service text directly and keep the interactive booking widget.

After the change, the developer attaches the before-and-after responses to the work ticket. The owner checks that the service area is accurate and the booking widget still works. They test another service page built from the same template. The technical task is complete when those agreed checks pass.

They do not label the result “ChatGPT rankings fixed.” No such result was measured. Their next marketing task is to decide whether the page answers the buyer's actual questions: which jobs the business handles, how to request a quote and what customers should prepare. Better delivery makes the information available; the information still has to be worth reading.

A handoff sheet your developer can act on

For each problem, keep one row in a shared sheet. Include the public URL, page template, essential text being checked, observed result, test method, date, proposed change, owner and retest outcome. Add screenshots when useful, but retain the exact text and response evidence so the screenshot does not become the whole record.

Use three result labels: confirmed issue, verified repair and needs investigation. Avoid a single percentage that mixes a successful fetch with an unmeasured business outcome. If the test cannot answer a question, leave that question open.

Agree on the scope before work starts. “Make our website readable by AI” is hard to accept or reject. “Deliver these service descriptions in the initial response on these templates, preserve booking, and attach retest evidence” gives both sides something concrete to review.

What to measure after the technical work

Keep technical availability, answer appearances, referral visits and enquiries in separate columns. Record the AI product, question and date for any answer sample. A single missing mention should not trigger a site rebuild, and a single citation should not be treated as proof of a successful campaign.

For business results, use actual attributable sessions or enquiries where your measurement setup supports them. Leave unavailable metrics blank. A bot request is not a lead, and an enquiry that happened after a deployment is not automatically caused by it.

If delivery checks pass and the main gap is useful content, outwrite.ai's article workflow researches topics, writes articles and publishes through a connected CMS. You can try outwrite.ai free for seven days without a credit card. The aim is to answer more of your customers' real questions while keeping the technical and commercial evidence separate.

Limits and when to revisit this review

The evidence combines provider documentation with an older vendor observational report. It does not compare every model, search partnership, crawler version, firewall or browser agent. Documentation can change, and an access policy is not a rendering experiment.

Recheck the relevant provider guidance before changing access rules, and repeat the page checks after a redesign, migration or substantial template change. If you need certainty about a particular product on a particular website, collect evidence for that exact combination. This review gives you a way to ask and test a narrower question; it cannot certify every AI system's view of your site.