Site migration checklist: from T-4 weeks to day 45
Domain change, replatform, host move or a new URL scheme: the links pointing at you do not care which. This list tells you what to capture before launch and what to re-check after it.
ArchiLinks research team ·
Our position
Most migration losses come from missing redirects, not from the redirect type
Teams argue about 301 versus 302 for hours and then ship with 3,000 external-link URLs returning 404. Find all backlinks to a website before you decide anything else, because the list tells you where the risk sits.
- Pull linked pages 4 weeks ahead, not the night before.
- Every URL with an external link needs a one-hop 301 to a relevant page.
- Keep redirects live for at least a year, as Google's own documentation advises.
The timeline
T-4 weeks: inventory
Crawl the old site, export the Search Console performance report and run toppages plus refdomains for the old host. Store the three files together with the date.
T-3 weeks: map
Build the redirect map from linked pages first, from traffic second, from the crawl last. The redirect map recipe shows the ranking script.
T-2 weeks: test on staging
Run every old URL against staging and assert one hop, status 301 and a 200 at the end. Fail the build on a chain or a loop.
T-0: launch
Ship the redirects, the new sitemap, the updated canonical tags and the internal links in one release. Submit the new sitemap in Search Console. For a domain change, use the Change of Address tool.
T+1 week: logs and coverage
Check server logs for Googlebot hits on old URLs, then the Pages report for spikes in 404 or soft 404. Fix the map; do not wait.
T+30 to 45 days: link diff
After the monthly refresh, pull refdomains for the new host and compare it with the old file. Differences larger than a few percent deserve a look.
What changes with the type of move
| Move | Redirects | Extra checks | Link-data focus |
|---|---|---|---|
| New domain | Host-wide 301, path-level where paths change | Change of Address tool, old domain kept at least 12 months | Referring domains moving to the new host over time |
| HTTP to HTTPS or www change | Host-level 301 | Canonical, HSTS, mixed content | Few differences; confirm both hosts resolve to one |
| Replatform, same domain | Path-level map | Pagination, parameters, trailing slashes | Top linked pages that changed path |
| Subdomain to subfolder (or back) | Path-level map, host-level rules | Cookies, robots.txt per host, analytics | Whether links point to the old host or the new one |
| Merging two sites | Many-to-one map | Duplicate content, canonical choices | Overlap of linking domains via intersect |
The launch-day tick list
- Old URLs return 301 in a single hop, tested by a script rather than by hand.
- The new host returns 200 with a self-referencing canonical on every template.
- robots.txt on the new host does not carry staging rules. A leftover Disallow: / is the classic launch-day accident.
- The XML sitemap lists only 200, indexable, canonical URLs.
- Internal links, navigation and structured data point to new URLs, not to redirected ones.
- Analytics and Search Console properties exist for the new host before the switch.
- The baseline JSON files are committed, with the date in each file name.
Our link graph is rebuilt about once a month. A link created in the week of your launch may not show on the day-30 pull. Use Search Console's Links report for the last mile, and judge the diff from the second refresh. The same data feeds the internal vs external equity review after launch, and hreflang regional domains covers the multi-country case.