Agree the migration scope
Identify whether the project changes design, content management, domains, hosting, URL structure or several of these together. Each change introduces different dependencies. Record who can alter DNS, hosting, redirects, analytics and the content platform. Agree a launch owner and a rollback decision before the release window.
Where practical, avoid unnecessary simultaneous changes. If everything changes at once, diagnosing a problem becomes harder and teams can disagree about which system caused it.
Inventory existing URLs and evidence
Combine a crawl with sitemaps, analytics landing pages, Search Console data and known important external links. Include PDFs and legacy campaign pages where relevant. Record current status, canonical target, page purpose and commercial importance. A crawler alone may miss unlinked pages still receiving visits.
Use the redirect-mapping template to record each old URL, proposed destination, reason, owner and test result. The supplied rows are examples of structure, not live redirect instructions.
Map destinations deliberately
- Preserve useful URLs where there is no reason to change them.
- Map genuinely replaced pages to the closest relevant destination.
- Keep useful content that still serves customers.
- Decide explicitly how discontinued material should respond.
- Avoid blanket homepage redirects and unnecessary redirect chains.
A mapping is not approved merely because the destination returns 200. The destination should also meet the old page’s relevant user need. Redirect to the final intended page wherever possible.
Test staging against acceptance criteria
Check page content, titles, descriptions, canonical declarations, navigation, images and structured data. Test important enquiry, booking and payment journeys. Confirm that staging controls will not accidentally block the public site at launch. Inspect generated HTML and actual HTTP responses rather than judging screenshots alone.
| Check | Acceptance evidence |
|---|---|
| Redirects | Old URL reaches approved final destination |
| Conversions | One completed action produces correct measurement |
| Indexing controls | Public pages use intended robots/canonical settings |
Use a controlled launch checklist
Take appropriate backups, confirm access and publish during an agreed window. Activate tested redirects, update internal links and publish a sitemap containing preferred public URLs. Check the most valuable journeys immediately after launch. If the domain changes, review Google’s site-move instructions, including whether Search Console’s Change of Address tool applies. Do not assume that changing DNS also transfers the content relationships.
Keep old-domain access and renewal responsibilities clear so redirects remain operational.
Monitor and close the project properly
Review server errors, redirects, crawling, indexing and completed business actions after release. Some movement is possible while search engines process changes; no migration checklist guarantees unchanged rankings. Investigate specific failures instead of treating every fluctuation as either normal or catastrophic. Keep a log of corrective changes and compare like-for-like data where possible. Close the project only when the agreed acceptance checks are complete and ongoing ownership is clear.
Common questions
Can we delete the old pages after launch?
Only after deciding their intended treatment. URLs receiving visits or references may need retained content or relevant redirects, not silent removal.
Does a sitemap replace redirects?
No. A sitemap lists preferred URLs. Redirects handle requests to old addresses and communicate the move.