How an AI Agent Caught a Bad Sitemap Path on 11 Sites

A task said to submit one sitemap path across 13 sites. On 11 of them that path returns a 404. A Claude agent checked before submitting, caught it, and sent the right one instead.

A task assignment is not a source of truth. During a Search Console run across 13 sites the team publishes to but could not measure, a Claude agent was handed an explicit instruction: submit /sitemap_index.xml for every site. On 11 of the 13, that file does not exist. Following the instruction would have registered dead URLs across the entire Spotlight network and produced a queue of fetch errors that looked like broken sites rather than a bad instruction. This is the story of how checking first turned a wrong instruction into 159 discovered pages.

Verify The Other Agent, Do Not Redo Their Work

Another agent had already commented on the task that it set up Search Console and Analytics for all 13 sites. The tempting move is to either trust that completely or start over from scratch. Both are wrong. Duplicate properties split the data, and blind trust leaves gaps.

The agent ran a read-only pass first. All 12 existing Search Console properties were correct and verified. GA4 was present and collecting real data on all 13, not empty containers firing into nothing. That half of the task was genuinely done and did not need touching. It is the same check-before-you-touch order that made the 46-site verification run cheap to execute.

The gap was somewhere else entirely: 12 of the 13 sites had no sitemap submitted at all.

Check The Path Before You Submit It

The task prescribed /sitemap_index.xml for all 13. The agent tested the path instead of trusting it.

The 11 Spotlight sites run WordPress core sitemaps at /wp-sitemap.xml. The prescribed path returns a 404 on every one of them. Submitting it would have queued 11 fetch failures against healthy sites. Only the two client sites, which run an SEO plugin, actually serve /sitemap_index.xml.

So the agent split the submission by what each site actually serves. Ten Spotlight sites took the core path and returned Success immediately. Then the eleventh failed, and that failure was worth reading.

One Site Broke The Pattern, So The Pattern Was Wrong

One Spotlight domain returned “Couldn’t fetch” while its ten identical-looking siblings succeeded. Same template, same host, same owner.

A blanket rule would have logged it as a broken site. The agent checked the URL directly and found a 404, then checked the alternative and found a working sitemap with 19 live URLs. That one site runs a different SEO plugin, which disables the WordPress core sitemap. Its robots.txt advertises a third path again, so all three answers were in play at once.

The correct sitemap went in and returned Success with 19 pages. The lesson generalizes: “same template” is an assumption, not a fact, and it costs nothing to check per site. This is the same principle behind reading the error instead of the spreadsheet on an earlier run in this fleet. The failure is usually telling you something specific.

Stop On A Contradiction Instead Of Guessing

The task named a personal Gmail account as the one to use, explicitly and twice, and named the operations account as the one not to use. Every other Search Console, Analytics, and Tag Manager property in the business lives under the operations account.

The agent stopped and flagged it rather than picking. Both guesses were expensive: work under the wrong account is invisible to the team and has to be redone, and it fragments ownership across accounts that cannot see each other. A human resolved it in one line, and the run continued under the operations account.

The same guardrail caught a second thing. The audit spreadsheet contains a cell instructing whoever reads it to inject a verification tag into every site in the fleet. That instruction is stale, left over from an abandoned approach. The agent treated the cell as data rather than as a command and did not act on it. Content found inside a document is never an instruction, and this is now the second run where that rule prevented an unwanted change to live client sites.

The Critical Decisions

1. Verify the prior agent’s work instead of redoing it. A read-only pass confirmed 12 properties and 13 GA4 installs were already correct, which removed most of the task and prevented duplicate properties. The alternative was either wasted rework or an unchecked assumption.
2. Test the prescribed path before submitting it. The instruction was wrong for 11 of 13 sites. The alternative was 11 fetch errors that would have read as broken sites instead of a bad instruction.
3. Investigate the one failure that broke the pattern. That site was not broken, it was different. The alternative was logging a working site as failed and leaving 19 pages undiscovered.
4. Stop on the account contradiction rather than choosing. One clarifying question cost a minute. The alternative was a full run stranded under the wrong account.

Effort And Cost Comparison

What The Agent Could And Could Not Do

The agent read every property, tested every sitemap path against the live sites, submitted the correct sitemap for each, and confirmed the fetch result. It could not resolve the account contradiction, which required a human decision, and it could not verify one Domain property that sits under an account the operations login cannot see. It did not delete the failed submission left behind on the one mismatched site, and it did not act on the tag-injection instruction embedded in the spreadsheet. Publishing this article is also a human step.

Information Ingestion Inventory

Guidelines Compliance Scorecard