Website migrations: redirects and URL verification
Inventory URLs, map redirects and verify canonical, content, images and sitemaps, with post-release monitoring and rollback preparation.
Updated: · AI-generated editorial illustration
Moving a website to a new platform or design can break addresses that visitors and search engines already use. A polished replacement with old articles returning 404, broken images or a preview-domain canonical is not a complete migration. The goal is to preserve important content and route historical URLs to suitable destinations.
No responsible process guarantees that search visibility will never fluctuate. Inventory, mapping, validation and monitoring can reduce avoidable mistakes. This guide outlines a small-business workflow; larger sites need their own sampling and infrastructure plan.
1. Inventory the site before changing it
Collect URLs from sitemaps, internal links, available search data and the active catalog. Record type, response, title, canonical, main content and important images. Separate pages to retain, consolidate or retire. Menu links alone do not cover every article or product.
Identify traffic or backlink importance only where evidence is available. If access is missing, state the limitation rather than inventing priorities based on assumed visits. Google's site-move guidance provides a framework for URL changes. The inventory is how you establish whether the replacement still serves the useful historical paths.
2. Map redirects to equivalent content
For every changed URL, choose the destination closest to the original task. Do not send all missing addresses to the homepage. If a product is gone without an equivalent replacement, review the content policy and appropriate response instead of inventing an irrelevant redirect. Retiring content and changing its address are different decisions.
Use a permanent redirect when the move is genuinely permanent, verify its status and avoid old-to-intermediate-to-new chains. Google's redirect documentation explains supported behaviour. A rule saved in a plugin is not proof that the production host is applying it to the intended path.
3. Prepare replacement content and assets
Move titles, bodies, images, alternatives, dates and links according to their records. Retain slugs unless there is a reason to change them. When editing content, document the substantive change instead of resetting every publication date to migration day. Check both language versions and alternates for bilingual material.
Assets must be available to the new website, not only on an implementer's computer or a protected preview host. Test thumbnails, hero images, inline images and social covers. Compare each template with its original source to catch missing tables, checklists or evidence links. Data continuity deserves the same attention as the visual redesign.
4. Verify technical signals before assigning the domain
Check 200 responses for retained URLs, the correct-domain canonical, robots and noindex state, sitemap, metadata and structured data. Preview environments may need indexing restrictions; production needs instructions appropriate to its actual purpose. Do not carry an experimental noindex setting into the release.
Review a sample of every template and all mapped URLs when feasible. Ensure content links no longer point to preview hosts. The technical SEO checklist connects these signals. A successful build proves that code can be built, not that redirects, domain assignment or public content behave correctly. Verification needs the destination environment.
5. Release with a checkpoint and rollback path
Record the commit or version, release time, domain and verifier. Preserve necessary data snapshots and the mapping. Choose rollback steps appropriate to code, domain configuration or data changes. Rolling back code does not automatically restore content deleted in another system.
After release, inspect the public domain, historical URLs, replacement pages and image requests. A deployment marked READY is insufficient. For forms and payments, use checks appropriate to the authorised scope rather than creating unexplained real transactions. Name boundaries still unconfirmed, such as email receipt or webhook delivery, alongside the parts that were verified.
6. Monitor pages and failure groups after migration
Review indexing, canonical selection and errors in Search Console where access is available. Compare traffic across equivalent periods and record other changes happening at the same time. Focus on actionable issues such as incorrect redirects, unexpected 404s, inaccessible images and mismatched metadata.
If clicks decline, avoid immediately changing all URLs again. Investigate affected groups and a specific hypothesis. Give systems time to process new signals while correcting observable defects. A migration report should separate successful deployment, verified URL behaviour and search outcomes still being monitored. These are different kinds of evidence and should not be collapsed into a single migration succeeded claim.
Frequently asked questions
Does a redesign require new slugs?
Usually not. When purpose and content remain, preserving URLs reduces migration work. Change them for a clear architectural reason with corresponding mapping, not merely to make the new design look like a different site.
References and further reading
To apply this to your current website, explore the website service or contact Dean Vu to define a scope around your existing site and actual evidence.