Serving AI bots a different page: prerendering or cloaking?

On 11 October 2026, Profound launched a feature called "Dynamic Bot Rendering". It spots visits from AI crawlers and hands them a fully built copy of the page, while human visitors keep receiving the page as usual. One site can therefore exist in two versions: the one your customers read, and the one read by the systems that assemble answers in ChatGPT, Perplexity or Gemini.

The technique itself is not new. Engineering teams have been serving prerendered pages to search engines for the better part of a decade under the name dynamic rendering, and Google documented how to set it up for years. What has changed is the recipient. AI crawlers do not share Googlebot's technical abilities, its published rules, or its tolerance. Two episodes from the summer of 2026 showed that a line does exist, and that crossing it has a price.

This article first establishes why the underlying technical problem is real, then tests the practice against the definitions of cloaking already on the books. It goes on to describe the precedent that currently sets the penalty, and offers a simple test for deciding whether your own setup holds up.

Key takeaways

• The main AI crawlers do not execute JavaScript, so part of the content your readers see never reaches them.
• Serving those crawlers a prerendered version is not deceptive as long as the content stays equivalent to what human visitors get.
• The line is measured by the gap between the two versions, not by the fact of serving two.
• Perplexity has already penalised a publisher over a bot-only version it judged deceptive, targeting its trust score rather than its ranking.
• Server-side rendering remains Google's recommendation, because serving everyone a single page removes the question entirely.

Why AI crawlers do not see the page your visitors see

A modern site often assembles its content in the visitor's browser, after the initial load. AI crawlers, for their part, usually take only the first HTML file the server returns. Anything that appears after that point is lost on them.

Profound describes three common situations in its announcement. A homepage built on a JavaScript framework may ship little more than an empty shell. A pricing page whose tabs only fill in on click delivers nothing before that click, which the crawler will not perform. A page whose personalisation logic or third-party scripts inject the text after load behaves the same way. The company draws a commercial conclusion from this and argues that marketing now addresses "two audiences", the human buyer and the system that writes the answer.

The imbalance matters more as bots take a larger share of traffic. On 3 June 2026, Cloudflare chief executive Matthew Prince said that automated traffic had overtaken human traffic for the first time. Cloudflare Radar data put it at 57.5% of requests at that point, against 42.5% for human traffic. The measurement covers HTML page requests rather than total bandwidth, which narrows the figure's scope without changing its direction. AI crawlers are only one part of that total, alongside monitoring tools and malicious bots, a split we examined in our piece on Cloudflare's default setting for AI bots.

Do AI crawlers execute JavaScript?

Most do not, and the limitation has been documented since late 2024. The Vercel and MERJ study published on 17 December 2024 examined server logs across Vercel's network to compare how the main crawlers behave.

The authors found no client-side JavaScript execution by the crawlers operated by OpenAI, Anthropic, Perplexity, Common Crawl, ByteDance or Meta. Two exceptions stand out: Googlebot, whose infrastructure feeds Gemini, and Applebot, which runs a browser-based crawler. The volumes recorded over a single month give a sense of the scale involved, with roughly 569 million requests from GPTBot and 370 million from Anthropic's crawler.

One detail of the study is worth pausing on: these crawlers download JavaScript files without running them, in 11.50% of requests for OpenAI's crawler and 23.84% for Anthropic's. They are spending bandwidth that returns them nothing. Two caveats apply to the findings. The data comes from Vercel's network and its own nextjs.org site, which does not guarantee the same distribution elsewhere, and it dates from late 2024, in a field where crawler behaviour moves quickly. Our glossary of AI crawlers sets out what each one does.

What Google calls cloaking

Google's spam policies define cloaking as presenting different content to users and to search engines. Stated intent counts as much as the observed gap: manipulating rankings and misleading users.

The policy page, last updated on 28 August 2026, gives two examples. The first shows search engines a page about travel destinations while users see a page about discount drugs. The second inserts keywords that appear only when the request comes from a crawler. The stated consequences range from ranking lower to disappearing from results altogether.

Google's documentation on dynamic rendering, last updated on 10 December 2025, settles the prerendering question directly. It states that Googlebot will not view the technique as cloaking as long as the rendering produces content similar to what visitors see. The same page goes on to call dynamic rendering a workaround rather than a durable fix for JavaScript-generated content. It points instead to server-side rendering, static rendering or hydration.

Two limits temper how far these texts reach. They address search engines and rankings, not answer engines that compose text from sources. No AI provider has published an equivalent rule to date, and Profound's announcement mentions neither cloaking nor search engine guidance.

The Time case showed who penalises, and how

The clearest precedent comes not from a written rule but from a commercial decision. During the summer of 2026, Time's site began serving AI crawlers markdown versions of its pages containing advertising blocks that no human reader ever saw.

A developer spotted the practice in early August 2026, and the trade press picked it up shortly afterwards (MediaPost, 7 August 2026). The blocks, produced with the ad tech firm Mobian, took the shape of question-and-answer pairs carrying a brand's messaging, in a format AI systems extract readily. Ally Bank and the Project Management Institute are named among the early buyers.

The response came less than two weeks later. On 11 August 2026, Digiday reported that Perplexity had blocked all of that markdown advertising on Time.com from influencing either its agents or the results shown to its users. Jesse Dwyer, Perplexity's chief communications officer, warned that publishers deploying "deceptive advertising like markdown ads" exposed themselves to a reputational downgrade. That downgrade would affect their standing in the company's search index, "including a hit to their trust score". Perplexity did not say how it defines deceptive or how it detects the blocks, and Time did not comment on the decision.

The episode teaches two things to anyone considering bot rendering. A penalty exists even without a published rule, and it lands on the trust placed in the domain rather than on a ranking. It was also handed down over an obvious content gap, not over the principle of serving a separate version.

Where does prerendering end and misleading content begin?

The useful test is not how many versions you serve but whether they are equivalent. A crawler can receive a page built differently, provided it reads the same thing a human reader would. Applying that test separates three distinct cases.

The middle row calls for the most care, because it slides easily into the third. A markdown version for crawlers looks harmless at first. One team then adds a list of question-and-answer pairs to improve its odds of being cited, and another places a sales claim the public page does not carry. Each step looks minor, and the accumulated gap eventually becomes visible. We described a related mechanism in our piece on GEO poisoning, where the manipulated content comes from a third party rather than the publisher.

A second consideration arises before any rollout. Bot rendering creates a surface nobody looks at. Readers never see it, and marketing teams do not proofread it either, since it does not appear in an ordinary browser. A mistake introduced into that version can therefore circulate in AI answers for a long time before anyone notices.

What we recommend before turning on bot rendering

Server-side rendering remains the sturdiest answer, for a reason that fits in one sentence: there is only one page, so no gap is possible. Google has recommended it since 2022, and it solves the problem for every crawler at once, including the ones that will appear next year. A rebuild does cost time, however, and not every team has that time in the short term.

If you go ahead with bot rendering regardless, three conditions strike us as necessary. The version served to machines must carry the same text as the public version, with nothing added. It must be proofread like any other page, on a regular schedule, by whoever owns the content. It must also be checked from the outside, by an agent that requests the page while identifying itself as a crawler and then compares what it receives with what a browser receives.

A first check needs no special tooling. Request a page on your site while presenting yourself as GPTBot, for instance with curl -A "GPTBot" https://your-site.com/page, and save the response. Then request the same page with an ordinary browser identifier and compare the two texts once the markup is stripped out. A difference in formatting is expected, since that is what prerendering is for. A sentence, a claim or a block present on only one side calls for an explanation.

This last point is the one most tools on the market leave aside. Profound offers a "Bot View" that shows what crawlers see, but the check stays inside the tool that produces the rendering. A discrepancy introduced by the feature itself would not show up in its own interface. That is the job of an AI visibility audit run independently of the publishing chain, followed by citation tracking that observes what the engines actually take from your page. Our article on proving that GEO works sets out the general verification method.

For most sites, the sensible decision is to treat the cause rather than the symptom. Put what you want cited into the initial HTML first, since that work also serves your visitors and your performance budget. Keep differentiated rendering for cases where a rebuild is planned but not yet done, and treat it as a temporary stage. Give yourself the means to confirm, every month, that the two versions still say the same thing.