Models know the general rules of indexing well, and they still pick a stale or wrong action in a handful of specific Google situations. The ones we caught: pressing Request indexing on a URL that redirects, answering a redirect that has no destination by blaming the site, pointing a syndicated copy at the original with a canonical, and hiding an untranslated page instead of treating it as a duplicate. A strong model slipped in only a few of our test cases; a smaller one slipped more often. Below is each trap, the right move, and what the test showed.

Method

We wrote two sets of situations the way a site owner would describe them in a chat. The first has 22 Search Console cases: 15 with a tempting wrong button and 7 with a plain right one, so a skill that does harm would show. The model picks one of 14 action codes, gives a reason and steps, and the code is checked by a script. The second holds 24 sets of URL variants, 17 with a trap and 7 plain, and the model must say per URL whether it is kept, redirected, pointed at another address or hidden from the index.

Sonnet and Haiku answered each situation once with nothing loaded, and once more with one of our skills. Then we read every wrong answer by hand, because a failed check is not always a wrong answer.

Results

The headline numbers

Without a skill, Sonnet chose the right Search Console action in 17 of 22 and Haiku in 16; with the skill both reached 22. For the URL sets, Sonnet scored 20 of 24 without and 24 with, and Haiku 21 without and 22 with.

Request indexing on a redirecting URL

An owner moved a page, tested the old address live, pressed the button to get it indexed, and a week later saw the old address listed under "Redirect error" even though the redirect works in a browser. Sonnet suggested another live test, and so did Haiku. What worked on our own sites was to press Validate fix on the matching issue row, because the button itself had sent Googlebot to a redirect. In a sibling case, three moved pages and a plan to press the button again, Sonnet answered "no action" and Haiku "wait". Sonnet was half right: it saw the button would not help but left the report entry standing.

A temporary move during a sale

Google's rule is that a 301 or 308 shows the new target in results, while a 302, 303 or 307 keeps the source page showing (Google on redirects). That is why a two-month sale wants a temporary redirect: the category page stays the one that ranks. Sonnet's answer to that case was not valid JSON, and Haiku answered "unknown" without the skill and self-canonical with it, so the skill did not fix this one for the smaller model.

A redirect with no destination

A page reported as missing got a redirect added in a redirect table, and the old address now showed an error. The response was a permanent-redirect status with the destination header missing. Sonnet and Haiku both said to repair the redirect handling on the site. On a site we run, the cause was an old cached copy of the not-found page, which the framework kept serving over the new rule; the fix was to clear the cache for that path. The giveaway is a correct saved rule next to a broken response, which points at a cache. A related case, where Search Console statuses came from server errors under a crawler burst, is in our write-up on indexing failures on Workers.

Blocking with robots.txt, and the line Google ignores

Hiding a page with a Disallow line does not remove it. Google says plainly not to use robots.txt to block a page and lists a noindex tag, removal of the content or a password as the permanent ways (Google on removing pages). It also says a noindex rule only works if the page is not blocked in robots.txt (Google on noindex). So for "my private page is still listed" the answer is a noindex that Googlebot can actually fetch, with the Disallow removed first. Sonnet answered "delete the Disallow line", which is only the first step, so we count it as defensible.

The same grey zone covers the report warning about a Host directive. Google's parser only acts on allow, disallow and user-agent lines (Google's robots.txt specification), so Sonnet's "no action" was a reasonable read, though our key wanted the line deleted.

Syndicated copies

The case: a partner magazine republishes a full article and asks how its copy should behave so that the original keeps ranking. Both models, without the skill, answered with a cross-domain canonical pointing at the original. That is the common advice and it is stale. Google's page on canonical problems advises against the canonical element for syndication partners, since such copies often differ a lot, and says the partner site should keep the copy out of the index (Google on syndicated content). That page does not use the word noindex; the practical way is the rule from the previous section. Once the skill was loaded, both models chose noindex on the partner's copy.

Untranslated pages

A new French section exists, but one French page carries the English wording unchanged, and the pair is linked with hreflang. Sonnet answered noindex and told the owner to drop the hreflang tags; Haiku answered "unknown". Google counts a localized page as a duplicate only when its body text has not been translated (Google on localized versions), and its duplicate-URL guidance asks for a canonical page in the matching language, with the nearest available language as fallback (Google on duplicate URLs). Our answer key was a canonical from the French address to the English one until the text is translated. That is our reading of the two pages, not a sentence either states; the same guidance also advises against noindex for choosing a canonical within one site.

What the gain really is

For Sonnet and the Search Console set, we read the five misses: two real gaps (the redirect error after the button, and the cached 404), one half right, and two defensible. The honest gain is two to three of 22, not five. For the URL sets, two of Sonnet's four misses were invalid JSON, a format failure and not a knowledge gap, so the knowledge gap was the syndicated and the untranslated copy.

Haiku gained more in the Search Console set, from 16 to 22, but not all of its six misses are knowledge either. Two are the redirect cases above, a third is the cached 404, and a fourth told the owner of a Domain property to type the short sitemap name again; on our own property that short name was refused and the full https address was accepted. The other two are not knowledge: one answer named the right fix in its steps but gave the wrong action label, and one asked for a live test first on a page the owner had already seen fail with a server error every time. In the URL sets Haiku moved only from 21 to 22: it fixed the syndicated and untranslated copies but broke a third case by adding a key the answer format forbids.

A strong model gains little from these two skills; a smaller one gains more, where the misses are real knowledge about Google's current behaviour. If you use search-console-actions or canonical-url-decision, that is the honest size of what they add.

What we did not measure

  • One sample each. We have no variance estimate, and one changed answer moves a score by one.
  • The cases are ours. We wrote all 46 from problems on sites we run, so they fit traps we already knew.
  • Google changes. The pages cited above were read on 20 October 2026 and can change; where they differ from this post, trust the page. The cached not-found page and the Request indexing behaviour are our own measurements, not Google statements.
  • The run log and the summary differ by one. The summary file records Sonnet at 22 of 22 with the skill, but the run log marks one answer as a miss because its reason lacked a keyword, even though the action was right.
  • Partial scoring. A check can fail a right action and pass a poor reason.
  • Two models, single questions. No other models, and no back-and-forth over real Search Console screens.

Read this post as Markdown: /blog/google-indexing-fixes-models-get-wrong.md · Atom feed.