The way to prove a page-side change moved something is to bracket it: crawl before, write down exactly what changed and when, crawl again with the same settings, and compare the two crawls URL by URL. That proves the change shipped and that the page’s measured readiness moved. It does not prove that traffic or citations moved because of it, and the most common mistake in AEO and GEO reporting is presenting the first kind of evidence as the second.
This post is the loop in four steps (baseline, change log, re-crawl, compare), followed by how to keep readiness deltas separate from traffic, and how to run the whole thing with nothing but a crawler export and a spreadsheet. It sits under How to audit a site for AEO and GEO, and picks up where Prioritizing AEO fixes leaves off: that post decides what to fix; this one proves it was fixed.
What counts as proof?
It depends on the claim. Four kinds of evidence get mixed together in AEO reporting, and each supports a different sentence:
| Evidence | Source | What it can prove | What it can’t |
|---|---|---|---|
| Readiness delta | Two comparable crawls | The page now has the property the fix added | That anything cites the page |
| Fetch evidence | Server logs | Crawlers requested the changed page after the change | What they did with it |
| Search performance | Search Console, analytics | Clicks and impressions changed over a window | That your change caused it |
| Answer appearances | Sampled prompt runs | A brand appears more or less often in a sample | Why, or what customers saw |
The crawl delta is the only row that is deterministic. Run the same crawl twice against an unchanged site and you get the same scores. That is what makes it usable as proof of the change itself, and it is the row this post is mostly about. The fetch row is covered in Reading server logs for AI bot traffic; the last row in What prompt tracking can and can’t tell you.
Step 1: How do you take a baseline?
Crawl the pages you intend to change, plus a comparison set you don’t intend to change, and save the export with the date in the filename. Everything that defines the crawl has to be written down, because the re-crawl has to match it:
- Scope: start URL, page limit, include and exclude path patterns.
- Mode: a static fetch or a rendered one. Results from the two are not comparable.
- User agent and robots handling: the same identity both times.
- Scoring thresholds: if your crawler lets you change them, freeze them for the duration.
The comparison set matters more than it looks. If you are adding answer blocks to twenty product pages, crawl twenty similar product pages you are leaving alone. If their scores move between crawls, something other than your edit moved them: a template deploy, a CMS update, a CDN rule.
For a small set, a baseline can be done by hand. Save view-source: of each page as a file, and record in a spreadsheet the checks you care about: is there an answer in the first paragraph, does the JSON-LD parse, what does the canonical say. It’s slower than a crawl, but it is the same evidence.
Step 2: What goes in the change log?
One row per shipped change, written when it ships, not reconstructed later. The columns:
| Column | Example (fictional) |
|---|---|
| Date live | 2026-10-14 |
| URL or template | /products/* template |
| Change | Added 50-word answer paragraph under H1; added Product JSON-LD with offers |
| Ticket | WEB-1182 |
| Expected crawl signal | AEO answer block passes; Schema column reads Product |
| Expected direction | AEO up on 38 URLs; no SEO change |
“Expected crawl signal” is the column that makes the re-crawl a test rather than a look-around. If you wrote down that the Schema column should read Product and it reads Invalid, you have found a bug, not a disappointing result.
Search Console has a place for the same note. Since November 2025, its performance charts support custom annotations: right-click the chart, add an annotation with a date and up to 120 characters of text. Everyone with access to the property can see them, so keep personal information out. An annotation on the date the template shipped saves an argument three months later about what happened that week.
Step 3: When should you re-crawl?
As soon as the change is live and caches have cleared. A crawler you run fetches the page as it is now; there is no reason to wait. Confirm the change is live first by opening view-source on two or three of the changed URLs. A re-crawl against a staging deploy that never reached production is the most common source of “the fix didn’t do anything.”
Search engines are a different clock. Google says recrawling “can take anywhere from a few days to a few weeks,” that you can request a crawl of individual URLs through the URL Inspection tool subject to a quota, and that requesting a crawl “does not guarantee that inclusion in search results will happen instantly or even at all.” So your re-crawl proves the change shipped today; whether Google has seen it is a question for the URL Inspection tool, page by page, later.
Step 4: How do you read the comparison?
Line the two crawls up by URL and classify every row. The categories that matter:
- Improved: scores went up. Check it is the score your change log predicted.
- Regressed: scores went down. Read these first. A template change that fixes one thing commonly breaks another on a page type nobody checked.
- Unchanged where you expected a change: the fix didn’t ship, shipped to a different template, or isn’t detectable the way you assumed.
- Added and removed: URLs present in only one crawl. Usually a scope difference; occasionally a redirect you didn’t intend.
Size the expected movement before you look. In a weighted score, a fix moves the score by at most the weight of the signal it fixes. GEOBee’s AEO lens weights the answer block at 20 of 100, so adding a passing answer block to a page that had none should move that page’s AEO score by up to 20 points and no more (the three lenses lists every weight). A page that jumps 45 points after a one-signal fix had something else change; a page that moves 3 points got partial credit or the detection disagreed with your edit. Either is worth a look.
How do you keep readiness and traffic apart?
Report them in separate sections with separate claims, and never put a readiness delta and a traffic change in the same sentence as cause and effect.
Readiness is deterministic and immediate: the crawl proves the page changed. Traffic is neither. Clicks in Search Console move with seasonality, algorithm updates, competitors’ pages, and changes in how often AI features appear for a query, none of which your change log records. A rise in clicks after a fix is consistent with the fix helping. It is not evidence that it did.
If you need to say something about traffic, three habits make it more defensible:
- Use the comparison set. Compare the change in clicks on the edited pages with the change on the untouched pages over the same window. A difference between the two is more informative than either alone.
- Use equal windows, far enough out. Compare the same number of days before and after, starting after the recrawl lag above, and prefer year-over-year where seasonality is strong.
- Say “consistent with,” not “caused.” It is the accurate phrase, and an executive who later learns the traffic moved for another reason will remember which way you put it.
How do you do this without a dedicated tool?
Any crawler that exports per-URL results to CSV will do. Export the baseline and the re-crawl with identical columns. In a spreadsheet, put the baseline in one sheet and the re-crawl in another, then in the re-crawl sheet look up each URL’s old value:
=XLOOKUP(A2, Baseline!A:A, Baseline!D:D, "added")A second column computes the delta, a third classifies it with =IF(E2>0,"improved",IF(E2<0,"regressed","unchanged")), and a filter on the change-log URLs shows whether each row did what it said it would. A reverse lookup from the baseline sheet finds URLs that disappeared.
From a terminal, the same diff for one score column. This assumes the URL is in column 1 and the score in column 4, and that no field contains a comma:
cut -d, -f1,4 baseline.csv | sort > before.csv
cut -d, -f1,4 recrawl.csv | sort > after.csv
join -t, -a1 -a2 -e NA -o 0,1.2,2.2 before.csv after.csv |
awk -F, '$2=="NA"{print $0",added";next} $3=="NA"{print $0",removed";next} {print $0","($3-$2)}'Column positions depend on your export, so adjust the field numbers; the spreadsheet route is easier to get right.
How GEOBee runs the loop
GEOBee saves every crawl into a per-domain project stored locally. Re-crawl runs the same domain again for a fresh snapshot, and Compare lines up a baseline and a current crawl. Summary chips show the movement in AEO, GEO, SEO, pages, and Critical count, where a negative Critical delta is the good direction, and the per-page diff marks each URL as Added, Removed, Improved, Regressed, or Unchanged with old and new scores and a signed delta. If the two snapshots are from different sites, or one is a quick scan and the other a deep scan, it warns you that the deltas aren’t meaningful. Projects & compare and scan modes cover both.
What the diff can’t tell you is the last two rows of the evidence table. It measures readiness, deterministically, and stops there; What GEOBee measures, and what it deliberately doesn’t explains why. The AEO audit, end to end shows the same loop run on a sample site from the first crawl onward.
To run a baseline today and diff it against next week’s re-crawl, download GEOBee and use the 7-day trial.