A client has 14 location pages with the wrong phone number and opening hours on every one. The fix is simple; getting into the CMS is not. White-label AEO lives or dies on the request path between a bot and that CMS. If an agency can put a reverse proxy at the edge, it can change the HTML a fetch receives without editing the original page. If it cannot explain that middle hop, its “no developer needed” pitch is just a slogan.

Use that client as a running example. The location pages still show a holiday schedule from 2022, the developer is unavailable, and nobody can find the CMS login. An edge rewrite can correct what a visitor or bot receives. It cannot cure every problem hiding behind the login. Here is how to tell the difference.

Start with the HTML a fetch actually receives

When an AI assistant fetches a page, it reads the response it gets, not a CMS entry sitting behind it. ChatGPT-User can fetch a page during a user-initiated request; Anthropic has separate bots for training, search and Claude-User fetches. Not every answer requires a live visit. For the visits that do happen, though, the returned HTML is the thing you can change.

The path has three parts:

  1. DNS sends the request toward the domain’s configured destination.
  2. The edge sits in front of the client’s server and can intercept and modify requests and responses.
  3. The origin is the client’s server, where the existing site lives.

I used to talk about the CMS as though it was the site. It is where the original page is managed. What a bot receives is the response that comes back through this path. Put a worker in the middle, and you can change that response without changing the CMS entry. That distinction is the whole pitch, and its first limit: the worker needs a request it can handle and, for a rewrite, an origin response it can use.

Follow one request through the proxy

An edge proxy is a reverse proxy between the requester and the client’s server. Say ChatGPT-User requests /emergency-plumber-austin. DNS routes the request to the edge worker. The worker fetches the original page from the origin, edits the response and returns the edited version. The origin still holds its old page. The requester sees the new HTML.

That is not quite what a CDN cache or a CMS plugin does. A cache can serve a stored copy of a response. A plugin changes what the CMS produces and requires access to that system. The edge can ship title changes, redirects, schema and tests without editing the origin. Here is the useful distinction: a cache repeats a response; a plugin changes the source; an edge rewrite changes what gets served.

The edit happens before the response goes out

The worker need not download a page, rebuild the site and upload it again. Cloudflare’s HTMLRewriter, for example, supports modifying HTML as it passes through without buffering the whole document. A rule can match head, title or a[href] and alter the matching element. One documented use rewrites a script source; the AEO version can insert JSON-LD into head at the CDN before a visitor or crawler receives the page.

Back to the home-services client. The origin returns the stale opening hours. The worker receives that HTML, updates the LocalBusiness markup with the verified phone number and hours, changes the title from “Plumber | Home” to “Emergency Plumber in Austin: 60-Minute Response,” and sends the result on. A visitor and a bot can receive the correction even though nobody opened the CMS. One origin fetch, one response edit, one corrected page served.

That mechanism is powerful, but notice what it depends on: the agency has the right facts, the request reaches the edge, and the origin supplies a page worth editing. Keep those conditions in view as the list of possible changes grows.

What an agency can change without CMS access

The most direct job is structured data. The worker can insert a corrected JSON-LD block in head across the 14 location URLs. In groas, the agency can treat that as a rule for /location/*: use verified phone numbers and hours, and add FAQ or Service schema where the answers already appear on the page. The aim is not to pour markup over bad copy. It is to make the markup agree with what a reader can see. Fix the answer before you label the answer.

Diagram of a bot request reaching an edge worker, which fetches the origin and returns edited HTML

Serve the right crawler files for the right jobs

The edge can also serve files bots request without opening the CMS. These three are easy to confuse:

Publishing an llms.txt file is not the same as fixing crawler access. The draft’s cited analyses found no citation-frequency lift from the file alone across 300,000 domains, and only 84 requests for it among 62,100 AI bot visits in a 90-day log study. Treat it as a menu, not a lock. Access rules still need their own work. There is a further wrinkle: robots.txt may not apply to user-initiated ChatGPT-User visits. If the requirement is to stop those fetches, an edge rule targeting the user-agent is a different control from another Disallow line.

For the location-page client, this means checking what each bot can reach before promising that a new file will change what it reads. Discovery, guidance and blocking are separate jobs.

Publish a page the origin never had

A worker does not have to fetch the origin for every path. For /austin-emergency-plumber-cost/, it can return an edge-held HTML page on the client’s domain, with copy, FAQ schema and links to the location pages. The CMS never held that URL. This is one route to getting client-site fixes live without waiting for write access.

It can also revise titles, meta descriptions and internal links on existing responses. A link to a broad /services page can point instead to a relevant answer page if that page exists and matches the surrounding text. None of this makes the origin’s old HTML disappear. It changes what comes back through the proxy. The distinction matters when someone later checks the CMS and wonders where the new page went.

Three problems the middle hop does not solve

The request path makes the limits easier to see. Ask what the worker needs at each step, then look for what is missing.

1. A slow or failing origin. To rewrite an existing page, the worker first needs the origin’s response. If the server takes four seconds, that wait does not vanish because a worker edits the HTML afterward. If it returns a 500 error, there may be no usable page to rewrite. An edge-held answer page is a separate case because the worker can serve it itself; that does not repair the client’s existing pages or hosting. Check Time to First Byte before selling a rewrite as a speed fix. The proxy can change a response; it cannot make a failing origin healthy.

2. Facts nobody has supplied. The edge can publish a cost page, but somebody still has to establish the plumber’s prices, service areas and warranty terms. If those facts are missing, adding Service schema or a tidy FAQ only makes an unsupported answer look more polished. For the 14 location pages, verify the phone number and hours before writing the rule. The edge removes a publishing bottleneck, not a knowledge bottleneck.

3. Text absent from the HTML. Some pages send a thin shell and expect JavaScript to fill in the useful content. A December 2024 analysis reported that several major AI crawlers fetch JavaScript files without executing them. In a 50-site test cited there, 20 of 32 judgable sites depended on JavaScript for most of their text; their crawler-visible versions had a median of 7 words against 631 visible to a human. If the origin sends an empty root element, there is no service list in that HTML for a simple rewrite to improve.

The quick check is to view the page’s source, not the browser’s Inspect Element panel, and look for the service list, prices and FAQs before scripts run. If they are absent, the agency would have to supply that body content through the edge rather than merely patch the head. Say that plainly. A schema block around an empty body does not give a fetcher the missing explanation. Before promising a fix, check whether bots could actually load the page.

Five questions that expose a vague proxy pitch

Once you know what the middle hop does, a vendor demo becomes easier to interrogate. I would ask these in order, including when you onboard a first white-label AEO client without touching their CMS:

  1. Which user-agents get the rewrite? Does it cover GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User and PerplexityBot, or only Googlebot?
  2. Where do new answer pages live? Are they served from the edge on the client domain, or hosted on a separate subdomain with a canonical pointing back?
  3. What happens when the origin is slow or down? Is the response a stale copy, a hard failure or a bypass with an alert?
  4. How do you show what a bot received? Can the vendor provide fetch logs by user-agent and the resulting HTML, rather than relying on referral traffic alone? Bots that do not execute JavaScript will not show up in a JavaScript-based analytics report in the same way as visitors.
  5. Who owns rollback and communication? Can the team restore the origin response quickly, and does the client’s developer know about the edge rules? Otherwise, edits can create a gap between what developers manage and what gets served.

Those questions test the delivery, not the slide deck. If a vendor cannot show the rewritten response and explain how to undo it, you cannot tell what you are reselling.

Run the model on a different client

Now take a dentist on Wix with a five-second mobile load time and a contact page built around an embedded booking iframe. Start at the request path. DNS can send the fetch to the edge, and the worker can fetch the origin. It can fix a title, insert verified Dentist schema and serve an edge-held /dental-emergency-austin-cost/ page if the dentist supplies the facts for it. Those are middle-hop jobs.

Then test the limits. The existing pages still depend on a slow origin. The worker cannot rewrite booking information it never receives as usable HTML from the iframe. And a new cost page is not ready just because a URL is available: somebody must provide the real answers. Because major AI crawlers may fetch scripts without running them, I would inspect the raw source before promising that a head rewrite solves the contact page.

The pitch to that dentist is specific: use the edge for markup and pages it can actually serve; address origin speed as origin work; get the missing facts from the client before publishing answers. That is what white-label AEO is worth selling. I run this work through groas for agencies because execution and action logs matter alongside the rewrite. The proxy is the tool. The log is how you show what it did. If a vendor sells you the first without the second, you bought a rumor.