Almost always because the old URLs were not redirected, or were redirected badly. Every link, bookmark, and search result pointing at your old pages now leads nowhere. The rankings those pages earned over years do not transfer on their own. A redirect is what carries them across.
This is the single most expensive avoidable mistake we see in web projects. A team spends months on a beautiful new site, launches it, and loses half its organic traffic in a fortnight. The design was fine. The redirect map was missing.
Redirects are boring work. They are also the difference between a launch that keeps its search visibility and one that starts from zero. Here is how we handle them, and what Google itself says about the rules.
A redirect tells browsers and crawlers that a URL has moved. Google's documentation splits them into permanent and temporary. Permanent redirects show the new page in search results. Temporary redirects keep showing the original. Which one you pick changes what Google indexes.
Google lists the permanent options as HTTP 301, HTTP 308, a meta refresh set to zero seconds, an HTTP refresh set to zero seconds, and a JavaScript location change. The temporary options are HTTP 302, HTTP 303, HTTP 307, and meta or HTTP refreshes set to longer than zero seconds.
Google is also explicit about which method to reach for. Server-side redirects are the most reliable, meta refresh is second, and JavaScript is last. Its guidance says to only use JavaScript redirects if you cannot do server-side or meta refresh redirects, because the rendering step can fail.
That ordering matters on modern stacks. A redirect implemented in client-side JavaScript depends on a crawler running your code. Some will. Some will not, and you will not get a warning.
Use a 301 when the move is permanent, which covers almost every launch, rebuild, and URL restructure. Use a 302 only when the original URL will genuinely come back, such as a page temporarily pointing at a maintenance notice or a regional promotion.
The mechanical difference is canonicalization. Google says that with a permanent redirect, Googlebot follows it and the indexing pipeline uses the redirect as a signal that the target should be canonical. With a temporary redirect, the pipeline does not treat the target as canonical.
So a 302 left in place by accident tells Google to keep indexing a URL you have abandoned. We find these constantly on inherited sites, usually because a developer used the default setting in a hurry and nobody checked the status codes afterwards.
Crawl the old site, export every URL that has traffic or links, and pair each one with its closest match on the new site. Do this before launch, not after. The map is a simple two column list, and it is the most valuable document in a migration.
We start with a full crawl using a tool like Screaming Frog, then cross-reference against Google Search Console for pages with impressions and against Ahrefs or Semrush for pages with backlinks. A URL with no traffic and no links can often be retired. A URL with either needs a destination.
Every old URL should land on the most relevant equivalent page. If a blog post about pricing becomes part of a larger pricing guide, that is where it goes. Relevance is what preserves the value, because the redirect is telling Google these two pages serve the same intent.
Where possible we use pattern-based rules rather than one line per page. Webflow supports wildcard redirects, and its help documentation recommends using wildcards where possible to minimize the total number of rules. It also notes that more specific redirects must be added before broader wildcards, because otherwise the wildcard catches the request first.
Because each hop adds delay and risk, and Google actively discourages them. Its crawl budget documentation says plainly to avoid long redirect chains, which have a negative effect on crawling. A chain also slows real users, since every hop is another round trip.
Chains build up over years without anyone noticing. The 2019 rebuild redirected page A to page B. The 2023 rebuild redirected B to C. Now a visitor from an old link travels A to B to C before seeing anything. Each step is a fresh request to your server.
The fix is to flatten. Point every old URL directly at the final destination, not at an intermediate one. When we take over a site with several rebuilds behind it, flattening chains is usually one of the first things we do, and it is often the fastest measurable win available.
The same documentation lists other crawl waste worth cleaning up at the same time, including soft 404 errors, which Google says continue to be crawled and waste your budget, and duplicate content, which it recommends consolidating.
No. It is the most common shortcut and it throws away most of the value. A bulk redirect to the homepage tells Google the old page has no real equivalent, and visitors who wanted a specific thing land on a generic page and leave.
We understand the temptation. A large site with thousands of retired URLs is a lot of mapping work, and pointing everything at the root takes ten minutes. The result is predictable, which is that rankings for those pages do not survive the move.
The honest alternative for genuinely dead pages is a 404 or a 410. If a page has no equivalent and no traffic worth saving, letting it die cleanly is better than a misleading redirect. Save your mapping effort for the URLs that actually earned something.
Longer than most teams expect. Google's site move documentation says to keep the redirects for as long as possible, generally at least one year, because that is what allows all the signals to transfer to the new URLs. For user experience, keeping them indefinitely is reasonable.
Google also sets expectations on speed. Its documentation says a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer, because Googlebot has to visit every URL on both the old and new sites at least once.
There is a second reason not to remove redirects early. Older pages carry disproportionate weight in search. Ahrefs found in a 2025 study of 1 million URLs that 72.9% of pages in Google's top 10 are more than three years old, with the average top-ranking page around five years old. Those accumulated years are exactly what a redirect is protecting.
Four things, all named in Google's own migration guidance. Submit the new sitemap in Search Console. Use the Change of Address tool if the domain is changing. Update your internal links to point at the new URLs. And ask the most important external sites linking to you to update their links.
Internal links are the step teams skip most often. Leaving them pointing at redirected URLs means every internal click takes an extra hop, and it signals uncertainty about which URL is canonical. We rewrite internal links to their final destinations as part of the launch, not afterwards. Our notes on internal linking for SEO cover why that structure carries more weight than people assume.
The Change of Address tool applies to domain moves rather than URL restructures on the same domain, and Google notes it does not apply to plain HTTP to HTTPS migrations. If you are moving domains, submit it for all the variants including subdomains and the www and non-www forms.
Test the status codes directly rather than trusting the browser. A page that visually loads can still be returning the wrong code. Crawl your old URL list after launch and confirm each one returns a single 301 straight to a live 200 page.
We run the pre-launch URL list through a crawler on launch day and again a week later. What we are hunting for is any old URL returning 404, any chain longer than one hop, any 302 that should be a 301, and any redirect landing on a page that itself redirects.
Then watch Search Console rather than analytics for the first month. Coverage reports show you which old URLs Google has processed and which new ones it has indexed, which is the actual measure of whether the move is transferring. Traffic dips of a few weeks are normal on a large move, and Google says as much.
Platform detail matters here too. In Webflow, redirects live in Site settings under Publishing, and per Webflow's documentation the site needs a paid Site plan or a paid Workspace plan for them to be available. Webflow also tries older rules before newer ones, which affects how wildcards and specific rules interact.
Build the redirect map while the new site is still in staging, not on launch day. Crawl the old site, keep every URL with traffic or backlinks, pair each with its closest equivalent, flatten anything that would create a chain, and test the whole list against staging before you go live.
Treat it as a launch requirement rather than a post-launch task. Across the 150-plus projects we have delivered, redirects are the least glamorous part of the work and the one with the highest cost of failure. A missing map can undo years of search equity in a fortnight, and the fix afterwards is always slower than doing it in advance. Our fuller walkthrough of migrating a site without losing SEO covers the surrounding steps, and the WordPress to Webflow guide gets specific about that path.
If you have a rebuild coming and you want someone to sanity-check the mapping before you launch, we are happy to look at it. Send us the old URL list and the new sitemap and we will tell you what is missing. Let's talk, over at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.