Rendering in the DSCRI Pipeline: The Bot Sees a Different Page Than Your Customers Do
By Jason Barnard
Search was built on favours, and the new AI bots are not offering them.
Google and Bing invested heavily in JavaScript rendering. They built the infrastructure to execute client-side code, construct the Document Object Model, and produce a rendered page close to what a human browser sees. That investment was a favour to the web development community, which had built an increasing proportion of the web on JavaScript frameworks that required rendering to expose their content. The favour worked and JavaScript became standard. And the industry built on the assumption that the standard was universal.
That assumption is wrong: most AI agent bots do not render JavaScript, they fetch the initial HTML and work with that, Perplexity’s grounding fetches work primarily with server-rendered content, and the smaller AI agent bots have no rendering infrastructure at all. A page that loads a product comparison table via JavaScript displays perfectly in a browser and renders as an empty container for a bot that does not execute the code. The human sees a detailed comparison and the bot sees a div with a loading spinner.
Rendering Fidelity: how much of your published content the bot actually sees
I coined the term Rendering Fidelity - Jason Barnard’s measure of how much of the published content the bot actually receives - because the industry had been treating Rendering as binary: either the bot rendered the page or it did not. The reality is a spectrum. The bot may execute some JavaScript and not others, may parse some DOM elements cleanly and interpret others approximately, may produce a rendered version that captures 60% or 80% of the semantic content depending on the complexity of the implementation and the processing investment the system allocated at Selection.
Content behind client-side rendering that the bot never executes is gone. Information the bot never sees cannot be recovered at any downstream gate. Every annotation, every grounding decision, every display outcome depends on what survived rendering, and the grounding system verifies what was annotated, the display system presents what was grounded, and every gate from Annotation forward operates on the raw material that Rendering produced.
The friction hierarchy explains why the bot renders some sites more carefully than others
Fabrice Canel confirmed that the more common a pattern is, the less friction the bot encounters. WordPress with Gutenberg and a clean theme covers roughly 30% of the web. The bot has parsed that pattern more times than any other and encounters minimal friction. Established platforms like Wix and Squarespace use known, predictable structures. WordPress with page builders like Elementor adds markup noise that forces the bot to work harder to find core content. Bespoke code, however well-written, presents an unfamiliar pattern the bot has to interpret without a reference library to validate against.
The critical implication: if a site is not important enough (meaning, if publisher entity authority is low) the bot may never reach full Rendering because the cost of parsing unfamiliar code exceeds the estimated benefit of getting the content. Entity authority determines whether the system invests in rendering your page carefully or cheaply. That is the Selection gate expressing itself at Rendering.
Three rendering pathways, and two of them bypass the problem entirely
The traditional rendering model assumes one pathway: HTML delivered, bot constructs DOM, Rendering Fidelity determined by how much JavaScript the bot executes. For most of the web’s history, that was the only option.
WebMCP, built by Google and Microsoft and therefore a safe long-term bet, gives agents direct DOM access without the traditional rendering pipeline. Instead of fetching HTML and building the page, the agent accesses a structured representation of the DOM through a protocol connection. The bot does not need to execute JavaScript or guess at layout, because the structured DOM is served directly. Rendering Fidelity becomes a non-issue: the bot receives exactly what it needs.
Markdown for Agents uses HTTP content negotiation to serve pre-simplified content. When the bot identifies itself, the server delivers a clean markdown version instead of the full HTML page, stripped of everything the bot would have had to remove anyway: navigation, sidebars, JavaScript widgets. The rendering gate is effectively skipped with zero information loss. If you use Cloudflare, they launched an easy implementation of this in early 2026.
For me, the practical test is simple: disable JavaScript in your browser and look at your page. What you see is what most AI agent bots see. If the page is empty, broken, or missing core content, your Rendering Fidelity is low and you have a gate failure that costs you everything downstream. Fix it with server-side rendering or static site generation so the initial HTML contains the complete semantic content, or skip the problem entirely with WebMCP or Markdown for Agents.
What is lost at Rendering cannot be recovered
This is the sentence worth carrying from this article into everything that follows. The annotation system in the ARGDW phase works on what survived rendering, the grounding system verifies what was annotated, the display system presents what was grounded, and every gate from Annotation forward operates on the raw material that Rendering produced, and degraded raw material produces degraded competitive performance regardless of how well the downstream gates operate.
The brands still building on JavaScript frameworks without server-side rendering, without WebMCP, without Markdown for Agents, are running the ARGDW competitive phase on whatever fraction of their content the bot happened to see. Their competitors who invested one architectural change in either of the bypass pathways are running it on 100%.
The Complete Ten-Gate AI Engine Pipeline
- Discovery in the DSCRI Pipeline: The Bot Will Never Find You If You Wait to Be Found
- Selection in the DSCRI Pipeline: The Bot Decided Your Page Wasn’t Worth Its Time
- Crawling in the DSCRI Pipeline: The Bot Arrived at Your Page and Brought a Briefing Document
- Rendering in the DSCRI Pipeline: The Bot Sees a Different Page Than Your Customers Do
- Indexing in the DSCRI Pipeline: Stored Is Not the Same as Understood
- Annotation in the ARGDW Pipeline: The Bots Stored Your Page but the Algorithms Don’t Understand It
- Recruitment in the ARGDW Pipeline: The Trick Is to Charm the Algorithmic Trinity
- Grounding in the ARGDW Pipeline: The Truth-Check That Decides Whether the AI Uses Your Brand or Your Competitor’s at the Moment of Display in Assistive Engines
- Display in the ARGDW Pipeline: Your AI Salesforce Is Recommending Your Competitor, Not You
- Won in the ARGDW Pipeline: 95% of Your Market Is Not Buying Right Now. Who Does the Assistive Engine Choose When They Are?
This is the fourth in a five-part series on the DSCRI infrastructure gates in Jason Barnard’s ten-gate AI Engine Pipeline (part of the 15-gate Kalicube® Framework). The next piece covers Indexing: the strip, chunk, convert, store sequence that transforms your rendered page into what the system actually files, and why being filed incorrectly is more dangerous than being absent from the index entirely.
