# Measure what changed, and maintain what you published A baseline is a dated snapshot of your pages, and it only earns its keep when something is compared against it later. Ours took 15 seconds and stored one home page: status, title, H1, canonical, headings, JSON-LD blocks and Open Graph tags. The field it left empty is the most useful thing in the record. This closing lesson reads the snapshot, names what no crawl can see, and ends the course. Claude SEO: do SEO inside Claude Code · Module 5 · 13 of 13 · 16 min > This course is independent. It has no affiliation with Anthropic or with AgriciDaniel, who writes claude-seo, and nobody on their side reviewed it. Run with claude-seo v2.4.1 on 2026-10-03. URL: https://seodraft.app/learn/claude-seo/measure-and-maintain Learn: https://seodraft.app/learn/claude-seo.md ## What you will be able to do - Capture a baseline and know exactly which fields it stored. - Name the measurements your run could not take, and what each one needs. - Keep a published article honest after the week you published it. 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](https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports)). 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](/learn/claude-seo/complete) 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. ## Steps ### Step 1 · Store the snapshot you will compare against (claude-seo) Run this on the page whose changes you care about most, usually the home page or a money page. The record is local: it lands in a small database under your cache directory, so a teammate on another machine has their own baselines and yours travel with your laptop. ``` /seo drift baseline https://your-site.com ``` What you should see: A numbered baseline with a timestamp and a table of what it stored. Ours is ID 1, captured on 2026-10-03 at 07:23 UTC in 15 seconds over 4 turns: status 200, the title, the H1, the canonical, no meta robots, 3 H2 and 0 H3, 4 JSON-LD blocks and 7 Open Graph tags. ### Step 2 · Compare after a deploy, once there is something to see (claude-seo) The comparison is the half that pays for the baseline, and it only says something after the site changed. Run it after your next deploy. Our own course has not run it yet, because the baseline above was captured on the day of the run and nothing has shipped since. ``` /seo drift compare https://your-site.com ``` What you should see: A list of fields that moved since the baseline. Ours will skip the Core Web Vitals rules whenever it runs, because the baseline stored no vitals, and the baseline report says so in the same paragraph where it explains why. ### Step 3 · Turn the empty sections into a short shopping list (claude-seo) An agent without credentials writes a report with holes in it, and the holes are easy to read past. This prompt collects them into one list you can act on in an afternoon. Each item is a key, an account or a quota, and each one unlocks a specific section that is currently a guess. ``` List every finding in this audit that is missing because a data source is not connected, and say what connecting each source would unlock. ``` What you should see: A list with the cost of each gap. Ours named three: a Google API key or service account for field vitals, indexation and analytics; the free Moz API for a backlink baseline; and the drift baseline itself, which we then captured. ### Step 4 · Re-measure the numbers that aged (seodraft) Search volume and intent move, and a topic bank quietly 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. Archiving keeps the measured history and takes the topic out of planning. ``` Run refresh_metrics on the topics I still plan to write, and archive the ones I no longer want. ``` What you should see: Updated metrics with their state attached, and a shorter bank. A number the provider does not return comes back as unavailable, which seodraft never displays as a zero, so an empty cell stays readable as an empty cell. ### Step 5 · Keep the promise the article made (seodraft) An article that says results are coming has made a dated promise to its reader, and the update is the strongest freshness signal you control. Our own post says it has no measured results yet, and our content report asked for an update in four to six weeks with the real numbers. `deliver_draft` re-sends an approved article to the same path, which is what makes an update safe to repeat. ``` Add the measured results to this published post, run run_gate, and re-deliver it with deliver_draft once it passes. ``` What you should see: The same file overwritten through its blob SHA, with the draft flag still forced on. Nothing in your repository is deleted, and you publish the updated version from your CMS the same way you published the first one. ## Checklist - [ ] I captured a baseline and read which fields it stored. - [ ] I listed the measurements my run could not take, and why. - [ ] I know which of my questions only Search Console can answer. - [ ] My topic bank holds terms I still intend to write. - [ ] Every article of mine that promised results has a date for the update. ## Checkpoint ### Your backlink section says insufficient data. How many backlinks do you have? The report cannot say, and reading it as zero is the mistake the sentence exists to prevent. Our audit left backlinks unscored because the domain is absent from the open crawl graph it had access to, and it wrote the caveat into the finding: absence from that graph is not proof of zero links. The fix it recommended is a free Moz API key, which establishes a real baseline to compare against later. Until a source is connected, the honest answer is that nobody measured it. ### Your agent can crawl your site whenever you ask. Why connect Search Console at all? A crawl reads your pages and Search Console reads Google's side of the relationship, and only the second one knows what people searched, which pages were served, where they ranked and what got indexed. Google also publishes a generative AI performance report with impressions and visible pages, which is the closest thing to measured AI visibility that your own property gives you. Our audit ran with no Google credentials at all, so its indexation and field-performance sections are empty by construction. Connecting the account turns three guessed sections into measured ones. ## What this lesson said - A baseline stores status, title, H1, canonical, robots, heading counts, JSON-LD blocks and Open Graph tags, with a number and a timestamp so a later run can compare. - Ours is ID 1, captured on 2026-10-03 at 07:23 UTC, and it stored no Core Web Vitals, so every comparison from it will skip those rules until a PageSpeed key exists. - The same baseline caught a title that names two products and an H1 that names three. Fix a mismatch before comparing, or the comparison reports your own edit. - Three data gaps were named by the audit: a Google key for field vitals, indexation and analytics; a free Moz key for backlinks; and the baseline itself. - An article that promised measured results owes its reader an update. Ours is due four to six weeks after publication, with the real numbers. ## Questions ### How often should I re-run the audit? Capture a baseline now and compare after each deploy that touches templates, which is the rhythm the drift commands are built for. A full audit is worth repeating when something structural changes: a redesign, a migration, a new section of the site, or a new version of the plugin. Our own course was written against v2.4.1 checked on 2026-10-03, and a new version of the tool opens a review of the lessons it affects. Between those moments, Search Console answers more of your questions than another crawl will. ### Can claude-seo measure my Core Web Vitals? With a PageSpeed API key configured, yes; without one, the field is left empty and the report says so. Our baseline stored no vitals for that reason, and the audit's performance section ran on lab data alone because the API was rate-limited. The drift report spells out the consequence in one sentence: comparisons will skip the vitals rules until a key exists and a new baseline is captured. An empty field that announces itself is the behaviour you want from a measuring tool. ### What does Search Console show about AI search? Google publishes a dedicated generative AI performance report with impressions and the pages that were visible, documented on its search blog in June 2026 (https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports). That is first-party data about your own property, so it answers a question no readiness score can: whether your pages were actually served inside AI experiences. Lesson 12 scored how quotable a page is; this report counts what happened. Connect the property, give it a few weeks of data, and read it beside the classic performance report.