Which moves need a plan
- •A redesign that changes URLs, even a few. New page names, a flatter menu or a merged services section all change addresses.
- •A domain change. Every URL on the site changes at once.
- •Two sites becoming one. The smaller site’s pages need a home on the bigger one.
- •A platform change, such as WordPress to a headless Next.js front end, or a hosted store builder to WooCommerce.
- •A hosting move. The URLs stay the same, but DNS, caching and email are all in play. When the move is part of a security fix, see WordPress hosting migration.
01
Photograph the old site first
Everything after launch is a comparison with this, so it comes before any design work.
- •A URL inventory from several sources, not only the sitemap: the XML sitemap, Search Console’s page indexing report, twelve months of landing pages from analytics, every URL with backlinks, and a full crawl.
- •Ask the client which links they send people. Forms, price lists and onboarding pages often live outside search data.
- •A snapshot of each URL: status code, title, meta description, canonical, H1, robots directives, word count and structured data.
- •A 16-month export from Search Console. After launch, it is the only record of what each old URL was worth.
From our logs
On a WordPress to Next.js move we are finishing now, the new build left out an application form the client sends directly to its customers. The page is not indexed and nearly all of its visits come from that link, so search data made it look unimportant. The client had already flagged it, and it came up again in a review call before launch. Search data tells you which pages Google values. Only the business can tell you which pages it depends on.
Our SEO audit checklist covers the baseline in more detail, and an SEO audit is the quickest way to get one done before a move.
02
Map every old URL to one new URL
The map is a spreadsheet with one row per old URL: content type, old URL, new URL, and what happens to it. Our rules:
- •One hop. Old URL to final URL in a single redirect, whichever protocol or trailing slash the request arrived with.
- •Permanent. 301 or 308. Google treats both as permanent. Pick one and use it consistently.
- •The closest match in meaning. A blog post goes to its new home or to the blog, not to a sales page. Google says redirecting many old URLs to one irrelevant page, such as the homepage, may be treated as a soft 404.
- •Leftovers are decided on purpose: tag archives, author pages, feeds, paginated pages, and PDFs in the uploads folder that other sites link to.
- •The redirects stay. Google recommends keeping them for at least a year. On most sites they cost nothing to keep for good.
From our logs
A Florida contractor asked us to fold a second domain into its main site. The old domain had 26 URLs in its sitemaps: 9 pages, 11 portfolio items, 4 blog posts and 2 legacy model pages. The existing rules used a few patterns plus a catch-all that sent everything else to one service page, and plain http requests took two hops to land. Our plan sends both protocols straight to the final URL, the blog posts to the blog and the legacy models to the models page, and checks all 26 URLs, not only the eight on the acceptance list. As we put it to the client: “The 8-URL list proves the redirects fire, not where everything else lands.”
From our logs
Sometimes the map has to be built after launch. For a tile manufacturer whose URL structure changed in a move, we started from Search Console’s most-clicked pages over six months and matched each one to its new product or category. Eight leftover URLs had no obvious match, so we looked them up in the Wayback Machine. Five got a redirect. The other three could not be matched.
03
Launch in steps you can undo
- •Separate the redesign from the domain change when you can. On one project we launched the redesign first and moved the domain twelve days later. Our reasoning to the client: “Launching both simultaneously can create complex troubleshooting issues if something goes wrong.”
- •Staging blocks come off at launch, and only at launch. Check the WordPress “discourage search engines” setting, noindex tags from the SEO plugin, and host headers. On Vercel, preview deployments send an
X-Robots-Tag: noindexheader by default. The live domain must not. - •For a domain change on WordPress: set up the new domain and its SSL certificate first. Keep the old domain resolving. Run the database search-and-replace with a tool that handles serialized data, never raw SQL. Check wp-config.php for hard-coded site URLs. Redirect every old URL to the same path on the new domain, query string included. Retest existing redirect rules, because targets that still point at the old domain create chains. Update the analytics data stream to the new URL.
- •Then tell Google. Submit a Change of Address in Search Console. It checks the old site’s redirects before it accepts the move, so test http and https on deep URLs first.
04
The DNS nobody mentions
A website move is often a DNS move too, and the website is only one of the records.
- •Export the full DNS zone before touching nameservers, and list what every record is for: mail (MX, SPF, DKIM, DMARC), app and staging subdomains, and verification records for third-party tools.
- •Know where DNS lives. If the old domain’s DNS is hosted with the web host, moving the site can move everything else with it.
- •Keep the old host running for at least two weeks after the switch, while DNS caches expire.
- •Put a small marker on the old server’s copy of the site, such as a line in the footer, so anyone can tell at a glance which server they are looking at.
- •Ask about the office network. Company networks can carry their own internal DNS records.
From our logs
After a UK recruitment firm moved hosts, its office staff kept seeing the old site for about two weeks, while everyone outside the office saw the new one. The office’s internal DNS had its own record pointing at the old server’s IP address. We sent the new address to the client’s IT firm.
05
After launch: check daily, then weekly
- •Crawl the old URL list against the live site. Every old URL should return a 200, or a single permanent redirect (301 or 308, whichever you chose) to its mapped page. A 302, a 307, a chain, a loop or a 404 fails.
- •A test that passed on staging does not count until it passes on production. Hosts, caches and DNS all behave differently on the live domain.
- •Check the 404 log and Search Console’s page indexing report daily for the first weeks, then weekly.
- •Submit the sitemap, at the same URL as before where possible, and run a site: search to spot old URLs that are still indexed.
- •Watch traffic to both the old and the new URLs. Old URLs should fade as the new ones pick up.
- •Carry structured data and performance across. Compare the new site’s markup and Core Web Vitals with the baseline, template by template. See schema markup and Core Web Vitals.
When the platform changes too
Moving from WordPress to a headless front end adds problems you cannot see on screen: trailing slashes (WordPress uses them, Next.js drops them by default), 308 redirects instead of 301, preview deployments that carry a noindex header, and content that only appears after JavaScript runs. We wrote up the test plan for our current migration in how we test websites with AI.
From our logs
On the staging build of a WordPress to Next.js move we are finishing now, a first parity check across the 94 unique URLs in the old inventory found 7 returning 404 and 2 redirecting to the homepage. Some of the seven were merged into other pages on purpose and still need their redirects. The old site’s category sitemap listed 26 URLs, and staging had 5, so about 21 more redirects went onto the list.
Working with your SEO consultant
If you already have one, we fit around them. On one domain change, the client’s SEO consultant owned Search Console, the Change of Address and redirect testing, and we owned WordPress, the database and analytics. It is how we work with two clients who have their own SEO consultants.
What we won’t promise
Nobody can promise that rankings will not move during a migration. Google has to recrawl the site, and that takes time. What we can promise is the work that prevents avoidable losses: the inventory, the map, and the tests before and after launch.
We don’t publish before-and-after traffic numbers for client migrations. Some moves are still in progress, and on others the reporting belongs to the client’s SEO consultant.
If you are rebuilding rather than moving, start with how we approach web design. After launch, our maintenance retainer keeps the 404 log and Search Console under watch.
Frequently asked questions
When should redirect planning start?+
Before the new design is approved. The inventory shapes decisions such as which pages to merge and what to call them, and those arguments are cheaper to have before anything is built.
Should redirects be 301 or 308?+
Both mean the page has moved permanently, and Google treats them the same way. Next.js uses 308 by default. What matters is using one consistently.
Can we redirect old pages to the homepage?+
No. Google says redirecting many old URLs to one irrelevant page, such as the homepage, may be treated as a soft 404, so those URLs lose what they had. Send each one to its closest match. If nothing matches, let it return a 404 or 410.
How long should redirects stay in place?+
Google recommends at least a year. On most WordPress sites they cost nothing to keep indefinitely.
Do we need the Change of Address tool in Search Console?+
Only when the domain or subdomain changes. It checks the old site’s redirects before it accepts the move, so make sure they work on every URL, on both http and https.
What happens to our email when we move?+
Nothing, if the DNS records move with care. Export the full zone, list what every record does, and send test emails the day you switch.
Sources
- Google Search Central, Site moves with URL changes
- Google Search Central, Redirects and Google Search
- Vercel, Are Vercel preview deployments indexed by search engines?
- Next.js, redirects documentation