How the SEO Agent decides what to fix

Most SEO tools give you a list of problems. The SEO Agent fixes them. This post explains how it decides what to fix, in what order, and when to stop and ask you first.

The architecture borrows its shape from autonomous driving systems: a closed loop that perceives the environment, plans an action, executes it, and then checks whether the world changed the way it expected. We run that loop continuously on every connected site.

The six phases

1. Perceive

The agent starts by building a picture of the site’s current state. It pulls from two sources simultaneously.

From Search Console it reads: which queries are driving impressions versus clicks, which pages have fallen in average position over the past 28 days, which URLs are excluded from indexing and why, and whether Core Web Vitals are flagged at the origin level.

From the live site it reads: rendered HTML (not just source, because JavaScript-rendered content matters), internal link structure, canonical tags, title and meta description presence, structured data validity, and page speed signals via the CrUX API.

The output of this phase is a structured state object, a snapshot of roughly 40 signals per page, updated on a rolling basis as the crawl completes.

2. Prioritise

Raw signal count means nothing without ranking. The agent scores each detected issue on two axes: impact and risk.

Impact is estimated from the traffic at stake. A missing title tag on a page that drives zero impressions scores low. The same issue on a page sitting at position 8 for a high-volume query scores high, because a title rewrite is one of the cheapest ways to lift click-through rate from that position.

Risk is the probability that the fix could make things worse. Changing a canonical tag on a page with complex redirect chains scores high risk. Fixing a duplicate meta description on a standalone landing page scores low.

The scoring model is not a black box. Every issue in the queue shows its impact score, its risk score, and the signals that drove both. You can inspect the reasoning before anything runs.

Issues are then sorted into three buckets:

• Auto-execute: high impact, low risk, high confidence in the correct fix
• Escalate: high impact, non-trivial risk, or ambiguous correct action
• Monitor: low impact, no action yet, watch for trend changes

3. Decide

The decision layer is where the agent earns its autonomy, or gives it up.

For auto-execute candidates, the agent runs one more check: does it have a high-confidence fix? For a missing H1, the answer is almost always yes. For a page with thin content, the answer depends on whether there is enough context about the business to generate something accurate. If there is not, the issue escalates regardless of its impact score.

Escalated issues land in your In-House dashboard as a decision card. The card shows the issue, the proposed fix, the reasoning, and the estimated impact. You approve, edit, or dismiss. The agent does not proceed without a signal from you.

This is deliberate. Autonomous execution is only useful when the agent is more likely to be right than wrong. For anything where that confidence drops below a threshold, human review is the correct default.

4. Execute

For approved or auto-execute actions, the agent writes the change and applies it through the site’s connected CMS or via a direct file update, depending on how the site is set up.

Before writing anything, it takes a before snapshot: the full rendered state of the affected URL, the relevant HTML nodes, and the current Search Console metrics for that page. This snapshot is stored and linked to the action record.

The fix is then applied. Common auto-executed fixes include:

• Rewriting title tags that are missing, duplicated, or truncated in SERPs
• Adding or correcting meta descriptions
• Fixing broken internal links (404 targets replaced with correct destinations)
• Adding missing alt text to images that appear in indexed pages
• Correcting malformed structured data (schema type mismatches, missing required fields)
• Updating robots directives on pages that were accidentally noindexed

More complex fixes, like content rewrites, redirect chain consolidation, or site architecture changes, always go through the escalate path.

5. Verify

Execution is not the end of the loop. The agent needs to know whether the fix actually landed.

Within a short window after execution, it re-crawls the affected URL and compares the live state against the before snapshot. It checks that the change is present in the rendered HTML, not just in the CMS. This matters because caching layers, CDN rules, or CMS publish delays can mean a change is saved but not yet visible to Googlebot.

If the change is not detected in the live render, the agent flags the action as unverified and raises an alert. It does not assume success.

For changes that affect indexing (canonical tags, noindex directives, structured data), the agent also watches Search Console for the URL over the following weeks. It tracks whether impressions, position, or coverage status change in the direction the fix was intended to produce.

6. Reflect

The reflect phase closes the loop and feeds back into future prioritisation.

The agent compares outcomes against predictions. If a title tag rewrite was predicted to lift click-through rate and it did, that pattern strengthens the confidence model for similar fixes on similar pages. If a fix had no measurable effect, or a negative one, the model records that too.

This is not a marketing claim about the agent getting smarter. It is a straightforward feedback mechanism: predictions are logged, outcomes are measured, and the delta between them informs future scoring. Over time, the impact estimates for a given site become more accurate because they are calibrated against that site’s actual history.

Why a loop, not a checklist

Most SEO audits are point-in-time. You run a crawl, get a report, work through it, and run another crawl in three months. The problem is that sites change constantly. New pages are published, old ones break, search rankings shift, and Google’s indexing behaviour changes.

A loop handles this. The perceive phase runs continuously, so new issues are detected as they appear rather than at audit intervals. The reflect phase means the agent is always working from the most recent outcome data, not assumptions baked in at setup.

The shape is borrowed from how autonomous vehicles handle a moving environment: constant sensing, fast prioritisation, cautious action, and immediate verification. The problems are different, but the architecture fits.

What this means in practice

For a typical SMB site, the agent runs its first full perceive cycle within a few hours of connection. Priority issues surface in the dashboard within 24 hours. Low-risk auto-execute fixes start running from day one. Higher-risk or ambiguous issues queue as decision cards for your review.

You are not handed a 200-item audit report. You see a short list of decisions that actually need a human, and a log of everything the agent has already handled.

If you want to see the SEO Agent’s queue on your own site, you can connect Search Console and a live URL from the In-House dashboard. The first perceive cycle is free.