Why the addresses matter more than the design
Search engines, other websites, old emails, printed brochures and your customers' bookmarks all point at specific addresses on your current site. Each of those addresses has a history. When a migration changes them without telling anyone where the content went, that history is discarded, and visitors land on an error page.
A redesign and a migration are different jobs that often happen together. The redesign changes what people see. The migration changes where things live. A project can look excellent on launch day and still lose a large share of its visitors over the following period, because the second job was treated as a detail of the first.
Build a complete inventory of the old site
No single source lists every address a site answers, so the inventory is assembled from several and then merged. Expect to find pages nobody on the team remembers, some of which bring in more visitors than the pages everyone does remember.
| Source | What it adds | What it misses |
|---|---|---|
| A crawl of the live site | Every page reachable by following links | Pages with no links pointing to them |
| The sitemap file | Pages the site declares to search engines | Anything left out of the sitemap |
| Analytics, a full year | Pages that visitors actually land on | Pages with no recent visits |
| Search console data | Pages that appear in search, with their queries | Pages search engines never indexed |
| A backlink report | Pages other websites link to | Pages with no inbound links |
| Server logs, where available | Every address requested, including files | Nothing, though they need filtering |
Include files as well as pages. PDF documents, images used in other people's articles and old campaign addresses are often among the most linked items on a site.
Decide what happens to every address
With the inventory merged into one sheet, give every row one of four outcomes. The decision is editorial as much as technical, so it belongs with the person who knows the content, working beside whoever is building the new site.
| Outcome | When to use it | What to configure |
|---|---|---|
| Keep | The page survives at the same address | Nothing, apart from checking it after launch |
| Redirect | The page survives at a new address, or was merged into another | A permanent redirect to the closest equivalent page |
| Retire | The content is gone and nothing replaces it | A clear gone or not found response, with a helpful page |
| Review | Nobody is sure what the page is for | A decision before launch, never after |
The most common mistake is sending every retired page to the home page. Visitors arrive expecting a specific answer and find a front door, and search engines generally treat such redirects as if the page had simply disappeared. A redirect should lead to the page that best answers the same need.
A worked example
A training provider moving to a new platform
This example is invented to show the address map at work. A training company with several hundred pages moves from an old content system to a new one, and restructures its course catalogue at the same time.
- InventoryThe crawl finds 640 pages. Analytics adds 85 more with visits in the past year, mostly old course dates and campaign pages. The backlink report adds 30 PDF brochures.
- Decisions410 addresses are kept unchanged. 260 are redirected, because course pages move from a flat list into subject folders. 70 are retired. 15 are marked for review and settled in one meeting.
- SurpriseThe third most visited page is a five-year-old article on choosing a qualification. It was not in the new site plan at all. It is kept, updated and linked from the new course pages.
- TestingEvery one of the 755 addresses is requested against the staging site by script. 22 redirects point to pages that do not exist yet, and are corrected before launch.
After launch the team checks errors daily for the first fortnight and finds eleven more addresses, all from old email campaigns, which are redirected the same day. Search visits dip briefly and recover, instead of falling and staying down.
Test the redirects before anyone depends on them
- 01
Load the map into the new site early
Redirects are part of the build, not a task for launch night. Configure them on the staging site as soon as the new addresses are stable.
- 02
Request every old address by script
For each row of the inventory, record the response and the final destination. A person clicking through a sample will miss exactly the rows that are wrong.
- 03
Look for chains and loops
A redirect should reach its destination in one step. Chains slow visitors down and loops strand them, and both tend to appear when old redirects are stacked on new ones.
- 04
Check what the new pages say about themselves
Titles, descriptions, headings, canonical addresses and structured data should have travelled with the content. Compare the important pages side by side.
- 05
Carry over the old redirects
The old site probably has redirects from an earlier move. Those addresses still receive visits, and they need to point at the new destinations directly.
The migration checklist
Website migration checklist
0 of 10 checkedWhat to watch after launch
A careful migration still produces surprises, because no inventory is perfect. The difference between a short dip and a lasting loss is how quickly those surprises are found and fixed.
Normal after a move
- A brief dip in search visits while pages are reprocessed
- A handful of not found errors from very old links
- Rankings that fluctuate for a while before settling
Needs attention now
- Not found errors on pages that used to receive visits
- Important pages missing from search results after the settling period
- A steady decline with no sign of recovery
- Visitors landing on the home page from specific old links
Keep the redirects in place for the long term. Removing them after a year to tidy up the configuration undoes the work, since links from other websites do not expire.
What to do next
If a migration is ahead of you, start the inventory now, before the new site is designed. It costs little and it changes the plan, because it shows which pages the new structure has to make room for.
We handle migrations as a defined piece of work within a website redesign or as a website migration by itself. Send us your current address and we will tell you what we would check first.
Common questions
Will a website migration always cause a drop in traffic?
A short dip is common, because search engines need time to process the new addresses. A lasting drop is not inevitable. It usually traces back to missing redirects, redirects that point to the wrong place, or content that was removed without a replacement. A thorough inventory and tested redirects remove most of the causes within your control.
How long should redirects stay in place?
Indefinitely, as far as practical. Other websites, old documents and bookmarks keep pointing at the old addresses for as long as they exist. The cost of keeping a redirect is negligible, and removing it turns a working link into an error. If the configuration grows unwieldy, tidy it by combining rules, not by deleting them.
Can we change the design, the platform and the addresses all at once?
You can, and many projects do, but each change adds risk and makes problems harder to diagnose. If traffic falls, you will not know which change caused it. Where the timetable allows, keep addresses stable through a redesign, or move platforms first and restructure later. When everything must change together, the inventory and testing matter even more.
What if the old site has thousands of pages?
The method stays the same and the tools do more of the work. Group addresses by pattern, such as all product pages or all dated articles, and write one redirect rule per pattern where the new structure allows it. Reserve individual attention for the pages that carry the most visits and inbound links, which are usually a small share of the total.
Who should own the redirect map?
One named person, ideally on your side, with the agency or developer responsible for implementing it. The map is a business document as much as a technical one, because it records what happened to every page you ever published. Keep it after launch. It is the first thing anyone will ask for when a question about an old address comes up.
