You see a lot of “SEO systems with a dozen agents” going around. When you look at what they actually do, most of them read data, produce a list of recommendations and stop there. They write nothing to the site. And above all, they don’t measure what happened afterwards.
I built my own SEO autopilot, which I call Cortex. It runs every day on a server, even when my computer is off. What took me the most time wasn’t the “agents” part. It was the loop: observe, act, verify, measure, and be able to say whether the action was worth anything.
Here are the steps to set up a system like this, what broke on my side and how I fixed it. I give no figures drawn from my internal log: what I describe is lived experience, not a measurement. The only hard numbers come from Google’s documentation.
Key takeaways
A useful SEO autopilot closes the loop: it observes, acts on the site, rechecks live, then measures before and after. Without writing or measuring, it is a dashboard with suggestions.
A reviewer independent from the writer, who refuses often, beats a lenient check. In my case, it blocked a misleading price before publication.
According to Google’s documentation, a title change can take “a few days to a few weeks” to be picked up: the measurement window has to account for that.
A page modified during measurement has to “rest”, otherwise the effect gets mixed up. A register of manual changes prevents the system from overwriting human work.
Costs spiral quickly if every call reloads the tool’s whole context: set a budget per run, count it and log it.
What separates an autopilot from an automated report
An automated report answers “what’s wrong?”. An autopilot answers three more questions: what do we change, is the change safe, and did it work.
The last one is the question people skip the most. Yet without it, you can’t know whether the system is improving anything or just fidgeting. I started from this idea: an action without measurement before and after is not an SEO action, it is a bet.
My architecture comes down to one chain. A daily job on a server does the observation (Search Console, PageSpeed, indexing). An investigation step digs into what stands out. Then one action agent per site runs through: plan, writer, automated checks, independent reviewer, backup, write, live recheck, and automatic rollback if the check fails. Every action is entered in a register. A measurement compares the 28 days before with the 28 days after. In the morning, I receive a brief with a single decision to make.
Step 1: reliable data, and its limits
Everything starts from Search Console. A few points in the documentation change how you build the observation.
First, position. According to the Search Console help page on the performance report, the position shown is the highest one held by a link from your site, averaged over the queries concerned, and CTR is the ratio of clicks to impressions. An average position is therefore not a stable ranking: it has to be read with caution.
Next, freshness and volume. The Search Analytics API documentation states that data is generally available after two to three days, that the API exposes at most 50,000 rows per day per search type, and that results are browsed through pagination, in steps of 25,000 rows. It also specifies that the system may drop data when you group by page and by query, and that for exact totals you need to remove those dimensions. In practice: never compare an exact total with a sum of rows, and don’t measure over the last three days.
For indexing, the URL Inspection API gives the status of the version present in Google’s index. It does not test a live page. My agent must therefore not conclude “the page is indexable” from it: it observes what Google has kept, not what the site serves today.
Step 2: finding what to work on
My quick-win detection is deliberately simple. I look for pages close to the first page whose CTR is clearly below that of the other pages on the same site at the same position, brand queries aside. The idea: compare a site with itself, at equal position, rather than with an average CTR curve found online.
Setting brand aside is a methodological point. Brand queries have a very different CTR, and they would mask the signal. A page that underperforms at equal position often has a title or description that doesn’t make people want to click, or that doesn’t answer the intent of the query.
This detection produces candidates, not decisions. The investigation step checks that the page is indeed indexed, that it answers the query and that no other page on the site targets the same thing.
Step 3: agents that write, and a reviewer that refuses
This is where most demos stop. Getting an agent to write is easy. Getting it to write without breaking the site is the real work.
My setup separates the roles. One agent plans. A writer proposes. Automated checks verify what can be verified by code (length, format, presence of mandatory elements). Then an independent reviewer, who didn’t write the text, judges whether it is publishable.
This reviewer refuses often, and that is intended. It caught a misleading price before publication. It also rejected texts that paraphrased the page instead of adding something. A writer who reviews their own work validates almost everything.
When the reviewer refuses, I don’t loosen it. Instead, the writer receives the latest reasons for refusal so it can learn. Loosening the check raises the publication rate, and that is exactly what you should not optimise.
After validation come the backup of the previous state, the write, then the live recheck: the system reloads the published page and checks that the change is there and that nothing else has moved. If the check fails, the rollback is automatic. Without this last building block, I would never let an agent write.
Step 4: measuring, and protecting the measurement
The measurement compares a window before and a window after the action, on the page concerned. Two precautions cost me a lot to discover.
Let the page rest
If you touch a page again during the measurement window, you no longer know which change produced what. The system therefore enforces a rest period: a modified page is not touched again until its measurement is finished.
To set the duration, you also need to know the delay on Google’s side. According to the documentation on title links, Google has to recrawl and reprocess the page, which can take “a few days to a few weeks”. The same page reminds us that Google may generate a title different from the one you wrote if it judges that the title doesn’t reflect the page. A modified title is therefore not necessarily a displayed title: the system must be able to observe that.
The day the pilot almost overwrote my work
First flaw I lived through: the pilot only saw its own actions. It almost rewrote a page that I had modified by hand a few days earlier. It didn’t know the page was “resting”, since it was me, not it, who had touched it.
The fix is a register of manual changes, which the pilot reads before every decision. As soon as I change a page by hand, I log it there. It isn’t elegant, but it solves the problem.
Actions without a URL
Second trap: some actions concern files, such as llms.txt, the sitemap or robots.txt. They have no page URL, so no page-by-page measurement. You can only track them at site level, and the effect is hard to attribute. I record them in the register, but I don’t claim to measure their result.
Step 5: cost, before it surprises you
My first tests burned a lot of tokens. The cause: every call reloaded the tool’s entire context, with its instructions, configuration files and history, when the task needed three lines of context.
I switched to a minimal context: each agent receives what it needs for its task and nothing else. The more general lesson: a budget per run, set in advance, counted and logged. If the run goes over, it stops and alerts me. No silent compensation.
Step 6: keeping the human where it matters
The morning brief contains only one decision for me. Everything else is either done and verified, or set aside with a reason.
On a sensitive client site, I keep the go-ahead. Some sites stay in proposals-only mode: the system observes, investigates, drafts, but does not write. Autonomy is earned site by site, not all at once.
An ongoing example: mesfrais.pro
On my own site mesfrais.pro, I had the titles of a page template rewritten. The independent reviewer rejected the first version: the text wrongly promised a tax advantage on some pages. A human in a hurry might have let it through.
I then narrowed the scope to the title alone, to isolate the effect. No content change at the same time. The rollback is ready.
I don’t have a result yet. The measurement window isn’t over, and when it is, it will only say what happened on those pages, not what would happen elsewhere. I prefer to write it as it stands rather than announce a gain too early.
What I would do on Monday morning
Start with a single type of action, such as the titles of one template. A narrow scope makes the measurement readable.
Write the register before the agent: system actions, manual changes, dates, previous state. The pilot reads it before every decision.
Separate writer and reviewer, with a reviewer brief that assumes the text is to be rejected. Don’t loosen it when it refuses a lot.
Plan the rollback before the first write, and the live recheck right after.
Decide on page rest and the length of the measurement window, taking into account the delays described by Google.
Set a budget per run and cut each call’s context down to the strict minimum.
Keep proposals-only mode on sites where a mistake is costly.
Limits
This post describes a system I built for my own needs. I give no internal figures, so you can’t judge its effectiveness on my word, and I don’t claim that it improves traffic. My only case described in detail doesn’t have a result yet.
Comparing 28 days before and after remains a simple comparison. It neutralises neither seasonality, nor Google updates, nor the fact that Google may rewrite a title. A rise after an action is not proof that the action is the cause.
Finally, the documentation points cited reflect when I read them, as of the date of this article, and may change. On the pages I opened, this documentation does not give a precise quota for the URL Inspection API: check it before sizing a job.