A website migration checklist is the documented sequence that carries a site to a new platform, structure or domain without losing what the old URLs had earned: a measured baseline, a complete URL inventory, a one-to-one mapping, correctly implemented redirects, preserved metadata and structured data, and monitored indexation after launch.
For an industrial site the inventory is what makes or breaks it. Alongside HTML pages sit datasheets, installation manuals, declarations of conformity, CAD files and part-number URLs, many of them linked from distributor sites and specification documents that will never be updated. A checklist that covers only the CMS page list is incomplete before it starts.
Before anything moves, capture organic sessions, impressions, ranking positions and inbound links per URL, along with crawl statistics and index coverage. Export it rather than relying on the reporting interface, since comparison windows shift.
Without a baseline there is no way to distinguish a migration fault from seasonal movement, and no way to demonstrate that the migration went well. It is the shortest task on the list and the one most often skipped.
Combine a crawl of the live site with the CMS page list, the XML sitemaps, search console coverage, backlink data and server logs. Logs surface documents no longer linked from the site but which distributors and specifiers still request directly.
Add every domain and subdomain the organisation holds, taken from the registrar rather than from memory. Microsites built for a trade fair or a product launch are a common source of URLs no one remembers owning.
Every URL in the inventory needs a named destination: the closest equivalent page, or a deliberate decision to retire it. Directory-wide blanket rules to a category or the homepage are quick to write and account for much of the loss attributed to migrations.
Documents and part-number URLs belong in the same mapping rather than a later pass. See how to redirect legacy PDF URLs for that part of the work.
Use permanent redirects with a single hop to the final URL, and confirm each returns the expected status and destination on the staging environment. Chains through an intermediate rule accumulate quickly where several restructures have happened over the years.
Test a sample from every URL pattern, and not the top pages alone. Faults tend to sit in the patterns rarely browsed in review: older document paths, language variants and legacy query strings.
Titles, meta descriptions, heading structure, canonical tags, hreflang sets, structured data and internal linking all need to arrive intact. Template rebuilds frequently drop product structured data or flatten a heading hierarchy without anyone noticing during visual review.
Check that catalogue content renders without client-side execution on the new platform, particularly where specifications now arrive from a PIM or product data feed.
Remove staging directives, submit the new sitemaps, and check index coverage, crawl errors, redirect resolution and organic sessions daily for the first weeks, then weekly. Compare against the baseline rather than against expectation.
A mapping error found in week one is a configuration change. The same error found in month six has already cost two quarters of visibility and takes longer to recover from.
It is the documented sequence that protects search visibility through a platform, structure or domain change: a measured baseline, a complete URL inventory including documents and part numbers, a one-to-one old-to-new mapping, single-hop permanent redirects, preservation of metadata, structured data and internal links, and monitored indexation for the weeks after launch.
At the point the new structure is being designed, not when the build is finished. The inventory and mapping influence the information architecture, since a structure that leaves large parts of the old site without an equivalent creates redirect decisions that are difficult to make well. Starting during launch week is what produces blanket rules.
Document URLs and part-number pages. Datasheets, manuals and declarations of conformity are linked from distributor sites, trade associations and specification files, and those links cannot be corrected on request. Superseded product pages are the next most common omission, since the installed base continues to look for models that are no longer sold.
A well-prepared migration usually shows a short, shallow dip while search engines process the change, followed by a return to the previous level. Where the mapping is incomplete the decline is deeper and lasts longer, and the part attributable to unrecoverable external links may not return at all. The variable is the preparation rather than the platform.
The sequence is the same, with additions. A domain change also needs the new property verified in search console before launch, the change of address signal submitted, email and certificate records confirmed, and the old domain retained under the same ownership so redirects continue to resolve. Retiring the old registration removes every redirect at once.
Much of it can be reconstructed afterwards from archived crawls, backlink data, search console history and server logs, then mapped and redirected retrospectively. Recovery is usually partial rather than complete, and it favours the URLs still receiving requests. See why did traffic drop after migration for the diagnostic sequence that identifies which recoverable causes are present.
Tell us what is moving and we will build the checklist against your own URL inventory.