An AEO and GEO audit is scoped by templates, not by URLs. A hypothetical site with 40,000 product pages built from one template is closer to a single review than to 40,000 of them, and a 300-page site built from fifteen hand-made layouts can be more work than either. Once the template count is known, the deliverables follow from it, the hours follow from the deliverables, and the price follows from the hours and from whatever pricing model you already use.
This post is that sequence for agencies and consultants: how to inventory a site before you quote, how to define the deliverables so the client knows what they are buying, how to estimate time as a method you can repeat, and what to leave out of the contract. It gives no price figures. Rates depend on your market, your seniority, and your client, and a number in a blog post would be wrong for most readers.
It sits under Running AEO and GEO as a practice. The audit itself is described in How to audit a site for AEO and GEO; this post is the commercial wrapper around it.
What are you actually selling?
You are selling a diagnosis of page-side readiness: whether AI crawlers can reach the site, whether its pages can be parsed and lifted from, and whether they carry the signals that make a source citable. Each of those can be checked, reproduced, and re-checked after a fix.
You are not selling citations. Nothing on the site’s side of the page guarantees that an assistant will cite it, and a scope that implies otherwise sets up an argument at renewal. Write the boundary into the proposal in one sentence: the audit measures readiness and access, and does not measure or promise visibility in any assistant’s answers. If the client also wants visibility tracking, quote it as a separate line with its own caveats; What prompt tracking can and can’t tell you is a fair summary to send them.
Saying this up front is not a hedge. It is what makes the rest of the scope defensible, because every deliverable below is something you can show was done.
How do you inventory a site before quoting?
Count URLs, then group them into templates, then sample. You can do all three without a full crawl and without access to the client’s systems.
Count URLs. Read the XML sitemap and its index, if there is one, and note the URL count per sitemap file. Sitemaps are often split by content type, which gives you a first draft of the template list for free. If you have Search Console access, the page indexing report gives indexed and non-indexed counts. Note that the Performance report export from the Search Console interface is truncated to 1,000 rows, so on a large site it shows a sample of pages, not all of them.
Group by template. Open a sheet with one row per URL pattern: /products/*, /blog/*, /docs/*, /locations/*, plus the one-off pages (home, pricing, about, contact). For each pattern, open three random URLs and confirm they share a layout. If they do not, split the pattern.
Sample. For a quote, a crawl capped at a few hundred pages, spread across every template, tells you more than a full crawl does. Path filters let you weight it toward the templates you are unsure about.
The inventory sheet ends up with these columns, and it doubles as an appendix to the proposal:
| Column | Contents |
|---|---|
| Template | URL pattern or page name |
| URL count | From the sitemap or index report |
| Business role | Revenue, support, editorial, or none |
| Variants | Number of distinct layouts inside the pattern |
| Rendering | Server-rendered, or content needing JavaScript |
| Notes | Anything that will slow the review: login walls, geo-redirects, a separate subdomain |
Two rows on that sheet change the estimate more than any URL count: client-side rendering, and multiple hosts. A JavaScript-dependent template needs a rendered pass as well as a static one, which JavaScript content and what never makes the trip explains. Each subdomain has its own robots.txt and often its own CDN rules, so each one is a separate access review.
Which deliverables should be fixed in the scope?
Fix the deliverables by name before you estimate, because the deliverables are what the hours are for. A workable set has four parts, and each one is a document the client keeps.
| Deliverable | What it contains | Scales with |
|---|---|---|
| Access review | robots.txt on every host, CDN and firewall behavior for each AI search crawler, snippet directives | Number of hosts |
| Template findings | Per template: findings, evidence URLs, the fix, and who owns it | Number of templates |
| Prioritized fix list | Every finding ranked by severity, page value, and effort | Number of findings |
| Baseline and re-crawl | The scored crawl as of the audit date, and a re-crawl after fixes ship | Site size, number of re-crawls |
The access review comes first and is the most valuable per hour, because a blocked search crawler or a max-snippet:0 makes the rest of the findings moot for that surface. The template findings are the bulk of the work. The fix list uses the spreadsheet method in Prioritizing AEO fixes: severity × page value, so the client can re-rank it themselves later. The re-crawl is what lets you say a fix landed; Crawl, fix, re-crawl describes how to read the comparison.
What to leave out of a fixed scope: writing the fixes, implementing schema, and rewriting content. Those are follow-on work with a different shape, priced per template or per page once the findings exist.
How do you estimate the hours?
Estimate each deliverable from its own driver, add a fixed overhead, and keep the per-unit figures in a sheet you update after every audit. The method is what matters; your numbers will be your own.
The structure:
Hours = overhead
+ (hosts × access-review hours per host)
+ (templates × review hours per template)
+ (JS templates × extra rendered-review hours)
+ (re-crawls × hours per re-crawl and report)Overhead covers kickoff, access requests, the readout meeting, and writing the summary. It barely moves with site size.
Here is an illustrative estimate for a fictional client, with invented per-unit figures, to show how the terms combine:
| Line | Count | Hours per unit (illustrative) | Hours |
|---|---|---|---|
| Overhead | 1 | 6 | 6 |
| Access review | 2 hosts | 2 | 4 |
| Template review | 9 templates | 1.5 | 13.5 |
| Rendered review | 2 JS templates | 1 | 2 |
| Re-crawl and delta report | 1 | 3 | 3 |
| Total | 28.5 |
The only defensible source for the per-unit column is your own record. After each audit, log the actual time per deliverable against the counts from the inventory sheet. After a handful of audits, the averages are your estimate, and you can show a client how the quote was built.
Two adjustments are worth building into the sheet. Add a multiplier for clients where every change needs sign-off from several people, because readout and revision time grows with the number of stakeholders. And cap the template count in the contract: if the inventory finds nine templates and the client later adds three more sections, that is a change request, not part of the original scope.
How should you price it?
Price it with whatever model you already use for technical SEO audits; the AEO and GEO work does not need a new one. The three common models each have a place:
| Model | How the price is set | Fits when |
|---|---|---|
| Time-based | Estimated hours × your rate | The inventory is uncertain, or the client wants to see the build-up |
| Fixed fee by tier | Price bands by template count and host count | You run many audits of similar shape |
| Value-based | A share of what the fixes are worth to the client | Pages carrying revenue are clearly identified and the client agrees on their value |
A fixed fee by tier is the natural fit once the estimate method has a few audits behind it, because template count and host count are the tier boundaries. Define tiers by those two numbers, not by URL count, and the price stays honest for a large site with few templates.
Two rules apply whatever the model. Price the re-crawl into the original scope rather than selling it later, because an audit without a measured after-state is the hardest one to renew. And quote re-audits as a separate, recurring line: AI crawlers, vendor documentation, and the site itself all change, so an access review from six months ago is a historical document.
What goes in the statement of work?
Five sections cover it:
- In scope. Hosts, templates by name, the inventory sheet as an appendix, and the scan modes you will run.
- Deliverables. The four above, each with its format and delivery date.
- Out of scope. Implementation, content writing, visibility tracking, and any promise of citation or traffic.
- Assumptions. Access you need (Search Console, a staging URL, someone who can answer CDN questions) and what happens to the timeline if it is late.
- Change control. New templates or hosts are quoted as additions at the same per-unit rates.
Keep the data clause specific. If crawl data stays on your machine and is shared only as the delivered reports, say so; client legal teams ask. What GEOBee measures, and what it deliberately doesn’t is a useful model for writing the boundary of a measurement in plain terms.
Where GEOBee fits
The inventory, the baseline, and the re-crawl are where a crawler saves the hours. A capped GEOBee crawl with Include path filters gives you the sampled pass for a quote; the full crawl becomes the baseline; Re-crawl and Compare in a project produce the after-state. Every finding comes with severity, module, and a one-line fix, and the JSON export carries them into the fix-list spreadsheet, as Exporting data describes. Crawls are stored locally, grouped by client domain.
Every license includes unlimited URLs per crawl, deep scans, and crawl comparison. To test the workflow on a real prospect before you quote, download GEOBee and use the 7-day trial.