The redirect map is the migration

Typography, copy and a contact form pointing at the wrong inbox can all be corrected after launch.

Missing redirects start causing damage immediately. Visitors and crawlers following established addresses reach dead ends from the first request. Redirects added later fix future requests, but they do not repair the visits already lost or update every external link.

I therefore write the redirect map before development and treat it as a requirement for the new site.

Your inbound links are an inheritance

Most companies never inventory their inbound links, but every migration puts those links at risk.

A site that has been online for years may have links from suppliers, directories, trade associations, news coverage, forum threads and documents people saved long ago. Analytics usually groups the resulting visits under broad labels such as organic and referral, so the individual links go unexamined until they stop working.

That accumulated visibility may be one of the old site’s most valuable assets. It cannot be recreated on a launch schedule. Before I decide what a replacement should look like, I find out which addresses the old site answers to.

The menu is always a subset

The navigation is not the site. It’s an editor’s opinion about the site, usually last revised two redesigns ago.

Underneath it sit addresses nobody chose deliberately: old permalink formats, tag and category archives, paginated listings, author pages, feeds, attachment pages, query-string forms and files linked outside the site.

Any of those addresses may still receive requests even when the current navigation no longer links to them. A crawl finds what can be reached by following links. It misses orphans by definition.

Six places a URL can hide. Each source has a different blind spot.

Where I look	What it can reveal	Why it is not enough alone
A crawl of the live site	Pages reachable by following links, including deep pagination	Orphans. If nothing links to a page, a crawler cannot reach it
The XML sitemap	What the current CMS intends search engines to discover	It can omit forgotten content, files and addresses that predate the current system
Access logs	Addresses people and crawlers actually requested during the retained period	Only requests inside that period, and only if the host retained usable logs
Search Console's page reports	Addresses Google discovered or attempted to index	They represent Google activity, not every visitor, crawler or historical address
The Wayback Machine's CDX index	Addresses captured before the current CMS or redesign	Coverage is incomplete and does not establish current traffic or value
The CMS's slug history	Previous slugs the CMS may currently redirect automatically	Only the history that particular CMS and extension set recorded

WordPress can keep previous post slugs in postmeta and redirect them through wp_old_slug_redirect(). Those redirects disappear with WordPress unless the stored history is included in the migration inventory. It is not a complete record of every previous URL pattern, but it can reveal working addresses that a crawl cannot explain.

What we actually do, in order

1. Collect. I combine all six sources above, deduplicate them and add request counts where the logs can supply them.
2. Sort by evidence. URLs with traffic or inbound links get individual attention. I use rules only for the genuinely uniform remainder.
3. Decide the destination for each. Not the homepage. The nearest page that answers the same question, which sometimes means the new site needs a page it wasn’t going to have.
4. Write the map as data. Each row records the old URL, intended destination, discovery source and whether the entry is explicit or generated by a rule. I keep the file in the repository where it can be reviewed and compared over time.
5. Build the site to satisfy the map. This is the inversion that matters. The map is the requirement; the sitemap is an output.
6. Test it against a server before launch, then monitor HTTP error responses after release.

The map has fewer rules than you’d expect

One regular expression that catches a whole archive pattern can feel cleaner than a long file of explicit source-and-destination pairs.

I avoid that shortcut for addresses with traffic. A pattern makes a promise about URLs I have not inspected, and patterns can collide: a rule for /news/2019/* may also swallow /news/2019-price-list.pdf. The server still returns a redirect, so ordinary error monitoring will not expose the mistake.

So: explicit rows for the pages that earn traffic, patterns only for the genuinely uniform tail — pagination, feeds, date archives — and every pattern gets a test of its own.

Two details that cost more than they should:

• One hop. If /old-page/ redirects to /interim/ which redirects to /new-page/, update the first rule to point directly at the destination. A shorter path is faster to request, easier to test and has fewer rules that can later diverge.
• Trailing slashes, case and query strings need explicit handling. /About/, /about, /about/ and /?page_id=12 are different request targets even when the server normalises some of them. Decide the canonical form once and test every form the old site accepted.

What the crawl misses, and how you find out

Some URLs will be absent from all six sources. A file may be linked from an email signature or an external system may call an endpoint that was never documented.

I review 404 responses weekly for the first month, grouped by URL and request count. Obvious probes such as requests for wp-login.php can be excluded. Legitimate requests are added to the map and tested like the original entries.

That review catches gaps no pre-launch inventory could see. Its workload depends on the size and age of the site, which is why it belongs in the migration scope rather than being left to chance.

How long redirects stay

Google recommends keeping site-move redirects for as long as possible and generally for at least one year. That gives Google time to recrawl old addresses and transfer signals to the new ones. For visitors, a useful redirect can remain indefinitely.

I document any decision to remove one. Before it goes, I check recent requests and known external links, then update high-volume links where I can.

When this doesn’t apply

Two limits.

If the site is new, has few indexed pages and has not accumulated meaningful inbound links, a large migration process may be disproportionate. Inventory the existing addresses, but spend effort according to the value at risk.

If retired content has a clear replacement, redirect it there. If it has no equivalent, return 404 or 410. Do not send unrelated retired URLs to the homepage: Google may treat that as a soft 404, and it leaves the visitor no closer to what they requested.

Sources

1. Redirects and Google Search — Google Search Central — Redirect types, chains and how Google treats them. Checked 20 August 2026.
2. Site moves with URL changes — Google Search Central — URL mapping, 404 and 410 responses for deleted content, avoiding irrelevant homepage redirects and keeping site-move redirects for at least one year. Checked 20 August 2026.
3. wp_old_slug_redirect() — WordPress developer reference — The built-in old-slug redirect and how WordPress finds previous slugs. Checked 20 August 2026.
4. Wayback CDX server API — Internet Archive — How to list archived URLs for a domain. Checked 20 August 2026.

Moving a site and want the map done first?

Send us the URL. The inventory is the first thing we produce and you see it before anything is built — including the list of pages you'd forgotten you had.

Get in touchHow a migration goes