How to Ship AEO Fixes on Client Sites You Don’t Control

You can sell AEO to 15 clients by Friday. Getting one schema fix live on all 15 domains is the hard part. Most agencies run the audit, write the recommendations deck, send it to a client contact who promises to pass it to their developer, and watch nothing ship for six weeks.

I know that stall from PPC. I have watched a landing page change hurt performance without warning, then waited on a different page change that could have helped because nobody with access made it. The lesson carries over: deployment method decides AEO results more than any content tactic. If you run more than five client domains, make an edge proxy your default instead of renting space in someone else’s developer queue.

Why does your AEO audit die in someone else’s inbox?

Hand a client a 40-page AEO audit and you have not sold execution. You have sold homework for a developer who did not ask for it, does not report to you, and already has a backlog of checkout bugs and plugin updates. Your FAQ schema is not winning that scheduling fight. One often-cited agency figure says the majority of SEOs wait six months to see recommendations go live. The precise wait will vary. The mechanism will not: the person who finds the fix cannot ship it.

A client contact can love your recommendations and still have no way to get them onto the site this month. You can improve the deck, add priorities, and make the developer ticket beautifully specific. None of that changes who owns the queue. The finding is cheap; the shipping is the product. If your delivery model requires someone else’s developer to care as much as you do, you do not have a delivery model.

How does a fix reach a site you do not control?

You have three practical paths. They differ less in what you can recommend than in who has to act before a recommendation becomes a live page:

1. Send tickets to the client’s developer. You specify the change; they schedule, deploy, and, if necessary, undo it.
2. Publish directly through the CMS. You use an API or plugin to update content and on-page fields, provided your access keeps working.
3. Deploy through an edge proxy. A worker at the CDN can rewrite a response after the CMS renders it but before a crawler receives it. That gives you a route to change titles, inject JSON-LD, set canonicals, and return 301s without deploying the client’s codebase.

The third path sounds more intimidating than it is. The important distinction is control: an edge change can go live and be rolled back without another request to the client’s developer. I go deeper on these routes in how agencies get client-site fixes live.

Tickets are familiar and slow. CMS access is fast until you are juggling 12 different WordPress roles, a Shopify store that blocks your app, and a HubSpot login that stops working. Edge sits in front of those publishing systems. Past five domains, choose a shipping path you can operate without asking permission for every fix.

Which method holds up across 15 domains?

I use four questions: How quickly can a finding go live? What access does it need? How do I undo it? What can it touch? A method that looks painless on one site can turn into a weekly permissions chase across 15.

Rollback is where I decide what I will sign my name to. With tickets, I have to ask whether the developer kept a backup. With CMS publishing, I need a usable revision. At edge, Cloudflare Workers offers a one-click rollback to a prior deployment. There is a catch worth respecting: rolling back traffic does not undo writes to KV or R2 storage. I keep edge changes narrow, approved, and versioned rather than treating rollback like a magic eraser. A client can approve a title rewrite more comfortably when undoing it does not mean touching checkout code.

Coverage matters just as much. Tickets can change almost anything if the developer says yes and gets to it. CMS publishing handles articles and on-page fields well, but it does not solve every root-file or server-level request. At edge, I can handle the file and technical layer: llms.txt and robots.txt, crawler allowances, sitemap references, and schema. When the host blocks direct edits to robots.txt or llms.txt, the edge layer can serve the intended version instead.

That gives me a division of labor: edge for technical and file fixes, CMS publishing for long-form content, tickets as a fallback. It is a deployment plan, not a claim that every change belongs in a worker.

How do you keep entities and schema straight across 15 domains?

Solving deployment exposes the next problem: consistency. Each client needs one entity sheet with its name, services, locations, and proof points. I treat every new page and schema block as a reflection of that sheet. Otherwise, a live page can say one thing while its markup says another. That is not a clever AEO tactic. It is two versions of the client competing for authority.

I follow the knowledge-graph and publishing approach groas documents for agencies: establish the entity, then publish schema that matches the page. Schema ships with the page, never after it. At edge, the JSON-LD rule and content change belong to one release with one version number. In the CMS, the custom fields feeding Product, Breadcrumb, FAQ, and LocalBusiness markup belong in the template, not in a block someone remembers to paste by hand.

Verification has to cover what was delivered, not just what the editor preview showed. Fetch the URL as GPTBot and Googlebot and compare the responses. If the entity name differs by an ampersand versus and, fix the source sheet and ship again. On one domain, that is discipline. On 15, it needs to be a repeatable rule rather than somebody’s excellent memory.

How do you publish content without becoming the bottleneck?

Content is where direct CMS publishing earns its place. WordPress supports AI-assisted publishing through its API, including posts, images, and categories. Easy publishing is also an easy way to create a pile of content nobody meant to approve.

I use a narrow gate: the client approves topics and the entity sheet, names one approver, and agrees to a 48-hour default-yes window for drafts within that scope. If they flag a draft, it stops. No agreed approval rule, no automatic publishing. Otherwise you have replaced a developer backlog with an approval backlog and called it scale.

The Search Atlas WordPress workflow illustrates the CMS part: connect once, publish fixes, and sync CMS edits back so they are not overwritten. Useful, but CMS publishing is only one part of this operating model. I still want an edge route for technical changes and a log that connects both routes to the client’s approval and report. That broader execution model is the point of groas for agencies, not another login for someone to babysit.

I log changes the way I used to log PPC change history: URL, old value, new value, approver, and the edge deployment or CMS revision needed to roll back. Some teams use a JavaScript overlay with deployment history for on-page edits. I prefer edge or CMS-native logs because browser-side JavaScript depends on execution there, while edge rewrites the response itself. Whatever ships the change, put the before and after in the weekly client report. The groas knowledge-graph and CMS publishing guide lays out that logging habit. A report should show work that reached the site, not just work that made the task list.

What should happen in the first three days?

I use the same order for domain one and domain 15. It tests access, publishing, approval, and rollback before an agency has a queue of drafts waiting on a connection that never worked.

1. Day one: secure access and authority. Get DNS delegation for the edge worker and a read-write CMS key tied to a named service user, not somebody’s personal admin login. Confirm rollback permission in writing.
2. Day two: ship the file layer. Put llms.txt, the agreed robots.txt allowances, and the sitemap reference through the edge route. Record the deployment version.
3. Day three: publish one test page. Take it through the real topic and draft approval gate, then check the live response and log the before and after.

For the first-client version, I wrote a more detailed white-label AEO onboarding walkthrough. groas for agencies connects each client’s ad accounts and website across platforms and CMSs. The operational test remains the same: can you move one approved change from decision to live response, then show exactly how to undo it?

Before calling onboarding complete, I want five things in place:

• DNS access or a CNAME for the edge worker, with rollback permission in writing.
• A CMS API key tied to a service user and scoped to the posts, pages, and schema fields it needs.
• A signed-off entity sheet covering name, services, locations, and proof points.
• One named approver and an agreed 48-hour default-yes rule.
• A log destination for the weekly branded report, with old and new values for each change.

How do you know the bots saw the change?

Do not trust raw hit counts or a preview screenshot. Server logs show bot requests that GA and tag tools miss. I filter access logs for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, and CCBot, then check status codes and response size. A 200 serving a full body is different from a 200 serving a challenge page. A 403, 429, or 5xx needs attention even if the publishing dashboard says the change went live.

A user agent alone is not proof of identity; anyone can claim to be a bot. I verify against published IP ranges or reverse DNS before counting a request. Verified fetches with clean responses are the ship confirmation I accept. That check closes the gap between “we deployed it” and “the intended crawler received it.”

When should you skip the edge proxy?

I default to edge past five domains, not on every site regardless of circumstances. Skip it when you have one cooperative developer and one CMS you already control. Direct publishing is simpler there. Skip it when enterprise security will not delegate DNS and the access fight costs more than the ticket queue. Skip it on a fragile checkout flow where another worker already rewrites responses; stacking rewrites is a poor way to discover who owns a broken cart at midnight.

Those are real exceptions. For the rest, tickets are the most expensive option on the menu: they cost nothing to set up and everything in delay. Choose the method that lets you ship, verify, and reverse an approved fix without turning every change into a favor.

The first thing to do today is small. Pick the client whose AEO fix has sat unshipped the longest. Get DNS delegation and a CMS service user in writing, then ship the file layer and one test page through the agreed approval gate. That is the chain to prove before you promise it across 15 domains. groas runs white-label AEO for agencies around one connection per client, continuous execution, logged actions, and weekly reports under your brand, with a full week on one real client before you pay. Stop selling audits that need someone else’s developer to succeed. Sell shipped fixes you can roll back.