Automating SEO with AI: build a self-improving loop

Why automating SEO with AI makes sense now

Two things changed compared to two years ago. One: agents can genuinely use tools today. Where a chat model used to only produce text, an agent like Hermes can now query an API, read and write files, run a build, and read the result back. Two: that access has been standardized. With gcloud you give an agent safe read access to your Google Search Console property through Application Default Credentials, without copying tokens or sharing passwords.

SEO is an ideal application for this, for three reasons:

• The source data is objective. Search Console shows literally how people find you: queries, impressions, clicks, positions. An agent working from that data does not hallucinate market numbers — it reads actual search behavior.
• The feedback loop already exists. Thirty days after every change you see in the same data whether it had an effect. That is a perfect learning loop for a step-by-step process.
• The work is repetitive but requires judgment. Pulling and organizing data is pure routine. Interpreting and prioritizing takes judgment. That exact mix is where a supervised agent shines.

Done manually, most people pick this up once a quarter with a spreadsheet and good intentions. The agent turns it into a fixed rhythm — and rhythm is the most underrated success factor in SEO.

What you need: gcloud, GSC access, and an agent

The setup is manageable. You need four things:

• A Google account with access to the Search Console property you want to optimize. The API works with any property you can open in the interface.
• gcloud with Application Default Credentials. After a one-time gcloud auth application-default login, the agent can query the Search Console API under your read permissions. You release nothing more than necessary: read only, this API only.
• An agent that can use tools. Think of Hermes from Nous Research — an open agent that runs on your own machine, handles files and shell commands, and receives or learns skills. Comparable options: Claude Code, Cursor agents, or your own script around a language model with API access.
• A place where the changes live. A git repository is ideal: every run becomes a small, reviewable commit with a description of why.

The second point deserves emphasis, because it is the difference between a safe and a reckless setup. You do not want a service account with broad permissions, no API keys in config files, and no agent writing directly to production. Read-only access to Search Console through ADC, and all changes through your own codebase with a review step around them. That keeps the agent a colleague who advises and prepares work — not an anonymous machine that rebuilds your website at night.

Stap 0101

The loop: pull the data

Every run starts the same way: the agent pulls fresh Search Console data for a bounded period — say the last thirty days, or a comparison with the thirty days before that. It requests the top queries per page, with impressions, clicks, CTR, and average position, and writes that away as a structured file in the repo. From that moment it no longer works with live APIs but with a snapshot you can inspect and compare against previous runs.

One important detail: Search Console data only becomes final after a few days. Google itself says about fresh data points: “Each fresh data point will be replaced with the final data point after a few days” (Google Search Central Blog on data freshness). Measure too early and you draw conclusions from numbers that still shift. That is why the agent works with closed periods and preferably compares month over month, never day over day.

Stap 0202

Prioritize: where is the biggest win?

With the data on the table, the agent looks for patterns worth a decision:

• Many impressions, few clicks on a query your page already ranks for: usually a title or meta description problem, not a content problem.
• Position 8 to 20 with a declining trend: the page is relevant enough to rank but not convincing enough to break through. Sharpening the search intent and internal links helps here.
• Queries you have no good page for: content gaps. Those lead to a new article or an expansion of an existing page — not keyword stuffing on some random page.
• Multiple pages competing for the same query: cannibalization. Strengthen one page, give the other its own angle.

For each finding the agent states a hypothesis: this page, this query, this expected intervention, this expected effect. No more than one or two per run. If you change ten things at once, you will never know what worked.

Stap 0303

Make one small improvement

Then comes the human moment. The agent prepares the change — a rewritten intro that puts the real search intent first, a better title tag, an internal link from a strong page — and for now you always review it. The change is deliberately small: one page, one aspect, describable in one sentence. “This intro now promises what the searcher actually asks for.” Not: “The entire page optimized.”

Next, the agent verifies its own work. For a website in git that means: commit the change, run the build, fetch the changed route again, and confirm the promised text is actually there. A successful tool call is not a successful task; the run is only complete when the published page checks out.

Stap 0404

Measure and log

Every run ends in a log: what the agent saw in the data, what it changed, what the expected effect is, and when to check it. Ideally in your issue tracker, so that thirty days later an on-the-record comparison is possible. Did the intervention raise the CTR on that one query? Did the position move from 14 to 9? Or did nothing happen — and why not?

That logging is not administrative luxury. It is the only way to learn from the agent and to teach the agent. Because every time a hypothesis does not pan out, it says something about your instructions: was the prioritization wrong, the intervention too small, or the expectation too high?

Stap 0505

Repeat every 30 days

A single run does little. The power is in the repetition. After six cycles you have six verified improvements, six measurement moments, and a growing archive of what did and did not work. Along the way your pages have gradually been tuned to the real search intent of your visitors — not to your assumption of what they search for, but to what the data shows they search for.

Why thirty days and not every week? Because Search Console data only finalizes after several days and positions show too much noise week over week. Thirty days gives a signal you can act on, and it matches the pace of content changes: thorough enough to matter, slow enough to measure cleanly.

From supervising to automatic: be realistic

This needs honesty: the first time, this does not work. The first run of a new agent rarely produces anything publishable. The data gets misinterpreted, the prioritization misses, the proposed copy reads like a committee memo. That is not the concept failing — it is the onboarding period.

Expect a learning curve in three phases:

How you speed up that curve: give the agent skills. An agent like Hermes works with reusable instruction packages — how to structure a page audit, how to interpret search intent, how to rewrite a title without clickbait. You teach those once, and every next run builds on them. After a few months those skills are the difference between an intern and a colleague: the process is in its fingers, and you only look over its shoulder for the hard cases.

From that moment on, you turn the loop into a cron job: a scheduled task that runs the agent on a schedule — say the first of every month. The run follows the same rules as when you sat next to it, only without you having to be there. Hard decisions (new pages, major rewrites, anything touching money or reputation) stay explicitly human.

Skills: teaching the agent how to run SEO audits

The fastest way to climb that curve: give the agent skills — reusable instruction packages that describe one task in detail. A skill for a page audit specifies exactly what data gets pulled (live HTML, Search Console rows, robots.txt), which dimensions get scored (search intent, E-E-A-T, content depth, on-page, structure, technical), with what weights, and in what format the report appears. You write such a package once, or teach it from an existing collection. After that, the agent runs every next audit in exactly the same way — including the cron run in the middle of the night.

Here is what such a report looks like in practice. The output below is the literal page audit the agent ran on this page on the publication date, taken over one to one — scores, priorities, E-E-A-T assessment, everything:

Note what is in it: the audit knows the page has no Search Console data yet (published that same day) and says so honestly instead of inventing numbers. That kind of discipline lives in the skill, not in the model — and it is the difference between a report you trust and one you have to double-check. Every finding comes with a concrete fix; today’s GSC baseline becomes the measuring stick for the first remeasurement thirty days from now.

What an agent may and may not do on its own

Automation without boundaries is a risk, especially on something as visible as your website. A few rules of thumb that work in practice:

• Read permissions for data, write access through git. The agent reads Search Console, but every change goes through your codebase and review flow.
• Small commits. One change per run, with explanation. Not because the agent cannot do more, but because otherwise you lose the measurement effect.
• No invented numbers. Every metric in copy comes from the actual data export, with period and source attached. An agent that smooths over or invents numbers is useless for this work.
• Human decisions stay human. Merging pages, restructuring key landing pages, changing prices or promises: do not automate.
• Useful stays useful, even at speed. Google’s guidance on AI-generated content stresses that automation changes nothing about the requirement that content be made for people and be genuinely helpful — regardless of who or what wrote it.

For a broader look at deploying such an agent without losing control, read What is an AI agent?. And for the bigger picture around recurring work: Workflow automation.

Where the change lands: MCP into your CMS, or Git for your Astro site

So far, every improvement went to “your codebase”. But where exactly the agent writes depends on how your website is built — and that is less complicated than it sounds. Broadly, there are two routes.

Route one: your site runs on a CMS. Then you want the agent to work directly in that CMS, and for that you use MCP: the Model Context Protocol, an open standard that connects AI applications to external systems in a structured way. An MCP server for WordPress or Storyblok offers the agent a limited, explicit list of functions — create a draft, update a field, publish a page — with matching permissions. That way the agent can adjust a page on its own after an approved analysis, but only through the doors you open. And because every CMS draft starts as a draft rather than going live immediately, you keep a natural review step.

Route two: your site is static, like this one. Straffe Sites runs on Astro with Content Collections: every page and article is a file in a git repository, with strict schemas as the quality gate. Here the agent does not edit a CMS but the files themselves — update frontmatter, rewrite an intro, add an internal link — and every change goes straight through the schema and build checks. Each run becomes a small commit you can read, revert, or approve. No database, no admin screen; the repository is the CMS.

Both routes end in the same place: one small, verified change per run, with a human eye on it before it goes live.

Further reading by topic:

• What is a headless CMS? — when managing content separately from the frontend makes sense, and what it means for AI workflows
• WordPress maintenance — what periodic maintenance on a CMS site involves, and where an agent can help

Plan B if the loop does not take off

Sometimes it does not work. The data is too thin (less than a few hundred impressions a month), the market too competitive, or the agent keeps making silly choices after months of course-correcting. Then the honest conclusion is: automation adds no value here.

But you still win. Because the agent still functions as an analyst: it pulls your data monthly, flags the notable movements, and puts it all in a fixed report. You do the interpretation and the changes yourself, once a quarter. That is not a self-improving loop, but it is a return on your onboarding time — and sometimes that is the realistic picture for a small website. Start small, measure honestly, and let the automation earn what it is worth.