Launching a New Website Without Killing Your SEO: The 12-Step Migration Checklist

The single biggest fear in a rebuild conversation is this one: "What if you launch the new site and we lose all our SEO?" Fair question. Most home-services owners who ask it already have a website that ranks for something. A few "service in city" pages bringing in calls. A Google Business Profile pointing to a homepage that converts okay. The cost they're worried about is invisible: the slow bleed of rankings, traffic, and phone calls that follows a botched cutover.

The fear is earned. Plenty of rebuild horror stories on Reddit and in agency-owner Slacks. The vendor wasn't thinking about URL preservation. Nobody made a 301 redirect map. New sitemap didn't match the old one. GBP pointed to a 404. Some sites recover. Some never do. This post is the 12-step checklist I run on every Front Door Digital rebuild so none of it happens to you.

Why do most website rebuilds tank SEO for 6 to 12 weeks?

Because the new vendor builds the new site as a greenfield project instead of treating the old site as the authoritative source of truth. They don't crawl the old URL tree. They don't preserve the routes. They don't write 301 redirects. They don't reconcile the sitemap. Google sees a different site with different URLs at the same domain and resets its trust signals while it figures out what happened.

The mechanics are not complicated. Google ranks URLs, not websites. When you publish a new site with different URLs, every URL Google had indexed becomes a 404. PageRank, link equity, dwell-time history, click-through-rate history, all the signals Google accumulated against the old URL get severed. A correctly executed 301 redirect tells Google "this content moved here, carry the equity over." Without that signal, Google starts each URL from zero.

The practical reason most rebuilds fail: most agencies and freelancers don't have a migration runbook. They build the new site, deploy it, push DNS, and assume Google will figure it out. Google does, eventually. Eventually takes six to twelve weeks. In a home-services business, that's six to twelve weeks of phone calls you don't get because the new site isn't ranking where the old one was.

What does Front Door Digital do differently when migrating?

I treat the old site as the spec. The new site has to honor every URL the old one had indexed, or it has to redirect to a 1:1 equivalent. No new URLs unless we're adding pages that didn't exist. The substrate underneath changes (WordPress shared hosting becomes Next.js 15 on Vercel edge, for example), the routes stay. That's the deal.

Two case studies on the FDD site are the clearest proof points. Texas Wildlife Specialists went from WordPress on shared hosting to Next.js 15 on Vercel edge. The site had roughly 1,700 city-by-service URLs spread across two disconnected sitemaps from the WordPress build. The rebuild preserved every legacy URL verbatim and unified the two sitemaps into one. Load time dropped from 3,778 ms to 487 ms, TTFB from 208 ms to 58 ms, LCP from 3,355 ms in Google's "Poor" band to 413 ms in "Good." No ranking dip on cutover, because Google saw the same URLs serving the same content at the same domain. Just faster.

Florida Wildlife Specialists is the cleaner example for the 301 work specifically. The old WordPress build had 2,054 indexed URLs and the new site preserved all 2,054 of them 1:1. On top of that, we added 308 redirects from common WordPress slug variants the old site never canonicalized: trailing-slash inconsistencies, the WordPress "page-id" variant URL existing alongside the pretty permalink, capitalization drift in older URLs. The old site let those variants live as semi-duplicate URLs in Google's index. The new site collapses every variant into the canonical permalink with a 308. Result: Lighthouse 100/100 on mobile, 100/100 on desktop across three consecutive cold runs, zero ranking loss, and a cleaner index than the site had before. The old site's LCP at 13,854 ms was more than 3x Google's 4-second "Poor" threshold. The new build lands LCP at 1,712 ms with 827 KB of payload instead of 2.79 MB.

I rebuilt my own TruLight SLC site first, before doing any of this for clients. Lovable.app SPA to Next.js 15 on Vercel edge, load time from 4,155 ms to 745 ms, TTFB from 585 ms to 37 ms. That rebuild taught me what a migration runbook actually needs to cover before I started executing on client work.

What are the 12 steps of an SEO-safe migration?

Here's the full checklist. None of these are optional. Skipping any one of them is how rankings disappear.

Step 1: Crawl every existing URL before you change anything

Run a full crawl of the live old site and export every URL it serves. I use Screaming Frog, but ahrefs, Sitebulb, or wget --mirror work fine. Output: a CSV of every URL reached, its status code, meta title, meta description, and H1. This is your source of truth. Everything that ranks lives in this CSV.

Also pull the live sitemap (sitemaps, plural, on most WordPress installs) and the Search Console "Pages" report. The crawl tells you what's live. The sitemap tells you what the old CMS thinks should be live. Search Console tells you what Google actually has indexed. The three rarely match. The job is to make them match on the new site.

Step 2: Build the redirect map spreadsheet

One row per old URL. Columns: old_url, new_url, status_code, notes. 301 for permanent moves (the vast majority), 302 only for temporary redirects (rare), 410 for pages you're deliberately retiring. If the new URL is identical to the old, write "no redirect needed, route preserved" in the notes column.

For the FWS rebuild, the redirect map had 2,054 rows. Of those, 1,746 didn't need redirects because the new site preserved the URL exactly. The remaining 308 got 301 (or 308, the modern HTTP equivalent) redirects from WordPress slug variants to the new canonical. That ratio is healthy. If more than 30% of URLs need redirects, you're probably not preserving enough of the old structure.

Step 3: Audit internal links on the old site

Internal links carry equity within a site, and they also tell the new build what the old site considered important. Export the internal-link graph from your crawler. The pages with the most inbound internal links are your priority pages. Those have to redirect cleanly and they have to load fast on the new site. If a service page on the old site has 47 internal links pointing to it from blog posts, navigation, and footer, the new site needs to hold that page at the same URL or 301 every one of those internal-link sources to point at the new canonical.

Step 4: Snapshot the schema markup on the old site

Most older WordPress sites have at least a LocalBusiness schema in the header and FAQPage schema on the FAQ. Some have BreadcrumbList, Service, or Review schema scattered around. Pull the JSON-LD from every important page and save it. The new site has to ship schema parity at minimum, ideally better. Same NAP, same FAQ structure, same Service blocks. Google trusts schema consistency across a domain migration. Losing schema on cutover is a quiet way to signal "this is a different site now" even if every URL stays the same.

Step 5: Baseline Core Web Vitals and Lighthouse on the old site

Cold runs, three of them, on both mobile and desktop. I use Lighthouse in headless Chrome via Playwright, but PageSpeed Insights works too. The numbers you care about: LCP, INP, CLS, TTFB, total page weight. Google's thresholds: LCP under 2.5 seconds is "Good," 2.5 to 4.0 seconds is "Needs Improvement," over 4.0 seconds is "Poor." INP under 200 ms is "Good." CLS under 0.1 is "Good."

Why baseline? One, you need apples-to-apples numbers to prove the new site is faster. Two, if the old site fails Core Web Vitals on any URL, that URL is probably already losing ranking position. The baseline tells you which pages had the worst problems so you can confirm the fix shipped.

Step 6: Build the new site with URL parity by default

This is the philosophical commitment. When you scaffold the new site, the route structure mirrors the old URL tree. If the old site had /services/bat-removal-austin, the new site has /services/bat-removal-austin. Same slug. Same path depth. Same trailing-slash convention. Even if your new framework has a "cleaner" pattern, you don't get to use it on URLs that already rank.

You can add new pages. You can add a richer service area structure underneath the existing routes. You can introduce a blog at a new path that didn't exist before. What you can't do is move an existing ranking page to a "better" URL just because you think it reads cleaner. The rule is: if it ranks, it stays.

Step 7: Implement 301 redirects for any URL that has to change

Most rebuilds have at least a handful of URLs that need to change. WordPress in particular accumulates weird slug variants over the years: ?page_id=123 URLs still live in Google's index alongside the pretty permalink, capitalization inconsistencies, trailing-slash issues. The new site collapses all of those into the canonical URL with a 301 (permanent) or 308 (also permanent, with stricter HTTP method preservation).

On Next.js + Vercel, redirects live in next.config.js as an array with source, destination, and permanent: true. On Apache, they go in .htaccess. On Nginx, the server block. Whatever the host, you need server-level 301s. JavaScript-based redirects do not preserve SEO equity the same way and Google can be slow to honor them.

Step 8: Set the new sitemap.xml live before the DNS cutover

Before the new site replaces the old at the live domain, the new sitemap.xml has to be ready. On Next.js, app/sitemap.ts generates every URL the new site serves with <loc> and <lastmod>. The TWS rebuild took two disconnected legacy WordPress sitemaps and unified them into one. A unified sitemap is easier for Google to crawl and trust. Test the sitemap on the staging URL before cutover. Validate the XML. Make sure every URL returns a 200 (or redirects to a 200). Broken URLs in a sitemap erode crawl budget.

Step 9: Cut DNS over to the new host

The flip itself. DNS changes propagate over a few hours typically, though TTL settings determine how fast. I drop TTL to 300 seconds (5 minutes) about 48 hours before cutover so propagation is fast. On cutover, change the A record (or CNAME) to point at the new host. The old site stays as a backup on a subdomain like old.yourdomain.com for a 30-day rollback window. Things go wrong: a service page slipped through the audit, a schema block got mangled. Having the old site live on a subdomain lets you diff in real time without scrambling to restore from backup.

Step 10: Submit the new sitemap to Google Search Console

Within an hour of cutover, log into Search Console and submit the new sitemap. Then request indexing on your top 10 to 20 priority pages via URL Inspection. Don't try to request indexing on hundreds (Google rate-limits this hard). Just hit the ones that matter most. Google picks up the rest from the sitemap. Use the Search Console Domain Change tool only if your migration involves an actual domain change (yourdomain.com to yourdomain.co). For same-domain rebuilds, skip it.

Step 11: Update Google Business Profile within 24 hours

If you have a Google Business Profile, the website URL on the GBP needs to point at the new site within 24 hours of cutover, ideally same day. The GBP is one of the strongest local-SEO signals you have, and a stale URL pointing at a dead page is a quiet way to bleed local pack rankings while Google sorts out which version of you to trust. Also update directory listings (Yelp, Angi, BBB, Nextdoor) within the first week. Citation consistency is a real local-ranking factor.

Step 12: Monitor indexation, rankings, and 404s for 90 days

The migration isn't done at cutover. It's done after 90 days of clean monitoring. Watch the Search Console "Pages" report weekly. Look for spikes in 404s (a missed redirect), crawl errors (a sitemap problem), and the indexation count (it should match the new sitemap within a few weeks). Track your top 20 keywords in a rank tracker and watch for dips that don't recover. Most well-executed migrations show a small dip (10-15%) in the first 7-14 days as Google re-evaluates, then return to baseline or better by day 21-30.

Set up a 404 monitoring tool. Vercel has this built in. On WordPress, the Redirection plugin works. Any 404 that gets traffic is a redirect you missed. Add it to the map, push the fix, watch the 404 disappear from the report.

How do you map redirects from an old WordPress site to a new structure?

The WordPress-to-modern migration is the most common rebuild path for home-services owners. The headline rule: if a URL is in Google's index, it gets a row in the redirect map. The implementation is mechanical once you know what to look for.

Start with the WordPress permalink structure. Most sites use one of three patterns: /post-name/ (the "pretty permalink"), /category/post-name/, or /?p=123 (the default ugly variant). The pretty permalink is what Google has indexed in 95% of cases, but the ugly variants are often still live in the index too. They need redirects.

WordPress also lets you nest pages, so you'll see URLs like /services/plumbing/water-heaters/. The new site may flatten that (Next.js is agnostic about path depth), but the old hierarchy must redirect cleanly. For trailing-slash and capitalization variants, write a single regex-based redirect rule in next.config.js or .htaccess rather than 200 individual 301 rows. One rule that catches every variant of /Services/Plumbing/, /services/Plumbing, /services/plumbing/ and routes them all to /services/plumbing. That's how the FWS rebuild handled the 308 redirect variants.

How long should the SEO dip last, and what does "normal" look like?

A well-executed migration shows a 10-15% traffic dip in the first 7-14 days as Google re-crawls and re-indexes. By day 21-30, traffic returns to baseline. By day 45-60, you're usually seeing a 10-30% lift because the new site is faster and ranks better on Core Web Vitals signals. By day 90, equilibrium.

If you're still seeing a dip at day 30, something broke. Most common culprits, in order: missing 301s for low-traffic but indexed URLs (check Search Console's 404 report), schema regression, internal-link breakage, or sitemap issues.

For TWS, the rebuild preserved every legacy URL plus unified the two old sitemaps into one. The expected dip didn't materialize because there was nothing for Google to re-evaluate. Same URLs, same content, faster site. For FWS, 2,054 URLs preserved plus 308 redirect variants cleaned up. Lighthouse landed at 100/100 mobile and 100/100 desktop on the live custom domain across three cold runs. The cleaner index from the variant redirects is a net SEO upgrade over the old site, not just parity. The dip is not inevitable. It happens when the migration is sloppy. A clean migration has no dip, or a barely-perceptible one that recovers in days.

What happens if the new site is on a different platform than the old one?

The platform-to-platform migration is where most rebuilds fail. WordPress to Wix, Wix to Squarespace, Squarespace to Next.js, GoDaddy to Webflow. The URL structures don't always map cleanly because each platform has its own conventions. WordPress likes /category/post-name/. Wix likes /post-name with no trailing slash. Squarespace likes /blog/post-name. Next.js is route-agnostic and can match anything you tell it to.

The trick: the new platform has to honor the old platform's URL structure on the routes that already rank. If WordPress had /services/plumbing/water-heaters/, the new Next.js site has a route at /services/plumbing/water-heaters that serves the equivalent content. The Next.js app router gives you total control. Wix and Squarespace give you less, which is one reason we recommend Next.js for businesses that depend on local SEO. You can shape the new URL tree to match whatever the old one had.

Cross-platform migrations also need extra schema attention. Wix, Squarespace, and WordPress + Yoast all inject their own. When you cut over to Next.js, none of that ships automatically. You write the schema yourself in JSON-LD, at least as complete as what the old platform was generating. The TWS and FWS rebuilds both shipped LocalBusiness, Service, BreadcrumbList, and FAQPage schema on every relevant page. For more on why most home-services owners migrate off WordPress, see the hidden costs of staying on WordPress.

The four artifacts every migration should produce

Before I close out a migration, four artifacts have to exist and be saved with the project:

1. The redirect map CSV. Every old URL, every new URL, every status code. Saved to the project repo. If a 404 shows up on day 47, this is the file you check first.
2. The before/after Lighthouse JSON. Three cold runs on the old site, three on the new. Proof the rebuild was faster.
3. The schema audit. JSON-LD pulled from every important old URL, compared to the new. Confirmation that schema parity (or improvement) shipped.
4. The Search Console index report screenshot. Before cutover and 90 days after. Proof that indexation held or grew.

These four artifacts make the work auditable. If a future SEO contractor takes over the site, they can see exactly what was done. No black box. Every migration decision is on paper.

Frequently asked questions about SEO-safe website migration

Do I have to use the same domain name, or can I switch domains during a rebuild?

You can switch domains, but it's harder. A same-domain rebuild only requires URL preservation and 301s within the existing domain. A domain change requires the same work plus the Google Search Console Domain Change tool, plus updating every external link (citations, backlinks, GBP, directories) to point at the new domain. Equity transfer typically takes 30-90 days for a domain change versus 7-30 days for a same-domain rebuild. If you can stay on the same domain, do.

What's the difference between a 301 redirect and a 302 redirect?

A 301 is permanent. It tells Google "this URL moved and you should treat the new URL as the canonical going forward." It transfers PageRank and link equity. A 302 is temporary. It tells Google "this URL is being served from a different location for now, but might move back." It does not transfer PageRank. For a website migration, 301 is almost always what you want. 308 is the modern HTTP equivalent of 301 with stricter method preservation, and Google honors both equally for SEO purposes.

How do I know which of my URLs are actually ranking?

Open Search Console, go to Performance, set the date range to the last 12 months, and export the full list of pages with impressions and clicks. Sort by clicks descending. The top 50-100 URLs are your priority list. Those have to be preserved or redirected with surgical precision. The long tail (under 10 clicks per year) can be redirected with broader rules, or in some cases retired via 410 if the page is truly stale.

Can I rebuild a website without anyone noticing the cutover?

Yes, if you do it right. The TWS and FWS rebuilds both had zero ranking dip because every legacy URL kept serving content at the same path from a faster substrate underneath. Visitors notice the site loads faster. Search engines see the same URL tree, same schema, same sitemap, just better Core Web Vitals. The "you can't tell anything changed" experience is the goal.

If you're staring at a rebuild quote and wondering whether the new vendor has any idea what they're doing on the SEO side, ask three things. Show me your migration runbook. Show me the redirect map from your last cutover. Show me the before/after Lighthouse. If they can't produce those three, keep shopping. Done badly, a rebuild makes your phone stop ringing for six weeks while you figure out what went wrong. Done well, the only thing your customers notice is that the page loaded before they finished tapping the screen.