How a Claude Agent Verified 46 Sites in Search Console

A Claude agent worked down a 46-site Google Search Console verification queue for the Local Service Spotlight fleet, verifying ownership site by site, catching a sheet-wide URL typo, and refusing to touch a broken or flagged site. Here is exactly how the run went, decision by decision.

Verifying a site in Google Search Console sounds like a one-click task. Across a fleet of 46 client sites on WordPress, it is not. Every site has its own hosting quirks, its own SEO plugin state, and its own way of being broken. This meta article documents a single real run through that queue, following the same repeatable per-site process on every row so the work is provable and the failures are honest.

Start With The Queue, Not The Sites

The source material was a single tab in the fleet audit spreadsheet: 46 rows sorted by 30-day traffic, each with a site name, a URL, and empty columns for verification status, method, and notes. The goal was simple to state and hard to execute: get Google Search Console ownership verified for as many of the 46 as possible, and leave a clear paper trail on every one that could not be verified.

The agent worked top-down by traffic priority. For each row the process was identical: read the URL from the sheet, confirm the URL actually resolves, check Search Console first, and only then decide whether the site needed any change at all.

Check Search Console Before Touching Anything

The single most important step was checking Search Console first. Adding a URL as a property triggers an automatic ownership check. If the site already carries a Google Tag Manager container or Analytics tag from prior work, Google verifies ownership on its own with no code change and no site login. Three sites in this run verified exactly that way, which meant the fastest wins came from doing nothing to the site at all.

Only when the auto-check failed did the agent drop into the manual path: confirm the hosting install, confirm the live domain is actually mapped, confirm the SEO plugin is active, generate the site’s own verification token, and type that token into the plugin by keyboard. Order matters here, and it is the same discipline behind our approach to running weekly AI agent SEO audits across every client — check the cheap signal before spending effort.

Catch The Data Problems The Task Owner Missed

The most valuable output of the run was not a verification. It was catching that three of the highest-traffic URLs in the sheet did not resolve at all. Each was a law-firm subdomain missing a word in the domain — the sheet listed a shorter version of the firm’s domain than the one that actually exists. The agent found the correct domains, verified them, and corrected the sheet with dated notes. That is the kind of judgment a keyword-matching script never makes, and it is the same principle behind smarter AI-driven internal link building: the agent has to understand the business, not just execute strings.

Refuse The Sites You Should Not Touch

Four sites were blocked, and blocking them correctly was the point. One site returned a cross-domain permission error because its plugin was hardcoded to the live domain while the single-sign-on session landed on the staging hostname. One site had a pre-existing site-wide fatal error — confirmed by loading its public homepage, which errored too — so the agent made zero changes and moved on. Two more had domains that were not wired to their hosting install, so any verification tag would never appear at the live URL. In every case the agent logged the cause rather than forcing a fix.

The agent also stopped at a Chrome “Dangerous site” warning on one install and did not click through it, and it never reused a shared fleet tag that belonged to a different Google account. Guardrails like these are why the fleet trusts the process — the same standard we describe in what we share from our AI’s rulebook and what we do not.

The Critical Decisions

1. Auto-verify before manual tagging. The agent added each URL as a Search Console property and let Google’s own check run before writing any token. A less capable system would have gone straight to plugin edits on all 46 sites. The alternative would have burned hours changing sites that never needed a change.

2. Validate the URL resolves before working it. Three top-priority rows pointed at domains that do not exist. Rather than log them as failures, the agent found the real domains and corrected the source data. The alternative was three false “unverifiable” entries and three lost verifications.

3. Prove the broken site was already broken. When a site showed a fatal error after sign-on, the agent loaded the public homepage to confirm the error was pre-existing and independent of anything it did, then made zero writes. The alternative — assuming fault and attempting a fix — risked worsening a live client site.

4. Honor the security warning. The agent hit a browser “Dangerous site” interstitial and refused to bypass it. The alternative was clicking through a flagged page on a client’s behalf, which is never acceptable.

5. Reject the wrong-account shared tag. A fleet-wide verification tag existed but was tied to a different Google account, so it would never verify these properties. The agent used each site’s own token instead. The alternative was a queue of silent verification failures.

Effort And Cost Comparison

What The Agent Could And Could Not Do

The agent handled everything on the software side: reading the queue, checking and adding Search Console properties, diagnosing hosting and DNS state, generating tokens, catching the data errors, and logging the sheet. It could not click the hosting single-sign-on “WP Admin” button for each install (a human did that), it could not fix the broken client site, it could not bypass the security warning, and it could not use the wrong-account shared tag. It flagged all of it honestly rather than papering over the gaps.

Information Ingestion Inventory

Guidelines Compliance Scorecard