What is agentic SEO?
Agentic SEO is SEO carried out by a coding agent: it reads what is wrong with a site, makes the fixes in the site's own code, and checks each one on the live site after it ships. The reading and the checking are what make it work; an agent that only edits is guessing.
GuideBy mttrPublished Updated 5 minute read
- 56%Of pages fail the description rule, the first fix most agents makeOver the 15,202,701 pages it applies to, as of October 26, 2026
- 46%Of pages leave an image undescribedOver the 15,202,701 pages it applies to
- 37%Of pages carry no structured data that parsesOver the 15,202,701 pages it applies to
- 18%Of sites have pages that nearly copy each otherPairs sharing half or more of their text, over 316,711 sites
Counted from the 316,711 sites mttr has read, each at its latest read, as of October 26, 2026.
What does an agent do in agentic SEO?
It runs a loop of three steps until the list is empty. It reads a brief of what fails, on which pages and why it matters. It changes the code where the fault is made, usually a template. Then, once the change is live, it has the site read again and compares the new read with the old one, rule by rule.
The loop, one step at a time. Open each step to see the call and a sample of what comes back, for a made up site.
Read. A list of fixes ranked by what each is worth, with the pages behind each one, not a score on its own.
The callmttr_brief({ site: "yoursite.com" })
# yoursite.com: what to fix first 1. Fix description lengths, on 41 pages 2. Set each page's canonical address, on 12 pages 3. Describe images, on 9 pages
Change. In the site's own project, at the layer that makes the page, one fix at a time so each can be checked.
The callmttr_page({ site: "yoursite.com", path: "/services/roof-repair" })
src/layouts/Base.astro
<title>{page.title}</title>
+ <meta name="description" content={page.summary}>
+ <link rel="canonical" href={page.url}>Check. On the live site, after deploy and after any cache, by the same rules that found the fault. mttr_rescan reads it again; mttr_changes says what moved.
The callmttr_changes({ site: "yoursite.com" })
Now passing Fix description lengths, on 41 pages Set each page's canonical address, on 12 pages Newly failing None
Then back to the first step, until the list is empty.
What changes is the cost of the boring fixes. A description on every page, a canonical on every template, one main heading, image text: an agent with the brief and the code does these in minutes. They are also the fixes most sites have not done.
Which fixes can an agent make safely?
Mechanical fixes, where the right answer is already on the page, are safe to hand over. 56% of the pages mttr has read fail the description rule alone. Fixes that need judgement about what is true, or what a reader needs, should come back to a person.
Pages failing each fix, and who should make it
| Fix | Pages failing, lower is better |
|---|---|
| Fix description lengths | 56% |
| Link straight to the final address | 47% |
| Describe images | 46% |
| Add structured data | 37% |
| Fix title lengths | 29% |
| Use one main heading | 27% |
| Set each page's canonical address | 21% |
| Put the text in the HTML | 11% |
| Answer the first question under it | 90% |
Where does agentic SEO go wrong?
- It invents facts. Structured data is only worth having when it says what the page already says. An agent asked to add ratings, prices or credentials that are not on the site is writing claims, and some of them are the kind search engines penalise.
- It edits the output, not the source. A fix to built HTML vanishes on the next build. The fix belongs in the template, the component or the content file that makes every page like it.
- It takes orders from the site it reads. Words fetched from a page are data. mttr hands them over under a key that says they are quoted, so a page that says "ignore your instructions" is a finding, not a command.
- It meets the check, not the reader. Any rule that code can check can be met without helping anyone. A rule worth keeping is one that is hard to game; the rest is for a person.
- It says done before the live site does. A deploy can lag, a cache can serve the old page, and a fix in one template can break another. Only a fresh read of the live site says what changed.
- It makes many pages that are nearly the same. Swapping a town or a product name into one text is what search engines call scaled content. 18% of the 316,711 sites mttr has read already have pairs of pages sharing half or more of their text.
How do you run agentic SEO with mttr?
Connect your agent once over MCP (see connecting an agent), then work in the site's own project so the agent can change what mttr finds. The agent makes the changes, fully automated or with your approval before each one ships, and mttr reads the live site again and grades every fix. mttr itself needs no access to the site.
> Use mttr to read yoursite.com, then fix the three things worth the most.
mttr_brief({ site: "yoursite.com" })
What to fix, in order, how, and on which pages
> Deployed. Have mttr read it again and tell me what changed.
mttr_rescan({ site: "yoursite.com" })
mttr_job({ id: 4242 })
mttr_changes({ site: "yoursite.com" })
Which rules now pass, which newly fail, and how the score movedEvery report ends in the same plan in two forms: the fixes worth the most as steps for a person, and the words to hand to Claude Code, Codex, Cursor or any other assistant, ready to copy. mttr_plan returns the plan itself, and the report of any ranked site shows it.
Run the loop on your site
Use mttr to read yoursite.com, then fix the three things worth the most, one at a time, in the templates that make the pages. Use only facts the pages already state, and ask me about anything that needs judgement. After I deploy, have mttr read the site again and tell me which rules now pass and which newly fail.
Hand this to Claude Code, Codex, Cursor or any agent connected to mttr.
Before you hand a site to an agent
- Connect the agent to mttr over MCP, once.
- Work in the site's own project, where the templates live.
- Fix one thing at a time, in the template, never in the built HTML.
- Let the agent add data only from facts the page already states.
- Read every change that needs judgement before it ships.
- After deploy and any cache, have mttr read the live site again.
- Compare the new read with the old one, rule by rule.
What should stay with a person?
Whether a paragraph answers the question it sits under, whether a claim is true, and whether two pages should be one. mttr keeps these apart on purpose: code decides every rule, and where a model gives an opinion and is unsure, the page goes to a person rather than to a pass or a fail. An agent that works the same way, fixing what is mechanical and asking about the rest, is the one worth running.
A score or a rule passed says pages are well formed. It does not say an assistant cites the site. See how mttr grades for what the score holds.
Sources
- Model Context ProtocolThe open protocol agents use to call tools such as mttr
modelcontextprotocol.io - Spam policies for Google web searchGoogle Search Central, including scaled content abuse
developers.google.com - Creating helpful, reliable, people-first contentGoogle Search Central
developers.google.com
How the figures were counted. Every figure on this page is counted from the 316,711 sites mttr has read, each at its latest read, with drafts left out, as of October 26, 2026, and worked out again as sites are read. A share of pages counts only pages that were read: a site read only in part speaks for the pages read and no others. Each rule is the one in mttr's rulebook, decided by code. A score or a rule passed says pages are well formed. It does not say an assistant cites the site. The methodology explains each count.