Build the Redirect Map Before You Touch Anything

There is one hour in a website migration that pays for itself many times over, and it happens before you choose a template. It is the hour you spend writing down every URL your site currently has and deciding, for each one, where a visitor who arrives at it next month should end up.

That document is the redirect map. It is two columns. It does not require software. And the difference between sites that shrug off a platform change and sites that never quite recover is, more often than anything else, whether somebody wrote it.

Why this cannot be done afterwards

The moment your domain points at the new platform, every old URL stops existing. Not gradually — instantly. Anyone following a link from a directory, an old newsletter, a forum post or another site’s article lands on an error page.

Search engines treat that as a page that has been removed, and the standing it earned goes with it. A 301 says something different: this has permanently moved here. The strength attached to the old address is meant to follow, and in practice it largely does, provided the destination is genuinely the equivalent page rather than a shrug.

Afterwards you no longer have a reliable list of what the old URLs were. The site that held them is gone. You are reconstructing from memory and from other people’s links, and you will miss most of them.

Finding every URL you own

Four sources, in order of how much they give you for the effort.

Your sitemap. Nearly every builder publishes one at /sitemap.xml. Open it in a browser, and either read it directly or view source if the browser renders it oddly. Copy every path out. This alone gets you most of a typical site.

Your own navigation. Walk the menu, including dropdowns and footer links. Sitemaps sometimes omit pages that are set to be hidden from search, and those pages often still have links pointing at them.

Your analytics. Pull a list of landing pages from the last twelve months, sorted by sessions. This catches the pages that people actually reach and that your sitemap may have dropped — old campaign pages, files, anything linked from an email you sent in 2023.

Search Console, if you have it. The pages report gives you every URL a search engine has on file for your domain, including ones you forgot you made. It is the most complete source and the slowest to read.

De-duplicate the combined list. You now have the left-hand column.

Deciding the right-hand column

Go row by row and write the new path next to each old one. Three kinds of decisions come up.

Direct equivalents. Most rows. The about page becomes the about page. Write the new path in the new platform’s format, which you can only do if you have already set the URL structure — do that first.

Pages you are not rebuilding. A migration is the right moment to delete the pages nobody reads. Those pages still get a row. Point each at the most specific relevant page that does exist: an old service page goes to the services index, not to the home page. Sending everything to the home page is barely better than leaving the errors in place, because it tells a visitor nothing and tells a search engine that the old page has no real successor.

Pages that genuinely have no successor. A discontinued product with nothing comparable. Point it at its category. If even that does not exist, letting it return an error is an acceptable last resort — but make it a deliberate decision recorded in the sheet, not an oversight.

Keep the map in one file, sorted by old path. You will be reading it under pressure later.

Loading it onto the platform that will answer

Here is the thing that catches people out, and it is worth stating bluntly because it is the most common misunderstanding in the entire subject.

Redirects only work on the platform that is currently answering for your domain. The old builder’s redirect panel stops being consulted the moment the domain moves.

Setting up redirects on the site you are leaving feels productive and does nothing. The rules have to exist on the receiving end. Every hour spent on the old platform’s redirect tool the night before launch is an hour thrown away.

How that is done depends on where you are going.

Squarespace has a URL Mappings panel under Settings, Advanced. It takes one rule per line in the form /old-path -> /new-path 301. Every path starts with a slash, and a rule missing the arrow or the response code fails to apply rather than warning you about it. Paste the whole map in at once.

Shopify keeps redirects in the admin under Content, then Menus, and accepts a CSV import so a map of hundreds of rows loads in one go. Two documented constraints shape how you use it. You can only redirect a URL that is currently broken — which on a newly built store is every one of your old paths, so this helps rather than hinders. And a set of prefixes cannot be redirected at all: /apps, /application, /cart, /carts, /orders, /services and /shop. Check your old URLs against that list before launch, not after.

WordPress has nothing in core. You install a redirect plugin, which gives you an interface and usually a bulk import, or you add rules to the server configuration, which is faster to serve and less pleasant to edit. Either is fine. A plugin is the right answer for most people because the map will need editing.

Testing the map

Do not trust that it worked. Check it.

Pick twenty rows at random — not the obvious ones, the odd ones — and visit each old URL. Three things have to be true for each. It has to land on the intended page. It has to arrive by a 301 and not a 302, because a temporary redirect signals that the move might be undone. And it has to arrive in one hop, not through a chain of two or three redirects.

Your browser’s network tab shows all three. A command-line request showing headers is faster if you are comfortable with one.

Then, for the fortnight after launch, read your 404 report every day. Every entry is a URL you missed, and each one is a two-minute fix while the move is fresh in your head.

Two traps worth knowing about

Trailing slashes. Platforms disagree about whether a URL ends with a slash. Some treat /about and /about/ as the same page; some do not. Check which convention your new platform uses and write your map in that form consistently.

Redirect chains. If you have moved before, some of your current URLs may already be the destination of an old redirect. Pointing those at a third address creates a chain. Flatten them — every old address should point directly at the final destination, not at another redirect.

Where this sits in the move

The map is built at the beginning, in the inventory phase, and loaded at the end, just before the domain changes. Nothing else in the project has that shape, which is why it gets forgotten in the middle.

If you have not planned the rest of the sequence yet, the order of operations is on the plan for switching website builders, and the full sheet to work from is in the moving-day checklist.