Will Switching Websites Cost Your Insurance Agency Rankings?

The site you can't stand but won't leave

You know your website is slow. You've probably watched it load on your own phone standing in a parking lot and felt the six seconds pass. You know the page builder templates all look the same, because you've seen three competitors running the exact same layout with a different logo dropped in. You've priced out a real build, maybe even talked to us or someone like us, and the number made sense. And then you didn't do it.

Ask why, honestly, and the answer usually isn't the price. It's a specific, half-remembered fear: somebody told you, or you read somewhere, that switching your website tanks your Google rankings for months. Maybe a friend at another agency changed vendors and disappeared from search for a while. Maybe you've seen a horror story on a marketing forum about a business that lost most of its traffic after a redesign. So the ugly, slow site stays, because at least it ranks, and ranking feels like the one thing you can't risk.

That fear is reasonable. It's also, in most agencies' actual situation, aimed at the wrong risk. There are two very different things a website move can mean. One of them really is as dangerous as the horror stories suggest. The other one, the one that applies to almost every agency replacing a WordPress or GoHighLevel funnel with a faster build on the same web address, carries a fraction of the risk, and Google's own documentation says so in plain language. This guide separates the two, shows you the actual numbers behind both, and gives you the checklist that decides which side of that gap you land on.

What actually happens when a URL changes

Every page on your site has a web address, and Google has built up trust in that specific address over years: how often it's crawled, how it's ranked for specific queries, how many other sites link to it. When you replace your website, some or all of those addresses change. What happens next is not mysterious. Google documents it directly.

A permanent redirect, either a 301 or a 308 status code, tells Google and every visitor's browser that a page has moved for good. Google's crawling and indexing documentation states this outright: "301 and other permanent redirects don't cause a loss in PageRank"². The value your old page earned transfers to wherever you point it. That's the entire mechanism, and it's the reason a correctly executed migration is fundamentally different from an accident that quietly deletes a hundred pages.

The transition isn't instant. Google's own site-move guidance is specific about the timeline: "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones," and larger sites take longer¹. During that window, "you may experience ranking fluctuations while Google recrawls and reindexes your site," and traffic shifts gradually, old-URL traffic going down while new-URL traffic comes up¹. None of that is a penalty. It's Google re-learning where your content lives, at the pace its crawlers actually work.

Walk one page through it to make the mechanism concrete. Say your current site has a page at yourdomain.com/medicare-advantage-plans that ranks decently for a handful of local searches. Your new site organizes the same content at yourdomain.com/plans/medicare-advantage instead, a common kind of change when a rebuild also cleans up an old, messy folder structure. On launch day, a 301 redirect is set from the old address to the new one. A visitor clicking an old bookmark, and a Google crawler revisiting a URL it already knows, both land on the new page automatically. Over the following days and weeks, Google's crawler revisits that old address, sees the redirect, and starts associating the new address with the ranking history the old one had built. The page doesn't lose its place in line. It changes seats while keeping its ticket. Skip the redirect, and the crawler instead finds a 404, treats the old URL as gone, and the new page starts as a stranger with no history at all, competing from zero against every competitor's page that never moved.

Domain change vs. platform change: not the same risk

Here's the distinction that most of the fear about migrations skips entirely. A domain change means your actual web address changes, agencytoday.com becomes agencytomorrow.com. Every signal Google has tied to the old address, years of crawl history, backlinks, brand recognition in search results, has to be rebuilt at a location that has never existed before, even with a flawless redirect map in place. A platform change means you keep the exact same domain and simply replace what runs behind it. The address Google has trusted for years doesn't move. Only the software serving the pages does.

The most cited migration horror statistic comes from the first category, not the second. A study by Dan Taylor, published on Search Engine Journal, analyzed 892 real domain changes using Ahrefs data and crowdsourced submissions from SEO practitioners, collected through October 22, 2024. Its own stated methodology measured "the number of days it took Domain B, the new domain, to achieve the same estimated organic traffic volume as Domain A, the old domain"³. That is a domain-to-domain comparison, the hardest version of this problem there is, and the average across all 892 cases was 523 days³. Seventeen percent of the domains in the sample still hadn't recovered after 1,000 days³.

Almost no agency reading this guide is planning that move. You're not rebranding to a new domain. You're replacing a slow page builder with a faster build, on the domain your clients already know, the one on your business cards and your Google Business Profile. That's a platform change, and it's a meaningfully smaller problem, which is exactly why Google's guidance treats "changing your CMS" and "changing your domain" as different scenarios with different expected timelines in the first place.

It's worth spelling out why the domain specifically carries so much of this weight, because it isn't only about Google's crawl history. Every other business site that links to you, a chamber of commerce directory, a carrier's find-an-agent tool, a local news mention, points at your current domain. Your Google Business Profile's website field points at your current domain. Every citation service, every old guest post, every partner's resource page, all of it points at the address you've had the whole time. A domain change doesn't just ask Google to rebuild trust from zero. It asks every one of those outside references to still find you, which most of them never will unless someone manually goes back and updates each one. A platform change leaves every single one of those links pointing at exactly the right place, automatically, because the address never moved.

What a bad migration actually costs

Put the numbers next to each other and the shape of the risk gets clear. Within the same 892-domain study, the fastest recoveries took 19, 22, 23, and 33 days, essentially in line with Google's own few-weeks estimate for a well handled move³. The average across the whole sample was 523 days³. That gap, from 23 days to 523 days, inside one dataset, is not explained by luck. It's explained by whether the redirect map was complete, whether the sitemap was submitted, and whether the move happened all at once or dribbled out in a way nobody could monitor cleanly. This is the one figure in this guide with a single source rather than two independent ones; it's worth citing plainly for what it is, one large, transparent study, rather than treating it as an industry-wide constant.

Run those numbers against your own traffic and the difference stops being abstract. If your current homepage and top three service pages together bring in 200 organic visits a month, a well executed platform change that lands in Google's few-weeks window means you're back to roughly that same 200 by the time your next billing cycle closes. A careless domain change with an incomplete redirect map, landing anywhere near the 523-day average, means an agency could spend the better part of two years rebuilding a traffic number it already had, while paying for ads or leads to make up the gap in the meantime. Same starting traffic, same amount of work put into the old site, a completely different outcome depending on which category the move fell into and how carefully it was executed.

There's a second cost that has nothing to do with domains or platforms and everything to do with what a careless launch leaves behind. A migration is exactly the moment a stale noindex tag from a staging environment, or an overzealous security plugin's default header, tends to survive into production unnoticed. We've written separately about how a single nosnippet or noindex directive can silently disqualify an otherwise well-ranked page from appearing in AI Overviews⁶ even while it still ranks normally in classic search. A migration doesn't cause that problem by nature. It's simply the moment that problem gets introduced most often, because it's the moment the most files and settings change at once.

What else moves besides rankings

Rankings get all the attention in this conversation because they're the easiest thing to measure, but they aren't the only thing that has to survive a launch intact. Three quieter systems break just as often, and none of them show up in a rank tracker.

Your lead forms are the first. Every quote request and contact form on your current site routes somewhere, a CRM, an email inbox, a GoHighLevel pipeline. A new site needs each of those forms wired to the same destination before launch, tested with a real submission, not assumed to work because the form itself renders correctly. A form that looks fine and silently fails to deliver a single lead for two weeks after launch is a worse outcome than a slow crawl, and it's far more common, because nobody checks a working-looking form the way they check a page that returns a 404.

Your tracking and analytics are the second, and this one carries a compliance dimension specific to health-adjacent insurance work. If your current site runs client-side tracking, a Meta Pixel or a standard Google Analytics tag firing straight from the browser, simply copying that same setup onto a new platform copies the same tracking posture, HIPAA exposure included. A migration is the natural moment to move to server-side, consent-gated tracking instead of quietly carrying an old liability onto a newer, faster site.

Your phone number and call tracking are the third. If you run call tracking numbers tied to specific pages or campaigns, confirm each one still routes correctly on the new site before cutover, not after a client calls a dead number during the exact week you're trying to make a good first impression with a faster page.

The weeks you never touch a Medicare or ACA site

Even a textbook migration carries some expected fluctuation, Google says so directly¹. That fluctuation costs almost nothing during a slow month. It costs a great deal during the weeks your entire book of business is actively shopping. Medicare's Annual Enrollment Period runs October 15 through December 7, and coverage elected during that window takes effect January 1, per Medicare.gov's own guidance⁴. The ACA Marketplace's Open Enrollment Period runs November 1 through January 15 in states using the federal marketplace, according to HealthCare.gov's own dates and deadlines page⁵. Line those two windows up and an agency serving both Medicare and ACA clients is effectively unable to afford any search visibility hiccup from roughly the start of October through the middle of January.

That's not a reason to avoid switching platforms. It's a reason to pick the calendar deliberately. Move in February through August, while your slowest search weeks are also your lowest-stakes weeks, and even a normal few-weeks recrawl window is finished long before your highest-value prospects start asking who to call. Move in October, and any rough patch lands directly on top of the exact period covered in our guide to getting a site ready before AEP.

The safe migration checklist

None of the following requires a developer you don't already have, and you can run through it yourself with any vendor, including one that isn't us. This is the actual method, not a teaser for it.

1. Keep your domain unless you have a real reason to change it. Staying on your existing address is what keeps this a platform change instead of a domain change, and it's the single biggest lever in this whole list.
2. Export a complete list of every live URL on your current site before you touch anything, using Search Console's Page Indexing report, your existing sitemap, and a basic crawl of the site itself. You can't redirect a page you forgot existed.
3. Build the new site on a private preview address first. Nothing about a rebuild requires your live domain to point at unfinished work. Review the finished site in full before any DNS record changes.
4. Map every old URL to its exact new equivalent, one to one. Not a blanket rule that sends everything to the homepage. A visitor or a crawler landing on your old blog post should land on that same post's new address, not on a general landing page.
5. Use 301 or 308 redirects for every mapped pair. Google states plainly that these don't cost you PageRank². A 302 temporary redirect, or no redirect at all, does not carry the same guarantee.
6. Move everything at once, not section by section, if your site is small or medium sized, which covers almost every agency site. That's Google's own recommendation, and splitting an already-small site into phases mostly just extends the confusing middle period without adding any real safety¹.
7. Submit the new sitemap in Search Console the same day you cut over, not a week later. Google states that submitting a sitemap helps the discovery process move faster¹.
8. Check the new site's meta robots tag and X-Robots-Tag header for anything left over from staging. A stray noindex or nosnippet is invisible in a browser and easy to miss without deliberately checking for it.
9. Confirm llms.txt, robots.txt, and sitemap.xml all resolve on the new site the moment it goes live, and that they reflect your actual current pages, not a cached or partial version.
10. Time it for February through August, outside the AEP and ACA Open Enrollment windows covered above, so any expected fluctuation lands during a slow month instead of your busiest one.
11. Watch the Page Indexing report weekly for 60 to 90 days after launch, looking for the pattern Google describes: old URLs dropping out of the index while new URLs take their place¹. That crossover is what a healthy migration looks like in progress.
12. Keep your old hosting active for at least 30 days after cutover, in case a redirect needs a fix. Cancelling the old host the day you launch removes your only safety net if something in the map was missed.

How we move a site without losing what you built

This checklist is the actual process we run, not a simplified version of something more complicated we hold back. Every site we build replaces what's running behind your domain, not the domain itself, so a client moving from a GoHighLevel funnel or a WordPress theme to a static Astro build served from Cloudflare's edge starts in the lower-risk category by default, not the 523-day one.

The new site gets built and reviewed on a preview address first, so you see the finished, working site before anything about your live domain changes. We build the full redirect map from your existing URLs before cutover, not after something 404s and someone reports it. Because sitemap.xml, robots.txt, and llms.txt regenerate themselves the moment a page publishes, the new site's crawl files are correct from the first minute it's live, which closes the exact gap covered in our guide to AI crawlers getting blocked without anyone having to remember a manual step. And because we know the calendar that matters to this industry specifically, we default to scheduling a cutover outside AEP and ACA Open Enrollment unless a client has a reason that outweighs it.

The destination matters as much as the process. A migration that trades a slow WordPress theme for a slow page-builder funnel still leaves you with a site that loads slowly on a phone, just on a new address. A static Astro build has fewer moving parts to slow it down in the first place: no plugin marketplace, no theme update pushing new bloat, no page-builder runtime booting before the content shows up. That's a separate problem from the migration risk this guide covers, and it's the reason the move is usually worth making once the risk itself is handled correctly.

Digital Foundation includes this migration process as part of building your site, not as a separate line item, with a 14-day free trial that lets you use the finished build before billing starts⁷. The point isn't the vendor. It's that the risk this guide describes is almost entirely a function of process, and a process you can specify in a contract before you sign one, whether that contract is with us or with whoever you're already talking to.

What actually changes once it's done

Nobody, including Google, can promise zero fluctuation during any migration. What changes is which category of risk you're actually taking. Keeping your domain and following the checklist above keeps you in the few-weeks range Google itself describes, not the 523-day average that belongs to a completely different kind of move. Your existing rankings, your Google Business Profile history, and the backlinks other sites have pointed at your domain for years all stay attached to the address that earned them.

What you get on top of that is the actual reason you were looking to switch in the first place: a site that loads in a couple of seconds instead of six, that doesn't run a plugin stack accumulating security patches, and that ships the crawl and citation plumbing this whole guide is really about protecting. The fear that's kept the old site alive turns out to be solvable with a checklist, not a reason to keep paying for something you don't like.

Questions agents ask