A page can look complete in a browser while its initial HTML contains little of the main content. Compare the two before treating the page as ready for search or AI retrieval.

Content in HTML: a baseline for AI discovery

Content in HTML can be incomplete even when a page looks finished in your browser. This matters for teams publishing articles, service pages or product information through sites that load the main text with JavaScript. Serving essential content in the initial HTML reduces dependence on rendering, but does not guarantee indexing, retrieval or AI citations.

The useful question is not “does this site use JavaScript?” It is “which facts can a crawler read from the document it receives, and which appear only after additional processing?”

What content in HTML actually means

The initial HTML is the document returned by the server before the browser executes page scripts. The rendered page is the result after scripts have changed the document, fetched data and inserted content.

A client-rendered page might initially contain this:

<body>
  <div id="root"></div>
  <script src="/assets/app.js"></script>
</body>

Your browser can turn that shell into a complete article. A fetch that does not execute the script receives an empty container instead of the article's heading, explanation and links.

The alternative is to return the main content in the document itself:

<main>
  <article>
    <h1>How to choose an audio interface</h1>
    <p>Choose the inputs and outputs your recording setup needs.</p>
    <h2>Check the connections</h2>
    <p>Match microphone, instrument and monitor connections to your equipment.</p>
  </article>
</main>

JavaScript can still add interactive controls afterwards. Publishing readable initial HTML does not mean removing interactivity or redesigning the site.

Google rendering is documented; AI rendering varies

Google's JavaScript SEO documentation describes crawling, rendering and indexing as separate stages. Google can execute JavaScript. That is different from a promise that every script, API request or interaction will complete successfully.

Google's guidance for AI features applies established SEO practices to AI Overviews and AI Mode. A page must meet the relevant indexing and snippet eligibility requirements; there is no additional special AI schema or machine-readable file required. Eligibility is not a promise of inclusion.

For other providers, be careful about what the documentation establishes:

The relevant references are the official OpenAI bot documentation, Anthropic crawler guidance and Perplexity crawler documentation.

These documents do not justify the headline “generative engines cannot see JavaScript content.” The defensible advice is narrower: do not make essential public facts depend on a rendering capability you have not verified.

Access, extraction and selection are different problems

Initial HTML addresses only part of discoverability. Keep these questions separate:

1. Access: can the intended crawler reach the URL, or is it blocked by robots rules, authentication or a firewall challenge?
2. Extraction: does the returned document contain the relevant facts, headings and links, or does retrieving them require further execution?
3. Selection: will the search or answer system choose this page for a particular result?

Fixing extraction does not remove access restrictions. Allowing a training bot does not automatically enable search retrieval: providers document different bot roles and controls. Neither access nor extraction proves selection.

Structured data can describe entities and relationships, but it should not become a substitute article hidden inside JSON-LD. Start with accessible, accurate page content, then use appropriate markup to describe it. The broader principle is covered in making your website a source for AI chatbots.

How to check this

Choose a representative public URL from each important page template. Include a page with substantive content, not just a homepage or login form.

Compare the response with the browser

Open the page's source, or fetch its HTML without running JavaScript:

curl -L https://example.com/articles/audio-interface

Look for the actual H1, opening explanation, product attributes or answer paragraphs. A matching phrase inside a script's data payload is not the same as readable page text in the document body.

Next, compare that response with the browser's rendered document. If the main content appears only in the latter, identify which script or request supplies it. For Google specifically, inspect the rendered HTML with URL Inspection in Google Search Console. That checks Google's rendering, not every AI provider's retrieval behaviour.

Use the ratio as a lead, not a verdict

In Be Seen Digitally, open Pages, select the URL and review its AEO / GEO section. The HTML-content comparison uses text extracted from the served HTML against the crawl's extracted Markdown word count. It is an approximate comparison, not a sentence-by-sentence match or an observation of a named AI bot.

The content_not_in_html rule flags eligible pages when the extracted content exceeds 50 words and the HTML-content ratio is below 50%. Those are the tool's diagnostic thresholds, not published search-engine requirements.

A low ratio deserves investigation. A high ratio is not conclusive either: navigation and repeated footer text can increase the initial word count while the main answer is still absent. Confirm the actual content before assigning work. The Content not in HTML Fix guide provides the related implementation steps; interpret the finding as an extraction risk, not confirmed AI exclusion.

What to do about it

1. Confirm the page's purpose. Prioritise public content, service and product pages intended for discovery. Do not turn a private account screen into an article to satisfy a content check. Legal pages also need separate treatment from dynamic utilities.
2. Find the missing content. Record which heading, paragraph, specification or internal link is absent from the initial response. Do not assign a generic “improve GEO” task.
3. Check the shared implementation. If several affected pages use the same template, investigate it first. Repeated findings suggest a shared check is worthwhile; they do not prove that every page has one common cause.
4. Choose a rendering approach. Server-side rendering produces HTML for a request; static generation or pre-rendering produces it ahead of time. Choose according to how often the content changes. Keep pre-rendered output current when the source changes.
5. Preserve the facts across both versions. The initial and rendered pages should agree on the main content, canonical URL and relevant metadata. Do not serve a separate, inflated version to crawlers.
6. Verify after deployment. Fetch the response again, inspect a normal browser session and re-crawl the affected URLs. Confirm the named content is present and that interactive behaviour still works.

When a developer or AI coding agent will implement the change, export an Audit & Action Plan from Reports. Give the recipient the affected URLs, the missing facts and an acceptance condition: those facts must appear in the served HTML without script execution. Keep later progress evaluation separate from that execution package.

Closing

The first check is concrete: does the document contain the facts the page is meant to publish? Put essential public content where it can be read, verify the response after changes, and keep technical availability separate from claims about indexing or AI citations.