An audit of any real site produces more findings than anyone can fix in a quarter. Sorting that list by severity alone puts a broken template on a page nobody visits ahead of a weaker problem on the page that carries your revenue. Sorting it by score does something worse: it sends you to the ugliest pages first, which are usually the ones that matter least.
The order that holds up is severity multiplied by page value, divided by effort. Each of the three is a column in a spreadsheet, each is rated on a small scale you write down in advance, and the product is a ranked list you can defend in a meeting and recompute next month. This post is that sheet: what goes in each column, the formula, a worked example on a fictional site, and the re-crawl that closes each row.
None of this predicts which fix earns a citation. Nothing on your side of the page can. What it decides is which readiness problems you remove first, which is the part of the work you control.
Where the findings come from
The sheet starts with one row per finding: a URL, what is wrong with it, and the fix. You can build that list by hand. Run the checks in Five checks for a page that ranks but never gets cited on your important templates, and confirm access with How to check whether AI crawlers can actually reach you before anything else. Each check produces a URL and a fault. Write it down as a row.
At scale, any crawler export gets you the same shape. GEOBee’s JSON export carries every issue per URL with its severity, module, category, finding, and recommended fix, so the first five columns of the sheet arrive already filled. The CSV export carries the per-URL scores if you only want one row per page. Either opens in a spreadsheet, and nothing below needs a terminal.
One rule before you rate anything: collapse findings that share a fix. Forty product pages missing the same JSON-LD block are one template change, not forty tickets. Give that fix one row, list the affected URLs in a notes column, and rate its value as the combined value of those pages. Otherwise the sheet ranks the same fix forty times.
Severity: what makes a finding a gate
Severity answers one question: how much of the page’s readiness does this finding take away? Use three tiers, not a continuous scale. A tier is quicker to agree on than a point on a ten-point scale.
| Tier | Score | What belongs here |
|---|---|---|
| Gate | 3 | The page can’t be fetched, indexed, or read at all. Examples: an AI crawler disallowed in robots.txt, a noindex, a 4xx or 5xx response, a redirect chain that never resolves. |
| Critical | 2 | The page can be read, but a core signal is broken: no H1, no answer anywhere near the top, schema that fails to parse, thin content with nothing to lift. |
| Warning | 1 | A signal is weakened, not broken: a long title, keyword headings instead of question headings, a missing byline, a stale date. |
The gate tier is separate from Critical for a reason that’s easy to miss in a scored audit. In GEOBee’s GEO lens, AI bot access is one signal worth 10 of 100 points (the three lenses lists every weight). As a score that’s honest, because it’s one signal among seven. As a priority it’s wrong. A page a crawler is told not to fetch is never read by that crawler, so every other fix on the page does nothing for it until the block is lifted. Gates outrank everything on the same page for that reason, not because of their weight.
The same logic gives you an ordering rule inside a single URL: clear the gate, then the Criticals, then the Warnings. GEOBee’s detail panel already lists a page’s findings from Critical down for this reason, and Findings & fixes describes the levels. The sheet only adds the cross-page view the panel can’t give you.
One check before you score a gate: is the block deliberate? Disallowing a training crawler can be a policy decision, not a fault. If someone decided it, mark the row “accepted,” note who decided and when, and leave it out of the ranking.
Page value: three things you already know
Page value is the column most audits skip, and it’s the one that changes the order. Build it from three sub-scores, each 0 to 2, from sources you already have.
Traffic (T). Export the Pages table from the Search Console Performance report for the last three months and paste the clicks next to each URL. Don’t set fixed thresholds. Split your own pages into bands instead: the top tenth by clicks scores 2, the rest of the top half scores 1, everything else 0.
Role (R). What job does the page do for the business? A 2 is a page where money or leads change hands: pricing, a product page, a demo request. A 1 supports that decision: specs, documentation, a comparison page. A 0 does neither. This is a judgment call. Make it once per template, not once per URL.
Question (Q). Does the page answer a question people actually ask? Look for question-phrased queries in the page’s Search Console query list, the same question in support tickets or sales calls, or the question appearing as a heading on the page with real impressions behind it. A 2 is demonstrated demand. A 1 is plausible demand. A 0 is a page that answers nothing in particular. Q is the sub-score most specific to answer engines: an extractor looks for a passage that resolves a question.
Value is 1 + T + R + Q, so it runs from 1 to 7. The 1 is a floor that keeps a zero-traffic page from multiplying a real problem down to nothing. A gate on an unvisited page still deserves a place on the list, just not near the top.
Effort, and the formula
Effort is the denominator, also on three tiers:
- 1: one person, one edit, in an afternoon or less. A robots.txt line, reordering a section, deleting a broken JSON-LD block.
- 2: a template change or a developer ticket. New structured data on a page type, rendering a table as HTML instead of an image.
- 3: a rewrite, a merge and redirect, or anything with more than one owner.
The sheet has these columns:
| Column | Contents |
|---|---|
| A: URL | The page, or the template for a shared fix |
| B: Finding | What is wrong, in one line |
| C: Fix | The action, in one line |
| D: Severity | 3, 2, or 1 |
| E: T | Traffic band, 0 to 2 |
| F: R | Role, 0 to 2 |
| G: Q | Question demand, 0 to 2 |
| H: Value | =1+E2+F2+G2 |
| I: Effort | 1, 2, or 3 |
| J: Priority | =ROUND(D2*H2/I2, 1) |
| K: Owner | Who ships it |
| L: Verified | Date of the crawl that confirmed the fix |
Sort by column J, descending. That’s the work order. Every input is a small integer with a written definition, so two people scoring the same finding should land on the same number. When they don’t, the disagreement is about one named column.
A worked example on acme-robotics.com
Acme Robotics is the fictional site used in the demo crawl on this site. Five of its findings are enough to show how the formula reorders a list. The traffic bands are invented for the example.
| URL | Finding | Sev | T | R | Q | Value | Effort | Priority |
|---|---|---|---|---|---|---|---|---|
| /products/arm-x9/downloads | All AI crawlers disallowed by robots.txt | 3 | 1 | 1 | 2 | 5 | 1 | 15.0 |
| /pricing | No structured data; prices rendered as images | 2 | 2 | 2 | 2 | 7 | 2 | 7.0 |
| /careers | GPTBot disallowed on /careers/ | 3 | 0 | 0 | 1 | 2 | 1 | 6.0 |
| /products/arm-x9/downloads | Thin page, no overview, no schema | 2 | 1 | 1 | 2 | 5 | 2 | 5.0 |
| /legacy/support-portal | JSON-LD fails to parse; 160-word thin page | 2 | 0 | 0 | 1 | 2 | 2 | 2.0 |
The downloads page comes first. It’s a gate on a page that answers a demonstrated question (buyers search for the ARM-X9 datasheet), and the fix is one robots.txt change. It has a second finding, the thin content and missing schema, which ranks fourth. That’s the ordering rule working as intended. Writing an overview paragraph for a page AI crawlers are told not to fetch does nothing for those crawlers until the block is lifted.
Pricing comes second, even though it has no gate. It scores the maximum on all three value sub-scores. “How much does it cost” is about as clear a question as a page can answer, and right now the answer is locked in images, with no Product or Offer markup to state it in machine-readable form. It’s a template ticket, so effort is 2.
The careers block sits in the middle. It’s a gate, so its severity is maximal, but the page has little traffic and no commercial role. Before it ships, someone confirms the GPTBot disallow wasn’t a deliberate choice.
The legacy support portal comes last, and that’s the useful lesson. In the sample crawl it has the lowest scores on the site: AEO 19, GEO 18. A score-sorted list would put it first. But nobody visits it and it does no job, and the right fix is to merge it into the live troubleshooting page and redirect, which is effort 2 with almost no value behind it. Low scores tell you where a page is weakest. They don’t tell you whether that page is worth the work.
Re-crawl to verify, then close the row
A row isn’t done when the ticket closes. It’s done when a fresh crawl shows the finding is gone. Verify by hand first, the same way you found it: re-read robots.txt, paste the URL into a structured-data validator to confirm the JSON-LD parses, read the opening of the section you rewrote.
At scale, re-crawl the same site in the same scan mode and compare. In GEOBee, a project’s Re-crawl captures a fresh snapshot, and Compare lines it up against a baseline. The summary chips show the movement in AEO, GEO, SEO, and Critical count across the crawl, and a negative Critical delta is the good direction. The per-page diff marks each URL as Improved, Regressed, Unchanged, Added, or Removed. Projects & compare covers both views, including why a quick scan and a deep scan shouldn’t be compared against each other.
Read the Regressed rows before the Improved ones. A template fix that adds Product markup to pricing can break the layout of another page that uses the same template, and the diff is where that shows up. When the finding is gone and nothing regressed, write the crawl date into column L.
Expect the scores to move in proportion to the weights, not to the priority. Lifting the downloads-page block clears a Critical and restores one 10-point GEO signal. It doesn’t turn a 22 into an 80, because the thin content is still there. A finding marked verified means the page is now readable where it wasn’t. Whether anything cites it is a separate question, and one this sheet doesn’t claim to answer.
Then re-score the value columns once a quarter. Traffic shifts, pages change roles, and the list should change with them.
If you want the findings column filled for you, download GEOBee. The 7-day trial exports every finding with its severity and fix, ready to paste into column B.