SEO, GEO and AEO: defining the scope of work

Start with the question the customer needs answered

SEO, GEO and AEO are labels used for overlapping kinds of search work. A useful buying decision starts with the problem: an important page may be inaccessible, a product fact may be inconsistent or an answer may omit the brand. These cases require different evidence even when a supplier puts them under the same service name.

Write the customer question and the business consequence before asking for a package. If the site cannot receive a qualified enquiry, an additional citation is not the immediate constraint. If the offer is described incorrectly across official sources, a content rewrite on one page may leave the underlying contradiction unresolved.

Separate site work from answer observations

Technical access, indexable content and a clear site structure support ordinary search eligibility. They also matter to search-backed answer features, but eligibility does not promise selection. Google states that established SEO practices remain relevant to its AI features; a supplier should not sell an unsupported special technical requirement as a guaranteed route into an answer.

Answer observations need their own collection record. Preserve the prompt, product or engine mode, date and linked sources. A mention, a recommendation and a citation are separate events. An answer produced without visible web retrieval should not be combined uncritically with a search-enabled answer as if both measured the same source mechanism.

Agree what the first handover contains

A technical scope can produce reproduced defects, affected URL groups and acceptance checks. A content scope can produce a decision brief, sourced draft and review record. A monitoring scope can produce a defined prompt sample and dated captures. Ask the supplier to identify the working file behind each promised output and the access needed to produce it.

The same work can support several channels without being counted several times. Correcting an official product specification is one change; later observing that specification in an answer is a different measurement. Record both, keeping implementation completion separate from any resulting traffic, ranking or answer appearance.

Choose a bounded test and retain the unknowns

Begin with a page population or question set small enough to inspect. Define what would count as a successful implementation before work starts: correct responses, consistent facts, usable navigation or a complete observation record. Set a later review point for outcomes that depend on external systems.

Do not make model selection or citation frequency an acceptance check for a code change. The provider can commit to a method and a deliverable, while an engine retains control over its answers. Leave unavailable account features, commercial terms and collection limits explicit in the brief rather than assuming the label includes them.

Example decision register

Illustrative rows explain how to use the worksheet. Bracketed entries are intentionally blank inputs; these are not client records or measured results.

Use the blank worksheet

1. Choose one real decision and replace the blank fields with evidence you are authorised to use.
2. Name the source and owner for each factual statement. Keep unresolved assumptions visible.
3. Agree an acceptance check before commissioning the change, then retain the result beside the original observation.

Common questions

Sources and editorial boundary

This guide proposes a working method. Its examples are illustrative and do not claim a completed client engagement. Commercial terms and individual author or reviewer details remain subject to confirmation.