Your First 90 Days of AEO: A Practical Roadmap

Before day one: name the pilot and its decision

A first programme should answer a management question as well as improve content. For example, an illustrative service business might ask whether clearer eligibility guidance can reduce unsuitable enquiries. That is more actionable than asking whether the company can become visible everywhere. Define the audience, the question family and the pages likely to contain the answer. Also name the decision the final review will support: expand to another service, maintain the current scope or redirect effort. A pilot without a decision can accumulate observations indefinitely without changing what the organisation does.

Reserve time from the people who own the facts and the website. A writer cannot resolve eligibility conditions alone, and a marketing lead may not be able to fix access problems. Agree who approves factual changes and who handles deployment. The AEO strategy guide covers those choices before scheduling begins. Ninety days is an illustrative planning window, not a universal optimum. A small site may finish useful work sooner; a regulated or complex organisation may need longer approval cycles. Keep the sequence of learning, delivery and review even when the calendar changes.

Days 1–15: establish the starting evidence

Read the existing pages as a prospective customer would. Can the person identify who the service is for, what is excluded and how to proceed? Record contradictions, missing conditions and broken supporting links. Gather the recurring questions from support and sales, preserving customer wording without exposing personal information. Create a content inventory for the bounded area rather than cataloguing the whole organisation if that would delay the pilot. The inventory should identify the current owner and role of each page, including documents that contain important facts but are difficult to discover.

Capture baseline website measures and a small set of answer observations before editing. Keep the query, date, product context and cited destination with each observation. Do not select only questions that already produce favourable responses. Separate missing citations from incorrect statements. Also inspect basic access: Google distinguishes discovery, indexing and serving, so an absent answer link alone cannot identify the problem. The opening period should produce a concise account of what is known, what is broken and what remains uncertain, rather than a large score whose components nobody can explain.

Days 16–30: turn findings into a bounded delivery plan

Choose the questions that matter most to the pilot and can be answered with available evidence. For each, decide whether to revise an existing page, consolidate overlapping pages or create a distinct destination. Avoid making new content the default. A service page with one buried exclusion may need a focused correction, while an unclear application process may need a proper walkthrough. The content brief guide helps define the answer, evidence and scope. Include the condition that would make the draft unacceptable, such as omitting a prerequisite that changes eligibility.

Set completion criteria that the team can actually meet. A reader should be able to identify eligibility, locate the relevant evidence and choose the next action without guessing. A developer should be able to demonstrate that the public page loads and the intended navigation reaches it. An editor should be able to trace factual claims to their owners. Google’s content guidance asks whether the audience can achieve its goal. Use that reader-centred standard as a delivery test, while keeping external answer inclusion outside the team’s list of guaranteed outputs.

Days 31–60: publish substantial improvements

Work through the selected pages in a sequence that respects dependencies. Correct the source policy before rewriting a summary that depends on it. Establish one clear destination before adding links from supporting pages. Have the factual owner review the conditions and exceptions, then have an unfamiliar reader try the intended task. The review should catch practical misunderstandings, not just spelling errors. For the illustrative service pilot, ask the reader to decide whether a described customer is eligible and explain which sentence supports that decision. Their reasoning can reveal ambiguity that a routine proofread misses.

Record each substantive release in a change log with the affected URL and reason for the change. Preserve stable destinations where possible and check links after deployment. The technical release checklist covers the publishing checks, while content refresh workflow addresses ongoing revisions. Avoid making unrelated redesigns during the pilot unless they are necessary, because they complicate interpretation. If an urgent change must happen, record it. The aim is not laboratory purity at the expense of business needs; it is enough transparency to understand what the site experienced during the observation period.

Days 61–75: inspect use and resolve real defects

After publication, inspect whether the intended pages and supporting material are reachable and current. Repeat the same reader tasks and question observations under comparable conditions. Open citations to see what claims they support. A new link is useful evidence of appearance, but it may still point to an obsolete page or accompany an inaccurate summary. The prompt tracking guide explains how to preserve a comparable question set. Resist rewriting a good page after every unfavourable answer. First establish whether the response reveals a genuine information defect or merely differs from another observation.

Use support and sales feedback carefully. If colleagues report fewer confused enquiries, ask what period and examples support that impression. If an analytics trend changes, check demand, campaigns and tracking changes before attributing it to the pilot. Small samples may be informative without being conclusive. Record the uncertainty in plain language. The AEO experiments guide offers stronger methods when a specific causal question matters. At this stage, fix clear errors promptly, but preserve the evidence needed to distinguish the original pilot changes from later corrections and unrelated business activity.

Days 76–90: decide what earns another cycle

Prepare the review around three questions: what information improved, what readers and the business experienced, and what external answer observations showed. List completed work separately from outcome measures. Include remaining defects and the maintenance responsibility for each important page. A pilot can produce a valuable source asset without showing a measurable citation change during the window. It can also produce more appearances without improving enquiry quality. Neither result should be disguised. The purpose of the review is to decide where another unit of effort is justified, not to make every indicator point in the same direction.

Expand where the organisation has another important question family and credible evidence to support it. Continue maintaining pages that now solve the original task. Pause activities whose cost exceeds the information they provide, such as broad monitoring that never informs a decision. The AEO reporting guide helps make the review useful to stakeholders. Finish the first cycle with a small next backlog, named owners and a clear reason for each item. That leaves the organisation with a repeatable publishing capability and an honest account of what the first 90 days did and did not establish.

Sources and further reading

• Google: how Search worksCrawling, indexing and serving are separate stages, and inclusion is not guaranteed.
• Google: people-first contentGoogle asks whether content helps an intended audience and rejects a preferred word count.