A Claude SEO audit is one command that starts eleven sub-agents and ends with a scored report you have to argue with. The command is easy; the reading is the skill. Our run against this site took 446 seconds, returned 79/100, listed what it could not measure, and threw out three of its own agents' findings before writing the plan. This lesson walks through that report in the order it should be read: what each agent looked at, what the number means, which findings survived verification, and how to choose the one item to do today. The site it ran against is the one you are reading, so every figure below is from a report whose subject can be checked.
What eleven sub-agents actually check
The orchestrator starts one sub-agent per area and each of them fetches your pages itself. Ours ran these:
| Agent | What it reads |
|---|---|
| technical | status codes, canonicals, redirects, headers, robots |
| content | depth, duplication, the words a page spends on its subject |
| schema | the JSON-LD a page ships and what it claims |
| sitemap | the sitemap's URLs, hreflang and lastmod dates |
| performance | lab measurements of loading and layout shift |
| visual | what the rendered page looks like, including on mobile |
| geo | whether an answer engine can quote the page |
| agentic | what an agent gets when it reads instead of a browser |
| sxo | whether the page matches the intent of its SERP |
| backlinks | links pointing at the domain, where data exists |
| cluster | how pages link to each other and which topics overlap |
That spread is why the audit takes minutes rather than seconds: eleven agents fetching, rendering and judging is eleven conversations happening at once. It is also why the report is long enough to need a reading order.
The score is a weighted average of what it could measure
Ours came to 79/100, built from seven categories with weights:
| Category | Weight | Score |
|---|---|---|
| Technical SEO | 22% | 78 |
| Content Quality | 23% | 78 |
| On-Page SEO | 20% | 85 |
| Schema | 10% | 78 |
| Performance (mobile lab, average of 3 pages) | 10% | 70 |
| AI Search Readiness | 10% | 82 |
| Images | 5% | 85 |
The backlinks row carries no score at all. The domain was absent from the link graph the agent reads, and absence from a graph is weak evidence about the web: the report says insufficient data and leaves the row out of the arithmetic. A tool that scored it zero would be making up a fact.
Know what your run could not read
Every audit has a "data not available" section, and reading it tells you which parts of the score to trust. Ours could not read Search Console, Analytics or field performance data, because the run had no Google credentials. Moz and Bing backlink data were absent for the same reason. The PageSpeed API was rate-limited, so the performance category rests on lab measurements of three pages.
That matters for how you use the number. A lab performance score of 70 describes what a measuring machine saw on a clean connection, and what your readers experience is a different measurement that needs field data. Treat the categories with missing inputs as directions, and close the gaps before you treat them as grades.
Read the verification section first
The orchestrator checks its agents against the live site before it writes the plan, and that pass is the most useful paragraph in the report. Ours confirmed three findings:
- the Spanish pages shipped
<html lang="en">in the server's HTML, with the correct language applied only after JavaScript ran - one blog post declared
datePublished: 2026-10-10, a date in the future, and four sitemaplastmodvalues carried the same date wwwredirected to the apex domain with a 307
It discarded three more. One agent flagged AI-slop phrases on a page whose subject is AI slop, where the phrases appear as quoted examples of what the tool detects. Another reported missing JSON-LD on a page that ships it, a counting artifact rather than a fact about the HTML. A third suggested adding FAQPage markup, which Google retired as a rich result on 2026-05-07, so the change would have cost an afternoon and returned nothing.
Reading that section first saves the afternoon. An agent reports what it saw in its slice; the orchestrator is the only pass that compares the slice with the site. When you write your own prompts later in this course, that is the shape to copy: a reader whose job is to disagree with the writer.
What the action plan gives you per item
Each item in the plan carries four parts, and they are what turn a finding into work:
- Why it matters, stated as a principle rather than a rule of thumb
- Depends on and unblocks, so the order is visible
- Failure check: the command or query that still fails while the problem is there
- Leading indicator: the measurement that should move first if the fix worked
The failure check is the part to copy into your own notes. A finding without one is an opinion you cannot close, and a fix without one is a change you merged and hoped about. The plan also ends with a dependency sequence, which is where you learn that two items worth doing are worth doing in a particular order.
Which finding to do first
Take the confirmed item whose failure check you can run yourself, in the category with the most weight, that unblocks something else. On this site that was the language tag: /es served <html lang="en">, the check was reading the <html> tag out of a curl of the page, and nothing about Spanish indexing could improve while it stayed wrong.
The future-dated post came second for a similar reason. Dates are a trust signal, and a sitemap whose lastmod points at tomorrow teaches a crawler to ignore the file. Fixing it unblocks the later work of publishing new articles and expecting them to be recrawled.
Items whose leading indicator needs data you do not have yet go last. The performance work on this site is real, and the measurement that would prove it fixed needs field data that the run could not read, so the honest order is to close the gap first and then the item.
Two things to hand seodraft while you are here
seodraft can take two facts about your site off this audit and keep them. import_sitemap reads your sitemap into its inventory, looking at the sitemap URL in your profile, then the Sitemap: lines in robots.txt, then /sitemap.xml and /sitemap_index.xml. It downloads no page, so titles are inferred from slugs and every screen that shows them says so. From then on, a topic that resembles something you already published comes back flagged.
check_ai_access reads your robots.txt the way RFC 9309 reads it and reports every documented AI crawler at your home page and at a content path, grouped by what blocking each one costs you: citations in search, fetches a person asked for, and training. There is no score. Your llms.txt is reported as a fact, and a Cloudflare edge raises a warning, because robots.txt cannot show you a firewall rule.
What to have ready before lesson 4
Keep three things from this audit: the confirmed findings with their failure checks, the list of data your run could not read, and the one item you chose to do first. The rest of the report keeps.
Lesson 4 goes deeper into the agentic and geo half of what you just read: which AI crawlers reach your pages, what an agent gets when it reads your HTML instead of rendering it, and what to change when the answer is less than you expected.