Orphan pages and redirect chains: what models miss

A move or a merge leaves two kinds of damage that no single page shows: orphan pages that nothing links to any more, and old addresses that hop through two or three stops before they land. Both are found from a crawl of the whole site. We gave two AI models both jobs, auditing a pasted crawl export and writing a redirect map. Counting links and collapsing a redirect chain they do well. They slipped at the edge of the evidence: a page marked noindex yet listed in the sitemap, a crawl in which part of the site never loaded, and, with our skill loaded, one old address that vanished from a list.

Method

The audit test has 30 crawl exports that we wrote. Seventeen carry a planted fault, three of those are hard, ten are sound sites where the right answer is "nothing to report", and the rest contain pages that failed to load. The request states the rules: two body links from other pages at least, three clicks from home at most, no extra click for a redirect, and a failed fetch means unknown links, not zero. The redirect test has 24 requests: chains, loops, old addresses with no named target, status codes for Next.js and for POST endpoints, queries, encoded paths and a cached error page.

Both models took every case twice: once as asked, once with the skill's instructions placed before it. They had no tools and no internet, and each got a single try. A script computed the expected answers; the raw reply behind every failure we read ourselves.

Results

The scores

Audits judged right, out of 30: Sonnet 28 without the skill and 30 with it, Haiku 29 and 30. Redirect maps right, out of 24: Sonnet 24 and 24, Haiku 24 without and 23 with. The first gap is two cases for Sonnet and one for Haiku. The second points the wrong way, and we get to it below.

The noindex page that was noticed and dropped

One export lists a tag page in the sitemap while its robots setting says noindex. Google describes noindex as a request not to show the page in search results (Google) and a sitemap as the pages you consider important (Google). For one address those two cannot both hold, and an audit should say so. Sonnet, without the skill, replied with one sentence that said nothing needed reporting and treated the noindex setting as a reason not to judge the owner's remark about that page. It had seen the problem and used it as a reason for silence.

Six pages that never loaded

The most instructive case is a crawl where six pages had timed out or returned a server error. Sonnet, without the skill, was careful about one thing: one page looked unlinked and another thinly linked, but the failed pages might supply the missing links, so it asked for a re-crawl. It named only three of the six failed pages, the ones its own reasoning needed. The other three, in two other sections, went unmentioned, so a reader would not learn that the crawl had holes there.

Haiku erred more sharply in the larger version of this case. It opened by calling two pages orphans as plain fact. Further down the same answer it listed all nine failed pages and wrote that their outgoing links stay unknown until a re-crawl. Any of those nine could have linked to the two pages, so the verdict was a guess dressed as a finding, and its own warning a few lines later said as much.

The same trap caught us. Our first audit of our own skill catalog was polluted: a burst of requests made 77 of 120 skill pages fail with a 500 error, and those pages added no outgoing links, so the count of unlinked pages was false. For an audit the lesson is that a link graph built from a half-failed crawl can be confidently wrong. A sound report names the failed pages before anything else and holds back every verdict they could change.

What a clean audit looked like

Most of the arithmetic needed no help. Both models counted a link once per source page, ignored self-links, kept navigation and footer links out of the body count, and treated a link that lands on a redirect as a problem of its own. Sound exports got a plain "nothing to report". The skill changed the cases above and the way a report is ordered. With the internal-link-orphan-audit skill both models scored 30 of 30, but only after we widened two checks, and the last section explains why that is a weaker claim than it looks.

How big the problem is on a real site

On our skill catalog, 43 of 121 pages had no inbound links from another skill page. We then put a "more in this category" block under every skill, and the count of such pages fell to 0, with at least 1 inbound link per page and a median of 5. Google's advice is that each page you care about be linked from some other page of the site, and that links are how it finds new pages (Google). The same page warns that anchors without an address, or links built only from a click handler, are not reliably read. A counter that lets those pass will call a page reachable when a crawler cannot get there.

Redirect maps: no measured gain

For maps the plain request was enough. Without any skill, both models turned a three-step chain into rules that all point at the last live page. Haiku put a three-page loop under loops and wrote no rule for any member. Sonnet gave no rule to an old address with two conflicting targets and left a note asking which was meant. Haiku chose 308 for endpoints that receive POST.

These answers agree with the sources. Googlebot will follow a chain of up to 10 hops, yet Google advises pointing an old address directly at where it ends up, keeping any unavoidable chain short (three hops ideally, under five), and not sending many old addresses to one unrelated page like the new home page, which may be read as a soft error (Google). Next.js uses 308 for a permanent redirect so that the request method survives (Next.js). Neither model made up a target for an address that had none.

With the redirect-map skill, Sonnet stayed at 24 of 24 and Haiku fell to 23. The failing case had four old addresses and targets for two of them. Haiku listed one address as unmapped and left the other out of every list, notes included. The answer looked tidy, and one old address silently had no plan; without the skill the same model listed both. One run cannot show a pattern, so we read it as a slip. It still means the measured effect of the skill on these two models is nothing for Sonnet and slightly negative for Haiku, and we say that plainly. A reason to use such a skill could be a fixed output shape and a written ban on guessing targets, which matters only if your own pipeline reads the answer by machine.

Two more facts belong after any move: Google counts 301 and 308 as permanent and 302, 303 and 307 as temporary (Google), and it suggests keeping the redirects a year or longer (Google). No model contradicted either one. We did not test whether they would bring up the year on their own.

What to take from this

Audit from a crawl export, and start the report with the pages that failed to load.
Never call a page an orphan while pages that could link to it are missing from the crawl. Write "unknown" and ask for a re-crawl.
A page that is both in the sitemap and marked noindex is a finding, even when someone says the page is useful.
Count links from distinct body pages. Navigation, footers and script-only handlers do not stand in for a link.
Send every old address to its final live target, report loops without writing a rule for them, and keep addresses with no target in an explicit list.
After a model writes the map, compare how many old addresses went in with the rules, unmapped and loops that came out. That check would have caught the only slip we saw.

Our earlier test of the Bing and IndexNow submission code shows the same pattern from another angle: the models handled the routine part and missed what had changed or needed a small calculation.

What we did not measure

One try each. A rerun could move a score by a full point, and the redirect-map difference rests on a single case.
Our own cases. The 54 inputs (30 plus 24) are small invented sites that we wrote, which favours the faults we already knew about.
Widened checks. Once the audit answers were in, we loosened two checks, on both sides alike. The first lets an unlinked page count when it is described as having no crawled page pointing at it. The second, in the case with a redirect and a deep page, also accepts calling a page weak when it has one direct link plus links that go through a redirect; both models gave that reading only with the skill, so this one helped the skill side. On first scoring, Sonnet had 27 and Haiku 28 without the skill, and both 29 with it; the 28, 29 and 30 above are the widened figures. We read each answer that changed, and all were right in substance.
Pasted text only. Two models read an export, not a site, and real exports are far larger than ours. A model with a crawler of its own could fail in other ways; we did not try.
Stated thresholds. Our requests spell out the limits. A model left to choose its own would give answers that are harder to grade.
Search engine behaviour. We never measured how an engine treats a chain; we compared the models with Google's published advice only.
Cache note. One redirect case includes a cached error page, but the request itself names the cache, which makes the note easy to write. Whether a model would raise it unprompted is untested.
Catalog counts. The link counts for our catalog come from our own audit of 18 October, not from a fresh crawl, and the catalog has grown since. Our planning notes from the same day give the total as 120 rather than 121, so treat the share as approximate.