A practical release checklist
SEO migration checklist. Make every URL accountable.
A website move needs decisions you can test: what changes, where each important URL goes and who decides whether to launch. Use this checklist and copyable mapping record to prepare a domain, CMS or site-structure change.
Define the change
Separate the projects in your brief.
Write down whether the domain, page addresses, CMS, design or hosting will change. Name the person responsible for each part and the business functions that must keep working. Where possible, separate major changes so problems are easier to trace.
Moving an unchanged WordPress site between hosts calls for infrastructure and data checks. A project that changes URLs also needs a page-by-page destination plan. Google provides separate guidance for hosting changes without URL changes.
Jump to the URL record, release checks, rollback plan or post-launch review.
If the move is part of a redesign, website development describes how we agree the scope of the new build.
Before editing
Capture a baseline you can compare.
Collect the current URL inventory from the CMS, sitemap and available crawl or search data. Include important downloads and images. Record which pages support enquiries, sales or other agreed goals. Keep the observation dates and filters with any performance exports.
Create a change log with a task, owner, approval, expected result, actual result and evidence location. Mark unavailable data as unavailable. This prevents a missing measurement from being mistaken for a successful check.
Agree who can approve the release, report an incident and authorise a rollback. Keep passwords and customer data out of the shared checklist.
Copyable working record
Build the URL map before configuring redirects.
Copy this record once per URL into your project document, or use its labels as spreadsheet columns. Fill expected results before testing; add observed results afterwards. Use complete URLs in the working map, including protocol and domain.
Old URL: New URL (if applicable): Decision: keep / move / remove Reason for this decision: Expected HTTP response: Expected canonical URL: Language counterpart: Internal links to update: Owner and approval date: Observed result and test date: Evidence location: Open issue and next action:
Worked example: a renamed service page
Illustrative paths: /old-service/ moves to /services/new-service/ because the new page serves the same purpose. Expected result: one permanent redirect to the new page, which returns HTTP 200. Keep the test result marked “Not tested” until someone checks it.
A removed page with no suitable replacement can return 404 or 410. Avoid sending unrelated old pages to the homepage. Google’s site-move documentation explains destination mapping and permanent redirects. Rankings can fluctuate during a move; a checklist cannot remove that uncertainty.
Want help applying this to your website? See Website development or tell us about your project ↗
Acceptance checks
Give each check an expected result.
01
Destination and content
Open each priority destination. Check its response, main content, headings, images and downloads. Follow old URLs to confirm the final page and check for redirect loops or extra hops.
02
Canonical and indexability
For pages intended for search, check that temporary launch restrictions are removed and the canonical identifies the intended production URL. Internal links and the sitemap should agree. Review the canonical guidelines when content is duplicated.
03
Language versions
If translated counterparts exist, check that the language switcher reaches the matching page and hreflang references are reciprocal. Review Google’s localized-page guidance. Do not pair unrelated content simply because the languages differ.
04
Forms and integrations
List the contact, login, booking and checkout paths that apply to the site. Test in an isolated environment with authorised test data and external effects controlled. Record who approves any final live test.
05
Measurement continuity
Where measurement is already authorised, compare the event definitions and destination pages with the baseline. Record the release time and any configuration changes. A change in tracking can alter reported numbers without reflecting a real change in enquiries.
Before the release decision
Prepare a rollback that accounts for new data.
For WordPress, preserve the files and database needed to restore the agreed starting point. A content-only export is not a complete site backup. The WordPress migration handbook provides platform-specific steps; adapt the runbook to the actual environment.
Record the backup time, protected storage location, restoration steps, person responsible and evidence from a test restore. List which DNS or redirect settings would also need restoring, if those changes are part of the approved project.
Define the conditions that stop the launch, such as a broken priority form or unavailable key pages. Before restoring an older database, decide how to preserve orders, enquiries or edits created after the backup. Reverting files alone may not restore a consistent state.
The release record should state: go or no-go, unresolved issues, the owner accepting any remaining risk, rollback authority and the next review time.
Before you rely on a rollback, test the restore itself. See WordPress backup restore test.
After launch
Review failures and search changes separately.
Repeat the acceptance checks against the public site and record the results. Prioritise broken visitor journeys, incorrect destinations and unexpected error responses. Review logs and available Search Console data for problems that emerge after publication.
Compare equivalent periods and annotate other changes, such as content edits or campaigns. Keep search visibility, tracked enquiries and confirmed business outcomes separate. Schedule follow-up checks and assign an owner to unresolved issues.
For a project review, see our SEO assessment. Ongoing updates and recurring checks can be scoped through WordPress maintenance.
Planning a website change?
Share the current website, the planned changes and your key visitor journeys. That gives us a starting point for discussing an assessment and the work that would need a separate scope.