# Website migration checklist: URLs, content and operations A website migration checklist has four parts. Give every old URL one decision (keep, 301 or 410), and test that each redirect reaches a live page in one hop. Copy DNS, email and SSL settings before the switch. Then keep a restorable backup, agree on rollback triggers and monitor for 14 days. ## Key takeaways - Build the URL inventory from sitemaps, Search Console, backlinks and logs. Our live sitemaps held 73 unique paths, and 5 more URLs came only from Search Console. - Every 301 must reach a 200 page in one hop and never default to the homepage. Our 72-row map passes that test locally. - Copy every DNS record before you switch, above all MX and TXT. Our lookup found the mail host and showed no SPF or DMARC record. - A backup only counts once you have opened it, and the old site is removed last so a rollback stays possible. - Watch 404 paths, index coverage, key page positions and forms daily for 14 days after launch. ## What does a website migration checklist need to cover? A website migration is any change that moves your site’s URLs, platform, host or domain. Moving from WordPress to a new build counts. So does a change of host, a new URL structure, or a switch from www to the bare domain. Every migration carries four kinds of risk, and a useful checklist covers all four: - **URLs:** every old address needs a decision, or visitors and search engines hit dead ends. - **Content:** pages, images, heading anchors and metadata have to arrive intact. - **Infrastructure:** DNS, SSL certificates and email records have to keep working through the switch. - **Operations:** a tested backup, a rollback path and a monitoring plan for the weeks after launch. This guide walks through each area, using the migration of w3experts.com from WordPress to a new build as the worked example. That cutover is planned, not finished. Everything below that says “tested” was run locally or against public DNS on November 11, 2026. If you would rather hand the job over, our [website migration service](/services/website-migration/) follows this same checklist. Deciding which pages to keep, merge or remove is a redesign question, and it comes first. Our [website redesign checklist](/blog/website-redesign-checklist/) covers those decisions. This checklist starts once you know what each page should become. ## How do you build a URL inventory you can trust? The inventory is the list of every URL the old site answers, each with one decision. Pull it from several sources, because each one misses something: | Source | What it finds | What it misses | | XML sitemaps | Published posts, pages, categories and author archives | Tags, paged archives, old URLs that still get links | | Search Console, Pages and Performance exports | URLs with impressions or clicks, including truncated and odd variants | Pages Google never showed | | Analytics landing pages | Pages people actually enter on | Pages with no recent visits | | Backlink exports | Old URLs other sites still link to | Internal-only pages | | Server or CDN logs | Everything requested, including bots and feeds | Nothing, but they are noisy | Where URLs come from, and why one source is never enough Then give each URL exactly one of three outcomes. Keep it at 200, send it with a 301 to one specific new page, or return 410 Gone for a deliberate removal. Reconcile until no URL is left without a decision. ### What did the W3Experts inventory look like? The old site had 54 posts, 12 pages, 6 categories and 2 author archives in its sitemaps. A 12-month Search Console export showed 185 clicks and about 147,000 impressions in total. Only one post, the 414 error guide, was a web-build topic with real search signal. The owner-approved decisions became a redirect map of 72 rows: 33 redirects and 39 removals. Six URLs stay at 200 on the new site. They are the homepage, About, Contact, the services hub, the blog index and the [414 guide](/blog/what-is-414-request-uri-too-large-understanding-the-error/) at its original address. On November 11, 2026, we fetched the live sitemaps again and checked every URL against the map: ``` sitemaps fetched: post 55, page 12, category 6, author 2 = 75 entries unique paths: 73 (/blog/ and /seo/ each appear in two sitemaps) kept at 200: 6 mapped 301: 28 mapped 410: 39 unmatched: 0 map rows not in any sitemap: 5 /blog/why-are-b2b-sales-based-on-personal-selling-wa 301 /ppc/ 301 /seo/onpage/ 301 /checklist/ 301 /author/roman/page/* 301 ``` Two things stand out. First, every sitemap URL had a decision, so nothing would fall through to a 404. Second, five rows cover URLs that no sitemap lists. They came from Search Console: a truncated link, two tag archives, a paged author archive and an old tag. A sitemap-only inventory would have missed all five. ## How should redirects be decided and tested? Google’s site-move guidance asks for server-side permanent redirects that point straight at the final page, with no chains. Sending many old pages to the homepage can be treated as a soft 404, so those redirects pass nothing. Keep redirects in place for at least a year, and longer where you can. The rules we applied to the W3Experts map: - A 301 goes to the closest relevant page that exists at launch, never to the homepage by default. - The target must answer 200 in one hop, and it must not be another row in the map. - Off-topic posts with no clicks and fewer than 1,000 impressions in 12 months get a 410, which signals a deliberate removal. - Any 410 URL with a referring domain is upgraded to a 301 before cutover. - Paths are lowercase with a trailing slash. Wildcards are allowed only for paged archives. - The www to bare-domain and HTTP to HTTPS rules live at the CDN as one redirect, so they never add a second hop. The map is tested by a script that runs every row against the local build. It checks that the map still matches the owner-approved report, that every row returns its status, and that internal targets answer 200 with no chain. The run logged in our redirect runbook on November 10, 2026, and repeated on November 11, 2026, printed: ``` PASS redirects: 72 of 72 owner-approved rows; internal destinations 200 with no chains; retained 414 article 200. External BizAttic status checks remain gated to P5-03. ``` The last line matters. Ten posts move to our sister brand [BizAttic](https://bizattic.com/), which handles ongoing SEO and content. Those external targets can only be checked once they are live. A 301 into a 404 throws away the page’s history, so the plan says to wait rather than switch those rows to 410. ## Tip Test redirects with a client that does not follow them. In curl, leave out `-L` and print the status and target: `curl -s -o /dev/null -w '%{http_code} %{redirect_url}' URL`. A browser hides chains from you. ## What has to happen to content and media? Redirects only protect URLs. The content behind the kept URLs needs its own checks: - **Heading anchors.** Search Console showed fragment URLs such as `#Causes_Of_414_Error_Code`. Browsers never send fragments to the server, so no redirect can fix them. The rewritten 414 guide keeps its old heading IDs instead. - **Images.** Old upload paths return 410, except images reused in kept posts. Those are uploaded again and referenced at their new addresses. - **Moved content goes live first.** The 10 posts moving to BizAttic carried 59% of the old site’s clicks. They must answer 200 on BizAttic before the W3Experts redirects ship. - **Feeds and stray paths.** Old feed URLs, comment feeds and `?p=` links each get a rule, so they do not flood the 404 log. - **Metadata.** Titles, descriptions, canonicals and structured data come across with each kept page. The new sitemap lists only the new URLs. ## How do you handle DNS, TTL and email without downtime? Write down every DNS record before you touch anything. A forgotten MX or TXT record is the usual cause of “the site is fine but email stopped”. We pulled the current w3experts.com records on November 11, 2026, with PowerShell: ``` foreach ($t in 'NS','A','AAAA','MX','TXT') { Resolve-DnsName -Name w3experts.com -Type $t -DnsOnly } Resolve-DnsName -Name _dmarc.w3experts.com -Type TXT -DnsOnly Name Type TTL NameHost / NameExchange Preference w3experts.com NS 21600 roxy.ns.cloudflare.com w3experts.com NS 21600 sam.ns.cloudflare.com w3experts.com A 300 172.67.130.2, 104.21.3.11 (Cloudflare edge) w3experts.com AAAA 300 2606:4700:3031::ac43:8202, 2606:4700:3033::6815:30b w3experts.com MX 300 mx1-hosting.jellyfish.systems 5 w3experts.com MX 300 mx2-hosting.jellyfish.systems 10 w3experts.com MX 300 mx3-hosting.jellyfish.systems 20 w3experts.com TXT 300 google-site-verification=... _dmarc.w3experts.com DNS name does not exist ``` What the lookup told us, and what it changes in the plan: - **The site is proxied.** The A and AAAA records answer with Cloudflare edge addresses. Visitors never see the origin, so changing the origin behind the proxy takes effect without waiting for DNS caches. - **Proxied TTL is fixed.** Cloudflare’s documentation says proxied records use Auto, which is 300 seconds, and it cannot be edited. Unproxied records can go as low as 60 seconds on non-Enterprise plans. - **Mail is hosted elsewhere.** Three MX records point at the mail host. They must be copied exactly and left untouched by the cutover. - **Email authentication has gaps.** The lookup returned no SPF record and no DMARC record. That is unrelated to the migration, but the record audit is the right moment to fix it. Not behind a proxy? Then lower the TTL on the records you will change to 300 seconds, at least a day before launch. Wait for the old TTL to expire, then switch. Raise the TTL again once the new site is stable. ## What about SSL certificates? Two certificates matter on a proxied site. The edge certificate is what visitors see. On November 11, 2026, it was issued by Google Trust Services and valid until December 20, 2026. The origin certificate sits on the new server and encrypts the hop from the CDN to it. - Install a valid origin certificate on the new host before the switch, for every hostname it will serve. - Set the CDN’s encryption mode to full with certificate validation (Cloudflare calls it “Full (strict)”). - Test HTTP on the bare domain, HTTP on www and HTTPS on www. Each must reach the HTTPS bare domain in one hop. Today’s site already behaves that way. `http://w3experts.com/` and `https://www.w3experts.com/` both answered 301 to `https://w3experts.com/` in our check. The new setup has to keep that single hop. ## What backups do you need before you start? Back up the old site in a form you can actually restore, and keep it outside the hosting account you are about to change. The W3Experts plan (check C-01) requires: - a database dump and the full uploads folder; - a WordPress XML export of all content; - saved HTML of the 13 posts being kept or moved. The pass condition is not “the file exists”. It is “the archive opens and the 13 HTML files render locally”. A backup you have not opened is a hope, not a backup. The new site has its own drill. On November 10, 2026, we created and verified a git bundle of the new build (“The bundle records a complete history”). The clone and rebuild steps of that drill were not run yet, so the restore time is still unmeasured. ## What happens on launch day? Pick a quiet window you can staff. The W3Experts cutover is set for a Tuesday to Thursday morning, US Eastern, after the owner approves the date. ## Steps - ### Freeze and back up Stop content edits on the old site. Take the final backup, then open it and render the saved posts locally. - ### Export the baseline Export Search Console Pages, Queries and Links for the last three months, so you can compare after launch. - ### Confirm external destinations Fetch every off-site redirect target, such as the 10 BizAttic posts. Each must answer 200 with a self-referencing canonical. - ### Switch the origin Remove the old site from the domain only after the backup is verified. Attach the new app, then apply the DNS and CDN rules. - ### Verify in production Check the homepage, the 414 guide, five sample redirects and every form. Run the full redirect check against the live domain. - ### Tell search engines Submit the new sitemap in Search Console and Bing Webmaster Tools. Old URLs need no removal requests, because the 301s and 410s handle them. ## When and how do you roll back? Decide the rollback triggers before launch, so nobody debates them at 9 a.m. on launch day. Ours are simple: - a form that does not deliver; - 5xx errors on any main page; - the production redirect check failing on more than a handful of rows; - the 414 guide, the one URL with real search history, not answering 200. Fix forward when the problem is small and understood, such as one wrong redirect row. Roll back when the cause is unknown or users are losing data. On a proxied site, rolling back means pointing the origin back at the old site. That only works if the old site still exists somewhere. That is why the plan keeps a restorable backup and removes the old site last. For the new build itself, a bad release is rolled back by reverting the change and deploying again. The same pattern, with release folders, appears in our [Laravel deployment checklist](/blog/laravel-deployment-checklist/), where we tested a rollback end to end. ## What should you monitor for 14 days after launch? Search engines need weeks to recrawl a moved site, and Google warns that rankings can fluctuate meanwhile. Watch these daily for the first 14 days: | Signal | Where | Pass when | | 404 paths | CDN analytics or server logs | Every path with more than 5 hits is reviewed; scanner probes are ignored | | 404 spike | Daily alert | 404s stay under 3 times the trailing 7-day median, or under 50 | | 301 and 410 counts | Logs against the redirect map | Old URLs answer as mapped | | Index coverage | Search Console | Old URLs drop as new ones are indexed | | Key page position | Search Console, Performance | The 414 guide holds roughly position 14 | | Forms | Uptime monitor and inbox | Every test submission arrives | | Referral traffic | BizAttic analytics | Visits arrive from the old W3Experts URLs | The W3Experts 14-day watch, from the cutover plan and the monitoring runbook An old URL worth keeping goes through the redirect runbook as a new row. A broken internal link becomes a fix. Speed is worth a check too. If you are moving to a new platform, our [Shopify speed diagnosis](/blog/shopify-speed-diagnosis/) shows how to separate the theme, apps and third-party scripts in lab tests. ## Where does the W3Experts migration stand today? Here is the honest status of each check on November 11, 2026: ## Comparison | Check | Status | Evidence | | URL inventory and reconciliation | Done locally | 73 unique sitemap paths, 0 without a decision | | Redirect map against the new build | Tested locally | 72 of 72 rows pass, no chains | | DNS and email record inventory | Done | Public lookup; MX copied; no SPF or DMARC found | | New-build backup | Partly tested | Bundle created and verified; restore not timed | | Old-site backup (C-01) | Planned | Runs on cutover day | | BizAttic destinations (C-04) | Waiting | Posts must be live first | | Cutover, production checks, 14-day watch | Planned | Needs the owner’s approval of the date | We will update this post with the production results after the cutover. ## Limits: what this guide does not cover - **The cutover itself has not happened.** Production redirect checks, the old-site backup, the 14-day watch and any rollback are described as plans. - **Domain changes.** This example keeps the same domain. A move to a new domain also needs Search Console’s Change of Address tool, which we did not use. - **Ecommerce data.** Orders, customer accounts and payment tokens need their own migration plan. - **Large sites.** With tens of thousands of URLs, the inventory needs log analysis and crawl tooling beyond a sitemap check. - **Email host moves.** We kept the mail host. Moving mailboxes is a separate project with its own cutover. - **Unproxied DNS.** Our TTL advice for unproxied records comes from Cloudflare’s documentation. We did not run a TTL change in this test. ## Planning a move? We run migrations with a reconciled URL map, tested redirects and a written rollback plan. Tell us what you are moving and when. [Plan your website migration](/services/website-migration/) [Explore the service](https://w3experts.com/services/website-migration/) - [Google Search Central: Site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) — accessed 2026-11-11T00:00:00+00:00 - [Google Search Central: How HTTP status codes affect Google Search](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) — accessed 2026-11-11T00:00:00+00:00 - [Cloudflare DNS docs: Time to Live (TTL)](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) — accessed 2026-11-11T00:00:00+00:00 - [Cloudflare SSL/TLS docs: Full (strict) encryption mode](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/) — accessed 2026-11-11T00:00:00+00:00 Canonical: https://w3experts.com/blog/website-migration-checklist/