I Gave a Claude Code Agent My Search Console Data: An Agentic Technical-SEO Triage Experiment
Every technical SEO team has the same backlog problem: Search Console surfaces hundreds of small issues — pages slipping from position 8 to 14, queries with a 1.2% CTR that should be doing 4%, indexing warnings that pile up faster than anyone can triage them. The work is not hard. It is just relentless, and humans are expensive to point at relentless, low-creativity triage.
So I ran an experiment. Instead of writing yet another single-purpose Python script, I handed the whole messy job to an autonomous agent — Claude Code with filesystem and shell access, plus a thin set of tools to reach the Google Search Console API — and gave it one brief: “Find the highest-leverage technical and on-page issues in this property and propose fixes I can approve.” This is a teardown of what happened, what the agent got right, where it went off the rails, and the guardrails that turned it from a novelty into something I actually re-run weekly.
Why an agent instead of a script?
A script does exactly one thing. The striking-distance finder finds striking-distance keywords; the 404 monitor finds 404s. Each is great, and each requires a human to decide which script to run, in what order, and what to do with the output. That orchestration layer — “look at the data, decide what matters today, chain three tools together, summarize” — is precisely the judgment work that an LLM agent is suited for.
The bet was that a model with tool-use could replace the analyst-glue between scripts, not the scripts themselves. So I didn’t ask the agent to invent crawling from scratch. I gave it a toolbox of small, deterministic functions it could call, and let it decide the strategy. This is the same philosophy behind comparing orchestration platforms in our n8n vs Make vs Zapier teardown — the value is in the connective tissue, not any single node.
The setup: a constrained toolbox, not a blank shell
The single most important design decision was limiting what the agent could touch. An agent with raw shell access and a production API key is a liability. So the toolbox exposed exactly four read-only capabilities and zero write capabilities:
tools = [
gsc_query(dimensions, date_range, row_limit), # Search Analytics API
gsc_inspect_url(url), # URL Inspection API
fetch_url(url), # plain GET, 10s timeout
read_sitemap(sitemap_url), # parse <loc> entries
]
# Deliberately ABSENT: anything that writes, deploys, or edits the live site.
The agent ran in a loop: it called a tool, read the result, reasoned about the next step, and called another. Its only required output was a structured Markdown report — a ranked list of findings, each with the evidence it used, a proposed fix, and a confidence score. Nothing it produced touched the live site. That separation between diagnose and deploy is the whole safety model, and it mirrors the redirect-suggestion pattern we use in automated 404 monitoring: the machine proposes, a human disposes.
What the agent actually did
Pointed at a ~600-URL content site, the agent’s unsupervised run took about nine minutes and 41 tool calls. The interesting part was the order it chose without being told to. It pulled the last 28 days of Search Analytics first, clustered queries by landing page, and immediately flagged the cohort of pages sitting in positions 8–20 — the classic striking-distance band — because, in its words, “marginal rank gains here convert directly to traffic.” Only then did it start inspecting individual URLs.
Three findings stood out as genuinely useful:
1. A title-tag truncation pattern. The agent noticed that eleven striking-distance pages shared a template whose titles ran past 60 characters and got truncated in the SERP, with the differentiating keyword falling off the end. It cross-referenced the impressions-to-clicks ratio and ranked this as the highest-leverage fix: small change, eleven pages, measurable CTR upside. No single script I owned would have connected “title length” to “CTR gap on this specific cohort” — that synthesis was the agent’s.
2. An orphaned high-impression page. Using read_sitemap plus a shallow crawl via fetch_url, it found a page earning thousands of impressions that had zero internal links pointing to it. It proposed three contextually relevant source pages for new internal links, with anchor text suggestions. This overlaps with what a dedicated internal-linking engine does, but the agent found it as a byproduct of investigating something else.
3. A canonical mismatch. gsc_inspect_url reported Google had chosen a different canonical than the page declared, on a paginated archive. The agent correctly identified this as a self-referencing canonical bug and explained the indexing consequence in plain language.
Where it went off the rails
It was not magic. Two failure modes showed up reliably, and naming them is the actual deliverable of this experiment.
Confident hallucination of fixes. For the canonical issue, the agent’s diagnosis was correct but its proposed code referenced a templating system the site doesn’t use. Left to “just fix it,” it would have happily edited a file that doesn’t exist. This is the entire argument for the propose-don’t-deploy boundary. An agent’s confidence is uncorrelated with its correctness on implementation specifics, so the human approval gate is not optional — it is the product.
Tool-call thrash. On the first run, without a budget, the agent re-inspected the same twelve URLs three times, burning API quota and minutes, because nothing told it “you already have this data.” Adding a simple in-loop cache and a hard cap of 50 tool calls fixed it. Agents do not naturally economize; you have to impose the budget.
The results, measured honestly
I approved seven of the nine proposed fixes (rejecting the two that depended on hallucinated implementation details) and shipped them manually. Over the following three weeks:
- The eleven retitled pages gained an aggregate +0.9 average position and roughly +18% clicks on their primary queries — modest, but real, and exactly the kind of marginal gain that is too small to prioritize manually across hundreds of pages.
- The orphaned page picked up internal links and moved from page 2 to the bottom of page 1 for its head term.
- Total human time spent: about 25 minutes of review versus an estimated 3–4 hours to do the same triage by hand.
The headline isn’t “the agent did SEO.” It’s that the agent collapsed the triage-and-prioritize step — usually the most procrastinated part of technical SEO — into a nine-minute background job whose output a human can vet in a coffee break.
How to reproduce this responsibly
If you want to run your own version, the pattern matters more than the specific model. Keep the agent on a tight leash and you get most of the upside with little of the risk.
- Expose read-only tools only. Wrap the GSC API and a fetch function. Grant no write, deploy, or edit capability. If you want background on the GSC API surface itself, our comparison of the GSC, SEMrush, and Ahrefs APIs covers the trade-offs.
- Demand structured output. Require a ranked report with evidence and a confidence score per finding. This makes the agent’s reasoning auditable and forces it to justify rankings.
- Cap the loop. Hard limit on tool calls, plus an in-memory cache so it never re-fetches identical data. Budgets prevent thrash and protect your API quota.
- Gate every write behind a human. The agent proposes; you approve and ship. Treat any code it generates as a draft to verify against your real stack, not a patch to apply.
- Log every tool call. When a finding looks wrong, you want the exact API responses it reasoned from.
Run it on a schedule — weekly is plenty — and you get a standing technical-SEO analyst that never skips the boring triage. The fixes still need your judgment, and the schema, rank, and crawl scripts it leans on still need building. But the glue work, the part nobody wants to do, is now a background process.
Takeaways
Agentic SEO is not about replacing your scripts or your judgment. It is about automating the analyst layer in between — the part that decides what to look at, chains the tools, and writes up what matters. Constrain it to read-only diagnosis, force structured and auditable output, budget its loops, and keep a human on every write. Do that, and an agent earns its place in the stack: not as an oracle, but as a tireless triage analyst whose homework you grade in twenty minutes instead of doing in four hours.
Found this useful? Bookmark SEO Automation Club and check back for weekly automation playbooks — working code and real workflows, never generic listicles. If you build SEO pipelines with LLMs, you’ll also want our deep-dive on automating schema markup at scale with a Python + LLM pipeline.
Frequently Asked Questions
Is it safe to give an AI agent access to Search Console?
Yes, if you scope it correctly. The Search Console API supports read-only access, and you should wrap it in tools that can only query — never write or change settings. The risk comes from giving an agent deploy or edit capability on your live site, not from letting it read analytics data. Keep diagnosis and deployment strictly separated.
Which model should I use for agentic SEO triage?
Any frontier model with reliable tool-use and a large context window works. The pattern — a constrained toolbox plus a structured-report requirement — matters far more than the specific model. The agent’s job is orchestration and synthesis, which most current top-tier models handle well; the deterministic work stays in your tools.
Can the agent actually fix the issues it finds?
Treat anything it generates as a proposal, not a patch. In testing, diagnoses were frequently correct while the implementation code referenced systems the site didn’t use. Always keep a human approval gate before any change reaches production, and verify generated code against your real stack.
How is this different from just running individual Python scripts?
Scripts each do one fixed task and require a human to choose, sequence, and interpret them. An agent replaces that glue: it decides which checks matter today, chains the tools together, and writes a prioritized summary. You still build the underlying read-only tools — the agent supplies the judgment layer on top.
