Switching Websites Without Losing Your Google Rankings

You’re finally ready to replace the website, and then one thought stops you cold: you rank for “garage door repair” plus your town, or you’re sitting in the map pack, and you’re not willing to risk that for a nicer-looking site. That’s a smart thing to worry about. It’s also, in our experience, a fear pointed at the wrong villain.

We build websites for a living, so take that as it is: we’re not a neutral reviewer here, we want you to hire us to do this. But the honest answer doesn’t change based on who’s telling you. A new website almost never tanks your rankings on its own. What tanks rankings is a launch with no redirect map, because the search engine shows up looking for pages that used to exist and finds nothing there.

By the end of this you’ll know what actually carries your rankings across a switch, how to build the redirect map that protects them, what breaks silently on launch day if nobody checks, and how to read the first two weeks so you can tell a normal dip from a real problem. If you haven’t read up on how local rankings work in the first place, our local SEO guide covers that separately; this article assumes you already have something worth protecting.

The short answer

A new website will not cost you your rankings by itself. Losing rankings in a relaunch is almost always one specific failure: old URLs that got dropped instead of redirected. Google, or whoever’s linking to your old blog post, hits a dead page, gets a 404, and eventually stops sending anyone there. Do the redirect work and the rest of the migration risk is manageable.

The fix isn’t complicated, it’s just easy to skip when you’re focused on how the new site looks. Export every URL the old site has. Give every one exactly one destination on the new site. Test the redirects before launch, not after. Watch the first two weeks closely. That’s the whole job.

What actually carries your rankings

Here’s the part that calms most owners down once it’s laid out. A relaunch touches one thing out of four that matter for local rankings.

Your domain doesn’t move. If garagedoorusa.com is what you rank on, it’s still what you rank on after the redesign, as long as you keep the same domain.

Your backlinks don’t move. Every link pointing at your old pages from directories, news mentions, or other sites still points there. Redirect the destination correctly and that link equity follows. Don’t, and every one of those links now points at a dead page.

Your Google Business Profile doesn’t move. Your reviews, your map pack position, your photos, your hours: none of that lives on your website. It’s a separate Google product tied to your business listing, not your code.

Your content is the one thing that does move, because it’s the thing getting rebuilt. This is where the actual risk lives: thinner content, missing pages, or a new writer who leaves out the service terms your old pages ranked for.

Three of the four things that carry your rankings never touch the new build at all. The one that does is entirely in your control.

The comparison: what each platform gives you for the move

Every platform handles exports and redirects differently, and this is where a migration quietly goes sideways. Here’s what’s actually available on each, checked 2026-08-28.

Platform	What you get for the move	Where it gets hard
WordPress	Tools > Export produces a WXR file with posts, pages, and content. A free plugin like Redirection manages 301s and can export them to CSV or .htaccess.	The WXR file has no redirect data in it. You’re building the redirect map separately, by hand or with a second export, and it’s easy to assume the content export covers it when it doesn’t.
Wix	You can export store products, contacts, orders, and blog posts as CSV or XML from the dashboard.	The site itself, meaning the design, layout, and page structure, cannot be exported. There is no path to take a Wix site’s code anywhere else. You’re rebuilding from a content list, not migrating a site.
Squarespace	URL Mappings (in Settings, location varies by site version) supports one-to-one and wildcard 301 redirects, entered as plain text rules.	The mapping field caps out around 2,500 redirect lines, and a redirect only fires once the old page is actually deleted or disabled, which is easy to forget mid-migration.
Webflow	A paid-plan code export gives you static HTML, CSS, and JavaScript. Redirects can be managed separately and exported as CSV.	The code export does not include CMS collections or the 301 redirects you set up in Webflow’s own settings. Both have to be pulled out through separate tools, or they get left behind entirely.
Static hosting (Vercel, Netlify, Cloudflare)	Redirects live in a config file in your repo (vercel.json, a _redirects file, or similar), version-controlled right alongside the code.	There’s no dashboard warning you when a rule is missing. If whoever wrote the config left out a URL, nothing tells you until traffic drops.

Notice the pattern. Every platform on this list can handle the redirect side of a move. None of them do it automatically. Somebody has to build the list.

The inventory: step one

Before anyone touches the new site, get a complete list of every URL the current one has. Not the pages you remember. Every page.

The reliable way to do this without special tools: open Google Search Console for the domain, if you have access to it, and pull the list of indexed pages under Pages. Cross-check it against your XML sitemap, usually at yourdomain.com/sitemap.xml. Then walk the site’s own navigation and footer by hand, because sitemaps miss pages that got orphaned years ago, an old blog post nobody links to, or a landing page from a Facebook ad campaign that ran once in 2023.

That last category is the one that bites people. A page with almost no visible traffic today can still be the destination of old backlinks, or the exact page ranking for a long-tail term you didn’t know you had. You won’t find it by memory. You find it by exporting.

The map: step two

Every old URL gets exactly one new destination. That’s the whole rule, and it’s also the rule people bend when they’re in a hurry.

Build it as a spreadsheet with two columns: old URL, new URL. Go one row at a time. Where the old page has a clear match, an old /services/spring-repair to a new /garage-door-spring-repair, that’s easy. Where it doesn’t, pick the closest relevant page rather than skipping the row.

The mistake to avoid is a blanket redirect: sending every old URL to the new homepage because it’s faster than mapping each one. It technically stops 404 errors, but search engines read a mass redirect to the homepage as a signal that the old page’s specific content is gone, not moved, and the ranking value doesn’t transfer the way a real one-to-one redirect does. You’ll keep the domain’s overall standing. You’ll lose the pages that ranked for their own specific terms.

What to carry over on purpose

A redirect map protects old URLs. It doesn’t protect what those pages said, and that’s a separate decision.

Before the new site goes live, pull the page titles and headings from any old page that currently ranks, and use them, or something close to them, on the new version. If “24-Hour Garage Door Repair in [Your City]” is the heading pulling traffic, don’t let a new copywriter quietly rename it “Emergency Services” because it sounds cleaner. Keep the real body content too, not a thinned-out summary of it. A beautiful new page with a third of the old one’s words often means the specific phrases that used to match a search are simply gone.

Carry structured data forward as well, meaning the LocalBusiness schema markup that tells Google your name, address, phone, and hours in a machine-readable format. And if your image files are named garage-door-spring-repair-minneapolis.jpg rather than IMG_4021.jpg, keep those filenames. It’s a small thing search engines still read.

What breaks silently on launch day

Nobody notices these until a customer mentions it, which is exactly the problem: by then it’s been broken for a while.

Contact forms. The new form has to point at wherever leads actually land, whether that’s an inbox, a CRM, or a notification service. Test it yourself before launch, with a real submission, not a glance at the form on the page.

Tracking. If you had Google Analytics or a conversion pixel on the old site, the same tracking needs to be installed and firing on the new one before launch, not added a week later once someone notices the numbers went quiet. If you’re also connecting offline conversion data at the same time, that’s a setup our sister brand, Garage Door Lead Engine, has a full walkthrough for: see their guide on GA4 and GTM offline conversion import setup.

The phone number in the header. Sounds too obvious to mention. It’s also the single most common thing we’ve seen go stale on a new build, especially if the shop uses a tracking number that’s different from the one printed on the trucks. If that number does dynamic call tracking, Lead Engine’s guide on call tracking and dynamic number insertion setup covers getting it right, since a broken tracking number on launch day means every attributed call from the old site goes quiet at once.

Third-party embeds. A review widget, a booking calendar, a chat box, a financing application. Anything embedded from an outside service needs its own line in your launch checklist, because it’s easy for a builder to treat the visible design as the whole job and skip the invisible plumbing.

Launch, and the two-week watch

Launch day itself: confirm the redirect map is live by spot-checking twenty or thirty of your highest-traffic old URLs by hand. Type them in, watch where they land. Confirm the site is submitted in Google Search Console with an updated sitemap. Confirm your Google Business Profile still points at the correct domain, since that’s a separate setting from the website itself.

Day one to three: expect nothing dramatic. Search engines don’t instantly re-crawl and re-rank a whole site, and a day-one ranking check tells you almost nothing.

Day three to seven: a small, temporary dip on some terms is typical here, as search engines work through re-crawling redirected pages. That’s normal settling, not a sign of trouble.

Day fourteen: redirected pages should be showing rankings close to where they were, assuming the map was complete and the content carried over intact. If one is still missing or dropped hard, check that exact URL’s redirect first. Nine times out of ten, the pattern is one row missing from the spreadsheet, not something wrong with the new site as a whole.

If your Google Business Profile also needs attention as part of this move, that setup lives with our sister brand too. Their guide on Google Business Profile setup for a service-area business covers it in full, since GBP configuration is a lead-generation system question, not a website one.

The challenging one: keeping your existing URLs

The cautious instinct, once you understand how much rides on redirects, is to just keep every old URL exactly as it is. Don’t change anything, don’t risk anything. It feels like the safe move. It’s usually the wrong one.

A lot of older contractor sites have URL structures that were never good to begin with: /page-id-4471, or /services/services/spring, or a URL with the old company name baked in from before a rebrand. Keeping a bad URL doesn’t protect you, it just keeps a small ongoing tax on how clearly that page tells Google and the reader what it’s about. A properly mapped 301 redirect from a bad old URL to a clean, specific new one carries the ranking value across just fine. That’s the entire point of a redirect.

The move that’s genuinely risky isn’t changing URLs. It’s changing URLs without a complete map. An owner sees rankings dip after a launch where URLs changed, and concludes “changing the URLs was the problem,” when the real cause was that six of the forty old URLs never got a destination and just started 404ing. Fix the map, and cleaning up the URLs becomes a net improvement instead of a risk.

When not to migrate

Not every site that looks dated needs to be replaced. If your current site ranks well, loads reasonably fast, and the complaints are cosmetic, meaning it looks like it’s from 2014 but it works, a full rebuild carries migration risk for a cosmetic gain. A targeted update, new photos, updated copy, a design refresh within the existing structure, gets you most of the benefit without touching a single URL.

The real signal that you’ve outgrown the current site, versus just being tired of looking at it, is usually functional: not mobile-friendly and you can’t fix that on the current platform, built on something so old no one can safely edit it, or actively costing you leads because the phone number is buried or the form doesn’t work. That’s a different conversation than “it looks old.” Our garage door website ROI breakdown walks through whether a rebuild pays for itself in your specific case, separate from the migration question covered here.

What usually goes wrong

The single most common failure is the one already mentioned twice in this article, because it really is the one that matters most: a partial or missing redirect map. Someone maps the ten pages they remember and misses the twenty they forgot existed.

Second: the blanket redirect to the homepage, chosen because it’s faster than doing the real mapping work. It stops the 404 errors and quietly throws away the ranking value of every specific page it swallows.

Third: content that got rewritten thinner on the new site, losing the specific phrases and terms the old pages ranked for, in the name of a cleaner design.

Fourth, and this one’s about timing rather than technique: launching on a Friday afternoon with no one watching over the weekend. If something’s wrong with the map, you want to catch it Monday morning, not find out from a customer nine days later that your top service page returns a 404.

How to tell you got it right

Two weeks after launch, check three things. Pull up Search Console’s Pages report and confirm the old URLs indexed before launch are now showing as redirected, not 404. Spot-check your ten highest-traffic old pages by hand, typing each URL and confirming it lands where you intended. And look at whether your map pack position and your two or three most important terms are within a normal range of where they were before launch.

If all three check out, the migration did its job. If one page is still off, it’s almost always fixable: find that URL in your map, confirm the redirect is live, and give it another week to re-index.

A one-page pre-launch checklist

Hand this to whoever’s doing the technical work, including us if that’s who you hire.

• Full URL inventory pulled from Search Console, the sitemap, and a manual walk of the old site’s navigation.
• One-to-one redirect map built for every URL on that list. No blanket redirects to the homepage.
• Redirect map tested on a staging version of the new site before it goes live, not after.
• Page titles, headings, and body content from ranking pages carried forward, not thinned out.
• LocalBusiness structured data and image filenames carried over where they’re already in place.
• Contact form tested with a real submission and confirmed it reaches the right inbox or system.
• Analytics and conversion tracking installed and firing on the new site before launch.
• Header phone number confirmed correct, including any call-tracking number.
• Every third-party embed, review widget, calendar, chat box, checked and working.
• Updated sitemap submitted in Search Console on launch day.
• Google Business Profile confirmed pointing at the right domain.
• Twenty to thirty of the highest-traffic old URLs spot-checked by hand on launch day.
• A calendar reminder set for day three and day fourteen to check rankings again.

Run through that list before anyone flips the switch, and the redesign you were worried about becomes what it should be: a better website, on the same domain, with the same links and the same map pack listing, saying the same things Google already trusted it to say.