--- title: "How to Ship AEO Fixes on Client Sites You Don’t Control" description: "For agencies, AEO stalls when fixes wait in a client’s developer queue. Compare tickets, CMS publishing, and edge proxies, then set up a workflow that holds across 15 domains." url: "https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t" image: "https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/5218d411-f027-44ba-8d9c-fb351fc9d0a9.png" published: "2026-10-19T05:36:05.801Z" modified: "2026-10-19T05:36:05.866Z" --- October 19, 2026 · 10 min read # How to Ship AEO Fixes on Client Sites You Don’t Control [Alexander PerelmanHead Of Product @ groas](https://groas.com/author/alexander-perelman)[LinkedIn](https://www.linkedin.com/in/alexander-433793253/) ![A deli take-a-number display reads 'Now serving 12' while a ticket marked 847 for a schema fix waits beside it, stuck in someone else's queue.](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/5218d411-f027-44ba-8d9c-fb351fc9d0a9.png) In this article 1. [Why does your AEO audit die in someone else’s inbox?](#why-does-your-aeo-audit-die-in-someone-elses-inbox) 2. [How does a fix reach a site you do not control?](#how-does-a-fix-reach-a-site-you-do-not-control) 3. [Which method holds up across 15 domains?](#which-method-holds-up-across-15-domains) 4. [How do you keep entities and schema straight across 15 domains?](#how-do-you-keep-entities-and-schema-straight-across-15-domains) 5. [How do you publish content without becoming the bottleneck?](#how-do-you-publish-content-without-becoming-the-bottleneck) 6. [What should happen in the first three days?](#what-should-happen-in-the-first-three-days) 7. [How do you know the bots saw the change?](#how-do-you-know-the-bots-saw-the-change) 8. [When should you skip the edge proxy?](#when-should-you-skip-the-edge-proxy) 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](https://huckabuy.com/technical-seo/edge-seo/) 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](https://alchemyleads.com/edge-seo/). 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](https://groas.com/post/getting-aeo-changes-live-on-client-sites). 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. | Question | Tickets to client dev | Direct CMS publishing | Edge proxy | | ------------------------- | ---------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Time from finding to live | Two to six weeks, sometimes never | Minutes once connected; access can take days | Minutes without a codebase deploy | | Access needed | No site access, which is the trap | Admin or API key for each CMS | DNS change, then rules for each domain | | Rollback | Ask the developer to restore the prior version | Use CMS revisions | Return to a prior deployment | | What it can touch | Whatever the developer prioritizes | Posts, pages, and most on-page fields | [Titles, canonicals, JSON-LD, 301s, hreflang, robots.txt overrides, and log collection where Shopify blocks logs](https://alchemyleads.com/edge-seo/) | 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](https://developers.cloudflare.com/workers/versions-and-deployments/rollbacks/). 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](https://whitebunnie.com/technical-aeo-checklist-schema-structured-data-2026/). 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. ![Small traffic control tower routing client-domain planes around a developer queue](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/f5a05bec-a4db-4afe-9fb2-026fea391300.png) ## 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](https://groas.com/post/agency-aeo-knowledge-graph-cms-publishing-guide): 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](https://savedelete.com/article/wordpress-ai-agents-write-publish-posts-automatically/), 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](https://www.searchenginejournal.com/search-atlas-announces-new-features-for-agencies/557725/) 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](https://tiny-tool.com/alliai-review/) 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](https://groas.com/post/onboard-your-first-white-label-aeo-clien). [groas for agencies](https://groas.com/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? ![Agency owner holding an audit binder while fixes move through a separate publishing route](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/ea66acf5-481b-469c-b945-790449ca4131.png) 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](https://siteseoaiaudit.com/ai-crawlers-server-logs/). 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. ## Frequently Asked Questions ### Why do AEO recommendations take so long to go live on client sites? The usual workflow hands the audit to a client contact, who passes it to a developer who did not ask for it and already has a backlog. The person who finds the fix cannot ship it, so recommendations often wait weeks or months. One often-cited agency figure says the majority of SEOs wait six months to see recommendations go live. ### What are the ways an agency can get a fix onto a client site it does not control? There are three practical paths. You can send tickets to the client's developer, publish directly through the CMS via an API or plugin, or deploy through an edge proxy where a CDN worker rewrites the response after the CMS renders it but before a crawler receives it. The edge route can change titles, inject JSON-LD, set canonicals, and return 301s without deploying the client's codebase. ### When should an agency use an edge proxy instead of client developer tickets? Past five client domains, an edge proxy is the better default because a change can go live and be rolled back without another request to the client's developer. Tickets are familiar but slow, and CMS access gets complicated when juggling many platforms and logins. Edge lets you operate a shipping path without asking permission for every fix. ### Does rolling back a Cloudflare Workers deployment undo everything? No. Rolling back traffic does not undo writes to KV or R2 storage. The recommendation is to keep edge changes narrow, approved, and versioned rather than treating rollback like a magic eraser, even though one-click rollback to a prior deployment is available. ### How do you keep schema and entity information consistent across many client domains? Give each client one entity sheet with its name, services, locations, and proof points, and treat every new page and schema block as a reflection of that sheet. 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, and in the CMS the fields feeding markup belong in the template rather than a pasted block. ### How do you publish content automatically for clients without creating an approval bottleneck? 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, publishing stops. No agreed approval rule means no automatic publishing, otherwise you have only replaced a developer backlog with an approval backlog. ### How can I verify that AI crawlers actually fetched my updated page? Filter server logs for user agents like GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, and CCBot, then check status codes and response size, since a 200 serving a challenge page is not the same as a full body. Because a user agent alone can be faked, verify the request against published IP ranges or reverse DNS before counting it. Verified fetches with clean responses are the ship confirmation. ### When is an edge proxy not the right choice? Skip the edge proxy when you have one cooperative developer and one CMS you already control, when enterprise security will not delegate DNS, or on a fragile checkout flow where another worker already rewrites responses, since stacking rewrites makes debugging difficult. In those cases direct publishing or tickets can be the simpler option. ## Pay For Results, Not For Hours Businesses buy the outcome, agencies resell it, and groas answers for it either way. [See If You Qualify](https://groas.typeform.com/to/xC1bQNUT) ## Structured data ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://graph.groas.com/entity/groas","name":"groas","url":"https://groas.com/","logo":{"@type":"ImageObject","url":"https://groas.com/icon-512.png","width":512,"height":512},"sameAs":["https://www.linkedin.com/company/groas/"]},{"@type":"WebSite","@id":"https://groas.com/#website","name":"groas","url":"https://groas.com/","inLanguage":"en-US","publisher":{"@id":"https://graph.groas.com/entity/groas"}},{"@type":"WebPage","@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#webpage","url":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t","name":"How to Ship AEO Fixes on Client Sites You Don’t Control","description":"For agencies, AEO stalls when fixes wait in a client’s developer queue. Compare tickets, CMS publishing, and edge proxies, then set up a workflow that holds across 15 domains.","inLanguage":"en-US","isPartOf":{"@id":"https://groas.com/#website"},"about":{"@id":"https://graph.groas.com/entity/groas"},"primaryImageOfPage":{"@type":"ImageObject","url":"https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/5218d411-f027-44ba-8d9c-fb351fc9d0a9.png"},"breadcrumb":{"@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#breadcrumb"},"dateModified":"2026-10-19T05:36:05.866Z","mainEntity":{"@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#article"}},{"@type":"BreadcrumbList","@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://groas.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://groas.com/blog"},{"@type":"ListItem","position":3,"name":"How to Ship AEO Fixes on Client Sites You Don’t Control","item":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t"}]},{"@type":"BlogPosting","@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#article","url":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t","mainEntityOfPage":{"@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#webpage"},"isPartOf":{"@id":"https://groas.com/blog#blog"},"headline":"How to Ship AEO Fixes on Client Sites You Don’t Control","description":"For agencies, AEO stalls when fixes wait in a client’s developer queue. Compare tickets, CMS publishing, and edge proxies, then set up a workflow that holds across 15 domains.","datePublished":"2026-10-19T05:36:05.801Z","dateModified":"2026-10-19T05:36:05.866Z","image":{"@type":"ImageObject","url":"https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/5218d411-f027-44ba-8d9c-fb351fc9d0a9.png"},"author":{"@id":"https://groas.com/author/alexander-perelman#person"},"publisher":{"@id":"https://graph.groas.com/entity/groas"},"keywords":"edge, cms, publishing, client, aeo, developer, change, cms publishing","wordCount":2003,"inLanguage":"en-US"},{"@type":"Person","@id":"https://groas.com/author/alexander-perelman#person","name":"Alexander Perelman","jobTitle":"Head Of Product @ groas","description":"My background includes Goldman Sachs and Stanford Computer Science.","image":"https://groas.com/media/blog/4f17cac3a81acc224cc1b2cfab8f94bbc295a3089d13e8421125771ef8d4064f.jpg","worksFor":{"@id":"https://graph.groas.com/entity/groas"},"sameAs":["https://www.linkedin.com/in/alexander-433793253/"]},{"@type":"FAQPage","@id":"https://groas.com/post/how-to-run-aeo-on-client-sites-you-don-t#faq","mainEntity":[{"@type":"Question","name":"Why do AEO recommendations take so long to go live on client sites?","acceptedAnswer":{"@type":"Answer","text":"The usual workflow hands the audit to a client contact, who passes it to a developer who did not ask for it and already has a backlog. The person who finds the fix cannot ship it, so recommendations often wait weeks or months. One often-cited agency figure says the majority of SEOs wait six months to see recommendations go live."}},{"@type":"Question","name":"What are the ways an agency can get a fix onto a client site it does not control?","acceptedAnswer":{"@type":"Answer","text":"There are three practical paths. You can send tickets to the client's developer, publish directly through the CMS via an API or plugin, or deploy through an edge proxy where a CDN worker rewrites the response after the CMS renders it but before a crawler receives it. The edge route can change titles, inject JSON-LD, set canonicals, and return 301s without deploying the client's codebase."}},{"@type":"Question","name":"When should an agency use an edge proxy instead of client developer tickets?","acceptedAnswer":{"@type":"Answer","text":"Past five client domains, an edge proxy is the better default because a change can go live and be rolled back without another request to the client's developer. Tickets are familiar but slow, and CMS access gets complicated when juggling many platforms and logins. Edge lets you operate a shipping path without asking permission for every fix."}},{"@type":"Question","name":"Does rolling back a Cloudflare Workers deployment undo everything?","acceptedAnswer":{"@type":"Answer","text":"No. Rolling back traffic does not undo writes to KV or R2 storage. The recommendation is to keep edge changes narrow, approved, and versioned rather than treating rollback like a magic eraser, even though one-click rollback to a prior deployment is available."}},{"@type":"Question","name":"How do you keep schema and entity information consistent across many client domains?","acceptedAnswer":{"@type":"Answer","text":"Give each client one entity sheet with its name, services, locations, and proof points, and treat every new page and schema block as a reflection of that sheet. 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, and in the CMS the fields feeding markup belong in the template rather than a pasted block."}},{"@type":"Question","name":"How do you publish content automatically for clients without creating an approval bottleneck?","acceptedAnswer":{"@type":"Answer","text":"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, publishing stops. No agreed approval rule means no automatic publishing, otherwise you have only replaced a developer backlog with an approval backlog."}},{"@type":"Question","name":"How can I verify that AI crawlers actually fetched my updated page?","acceptedAnswer":{"@type":"Answer","text":"Filter server logs for user agents like GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, and CCBot, then check status codes and response size, since a 200 serving a challenge page is not the same as a full body. Because a user agent alone can be faked, verify the request against published IP ranges or reverse DNS before counting it. Verified fetches with clean responses are the ship confirmation."}},{"@type":"Question","name":"When is an edge proxy not the right choice?","acceptedAnswer":{"@type":"Answer","text":"Skip the edge proxy when you have one cooperative developer and one CMS you already control, when enterprise security will not delegate DNS, or on a fragile checkout flow where another worker already rewrites responses, since stacking rewrites makes debugging difficult. In those cases direct publishing or tickets can be the simpler option."}}]}]} ```