Onboard a White-Label AEO Client in an Afternoon Without Touching Their CMS

Most agencies put a new white-label SEO client in a queue for developer time. I used to do it too. For a client site that can be served through an edge proxy, that wait is often the wrong first move: you can publish structured content and technical fixes without changing the CMS codebase.

By the end of this afternoon, you will have one client domain routed through a working edge proxy, crawler access checked, a buyer-prompt set and dated visibility baseline saved, three pages of first fixes published, and a white-label report ready to send. The prompt set is the real work. The route only earns its keep if you know which buyer questions the pages need to answer.

Before you start: secure access and a working route

This is not an afternoon project if nobody can change DNS or the edge worker does not yet serve the client’s origin site. Settle those dependencies first. You do not need CMS admin access, FTP or a theme edit, but you do need a way to inspect what the worker serves before you publish a rewrite.

• DNS access, or a named contact who has it. Know who can approve the hostname changes. Do not discover that person at 4pm.
• An edge worker ready to serve the client hostname. Have the worker or template in place before you add its domain route. Adding a hostname is not, by itself, a content rewrite.
• The Google Business Profile name, address, phone and hours, copied exactly. You will use these when you add local business data.
• Five real buyer questions. Get them from sales calls or search terms, not a generic keyword list.
• A destination for the branded report. Decide where the client-facing export goes before the first reporting day becomes a screenshot scramble.

If one of the first two items is missing, fix that before starting the clock. The point is to avoid a developer ticket on the client’s CMS, not to pretend that a proxy works without access or configuration.

Step 1: Route both hostnames through the edge proxy

Open Cloudflare and go to Workers & Pages > select Worker > Settings > Domains & Routes > Add > Custom Domain. Add the client hostname to the worker that serves the origin site. Cloudflare can create the DNS records and certificates for a custom domain, but you still need to confirm that the worker returns the client’s pages. For client.com, account for both client.com and www.client.com as separate hostnames, then redirect one to the other.

The worker sits between the request and the CMS response. That is where edge SEO can rewrite served HTML for titles or JSON-LD, or handle redirects and robots.txt, without editing the origin code. A route is not proof of a working proxy. Open client.com/pricing and www.client.com/pricing separately. Confirm that each reaches the intended page, that the content still looks right, and that the request appears on the worker route or in its edge log. If you use a response header to identify the worker, confirm that it is actually configured before relying on it.

Expected result: the client page serves through the worker, with no unintended visual change, and both hostname variants resolve as planned. The common mistake is testing the apex and forgetting www. An exact hostname mismatch can leave one version failing while the other looks fine. Fix the route or redirect now, before adding content changes. For the longer click path, keep the edge-proxy walkthrough beside this step.

Step 2: Check crawler access before writing answers

Open client.com/robots.txt. Read the rules that apply to the pages you intend to fix, then check the edge log for fetches. For this first pass, inspect access for Googlebot, OAI-SearchBot and PerplexityBot. Do not treat every AI-named bot as the same thing: search access and model-training controls are different decisions. Check the search crawlers relevant to the visibility you plan to measure rather than changing training-bot rules as a shortcut.

If the client intends to allow these crawlers on the relevant pages, the rules you are checking for have this shape:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Googlebot
Allow: /

Expected result: robots.txt does not block the intended pages, and the edge log can show page-level requests when those crawlers visit. An allowed rule is not a verified fetch. Do not promise a visit within an hour or mistake your own browser test for one. Check the page-level record in the verified-crawler report before telling the client a crawler saw a changed page.

While you are here, open sitemap.xml and remove dead URLs from the list you submit. The mistake at this step is running a third-party bot checker, seeing a green light and calling access proven. The practical order is simpler: check the rule, check the served page, then check the log. If there is no verified fetch yet, report access as checked and the fetch as pending. Do not turn a permission into a citation claim.

Step 3: Spend the afternoon on buyer prompts

Open the client’s last 30 days of paid search terms, the last five lost-deal notes and the Google Business Profile queries. Put the five questions you collected before starting beside them. Pull out the language buyers use when they compare options, ask about cost or narrow a local search. Draft prompts in the client’s actual category, using patterns like these only where they fit:

best [category] for [use case]
how does [product type] work
[service] near me open Saturday
how much does [service] cost in [city]

Start with 10 to 15 evaluation questions if that is what the evidence supports. Build toward 15 to 20 prompts for the first main offer, weighted toward consideration and decision questions because those are the comparisons this first round of fixes is meant to address. Keep local variants where city or near-me language changes the question. For a local client with emergency plumbing and drain replacement as separate services, build a set for each rather than pretending one generic list covers both.

Give the sheet four columns: prompt text | stage | local intent Y/N | engine. Put one question on each row. Name the category and city where they matter, and label the engine you will test. Review the set every 30 to 60 days, but do not wait for that review to remove a question nobody would ask on a sales call.

Expected result: a small set you can read aloud to the client and use to choose pages. The common mistake is filling a tracker because it has room. Otterly’s agency tiers list 100 and 400 prompts; that is a capacity comparison, not a reason to manufacture 100 questions. Twenty prompts tied to buying decisions give you a clearer first job than 200 prompts you cannot act on. Spend the time here. The proxy will not tell you what the buyer needs answered.

Step 4: Save the baseline before shipping a fix

Paste the prompt set into the tracker and run the first read across the engines you selected. Use the same logged-out setup for the initial pass, then record the result for every row: cited Y/N, competitors that appear, and the client URL cited, if any. Date the sheet and save it before changing a page.

Do not read the output like a conventional position report. Answers can vary by session, context and time. A single answer is a snapshot; repeated competitor appearances across the set give you a more useful clue about which questions need work. Look for prompts where a competitor appears and the client’s relevant page does not. Those are candidates for the first three fixes, not proof that a particular rewrite will produce a citation.

Expected result: a dated record of where the client is cited and absent, including the URLs and competitors you observed. Do not expect a preset number of citations. The mistake is changing a page, rerunning its prompt once and calling the difference a win. Save this first read unchanged, then compare a later full-set run against it. Without the pre-fix sheet, you can show activity, but you cannot show the client what changed from the starting point.

Step 5: Publish three complete page fixes at the edge

Pick three pages that match prompts where competitors appeared and the client did not. On each page, use the worker to publish a direct answer near the top, add a JSON-LD payload, and correct the local business facts to match the Google Business Profile. Start the answer with the buyer’s question phrasing and keep it to roughly 40 words. The job is to make the answer easy to find on the served page, not to bury it under another introduction.

For a local client, the LocalBusiness data you prepare should use the matching name, full address, phone, URL, hours, geo-coordinates and service descriptions. Add FAQPage, Service or BreadcrumbList JSON-LD where the page calls for it, and check the markup you publish in the Rich Results Test. This is a starter shape, not the finished data for every client; replace the brackets and check the served result:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "[GBP NAME EXACT]",
  "address": "[STREET, CITY, ZIP EXACT]",
  "telephone": "[PHONE EXACT]",
  "url": "[CANONICAL URL]",
  "openingHours": "[Mo-Fr 08:00-18:00]"
}

Inspect each served page after the worker rewrites the CMS response. Confirm that the direct answer appears, the business facts match the client’s listing, and the intended JSON-LD is present and passes the relevant check. Record one row per URL as URL | fix shipped | validator pass Y/N; note any failed check instead of marking the page done.

The choice here is three complete pages, not ten shallow ones. I would rather show a client the question, the answer on the served page and the corresponding markup than hand them a pile of articles. White-label AI SEO is not improved by treating output volume as the deliverable. Log the fix per page. Otherwise next week’s report cannot connect an action to the URL it changed.

Expected result: three served pages you have inspected, with each change recorded and the structured data checked. The mistake is validating the JSON-LD but never opening the page through the proxy. A passing markup check does not tell you whether the answer reads cleanly or whether the wrong hostname is serving it.

Step 6: Make the white-label report forwardable

Set up the branded weekly export before you log off. Use the agency’s logo and report destination. Keep it to three things a client can check quickly: prompts where the client was cited, fixes shipped with their URLs, and verified crawler fetches where the log has them. If a crawler has not fetched a changed page yet, leave that status pending rather than dressing an access check up as a visit.

Expected result: a test report you can forward without rewriting it. The mistake is leading with rankings when the work you just did was built around buyer questions, citations and served-page changes. Show the client what you checked, what you published and what the baseline says. That is a more useful account of the afternoon than a screenshot of a position moving from 11 to 9.

Pre-launch checklist: do not skip the baseline

Keep this list open for the first domain and reuse it for the next. Run it in order before calling the launch complete. The proxy is forgiving; a missing route or missing baseline is not.

1. Apex and www serve the intended page through the proxy. Confirm the redirect direction rather than assuming both hostnames work.
2. robots.txt permits the intended money pages for the search crawlers you checked; record verified fetches separately.
3. sitemap.xml does not list dead URLs.
4. Google Business Profile name, address and phone match the published LocalBusiness data. Check the details on the served page, not just in your draft.
5. The buyer-prompt sheet contains prompt text | stage | local intent Y/N | engine for the first offer.
6. The baseline is dated and saved before the fixes ship. Skip it and you lose the clearest way to show what changed; no polished Friday report can recreate a pre-fix read.

Verify the launch, then change the questions

Before you call the domain live, open both hostnames again, inspect the three changed pages through the worker, check robots.txt, and confirm that the baseline date precedes the fix log. Check the edge log for crawler fetches, but keep any that have not happened yet marked as pending. Verify the served changes; do not claim a crawler visit you have not seen.

Next week, rerun the full prompt set. Keep the questions where competitors still appear and the client’s relevant pages are absent, then choose the next three pages from that pattern. Change the prompt set when it stops reflecting how buyers choose. Do not rebuild the proxy because a single answer moved. That repeatable loop is the white-label AEO playbook: the plumbing stays put, and the questions get sharper.