SHORT ANSWER
A website migration checklist has three phases. Before launch: record a baseline of rankings and traffic, collect every old url, and build a redirect map that gives each one a target on the new site. On launch day: publish the redirects in the same release as the new site, remove the staging blocks, and submit the sitemaps. After launch: test that every old url resolves in one hop to a page that answers 200, and watch Search Console for several weeks. The redirect map connects all three — it is built from the inventory, shipped on the day and tested afterwards.
The three phases at a glance
| phase | when | what it produces | done when |
|---|---|---|---|
| before launch | from the moment the new url structure is fixed | a baseline, a complete list of old urls, a reviewed redirect map, a new sitemap | every old url has a target or a deliberate 410 |
| launch day | the release itself | the new site live with its redirects, no leftover noindex, both sitemaps submitted | the top urls answer 301 → 200 from outside |
| after launch | the first day, then weekly for two to three months | a full redirect test, a list of fixes, Search Console trends | 404s flat, old urls dropping out of the index, traffic back at the baseline |
The checklist below follows Google’s own guide to site moves with url changes and adds the parts that guide leaves to you: how to find all the old urls, and how to prove the redirects work.
Before launch: the checklist
Almost everything that decides whether a migration keeps its traffic happens here. The items are roughly in order; the first three cannot be done after the old site is gone.
- record a baseline. Export the Search Console performance report by page (clicks and impressions for the last three to twelve months), the landing pages from your analytics, and a crawl of the old site with titles and status codes. After launch, this is the only way to tell a normal fluctuation from a loss.
- collect every old url. A crawl only finds what the site still links to. Add the sitemap.xml (and any sitemap index), the Search Console export, server logs and the redirect file of the previous relaunch. Finding the urls nothing links to covers the sources one by one.
- freeze the new url structure. The redirect map points at new urls; every slug renamed after the map is built is a redirect to a 404. Agree on trailing slashes, lowercase paths and folder names before mapping starts.
- build and review the redirect map. One target per old url, one to one where an equivalent exists, the nearest category where it does not. The next section is about this step.
- decide what is gone on purpose. Expired campaigns, past events and products with no successor and no links can answer 410 instead of being forced onto an unrelated page. See 301 vs 302 vs 410.
- carry the on-page signals over. Titles, meta descriptions, h1s, body copy and structured data of the pages that earn traffic should arrive on the new site intact, or deliberately improved — not lost in a template change.
- point internal links and canonicals at the new urls. Google’s site move guide asks for canonical tags and internal links on the new pages to use the new urls. An internal link that relies on a redirect adds a hop on every visit.
- prepare the new sitemap with only the new, canonical urls that answer 200 — and keep a copy of the old one to submit as well.
- keep staging out of the index with a password or a noindex, and write down where that block lives so it is removed on the day.
- move the tracking. Analytics, tag manager, consent banner and conversion tags on the new templates, tested on staging.
Where the redirect map fits
The redirect map is the one artefact that touches every phase. It is built from the url inventory, it ships on launch day, and the test after launch checks the live site against it. That is also why it cannot be built too early or too late: it needs the complete list of old urls on one side and the final urls of the new site on the other. In practice that means building it against staging once the structure is frozen — typically two to four weeks before launch, leaving time to review the uncertain rows.
inputs — the old url list from all sources, the new site’s urls (a crawl of staging, or its sitemap), and ideally clicks per url so the review starts with the pages that matter.
output — one row per old url with a target and a status, plus the same list in the format your platform imports. The redirect map template shows the columns worth keeping.
the checks it has to pass — no target that redirects itself (a chain), no rule that leads back to its own source (a loop), no target that does not exist on the new site, no rows sending a whole section to the homepage.
Silentfrog builds that map: it crawls the old site and the new one — a staging domain like your-site.webflow.io works — reads both sites’ sitemaps, pairs identical paths, scores the rest on slug, title and h1, and puts the uncertain rows in a review bucket. Whole folders move with one directory rule, a Search Console export adds a clicks column, and the result downloads as a generic csv or in the spelling of your importer (Webflow, Shopify, the WordPress plugins, Squarespace, .htaccess, nginx). If staging sits behind an ip allowlist, the desktop app crawls from your own machine; if the old site is already offline, its sitemap or a url list stands in for the crawl (when the old site is gone).
the crawl form with the old site url, the new site url, the page cap, the sitemap option and the field for your own url list.
EXAMPLE
a 600-page site moves to a new cms. The map is built against staging three weeks before launch: 410 urls keep their path, two directory rules settle 120, 50 fuzzy matches are accepted, 20 are reviewed by hand. A week later the content team renames the pricing pages — the map is rebuilt, and two targets that would have been 404s are caught before launch rather than after.
Launch day: the checklist
- publish the redirects in the same release as the new site. Every hour between the switch and the import is an hour of 404s for crawlers and visitors. Import the file on staging first if the platform allows it.
- remove the staging blocks. Google’s guide puts it plainly: “Don’t forget to remove any noindex or robots.txt blocks that were only needed for the migration.” A leftover noindex on a new site is one of the most expensive one-line mistakes there is.
- check the host and protocol rules.
http://and the non-preferredwwwvariant should reach the final https url in one hop, not via an extra upgrade step before the path redirect. - test the top urls from outside. The twenty pages with the most clicks, by hand: each should answer 301 and land on the right page with a 200.
- submit the sitemaps. The new one, and the old one too. Google describes the effect: over time the pages indexed from the old sitemap drop to zero while the new ones rise.
- use Change of Address only for a domain move. Google: “You only need this tool when moving from one domain or subdomain to another.”
- confirm tracking fires on the new templates, so the first days of data are not lost.
After launch: the checklist
The map was a plan; the live site is the test. Google’s guide says a small to medium-sized site “can take a few weeks for most pages to move, and larger sites take longer”, and that visibility may fluctuate during the move. Plan the checks over that whole period.
| when | check | what good looks like |
|---|---|---|
| day 1–3 | request every old url against the live site | 301 → 200 in one hop, landing on the planned target |
| week 1 | Search Console page indexing report | “Page with redirect” growing for old urls, “Not found (404)” flat |
| weeks 1–4 | page indexing and crawl stats | no “Redirect error”, almost no 302s among redirect responses |
| weeks 2–8 | performance report against the baseline | new urls picking up the clicks the old ones had |
| 12 months + | the redirect rules | still in place — Google recommends at least a year |
The first row is where most problems surface: rules that were never imported, targets renamed after the map was built, chains from an earlier relaunch. How to run that test on a few thousand urls — a curl loop or a crawler in list mode — is in how to check redirects after launch; what to do when a url hops more than once is in redirect chains and loops. The report names in the table are the ones Search Console uses in its page indexing report.
EXAMPLE
two weeks after launch, “Not found (404)” rises by 80 urls. All of them start with /downloads/: pdf files that were never in the sitemap and only appeared in the server logs, which nobody added to the inventory. One wildcard rule to the new downloads page fixes them in an afternoon.
The mistakes that show up most
| mistake | symptom | fix |
|---|---|---|
| no redirect map | traffic drops over weeks as old urls fall out of the index | build the map before launch; add rules for every 404 with links or traffic |
| everything to the homepage | soft 404s, rankings not transferred | one-to-one targets, the nearest category where none exists |
| 302 instead of 301 | old urls stay canonical in search results | change the rule type; temporary redirects are a weak canonical signal |
| chains from the last relaunch | two or three hops per old url | flatten: every source straight to its final target |
| staging noindex left on | new pages not indexed at all | remove it; request indexing for the key pages |
| map built from a crawl only | 404s for orphan pages, pdfs and campaign urls | add sitemaps, Search Console, logs and the old redirect file to the inventory |
Google is explicit about the homepage pattern in its site move guide: redirecting many old urls to one irrelevant destination “can confuse users and might be treated as a soft 404 error.” And on the redirect types themselves, its redirects documentation says a permanent redirect is used as a signal that the target should be canonical, a temporary one is not.
In short
- Before launch: baseline, complete url inventory, frozen new structure, a reviewed redirect map, on-page signals carried over.
- The redirect map is built against staging once the new urls are final — usually two to four weeks before launch.
- Launch day: redirects in the same release, staging blocks removed, both sitemaps submitted, Change of Address only for a new domain.
- After launch: test every old url for 301 → 200 in one hop, then watch the page indexing report, crawl stats and performance for weeks.
- Keep the redirects for at least a year; in practice, keep them.
The map is the step a checklist cannot do for you. Silentfrog builds it from both sites; the first 50 pages of the old site are free and need no signup — open the tool.