Misimplementing SEO Work with an AI Agent

Netsujo Inc. · Published April 17, 2026 · Updated August 6, 2026

In April 2026 we used Claude Code to run a batch of SEO changes on netsujo.jp, editing across many files at once to sort out structured data, redirects, Open Graph tags, internal links and how much a page loads. That work also contained a clear error. We submitted ordinary web pages to the Google Indexing API and treated that as a way to get them indexed. Under Google's official specification, the Indexing API applies only to pages carrying JobPosting markup for job listings, or live-stream pages with a BroadcastEvent inside a VideoObject. It is not an API for general company information, service pages or blog articles. This article is not about how much work we shipped or how fast. It sets out why a wrong implementation got through, how we stopped it, and which quality gates we now place in the process.

Revision history, kept permanently at the top of the article. April 17, 2026 (first published): the SEO work done with Claude Code was published as a batch of 17 measures. July 23, 2026 (correction): we corrected the passage that listed submission of ordinary pages to the Google Indexing API as a measure, and added that the effect of llms.txt and ai-plugin.json is unverified. August 6, 2026 (full rewrite): the retracted material was removed from the body, namely the results table for the bulk Indexing API submission, the prompt for reproducing it, and the list that marked measures as done. The article was restructured around how the error happened and the quality gates that prevent a repeat. Sources (Google official): developers.google.com/search/apis/indexing-api/v3/using-api and developers.google.com/search/docs/appearance/ai-features.

Speed of implementation and correctness are separate measures

The faster implementation gets, the faster a wrong premise spreads with it. Having fixed something quickly is not proof of having fixed it correctly. AI agents suit work that runs across large volumes of code and pages, and this case was no exception: correcting redirect targets, setting per-article Open Graph images, reviewing structured data and adding related articles were all changes that take a long time by hand, and they went through together.

Three assumptions we short-circuited

• There is an API for notifying Google about URLs
• We have a large number of URLs that are not indexed
• Perhaps we can improve that by using the API

Those three joined up directly, and the step of checking the conditions a target page has to meet dropped out. The code ran, the API responded and a processed count appeared, which made it easy to judge the work complete. Being technically able to execute something is not the same as being within the official specification.

What we did wrong

We had been submitting the URLs contained in our sitemap, together with legacy URLs found in Search Console, to the Indexing API in bulk. The first version of this article presented those counts as a result and published a prompt for reproducing the procedure. We retract that account.

The statements we retract

• The comparison table that lined up bulk Indexing API submission counts as an indexing improvement
• The example prompt for readers to reproduce the same bulk Indexing API submission
• The list that displayed measures of differing certainty together as completed

To check crawling and indexing of ordinary pages, these are the methods we use now. The investigation procedure itself is set out in our article on diagnosing pages reported as crawled but not indexed.

Diagnosing "crawled - currently not indexed" in Search Console（日本語）

• Generate a correct XML sitemap and submit it to Search Console
• Add internal links to the pages that matter
• Check the state of representative pages with URL Inspection
• Confirm Googlebot visits in the server logs
• Review duplication, canonical tags, noindex, rendering and the quality of the body content
• Observe how publication is reflected over a defined period

We do not present the Indexing API as a general SEO measure.

The AI-search measures we reassessed at the same time

Having installed a file, and judging that it improves search exposure, have to be treated as two different things. The AI-oriented files that the first version listed as completed measures are not rated at the same strength now. At the time, the article listed llms.txt, llms-full.txt, ai-plugin.json, an ai:description meta tag and an AI-oriented answer-first format together as completed measures.

Google states that appearing in AI Overviews or AI Mode requires no special AI-oriented files, no special writing format and no AI-specific structured data. What should come first for Google Search is meeting the ordinary search requirements, publishing unique and useful content, and reducing duplication and technical obstacles. Sources: developers.google.com/search/docs/appearance/ai-features and developers.google.com/search/docs/fundamentals/ai-optimization-guide.

llms.txt is a proposed specification and there is room to examine it, but it is not a required measure for Google Search. Where it currently stands is set out in our article on whether llms.txt is necessary. ai-plugin.json is likewise not a general requirement for registering a site with ChatGPT search as it works today. Installing a file, and judging that it has an effect on search exposure, need to be kept apart.

Is llms.txt necessary? The proposed spec, where it applies, and why Google does not use it

Improvements worth keeping, and claims to remove

Not every measure in this work was wrong. We kept the fixes whose scope and verification method were clear, and removed only the claims that came without that certainty.

Improvements we keep

Correcting redirects for old URLs that were landing on 404s; improving og:type and og:image on blog articles; fixing the use of Product structured data on services that are not physical goods; adding internal links to related articles and related services; reducing how much a listing page loads initially; automating type checks, builds and URL health checks.

Claims we remove or re-evaluate

Treating submission of ordinary pages to the Indexing API as an SEO measure; calling llms.txt and ai-plugin.json standard AI-search preparation; generalising the text-to-HTML ratio as an important AI-search metric; wording that can be read as allowing AI crawlers increasing citations or recommendations; treating the state immediately after implementation as a result in search traffic or enquiries.

Volume of work is not a result. The amount of code changed, the number of URLs processed and the hours spent are not results in themselves. Evaluating results requires separately observing search appearance, clicks, enquiries, incorrect answers and reproducibility after publication.

Why the error reached publication

The cause was not only a wrong answer from the AI. There were problems in how we designed the review on the human side.

01. We executed before confirming the specification

We thought first about how to implement, and left the question of whether it applied at all until later.

02. We mistook a successful API call for a successful measure

A successful HTTP response does not mean the purpose it was used for was correct. Once a processed count appears, it becomes easy to feel that a result has been produced.

03. We put measures of differing certainty into one article

Fixes grounded in official specifications, attempts that circulate in the industry, and our own hypotheses all went into the same table of completed items. From a reader's point of view they all look equally certain.

04. There was no disconfirming review before publication

The person implementing and the person writing the article shared the same assumptions, so we did not sufficiently ask which official document would contradict a measure if it were wrong.

The quality gates we now require

When we hand SEO or web improvement work to an AI agent, we require the following order. This is our own operating procedure, not something we present as a universal answer. The wider picture of how we run this is described in our article on running the company with AI agents.

Running a company with AI agents: the operating system we use

Gate 1. Confirm what it applies to

For APIs, structured data, robots control and analytics features, confirm the target pages and the intended use in the official documentation.

Gate 2. Separate fact, hypothesis and experiment

Label each item in an article or implementation spec as an official specification, a fact we confirmed ourselves, a hypothesis drawn from observation, or an experiment whose effect is unverified.

Gate 3. Decide stop conditions before running

Automated processing stops when out-of-scope URLs, excessive permissions, unexpected API responses, build failures, or an inability to measure are found.

Gate 4. Run a disconfirming review before publishing

Assign the job of looking for ways the conclusion could be wrong to someone other than the implementer, checking official documents, primary sources and current product specifications.

Gate 5. Separate volume of work from business outcomes

Files changed and hours spent are productivity metrics. Search appearance, traffic and enquiries are outcome metrics. We do not compare the two in the same table.

The value is in not hiding the mistake

AI agents speed up investigation, correction and testing. Speed does not guarantee correctness. Unless a human holds the purpose, the conditions of application, the approval and the responsibility after publication, a wrong measure spreads at the same speed.

The cause of this misimplementation was less the use of AI than our failure to build confirmation of the official specification, and a disconfirming review, into the process.

We do not quietly rewrite a past article and leave it at that. We keep a record of what we got wrong, what we stopped, and how we assess it now. As a company that uses AI agents in real work, we intend to publish not only what worked but also how we correct what did not.