Building a Redirect Map Checker That Checks the Plan Honestly

A redirect plan usually starts life as a spreadsheet: old URLs in one column, new URLs in the other. Read row by row, almost every line looks reasonable. The defects sit in the relationships between rows. One old URL appears twice with two different destinations. Two pages point at each other. A page redirects to a URL that itself redirects somewhere else. None of these is visible from a single row, and all of them can exist before any rule reaches a server.

We built the CoreAEX Redirect Map Checker to find those relationship problems in a pasted map and name the rows involved. This is how we scoped it, what review caught before release, and where its answer stops. It is a planning check. It does not replace a crawl, live redirect testing or a migration review.

Two labels mark evidence boundaries on this page. Documented marks a platform behaviour directly supported by the linked WHATWG or Google documentation; any surrounding interpretation remains CoreAEX analysis. Recommendation marks a practice we suggest that no source prescribes. Results from our own build and review are described in the prose as reported history or as checks we ran on a stated date. Untagged text is ordinary explanation.

Choosing a scope that could stay small

The brief, written on October 7, 2026, was deliberately narrow: one page inside the existing CoreAEX Astro site, using its shared layout and design, with a single input of two tab-separated columns and an optional old_url/new_url header. A coordinator turned that brief into bounded prompts, Claude Code implemented each step and returned evidence, and the work was reviewed before anything was published. The work was isolated from the site's services, contact and CMS records.

It has no account, no saved map history, no analysis backend and no AI calls. It does not fetch source or destination URLs. The analysis runs in the browser tab and does not upload the paste. The page itself still loads its normal site assets and carries a booking link, so the privacy claim is about the map, not a claim that visiting the page makes no network requests.

A deterministic check suited the problem. Duplicates, conflicts, loops and chains are properties of a graph built from the rows you supply: each URL is a node, and each row is an edge from an old URL to a new one. The same paste should produce the same findings every time, with row numbers a person can fix. We did not compare this against an AI model for accuracy or speed; our reason was reproducibility, not a measured advantage.

Making URL interpretation explicit

Before you can find a loop, you have to decide when two URLs are the same node. The checker compares accepted URLs as exact, case-sensitive strings. A difference in scheme, path case, percent-encoding, trailing slash, query string or query order, or fragment makes a different node. https://example.com/Pricing and https://example.com/pricing are two nodes, and so are https://example.com and https://example.com/.

We chose exact matching because the alternative is guessing. Servers differ in whether a trailing slash, an uppercase path or a reordered query is equivalent, and a checker that silently merged variants would be asserting server behaviour it cannot see.

That created a second problem. Browsers validate URLs with the WHATWG URL parser, and that parser rewrites some spellings while parsing them. It lowercases ASCII domain names, drops a port that matches the scheme's default, resolves . and .. path segments, treats a backslash as a slash in http and https URLs, and percent-encodes characters such as spaces. Documented In a quick Node check, https://EXAMPLE.com/page, https://example.com:443/page and https://example.com/a/../page all came back as https://example.com/page.

If the tool accepted the parser's output, the graph would contain URLs nobody typed. If it accepted the original while validating the rewritten version, two different spellings could hide a relationship. So the rule is conservative: when parsing changes a spelling, that cell is rejected and named for correction. The single exception is a valid host-only URL such as https://example.com, which the parser would give a trailing slash. Rejecting every host-only URL would be unhelpful, so it is accepted exactly as pasted, without the slash. Credentials, whitespace, control characters and other schemes are also rejected.

This is the tool's policy for checking a plan. It is not a description of how every server matches requests, and the tool does not model rewrite patterns, wildcards or rule precedence.

Turning graph findings into specific edits

Each finding names its type, rows, URLs, an explanation and a suggested action, with errors before warnings.

• Duplicate mapping (warning): the same old and new pair appears more than once. Keep one copy.
• Conflicting destinations (error): one old URL points to two or more new URLs. The tool does not pick a winner; that depends on server rule order it cannot see.
• Redirects to itself (error): the old and new URL are identical.
• Redirect loop (error): a closed cycle, whether two URLs or several. Where a conflict sits inside a possible cycle, the finding is a potential loop, because the real behaviour depends on which conflicting rule wins.
• Redirect chain (warning): two or more hops before reaching a URL with no further mapping.

Take a short chain. If A maps to B and B maps to C, the checker suggests pointing both sources directly to C. But C is terminal only within the map you pasted. The checker has not visited C and cannot know whether it redirects again, returns an error or serves the right content. If the path runs into a conflict, a rejected row or a loop before it ends, the tool reports the blocker and suggests no destination.

Chains are warnings, not errors, for a reason. Google's documentation says its crawlers follow up to 10 redirect hops by default, and that specific products' crawlers may have different limits. Documented A two-hop chain is therefore not automatically a failure. Collapsing it still removes an extra request and a dependency on an intermediate rule.

Several old URLs sharing one destination is not flagged at all. Retired pages often have a single genuine successor. Whether that successor is right for each old page is a content decision the checker cannot make.

What review caught before release

An early candidate passed its 39 tests, and review still found results that meant the wrong thing. The tests showed the code did what they asked, not that every result told the user the truth.

• A false clean state. A paste containing only a header row could look like a map with no issues. Header-only and blank input are now treated as incomplete, not as a clean check.
• A false terminal. If B's own outgoing row was rejected as an unusable URL, B could appear to be the end of a chain, and the tool would suggest mapping A straight to it. B is now tracked as blocked, and no final destination is suggested until the invalid row is fixed.
• Lost evidence. Malformed rows could lose the values that made them malformed. The cell contents are now preserved in the finding.
• Limit bypasses. Whitespace could slip past the size limits. Limits are now measured on the original paste, and over-limit input is rejected rather than truncated.
• CSV export. The export carries pasted values, and a cell starting with =, +, - or @ can be read as a formula by spreadsheet software. Control-character handling was incomplete; such cells now receive a leading apostrophe in the export, without changing what the page displays.
• Stale results. Findings could survive an edit to the textbox. Editing now invalidates the result and disables export, and slower rendering work from an earlier run cannot bring old findings back.

Review also removed repeated chain output, and each fix stayed inside the original scope. The final review reported 66 passing tests. That figure comes from the implementation and review history; it is not a suite we have rerun for this article.

A passing build was not a live page

After review, the checker build passed, and the first attempt to put it live still stopped. The pre-upload check found that the parent directories for the tool page and its script bundle did not yet exist on the server, and refused. Nothing was uploaded in that attempt.

A later release created those directories and uploaded the page with its matching JavaScript bundle, and both returned HTTP 200. That first release was intentionally left out of navigation and the sitemap. A separate release then added the Tools index, the navigation entry and the sitemap entry. A successful build establishes neither file on the live host.

The tool on its own example

The page loads a fictional example. On October 31, 2026, it contained 14 data rows, 13 of them usable mappings, and returned four errors and two warnings. Row numbers count the header, so the first mapping is row 2.

Findings for the built-in example, checked October 31, 2026

For the conflict, the next step is a decision, not an edit the tool can make: choose the one intended destination for old-pricing.html in the source spreadsheet, then check again. For the chain, confirm the end of the docs path is the right page and actually serves, then map both sources directly to it. The example is broken on purpose, so these counts describe its contents, not the tool's quality.

On the same date we retrieved the live page and bundle and ran 25 focused checks against the deployed script, plus a short browser session. That session confirmed the example result, that editing invalidates findings, that a valid many-to-one map passes, and that Clear and Load example work. These were focused checks, not a rerun of the original suite and not a complete browser or privacy audit.

Where live validation begins

A clean result means the supported checks found nothing in the map you supplied. The checker cannot show that the redirects are deployed, that each source returns the intended redirect, or that destinations return 200, are indexable or are relevant. A URL missing from your paste is invisible to it. Maps over 2,000 data rows or 1 MiB are rejected, and splitting a large map can hide a conflict, loop or chain that crosses the split.

Use it to remove plan defects before deployment, then test the implemented redirects and destination pages through your normal migration checks. Recommendation For the inventory and mapping decisions that come first, see URL inventory and redirect mapping for SaaS migrations, and for the wider process the technical SEO checklist for SaaS website migrations.

If you have a plan in a spreadsheet, copy the two columns into the Redirect Map Checker and start with the rows it names.

---

Sources