Most agencies start AEO with a content calendar. I start with one About page and one block of Organization JSON-LD. If an engine cannot resolve who your client is, publishing more posts will not fix the foundation.

I learned the order from Google Ads. Great ad copy cannot rescue a campaign structure that mixes intent levels and splits conversion signal. Entity work is the account structure for AI answers: establish who the company is on one domain, then scale the content around it.

What you need and what you will ship

By the end, you will have one clear entity home page, one validated Organization block with sameAs links, and a logged baseline of five buyer prompts across ChatGPT, Perplexity, and Google AI Overviews. The page and markup go live on one client domain. The baseline goes in a sheet you can rerun.

Set aside about two hours. You need CMS admin access, the client’s legal name and founding facts, and URLs for its maintained profiles. If you do not have CMS write access, read Step 4 before you promise a launch date. A fallback still needs someone authorised to publish the change.

Step 1: Put the client’s identity in one sheet

Open a plain document or sheet. Give each fact its own row; do not accept a paragraph that makes you hunt for the actual value. Record:

  • legalName, name, alternateName, foundingDate, and founder.name
  • address, telephone, email, and areaServed
  • Three core services in plain words and a one-sentence description
  • Each maintained profile URL you might use in sameAs[]
  • The canonical entity home URL, usually /about/ or /about-us/
  • Business identifiers, such as DUNS, NAICS, or tax ID, if the client has them

The existing About page is usually the right entity home. Give its organization a stable @id that other schema blocks can point to. Google’s expanded Organization markup also accommodates business identifiers, but do not delay this job to chase an identifier the client does not have.

Expected result: one agreed value per field, with only genuinely unavailable identifiers left blank. You should be able to hand the sheet to another operator without an explanation of which company name is ‘the real one.’

Common mistake: accepting five versions of the name from the footer, Google Business Profile, LinkedIn, invoices, and the person replying to your email. Resolve the discrepancy with the client now. The sheet is where you make that call, not the JSON-LD editor at the end of the afternoon.

Step 2: Make the existing About page answerable

Open the entity home URL in the CMS and rewrite its first 150 words. Put the answers in this order:

  1. What is the company?
  2. Who does it serve?
  3. Where does it operate?
  4. What does it cost, or how does it charge?

Use one plain sentence per answer. Then add a short founder and history block, a services list in ordinary nouns, and a profiles section linking to the maintained profiles you selected in Step 1. Keep the company name consistent with the sheet. Cut the mission-statement paragraph if it pushes the actual description down the page.

I used to tell clients a good About page tells a story. I was wrong about what this page needs to do first. An entity home has to identify the business before it can tell its story. The top of the page should give a reader, or an engine, a sentence it can use without assembling clues from six other tabs.

Expected result: someone can read the opening and say what the company does and where it operates in one sentence. As a rough copy check, paste the URL into ChatGPT and ask, ‘In one sentence, what does this company do and where?’ A hesitant answer is a reason to inspect the page copy, not proof that one prompt has diagnosed the whole problem.

Common mistake: publishing a new /entity/ page that nobody links to. Use the existing About page if it is already the client’s established company page. The job is to make that page unambiguous, not to create another URL that needs its own explanation.

Step 3: Write one Organization block with a stable @id

Take the agreed facts from Step 1 and replace every placeholder in this snippet. Keep the @id shape tied to the canonical About URL. Use that same identifier when you link other schema blocks to the organization later. The fuller field-by-field process is in Build a Client Entity Graph in 90 Minutes, Then Reuse It Across 15 Domains.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://CLIENTDOMAIN/about/#organization",
  "name": "LEGAL NAME",
  "alternateName": "TRADING NAME",
  "legalName": "LEGAL NAME",
  "url": "https://CLIENTDOMAIN/",
  "logo": "https://CLIENTDOMAIN/logo.png",
  "description": "ONE SENTENCE: what the company is, who it serves, where.",
  "foundingDate": "2018",
  "founder": [{ "@type": "Person", "name": "FOUNDER NAME" }],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "STREET",
    "addressLocality": "CITY",
    "addressRegion": "STATE",
    "postalCode": "ZIP",
    "addressCountry": "US"
  },
  "telephone": "+1-555-0100",
  "email": "hello@CLIENTDOMAIN",
  "areaServed": ["CITY 1", "CITY 2"],
  "sameAs": [
    "https://www.linkedin.com/company/CLIENT",
    "https://www.crunchbase.com/organization/CLIENT",
    "https://www.wikidata.org/wiki/QXXXX"
  ]
}
</script>

Replace the example year, contact details, locations, and URLs; delete any field you cannot substantiate. name should match the name the client uses consistently on its site and maintained profiles. url is the full homepage URL, and logo is a full file URL, not a relative path. Use a four-digit foundingDate if that is all you know. Do not leave QXXXX in a live page because someone thinks a Wikidata entry would be nice to have.

Treat sameAs as a list of real matching profiles, not a link farm. Check each URL before you paste it. A maintained Wikidata entry, LinkedIn company page, Crunchbase profile, or relevant directory listing can be useful if it accurately identifies this client; the distinction between entity-data sources matters more than filling every slot in the example. Skip stale social accounts. Three checked links beat nine links to profiles nobody updates.

Expected result: one complete snippet whose page URL, @id, description, and profile links agree with the sheet and the About page.

Common mistake: copying the example whole. Placeholder addresses and unverified sameAs URLs make the graph less clear, not more complete.

Step 4: Publish to WordPress or Webflow without duplicating it

Before adding the snippet, inspect the live About page’s source for an existing Organization block. The goal is one consistent organization description, not two blocks that disagree about its name, logo, or identifier. Then take the route that matches the client’s CMS.

WordPress route

  1. Check Yoast SEO > Settings > Site representation or Rank Math SEO > Titles & Meta > Homepage for the organization name, logo, and social profiles. Check the resulting live source before adding custom markup.
  2. If the site needs the fuller custom block and you can avoid a duplicate, go to WPCode > Add Snippet > Add Your Custom Code > HTML Snippet. Paste the full <script type="application/ld+json"> snippet from Step 3, set the location to Specific Page: About when that option fits the setup, set priority to 10, and save.
  3. Open the published About page and view its source. Check the actual @id, not merely whether the snippet appears in the WordPress editor.

Expected result: the live About page contains the intended organization facts without a conflicting second block. Common mistake: leaving a plugin-generated block in place, adding another with different values, and calling the extra markup an improvement. A Gutenberg Custom HTML block can also render the script in the page body, but it is easier for a later editor to disturb. Check what the live page outputs either way.

Webflow route

  1. For head code, open Site Settings > Custom Code > Head Code or Page Settings > Custom Code > Inside <head> tag. Paste the complete script and select Publish (Webflow schema walkthrough).
  2. If you are adding markup through a page embed, use Designer > Add Element > Embed, paste the script, and publish. On a CMS collection page, put the Embed on the Collection Page template if it needs fields bound there.
  3. Open the published URL and inspect its source. Do not validate only the Designer preview.

Expected result: the published page contains the snippet with the client’s values. Common mistake: seeing code in Designer and assuming it reached the live page. Publication and source inspection are part of the step.

If you lack write access, hand the authorised publisher the page copy, snippet, and exact target URL. If you control an authorised edge layer for the domain, that can be the route instead; Onboard a White-Label AEO Client in an Afternoon Without Touching Their CMS covers that workflow. Do not mistake ‘no CMS login’ for permission to change a site by some other means. If publishing stalls, get the route and owner agreed before you spend another afternoon polishing code nobody can ship.

Step 5: Validate the live URL, then log the baseline

Paste the published About URL into Schema Markup Validator. Inspect the detected Organization, its @id, and its sameAs values. Then run the same live URL through Google’s Rich Results Test to see what Google reports for the markup it supports. These tools answer different questions. Valid schema is not a promise of a citation, and an empty rich-results report does not by itself mean the Organization JSON-LD is absent.

Expected result: no syntax errors in the organization block, with the intended values visible in the live output. Fix broken JSON and wrong URLs before debating warnings. Common mistake: testing a draft or editor preview, then treating that result as proof about the published page.

Now write five real buyer prompts for this client: one categorization prompt, one problem prompt, one comparison prompt, one brand prompt, and one pricing prompt. Run the same wording in fresh sessions across ChatGPT, Perplexity, and Google AI Overviews. Log Named / Cited with URL / Position / Tone for each answer and save the exact prompt text beside the result.

Practitioners doing a broader audit run 25 to 40 prompts and repeat them weekly for a month. Five prompts are not that audit. They are a baseline you can finish today and rerun in 14 days. If the client is not named anywhere, keep the blank cells. They are the measurement, not an invitation to improve the spreadsheet’s mood.

Expected result: a saved sheet that lets you compare like with like in two weeks. Common mistake: changing the prompt wording on the second run, then calling the different answer progress.

Step 6: Repeat the method, not the manual copying

Once the first domain is live, separate what you can reuse from what still needs judgment:

  1. Template: copy the input sheet, JSON-LD structure, and five-prompt baseline sheet. Replace the client values; never carry placeholder facts into the next domain.
  2. Judge: settle the legal-name choice, write the one-sentence description, and remove dead or mismatched sameAs links. Do not automate those calls just because the fields look tidy in a spreadsheet.
  3. Automate: handle repeat publishing, post-change validation, and prompt logging where your access and workflow allow it. That is the pile that grows when you have ten client domains instead of one.

The first domain takes about two hours; the tenth should be closer to 25 minutes if your inputs and publishing route are ready. The aim is not to spend less time deciding who a company is. It is to stop rebuilding the same sheet and checking the same settings from scratch. Expected result: each new client gets its own verified facts and live output, using a repeatable process. Common mistake: copying the previous client’s @id or profiles along with the template.

That repetitive pile is why I stopped treating entity maintenance as a weekly tour of CMS logins. Under groas for agencies, content, technical fixes, and citation work run per client domain and report under your brand. Keep the judgment calls and the client relationship; put repeat execution where it belongs. If you are still opening ten CMSs every Friday to perform the same checks by hand, you are billing 2015 hours for work that no longer takes 2015 effort.

Rerun the exact five prompts in fresh sessions and compare them with the baseline. Look first for more specific answers: the client’s agreed name, city, and service wording instead of a vague description. Then check whether an engine names or cites the client where it did not before. One changed answer is a signal to investigate, not a victory lap.

Once the entity home is live and the comparison gives you a reason to continue, make the rest of the site point back to it. Link service pages and author bios to that URL using the same company name. That is the first change to make before scaling the content calendar: let the site reinforce the identity the About page and JSON-LD already state.