Protect important URLs and customer journeys during a website migration. Plan URL mapping, launch checks, enquiry testing and accountable monitoring.
A website migration involves more than opening a new design. Visitors following old links, search results, forms and measurement systems all need a working route into the new site. A redesigned homepage can look complete while an important service URL disappears. Manage migration as a transition project, with a named owner for each critical address and customer task.
Record what is changing before planning the switch
A simultaneous domain, URL structure, platform and content change makes it harder to identify the cause of a problem. Google's guidance on migrations with URL changes recommends separating major changes when practical. If your project requires a combined release, track each change explicitly instead of hiding everything under “new website”.
Build the existing-page inventory from more than the navigation. Include organic entry pages, enquiry sources, linked resources and URLs shared by your sales team. Remember downloads, language variants and campaign destinations. This protects business uses that may be invisible to the design team.
Give each old address a relevant destination
Your mapping table should contain the old URL, intended replacement, content decision and verification result. Sending every previous page to the homepage does not preserve the answer a visitor expected. Merged content needs a genuinely relevant destination; discontinued services require a separate editorial decision.
Repeating an old heading does not establish equivalence. The new page should also answer the underlying question, explain the relevant scope and provide a useful next step. Have content and technical owners approve the mapping together so redirects are not improvised on launch day.
Use observable evidence for the launch decision
Adapt this checklist to the project and add an owner, test example and result to each row. As the release approaches, replace a vague “SEO is done” statement with evidence of the items actually checked.
| Stage | Check | Evidence |
|---|---|---|
| Preparation | Important old URLs and replacements | Approved URL mapping |
| Preparation | Titles, descriptions and language links | Representative page comparison |
| Launch | Redirect and destination behaviour | Old link reaches the relevant content |
| Launch | Forms, calls and purchase journey | Test record reaches the correct owner |
| Launch | Crawler access and sitemap | Checks against the live environment |
| Monitoring | Important entry pages and error groups | A report with assigned follow-up |
Start launch testing from old links too
Imagine a new site with a working menu but an old quotation page still used by an advertisement returning an error. The visitor may leave without ever seeing the new navigation. This hypothetical scenario explains why testing journeys from existing addresses matters.
Check for staging restrictions left in production, links pointing to the wrong domain and forms still using obsolete recipients. Try the mobile menu, language switch and contact route in the same review. A successful technical switch does not establish that every commercial journey works.
Assign ownership beyond release day
Google notes that search visibility can fluctuate during a migration; do not promise a fixed recovery date. Investigate access, errors, indexing signals and enquiries by page group before interpreting the entire change through one total-traffic chart.
Monitor both old and new addresses, record evidence for important problems and retest each correction. Someone must own that issue list. Development, content and marketing teams need an agreed handover so the period immediately after launch does not become an accountability gap.