Agentic SEO · 7 min read ·
How to Build an AI SEO Loop with the Potatometer MCP
Potatometer's MCP server puts SEO and GEO scans inside Claude and Claude Code, so you can baseline, fix, ship, and verify without leaving the session.
Most site audits die in the gap between the report and the repo.
You run a scan, you get a list, you paste the list into a doc, and then the work moves somewhere else: a terminal, a Shopify theme editor, a Lovable project. By the time anything ships, nobody re-runs the scan. So there is no way to know whether the fix worked, or whether the change that shipped last week quietly broke something a crawler cared about.
The Potatometer MCP closes that gap. The scan now runs in the same place the fixing happens.
What the MCP actually is
Potatometer's MCP server exposes two tools to any MCP client, including Claude, Claude Code, and Cursor:
- analyze_website runs a full scan on one URL and returns the SEO score, the GEO score, the per-category breakdown, every check with pass or fail, and a ranked fix list with points, difficulty, and time to fix.
- compare_sites scans two to five URLs and returns their scores side by side.
Same engine as the web scan. Same deterministic checks. No summarising layer in between, and no model guessing at a number.
One MCP scan, end to end: your session (Claude, Claude Code, Cursor) calls analyze_website, the Potatometer MCP server runs the deterministic scan engine (fetch, headless render when needed, PageSpeed, 41 rule-based checks, no model), which reads your live site without writing to it, and the unmodified report returns into the same session with SEO and GEO kept separate.
Free accounts get 10 scans a day through the connector. Pro raises that to 100 a day and unlocks bulk compare.
Setup: sign in at potatometer.com, open your Account page, and generate your personal connector URL in the MCP Connector section. In Claude, open Settings, then Connectors, then Add custom connector, and paste that URL. In Claude Code, run the one-line claude mcp add command shown on the same card. Once connected, the tools show up in any new chat or session.
The loop, in four steps
The four step loop: 01 baseline scan, 02 fix, 03 ship, 04 verify with a re-scan. Because the scoring is deterministic, a delta between scans is a real delta. Most audits stop at step 02; the loop only compounds if step 04 runs.
1. Baseline
Ask for a scan before you change anything. The point of a baseline is not the score, it is the specific set of failing checks you can hold a later scan against.
"Scan example.com with Potatometer and show me the failed checks only."
We ran this on ourselves the day the connector went live. potatometer.com came back at 89 on SEO and 93 on GEO: 36 checks passed, 5 failed, 4 fixes worth having. AI crawlability, structured data, and content structure were full marks. Content depth was 11 out of 18, mostly because the homepage carries no imagery and no original data.
Baseline scan of potatometer.com: SEO 89/100 and GEO 93/100, 36 checks passed and 5 failed, two scores never blended. SEO categories: Technical SEO 44/48, On-Page SEO 30/30, Content SEO 15/22. GEO categories: AI Crawlability 40/40, Structured Data 22/22, Content Structure 20/20, Content Depth 11/18.
That is a useful thing to publish about your own product. The scan does not flatter anyone, including us.
2. Turn the fix list into work
This is the step the MCP changes most. The fix list arrives inside the session that is going to write the code, with the evidence attached, so you are not re-describing the problem to your coding agent from memory.
"Take the three highest-impact GEO fixes from that scan and implement them in this repo. Show me the diff before you touch anything."
Each recommendation carries its own points gain, difficulty, and estimated time, so the agent has a real basis for sequencing rather than doing whatever it saw first.
| Fix | Axis | Effort | Points |
|---|---|---|---|
| Add images, video, or other media | GEO | Easy · 1 hour | +6 |
| Add a byline and author schema | SEO | Easy · 1-2 hours | +4 |
| Add original statistics and findings | GEO | Medium · 2-4 hours | +4 |
| Get page load under three seconds | SEO | Medium · 4 hours | +1 |
Two of ours were worth doing that afternoon. One was worth putting on the content calendar. One, at plus 1 point for four hours of work, was worth ignoring for now, which the numbers make obvious.
Ask for the diff first. The scan tells you what is wrong, not what your codebase can absorb.
The diagrams in this post are two of those fixes, shipped. Media on the page and original data, both flagged by our own scanner.
3. Ship
Nothing special here, and that is the point. The MCP does not deploy anything for you. It writes nothing to your site. It reads, scores, and hands the result to whatever you already use to ship.
4. Verify with a re-scan
"Re-scan example.com and tell me which checks changed since the last scan."
This is the step that makes the loop a loop, and it only works because the scoring is deterministic. Same site, same external state, same score, every time. There is no randomness and no model in the scoring path, so a three point move is a real three point move rather than sampling noise. If a check flips from fail to pass, something you did caused it.
One caveat worth knowing: renders are cached for seven days per URL. If you shipped a fix ten minutes ago and want to confirm it immediately, use the force-fresh re-scan on your own site rather than expecting the cached render to reflect a change you just pushed.
Running the loop on a schedule
Once the scan is a tool call, it stops being a thing you remember to do and becomes a thing that happens.
Two patterns that work:
Pre-deploy check. Before a release goes out, scan staging and the current production URL, then diff them. Rendering regressions are the ones that hurt most and show up least: a route that quietly stops server-side rendering looks fine to you and looks empty to a crawler that does not run JavaScript.
Weekly competitive read. Run compare_sites on yourself and up to four others, on the same day each week. Positions move slowly, so the value is not the snapshot. It is noticing the week somebody's GEO score jumps 15 points, then going to find out what they shipped.
"Compare our site against these three competitors and tell me the categories where we are behind."
We ran ourselves against two other tools in the AI search category. We came second.
| Site | SEO | GEO |
|---|---|---|
| tryprofound.com | 93 | 99 |
| potatometer.com | 89 | 93 |
| athenahq.ai | 87 | 90 |
Note what the chart does not show: a single blended number. compare_sites returns a composite, and we leave it out of writeups like this one, because SEO and GEO answer different questions and averaging them hides which one you are losing.
Prompts that hold up
Short and specific beats clever. A few that work well:
- "Scan these five product pages and tell me which one is weakest for AI crawlers, and why."
- "Scan our homepage, then write the JSON-LD needed to fix every structured data check that failed."
- "Compare our blog against these two competitors on GEO only. Ignore SEO."
- "Scan our site and turn the fix list into GitHub issues, one per recommendation, with the evidence in the body."
One thing to be careful about
An MCP tool inside a chat makes it easy to blur the line between what was measured and what was inferred.
The scan output is measured. Every pass or fail comes from real fetched or rendered content, or a real API response. Checks that cannot run are marked not evaluated rather than guessed. The scores and the checks in that report are ground truth.
Anything the assistant says around the report is inference, and inference is where fabricated numbers creep in. If you ask a model to estimate how a fix will affect your traffic, or to predict a score before scanning, you will get a confident number with nothing underneath it. That is the exact failure mode Potatometer exists to avoid.
Scan first. Then reason about the result.
The short version
The diagnosis was never the hard part. Getting the diagnosis to the place where work happens, and then closing the loop by measuring whether the work landed, is the hard part.
Baseline, fix, ship, re-scan. Four steps, one session.
The connector is live now, 10 scans a day on the free tier. If you set it up and the loop breaks somewhere we did not anticipate, tell us at hello@potatometer.com.