What is on the old site, and where will it go?
Collect the existing URLs from several sources: a crawl of the site, your sitemaps, Search Console and analytics. Each source finds pages the others miss, such as old landing pages that are no longer in the menu but still bring visitors, PDF files and pages that other sites link to.
Map each page you keep to a new equivalent with the same purpose, and decide in advance what happens to the material you remove. Check images, documents and other files separately; they are easy to forget in a redirect map, the core document of any SEO website migration. Record each old URL’s purpose and current value, such as traffic, links and enquiries, so that the most important pages get the closest attention.
Keep the map up to date as design and content change during the project. A map built from an early prototype and never revised is a common source of broken redirects on launch day.
What should you test before launch?
On the staging site, check a representative sample of redirects, internal links, canonical tags, language annotations and sitemap entries. Redirects should lead directly to the final page, without chains.
Pay special attention to access and indexing settings. A test site is usually closed with a password or a noindex directive, and these settings must not travel to the public version along with the code: a forgotten noindex can take the whole site out of search.
Decide in advance who does what on launch day and under which conditions you roll back. Save a baseline for important landing pages and business actions, covering visibility, traffic and enquiries, so that later you can tell a migration defect from a problem that existed before. Tell the people who handle advertising and email about the launch date, too: campaigns and email templates often point at old URLs.
How do you check the site after release?
Repeat the checks on the live site, because a successful test on staging says nothing about how the production server is configured. Look for redirects to irrelevant pages, redirect loops, missing images and files, and forms that no longer send.
If the domain changes, use the Change of Address tool in Search Console. Google recommends keeping redirects in place for as long as possible, generally at least a year, so that signals can pass to the new URLs.
Monitor crawling, indexing and page-level search data throughout the transition, and record any other changes made at the same time. Follow unresolved cases until the right destination works. Redirecting every removed URL to the home page is no substitute for mapping relevant equivalents; Google may treat such redirects as soft 404 errors.
Migration mapping record
A template to adapt to your own project.
| Field | Decision to record |
|---|---|
| Old destination | Original URL, its purpose and current value. |
| New equivalent | Final URL and confirmation that the purpose matches. |
| Release changes | Redirect, internal links, canonical and sitemap. |
| Verification | Live server response and the complete customer journey. |
Checklist: site migration
- Map old URLs to suitable final destinations, without chains.
- Check files, language versions and key business journeys.
- Make sure staging passwords and noindex do not reach production.
- Name launch owners and the conditions for a rollback.
- Repeat technical and journey checks after publication.
Example: moving a consulting page
An old consulting page moves to a new service URL with the same scope. Its redirect points directly to that final page, and the navigation, contextual links and sitemap all use the new address, so visitors and crawlers do not pass through an extra hop.
An outdated offer that is being removed gets a separate decision: a close equivalent if one exists, otherwise a 404 or 410 response with a short explanation and links to current services, not an automatic redirect to the home page.
