Record what exists before changing it
Save a crawl of the current site and its sitemaps. Add landing pages found in Search Console, analytics and any useful redirect history. A sitemap alone may omit old addresses that still receive visits or links.
For each page, record the address, response status, title, description, canonical and whether it is intended to be indexed. Keep a dated copy. You will need a baseline to distinguish a migration defect from something that was already wrong.
The scope should also say whether you are changing the CMS, domain, design, navigation or content itself. A new CMS does not require new URLs. Retain suitable addresses when the new site can serve them, and make deliberate decisions about the ones that must change.
Give every old address a decision
A page can stay at its address, move to an equivalent page, merge into a genuinely relevant page or be removed. A useful mapping includes the reason, especially for merges and removals. Sending every missing article to the homepage leaves readers without the information they followed the link to find.
For example, if /news/2020/library-hours/ becomes /news/library-hours/, record the old address and its exact replacement. Then use that same decision for the redirect, navigation links and links inside content. Keep the rule in one URL mapping worksheet.
Google recommends preparing a URL map when addresses change, updating internal links and using permanent redirects for permanent moves. Its site-move guidance also explains why unrelated redirects are a poor substitute for a relevant destination.
Check what the new templates output
Importing an SEO title into a field is only half the job. Open the rendered page and verify which title and description the destination theme or SEO plugin actually outputs. Check one example of every important template, including category archives and language variants if they are part of the site.
Canonical tags need the same attention. A staging hostname copied into production can contradict the URLs in links and the sitemap. Keep those signals consistent with the preferred public address; see Google’s canonical guidance.
Also test images and documents. An article may load while its embedded PDF still points to a server scheduled for retirement.
A page can return 200 and still fail the launch checks
We ran a small demonstration with three synthetic source records and a local website. The first run deliberately used faulty mapping and page settings. The corrected run used the same input. No customer site or CMS connector was involved.
| Check | Faulty run | Corrected run |
|---|---|---|
| Canonical host | staging.publication.example | publication.example |
| Robots meta | noindex, follow | index, follow |
| Link to the sign-in guide | Old address that redirects | Final address directly |
The article loaded in both runs. Its HTTP status and title could not expose those three faults. Across the mapping, page and URL checks, the first run exposed nine intentionally introduced failures; the corrected run passed all twelve checks.
One source record still had no resolvable author and was held out of the corrected import. Passing the hold rule means the exception was handled as designed; it does not mean all content has moved or a launch is approved. Download the observed results (CSV). The mapping walkthrough explains the record decisions, and the redirect example follows the HTTP responses. These checks measure the demonstration behavior, not Google rankings or indexing.
Assign the launch checks to named owners
The migration team, developer and SEO lead may control different parts of the release. Record who can change each setting and who will check it.
- Before launch: test representative pages, their metadata, internal links and planned redirects in the prepared environment.
- At launch: confirm production responses, the preferred hostname, indexing instructions, sitemap and redirect behavior. Remove staging restrictions from production where appropriate; keep the actual staging site restricted.
- After launch: crawl the public site, inspect important landing pages and record errors that require a fix or an editorial decision.
Use the full migration checklist for the wider release work, including forms, backups and content acceptance.
Watch the pages that matter to the business
Start post-launch monitoring with pages that brought enquiries or meaningful search visits before the move. Review response errors, indexation, selected canonicals and changes in clicks alongside the launch log. A tracking problem can look like a traffic loss, so confirm measurement is working before interpreting the numbers.
A decline is a reason to investigate, not proof of one particular cause. Check whether the affected URLs changed, lost content, became inaccessible or received conflicting indexing signals. Keep a record of the fix and when it went live.
No migration plan can guarantee search positions. What it can provide is an address map, checked templates and evidence of the work completed. Our validation guide explains how to turn those checks into a reviewable handover.
Add the right scope to the estimate
If your migration includes a domain change, a large archive or an existing redirect backlog, include that in the enquiry. Redirect implementation, template changes and monitoring need owners and an agreed scope. They should not appear as surprise tasks on launch day.
For common routes, review Wix to WordPress or Drupal to WordPress. The cost guide explains how this work affects a CMS migration estimate.