Our homepage has a question for this: "Will Brandilite implement fixes or only recommend them?"
Someone about to pay a monthly fee deserves a straight answer to that. Let's use it to look at what our website needs to say. You'll probably recognise a question of your own along the way.
What does "we'll handle it" actually mean?
Here's our answer in ordinary language. Brandilite makes approved changes where the available platform access allows. When a client's developer needs to do the work, the plan includes specifications, implementation notes and QA. Larger migrations and custom development need a separate scope.
That last bit belongs in the answer too. Someone moving a large website has a different job in mind from someone asking for a service page rewrite. They shouldn't have to discover the difference after choosing a plan.
Say you want help with a page. Here's a brief you could send us:
Can you write the new page and add it to our website? We have a developer. Tell us what you'll need from them and who checks it before it goes live.
Compare it with "we offer technical AEO and content optimisation." There's nothing wrong with those service names, but they leave the buyer doing the translation. Does content optimisation mean a paragraph of advice in a spreadsheet? A rewritten page? Someone making the change in the CMS?
The answer needs to be on the page where you sell the work. A person reading it should be able to tell what the fee buys. A search tool has a better source to work from when you have explained that plainly, though you still don't get to choose whether it uses your page.
For your business, the question might be about delivery, importing old records or which parts of a service cost extra. Keep the awkward detail. That's often the detail the buyer came for.
Your homepage has enough to do
We wouldn't turn the homepage into a contract. A short answer there can point to the AEO service page, where someone can read what the work covers and where the limits are.
The methodology page has a different job. A buyer should be able to follow what happens to a finding: someone proposes the change, the client approves it, the change gets made and someone checks the result. If the client's developer is involved, this is the place to explain how the work gets handed over.
Then there's pricing. "Implementation included" is a little too easy for two people to read differently. The plan needs to say which work is included and what still needs a separate agreement. Link to that detail from the service page, while the person is wondering about it.
Read those pages in that order. If you have to open five tabs to work out who will touch the website, the explanation needs work.
This is also why the answer isn't always another blog post. A buyer looking at your service page may never reach the article where you finally explain the service. Fix the page they're already on.
Google's content guidance asks whether a page offers original information or analysis and helps its intended reader. Who does the work, what you need from a client, what costs extra: you know these things about your business. Another writer summarising ten articles about AEO doesn't.
If the text is clear but a search tool cannot receive it, you have a different problem. Our technical checklist covers login screens, missing text and settings that can get in the way.
"Show me the page you changed"
For someone buying implementation, that would be a fair thing to ask.
A useful example could show the original wording, what needed changing and the revised page. "We improved the content" doesn't tell a buyer much. "The page named the service but never explained what the client had to supply" tells them something they can look for on their own site. A labelled sample is fine for showing that kind of thinking.
Our case studies give readers reported work to inspect. When you read one, look for the dates and what was measured. A change in a visibility metric doesn't, by itself, tell you who wrote a particular page or how many sales followed. The case needs to supply those details if it's making those claims.
The same goes for screenshots. A lovely screenshot can show the design. It can't tell you that the page brought in enquiries unless there's something else to support that claim.
Some checks take you away from your website. Perhaps a partner still links to an old product, or a company profile describes a service you stopped offering. Correct it because a prospective customer could be reading it. Whether an AI answer picks up the change next Tuesday is a separate question.
If you're answering a community question yourself, say you work for the business and answer the actual question. You can explain the work better than a fake customer saying you're brilliant.
A mention can still get you wrong
Let's go back to the question about implementation.
"Does Brandilite make the recommended changes?" checks the description of our service. "Which AEO agencies help implement website changes?" asks a tool to find possible providers. We would save those as two different questions. Getting a good answer to the first wouldn't prove that buyers had found us through the second.
Read the replies. A tool might name Brandilite and describe us as an agency that only advises. That would be a mention with the wrong explanation. It might describe the implementation work correctly but use a different site as its source. Or it might link to our service page without recommending us at all.
You'd want to know which of those happened before celebrating the green tick on a dashboard.
Save the answer and its links, along with the question, tool and date. Include the market and search mode you used, and whether the account had any relevant personalisation. Otherwise, the next person may get a different reply and have no idea what changed. Our measurement guide explains the distinction between mentions and citations in more detail.
For a page edit, keep a note of what changed and when it went live. Repeat the questions under comparable conditions afterwards. A handful of saved replies is more useful than your memory of what the tool "used to say."
You can check platform reports as well. Google's Generative AI performance report shows impressions for supported AI features, with views such as pages and countries. It may not appear when a site has too few impressions. Bing AI Performance shows citations and cited pages within its coverage.
For Brandilite, we'd still want to know if someone needed help changing a real page, or was just looking for a free definition of AEO. Both people could visit the same article. Neither of those platform reports will sort them out for us.
An optional "How did you hear about us?" field can help with that conversation. Leave room for an untidy answer. Someone may have seen your name in an AI reply, read a case study and come back through Google a week later.
Where we'd start
Pick one service you want to sell and the question someone asks before buying it. Read the relevant page with that question in mind. Where does the answer stop short?
For our example, we'd want the implementation explanation and the plan detail to agree. We'd also want an example of the work for a buyer to inspect. Those are actual page decisions you could assign to a writer, a developer and whoever approves the work.
If a 90 day calendar helps you organise it, use one. Spend the early part on the answer and any access problem, then add the missing examples and correct outdated information. Leave time to read the later replies and enquiries. Review changes as they go live; you don't have to wait for the end of the quarter to spot a broken link or a paragraph that still ducks the question.
