A baseline is a dated snapshot of a page, stored so a later run can tell you what moved. On 2026-10-03 at 07:23 UTC we captured ours in 15 seconds: one home page, written to a small local database as baseline number one. The report that came back lists what it stored and, more usefully, one thing it could not store. This closing lesson reads that record, names the measurements no crawl can take on its own, and ends with the promise a published article owes its reader.
A baseline is only worth the comparison it enables
A snapshot on its own tells you nothing you could not read by opening the page. Its value arrives the second time, when a command diffs today's version of the page against the stored one and names the fields that changed. That is why the two commands come as a pair, and why capturing a baseline costs so little: 15 seconds and 4 turns for one URL.
Capture the page whose changes matter most. For most sites that is the home page or the page that sells, because those are the ones a redesign quietly rewrites. The record lands under your own cache directory, so baselines live on the machine that took them and a teammate has their own.
What our first baseline actually stored
The record is a short table, and reading it tells you what the comparison will be able to notice later. Ours stored status 200, the title, the H1, the canonical URL, the absence of a meta robots tag, a count of 3 H2 and 0 H3, 4 JSON-LD blocks and 7 Open Graph tags.
Everything in that list is a field a deploy can change without anybody meaning to. A component refactor drops a heading level. A layout change removes a JSON-LD block from one template. A copy edit rewrites a title that three other things referenced. None of these show up in a code review as a search problem, and all of them show up in a diff against a stored baseline.
A missing measurement is a finding of its own
Core Web Vitals were absent from our baseline, and the report said so in bold instead of leaving a blank cell. The reason is that no PageSpeed API key was configured in that session, so no field metrics could be fetched. The same gap appeared in the audit's performance section, which ran on lab data alone because the API was rate-limited.
The consequence is stated in the same paragraph: every comparison from this baseline will skip the vitals rules until a key exists and a new snapshot is taken. A tool that announces the measurement it could not take is giving you a true record of what it knows, and a blank cell with no explanation is how a reader ends up quoting a zero. Read for the empty fields first, then read the numbers.
Fix a mismatch before you compare, or the comparison reports your edit
Our baseline flagged something nobody had noticed: the home page title names Claude or ChatGPT, and the H1 names Claude, ChatGPT or Cursor. The report called it a mixed message and recommended fixing it before the next comparison, because a comparison run afterwards would report the title change as drift.
That ordering is worth keeping as a habit. A baseline is an agreement about what normal looks like, so anything you already intend to change belongs in the snapshot in its fixed form. Fix the known problems, capture the baseline, then let the comparison tell you about the ones you did not intend.
The comparison is the step this course has not run yet
We have not run /seo drift compare on this site, and saying so is more useful than describing what it would have said. The baseline was captured on the day of the audit, and nothing has shipped between then and the writing of this lesson, so a comparison would have nothing to report.
Run yours after the next deploy that touches templates. Expect a field-by-field diff with the vitals rules skipped if your baseline had none, and expect most runs to report nothing, which is the point. A monitor that only speaks when something changed is a monitor you keep running.
Search Console answers the questions a crawl cannot
A crawl reads your own pages, and Search Console reads Google's side of the relationship: what people searched, which of your pages were served, where they ranked, and what was indexed. No amount of crawling reconstructs those, so a report written without the connection has a specific, predictable hole in it. Ours ran with no Google credentials at all, which left indexation, field vitals and analytics empty by construction.
Google also publishes a dedicated generative AI performance report, with impressions and the pages that were visible, documented on its search blog in June 2026 (developers.google.com). That is first-party data about your own property, and it answers the question lesson 12 deliberately left open: a readiness score grades how quotable your page is, and this report counts what happened.
Three gaps, three keys, one afternoon
The audit closed with a short list it called data gaps to close, and each item is a credential rather than a project. A Google API key or service account unlocks field vitals, indexation data and analytics. The free Moz API establishes a backlink baseline. The third item was capturing the drift baseline, which is the command at the top of this lesson, and we did that one the same day.
Three keys is an afternoon of work that converts three guessed sections of every future report into measured ones. Do them in that order if you are choosing, because the Google connection covers the most questions and costs nothing beyond the setup.
Missing backlink data is weaker evidence than it looks
Our backlinks section came back unscored, with the words insufficient data and a caveat written into the finding: the domain is absent from the open crawl graph the agent could read, and that absence is no proof of zero links. The agent declined to score a category it could not measure, which is the behaviour you want.
Read every "insufficient data" line that way. A number that was never taken and a number that came back as zero look similar in a summary and mean opposite things, and a quarterly report built on the confusion will tell somebody a story that never happened. When a section is empty, the next action is connecting a source, and the honest sentence in the meantime is that nobody measured it.
Re-measure the numbers that aged, and retire the topics you abandoned
Search volume, intent and your own plans all drift, and a topic bank left alone becomes a list of last quarter's assumptions. refresh_metrics re-measures Google volume, AI search volume and intent for topics already in the bank, as one batch of three requests whatever the number of terms it carries. A figure the provider does not return comes back marked unavailable, and seodraft never renders that as a zero.
Archiving is the other half of the maintenance. A topic you decided against stays in the database with its measured history and leaves the planning surfaces, so the bank keeps describing what you actually intend to write. Do both on the same afternoon you read your Search Console numbers, because that is when you know which terms still deserve an article.
Keep the promise your article made
Our own post about distributing an MCP server tells its reader, in its own opening summary, that there are no measured results yet. That sentence is a dated promise, and the content report turned it into a recommendation: update the post in four to six weeks with the real numbers, because keeping that promise is the strongest freshness signal the page can earn.
The mechanics are the ones lesson 11 set up. Add the measured results, run the rules, approve, and re-deliver to the same path, where the draft flag is forced on again and nothing is deleted. Then publish the update from your CMS and change the dates on every surface that carries one, which is the check that started this module.
Where this course leaves you
You now have the loop the whole course was building: audit, plan, brief, write with evidence, check, publish, score and compare. Each step leaves a dated artefact somebody else can read, which is what separates this from asking a model to do SEO and hoping. The numbers in these thirteen lessons came from one real run against this site on 2026-10-03, with claude-seo v2.4.1, including the measurements it could not take and the bug it found in our own product.
Go and mark this lesson complete, then open the course close to build your share card. It takes your handle, puts it on a card you can post, and gives you the link to the course for whoever asks how you did it.