Full GEO Audit

1. What a full GEO audit covers

A full GEO audit is a periodic, site-wide review of the conditions that determine whether AI engines can fetch, parse, use, and cite your pages. The implementation work spans several disciplines: citability, crawler-access auditing, schema implementation, llms.txt deployment, writing for citation, and citation tracking. The audit reviews these areas in dependency order, assigns severity to each finding, and turns the results into an actionable report.

The six layers, in order, are access → rendering → structure → content → off-site authority → outcomes. If a prerequisite fails, findings in later layers may not be meaningful (§3).

A GEO audit connects ongoing monitoring with improvement planning:

• AI Citation Tracking records what engines actually do; the audit uses those results to investigate why.
• The GEO Maturity Model turns the diagnosis into a prioritized improvement plan.

“GEO audit” is a general industry term. The specific six-layer model used here is GEO Wiki’s framework, not an established standard. Its value lies in the dependency order explained in §3, not in external endorsement.

2. Before you audit — scope, inputs, trigger

Four decisions determine how every later finding should be interpreted. Set them before collecting data; otherwise, the report may combine results that are not comparable.

When to run it. Audit quarterly and after events that may change the results: a site migration, a redesign or SSR/rendering change, a robots.txt edit, a major content launch, or a known engine or retrieval update. Scheduled audits catch gradual drift; event-driven audits catch sudden changes.

Inputs to gather before you start: access to crawl the production site, the live robots.txt, the XML sitemap, a rendering test that inspects fetched output rather than only page source, and the latest citation-tracking log if one exists. A missing tracking log does not prevent you from auditing Layers 1–5; see §4.6.

3. The audit sequence — why order matters

GEO readiness consists of dependent conditions, not a set of independent checks. If a prerequisite fails, findings later in the sequence may not describe the site’s actual citation potential.

• Structured data cannot help a crawler that is blocked from the site.
• Strong content cannot be used if it is missing from the fetched output.

Review Layers 1 through 6 in order, but rank and report the findings by severity rather than by layer (§5–§6).

Keep every finding concise, self-contained, and easy to scan so the final report can be understood without extra context.

4. Running the audit

Audit the layers in order, from 1 to 6. For each layer, document the question being answered, the dependency that affects later checks, the two or three most diagnostic checks, and the relevant implementation guide.

4.1 Layer 1 — Access & crawlability

For Google’s user-agent list and robots.txt token behavior, see its common crawlers documentation. In practice, this layer is close to binary: if the pages are not reachable, record a Layer-1 blocker and resolve it before continuing.

4.2 Layer 2 — Rendering & delivery

See the IndexNow protocol documentation for submission details. If a page returns HTTP 200 but provides no primary content to a client that does not execute JavaScript, record a Layer-2 rendering finding rather than a Layer-4 content problem.

4.3 Layer 3 — Structure & machine readability

Use Google’s introduction to structured data, the Rich Results Test, and the schema.org Schema Markup Validator to validate markup. Compare llms.txt with the proposed specification. Google states that its AI features require no special schema, so evaluate structured data as an aid to entity clarity rather than a requirement for AI eligibility (AI features and your site).

4.4 Layer 4 — Content & trust

This layer has the strongest published causal evidence. In Aggarwal et al. 2024, content-level changes such as adding citations, statistics, and quotations increased answer visibility by up to about 40%. Treat that result as directional evidence, not as a guaranteed improvement; see §8.

4.5 Layer 5 — Off-site authority

This layer is easy to overlook. Even excellent on-page work may have limited effect when the entity is poorly recognized or weakly corroborated elsewhere.

4.6 Layer 6 — Observed outcomes

Layer 6 uses the latest tracking results; the AI Citation Tracking playbook covers how to collect them. If no tracking log exists, record one finding: establish citation tracking. Compare results separately for Perplexity AI, ChatGPT Search, and Google AI Overviews, because their behavior differs. Google AI Overviews has no per-citation API, so its outcome data is necessarily less detailed.

5. Scoring — a defensible severity model

Assign a severity to every finding based on the layer it affects and the extent of the impact. A Layer-1 access failure is more severe than a Layer-4 refinement because the content improvements cannot matter until access is restored.

A composite readiness score from 0 to 100 is optional and should remain secondary to the per-layer findings. It is directional rather than absolute. Publish it only when you also document the inputs and weighting method, following the provenance guidance in GEO Metrics. A score without its method is not an interpretable result.

6. Prioritize — from finding list to ranked action plan

Severity and priority are different. A major finding that is inexpensive and straightforward to fix may deserve attention before a blocker that requires a six-month migration. Rank the findings by impact × confidence × ease (ICE) to produce an ordered action list.

Use the ranked findings as input to the GEO Maturity Model, which converts the current assessment into a longer-term improvement plan.

7. What the audit report should include

Every audit report should include:

• Audit context and provenance — the audit date, scope, declared engine set, and tracking-log version used (§4.6). Without this information, later audits cannot be compared reliably.
• Layer-by-layer results — Layers 1 through 6, with evidence for each result.
• Findings ranked by severity, followed by the ICE-prioritized action plan.
• Changes from the baseline — if a previous audit exists, what changed and whether the likely cause was an action you took or a change in the engine.

During a re-audit, verify the layers affected by the triggering event and carry forward only results that remain valid (§2). State which checks were repeated and which results were retained. Otherwise, an outdated passing result can remain in several consecutive reports.

8. Common pitfalls and validity risks

Before publishing the report, check for each of the following problems:

• Top-down auditing — checking content first and overlooking a Layer-1 or Layer-2 failure that invalidates later findings.
• Composite score without a method — a 0–100 score with no documented weighting method (GEO Metrics).
• Outdated tracking data — comparing Layer 6 with results that no longer represent current engine behavior (AI Citation Tracking).
• Combining relative and absolute findings — competitor comparisons and absolute assessments are different measures and should not be added together (GEO Metrics).
• Generalizing from one locale to all locales — Chinese and English results are not interchangeable.
• Claiming a fix without a re-audit — implementation alone does not confirm that the result changed.
• Treating visibility as proof of revenue impact — the audit can show that a visibility problem was resolved, not that revenue increased. Use a separate model for the business relationship (GEO ROI Models).
• Generalizing from a single participant’s improvement — a gain measured in isolation may not persist once competitors optimize for the same engine; see the caveat in Aggarwal et al. 2024 §6.

9. Further reading

• Layer-specific guides: AI Crawler Access Audit · SSR for AI Crawlers · Sitemap & IndexNow · Schema Implementation · llms.txt Deployment · Citability · Writing for AI Citation · Brand Mention Tracking
• Monitoring and planning: AI Citation Tracking · GEO Maturity Model
• Metrics and definitions: GEO Metrics · Generative Engine Optimization
• Research: Aggarwal et al. 2024 — GEO: Generative Engine Optimization

References

Academic:

1. Aggarwal, P. et al. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · ACM DL
2. Liu, N., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP ‘23. arXiv:2304.09848

Platform & standards documentation (verified 2026-05):

• Google Search Central — Overview of Google crawlers · Common crawlers list · AI features and your site · Structured data intro
• Validators — Rich Results Test · Schema Markup Validator
• IndexNow — Protocol Documentation
• llms.txt — proposed standard
• Perplexity — Chat Completions API Reference · OpenAI — Web Search tool (Responses API)