SEO migrations without losing the pages that already work
Build a URL migration ledger, test redirect destinations, and separate search visibility changes from broken enquiry journeys.
Preserve the job each page does
A migration can return a successful HTTP response and still remove the answer a visitor came for. For example, replace a maintenance service page with a broad consulting page: the link works, but the offer, supporting detail, and next step have changed. Preserving that URL alone does not preserve the useful page.
Start with a ledger of existing URLs. Combine the CMS export with search landing pages, inbound links, and pages used in campaigns or sales conversations. Give each important page a purpose and an owner. Record the current title, main topic, canonical URL, enquiry destination, and any downloadable assets before changing templates. This makes removal a reviewable decision rather than an incidental consequence of rebuilding navigation.
Make every old URL an explicit decision
Keep a URL when the replacement still answers the same question. For a move, choose the closest relevant destination and use a permanent server redirect. For a removed offer with no replacement, an honest 404 or 410 is preferable to sending everyone to an unrelated homepage. Google documents irrelevant redirects as a possible soft-404 problem.
The following CSV is a small, framework-independent migration fixture. It is an example data contract for a reviewer or a custom checker, not a redirect configuration consumed automatically by a web server.
old_path,decision,new_path,expected_status,owner
/services/site-care,keep,/services/site-care,200,content
/services/old-audit,redirect,/services/technical-audit,301,engineering
/offers/retired-package,remove,,410,content
Test the first response and the final page
A browser often hides redirect chains. Test the first response separately from the destination: status, Location header, final status, and canonical URL. Include trailing slashes, case differences where relevant, and known query parameters. Tracking parameters may be retained; old parameters that select content need a deliberate mapping.
For every redirect row, require a direct hop to the intended final page. Then verify that the final page answers the old intent, links to the right enquiry route, and loads its images or downloads. A generic success page that returns 200 should fail this review. Test both the old and new hostname when the domain changes.
Remove accidental staging noindex settings before public release, update internal links and sitemap entries, and check canonical and language annotations against final URLs. Keep staging itself access-controlled during preparation. A prelaunch checklist should distinguish settings that belong only on staging from those required on production.
Cut over with an operational owner
Google recommends retaining redirects for at least a year. Budget for the old hostname, certificates, and redirect rules accordingly. Do not let a later infrastructure cleanup silently remove them. Search processing takes time, so a short-term ranking change alone is not proof of a failed migration.
Record the release time and retain comparable prelaunch measurements by landing page. After launch, inspect response failures, search indexing reports, and enquiry completion separately. Lost clicks can indicate discovery or relevance issues; stable visits with missing enquiries suggest a different investigation. Check tracking changes before interpreting either as business impact.
Rollback also needs a URL plan. Restoring the old application while leaving new redirects active can create loops. Keep the application version and routing configuration paired in the release record, and rehearse restoring that pair on a test environment.
- Every high-value URL has a reviewed keep, redirect, or remove decision.
- Enquiry forms and important downloads work through the final public URLs.
- An owner monitors errors and search visibility after launch.