Time Inc. has started placing ads inside pages that only AI agents will ever read. Not ads that a human might click on. These exist purely in a stripped-down markdown copy of a webpage, formatted as sponsored FAQ blocks, labeled as such, dropped there in the hope that when a large language model reads the page, the brand's facts end up in its answer.
The first two buyers are Ally Bank and the Project Management Institute. The AI probably didn't notice. That's not a criticism. It's the interesting part.
But before getting to the ads, there's a reasonable objection worth addressing. These are systems that can invent new mathematical algorithms, synthesize research across entire fields, and generate a photorealistic image of a Jack Russell Terrier in a traditional Italian commedia dell'arte clown costume in about four seconds. The premise that HTML would slow one down seems a little thin. So why does any of this infrastructure exist?
The Performance Argument (It's Not About Reading)
The answer is that it's not really about whether AI can parse HTML. It can. The issue is what happens when an AI agent doesn't just read a page but tries to do something on it.
A reading agent, one fetching content for a RAG pipeline (Retrieval-Augmented Generation: the technique where an AI pulls in fresh external content at query time rather than relying purely on its training data) or answering a user's question, pays a token cost to process HTML. All the navigation elements, JavaScript, CSS, layout scaffolding, cookie consent banners, and chat widgets that exist for human reasons get consumed as tokens before the agent gets to the content.
TollBit claims a roughly 90% reduction in token load when serving markdown instead of HTML. That's real, if a bit self-interested as a claim.
But TollBit's more interesting research is about execution agents, the kind that don't just read but do things: navigate to a product, apply filters, add an item to a cart, complete a checkout. For those agents, HTML sites create a genuinely different class of problem.
TollBit ran 1,000 benchmark tests across five e-commerce sites, using Claude Sonnet 4.6 as the agent, holding the task, prompt, and model constant, and changing only whether the agent was navigating the standard human-facing site or an agent-optimized version of the same site with the same products and prices. The results were notable: the agent-optimized surface was 24 to 35 percent faster to task completion across all five sites, used 18 to 38 percent fewer steps, and hit 100 percent task completion. The standard sites ranged from 91 to 100 percent completion, with failures tied to bots running out of steps while stuck in navigation loops or fighting popup overlays.
The failure modes are the telling part. In 21 of 500 default-site runs, the agent ran out of its step budget without finishing the task. Of those, 12 failed because the site's bot-detection triggered silently on repeated API calls, not with an error message but with actions that just stopped working, leaving the agent retrying until it hit its limit.
Eight more failed because the agent got distracted by a popup or made a wrong-turn navigation decision and couldn't recover efficiently. One failed because the page froze.
None of that is about whether the AI can read HTML. It's about whether a site built for a human who can visually scan, ignore distractions, and adapt on the fly is also a good environment for an agent executing a script. The answer, it turns out, is sometimes no.
How the Parallel Site Works
The setup is conceptually similar to how mobile-optimized sites work. You're not creating new content or a new product catalog. You're creating a different surface over the same content, one that a specific kind of visitor can use more reliably.
The practical implementation involves a few layers. First, bot detection: the site identifies non-human traffic by user-agent string. AI crawlers and agents announce themselves in their request headers, most of them anyway, and those identifiers are how services like TollBit distinguish a human browser session from an automated one.
Second, routing: detected bots get redirected to a subdomain, typically something like tollbit.yourdomain.com, which serves the same content as a clean markdown document, stripped of navigation, layout, and everything a browser needs but an agent doesn't. Third, access control: the publisher decides which bots get redirected to the clean version, which get blocked entirely, and which get charged per fetch. TollBit runs a marketplace for exactly this, at rates between $0.001 and $0.20 per page depending on content type.
The markdown output strips the presentational layer and returns the content itself: headings, paragraphs, structured metadata, links. An agent reading a product page gets the title, the specs, the price, the description. It doesn't get the image carousel, the sticky nav, the "customers also viewed" widget, or the promotional overlay asking for an email address.
WebMCP, the Google and Microsoft co-developed standard currently in a Chrome 149 origin trial, takes a different approach to the same underlying problem. Instead of a parallel site that a bot gets redirected to, WebMCP lets any website expose structured tools directly to AI agents through a browser API. A developer annotates their JavaScript functions and HTML forms so that an agent can call them as typed, reliable actions rather than guessing at the DOM.
The website hands the agent a manifest: here are the things this page can do, here are the exact parameters each action takes. The agent doesn't need to screenshot the page and infer where the add-to-cart button is. It calls the addToCart function directly.
That's a more elegant solution architecturally. But it requires every website to implement a new standard, which historically takes a while.
How to Build Your Own Parallel Site for LLMs
You don't need TollBit to do this. The core pattern is straightforward enough to implement yourself, and understanding how it works is useful whether or not you use a managed service.
The first step is robots.txt, the file that lives at yourdomain.com/robots.txt and tells crawlers what they can and can't access. The traditional use is blocking search engines from indexing certain pages. The same mechanism works for AI agents.
Each major AI system announces itself with a known user-agent string. OpenAI's assistant bot uses ChatGPT-User, Anthropic's uses Claude-User, Google's browser agent is GoogleAgent-Mariner, Perplexity uses Perplexity-User, and Amazon's shopping agent announces itself as AmazonBuyForMe. There are dozens of these now.
A robots.txt block that denies all of them from your main site looks roughly like this:
User-agent: ChatGPT-User
Disallow: /
User-agent: Claude-User
Disallow: /
User-agent: GoogleAgent-Mariner
Disallow: /
User-agent: Perplexity-User
Disallow: /
User-agent: AmazonBuyForMe
Disallow: /But blocking them entirely isn't the goal. The goal is to redirect them somewhere better. robots.txt can only allow or deny, it can't issue redirects. So the redirect logic lives in your server config or middleware.
The pattern Time uses, and the one TollBit automates, is to detect the AI user-agent in the HTTP request headers on the server side, then issue a redirect to the equivalent page on a separate subdomain that serves markdown instead of HTML. In Apache .htaccess, a simplified version looks something like this:
RewriteCond %{HTTP_USER_AGENT} (ChatGPT-User|Claude-User|GoogleAgent-Mariner|Perplexity-User|AmazonBuyForMe) [NC]
RewriteRule ^(.*)$ https://agents.yourdomain.com/$1 [R=302,L]The agents subdomain needs to exist and serve content. The simplest version is a script that takes any URL path, fetches the corresponding page's content from your database or CMS, strips the HTML template, and returns clean markdown. If your site runs on WordPress, there are plugins that expose a markdown or JSON version of any post. If you're on a custom CMS, it's a matter of adding an alternative output format to your existing content endpoints.
What you serve on that subdomain should include the content, the heading structure, the metadata, and the links. No navigation, no sidebars, no scripts, nothing that only makes sense inside a browser. The goal is that an LLM reading the page gets everything it needs to understand and cite the content, and nothing it doesn't.
One more thing worth knowing: robots.txt and the server-side redirect work together but differently. robots.txt tells well-behaved bots what they're permitted to fetch. The redirect handles the actual routing for any bot that checks user-agent regardless of robots.txt.
Most major AI systems respect robots.txt. Not all do, which is part of why the server-side rule matters as a backstop.
Back to the Ad That No Human Saw
Time's agent ads, built with a company called Mobian, are dropped into those markdown pages as labeled FAQ blocks. A brand writes a brief, Mobian generates structured factual claims, a human approves the PDF, and the content gets embedded in the version of the page that bots read. Mobian then tracks visibility, favorability, and accuracy over time. Whether any of this changes what an LLM says about a brand is, as of now, unverified by any independent party.
There's a reasonable skeptic position here. Scott Messer, a publisher consultant quoted in Digiday's original piece, put it plainly: "If there's no click, no ad impression and no check, the build is pure cost." If you don't believe agent citation eventually translates to some form of measurable value, you're doing expensive infrastructure work for an audience that can't buy anything.
That's a fair challenge. But it assumes the relationship between AI citation and downstream human behavior is currently unknowable, which may be true in a measurement sense but probably isn't true in a directional one. When an agent gives a user an answer that includes a brand by name, something happened. Whether that something is worth $X per sponsored FAQ block is genuinely unclear.
What is clear is that a meaningful portion of web traffic is already non-human, and it's growing. The infrastructure of the web, its business models, its ad formats, its analytics, was designed around a person sitting in front of a browser. That assumption is loosening.
Time selling an ad that no human will ever see is a small, strange data point in a much longer story about what the web is for. Whether it's a good investment for Ally Bank is probably a question for 2029.
The TollBit whitepaper is worth a read if you want the execution-layer performance data directly.