Crawlability is a condition. A ranking is an outcome. A citation is an observation. An answer is a context-dependent event. This lesson teaches you how to measure each one without turning a clean technical audit into a story it cannot support.
A site owner may say, “We improved visibility,” when they actually mean one of four things: a crawler can reach the page; Google indexed or displayed the page; a person clicked it; or an answer system mentioned it in a particular context. Those are related but non-identical events. Treating them as interchangeable creates bad decisions and makes a technical team report success before the audience has experienced any change.
Google’s Search Console guidance separates discovery, indexing, Search performance, structured-data status, security, and page experience into different reports [1]. That separation is useful beyond Google: each measurement should answer one question, have a named source, and carry a boundary around what it cannot establish.
After this lesson, you should be able to explain the difference between a structural check, a platform metric, an independent observation, and an unknown; choose the right instrument for a question; record enough context for another person to reproduce the observation; and write a release statement that does not overclaim.
| Evidence class | Plain-language definition | Example instrument | Safe statement |
|---|---|---|---|
| Structural check | A property of the published surface that can be inspected directly. | HTTP fetch, link crawler, canonical check, sitemap comparison. | “All 54 inspected routes returned 200 and were reachable within two clicks.” |
| Platform metric | A measurement reported by a platform operating a search or distribution surface. | Search Console Performance or indexing reports. | “The verified property reported 1,240 impressions during this date range.” |
| Independent observation | A dated, contextual record of what a person or answer system displayed. | Question, locale, device, model, response, links, timestamp. | “This query produced this response in this context on this date.” |
| Unknown | An outcome for which the appropriate evidence has not been collected. | Not a metric; a deliberate state in the claim register. | “Citation growth and Domain Authority are unknown.” |
Inspect status codes, HTML anchors, robots directives, canonicals, sitemap parity, and rendered resources. A passing result says the public surface is technically available to a crawler. It does not say that the page is valuable, indexed, or authoritative.
Use first-party tools for indexing and performance. Search Console can show impressions, clicks, queries, pages, countries, and trends, but the property, date window, filters, and report definitions must travel with the number [1].
Record the exact question, date, locale, device, surface, model where known, full response, cited links, and whether the answer changed. Do not turn one screenshot into a stable score or a universal claim about “the model.”
Keep rankings, citations, traffic, conversions, independent backlinks, Domain Authority, and answer inclusion separate. If the instrument has not been run, the correct result is unknown—not an optimistic inference.
Imagine a library. A crawlable link is a shelf label that lets a visitor reach a book. A canonical URL is the library’s decision about which edition is the reference copy. A sitemap is a catalogue supplied to the librarian. Structured data is a description of the book’s type and properties. None of these signals tells you that readers will choose the book, that a reviewer will cite it, or that a recommendation engine will mention it.
This is why our technical audits report conditions rather than outcomes. Google recommends checking that it can find and read pages, submitting or monitoring a sitemap, reviewing indexing coverage, and using the Performance report for impressions and clicks [1]. The measurement plan must preserve those layers instead of blending them into one “SEO score.”
“Risk management should be continuous, timely, and performed throughout the AI system lifecycle.” — NIST AI RMF Core [2]
We apply the same logic to GEO: measure the public knowledge surface continuously, map the context around a claim, record the observation, and manage correction when the record becomes stale. NIST’s Govern, Map, Measure, and Manage functions are a useful external framework for this rhythm, but this lesson’s worksheet is a Coreweaver interpretation, not a NIST certification or required checklist [2].
A team publishes a 54-page learning site. Every route returns HTTP 200. Its sitemap matches the route manifest. Internal links are ordinary HTML anchors with no restrictive relationship attributes. No route is orphaned, and the maximum path from home is two clicks. The team has not connected Search Console, collected a backlink baseline, or run a documented answer-observation study.
Supported: “As of the audit date, the inspected public route graph was reachable, its declared canonical and crawl controls were internally consistent, and its internal links were not marked with restrictive relationship attributes.”
Not supported: “The site now ranks better, has higher Domain Authority, earns more citations, receives more traffic, or is more likely to appear in AI answers.” Those may become testable questions, but this structural audit did not measure them.
Verify the property in Search Console and establish a dated baseline for indexing, impressions, clicks, queries, and pages. Then define an independent observation protocol for answer surfaces if answer visibility is a real decision. Treat each protocol as a separate evidence stream.
PASS → STRUCTURE
MEASURE → SEARCH
OBSERVE → ANSWER
UNKNOWN → AUTHORITY
Do not fill a field with a guess. If the source is missing, write unknown and name the instrument that would resolve it.
| Layer | Question and scope | Evidence to attach | Boundary / next action |
|---|---|---|---|
| Structure | Which routes, links, canonicals, robots rules, sitemap entries, and schema blocks were checked? What date and commit? | Audit JSON, route manifest, commit URL. | Does not establish rankings or authority. Fix any failed route or control. |
| Search | Which verified property, date range, country, device, query, and page filters were used? | Search Console export or recorded report state. | Does not establish AI-answer inclusion. Compare equivalent periods. |
| Answer observation | What exact question, locale, device, surface, model, timestamp, response, and cited sources were recorded? | Observation packet with response and links. | One observation is not a universal score. Repeat across a defined sample. |
| Authority | What independent referring domains, citations, or third-party mentions were measured, and with which tool? | Dated backlink/referring-domain export and methodology. | Unknown until measured. Do not substitute a technical pass for off-site authority. |
Practice prompt: Complete the Structure row for this lesson. Then write one Search question that could be answered by Search Console and one Answer question that would require a dated observation packet. If a learner cannot name the instrument, the question is not ready to measure.
A useful evaluation process moves from cheap, repeatable checks to slower, context-rich observations. Run the first rung on every release. Run the later rungs when the decision justifies the effort.
| Rung | When to run it | Output | Failure response |
|---|---|---|---|
| 1. Route and link check | Every commit that changes routes or navigation. | Status map, broken-target list, click-depth graph. | Repair the route or link before release. |
| 2. Index and metadata check | Every release; after migrations or template changes. | Canonical, robots, sitemap, JSON-LD, and title/description report. | Fix conflicting or missing signals; do not infer an outcome. |
| 3. First-party search baseline | After property verification and on a chosen cadence. | Date-bounded impressions, clicks, queries, pages, and indexing state. | Investigate trend changes with equivalent filters. |
| 4. Contextual answer study | When a real decision depends on answer-system behavior. | Repeatable question sample and dated response packets. | Compare context and sources; do not generalize from one output. |
| 5. Authority and outcome review | When off-site growth or business outcomes are in scope. | Referring-domain, citation, conversion, or qualified-lead evidence. | Keep the outcome separate from the technical release record. |
Start with the GEO Source Attribution lesson if you need to improve evidence handling, then return to the Technical SEO and GEO Playbook to connect the measurement ladder to the full authority graph. For implementation, run the project’s all-pages directory and keep the machine-readable llms.txt index aligned with the route manifest.