TL;DR: A GEO audit answers four questions: can crawlers reach you, what do assistants currently say, what gets cited instead of you, and what is wrong. Six phases, one day, no tooling required beyond server logs and an assistant account. The output is a prioritised list of fixes, most of which turn out to be access and accuracy problems rather than content problems.
Key Takeaways
Start with access, not content. A blocked crawler or a JavaScript-rendered page makes every other finding moot, and it is the fastest thing to check.
Establish a baseline before changing anything. Twenty prompts, three assistants, three runs each, written down. Without it you cannot tell whether anything you do later works.
Find out what gets cited instead of you. The sources appearing in answers to your category questions are your actual competition for the citation.
Check what is wrong, not just what is missing. Inaccurate descriptions are usually quicker to fix than absence and more damaging while they persist.
Prioritise by impact against effort. Most audits produce twenty findings, of which three matter and two are one-line fixes.
Re-run quarterly, not monthly. The access checks are worth a monthly glance; the full audit is a quarterly exercise.
Anchor targets assume your CMS generates slug IDs from heading text. Confirm on staging and adjust the hrefs if your platform slugifies differently.
What a GEO audit is
An assessment of whether AI assistants can find you, do mention you, and describe you correctly. It produces a prioritised list of fixes.
Related reading: Generative Engine Optimization: 2026 Strategy
The six phases
Phase | Question | Time |
|---|---|---|
1. Access | Can crawlers reach your content at all? | 1 hour |
2. Baseline | What do assistants currently say about your category and you? | 2 hours |
3. Sources | What gets cited instead of you? | 1 hour |
4. Content | Can your pages be quoted? | 1 hour |
5. Entity | Are you recognised as a distinct, categorised thing? | 1 hour |
6. Accuracy | What is wrong about you? | 1 hour |
Seven hours of work, comfortably a day with breaks and note-taking.
What it is not
Not | Because |
|---|---|
A tool output you read | Tools produce measurements. An audit produces decisions |
A keyword exercise | Prompts are not keywords and the overlap is partial |
A one-off | It is a baseline you re-run against |
A content plan | Content is one possible output. Often not the main one |
What you need before starting
Requirement | Why |
|---|---|
Access to server logs, or someone who has it | Phase 1 depends on it |
Accounts on two or three assistants | Phase 2 onward |
Your robots.txt, including on any subdomains | Phase 1 |
A list of your main competitors | Phases 2 and 3 |
A spreadsheet | For the baseline record |
Three hours of someone technical | Phases 1 and 4 |
The honest framing
Most first audits find that two or three things are badly wrong and everything else is fine. The value is in locating those two or three, not in the completeness of the checklist.
So work through it quickly, note what fails, and resist the urge to produce a fifty-point report. A report with three real findings gets acted on; one with fifty gets filed.
Phase 1: access
One hour. Everything else is pointless if this fails, which is why it goes first.
The checks
Check | How | Pass looks like |
|---|---|---|
robots.txt on the main domain | Read it. Look for GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended | Deliberate decisions, not accidental blocks |
robots.txt on every subdomain | docs, help, blog, app. Each has its own | Checked, not assumed |
Server-side rendering | View source on key pages. Search for a body sentence | Content present in the HTML |
Crawler hits in server logs | Filter the last 30 days by the bot user agents | Regular requests, mostly 200s |
Status codes served to bots | Same filter, look at the codes | Not 403s, not soft 404s |
CDN or WAF rules | Ask whoever manages it whether bots are challenged | No blanket bot challenge |
Login walls on useful content | Try a key page in a private window | Reachable |
The distinction that catches people out
Google-Extended controls whether your content is used for Gemini and Vertex AI model training. It does not control appearance in AI Overviews, which follows ordinary Googlebot access.
GPTBot is OpenAI's training crawler. OAI-SearchBot is the one for ChatGPT search. Blocking the first does not block the second, and teams frequently block both when they meant to block only training.
So read your robots.txt asking what each line was meant to do, not just whether bots are allowed.
The CDN finding
This is the one most often missed, because it is invisible in robots.txt. Bot management rules at the CDN layer can challenge or block AI crawlers regardless of what your robots file says.
Server logs are the check that catches it. If your robots.txt allows a crawler and your logs show no requests from it, something between the two is intervening.
Recording the output
For each crawler: allowed or blocked in robots, requests in the last 30 days, predominant status code. Six rows, and they tell you immediately whether you have an access problem.
A site where every AI crawler shows zero requests has one finding worth more than everything in the next five phases.
Phase 2: baseline
Two hours. The record you will compare against for the next year, so do it properly once.
The prompts
Twenty, covering four intents:
Intent | Count | Example |
|---|---|---|
Category discovery | 7 | best [category] for [your buyer type] |
Comparative | 5 | alternatives to [main competitor] |
Problem-first | 5 | [the problem you solve, in a customer's words] |
Branded | 3 | what is [you], is [you] any good |
Source them from sales calls and support tickets rather than a keyword tool. Twenty minutes with real transcripts produces better prompts than an hour of keyword research.
The method
Three assistants, three runs per prompt, fresh sessions each time, location set explicitly if you serve a geography. That is 180 runs, which sounds like a lot and takes about ninety minutes with a spreadsheet open.
Three runs is the minimum that lets you distinguish a consistent absence from a single unlucky one. Answers vary between identical runs, so a single result is not a finding.
What to record per run
Field | Why |
|---|---|
Mentioned, yes or no | The core measure |
Position in the answer | First named differs from a closing aside |
Which competitors appeared | Phase 3 input |
Which sources were cited | Phase 3 input |
Anything inaccurate | Phase 6 input |
You are collecting inputs for three later phases while you do this, which is why phase 2 takes the longest and why the others go quickly.
Reading the baseline
Pattern | Reading |
|---|---|
Strong on branded, weak everywhere else | Known to those who know you, invisible to new buyers |
Weak on branded too | An entity problem. Phase 5 matters most |
Strong on problem-first, weak on category | Content works, category association does not |
Strong on category, weak on comparative | Losing at the decision stage |
Inconsistent across assistants | Normal. Note it and do not over-read it |
The discipline
Write the prompt list down and do not change it. This is now your instrument, and if you edit it before the next audit your comparison is meaningless.
Version it, date it, and store it somewhere that is not a vendor platform.
Phase 3: sources
One hour, using the citations you recorded in phase 2. This is the phase that converts a disappointing baseline into a plan.
The question
When an assistant answers a question in your category and does not cite you, what does it cite? Those sources are your real competition for the citation, and they are usually not your competitors' websites.
What to tally
Go through every citation you recorded and count by type:
Source type | What it means if dominant |
|---|---|
Review platforms | Your profile there matters more than your blog |
Industry publications | Earned coverage is the lever |
Competitor sites | They have published something you have not |
Forums and communities | Real user discussion carries the category |
Reference sites | The category is being defined elsewhere |
Your own site | Working. Note which pages |
The two findings to look for
Which specific sources appear repeatedly. Usually a handful dominate. Those are the places where being present, accurate and current is worth real effort, and they are a short list rather than the whole internet.
Which of your own pages get cited, if any. This is more useful than the overall rate. If three of your pages do all the work, their format is telling you something, and phase 4 is where you work out what.
What to do with a dominant source
Source | Action |
|---|---|
A review platform you are listed on | Audit the profile: category, features, pricing, description |
A review platform you are not on | Get listed |
A publication covering your category | Earned coverage work, honestly done |
A community thread | Participate transparently, disclosed, or leave it alone |
A competitor's comparison page | Write a better and more honest one |
The thing not to do
Do not plant content on the sources you find. Arranged mentions presented as organic breach platform rules and raise disclosure problems under advertising standards, and manipulating AI-generated responses has been treated as spam behaviour by search platforms.
The finding is where to be genuinely present, not where to astroturf.
Recording it
A ranked list of the ten most-cited sources, with a note on your current status at each. That list is the most directly actionable artefact the audit produces.
Phase 4: content
One hour. Whether a system reading your pages can extract a clean, quotable answer.
The test
Take your ten most commercially important pages. For each, ask: if someone asked the question this page answers, could a system lift a two-sentence answer from it without rewriting?
That is the whole test, and most pages fail it for the same few reasons.
The checks
Check | Fail looks like |
|---|---|
Answer near the top | 400 words of preamble before the page addresses its own question |
Headings as questions | Headings like Our Approach rather than the question being answered |
Self-contained paragraphs | Paragraphs that only make sense after the three before them |
Specifics over adjectives | Fast, powerful, intuitive, where a number or fact belongs |
Dates on anything that ages | Pricing, comparisons and statistics with no date |
Tables as HTML | Comparison data as an image |
One page per question | Five questions crammed into one long page |
The most common failure
The buried answer. Marketing pages are structured to build a case before delivering a conclusion, which is reasonable for a human reader scrolling and bad for extraction.
Moving the direct answer into the first hundred words costs nothing and is the single most repeated fix in this phase.
Cross-reference with phase 3
If phase 3 showed that a few of your pages do get cited, compare them against the ones that do not. The difference is usually structural rather than topical: the cited pages answer a specific question directly and the others do not.
That comparison is better guidance than any general advice, because it is derived from your own site.
Schema
Check that Organization, Product and FAQPage markup where relevant is present and valid. It is a modest contributor rather than a lever, and FAQPage markup must match visible page text.
If schema is absent, note it as a low-effort fix rather than a priority finding.
Recording it
Ten pages, pass or fail against the seven checks, with the specific failure noted. That converts directly into a rewrite list, ordered by the commercial value of the page.
Phase 5: entity
One hour. Whether you exist as a distinct, correctly categorised thing rather than a name that might be several companies.
Why it comes before content work
If a system cannot reliably establish what you are, no amount of good content gets you into a recommendation. It has nothing to attach the content to.
This phase matters most when your baseline showed weakness even on branded prompts, which is the signature of an entity problem rather than a content one.
The checks
Check | How |
|---|---|
Name ambiguity | Search your name. How many other things share it? |
Consistent naming | Is it written identically everywhere, including legal suffixes? |
Category statement | Does your homepage say plainly what kind of thing you are? |
Consistent facts | Founding year, location, size, leadership, the same everywhere |
Organization schema | Present, with sameAs links to your real profiles |
Third-party profiles | Review sites, directories, professional networks, all current |
Who is behind it | Named people with real bios, not a faceless brand |
The disambiguation test
Ask an assistant what your company is, in a fresh session, without context. If the answer describes a different company with a similar name, or hedges between several, you have an entity problem and it outranks everything else in the audit.
Run it on all three assistants, three times each. Inconsistency across them is itself the finding.
The fix, in order
State your category plainly on your homepage, in the first paragraph, in ordinary words.
Make your name, founding details and location identical everywhere you control.
Add Organization schema with sameAs links to your genuine profiles.
Correct stale third-party profiles.
Put named people with real bios on the site.
None of that is sophisticated. Entity problems are usually inconsistency problems, and the fix is making the same facts appear identically in enough places.
What not to do
Do not create a Wikipedia or Wikidata entry about your own organisation. Wikidata's guidance discourages self-promotional item creation and Wikimedia's terms require paid editors to disclose. Notability is earned through coverage you did not place.
Recording it
The disambiguation test result, a consistency table of your core facts across five locations, and a list of stale profiles. Usually a short list of quick corrections.
Phase 6: accuracy
One hour. What assistants say about you that is wrong, which is usually more urgent than what they do not say.
Why absence is not the worst outcome
Being absent costs you an opportunity. Being described wrongly costs you a buyer who had already found you, and it is typically faster to fix because the cause is a specific retrievable page rather than your overall position.
The questions to ask
Question | What errors look like |
|---|---|
What does [you] do | Wrong category, outdated positioning |
How much does [you] cost | Old pricing, third-party guesses |
Does [you] do [feature you have] | A false no, the most costly error |
Does [you] do [feature you lack] | A false yes, which produces bad-fit leads |
Who runs [you] | Departed leadership |
Where is [you] based | Old address |
What are the downsides of [you] | Criticism that was resolved years ago |
Is [you] still operating | Confusion with a defunct similarly named company |
Ask each on three assistants. Record the error and, where the assistant shows sources, which page produced it.
The two error classes
Class | Cause | Fix |
|---|---|---|
Traceable | A specific outdated page, yours or a third party's | Correct or update that page. Often days |
Untraceable | No visible source. Likely parametric | Publish correct, clear, dated information and wait |
Traceable errors are the good kind, because they have an address. Start every accuracy investigation by asking which source produced the claim.
The one to prioritise
A false negative about a capability you actually have. A buyer asking whether you do something you do do, and being told no, is a lost deal you will never hear about.
If you find one, the fix is a page that states the capability plainly, with specifics, in language matching how the question was asked.
What you cannot do
You cannot contact a model provider and have a claim corrected, and nothing third-party edits training data. The route is always the same: publish clear, correct, well-structured information and let retrieval find it.
That is slower than people want and it is the honest answer.
Recording it
Every error found, its class, the source if traceable, and the severity. This list is usually the fastest-moving part of the whole audit.
Prioritising what you found
An audit that ends with a list of findings has not finished. The output is an order of work.
The two axes
Score each finding on impact and effort, both one to five, then sort.
Impact | Meaning |
|---|---|
5 | Blocks everything. Crawler access, entity confusion, a false negative on a core capability |
4 | Affects a commercially important question directly |
3 | Affects a real but narrower set of questions |
2 | Marginal contribution |
1 | Theoretical |
Effort | Meaning |
|---|---|
1 | A configuration change or a form submission |
2 | An afternoon |
3 | A week of someone's time |
4 | A project with dependencies |
5 | An ongoing programme |
Where typical findings land
Finding | Impact | Effort |
|---|---|---|
AI crawlers blocked at the CDN | 5 | 1 |
Documentation behind a login | 5 | 2 |
False negative on a core capability | 5 | 2 |
Wrong category on a review platform | 4 | 1 |
No published pricing information | 4 | 2 |
Entity disambiguation failure | 5 | 3 |
Buried answers on key pages | 3 | 2 |
Missing schema | 2 | 1 |
Absent from a dominant publication | 4 | 5 |
Low overall category citation rate | 4 | 5 |
How to read that
The top of the list is almost always access and accuracy: high impact, low effort, and fixable within a fortnight. The bottom is earned coverage and category position: high impact, high effort, measured in quarters.
Most teams invert this, starting with a content programme while a CDN rule quietly blocks every crawler.
The rule
Do everything at impact 4 or 5 with effort 1 or 2 before starting anything at effort 4 or 5. That usually means two to four weeks of unglamorous fixes before any content work begins.
It is also the period in which you are most likely to see the baseline move, because unblocking produces faster change than publishing does.
The things to drop
Anything at impact 1 or 2 with effort 3 or more. Audits generate busywork, and naming what you are deliberately not doing is part of the output.
The findings document
Short. One page of findings, one page of plan, and the raw data in an appendix nobody reads but everybody needs when they question a number.
The structure
Section | Content | Length |
|---|---|---|
Headline | Three sentences: what we found, what matters most, what we propose | 3 sentences |
The three findings that matter | One paragraph each, with evidence | Half a page |
Baseline | The rate by intent, with the range across runs | A table |
Prioritised actions | Impact, effort, owner, target date | A table |
Deliberately not doing | What you dropped and why | Three lines |
Method | Prompts, assistants, runs, dates, version | A paragraph |
Appendix | Full prompt list and raw results | As long as it is |
Why the method section is not optional
Someone will ask where the number came from, usually in three months when it has moved. Without the method recorded you cannot answer, and the number becomes unusable.
It also forces the versioning discipline, because writing down the prompt list makes it a thing you can accidentally change.
Report ranges, not points
Your baseline rate should read as roughly 20 to 28 percent, not 24 percent. Answers vary between identical runs, and a point estimate invites comparisons the data cannot support.
This single habit prevents most of the false conclusions that follow an audit.
The three-findings rule
If you present twenty findings, nothing happens. If you present three, with evidence and an owner, something usually does.
The other seventeen go in the appendix and get picked up in a later quarter if they still matter. Most will not.
Who it goes to
Whoever can authorise the top three actions. If the top finding is a CDN rule, the document needs to reach engineering, not just marketing leadership.
That routing is worth thinking about before writing, because an audit whose main finding sits outside the author's team is extremely common and is the usual reason nothing gets fixed.
What not to include
Several things appear on circulating GEO audit checklists that are wrong, unverifiable, or a waste of a day.
Files that are not required
Item | Position |
|---|---|
ai.json | Not a standard. No major provider documents reading it. There is nothing to check |
llms.txt | A proposal, not a requirement. Published analysis found the overwhelming majority of such files received no requests at all |
Google's own documentation states that no new machine-readable files are needed for its AI features; ordinary crawlable content and standard structured data are what matter. Adding these files is harmless and auditing for them wastes a line on your checklist.
Claims about model internals
Claim | Why to drop it |
|---|---|
Vector space positioning or semantic proximity scores | Commercial embeddings are not externally accessible. Nobody can measure this |
Getting woven into training data | Third parties do not edit training corpora |
Retraining the model's understanding of your brand | Not a thing that can be done from outside |
Training data refresh cycles you can time work against | Not published, not predictable |
These appear confidently in a lot of material. An audit that includes them produces findings nobody can act on or verify.
Single-run observations
One absence in one run is noise, not a finding. Everything in this audit is run at least three times for that reason, and a checklist that asks you to run a prompt once produces unreliable conclusions.
Manipulation tactics
Tactic | Problem |
|---|---|
Arranged community mentions presented as organic | Platform rules, and disclosure requirements for material connections |
Paid placement in listicles without disclosure | Advertising standards and search platform spam policies |
Content built around phrasing intended to steer answers | Treated as spam behaviour by search platforms |
Vanity metrics
An overall visibility score with no stated method, a competitor index with no denominator, or a single percentage with no range. If you cannot say how it was calculated and how much it varies, leave it out of the report.
How often to re-run it
Different parts have different half-lives, so splitting them keeps the work proportionate.
Cadence | What |
|---|---|
Monthly | The baseline prompt set, same version, same method. Ninety minutes |
Monthly | A glance at crawler hits in server logs. Ten minutes |
Quarterly | The full six-phase audit |
Quarterly | Review the prompt set itself and apply parked changes |
On change | A site migration, rebrand, CDN change or major launch triggers phase 1 immediately |
Why not monthly for everything
The full audit is a day. Run monthly it becomes a chore that gets skipped, and most of what it checks does not change month to month: your robots.txt, your entity consistency, your page structure.
What does change monthly is the baseline, and that is the cheap part.
The migration trigger
Worth stating separately. A site migration or CDN change is the most common cause of a sudden crawler access failure, and it will not announce itself.
Add a phase 1 check to the launch checklist for any infrastructure change. It takes ten minutes and prevents the worst silent failure in this field.
What a quarter of change looks like
Timeframe | What moves |
|---|---|
Weeks | Accuracy fixes with a traceable source. Access fixes |
1 to 2 quarters | Page-level citations after structural rewrites |
2 to 4 quarters | Category and comparative position |
Longer | Entity recognition where you were genuinely obscure |
Setting that expectation at the end of the first audit is worth doing, because the gap between expectation and reality is what kills these programmes in month three.
Keep the versions
Every audit gets a version number and a date, and the prompt set version is recorded alongside. A year of quarterly audits with consistent method is genuinely valuable; a year of inconsistent ones tells you nothing.
FAQs
What is a GEO audit?
An assessment of whether AI assistants can reach your content, do mention you, and describe you correctly. Six phases covering access, baseline, sources, content structure, entity recognition and accuracy, producing a prioritised list of fixes rather than a score.
How long does a GEO audit take?
About seven hours of work, comfortably one day. The baseline phase takes two hours and the rest take one each. You need server log access, accounts on two or three assistants, and about three hours of someone technical.
Do I need a tool to run one?
No. A spreadsheet, server logs and assistant accounts cover the whole audit. Tools help when you move from a one-off audit to continuous monthly measurement across a larger prompt set, which is a different problem.
What should I check first?
Crawler access. Read your robots.txt on every subdomain, check whether key pages are server-rendered, and look for AI crawler hits in server logs. If a CDN rule or a stale robots line is blocking crawlers, nothing else in the audit matters.
Do I need an ai.json or llms.txt file?
No. Neither is required by any major provider, and Google's documentation states no new machine-readable files are needed for its AI features. Published analysis found the overwhelming majority of llms.txt files received no requests at all.
How many prompts should the baseline use?
Twenty for a first audit, across category, comparative, problem-first and branded intents, run three times on each of three assistants. Source them from sales calls and support tickets rather than a keyword tool.
How do I prioritise the findings?
Score each on impact and effort from one to five. Access and accuracy problems are usually high impact and low effort, so they go first. Earned coverage and category position are high impact and high effort, measured in quarters.
How often should I re-run it?
The full audit quarterly. The baseline prompt set monthly, using the same version and method. A phase 1 access check immediately after any site migration, rebrand or CDN change, since those are the most common cause of silent crawler failures.
Running your first one
Book a day. Do phase 1 first thing, because if it fails you have found the thing that matters and the rest of the day is confirmation.
Most first audits produce the same shape of result: two or three real problems, usually access or accuracy, and a long tail of minor observations. Write up the two or three, park the rest, and get the top three fixed before starting any content work.
The six phases, in order
Access. robots.txt on every subdomain, server-side rendering, crawler hits in logs, CDN rules.
Baseline. Twenty prompts, three assistants, three runs, recorded.
Sources. What gets cited instead of you, ranked.
Content. Whether your ten key pages can be quoted.
Entity. Whether you are recognised as a distinct, categorised thing.
Accuracy. What is wrong, and whether it has a traceable source.
Then score every finding on impact and effort, do the high-impact low-effort work first, and write down what you are deliberately not doing.
If the output is a content backlog
Phases 3 to 6 typically produce a list of specific pages worth writing: the questions you lose, the capabilities you need to state plainly, the comparisons that need to be honest. Producing those consistently is where most teams stall, and Blazly SEO covers research, planning, drafting and direct publishing from about $39 a month.
The audit itself stays yours, which is the right arrangement. Nobody should outsource finding out what is wrong with their own site.
Summary
A GEO audit asks six questions in order: can crawlers reach you, what do assistants say now, what gets cited instead of you, can your pages be quoted, are you recognised as a distinct thing, and what is wrong about you. It takes a day and needs no tooling beyond server logs, a spreadsheet and assistant accounts. Start with access, because a CDN rule or a stale robots line makes every other finding moot. Record the baseline properly, including the method and the range, because it is what you will compare against for a year. Then score each finding on impact and effort and do the cheap high-impact fixes first, which are almost always access and accuracy problems rather than content ones. Three findings presented with evidence get acted on; twenty get filed.