Loop engineering for SEO: improve one page at a time

A useful loop does not publish because the agent sounds confident. It stops for proof—or for a person.

Most AI-for-SEO demonstrations end in the same place: type a keyword, generate an article, publish it, repeat.

That is not loop engineering. It is a content generator with a repeat button.

A properly engineered SEO loop is almost the opposite. It starts with evidence from your own site, selects one existing page, proposes one bounded improvement, runs technical and editorial checks, stops for human approval, records what happened, then waits long enough to see whether a predefined measurable outcome improved.

The goal is not more content. The goal is a better decision on the next pass.

I recently wrote a general introduction to AI agent loop engineering. This article takes the next step: one concrete SEO loop I would be comfortable operating on a real website.

Table of contents

What loop engineering changes

Addy Osmani’s recent description of loop engineering is useful because it moves the engineer one level above the prompt. Instead of personally telling an agent what to do next, you design a small system that discovers work, hands out a bounded task, checks the result, remembers the state and decides whether to run again.

The term is still new, but the engineering pattern is familiar:

1. Discover a fresh signal.
2. Frame one task with constraints and acceptance criteria.
3. Act inside a narrow permission boundary.
4. Verify with evidence that does not depend only on the maker’s opinion.
5. Persist the result so the next run does not start from zero.
6. Stop, wait, escalate or repeat according to explicit rules.

A prompt sits inside that system. It is no longer the whole system.

No measurable outcome, no learning loop

Before the first run, give the loop a measurement contract. It should define:

• the observation source;
• one primary outcome metric;
• guardrail metrics that must not deteriorate;
• a baseline and comparison window;
• the minimum amount of evidence required to make a decision; and
• the conditions for waiting, revising, escalating, reverting or stopping.

Without that contract, the system can repeat, but it cannot learn from the consequences of its work. It will optimise for the easiest visible activity—articles generated, changes shipped or budget spent—rather than the result the business actually values.

Here, “learn” does not necessarily mean retraining the underlying model. It means operational learning: the loop reads an outcome, compares it with the stored baseline, records the decision and uses that state to choose its next action.

Different loops therefore need different evidence:

These are candidate metrics, not universal prescriptions. The metric must match the objective. Search impressions can show demand, but they do not prove that a visitor found value. Page views can show consumption, but they do not prove conversion. Cheap clicks can look efficient while producing no qualified outcome.

Why SEO is a good example—and a dangerous one

SEO fits a loop because the work recurs and the environment talks back. Search Console exposes impressions, clicks, click-through rate and average position by dimensions such as page and query. Your site can expose broken links, accidental noindex rules, duplicate titles, missing canonicals and build failures. A later measurement window can show whether a change deserves another pass.

But SEO also shows exactly why loops need guardrails.

Google’s guidance asks creators to focus on helpful, reliable, people-first content, not pages made primarily to gain rankings. Its spam policies explicitly call out scaled content abuse: producing many low-value or unoriginal pages to manipulate search results, whether the pages were made by AI, people or another process.

The safe automation boundary is therefore deliberate: let the loop discover, analyse, draft and check. Keep publication behind a person until the operating evidence proves that a narrower gate is safe—and for brand, legal or expert claims, I would keep that human gate permanently.

Write the loop contract before choosing the model

I would start with a plain contract like this. It is a design document, not runnable framework configuration:

name: improve-one-existing-seo-page
trigger: weekly manual review
goal: improve one useful existing page for a query it already serves
discovery:
  source: Google Search Console final data
  comparison_window_days: 28
  maximum_candidates: 5
measurement:
  primary_metric: useful page-query clicks
  diagnostic_metrics:
    - impressions
    - click-through rate
    - average position
  downstream_guardrail: GA4 organic landing-page key-event rate
  baseline_window_days: 28
  comparison_window_days: 28
  minimum_evidence: defined by the owner before the run
selection:
  pages_per_run: 1
  requires_human_choice: true
allowed_changes:
  - clarify the title and introduction
  - answer one evidenced reader question
  - add one relevant internal link
  - repair a verified technical issue
verification:
  - site build passes
  - links resolve
  - page remains indexable and canonical is correct
  - claims have sources or first-hand evidence
  - change adds value beyond rewording competitors
limits:
  revision_attempts: 3
  automatic_publish: false
remeasure_after_days: 28
terminal_states:
  - approved_to_publish
  - wait_for_data
  - needs_human
  - no_useful_change
  - budget_exhausted

This is intentionally boring. That is a compliment.

The contract defines the source, scope, permitted changes, checks, budget and stopping states before a model has a chance to improvise them. A more capable model may improve the draft, but it should not quietly rewrite the operating rules.

The content change is only one frame. Discovery, checking, approval and measurement are the rest of the system.

The SEO loop, step by step

1. Discover from first-party evidence

The loop reads finalised Search Console data for the previous 28 days and compares it with the preceding 28-day window. It can group by page and query, then look for signals such as:

• an existing page receiving meaningful impressions for a relevant query but few clicks;
• a formerly useful page losing clicks while its topic remains important to the audience;
• two pages competing for the same intent;
• a query exposing a question the current page only answers indirectly; or
• a technical regression that makes a valuable page harder to crawl or understand.

The official Search Analytics API supports dimensions, filters and date ranges, but it does not guarantee every data row; it generally returns top rows within internal limits. Recent data may also be incomplete. A responsible loop records those limitations instead of turning a partial dataset into a confident site-wide conclusion.

This discovery stage should use your own Search Console property and site evidence. It should not send automated queries to Google Search to scrape rankings; Google’s spam policies prohibit machine-generated search traffic without permission.

2. Frame one candidate, not a vague mission

“Improve SEO” is not a task. “Review this existing page for this observed query-page mismatch” is.

The handoff should contain:

• the page and the audience it is meant to help;
• the relevant queries and measurement window;
• the page’s current title, description, headings and internal links;
• the site’s subject-matter boundaries and sources;
• exactly which files may change;
• the checks that must pass; and
• the reasons the loop must stop for a person.

I would allow only one page per run at the beginning. Small scope makes the diff readable and the result attributable. If five pages and twelve templates change together, even a positive graph will not tell you which decision worked.

3. Let the maker propose the smallest useful change

The agent may discover that the page already answers the query well and needs no edit. no_useful_change is a successful terminal state; it prevents the loop from creating work to justify its existence.

When a change is justified, I would prefer this order:

1. repair a factual or technical defect;
2. make the title and opening accurately describe the page;
3. surface an answer that already exists but is buried;
4. add missing first-hand evidence, an example or a useful comparison;
5. improve a relevant internal path; then
6. create a new page only when the intent is genuinely distinct and the site has something original to contribute.

Google recommends descriptive, concise titles and warns against keyword stuffing and boilerplate title text. The loop should therefore explain why a proposed title is more accurate for a person—not simply count keywords.

4. Use two kinds of verification

Technical verification can be deterministic:

• the site builds;
• the route returns successfully;
• internal links resolve;
• the canonical URL is unchanged unless the brief explicitly allows it;
• the page remains indexable;
• structured data, if present, validates; and
• the diff touches only the approved scope.

Editorial verification needs a narrow rubric and preferably a different reviewer:

• Does the change answer the observed intent more directly?
• Is there original experience, evidence or analysis?
• Are factual claims supported?
• Would the page still be worth publishing if search traffic did not exist?
• Has the maker added genuine value, or just made the text longer?

The maker should not be the only judge of its own draft. A second agent can flag issues, but a person who understands the product, audience and claims should own the publish decision.

5. Publish through a human gate

The loop presents a compact packet: baseline data, reason for selection, before/after diff, verification results, risk notes and the proposed measurement date.

The reviewer can approve, reject, edit or return it with one specific request. Rejection also becomes state; next week’s loop should not rediscover the same bad idea as though nothing happened.

Submitting a sitemap after publication can help discovery, but Google is clear that a sitemap is only a hint. It does not guarantee crawling or indexing. A loop should never label a page “indexed” merely because it submitted a URL.

6. Wait, measure and write the result back

SEO feedback is slow and noisy. The loop should not revise the same title every morning because yesterday’s click-through rate moved.

Choose the measurement source according to the part of the journey you are changing:

• Google Search Console shows how a page appears in organic search through impressions, clicks, click-through rate and average position. It is useful for query-page discovery and search visibility, not for proving a business outcome after the click.
• Google Analytics can measure what happens on the site through sessions, engaged sessions, key events, key-event rates and revenue metrics. It can tell the loop whether additional traffic remains engaged or completes an intended action.
• What people often call separate Facebook Ads or Instagram Ads reporting is normally managed through Meta Ads Manager. For a paid-social loop, the primary metric might be qualified leads, purchases, conversion value or cost per result; reach, impressions, frequency, clicks and spend are supporting diagnostics rather than success by themselves.

Do not pour every available number into the objective. Select one primary outcome, then use a small set of diagnostics and guardrails to explain it. Otherwise the loop can cherry-pick whichever metric improved and declare itself successful.

For a modest site, I would choose a 28-day comparison window as an operating decision—not a Google promise—and use finalised data. Record the baseline, publication date, change, checks and next measurement date. When the window closes:

• done if the page remains useful and the target signal improves without a concerning trade-off;
• wait_for_data if impressions are too low or data is incomplete;
• needs_human if position, demand, seasonality or another change makes attribution unclear;
• revise if there is one evidence-backed next action and the attempt budget remains; or
• stop after three revisions rather than tuning forever.

That state is the difference between a loop and repeated amnesia.

A worked SEO example

Imagine an on-premises AI consultancy with an existing page called /private-ai-deployment/. The following numbers are fictional, chosen only to make the decision visible.

The page receives 12,400 impressions and 190 clicks over 28 finalised days for a cluster that includes “private AI deployment checklist”. That is a 1.53% click-through rate, with an average position of 7.8. The measurement contract selects relevant organic clicks as the primary metric, while the page’s Google Analytics key-event rate acts as a downstream guardrail: attracting more clicks is not a win if the visitors immediately disengage or stop completing the intended action.

Those numbers do not prove the title is bad. Position, device, result layout, brand familiarity and query intent all affect clicks. They are enough to create a review candidate, not enough to authorise a rewrite.

The loop packages the page and discovers three things:

1. the title says “Our AI services”, which does not describe the page clearly;
2. a real deployment checklist exists halfway down the page, based on the team’s work, but the introduction never signals it; and
3. a related security article has no internal link from this page.

The maker proposes one bounded revision:

• use a descriptive title that accurately names the private AI deployment checklist;
• move a concise summary of the existing checklist near the opening;
• retain the first-hand deployment notes and their limitations; and
• add one relevant internal link to the security article.

It does not invent twenty location pages, repeat the phrase in every heading or manufacture client results.

After technical checks and human approval, the page is published and the baseline is stored. Twenty-eight finalised days later, one of three things may happen:

The point is not to promise an SEO lift. The point is to make every next action traceable to evidence.

What an SEO loop can reasonably do

Once the supervised version is reliable, the same pattern can help with:

• opportunity triage: rank a small review queue from Search Console signals;
• content maintenance: identify pages with outdated facts, dead references or changed product behaviour;
• technical regression checks: surface broken links, accidental indexability changes, missing canonicals or invalid structured data;
• internal-link suggestions: connect genuinely related pages, subject to editorial review;
• snippet experiments: propose clearer titles and descriptions for existing useful pages;
• content consolidation: identify overlapping pages for a person to merge or redirect; and
• reporting: explain what changed, what evidence exists and which items are waiting.

The loop is strongest when it turns a large, vague backlog into a small, inspectable decision queue.

What it should not do

A loop amplifies its objective. “More pages” and “more evidence” create very different systems.

I would not let an SEO loop:

• publish large batches of AI-generated pages;
• scrape Google Search results through automated queries;
• invent expertise, authors, reviews, customer outcomes or citations;
• change canonicals, redirects, robots rules or sitemaps without review;
• judge success from average position alone;
• rewrite pages merely to make them look “fresh”;
• resubmit unchanged sitemaps repeatedly; or
• continue spending after evidence becomes ambiguous.

These are not edge cases. They are the obvious direction of travel when speed is rewarded and quality is only a sentence in the prompt.

How I would start on Monday

Do not begin with a scheduler. Begin with a spreadsheet or small state file and run the loop manually once a week.

1. Choose one primary measurable outcome and two or three guardrails.
2. Record their definitions, data sources, baseline and comparison window.
3. Pull one 28-day Search Console comparison using final data.
4. Ask the loop for no more than five candidates and the evidence for each.
5. Choose one existing page yourself.
6. Allow one bounded change and require a readable diff.
7. Run technical and editorial checks.
8. Publish only after human approval.
9. Write the result and next measurement date into state.
10. Repeat this manually for six cycles before automating discovery.

By then, you will know which rules were missing, which signals were noisy and whether the loop saves more judgement than it consumes.

The real takeaway

SEO does not need another machine that can produce a thousand articles. It needs a feedback system that can notice one worthwhile opportunity, improve it carefully, measure the result and admit when the evidence says “wait” or “stop”.

That is what loop engineering contributes: not infinite autonomy, but structured recurrence.

The useful unit is not the article. It is the evidence-backed decision. Without a measurable outcome written back into state, there is no learning loop—only repeated automation.

Build the loop around that, and AI can make SEO operations more consistent without turning the web into a landfill of confident text.

If you are considering an evidence-led SEO or content-operations loop, I am happy to help map the data source, verifier, state and human gates—email me.

For more practical notes from the intersection of AI, engineering and business, follow me on Medium, subscribe or bookmark nam-ai.uk, or connect with me on LinkedIn—I am always interested in the systems that survive beyond the demo.