I Built an AI SEO Agent: Here’s What I Automate and What I Keep Under Control

Appearing in an AI-generated answer starts with information the assistant can find and use: a clear offer, accessible pages, and evidence that addresses the user’s needs.
When it uses web search, the assistant can consult several sources, then cite a page or mention a brand in its summary.
You control your content and access to it, but you do not control the final answer.

For a publisher managing several sites, the work involves identifying pages that need improvement, preparing useful content, and checking what actually gets published.
An AI SEO agent can help carry out these tasks in sequence based on data and explicit rules.
It cannot guarantee that an assistant will cite the result.

This article explains how to organize this automation: what data to provide, what actions to allow, and what checks to retain before publication.
The goal is to produce verifiable improvements while keeping control of the sites.

I define the contract before giving the agent a tool

I start by specifying what the agent can decide.
I do not start by choosing a model or connecting a CMS.

The contract contains five elements.

The objective describes an observable result, such as fixing a page that is losing clicks or preparing an article that covers a validated query.
The permitted inputs list the data the agent can read.
The outputs define what it must produce, such as a diagnosis, a draft, a diff, or a validation report.
The limits specify what it cannot publish, delete, or change on its own.
The budget caps the calls, time, pages, and external effects it can consume.

This step prevents a common form of scope creep.
An instruction such as “improve my SEO” leaves too much room for interpretation.
The agent could rewrite a page that was converting, create a competing URL, or multiply paid calls without knowing when to stop.

I prefer a contract like this: “Analyze pages that are losing clicks, select one whose intent remains stable, prepare a limited correction, verify that it compiles, and present the change before publication.”

The verb “present” matters as much as the verb “fix.”
It sets the point at which the agent stops executing and I make the decision.

I distinguish the agent from the workflow around it

A deterministic workflow executes planned steps in a fixed order.
It retrieves data, applies a rule, writes a file, and runs a check.

A task queue stores work to be done and allows the process to resume after an interruption.
It does not decide by itself which task deserves attention.

A model call transforms an input into an output.
It does not become an agent simply because it receives a long prompt.

I call the component that observes a state, selects an action from several possibilities, evaluates the result, and decides whether to continue, correct, or abstain the agent.
The rest of the system should remain as deterministic as possible.

This separation reduces risk.
I ask the model to classify an ambiguous situation or prepare text.
I rely on code for binary rules, formats, quotas, tests, and access rights.

The agent can suggest that a page needs an update.
The workflow then checks that the slug exists, that the page matches the topic, that the expected file remains the right one, and that the change does not create a second competing URL.

The architecture connects data, task selection, a reversible action, human validation, and the log.

My AI SEO agent collects only the data needed to make a decision

I do not connect every available API.
Each source must answer a question in the contract.

Search Console shows queries, pages, clicks, and impressions within the scope of Google Search.
Its documentation also explains that the Search Analytics API can return top rows rather than guarantee complete coverage.
I therefore retain the dates, dimensions, and query limits with the result.

Google documents this behavior at https://developers.google.com/webmaster-tools/v1/searchanalytics/query .

I also read the indexing status when the system has an authorized source for doing so.
I never treat missing data as proof that a page does not exist or has been penalized.

Keywords and SERPs help verify intent and the pages already present.
The site’s content helps identify duplicates, internal links, and information that has already been published.
Logs help explain what the automation actually executed.
Conversion data helps prioritize pages when attribution allows for an honest interpretation.

Each collection has a date, a source, and a scope.
A metric without context quickly becomes false certainty.

I also keep data that changes over time in a database or searchable repository.
A recommendation that depends on a screenshot or a memory cannot be reproduced by the next run.

The agent selects a task and must be able to explain why it abstains

The decision starts with a list of candidates.
Each candidate represents a limited task: fixing a broken link, enriching a page that is losing clicks, preparing a missing article, or checking a page that has not been indexed.

I calculate the deterministic criteria before calling the model.
The system can eliminate a task if the page no longer exists, if another operation has locked it, if the budget has been exceeded, or if the change would require a permission it does not have.

The model then receives the remaining candidates and the relevant evidence.
It must produce a selected task, the evidence supporting that choice, a confidence level, and a possible reason for abstaining.

The confidence score is not a mathematical truth.
It serves to apply an operational rule.

High confidence can authorize preparation of the change.
Medium confidence can require additional research.
Low confidence must produce a diagnosis without any modification.

I also require a structured reason for abstaining.
Common reasons include a missing source, ambiguous intent, a conflict with an existing page, publication risk, and a cost above the budget.

An agent that can only respond with an action will always find a reason to act.
The choice “I am stopping because evidence is missing” must be part of the contract.

The agent prepares a reversible change

Once the task has been selected, the agent produces a brief that connects every change to evidence.
It does not start by rewriting the entire page.

For an article, the brief defines the intent, the questions covered, the sourced facts, the internal links, the permitted CTAs, and the prohibited claims.
For a technical fix, it defines the file, the expected behavior, the relevant test, and the limit of the diff.

The agent then works on an isolated copy.
It does not directly replace the public version.

The change must remain readable in a diff.
I want to be able to answer three questions: what is changing, why is it changing, and how does the check prove the expected result?

A reversible change also makes it possible to resume after an error.
The system can retain the draft, the diagnosis, and the logs without touching the public page.

This property turns a generation failure into useful information.
It prevents an editorial error from immediately becoming an error that readers can see.

I keep binary checks in the code

The model can assess the quality of an explanation or identify ambiguity.
It should not decide by itself that a file exists, a link responds, a test passes, or a quota remains available.

The workflow verifies these facts with deterministic checks.

It checks for the expected files.
It validates types and compilation when a change affects code.
It checks links and destinations before publication.
It rejects prohibited attributes on affiliate links.
It enforces the number and placement of CTAs when the format requires them.
It confirms that an affiliate disclosure appears exactly once.
It blocks a competing URL when an owned page already exists.

The model can explain a failure.
The code determines that the check failed.

I rerun only the affected step once the cause has been identified.
I do not ask the model to redo all the work because one link was malformed.

I limit permissions, time, and costs

Each component receives the minimum permission it needs.
An agent that prepares a draft does not need permission to publish.
An agent that reads Search Console does not need CMS credentials.

I also separate the environments.
Local work can create files and run tests.
Publication requires a separate entry point with its own check and its own log.

Every external call has a maximum duration.
A silent API must not hold up the process for hours.

Quotas cover the number of pages, the number of queries, model costs, and the number of external actions.
The system stops the batch when the budget is reached.

Idempotency provides additional protection.
If a task restarts after an interruption, it must recognize what already exists and avoid publishing the same content twice or paying twice for the same operation.

I prefer a stable key based on the task, the page, and the draft version.
The log records this key with the result.

Logs show what the agent actually did

I separate intentions from effects.
The log does not merely state that “the agent improved the page.”

It records the inputs read, the decision, the modified files, the checks, the external calls, and their results.
It also retains the reason for abstaining when no action was executed.

Secrets never appear in these records.
Customer data is removed or redacted before anything is shared.

I use three error states.

A recovered failure means that a step failed, then a targeted correction allowed the process to finish.
A block means that the system is waiting for a decision or data it cannot invent.
A final incident means that the autonomous process gives up without producing the promised result.

The final incident must become visible.
It must name the project, the entry point, the time, the observed error, the relevant log, and the next check.

A silent agent that fails during the night does not automate anything.
It simply delays discovery of the problem until the next day.

I automate repeated tasks and retain risky decisions

I automate metric collection, broken link searches, format checks, brief preparation, and the generation of isolated drafts.
I also automate checks that produce a verifiable binary result.

I retain human control over content deletion, changes to a page’s intent, publication of a sensitive claim, and changes to a commercial offer.
I also retain control over choices that involve a public identity, an expense, or a relationship with a third party.

The boundary depends on the system.
It does not depend solely on the model’s capabilities.

An action can become suitable for automation when it recurs, its inputs are reliable, its result can be measured, and rollback works.
An action remains manual when the cost of an error exceeds the quality of the available evidence.

You can apply this architecture in six blocks

You can represent the system as follows:

Data enters the system.
        ↓
The deterministic filter removes impossible tasks.
        ↓
The agent selects a task or abstains.
        ↓
The workflow prepares an isolated change.
        ↓
The checks validate facts, formats, and limits.
        ↓
Human validation authorizes the risky external effect.

This design does not require any particular framework.
Above all, it requires explicit boundaries between the model’s decision and the system’s guarantees.

You can check your agent before entrusting it with a site

You can use this checklist before the first real run.

Does the objective produce an observable result?
Do the permitted inputs have a source and a date?
Can the agent respond that it is abstaining?
Does every external action have a limit and a timeout?
Does the draft remain isolated from the public version?
Do binary checks run outside the model?
Does a restart avoid duplicates?
Does the log distinguish the decision from the actual effect?
Does a final incident become visible?
Does an identified person validate risky changes?

If any answer remains negative, I keep the task in assisted mode.
I let the agent prepare the work and retain control over final execution.

I start with a repeated, measurable, and reversible task

I do not try to build an autonomous SEO director.
I choose a task that recurs often, whose result I can measure, and whose effects I can reverse.

A link check, a data update, or the preparation of a brief provides a good starting point.
Autonomous publication of an editorial overhaul provides a poor first test.

The best sign of maturity is not the number of actions executed without a human.
It is the system’s ability to finish the authorized work, show its evidence, and stop at the right point.

The PDF guide in French now helps you choose among measurement, production, third-party visibility, and commercial management tools (ChatSEO, Semrush, HubSpot, GeoLinka, and Writesonic).

Before an AI SEO agent touches your CMS, decide what it can and cannot do. The kit’s production CLAUDE.md template shows how to set agent rules, deny-lists, and manual checkpoints so automation does not rewrite pages that already convert.

→ Get the welcome kit

This post may contain affiliate links. If you click them, I might earn a small commission (it costs you nothing and helps me keep shipping quality articles every day for your reading pleasure).