Website migration SEO that keeps the rankings you already earned

01 / 08

What is an SEO site migration?

An SEO site migration is any change that alters the URLs, platform, domain, or structure a search engine already knows: a redesign, a move from WordPress to a new stack, an HTTP-to-HTTPS switch, or a new domain. The goal is to carry every ranking signal from the old addresses to the new ones so the change is invisible to your traffic, not to your customers.

To a search engine, only a few things count as a migration: the URL changed, the domain changed, the content moved, or the way the page is delivered changed. Any of those forces Google to re-map your site, and that re-mapping is where equity is preserved or lost.

Google splits the problem into two cases: site moves with URL changes and site moves without them (Google, 2026). A domain change where every path stays the same is very different from a redesign that renumbers every URL. Most real projects are a mix of both, which is why they go wrong.

What we protect is not the website. It is the accumulated trust behind it: the rankings, the backlinks pointing at specific pages, the entity data AI engines rely on. That trust is attached to URLs. Change them without telling search engines where everything went, and it is gone.

02 / 08

Why do websites lose traffic after a redesign or migration?

Almost always because of a handful of avoidable mistakes: missing or broken redirects, blanket redirects to the homepage, a staging "noindex" left switched on at launch, changed URLs with no redirect at all, and lost titles, schema, or internal links. The design gets the blame, but the traffic loss is nearly always a redirect or indexation error hiding under it.

The most common failure is the simplest: pages move and nothing tells Google where they went. Old URLs return a 404 and the new pages start from zero. Google confirms a page returning a 4xx error is removed from the index if it was previously indexed (Google, 2026). No redirect means no inheritance.

The second most common is the lazy fix: redirecting every old URL to the homepage. Google treats an irrelevant redirect like that as a soft 404, so the equity is discarded as if the page had 404ed. A redirect only preserves a signal when it points to a genuinely equivalent page.

Then there is the quiet killer: the staging site. Development builds are usually blocked from indexing with a noindex directive, and if that directive ships to production, Google drops the whole site from search, a catastrophic collapse that is really one line of code. Lost titles, stripped schema, and unrebuilt internal links do slower versions of the same damage.

Honesty matters here. A well-executed migration usually still sees a short dip while Google recrawls and re-evaluates, followed by recovery. Anyone promising zero impact is guessing. The work is not to make the dip impossible: it is to make it shallow, short, and visible while it happens.

04 / 08

What is a redirect map and why does it matter?

A redirect map is the master list pairing every old URL with the single new URL it should send visitors and crawlers to. It is the document that decides whether your rankings survive. It must be 1:1 where possible, free of chains and loops, and every target must actually exist. Get the map right and most of the migration risk is already gone.

The map is the migration; everything else is execution. Each row says: this old address now lives here, permanently. Do it well and search engines transfer trust to the new URL. Leave gaps and those pages fall out of the index; add errors and you send Google in circles.

Three flaws break a map, all invisible until traffic drops. Chains, old URL to interim URL to final URL, bleed signal at each hop and slow crawling, and Google follows only up to ten redirect hops before it stops (Google, 2026). Loops break pages entirely. Missing targets send equity to a 404. A map has to be validated for duplicates, conflicts, chains, and missing destinations before launch, not debugged afterward.

Here we can point at our own work rather than describe it in the abstract. Our 502-URL migration ran with a redirect map validated for duplicate rules, conflicting rules, redirect chains, and missing targets, all four checks returning zero before we shipped. On top of that, a link-integrity gate runs on every build, crawling the built output and failing the deploy if any internal link points at a 404. A broken link cannot reach production, because the build will not let it.

05 / 08

301, 302 or 410: which redirect should you use?

For a permanent move, use a 301. Google treats a 301 as a strong signal that the new URL should be canonical and inherit the old page's signals, while a 302 is a weak, temporary signal that tells Google to keep the old URL (Google, 2026). Use a 302 only for genuinely temporary detours. For a page you are deleting on purpose, serve a 410 Gone.

The distinction is not cosmetic. Google follows both, but only the 301 tells the indexing pipeline the destination should become canonical and receive the old page's ranking equity (Google, 2026). Use a 302 for a move you intend to keep and you signal the opposite of what you want: Google may keep the old URL indexed and never fully transfer the page.

The reflex to redirect everything is itself a mistake. Thin, spammy, or dead pages have no equity worth preserving, and forcing them onto a live page dilutes relevance. For those, the honest status code is 410 Gone. Google drops both 404 and 410 pages from the index, and a 410 tends to fall out a couple of days faster (Search Engine Journal, 2026). Neither is a penalty; both are accurate.

Our own migration used all three tools on purpose. Of 502 URLs, 374 kept their place, 113 earned a permanent 301 to their closest equivalent, and 15 low-value URLs, spam posts plus a bot trap, were removed and served a true 410. One detail worth stating: Cloudflare Pages' _redirects file supports 301 but not 410, so we serve the 410 responses from an edge function instead. The point is not the tooling: it is that "deleted" and "moved" are different decisions, and each URL got the status code that told the truth about it.

06 / 08

How long does it take Google to process a site move?

Google says a small to medium-sized site can take a few weeks for most pages to move over, and larger sites take longer, depending on the number of URLs and server speed (Google, 2026). Plan for weeks of transition, not days. Rankings often wobble during that window and settle as Google recrawls the new URLs and follows every redirect.

You do not control the timeline by wishing. Google has to recrawl the old URLs, follow the redirects, index the new URLs, and re-evaluate them, on its own schedule, not yours. For most local and mid-sized business sites that is a matter of weeks; for very large sites it runs longer (Google, 2026).

You can help it along. Google recommends submitting the new sitemap in Search Console so it learns the new URLs faster, and using the Change of Address tool for a domain move, though not for a plain HTTP-to-HTTPS switch, which needs no address change (Google, 2026). Where the domain stays the same but hosting changes, Google advises lowering your DNS TTL about a week ahead so it propagates quickly (Google, 2026).

Expect the crawl rate to dip right after launch. Google states that a temporary drop in Googlebot's crawl rate immediately after a hosting move is normal, followed by a steady increase over the next few days (Google, 2026). That is why we keep redirects live for a long time, at least a year as Google recommends (Google, 2026), and never judge a migration on its first week.

07 / 08

What should you check the moment a site goes live?

On launch day: confirm the staging noindex is gone and the site is indexable, spot-check that key old URLs 301 to the right new pages, verify the sitemap is live and submitted, and watch Search Console for crawl and coverage errors. The first days after launch are the cheap window to catch a mistake. Weeks later, the same error is far harder to trace.

The first check is always the noindex. We confirm the production site is allowing indexing and that no robots.txt block or meta noindex survived from staging. A single leftover directive is the difference between a smooth move and a site that disappears from search a week later.

Then the redirects get tested against the map, not assumed. We sample old URLs across every section, confirm each returns a 301 to its mapped target with no chain in between, and check that deleted URLs return their intended 410. Sitemaps go in through Search Console, and we watch the coverage and crawl-stats reports for errors that only surface once Google recrawls in volume.

Server logs are the ground truth nobody looks at. They show which URLs Googlebot is hitting, how often, and what status code it gets back: real crawl behavior rather than a guess. Every migration also ships with a rollback plan: if something is badly wrong, we revert quickly rather than debug live under pressure. The goal is to catch any mistake in days, while it is cheap, not in a traffic report a month on.

08 / 08

How do you migrate off WordPress to a static, edge-delivered site safely?

The same discipline applies, plus a platform decision. Moving from WordPress to a static, server-rendered site delivered at the edge can make a site faster and far more legible to AI crawlers, but only if every URL is mapped, every redirect validated, and the build itself refuses to ship broken links. The platform is an upgrade; the migration rules do not change.

WordPress is fine, and plenty of sites should stay on it. But a heavy theme-and-plugin stack often carries slow pages and JavaScript-dependent rendering. The major AI crawlers (GPTBot, ClaudeBot, PerplexityBot) fetch raw HTML and do not execute JavaScript, so content that only appears after scripts run is invisible to them. Server-rendered HTML is now a requirement, and static edge delivery satisfies it cleanly, which is part of the AI-search readiness a migration can unlock.

This is the migration we ran on ourselves, so we describe it as fact, not theory. We moved a 502-URL WordPress and Elementor site to a static Astro build on Cloudflare Pages. Every URL was classified first (374 kept, 113 permanently redirected, 15 removed with a 410) and the redirect map was validated for duplicates, conflicts, chains, and missing targets before launch, all four clean. We make no traffic or ranking claim about that move; we can state exactly what we did and how it was verified.

The safety net is the build itself. A link-integrity gate runs on every deploy, crawling the built output and failing the build if any internal link 404s, so a broken link cannot reach production. Because Cloudflare Pages' _redirects handles 301 but not 410, the intentional 410 responses come from an edge function. The result ships complete, server-rendered HTML with clean structured data, the format Google indexes reliably and AI engines can read.

If your business does not need to leave WordPress, we will say so and optimize what you have; that work is covered under our technical SEO services. A migration is worth doing when the platform is genuinely holding you back, not because a new stack is fashionable. Either way, the redirect map and the monitoring are non-negotiable.