Yes, a new website can cost a business its Google rankings and its place in AI answers, and the cause is rarely the design. When a website redesign loses rankings, the trail almost always leads back to old page addresses, wording and tracking that were not carried over to the new site. The protection is simple: before the old site is switched off, five things need to be proven, and after launch, calls and bookings need to be watched for 12 weeks.
An old website is worth more than it looks, and a relaunch can quietly throw it away
A website that looks dated can still carry years of history. Google knows which of its pages answers "emergency repair on a Saturday" or "consultation fees near me". AI answer tools like ChatGPT have read its service pages. Customers have bookmarked the booking page, and the Google Business Profile links to one specific address on the site.
A relaunch changes three things at once: the page addresses, the wording on the pages, and the code that runs behind them. Any one of those can break the link between a person searching and a phone ringing. It is like moving offices without telling the post office: the mail is sent, it just stops arriving.
The cost shows up as a chain. Fewer people find the page, fewer people call or book, and more ad money goes into filling the gaps in the calendar. The dots rarely get connected, because nothing looks broken. The new site is beautiful and it loads fine.
There is also a cost almost nobody measures. If AI tools can no longer read the new pages, the business can drop out of the answer when someone asks for "the best option in [town]".
Timing makes it worse. Google's guide to site moves says a small to medium-sized site can take a few weeks for most pages to move over, and larger sites take longer. So the damage often appears a few weeks after launch, when the project has been paid for, the support window is closing and the old site is gone.
A typical scenario: a local service business relaunches in March. Its most profitable service page gets a new address, and nobody sets up forwarding from the old one. In April, requests for that service go quiet. The slowdown gets blamed on the season, and by June nobody remembers the website changed.

"A small dip is normal and it will bounce back" is the most expensive sentence in web design
Some wobble after a launch is real. Google needs time to visit the new pages, compare them with the old ones and decide where they belong. During that time, positions in search results can move up and down.
But a drop caused by something missing does not bounce back. If an old page now leads to a "page not found" screen, Google will eventually stop showing it, and no amount of waiting brings it back. That kind of drop waits for someone to fix the cause.
So two very different things hide behind the word "dip":
- Settling: the same pages exist, at forwarded addresses, with the same substance. Google is re-checking them. Temporary.
- Breakage: pages are gone, old addresses lead nowhere, wording was cut, or the tracking that counts calls was left behind. Permanent until fixed.
Here is the problem: on a traffic chart, settling and breakage look identical for the first few weeks. That is why the protection has to happen before launch, as proof, not after launch, as hope.
One more gap: most redesign advice measures "traffic". What matters is calls, form requests and booked appointments, and whether AI tools still mention the business. Those are the numbers this guide tracks.
Warning signs that need no tools to spot:
- The phone is quieter, but the website report says visits look fine.
- Online booking requests or contact form messages stop completely, even for a few days.
- An old link in a past email, a printed flyer's QR code or the Google Business Profile opens an error page.
- Customers mention they "could not find" a page they used to visit.
Why a website redesign loses rankings: what actually breaks, in plain words
Four causes account for most of the damage, and none is about colors or layout.
1. Page addresses change without forwarding
Every page on a site has an address, like a street address for that page. When the new site uses different addresses, each old one needs a permanent forward to its closest new page. Web developers call this a "301 redirect".
The business effect: without forwarding, every link that Google, AI tools and customers have to the old page leads to a dead end. Forwarding everything to the home page is not the same thing. The person who searched for a specific service lands on a generic page and leaves.
2. Content gets trimmed
Designers often shorten long service pages for a cleaner look. Those words were exactly what Google and AI tools used to match the page to real questions: the areas served, the services offered, price ranges, opening hours, the answers to common questions. Fewer words means fewer questions the site can answer.
3. Tracking does not move over
The call tracking number (a special phone number that shows which calls came from the website), the connection that sends form messages into the customer database, the booking widget and the visitor counter all live in the old site's code. One agency's analysis of traffic drops after redesigns lists missing or broken tracking among the usual suspects.
The effect: the numbers disappear exactly when they are needed to judge the launch. Calls may still arrive, but nobody can tell which ones came from the website and which came from ads. Budget decisions then rest on numbers nobody was counting.
4. Content becomes harder for machines to read
Some modern websites send a nearly empty page first, and the text appears only after extra code runs in the visitor's browser. Google explains that it handles this in a later step, so pages can wait in line before Google sees the full text. Google also notes that not every automated reader can run that extra code.
That matters for AI tools. The program an AI tool sends to read websites (often called a crawler) may only see what the server sends first. If service descriptions, prices or common questions only appear after that extra code runs, the safe assumption is that those tools cannot see them until someone proves otherwise.
Two smaller mistakes that cause big damage:
- The "do not list this site" switch is left on. While a new site is built on a private test copy (a staging site), a setting tells search engines to ignore it. If that setting goes live with the new site, Google is told to forget the business. The same applies to settings that block AI readers: OpenAI's crawler documentation says sites that block its search crawler will not be shown in ChatGPT search answers, and changes to that setting take about a day to take effect.
- Page titles reset to "Home" or "Untitled". The title is the blue headline Google shows for a page. A generic title gets fewer clicks, even when the page still ranks.

What it looks like day to day: three common ways a relaunch goes quiet
The three examples below are illustrative, built from the causes above. They show how the same technical problems feel from the inside of a business, and why they take so long to notice.
Two service pages merged into one
The new design combines all services into a single "Services" page. Two old pages, one for the most profitable service and one for urgent same-day requests, are deleted without forwarding. Google keeps showing the old addresses for a while, which now lead to an error page, then quietly drops them.
The slowdown gets noticed about five weeks later, when the front desk mentions that urgent requests have dried up. That is five weeks of the highest-value enquiries lost.
Warning sign: one type of request slows down, while general calls stay normal.
A new phone number nobody connected
The new site comes with a fresh call tracking number, but nobody links it to the reporting. Calls still arrive, so nothing seems wrong. But nobody can tell which jobs came from the website and which came from the ads anymore.
Two months later, the ad budget gets cut because "the website brings nothing", based on numbers that were never being counted.
Warning sign: website-sourced calls in the reports drop to zero or near zero overnight, right after launch.
A fancy section AI tools cannot read
The new site shows its service descriptions and common questions inside an interactive section that loads after the page opens. Google still lists the home page. But when a prospect asks ChatGPT for a recommendation in town, the business no longer comes up, because the pages that described its services now look almost empty to the AI tool.
Nobody finds out directly. New customers who used to say "I asked ChatGPT and it mentioned you" simply stop saying it.
Warning sign: new customers stop mentioning AI tools as how they found the business, and the test questions described below no longer return it.
What good protection looks like: five things to confirm before the old site is switched off
This is the core of the plan. None of it requires touching code. Each item is something the team building the site produces, and something that can be checked with plain eyes on launch day.
1. The address map
A simple spreadsheet listing every old page address and the new address it forwards to. How to check it: collect 10 old addresses (from a Google search of the business name, old emails, the Business Profile link, a flyer's QR code) and click them on launch day. Each one must land on the matching new page, not the home page and not an error.
Red flag: a plan to "send everything to the home page" or the assumption that "Google will figure it out".
2. A saved copy of the best old pages
Before anything is deleted, the pages that brought the most calls and form requests are saved with their full wording. Then the old and new versions are compared side by side: does the new page still cover the same services, areas served, price ranges and common questions?
Red flag: "The new copy is shorter and punchier, nobody reads long pages anyway."
3. The "before" numbers, written down
The last 8 to 12 weeks of calls, form requests and online bookings, week by week, recorded before launch. This is the baseline. Without it, nobody can prove a drop later.
Red flag: a plan to "look at the visitor numbers after launch".
4. Tracking carried over and proven
Before launch, someone makes a test call, sends a test form and books a test appointment on the new site. Each one must arrive where it should: in the customer database, the inbox, the booking or job management software.
Red flag: "The tracking code is the same, it should work."
5. Proof that Google and AI tools can read the pages
The key text on the service pages must be visible in the version of the page that automated readers receive, not only after extra code runs in a browser. Before launch, also confirm three settings: the "do not list this site" switch is off, AI search crawlers are not blocked, and the sitemap, the list of pages handed to Google, has been submitted.
Red flag: "Google can run our code, so it is fine." Google may get there later. Several AI tools may not get there at all.
The AI visibility test anyone can run
Pick five real questions customers ask, such as "who offers same-day appointments in [town]" or "best [service] near [area] open on weekends". Two weeks before launch, ask each one in ChatGPT and in Google (note the AI answer at the top of the results). Save screenshots.
Repeat the same questions at weeks 2, 6 and 12 after launch. Be honest about what this test can show: AI answers change from one run to the next, so one missing mention means little. Look for a pattern across all five questions.

Questions worth settling before launch
Each of these deserves a clear answer, in writing, before the old site goes dark:
- Is there a complete address map, and has it been spot-checked?
- Which old pages are being deleted, and why?
- How will it be proven that calls, forms and bookings arrive on day one?
- Can automated readers see the service pages without running extra code in the browser?
- What is the rollback plan, and how long would it take?
- How long will the old site files be kept after launch?
- Who watches the numbers for the first 12 weeks, and what happens if they drop?
Trade-offs: when this is overkill, and when it is not negotiable
Not every relaunch needs the full plan. The effort should scale with the risk.
A light version is enough when the site has about five pages, no ads point to it, and very few calls come from the web. In that case, three steps cover most of the risk: check that the old addresses forward correctly, make a test call and send a test form, and write down the numbers before launch.
The full plan is not negotiable when any of these apply:
- The domain name (the web address itself) is changing.
- The site is moving to a different website platform.
- Locations are being merged, or service pages are being cut or combined.
- The website brings in most new customers.
- Paid ads send people to specific pages.
Doing it properly has real costs. Expect a few extra days before launch, some extra hours for the address map and testing, and possibly keeping longer service pages than the designer would like. Weigh that against several weeks of reduced calls, which tends to hurt most when it lands in the busiest season.
And sometimes the right answer is not to relaunch at all. If the goal is only to look newer, a visual refresh of the current site, keeping the same addresses and the same pages, carries far less risk. It is worth being clear about what problem the new site solves before accepting the risk of moving everything at once.
What to do and when: a 12-week plan and a decision rule
- 4 weeks before launch: write down the baseline numbers, run the AI and Google question test, and request the address map.
- 1 week before launch: review the five proofs, agree on a go or no-go date in writing, and agree how long the old site stays available for a rollback (switching some or all of it back to the old version).
- Launch day: click the 10 old addresses, make a test call, send a test form, book a test appointment.
- Weeks 1 to 12: one line per week in a simple sheet: calls, form requests and bookings, next to the same week of the baseline. Repeat the AI question test at weeks 2, 6 and 12.
The decision rule below is an engineering rule of thumb, not a Google rule. It prevents both panicking too early and waiting too long.
- Act now: bookings or form requests near zero for even a few days. This is almost always a broken form, booking widget or tracking, not Google.
- Worry: calls or bookings noticeably down for two weeks in a row compared with the same weeks of the baseline. Time to find the cause.
Once a cause is found, there are four possible responses, and they are not equally good:
Fixing the specific cause is almost always the fastest route back. A full switch back feels safe, but it restarts the settling Google has already done.
One more rule from Google's site move guide: keep the forwarding in place for as long as possible, and generally for at least a year. Removing it early, for example during a later cleanup of the website account, is a common way to lose ground months after a launch that went well.
Closing thoughts: the redesign is not the risk, the move is
A new website is often the right decision. Faster pages, clearer services and a better booking flow can win back more customers than an old site ever brought in.
What costs rankings is the move: old addresses that lead nowhere, service pages that say less than they used to, tracking left behind in the old code, and text that machines can no longer read. Each of these is invisible on launch day and expensive by week six.
The good news is that every one of them can be proven before the old site is switched off, and measured for 12 weeks after. A launch backed by an address map, a saved copy of the best pages, honest before-and-after numbers and a few test calls keeps what the old site earned, and lets the new one build on it.



