Synthetic acceptance exercise. The example hosts and response records are fictional. This tool does not fetch URLs, create redirects or change any existing page.
Agree the destination before accepting the response
A redirect returning 301 is only one part of a migration handover. First approve what the old address should lead to, then compare the supplied response chain and final page evidence against that decision. A program can compare records; it cannot decide whether the destination still answers the buyer's original question.
A site owner raised the problem of directing many distinct old pages to broad landing pages in a 6 May 2015 question. It is historical problem provenance, not current volume, a MadRaven client case or authority for the replies' technical claims. This resource does not recommend deleting or consolidating existing content.
One approved service destination, two recorded outcomes
The fictional old address is https://old.example.test/services/design/. Its approved counterpart is https://new.example.test/web-design/. The recorded example time is 15 October 2026 at 06:00 UTC. The new homepage is not the approved counterpart.
| Check | Broken input | Corrected input |
|---|---|---|
| First recorded status | 301 | 301 |
| Location | New homepage | Approved /web-design/ |
| Final recorded page and status | Homepage, 200 | /web-design/, 200 |
| Final canonical; noindex observation | Homepage; false | Approved /web-design/; false |
| Offline result | MISMATCH: first target, final record and canonical differ from approval | CONSISTENT within this supplied-record model |
Both examples contain a permanent first response. Only the corrected records match the approved service destination. A filled but wrongly approved mapping can still pass, so a content owner must check the decision itself. Neither example demonstrates a real traffic loss or recovery.
Run the worked records
Download the offline checker, broken input and corrected input. Place them together and use Node 22.13 or newer:
node migration-record-check.mjs --test node migration-record-check.mjs broken.json node migration-record-check.mjs corrected.json
Fifteen tests cover permanent and temporary responses, wrong destinations, extra hops, final status, canonical and noindex observations, duplicate mappings and missing or malformed evidence. BLOCKED means obtain the missing record; MISMATCH identifies a difference; CONSISTENT means only that the supplied records satisfy this model. Read the printed JSON state, not the shell exit code. This teaching CLI is not a production CI gate.
The model asks for a direct two-record chain: one redirect and one final response. An extra hop therefore fails this acceptance agreement; that is not a claim that Google cannot follow chains. The code does not extract headers or HTML, authenticate observations, assess content similarity or test Google indexing.
Official basis and the important exception
Google's site-move documentation, checked 15 October 2026, supports preparing mappings, permanent redirects where possible and testing destinations. It warns against irrelevant mass redirects, while allowing a relevant shared destination for genuinely consolidated content. The reviewer must establish that relevance; this tool neither bans every many-to-one mapping nor approves every homepage redirect.
Our JSON shape, direct-chain rule, exact canonical check and explicit noindex field are original acceptance choices. They are not a complete Google diagnostic or a guarantee that a move preserves rankings. A technical discrepancy is not automatically the explanation for an observed traffic change.
Return a checkable handover packet
- Have the content owner approve the old-to-new map and explain any shared destination.
- Retain timestamped original responses and final metadata, with missing items explicitly unknown.
- Request a bounded staging correction and repeat the same observations after an authorised change. Do not change unrelated URLs to make a score improve.
- Verify the intended business hostname and release separately using the domain handover register.
- Observe later search cohorts over complete comparable windows. Keep technical acceptance separate from indexing, enquiries and paid work.
Bring the approved map and a redacted failing record to a website migration discussion. This resource performs no production migration, Change of Address request, new account authorisation, deletion, consolidation or old-page rewrite.