Practical guide 7 min read
A website migration SEO checklist is a record of what must be preserved, changed and verified when an existing website moves. It connects the old URL inventory to the new site, checks the launch rather than only its appearance, and gives someone responsibility for exceptions after release.
This guide covers migration execution. If you are still choosing the level of change, start with the website redesign vs rebuild decision guide. A new design is not a reason to change every URL, and a migration does not guarantee better rankings.
1. Define what is actually moving
Write down whether the project changes the domain, URL paths, CMS, content, hosting or several of these. A hosting move that keeps URLs unchanged needs different search checks from a domain move. Separate unrelated changes where practical so a problem can be traced to the relevant release.
Name the launch approver, technical owner, content reviewer and person monitoring enquiries. Agree which workflows must remain available, how new data will be handled during the switch, and what would stop or reverse the launch. Do not treat every migration as a simple file transfer.
2. Capture a useful baseline before changing anything
Combine the CMS inventory, sitemap, analytics, Search Console and relevant server logs to identify existing pages and assets. A sitemap alone may miss old landing pages that still receive enquiries or external links.
- Record each important URL, purpose, current status, title, main heading and canonical.
- Identify service, product and resource pages with relevant search activity, links or business value.
- Include images, downloads and other assets whose addresses will change.
- Record the measurement period and known problems; keep private enquiry data out of shared planning sheets.
- Confirm business-owned access to hosting, domain, CMS, analytics and Search Console before the change.
Use a baseline to compare like-for-like pages and periods after launch, not to promise that every old position will remain unchanged.
3. Build an old-to-new URL map
Give each old URL an explicit decision: keep it, move it to an equivalent page, merge it into a relevant consolidated page, or retire it with no replacement. Assign a reviewer to ambiguous destinations before redirects are deployed.
For each row, record the old URL, decision, destination if applicable, expected response, final canonical, reason, owner and test result. Mapping by similar wording alone is unsafe: the destination must still satisfy the visitor’s purpose.
Illustrative URL-map example
The following example uses example.com to demonstrate decisions. It is not an Agal client project or a claim of migration results.
| Old URL | Decision | Expected check |
|---|---|---|
example.com/contact/ |
Keep the address | Returns 200, shows the intended contact page and uses its own canonical URL. |
example.com/websites/ |
Move to /web-design/ with the same service purpose |
Permanent server redirect to the final destination; destination returns 200 with the new canonical. |
example.com/guide-a/ and /guide-b/ |
Merge into a genuinely consolidated /combined-guide/ |
Both redirect to the relevant combined resource; useful content and internal links are reviewed. |
example.com/retired-offer/ |
Remove an offer with no relevant replacement | Returns a genuine 404 or 410; does not redirect to an unrelated homepage. |
A 200 response alone is not a pass if the destination is empty, unrelated or blocked from indexing. Check the page content and search signals as well as the response.
4. Prepare staging and recovery without risking new data
Keep a working backup of the required files, database and configuration, with an authorised person able to restore it. Test recovery in an isolated environment where appropriate; the existence of a backup file does not prove that restoration works.
Document how orders, enquiries, bookings and account changes created during the launch window will be reconciled. Restoring an old database blindly can discard new records. Agree whether a controlled pause, final data sync or another platform-specific process is required; there is no universal launch window that fits every site.
Protect staging and document its development-only indexing restrictions. Prepare the production robots and indexing settings separately so a staging noindex rule is not accidentally carried into launch.
5. Update references throughout the new site
Update navigation, contextual links, buttons, image references and downloads to their intended final addresses. Do not rely on redirects for every internal click. Review canonical tags, sitemap entries and structured-data URLs for old destinations.
For a multilingual or multi-country site, update applicable hreflang relationships as well. Check the selected language and market pages, not just the homepage. Preserve useful page purpose and content when replacing templates.
6. Test redirects against the complete mapping
Where a URL genuinely moves, use an appropriate permanent server-side redirect, such as 301 or 308, to its relevant final destination. Avoid loops, unnecessary chains and blanket rules that send unrelated old pages to the homepage.
Test each mapped URL, not only one example from a redirect rule. Record the initial response, redirect destination, final response and rendered result. Include relevant hostname, protocol and trailing-slash variants in the test set. Retired pages need an intentional error response rather than a misleading success page.
Google’s official site-move guidance recommends keeping redirects generally for at least a year. Plan ongoing ownership of the old domain and redirect rules instead of deleting them immediately after the launch looks correct.
7. Use a launch acceptance gate
Give the approver evidence for the changed scope, with failures and untested items visible. The gate should cover:
- Priority public pages load the approved content, with correct canonicals and intended indexing controls.
- Mapped redirects and intentionally retired URLs return the expected results.
- Forms, notification receipt, calls, bookings, checkout and integrations work where applicable.
- Mobile navigation, key actions and measurement still function.
- Recovery access and new-data handling are understood by the responsible team.
Use the business website launch checklist for general usability and launch QA. The migration record adds old-to-new continuity; it should not replace normal customer-workflow testing.
8. Notify search engines appropriately
Publish an accurate sitemap containing the intended current URLs and review it in Search Console. Maintain verification access for the affected properties. For a domain or subdomain move, assess the Change of Address tool for the old property; it is not needed for path-only changes, HTTP-to-HTTPS moves or a www/non-www switch on the same domain.
URL Inspection can help diagnose an individual page and its accessibility. A successful live test, sitemap submission or indexing notification is not proof that the page has been indexed or will rank. Avoid repeatedly submitting unchanged URLs instead of resolving a concrete issue.
9. Monitor exceptions after the switch
Compare relevant old and new URLs in Search Console, analytics and server logs. Review unexpected errors, blocked pages, mismatched canonicals and important pages missing from the intended sitemap. Check real enquiry receipt separately from analytics events.
Create an exception record with the affected URL or workflow, expected result, observed result, evidence, severity, owner and next review. Prioritise a broken enquiry path or wrong redirect over cosmetic differences. Keep migration observations separate from unrelated campaigns, seasonality and tracking changes.
Search visibility can fluctuate while a move is processed. A daily ranking change alone does not establish the cause or justify reversing a working migration. Investigate technical and page-level evidence before deciding on remediation or a controlled rollback.
10. Handover the migration record
Keep the approved URL map, test results, deployment date, change log, known exceptions, redirect ownership and recovery responsibilities with the business. Protect credentials and private customer records rather than including them in a general handover document.
Schedule ongoing checks according to the site’s risk and change rate. The WordPress maintenance checklist covers recurring care after the migration-specific issues are resolved.
Frequently asked questions
Does a visual redesign require new URLs?
No. Keep useful addresses when their purpose stays the same. A change in colours, typography or page layout does not by itself require a URL migration.
Can every removed page redirect to the homepage?
No. Redirect to a relevant replacement or consolidated resource. If there is no suitable replacement, a genuine 404 or 410 can be more accurate than an unrelated destination.
Should we use Change of Address for every migration?
No. Google’s tool applies to domain or subdomain moves, not ordinary path changes, HTTP-to-HTTPS migration or switching www on the same domain.
How long does migration recovery take?
There is no guaranteed recovery date. Processing depends on the scope, URL count, crawling and technical implementation. Review errors, page relevance and business workflows rather than promising a fixed ranking-recovery deadline.
For an existing-site project, review Agal Technologies’ website redesign scope. If the work needs search-specific migration planning, agree those responsibilities within the SEO service scope. Share the current website, proposed changes and important customer workflows when requesting a written proposal.
Related Blogs
