JavaScript and AI Search: What Crawlers Can Read

A page can look complete in your browser while important information is missing from its initial HTML. Comparing those two states helps establish what a crawler can access.

JavaScript may load a service description, populate a location finder or replace a phone number. Some content arrives automatically; other content appears only after a click, scroll or consent choice.

Google can render JavaScript, while other crawlers and agents have different capabilities and resource limits. The useful diagnostic is to identify which business facts depend on those steps, then check whether the intended system can reach them.

This guide compares the server response, rendered page and interactive state, with special attention to contact details, structured data and third-party widgets.

The three versions of a modern web page

For practical auditing, it helps to stop thinking of a page as one thing. There can be at least three meaningful states.

1. The server response

This is the HTML returned when the URL is requested. On a traditional server-rendered site, most important content may already be here.

On a heavily client-rendered application, the response may contain little more than:

• navigation,
• script references,
• a root element,
• and optimism.

2. The rendered DOM

The browser executes JavaScript. Additional content appears. Links may be added. Components populate. API responses become visible. The final document can look dramatically different from the original response.

3. The interactive state

Some content does not appear merely because JavaScript ran.

It appears after:

• a click,
• a scroll,
• a tab selection,
• a form submission,
• a location choice,
• a consent event,
• or another user interaction.

That third state is where many implementations become unexpectedly fragile for machine access. Google, for example, explicitly says its Search crawler does not interact with pages by clicking or scrolling simply to trigger lazy-loaded content.

So when essential information sits behind an interaction, the problem is not “JavaScript SEO.” The problem is the sequence of dependencies required to access the content.

Why Google is not a universal model for every crawler

Google is unusually capable and unusually well documented. Google Search describes its JavaScript pipeline as crawling, rendering, and indexing. Googlebot can use an evergreen Chromium rendering environment. That is good news for JavaScript-heavy websites.

It is not permission to assume every automated system on the web works the same way. Google’s own documentation gives us the more sensible principle: server-side rendering or pre-rendering can still be useful because not every bot can run JavaScript.

That should immediately change how we treat critical website information.

If the information is important enough that a search engine, AI retrieval system, business directory parser, accessibility tool, or crawler needs it to understand the page, there is often little benefit in making it unnecessarily dependent on client-side execution.

JavaScript should enhance the experience. It should not be the only witness to the identity of your business.

Check older scripts and integrations

AI search did not invent these problems. It just gives us another reason to care about them. Years of marketing technology have produced wonderfully creative implementations. Phone numbers injected through tracking scripts.

Reviews loaded from third-party widgets. FAQs built entirely inside page-builder components. Location data requested from an API after page load. Navigation links created only after JavaScript initializes. Schema injected through Tag Manager.

Content hidden in tab systems that do not exist until the component loads. Service details embedded in interactive maps. Lead-generation tools replacing original page elements. Many of these systems were built for perfectly reasonable business reasons.

Attribution. Personalization. Performance. Marketing automation. Ease of editing. The problem appears when the implementation quietly becomes the only place a critical fact exists.

Call tracking is a perfect example

Dynamic Number Insertion is useful. It allows marketers to show different tracking numbers based on source while preserving attribution. The problem is not using DNI. The problem would be designing the website so poorly that the canonical phone identity of the business exists nowhere reliable outside the JavaScript replacement process.

A robust implementation can have both:

• the correct semantic business information,
• and dynamic visitor-facing attribution.

Those ideas are not enemies.

For local businesses in particular, this matters because phone numbers can appear across:

• visible website content,
• structured data,
• Google Business Profile,
• Bing Places,
• directory listings,
• location pages,
• and tracking systems.

We want the ecosystem to understand that these numbers relate to the same business and purpose. Not discover six disconnected phone numbers and begin a small existential crisis.

GTM-injected content deserves special suspicion

Google Tag Manager is extremely useful. It is also frequently asked to perform jobs it was never meant to become responsible for.

Marketing teams sometimes use GTM to inject:

• text,
• links,
• schema,
• tracking numbers,
• banners,
• or even larger page elements.

Why?

Because GTM access is sometimes easier to obtain than developer access. Anyone who has worked in agency land knows this story.

“We cannot get the developer to make the update until next sprint.”

“Can we just do it in GTM?”

Sometimes, yes.

Should permanent, important page content live there forever?

That deserves a much harder look.

GTM adds another dependency:

• the page loads,
• the tag container loads,
• the correct trigger fires,
• the script executes,
• the intended element is found,
• then the content appears.

That is more fragile than the server simply returning the information. For analytics, that dependency may be perfectly normal.

For the only link to your most important service page?

Maybe not.

Lazy loading: good idea, easy to get wrong

Lazy loading is normally a performance improvement.

Why load everything before the user needs it?

The problem is implementations that only fetch important content after a human action. Google’s guidance is very practical here. Relevant lazy-loaded content should load when it becomes visible without depending on user actions such as clicking or scrolling.

This distinction matters. An image loading as it approaches the viewport is normal. A block of core service content that literally does not exist until somebody clicks “Learn More” is different.

Ask:

• Is the hidden content already present in the DOM and merely collapsed?
• Or is it fetched only after the click?

Those are not the same architecture.

Accordions are not automatically a problem

This deserves a myth-buster of its own because SEO advice around accordions has historically been strange. A collapsed accordion can still contain perfectly accessible content. If the content exists in the HTML or rendered DOM and CSS merely controls visibility, machines may have no problem accessing it.

The more concerning implementation is:

• the user clicks the accordion,
• then JavaScript sends a request,
• then the server returns the content,
• then the browser inserts it.

Same visual design. Very different machine dependency. This is why screenshots are not enough for technical auditing. Two pages can look identical and expose completely different information to non-interactive crawlers.

Third-party widgets are their own little websites

Review carousels, scheduling tools and embedded maps can improve the customer experience. Their information may come from another domain, live inside an iframe or load only after an interaction.

Keep essential business facts available on your own pages as well. Publish office hours beside the scheduling tool, a readable address beside the map and useful reputation evidence alongside the review widget.

Check what the server returns and what appears after rendering. That comparison shows whether your important facts depend entirely on a third-party service.

Structured data injected with JavaScript

Google can process JavaScript-generated JSON-LD. Choose the implementation that delivers accurate data reliably and is straightforward for your team to maintain.

If the content-management system can output the markup directly, that may avoid an extra dependency. Google Tag Manager can be a useful temporary deployment route, but record who owns the tags and how they will be reviewed.

Compare the structured values with the visible page. Correct conflicting names, contact details or service information at the source, then verify the rendered markup.

Links are especially important

Google can discover links inserted into the DOM through JavaScript when they are implemented as crawlable links. But internal-link architecture should not depend unnecessarily on brittle scripts.

A strong crawlable link generally means:

• an anchor element,
• a usable href,
• a destination that resolves,
• descriptive anchor context,
• and no requirement that a user execute a custom interaction just to expose it.

If a major section of your website is connected only through clickable divs with JavaScript event handlers, you have designed navigation for a browser user and hoped everything else figures it out.

Use standard links with usable destinations for important navigation.

The accessibility tree is becoming more interesting too

Browser agents complicate the picture further.

A browser agent may inspect:

• the rendered DOM,
• visual screenshots,
• accessible names,
• roles,
• and other page semantics.

Google’s current generative AI guidance explicitly discusses browser agents that may analyze screenshots, inspect DOM structure, and interpret the accessibility tree. This creates a pleasant convergence.

Websites that are:

• semantically clear,
• accessible,
• properly labeled,
• and structurally coherent

are also easier for increasingly capable software agents to operate. Clear labels and semantic structure help people use the interface and can also help browser agents interpret it.

What content should be in the initial HTML?

Prioritize the facts a reader or machine needs to understand the page. Interactive features can use JavaScript while those core facts remain reliably accessible.

For a service business, that can include:

• primary service description,
• business identity,
• location identity,
• important contact information,
• core page headings,
• primary navigation,
• important internal links,
• critical qualifications,
• pricing where publicly offered,
• main product or service facts,
• and other information central to the page’s purpose.

Interactive enhancements can remain interactive. The key is graceful degradation of meaning. If JavaScript fails, the website does not need to remain beautiful. It should remain understandable.

What about single-page applications?

SPAs can absolutely be searchable. The issue is implementation quality.

Questions include:

• Does every meaningful state have a stable URL?
• Does direct navigation to that URL return a usable page?
• Are status codes meaningful?
• Are titles and canonical tags correct?
• Does rendering reliably produce the content?
• Are links crawlable?
• Does the site accidentally return 200 for nonexistent routes?
• Is important data available without authentication?
• Can pages be shared independently?

If those answers are good, the architecture can work.

If the answer to everything is:

“React handles it”

that is not an architecture document.

Check content quality alongside server-side rendering

We should avoid replacing one simplistic rule with another. Server-rendering content does not automatically make the page good.

You can server-render:

• duplicate content,
• incorrect facts,
• broken canonicals,
• terrible internal linking,
• thin pages,
• and nonsense.

Accessible content still needs accurate, useful information. Rendering solves an access problem. It does not solve retrieval relevance, evidence, entity clarity, or content quality. That is why our model has multiple stages.

How this ties into AI search

Why does all of this matter now?

Because AI search broadens the number of machine consumers we care about. Traditional SEO already taught us to think about Google and Bing.

Now add:

• AI-specific search crawlers,
• retrieval systems,
• training crawlers,
• browser agents,
• and new protocols that may expose structured information to software acting for users.

The safest long-term technical strategy is not to predict every crawler’s JavaScript implementation. It is to reduce unnecessary fragility.

Make important information:

• accessible,
• owned,
• stable,
• clear,
• linked,
• current,
• and consistent.

That principle survives technology changes remarkably well.

A practical JavaScript audit

For each important template, compare:

That is already a much more useful audit than:

“Site uses JavaScript: warning.”

Favor reliable, maintainable delivery

There is a recurring theme in technical SEO. Boring implementations are annoyingly resilient. A real heading. A real paragraph. A real link. A real URL. A correct status code. A stable canonical.

A server response containing the core information. These things are not impressive at conferences. They also keep working. Use JavaScript for what JavaScript is good at. Interactivity. Personalization. Applications. Dynamic functionality.

Do not use it to make basic facts unnecessarily difficult to retrieve just because the marketing stack slowly evolved into that shape. AI search gives us a useful excuse to clean some of that up.