DemoBitesModern websites are applications.
They render components dynamically, fetch data from APIs, open tabs and modals, personalize content, and sometimes generate entire views on the client.
Humans with modern browsers handle this naturally.
Machines vary.
Some search and agent systems can render JavaScript. Some use browser automation. Others prefer raw HTML or extracted Markdown. Some stop when a site requires interaction or authentication.
The practical strategy is not to predict every crawler.
It is to make essential knowledge resilient.
The failure mode
Imagine a pricing page where plan details render only after JavaScript runs.
Or an integration page where supported actions appear only after a dropdown selection.
Or a feature page where every substantive fact is fetched only after clicking an accordion.
The information may technically exist.
But retrieval now depends on script execution, timing, network calls, browser capabilities, and UI state.
Every dependency increases fragility.
Progressive disclosure is fine
This does not mean everything must be visible in one giant static page.
Accordions, tabs, demos, and interactive components are useful.
The question is whether important facts remain represented in the rendered document or in a discoverable canonical source.
Test the information, not just the page
Developers often test one thing.
Does the page render?
For agent readiness, also test another.
Can a retrieval system extract the facts we care about?
Pick five critical questions.
- What does this feature do?
- Which plans include it?
- Does it integrate with Salesforce?
- What are its limits?
- When was it updated?
Then inspect how different tools see the page.
Human browser
Full JavaScript, patient rendering, real clicks. Sees everything the UI eventually reveals.
Facts visible
Raw HTML source
No script execution. In a fragile build this holds a shell of markup and empty containers.
Facts missing
Rendered DOM
Facts appear only if scripts, network calls, timing, and UI state all cooperate.
Facts fragile
Extracted text
What a retrieval system keeps after stripping the page down to text or Markdown.
Facts depend on structure
The same page through four lenses. In a fragile implementation, the facts thin out at every step away from the human browser.
If they cannot answer accurately, identify where the facts disappear.
Browser agents change the picture
The rise of agents that drive a real browser means JavaScript is not automatically a blocker.
Agents can increasingly render pages, inspect DOM structure, click, type, navigate, and interact with controls.
Cloudflare's work on agent readiness reflects this broader shift.
But browser capability does not remove the value of clean source information.
A machine that can click twelve times is still less efficient than one that can retrieve the answer directly.
Accessibility helps
Good accessibility often improves machine legibility too.
Useful practices include semantic headings, labels, descriptive links, button names, alt text, logical document order, and meaningful form controls.
An opaque interface with dozens of anonymous divs is harder for assistive technology and browser agents alike.
Give rich experiences a stable knowledge layer
One strong architecture pairs two layers.
An interactive product experience for demonstration and conversion, paired with canonical product knowledge for explanation, retrieval, and citation.
The two can live on the same page.
A demo can show the workflow.
Text can explain what the workflow supports.
Q&A can answer edge cases.
A release page can show when it became available.
Markdown as an optional machine representation
For documentation heavy environments, clean Markdown alternatives are becoming more common.
The llms.txt proposal encourages links to machine friendly Markdown pages.
This is an emerging convention, not a universal requirement.
Use it where it reduces extraction noise without creating conflicting versions of truth.
The practical rule
Do not build for the least capable crawler.
Do not assume every agent has the most capable browser either.
Questions people ask
- Is client side rendering bad for GEO?
- Not inherently. The risk is making important facts depend on fragile execution or interaction rather than on content a retrieval system can reliably reach.
- Do AI agents run JavaScript?
- Some do. Capabilities vary widely across search and agent systems, so it is safer not to assume any single level of rendering ability.
- Should we make a static duplicate of every dynamic page?
- Usually no. Prefer one canonical page with accessible content and progressive enhancement over parallel versions that can drift apart.
- Does accessibility improve agent readiness?
- Often yes. Semantic structure and descriptive controls benefit both assistive technology and machine interaction.