SEO, GEO and AEO audit: from URL evidence to decisions

01 / Start with a decision

A useful audit does not produce an endless issue list. It determines which pages deserve repair, deeper content, consolidation or no immediate change. First define the market, language, offer and desired user action. A German service page serves a different task from an English introductory article.

Separate three layers: technical accessibility, content reliability and business usefulness. A reachable page can contain weak information. An excellent article can sit behind a login. A frequently cited explanation can attract people who will never need your offer. Combining all three layers turns an audit into a useful investment decision.

02 / Define the sample and evidence boundaries

Export URLs from your own sitemap or CMS. Add page type, language, topic, last subject-matter review and intended action. Begin with a representative sample: one core service, an industry page, a pillar, a supporting article and a resource. Expand the sample when a template-level problem appears.

Record date ranges, filters and permissions for every export. Search Console data is not the same as all website visits. Missing access is an audit limitation, not proof of missing visibility. When examining public HTML only, explicitly state that server logs, indexing status and actual conversions were not assessed. This keeps the report useful for subsequent technical reviewers.

03 / Check accessibility reproducibly

Open the complete URL without signing in. Record its status code, redirects and final address. Inspect robots.txt for the relevant crawler, then inspect meta robots and any X-Robots-Tag response header. These controls serve different purposes. A robots.txt rule is not a dependable substitute for an indexing directive.

Next inspect both the original HTML source and the rendered page. Are the H1, core answer, important paragraphs and internal links present? If content appears only after JavaScript runs, document that dependency without automatically concluding that crawling is impossible. For restricted private previews, the correct finding is “not publicly verifiable,” rather than “fully indexed.”

04 / Audit the task rather than keyword density

Write one user question and one suitable next action for every page. For example, “How should procurement evaluate maintenance software?” calls for an assessment matrix rather than an immediate generic demo request. Check whether the page answers with criteria, limitations and a concrete example.

Group terminology by meaning and decision stage, not a required repetition count. When two pages answer the same question for the same audience, examine overlap. Different user intentions can justify separate pages. Nearly identical copy with a substituted industry name offers little additional usefulness. Consolidation requires a clear destination page and an owner for redirects and internal-link updates.

05 / Inspect claims, sources and limitations

Mark every verifiable assertion: product capability, metric, comparison, legal statement or technical promise. Link a reliable primary source or approved internal documentation. Record its date and scope. When evidence is missing, qualify the statement, label it as an assumption or remove it.

An author byline alone does not establish expertise. Check that the named person actually owns the content and that an update process exists. Never invent credentials, customer outcomes or sources. For comparison tables, record the product versions reviewed and any criteria that could not be verified. Readers must be able to distinguish observed facts, illustrative assumptions and your recommendation.

06 / GEO and AEO without false promises

Place the core answer immediately below the relevant subheading. Add definitions, transparent tables and questions drawn from real sales or support conversations. This makes information easier for people and extracting systems to understand, but does not guarantee a mention in a language model.

Google describes no additional special optimization requirements for its AI search features beyond fundamental search requirements. That does not establish identical behavior across other providers. Inspect access controls separately for each provider and keep observations distinct. A manual prompt sample is a snapshot tied to a model, language and date; it is neither a complete market-share measure nor a stable ranking. Prioritize usefulness and evidenced answers.

07 / Check structured data and media

Read existing structured data and compare it with visible content. Names, URLs, author, language and service descriptions must match the page. FAQ markup must not contain questions missing from the visible page. Technically valid data does not guarantee enhanced search presentation.

Assess images for their informational role. Descriptive alt text explains relevant image content; decorative elements do not need a keyword list. Charts also need a clear textual explanation so their meaning remains understandable without the image. PDFs need a meaningful title, a logical structure and readable text. Record any accessibility or PDF-tagging checks that were outside the scope of your assessment.

08 / Fictional case: three pages, three decisions

The following case is entirely fictional; all figures and findings are teaching assumptions. Nordlicht Systems examines a service page, a guide and a PDF resource. The service page contains accurate copy but its inquiry journey fails. The guide includes an unsupported efficiency comparison. The PDF contains useful tables but can only be reached through an image button without meaningful link text.

The team assigns technical and editorial tasks separately. It repairs the inquiry journey first, replaces the comparison with verifiable criteria next, and adds a clearly named resource link. It does not automatically commission three new pages. The audit first improves existing assets and prevents new content from inheriting the same faults.

09 / Prioritize with explicit rules

Use P0 for a current blockage of a business-critical journey, P1 for substantial content or decision-quality errors, and P2 for later improvements. These labels are an internal working model, not an official search-engine standard. Also record the scope of the issue, confidence in the evidence and dependencies.

A small template defect can affect hundreds of pages and needs different planning from a weak phrase on one page. Still, do not prioritize blindly by URL count. A blocked central contact page can matter more than many decorative image descriptions. Give every task a testable result, a named owner and a due date. When effort or effect is unknown, commission a bounded investigation first.

10 / Maintain an audit trail and retest

For every finding, save the URL, time, method, observation and expected change. Separate screenshots from interpretation. A screenshot may prove a visible fault without establishing its cause. Link technical tickets rather than maintaining diverging solution descriptions in several documents.

After a repair, repeat the exact original check. Also inspect at least one unaffected page using the same template to identify side effects. Keep the before and after states. A fix is complete when its stated acceptance criterion passes; a hoped-for future ranking improvement is not an immediate functional verification.

11 / Run a bounded audit sprint

Allow half a day for sample selection and access checks, a day for the representative review and a joint interpretation meeting. These timings are a planning suggestion for a small first pass, not a general effort guarantee. Large websites and complex applications require their own scope.

In the review meeting, begin with three evidenced findings and their resulting decisions. Then determine which patterns need checking across additional pages. Finish with a small repair package, a subject-matter content assignment and a retest date. A sprint succeeds when the key decisions become clearer and next actions executable, even when every URL has not been reviewed.

12 / Measure outcomes without hiding uncertainty

After publishing, inspect functional evidence first: can pages be reached, is content complete, and can inquiries be handled? Then examine search data and actual inquiries over consistent date ranges. Note concurrent campaigns, seasonality and product changes. A change occurring after the audit was not necessarily caused by it.

For manual AI queries, save the question, system, language, date and displayed sources. Repeat a small fixed sample instead of collecting only favorable appearances. Show variation honestly. The objective remains a demonstrably better knowledge and decision resource on your website; search systems and language models independently determine which content they use and when.

YOUR WORKSHEET

Worksheet: URL audit and repair decisions

Use one row per finding rather than a general wish. The first row is fictional. Include the date and method in the evidence field.