The redirect map is the migration

Suppose an old product page still has links in a supplier’s PDF. The replacement site launches without that address, and everyone following the PDF gets a 404. You can add a redirect tomorrow; you cannot recover today’s enquiries or edit copies of the PDF you do not control.

That is why I ask for the old URLs before I start building the new site. The redirect map tells me which destinations the new site must provide, and it gives me something concrete to test on staging.

Inventory inbound links before the build

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.

Look beyond the current navigation

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.

Sometimes a page really is gone. If there is a successor that answers the same question, point the old URL to it. Otherwise I leave a 404 or 410 and record the decision in the map. Sending every retired page to the homepage looks tidy in a spreadsheet; to the visitor who followed a link to a manual, it is a dead end with a different status code.

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