How do you test a website migration?

Last updated: 23 October 2026

Test a website migration by listing every URL of the old site, then requesting each one on the new site and comparing the two versions: the HTTP status, the SEO fields, the body text and the layout. Run the comparison on staging before launch and again on the live site after it, and fix every page that differs without a reason.

The checklist, step by step

These steps work with any tool, including a spreadsheet and a browser. They are ordered so that each one relies on the one before it.

1. Freeze an inventory of the old site. Collect every URL from the old site’s sitemap.xml, the Sitemap: lines in its robots.txt and a crawl of its links. Add the pages that receive search traffic or inbound links, even if no sitemap lists them. This list is the baseline: a page that is not on it is never checked.
2. Write the redirect map. For each old URL, note the new URL it should reach. A page that keeps its path maps to itself. A page that moves needs a single permanent redirect (301 or 308) to its new address. A page that is retired on purpose should redirect to its closest replacement or answer 410.
3. Request every old URL on the new site. Follow the redirects and record the final status. Every row should end in a 200 on the page the map names. Anything that ends in a 404, a 5xx, a login wall, a redirect loop or a chain of several hops is a broken page. The guide finding broken pages after a migration covers this step in detail.
4. Compare the SEO fields. For each pair, compare the title, the H1, the meta description, the canonical URL, the robots meta tag and the hreflang links. A canonical that still names the old host, or a noindex carried over from staging, can take a page out of search results. The guide checking SEO after a migration lists what to look for in each field.
5. Compare the body text. Content often goes missing in a migration: a sidebar that was not rebuilt, a tab that no longer opens, a block the importer skipped. Compare the words on each pair of pages, not only the headings.
6. Compare the layout at each width. Screenshot both versions of each page at phone, tablet and desktop widths and look for missing images, broken grids and overlapping elements. A layout that holds on a desktop can still collapse on a phone.
7. Check the new site’s own crawl files. The new sitemap.xml should list the new URLs and only those, and the new robots.txt should not block the whole site, as a staging configuration often does.
8. Repeat after launch. Run the same comparison against the live site on launch day, when DNS, the CDN and production settings are in place, and keep the result as a record of what was verified.

What DiffiCat automates

DiffiCat runs steps 1 and 3 to 6 for you. Enter the site you are moving from as Site A and the site you are moving to as Site B.

• The inventory. DiffiCat finds the pages through five strategies, in order, and stops at the first that returns pages: a sitemap URL you supply, the source /sitemap.xml, the Sitemap: lines in the source robots.txt, the target /sitemap.xml remapped onto the source, and a crawl of the source homepage. You choose which pages to test and set a page limit: chips of 10, 20 or 50, any number up to 10,000, or blank for no limit.
• Three checks on every page. “Exists” compares the HTTP status of both versions. “Content” compares the title, H1, meta description, canonical, robots meta, hreflang and body text, with a 90% word-overlap threshold for the body. “Visual” compares screenshots pixel by pixel, with a threshold you set from 0% to 100% (0% by default, so any changed pixel is flagged).
• Every width. Captures run at 375 px, 768 px or 1440 px, or any width from 320 px to 2560 px.
• A report you can act on. The report leads with a verdict and lists pages worst first, with blame indicators naming Site A or Site B, word-level text diffs and side-by-side screenshots. Export gives a ZIP with report.txt, report.csv, manifest.json and the screenshots as PNG files.

Step 2 stays yours: DiffiCat compares each page at the same path on both sites, so a page that moved shows up as a failure until the old path redirects to the new one. Step 7 also stays manual.

What this does not catch

• Behaviour: forms, search, checkout, sign-up flows and other interactive features need their own functional tests.
• Speed and server load: a page can match exactly and still be slower.
• Pages nobody listed: if a URL is missing from the inventory, no tool checks it.

DiffiCat has its own limits. Both sites must resolve on the public internet: localhost, loopback and private-network addresses are refused, so deploy staging to a public URL (password protection is fine). Pages are rendered in headless Chromium only. Sign-in with a username and password is supported, but sign-ins that need a code (MFA), a CAPTCHA or single sign-on are not.

Run the checklist on your sites

Enter your old and new site in the try-it form, or open app.difficat.com and start the free trial: 500 captured pages once when signed in, 100 without signing in, with every check and viewport width and no card needed.