Migration runbook · Intermediate · an afternoon plus monitoring
How to move a website to a new domain — A One-Hop Redirect Map, and Nothing Still Pointing Home
You need every old URL landing on its real equivalent in a single hop, with nothing in the codebase, the sitemap or the mail records still naming the old domain.
The short answer
Build the redirect map before you build anything else: every URL that currently returns 200, paired with the URL that should serve it afterwards, one hop each. That map is the deliverable; standing the site up on the new name is the easy part.
Then hunt the references. Internal links, canonical tags, the sitemap, hardcoded asset URLs, wp-config, SPF and DKIM, OAuth callbacks and anything printed. A rename is not finished when the redirects work, it is finished when nothing in your own stack still says the old name.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Skill floor
5
Stages start to end
Free
Support, every tier
Proven
Run on the live stack
You need both domains, hosting for the new one, and a list of your current URLs. An afternoon of careful work followed by a few weeks of watching logs.
Reversible in principle, and unpleasant in practice, because 301s are cached hard by browsers. Get the map right before you publish it rather than iterating in public.
The map is the deliverable
Start with an inventory of every URL that currently returns 200: from the sitemap, from the server access log, from a crawl, and from your analytics for anything with real traffic. Deduplicate, then pair each one with its destination. Where a page has no equivalent, decide deliberately between the nearest relevant page and a 410.
Do not map everything to the homepage. It is quick, it satisfies a naive test, and it throws away the specific relevance of every URL you had. A one-to-one map is more work for exactly one afternoon and it is the difference between a rename and a reset.
One hop per URL, and how chains form
Chains appear without anyone writing them. Old URL redirects to old canonical, which redirects to http-to-https, which redirects to the new domain: three hops, three DNS lookups in the worst case, three connections, three round trips before the first byte of the page. Measure the reality with curl -sIL -o /dev/null -w '%{num_redirects} %{time_starttransfer}\n'.
The fix is to target the final URL directly from the first rule. Write the rewrite so old.example/pricing goes straight to https://new.example/pricing, not to the old canonical form first. Then test the four entrance combinations of http, https, www and bare on both domains.
Everything in your own stack that still says the old name
In WordPress, wp search-replace 'old.example' 'new.example' --all-tables --dry-run first, then for real, handles the database including serialised values without corrupting them, which a SQL find-and-replace will not. Update siteurl and home, then flush the object cache and any page cache.
Outside the database: hardcoded asset URLs in the theme, canonical tags, hreflang if you use it, the sitemap, robots.txt, the SPF record and DKIM selectors on the new domain, OAuth and webhook callback URLs, analytics property settings, and every third-party integration that was configured with the old hostname.
Watching it land, in the logs rather than the dashboard
File the change of address in Search Console, resubmit the sitemap on the new property, and then stop looking at the dashboard for a fortnight because it lags. The immediate signal lives in your access log: grep for 404 responses, and every unique path that appears is a URL your map missed.
Keep watching for at least a full crawl cycle, and hold the old domain registration indefinitely. The redirects are only worth anything while that name still resolves, and letting it lapse in three years silently deletes the entire migration.
Fast platforms make for short guides
Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.
Already hosted somewhere slower? Our engineers migrate the whole site free, usually within 24 hours, and it keeps serving visitors throughout.
- The redirect map treated as the deliverable
- Hops counted on the wire, not in a browser
- wp search-replace done safely, dry run first
- Engineers on support at any hour
Why HostingFast
Standard on every plan
The map comes first
A one-to-one URL inventory is the actual work, and the page puts it before standing the new site up rather than after.
Chains measured
You get the curl invocation that prints the hop count, so the target is a number you can see rather than a hope.
The reference hunt listed
Database, theme, sitemap, SPF, DKIM, callbacks — the page enumerates what still names the old domain instead of saying check everything.
5 steps, no padding
Five stages, each with a check attached, and the monitoring period described honestly as weeks rather than minutes.
search-replace done safely
The WP-CLI invocation includes the dry run and the serialised-data caveat, which is what stops a rename corrupting options rows.
Engineers on call
Support is staffed at any hour, and free migration means the move itself does not have to be your Saturday.
Quick Start
From order to online
- 1
Inventory every URL that returns 200
Pull from the sitemap, the access log, a crawl and your analytics, then deduplicate. Sort by traffic so you know which hundred URLs actually matter, and pair every one with its destination or a deliberate 410.
- 2
Stand the site up on the new name and rewrite its references
Deploy to the new domain, then run wp search-replace 'old.example' 'new.example' --all-tables --dry-run, read the report, and run it for real. Update siteurl and home, then clear the object cache and the page cache.
- 3
Publish the map as one-hop 301s
Write the rules so each old URL targets its final destination directly, never an intermediate canonical form. Then verify with curl -sIL against a sample from each section of the site and confirm every hop count reads 1.
- 4
File the change and resubmit the sitemap
Use the change of address tool in Search Console, add the new property, and submit the new sitemap there. Leave the old property in place so you can watch the crawl move rather than losing sight of it.
- 5
Hold the old domain and watch the 404 log
Grep the access log for 404 responses daily for a fortnight and add every unique path to the map. Keep the old registration on auto-renew permanently, because the redirects stop existing the day that name stops resolving.
Built In
Loaded onto every plan
- Free migration: our engineers move the existing site
- SSH with Git and Composer on the developer plans
- Daily backups with self-service restores from the panel
- Staging environments for testing before you ship
- In-place account upgrades, with no migration to change plan
- LiteSpeed caching in the server, not bolted on by plugin
- Per-site PHP version switching in the control panel
- Support staffed by humans, every hour of the day
- A renewal price identical to the one you signed up at
- NVMe storage on every tier, not only the expensive ones
Frequently Asked
What people ask us most often
How long do the 301s need to stay in place?
Indefinitely, in practice. Crawlers stop following them fairly quickly once the new URLs are established, but links, bookmarks, PDFs and printed material do not expire, and neither do the redirects' value in carrying those visits. The cost of keeping them is one domain registration and a rules file, which is nothing against the cost of turning them off and finding out what still used them.
Does a redirect chain really cost anything measurable?
Yes, and you can see it. Each extra hop adds a request round trip, and where the hop crosses to a different hostname it can add a DNS lookup and a TLS handshake as well. On a mobile connection that is easily hundreds of milliseconds per hop before any HTML arrives. Run curl -sIL -o /dev/null -w '%{num_redirects} %{time_total}\n' against a one-hop and a three-hop path on the same site and compare.
Will wp search-replace break serialised data?
No, and that is precisely why you use it instead of SQL. It unserialises values, replaces inside them and reserialises with correct string lengths, which a raw UPDATE cannot do — a byte-count mismatch there silently destroys options and widget data. Always run --dry-run first and read the table-by-table report, and take a backup before the real run regardless.
Do I need new SPF and DKIM records for the new domain?
Yes. Both are per domain, so mail sent as the new name authenticates against the new name's records and nothing carries over. Publish SPF and a DKIM selector on the new domain before you switch any sending address across, and add DMARC once you have seen authenticated mail passing. Otherwise your first outbound message from the rebrand is also your first authentication failure.
Keep reading
How to Submit a Sitemap to Google
Get the new property crawled properly, with the sitemap reflecting what actually returns 200.
How to Clean Up the WordPress Database
Clear the autoloaded rows, transients and revisions that a long-lived install accumulates.
Best Domain and Hosting Together
Plans that bundle the first year of a domain with annual hosting, compared on what each includes.
VPS Hosting
A VPS with root access when the shared account is no longer the right shape for the job.
Domain Names
Search, register and transfer names — first year free with an annual hosting plan.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Land the rebrand on faster hardware.
NVMe behind a LiteSpeed cache, free migration by our engineers, free SSL, and a renewal price identical to the one you signed up at.
View Domain Names plans