The short answer
Redesigns lose search traffic for one main reason: URLs change and nothing points the old addresses to the new ones. Google's site move documentation gives the method. Inventory every existing URL, map each one to its new home, use permanent server-side redirects, avoid chains, submit a new sitemap and keep the redirects for at least a year. Google also says to expect temporary ranking fluctuation, and that a medium-sized site can take a few weeks or more to settle. Plan the launch for a quiet period and watch Search Console closely afterward.
Inventory the old site before anyone designs
Start with a complete list of what exists. Google's documentation says to build the URL list from your sitemaps, server logs and analytics data. Add Search Console's performance data so you know which pages earn impressions and clicks. That list decides what must be kept, improved, merged or retired.
The inventory is where a redesign is won. A page that looks unimportant in a design review may be the one bringing in a third of your inquiries. Decide what happens to each URL with the data open, not from memory.
- Every live URL, including PDFs, images and old campaign pages
- Which pages receive search traffic and for which queries
- Which pages other websites link to
- Which pages generate calls, forms or sales
- Content that is outdated, duplicated or thin
- Every form, tracking tag, embedded tool and integration
Map every old URL to a new one
Create a mapping from each existing URL to its new destination. Google's guidance is specific: do not redirect many old URLs to one irrelevant page such as the home page, and return a proper 404 or 410 for content that is truly gone. Each valuable page needs an equivalent.
The cleanest redesign keeps URLs the same wherever the page still exists. Every URL you do not change is one you cannot break. Where the structure has to change, the map becomes the build specification for redirects and the test script for launch day.
Google's documentation also says to update internal links to point at the new URLs directly rather than relying on redirects, and to give new pages self-referencing canonical tags.
| Old page situation | What to do | Why |
|---|---|---|
| Page stays with the same content | Keep the same URL if possible | No redirect needed and nothing to lose |
| Page stays at a new address | Permanent redirect to the new URL | Google treats it as a signal that the target should be canonical |
| Two pages are merged | Redirect both to the combined page | Visitors and search engines land on the closest match |
| Page is retired with no replacement | Return a 404 or 410 | Google advises against redirecting to an irrelevant page |
| Whole site moves to a new domain | Redirect every URL then use the Change of Address tool | The tool is only for domain or subdomain moves |
Use the right kind of redirect
Use permanent server-side redirects, the 301 or 308 status codes. Google's redirect documentation says a permanent redirect shows the new target in search results while a temporary one keeps showing the source page. It says to use JavaScript redirects only if server-side or meta refresh redirects are not possible.
Google also advises against chaining redirects. If a page moved in an earlier redesign and moves again now, point the oldest address straight at the newest one instead of hopping through the middle. Then leave the redirects alone: Google says to keep them as long as possible, generally at least one year.
This matters for a physical business too. Old URLs are printed on brochures, vehicle graphics, QR codes and menus. Redirects keep those working long after the reprint budget is spent.
Carry over analytics and tracking
Record a baseline before launch and make sure measurement survives it. Export rankings, traffic and conversion numbers for the old site, verify the new site in Search Console and confirm that analytics, call tracking, ad conversion tags and form notifications all fire on the new pages before the switch.
Without a baseline you cannot tell a normal post-launch wobble from a real problem. Google recommends the Search Console Performance report as the first place to look when traffic changes, comparing periods and reviewing which pages were affected.
- Baseline export of traffic, top pages, queries and conversions
- Search Console verified for the new site, and the old one kept verified
- Analytics installed and tested on every page type
- Form submissions tested end to end, to the inbox and the CRM
- Call tracking numbers and click-to-call links checked on a phone
- Ad landing pages and conversion tags updated to the new URLs
Rebuild accessibility in instead of patching it later
A redesign is the cheapest moment to get accessibility right, because every template is being rebuilt anyway. Design to the Web Content Accessibility Guidelines from the first layout, then test each page type with a keyboard and a screen reader before launch rather than after a complaint.
The Department of Justice's guidance lists the barriers it sees most: poor contrast, missing text alternatives, uncaptioned video, inaccessible forms and mouse-only navigation. Each is trivial to prevent in a new design system and tedious to retrofit across a finished site. Our guide to website accessibility and the ADA in Florida covers the rules and a fuller checklist.
Launch day
Pick a quiet period, launch everything at once and test immediately. Google says small and medium sites should move all URLs together, and suggests timing a move for lower traffic. Then remove any noindex rules or robots.txt blocks left from development, test the redirects and submit the new sitemap.
Timing is local. For many Palm Beach County businesses the busy stretch runs through winter and spring, so the calmer summer months are the natural window for a move. A restaurant on Clematis Street and an equestrian business in Wellington will have different quiet weeks. Look at your own traffic and pick yours.
- Confirm the development noindex and robots.txt blocks are gone
- Test every redirect in the URL map, not a sample
- Submit the new sitemap in Search Console
- Send a test through every form and place a test call
- Check key pages on a phone, on slow data
- Use the Change of Address tool only if the domain itself changed
- Keep the old site's files and database archived
The weeks after launch
Expect some movement and watch for real errors. Google says to expect temporary fluctuation in ranking during a move and that for a medium-sized site it can take a few weeks or more for the new URLs to appear. Check Search Console's indexing reports for unexpected errors.
Google's troubleshooting advice is to look at the pattern. A brief dip that recovers is the move being processed. A drop confined to certain pages usually points to missing redirects or removed content. A site-wide drop that holds calls for a technical review of what changed.
- Review indexing reports for 404s and pages blocked by mistake
- Compare traffic and conversions against the baseline each week
- Fix any old URL that still gets visits and has no redirect
- Ask the owners of important sites that link to you to update their links
- Update the URL on your Google Business Profile, directories and social profiles
- Leave the redirects in place for at least a year
Frequently asked
Google says that for a medium-sized website it can take a few weeks or more for its systems to start showing the new URLs, and longer for large sites. The speed depends mostly on the number of URLs and your server speed. Google also tells site owners to expect temporary fluctuation in rankings while the move is processed.
Keep them as long as possible. Google's site move documentation says to keep redirects generally for at least one year so its systems can transfer signals to the new URLs. In practice there is rarely a reason to remove them, since printed materials, old emails and links on other websites will keep sending people to the old addresses.
Only if the domain or subdomain is changing. Google's Search Console help says the Change of Address tool is for moving a site from one domain or subdomain to another, used after the redirects are live. It is not for moving pages within the same site, switching to HTTPS or changing between the www and non-www versions.
You should not. Google's documentation specifically warns against redirecting many old URLs to one irrelevant destination such as the home page, because it confuses visitors and may be treated as an error. Redirect each old page to its closest equivalent, and let pages with no replacement return a 404 or 410 status.
Sources
- Google Search Central: Site moves with URL changes
- Google Search Central: Redirects and Google Search
- Search Console Help: Change of Address tool
- Google Search Central: Debugging drops in Google Search traffic
- ADA.gov: Guidance on Web Accessibility and the ADA
- W3C Web Accessibility Initiative: WCAG 2 Overview