Most writing about answer engine optimisation explains what AEO is. This is the other thing: the specific edits to make to a community page, in the order worth making them, and how to tell afterwards whether any of it worked.
If you want the strategic case for why this matters, the AI Overview click data is here. This post assumes you are already convinced.
1. Put the answer in the first sentence of every section
The single highest-return change, and it costs nothing but editing.
Answer engines extract the opening clause under a heading. A paragraph that sets up context before answering gets quoted saying nothing useful, or gets skipped entirely.
Go through your top ten organic search pages and rewrite the first sentence under each H2 so it stands alone. The test: could this sentence be pasted into a chat answer, with no other sentence, and still be true and useful?
2. Make headings the questions people actually type
Replace Our Memory Care Difference with What does memory care cost in [city]?
The second one matches a real query, and the model is looking for a question it can map an answer to. Marketing-voice headings are invisible to it.
Pull the actual questions from three places, the same ones that feed good keyword research: your Search Console query report, the People also ask box for your main terms, and the questions your sales counsellors get asked on tours. The third source is the best one and nobody uses it.
3. Add FAQPage schema, with real answers
Question-and-answer pairs in machine-readable form are the closest thing to handing an answer engine a quote.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "What is the difference between assisted living and memory care?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Memory care is a secured environment with staff trained in dementia care and higher staffing ratios. It typically costs 20 to 30% more per month than assisted living in the same market."
}
}]
}Two rules. The answer text must match the visible page text; mismatches get the markup ignored and can earn a manual action. And use <details> or plain markup rather than a JavaScript accordion, so the answer is in the DOM whether or not it is expanded.
4. Fix entity consistency before anything else
A model has to know what you are before it can recommend you. Three sources have to agree:
- Your page copy: who you serve, where, what care levels (what a citable community page contains)
- Your Organization or LocalBusiness schema: name, address, phone, area served, care types
- Your local listings: Google Business Profile, Apple, Bing, and the aggregators
Contradictions between these are the most common reason a well-written page never gets cited. A community whose site says memory care and assisted living while its Google Business Profile category says nursing home is telling the model two things, and the model resolves the conflict by trusting neither.
This is unglamorous, and it is where local listing hygiene stops being a checkbox exercise.
5. Give every number a named source and a date
Answer engines prefer sources that cite sources. An unsourced claim is a liability the model routes around; a figure with an origin and a date is quotable.
Senior housing occupancy reached 89.9% in Q2 2026 (NIC MAP).
That sentence can be lifted. “Occupancy is at record highs” cannot.
This is the largest open opportunity in senior living content, because the category is almost entirely assertion. It is also why we publish our method and its weaknesses rather than a claims list.
6. Use tables for anything comparative
Costs by care type, staffing ratios, amenities by floor plan. Tables are unambiguous to parse and get lifted whole. Prose comparisons do not.
Make sure they scroll rather than overflow on a phone, because a table that breaks the layout gets fixed by deleting it.
7. Publish an llms.txt
A short plain-text file at your root describing what the organisation is, what it does, and where the important pages are. Adoption is still limited and no engine guarantees it is read, so treat it as cheap insurance rather than a lever. Half an hour of work, no downside.
What to check afterwards
Ranking reports will not tell you whether this worked. Four things will.
| Signal | What it tells you | Where |
|---|---|---|
| Branded search volume | You are being cited and named | Search Console |
| Impressions holding, clicks falling | The AI Overview effect, not a ranking loss | Search Console |
| Direct citations | Ask the engines your own questions, monthly | ChatGPT, Perplexity, Google AI Mode |
| Tour requests | The only number that survives every algorithm change | Your CRM |
That third row is a real task, not a metaphor. Once a month, ask the answer engines the ten questions a family in your market would ask, and record whether you appear. It takes twenty minutes and it is the only direct measurement available.
The order that matters
If you do only three of these, do 4, 1 and 3, in that order. Entity consistency first, because nothing else works while the model is confused about what you are. Then answer-first sentences, because it is free. Then FAQ schema, because it is the highest-yield markup available.
What this will not do
It will not restore the organic traffic that AI Overviews absorbed. That traffic is gone, and any agency telling you otherwise is selling something.
What it does is change who gets named in the answer, and the demand that follows a citation is smaller, warmer and closer to a tour. That is a worse top line and a better business, and it is worth being clear about the trade before you start.