The old address stops working. Anyone who bookmarked it, linked to it, or found it in Google hits a dead page. Every link pointing at that URL stops helping you. A 301 redirect fixes this by telling browsers and search engines that the page moved and where it moved to.
We see this most during redesigns. A team reorganises the site, the new structure is genuinely better, and traffic drops by half the following month. The design was not the problem. The URLs changed and nobody mapped the old ones to the new ones.
Redirects are unglamorous and they are the highest leverage thing you can get right during a rebuild. Here is how they work in Webflow and, more importantly, how to decide which ones you need.
A 301 is the HTTP status code for a permanent move. MDN describes it as indicating that the requested resource has been permanently moved to the URL given in the Location header. The browser follows it automatically, so the visitor lands on the new page without noticing anything happened.
The part that matters commercially is what search engines do with it. MDN states that search engines receiving this response will attribute links to the original URL to the redirected resource, passing the SEO ranking to the new URL. In plain terms, the new page inherits the credit the old page earned.
Google describes the same behaviour from its own side. Google Search Central states that Googlebot follows the redirect and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. That is the whole reason to bother. Without it, years of accumulated authority evaporate.
In your site settings. Webflow University states that 301 redirects can be managed from your site settings under Redirects, and that they exist to preserve SEO equity when URLs change. You add the old path and the new path, save, and publish the site.
The important detail is that last step. Like everything else in Webflow, redirects take effect on the published site, not in the Designer. We have watched teams add forty redirects, close the tab, and wonder why nothing changed. Publish, then test.
Testing is not optional either. Open a private browser window, paste an old URL, and confirm where you land. Do this for a sample of every pattern you added, not just the first one. A redirect rule that looks right and points at a typo is a redirect that quietly loses a page.
Webflow's plan tiers and capabilities around redirects do change over time, so check what your specific plan supports in Webflow's own documentation rather than trusting a blog post from two years ago. Ours included.
A 301 says the move is permanent. A 302 says it is temporary. Google Search Central states that permanent redirects show the new target in search results, while temporary redirects keep the source page displayed. So the choice directly controls which URL appears to your customers.
Use a 302 only when you genuinely mean it, such as a page taken down for a fortnight or a seasonal campaign that will return to its own URL. Use a 301 for anything structural. If you are moving a page as part of a redesign, that is permanent, even if it feels reversible while you are nervous about it.
The common failure is using a temporary redirect out of caution during a migration and then never changing it. Search engines keep showing the old URL, the new one never accumulates authority, and six months later nobody remembers why the site never recovered.
When the request method must survive the redirect. MDN warns that under the Fetch Standard, a user agent receiving a 301 in response to a POST request will use GET for the subsequent request. It recommends 308 Permanent Redirect instead, because altering the method after a 308 is prohibited.
For ordinary page redirects this never comes up, because pages are requested with GET anyway. It matters for form endpoints and API routes, where turning a POST into a GET silently discards the submitted data. That is the kind of bug that produces an empty inbox and no error message.
Google treats both as permanent. Google Search Central lists 301 and 308 together as permanent redirects, and states that server-side redirects are the best way to ensure that Google Search and people are directed to the correct page. So there is no SEO penalty for choosing the safer code where it applies.
Every URL that has value and is changing. That means every page with existing traffic, every page with external links pointing at it, and every URL that appears in a printed or emailed asset you cannot recall. Everything else can be left to a good 404 page.
The way we build the list is to export the old site's URLs from analytics and Search Console, sort by traffic and by referring links, and map each one by hand to its closest new equivalent. Closest matters. A redirect to a vaguely related page is worse than a 404, because it wastes the visitor's time and tells search engines the pages are the same when they are not.
Do not redirect everything to the homepage. It is tempting, it is fast, and it destroys the value you were trying to preserve. A visitor looking for a specific page does not want your homepage, and a redirect to something unrelated does not describe a real move, so you get neither the ranking transfer nor a useful visitor experience.
The full process around a move is bigger than the redirect map alone, and we walked through it in our guide to migrating a website without losing SEO. The redirects are the last mile, not the whole road.
Longer than you think. There is no official expiry, and Google's redirect documentation does not put a number on it. Our rule is a minimum of one year and, in practice, forever, because a redirect costs nothing to keep and removing one silently breaks every old link that still exists.
Google's own framing supports patience. Its documentation notes that as users get used to a new domain name, alternate names will fade away without you doing anything. That fading takes real time, and it happens on the internet's schedule rather than yours.
The only redirects worth removing are ones that are now wrong, such as a rule pointing at a page you have since deleted. Auditing for those once a year is sensible. Deleting redirects to tidy up is not.
A chain is when one URL redirects to a second, which redirects to a third. Each hop adds latency for the visitor and adds a step that search engines have to follow correctly. Google's documentation lists redirect types by how likely it is able to interpret them correctly, which is a strong hint that simpler is safer.
Chains build up over years. Someone redirects a page in 2023, a different person redirects the new URL in 2025, and nobody goes back to update the first rule. The site works, so nobody notices, but every old link now takes three trips to arrive.
The fix is mechanical. Whenever you add a redirect, check whether any existing rule points at the URL you are moving, and repoint those directly at the final destination. It takes a minute during the change and it is tedious to untangle two years later.
Redirects and canonical tags also get confused with each other, and they solve different problems. We separated them out in our piece on what canonical URLs are and how they fix duplicate content.
Four, consistently. Forgetting to publish after adding rules. Mapping everything to the homepage. Using temporary redirects for permanent moves. And redirecting with JavaScript or a meta refresh instead of a proper server-side rule.
That last one deserves attention because it looks like it works. Google's documentation recommends server-side redirects first, meta refresh second, and JavaScript redirects last, citing reliability concerns with rendering. A JavaScript redirect only fires if the crawler runs your JavaScript, and many do not.
The other mistake we see is treating CMS item URLs as an afterthought. If you change a collection's slug field or restructure a collection, every item URL underneath it changes at once. That is potentially hundreds of URLs moving in a single publish, and it needs to be planned before you click the button, not discovered afterwards.
If you are moving onto Webflow from another platform, the redirect map is usually the biggest single task in the project. We described how that plays out in practice in our walkthrough of migrating from Squarespace to Webflow.
Write the redirect first. Before you rename a page, before you restructure a collection, before you launch a redesign, build the map of old paths to new paths and have it ready to enter. Changing URLs and then working out the redirects is how sites lose traffic they never get back.
Then verify after publishing. Test a sample by hand, watch Search Console coverage for the following few weeks, and keep an eye on 404 reports. Redirects are one of the few SEO tasks where you get clear, fast feedback on whether you got it right.
If you have a Webflow site with a redesign coming and the URL structure is changing, that is exactly the moment to get a second opinion. Send us the current sitemap over at phoenix.studio and we are happy to walk through the mapping with you. It is far cheaper to plan it than to reconstruct it.
Tell us where you want to go. We'll tell you how we'd get you there.