A 0–100 score is defensible when someone who disagrees with it can see exactly why a page got the number it did, run the same check, and get the same result. That needs four things: published signals, published weights, inputs that do not change between runs, and a way to say “not scored” instead of inventing a zero. A score missing any of the four can still be useful internally. It cannot be put in front of a client or an executive and defended line by line.
Most readiness scores in this category fail the first two. They show a number and a color, and the method behind it is a black box. That is a reasonable product choice for a dashboard. It is a poor one for an audit, because the first question in any review of an audit is “why is this page a 54,” and “the model says so” ends the conversation badly.
This post is a design guide for anyone building a score, whether in a spreadsheet for one client or in a tool. It uses GEOBee’s three lenses as the worked example because their weights are public, and it sits under How to audit a site for AEO and GEO.
What is the score actually measuring?
Decide this first and write it down in one sentence, because every later choice depends on it. For an AEO or GEO score, the defensible answer is page-side readiness: whether a page can be reached, parsed, and lifted from, and whether it carries the signals that make a source citable. That is a property of the page, observable in its HTML and headers.
The answer to avoid is “likelihood of being cited.” Citation depends on the query, the engine, the competing sources, and factors no crawler can observe. A score that claims to measure it is claiming something it cannot check, and the first time a high-scoring page is never cited, the score loses its credibility for everything else it measures. What GEOBee measures, and what it deliberately doesn’t states that boundary for one tool; any score should state its own.
A useful test of the sentence: could a reader with view-source and a browser verify every input? If yes, the score measures something observable. If some inputs need access to an assistant’s internals, those inputs belong in a different report.
Which signals belong in the score?
Signals that are observable on the page, have a written pass condition, and relate to the measured property by an argument you can state in one line. Each signal needs three things documented:
| Field | Example |
|---|---|
| Name | Answer block |
| Pass condition | A 40–60 word direct answer within the first few paragraphs |
| Why it relates to readiness | An extractor lifts passages; a self-contained answer near the top is the passage most likely to be usable |
The pass condition is where most scores go vague. “Good headings” is not a condition. “A single H1, at least two H2s, and question-style headings” is. When a condition needs judgment, split it into the parts that do not, and leave the judgment to the human review that follows the score.
Keep the signal list short enough to read. GEOBee’s AEO lens has eight signals and its GEO lens seven; The three lenses lists every one with its condition. A list of forty signals is not more rigorous, just harder to audit, and the weights become too small to mean anything.
How should the weights be set?
Set them so they sum to 100, publish them, and make each one large enough that passing or failing it moves the score visibly. A weight is a claim about relative importance, and publishing it invites the argument, which is the point. A reviewer who thinks Freshness is overweighted at 15 can say so, and you can answer with a reason. A reviewer who cannot see the weight can only distrust the total.
There is precedent for publishing weights. Google’s Lighthouse documents its performance score as a weighted average of metric scores and lists the weights: Total Blocking Time 30 %, Largest Contentful Paint 25 %, Cumulative Layout Shift 25 %, and First Contentful Paint and Speed Index 10 % each. Practitioners argue about those weights in public, and the argument makes the score more useful, not less.
Three practical rules for choosing weights:
- Gates are not weights. Some conditions make the rest moot: a page an AI search crawler is disallowed from fetching is never read by that crawler. Score that as a signal like any other, but report it as a gate outside the score as well. Prioritizing AEO fixes shows why a 10-point signal can still be the first fix.
- The heaviest weight goes to the signal with the strongest argument. In GEOBee’s GEO lens that is Citability at 25, which covers statistics, outbound citations, and quotable blocks, the closest match to the methods the GEO paper tested. In the AEO lens it is the answer block at 20.
- Do not blend lenses. An AEO score and a GEO score measure different things. Averaging them into one number hides which one failed. GEOBee keeps SEO, AEO, and GEO as three separate scores for that reason.
What should happen when a signal can’t be measured?
The page should read as “not scored,” not as zero. This is the rule most often broken, and breaking it quietly corrupts every average built on top.
Consider a crawl where a tenth of URLs return a redirect or a 404. If those rows score zero on every signal, the site average drops, the distribution grows a spike at zero, and a reviewer sees a site in worse shape than it is. Worse, the 404s look like content failures instead of status-code failures, and the fix list points at the wrong problem.
The defensible rule: a signal that does not apply, or a page that cannot be evaluated, is excluded from the score and shown as excluded. GEOBee shows redirects, errors, and non-HTML responses as ”—” in the score cells, so a 301 or a 404 cannot drag averages down. The same applies to URLs disallowed by robots.txt during the crawl itself: they are recorded with a note, not given a fake score.
Write the rule down for each signal. “No author byline found” is a measured failure. “Page returned 404” is not a page that lacks a byline.
How should the score be banded?
Use a small number of bands with fixed boundaries, and publish what each band means in terms of action. GEOBee uses three: 80–100 passes, 60–79 is a warning, below 60 is critical. Lighthouse uses 90–100 good, 50–89 needs improvement, and 0–49 poor. The boundaries differ; what matters is that they are stated and do not move between reports.
Bands do two jobs. They tell a reader where to act without reading digits, and they absorb small differences that do not mean anything. A page at 78 and a page at 81 are not meaningfully different, and a report that ranks them as if they were is overclaiming precision. Report distributions by band, and use the exact number for tracking one page over time.
How do you test that a score is defensible?
Run three checks before you put it in front of anyone. Each one can be done in a spreadsheet with two crawl exports.
Reproducibility. Crawl the same site twice, in the same mode, with nothing changed in between, and compare the per-URL scores. A deterministic score should match exactly. Lighthouse’s own documentation notes that much of the variability in its performance score comes from changing conditions such as network routing, devices, and ads, which is why it advises treating performance as a distribution. A readiness score built on static HTML should not have that problem; if it moves between identical runs, something in the inputs is not deterministic.
Sensitivity. Fix one signal on one page and re-crawl. The score should move by that signal’s weight, or by the share of it the fix earned, and by nothing else. If adding a byline moves the GEO score by 15 points, the weights are doing what they say. If it moves by 3 or by 40, the documentation and the scoring code disagree. Crawl, fix, re-crawl describes how to read the comparison.
Face validity. Sort pages by score and read the top five and bottom five. The top should be pages an experienced reviewer would call strong, and the bottom pages they would call weak. Where they disagree, the score or the reviewer has missed something, and either answer is useful.
Comparisons have one more condition: like with like. A static crawl and a rendered crawl see different HTML on a JavaScript-dependent site, so their scores are not comparable. GEOBee flags a quick scan compared against a deep scan for that reason; Scan modes explains the difference.
How do you present a score so it survives a review?
Show the number with the signals underneath it, never the number alone. For each page or template in a report, list the signals it failed, the weight of each, and the fix. A reviewer who disagrees can then point at one row instead of rejecting the whole score.
Three habits help:
- State the version. If you change a weight or a threshold, scores before and after the change are not comparable. Note the rule set used for each crawl.
- State configurable thresholds. If title length or a word-count floor is adjustable, say what it was set to. GEOBee’s Scoring Rules tab exposes these thresholds, and changes apply to the next crawl, not the current one.
- Separate readiness from outcomes. Put the score in one section and any visibility or traffic data in another, with a sentence saying the first does not predict the second. What prompt tracking can and can’t tell you covers the limits of the outcome side.
For agencies, the same structure belongs in the statement of work; Scoping and pricing an AEO and GEO audit covers how to write that boundary into a proposal.
Where GEOBee fits
GEOBee’s lenses follow the design in this post: published signals and weights summing to 100 per lens, three lenses kept separate, fixed bands, “not scored” cells for redirects and errors, and configurable thresholds that are stated. Every finding behind a score carries its severity and a one-line fix, so a reviewer can trace each lost point to a cause.
If you want a score you can defend line by line in your next audit, see pricing or download GEOBee and start the 7-day trial.