I wanted to improve the SEO of InfiniteGrammar.de.
The frontend originally came from a design built with Lovable and was developed further with Claude Code. I added prerendering, metadata, structured data, sitemaps and other SEO improvements along the way.
Still, the website showed poor organic search performance for months.
I tried the obvious next step: ask Claude Code with SEO skills to identify problems and fix them. It found plausible improvements. Some were useful. But the overall result was not satisfactory.
The problem was simple:
I am not an SEO expert.
I can work with product metrics, data, code and experimentation. But technical SEO contains a large number of interacting rules around crawling, rendering, canonicals, structured data, internal links, performance and indexability.
I did not want the quality of the site to depend on me knowing which SEO question to ask next.
So the goal changed.
Instead of using AI to help me do SEO, I wanted to build a system where an AI agent could act as the SEO specialist and developer, continuously inspect the site, fix problems, and prove that the fixes worked.
That became SEO-Autopilot.
From n8n workflows to an autonomous control loop
The first architecture was fairly simple.
- n8n was the orchestrator. It selected checks from the SEO catalog, tracked state, dispatched work and waited for results.
- Claude Code GitHub Agent was the developer. It investigated the repository, proposed fixes and implemented approved changes.
- GitHub Actions ran tests, verification steps, production checks and callbacks.
- Netlify provided Deploy Previews and production deployment.
And GitHub became the workspace where issues, branches, pull requests and execution results were visible.
At first I used to build the n8n workflows manually.
That worked while the system was small. Then the workflows accumulated retries, callbacks, observation windows, PR detection, deployment checks, rate-limit handling and failure recovery.
Editing nodes by hand became the bottleneck.
So I gradually moved the control plane into GitHub.
The n8n workflows became version-controlled JSON. ChatGPT became both the developer of those workflows and, effectively, my smart console for the system.
ChatGPT accesses the repository through the GitHub integration, inspects the current implementation, changes workflow definitions and helps debug failures. GitHub Actions then deploy those workflow definitions to n8n through the n8n API, with credentials stored in GitHub secrets.
That was the point where it stopped feeling like a collection of automations and started feeling like a real system.
The difficult part was verification
The initial idea was straightforward: take an SEO check from the prdefined catalog, let Claude investigate the repository, implement a fix, and verify the result.
The problem was that the verification itself was not stable.
If a check required evidence from production, the agent might instead prove that the corresponding code existed in the repository. If the check was defined against rendered HTML, it might inspect React source. If a performance check expected a particular Lighthouse signal, it might substitute a related PageSpeed result or infer success from the implementation.
Those substitutions often sounded reasonable.
They were still different checks.
A common failure mode looked like this:
The system was effectively allowing the agent to change the test after seeing its own implementation.
Some catalog checks explicitly required repository-static verification, while the execution system did not yet support that verifier type. The correct result should have been missing verifier capability. Earlier versions were too willing to substitute another form of evidence and continue.
Performance checks exposed the same problem. A PageSpeed collection path already existed, but that did not make it equivalent to every Lighthouse-based check in the catalog. Code inspection, Lighthouse diagnostics and PageSpeed measurements can all be useful evidence, but they are not interchangeable.
Coverage mattered as well. One representative URL could pass while another independently affected template remained broken.
That led to one of the most important architectural changes in the project.
The frozen verifier
Each deterministic fix now has to come with a concrete verification contract.
The proposal defines both:
proposed fix
+
verification contractA separate gatekeeper reviews both.
The verifier is then frozen before implementation starts.
The baseline failure is important.
A verifier is only useful if it can first reproduce the defect it claims to test.
The implementation agent can decide how to solve the problem.
It cannot redefine what “solved” means afterwards.
And if the required verifier does not exist yet, the workflow is put on hold and the missing capability becomes an engineering task of its own rather than an excuse to replace the check with something easier.
Three types of SEO checks
The catalog is split according to how objectively a check can be evaluated.
Deterministic
These have a machine-verifiable answer.
Examples:
- Does the canonical match the expected URL?
- Is an indexable URL present in the sitemap?
- Are important links present in the prerendered HTML?
- Does the expected structured data exist?
- Does an unknown URL return the correct HTTP response?
- Do image dimensions match the actual asset?
- Does the breadcrumb expose the expected hierarchy?
These checks do not need another LLM opinion.
They need a verifier.
Deterministic with policy
Some checks are technically easy to evaluate, but there is no correct answer until the site defines its own policy.
For example:
Should /exercise be crawlable?
There is no universal rule for that route.
But once the site policy is specified, the check becomes deterministic.
The same applies to questions such as:
- which route classes belong in the sitemap;
- which URL variant is canonical;
- which application routes should be crawlable;
- which page types require breadcrumbs;
- which structured-data types are expected on each route class.
A large part of technical SEO automation turned out to be about converting implicit product decisions into explicit rules that software can test.
Semantic
The remaining checks require judgement rather than simple verification.
Examples:
- Does the page satisfy search intent?
- Is the content sufficiently complete?
- Is it meaningfully different from another page?
- Is the title actually good for the query?
- Is the anchor text useful in context?
- Does the page deserve to rank against competing results?
These cannot be reduced reliably to a simple PASS / FAIL assertion.
They need a different evaluation layer: independent LLM judges, SERP context, stronger evidence requirements and likely multiple evaluators rather than letting the implementation agent judge itself.
What the workflow looks like now
At a high level, one catalog check becomes a small engineering experiment.
That is quite different from asking an AI:
“Improve SEO.”
The system is instead asking:
“Does this specific externally observable property fail, can we prove it, and can the same test prove that it no longer fails after the change?”
Some of the issues were surprisingly ordinary
One check inspected the main German grammar hub.
The application appeared to contain links to its topic categories. But those links existed only in a client-side UI state.
The prerendered HTML Google received contained none of them.
For users, the navigation worked.
For a crawler, an important part of the site's internal link graph did not exist.
The fix made both navigation structures part of the rendered document. The frozen verifier checked the actual built HTML and confirmed that every expected category link was present.
Another check found the same class of problem on exam-centre pages.
The UI used JavaScript navigation handlers instead of real anchors.
To a user they looked like links.
To a crawler they were buttons.
Other deterministic checks found:
- grammar content that existed in the repository but was unreachable because two identifiers did not match;
- grammar category pages without a proper crawlable breadcrumb hierarchy;
- application and utility routes without an explicit crawl policy;
- article images without intrinsic dimensions, creating avoidable layout movement;
- unknown URLs being served as successful pages instead of genuine not-found responses;
- URL variants that could resolve under inconsistent casing;
- structured data describing content that was not actually rendered.
None of these are spectacular SEO tricks.
That is partly the point.
A site can accumulate many small technical inconsistencies that are individually easy to miss and collectively expensive.
An autopilot can keep looking for them.
Then search traffic started moving
The first concentrated wave of deterministic production fixes was followed by a clear change in Google Search Console.
The metric I care about most at the current stage is clicks.
Compared with the period immediately before that remediation wave:
organic search clicks increased by approximately 77%.
Search visibility expanded even faster. After the initial spike settled down, impressions were still approximately 223% above the earlier baseline.
The later behaviour was particularly interesting.
At one point impressions fell by roughly 44% as Google reduced a large amount of broad, low-click exposure.
But clicks did not fall with them.
They increased by another 21%.
CTR more than doubled.
The timing was useful too.
The increase did not appear immediately after deployment. The strongest expansion came after enough time had passed for Google to recrawl and reconsider the changed site structure.
A plausible sequence is:
The result is observational rather than experimental.
But the pattern is encouraging: the improvement starts after the first remediation wave, appears with a plausible delay, and click growth survives after part of the impression spike disappears.
The deterministic part is only the first stage
The first production phase answered one question:
Can enough technical SEO knowledge be converted into executable checks that an autonomous coding agent can safely work against?
So far, the answer appears to be yes.
The next challenge is harder.
A deterministic verifier can prove that a page now has the correct canonical, that an internal link exists, or that a route returns the right response.
It cannot decide whether a page is genuinely useful.
It cannot judge whether the content is better aligned with search intent.
It cannot tell whether two pages are semantically too similar.
That is where the semantic part of the catalog starts.
The next version of SEO-Autopilot therefore needs another evaluation layer:
The goal is not to make the agent more confident.
It is to make the system better at knowing what it actually knows.
For deterministic SEO, that means executable contracts.
For semantic SEO, it will mean independent evaluation rather than self-judgement.
And eventually, the interesting question is not whether an AI can change a website.
It already can.
The interesting question is how well an autonomous system can build evidence around its own changes to know when a change is correct, when it worked, and when it should try something else.