Rebuilt in 18 days · Part 2 of 6
Website migration without losing links: every old address still answers
Moving an old site to a new platform? Search engines and other sites still point at its old addresses. How we mapped every one as keep, forward or remove, checked the map on every build, and rehearsed the go-live with a rollback written.
An old website is more than its pages. After years online, search engines have its addresses on file, other sites link to them, readers have them bookmarked, newsletters and old posts point at them. Move to a new platform and change those addresses carelessly, and all of that turns into error pages overnight. The new site can be faster and better written and still start with less than the old one had.
We recently moved a directory and review website, live for more than twenty years with many years of articles and reviews on WordPress, to a new site on a modern framework. It went live 18 days after kickoff. On launch day every old address answered as mapped. Here is how, and a checklist you can use on your own move.
If you lead the team: what to ask
- Where is the list of every old address, and what happens to each one after launch?
- Does something check that list automatically, or does someone click through a sample?
- Have we turned the live switches on in a rehearsal, and is the way back written down?
Start with the list nobody wants to make
Collect every address anyone might still ask for, not just the ones in today's menu: the old sitemaps, a crawl of the site, the pages in the Search Console export, and the pages other sites link to. Each source finds addresses the others miss. On this site, most of the pages that earned clicks were missing from the sitemap it gave Google, so a list built from the sitemap alone would have dropped the pages that mattered most.
Keep, forward or remove: decided, not defaulted
Every old address got one of three answers:
- Keep. The page exists on the new site at the same address. The cheapest way to keep what an address has earned is not to change it.
- Forward. The page moved or was merged. The old address sends visitors and search engines, permanently, to the one page that does the same job.
- Remove. Nothing on the new site serves that purpose, and nothing should pretend to. Removed on purpose, and recorded as such.
What we avoid is the default: sending everything that has no obvious home to the homepage. Search engines treat that as a dead end, and visitors who came for a specific review land somewhere that does not answer them. We explain why in Less site, more traffic.
Merge near-duplicates into the page that does the job
Old sites collect pages that answer almost the same question. Before launch, 60 near-duplicate addresses were merged into the page serving the same purpose. Each one forwards there, and the searches it was found for moved with it, so the surviving page is built to answer them. The merge is a content decision first and a forwarding rule second.
The map is a file, and the build checks it
The address map is written down, every old address with its answer. A script asks a running copy of the new site for every address on the map and compares each answer with the map: kept pages must answer, forwarded ones must land on the page the map names, removed ones must be gone. It runs on every build, not once before launch. A later change that breaks an old address fails the build before it reaches anyone.
That matters because a migration does not end on launch day. Pages get renamed, sections reorganized, new templates added. A check that ran once on launch day protects nothing two months later.
The addresses people forget
- Sitemaps and feeds. Search engines and feed readers keep asking for the old sitemap and feed addresses for a long time. They forward to the new ones.
- Images. Old images kept their old addresses, so image search results and other sites that embed or link them still work.
- Pages other sites link to. These carry the old site's links into the new one. Check them first, not last.
Rehearse the go-live with the switch on
A preview site is usually set up to stay hidden: closed to search engines, no sitemap offered, preview-only tools visible. Flip those at the last minute and you are testing the most important settings for the first time in production. So we rehearsed the go-live with the live switches on: robots open, the sitemap named, the preview-only tools gone. Then the real switch was the same steps again.
The go-live plan was written, step by step, with a rollback: what to undo, in what order, if something went wrong. Write down the launch date and time too. If traffic moves weeks later, a fixed date is what lets you find the day first, then the cause.
Comparing old and new pages one by one, and speed, are covered in Redesign without losing what ranks. This post is about the addresses themselves.
A checklist for your own migration
- List every old address from at least four sources: old sitemaps, a crawl, Search Console, and the pages other sites link to.
- Give each one an answer: keep, forward or remove. No blanket forwarding to the homepage.
- Merge near-duplicates into the one page that serves the same purpose, and make that page answer their searches.
- Keep the map as a file in the repository, not in a spreadsheet someone emails.
- Check a running copy of the site against the map on every build, and fail the build when an address breaks.
- Forward old sitemaps and feeds; keep image addresses.
- Rehearse the go-live with robots open, the sitemap named and preview tools removed.
- Write the go-live plan with its rollback, and note the exact launch time.
If your site is old and the platform under it is holding you back, the move is the part to get right first.
This article is drawn from a real engagement. Client details withheld; the figures describe our own work, checked against the project’s records.
Read the full case study →