What Breaks When You Change a Webflow CMS Collection Slug?

What breaks when you change a Webflow CMS Collection slug?

Every URL under that Collection changes at once, and every external link to the old URLs stops working until you add redirects. Webflow's documentation is direct about this: if you rename the Collection URL after publishing, you need to set 301 redirects so existing external links to pages in the Collection keep working.

The reason this catches people is scale. Changing one item slug breaks one page. Changing the Collection URL breaks every page the Collection generates, which on a mature blog might be a thousand URLs in a single click, with no warning proportional to the damage.

The shape of the mistake is always the same. Somebody decides /blog should be /resources, makes the change in the Designer, publishes, and only afterwards works out that every external link, every bookmark, and every indexed URL was pointing at the old path. The change itself takes one click. The consequences arrive later and from every direction at once.

What is the difference between a Collection URL and an item slug?

The Collection URL is the folder. Webflow describes it as the slug for the folder that holds your Collection pages, meaning the pages generated for each Collection item. The item slug is the individual page inside that folder. One is the street name, the other is the house number.

Both can change and both have consequences, but the blast radius is wildly different. Webflow's own Data API documentation is blunt about the item level, stating that updates to an item slug will break all links referencing the old slug. That is one page.

The Collection URL is the one to be frightened of, because it multiplies that same breakage by however many items you have. Webflow says you can rename a Collection URL at any time, which is true and is also the kind of permission that deserves a pause before you use it.

Why does Webflow let you do something this destructive?

Because it is the correct behaviour for a design tool. The URL structure is a design decision and locking it would be worse, particularly early in a project when the structure genuinely should change. The tool is not wrong. The absence of a proportional warning is what makes it feel wrong.

It also reflects a boundary that every CMS has to draw somewhere. Webflow cannot know whether your Collection has three items you made this morning or three thousand that have accumulated links for four years. Only you know which situation you are in, and only you can act accordingly.

There is one place Webflow does stop you, which is Ecommerce. Its documentation states that you cannot rename Collection slugs of Ecommerce Collections. If you work mostly in Ecommerce and assumed this was true everywhere, the CMS side will surprise you.

How do you redirect a whole Collection at once?

With capture groups, which is the one piece of syntax worth memorising. Webflow's documentation shows entering the old URL structure with a capture group in the Old path field, in the form /oldfolder/(.*), and the new structure with a target in the Redirect to path field, in the form /entirely/new-url/structure/%1.

That single rule handles every item in the Collection, which is the difference between a five minute fix and a spreadsheet of a thousand individual redirects. The (.*) captures whatever followed the old folder, and %1 puts it back after the new one.

You set these in Site settings, under Publishing, in the 301 redirects section, with an Old path field and a Redirect to path field. If you are doing this as part of a larger restructure, build the mapping before you touch anything, which is the argument I made in writing the redirect map before a Webflow migration.

Why can you not just redirect a live Collection item?

Because the page still exists, and a redirect cannot compete with a real page at the same address. Webflow's documentation says that to redirect an existing Collection item page to a new URL, you need to archive, delete, or unpublish the item, save it as a draft, or change its slug, before setting the redirect.

This is the single most confusing behaviour in this whole area, and it is the reason people conclude that Webflow redirects are broken. They add the redirect, they test it, the old page loads as normal, and they assume the feature failed. The feature did not fail. The source page is still live.

So the sequence matters more than the syntax. Change or retire the item first, then create the redirect, then publish. Doing it in the other order produces a redirect that sits there looking correct and does nothing at all.

What does this not cover?

Localisation and subdirectories. Webflow's documentation states that 301 redirects are relative to your root domain and won't apply to localized slugs or subdirectories. If you run a localised site, do not assume a root-level redirect protects the localised versions of those URLs.

It also does not cover anything pointing at the old URLs from inside your own site. Redirects rescue external links and bookmarks, but your own internal links, your navigation, and any hardcoded href in a rich text field will still point at the old structure, quietly relying on the redirect forever.

And it does not cover your sitemap, which is its own conversation. A structure change is exactly the moment your submitted URLs and your indexed URLs start disagreeing, which I have written about in why your sitemap and your index coverage disagree.

What is the order of operations that actually works?

Inventory first. Get a list of every live URL under the Collection before you change anything, because once you rename, reconstructing the old list is guesswork. Export it, save it somewhere outside the site, and date it.

Then write the capture group redirect before making the change, so the rule is ready the moment the new structure exists. Then rename the Collection URL, then publish, then test a handful of old URLs by hand rather than trusting that the rule is right.

Then fix your internal links properly rather than leaving them to the redirect. A redirect is a safety net for people you cannot reach. Your own links you can reach, and leaving them pointing at dead addresses is how a site accumulates a decade of chained redirects that nobody dares touch.

What if you inherit a site where this already happened?

Start with what is still being requested. Search Console will show you URLs that are returning errors, and that list is more useful than any audit tool, because it is the actual set of addresses the outside world still believes in.

Then look at whether redirects exist and are simply ineffective because the source pages are still live. That is the most common inherited version of this problem, and it looks identical to having no redirects at all while being much faster to fix once you know what you are looking at.

Also check the sitemap. If it is still advertising the old structure you are actively telling search engines to crawl addresses you have abandoned, and that is worth resolving before anything subtler. I went into the controls for this in how to control what Webflow puts in your sitemap.

Is changing the Collection URL ever worth it?

Yes, but far less often than people think. The genuine cases are a structure that actively misleads, such as a folder called /news that now holds product documentation, or a merge where two Collections have to live under one path. Those are real problems that a redirect solves cleanly.

The cases I would push back on are aesthetic. Changing /blog to /insights because a rebrand decided "blog" sounds casual is a lot of risk for a word nobody types. The URL is read by machines and by almost no humans.

My rule after six years and more than seventy projects is that a URL change needs to survive one question: what specifically gets better, and for whom? If the answer is about how it feels rather than what it does, leave it alone. Structural changes are cheap to make and expensive to be wrong about.

What should you do next?

If you are about to rename a Collection URL, stop and export your current URL list first. That single step converts an irreversible action into a reversible one, and it takes about two minutes on any site small enough that you were considering doing this casually.

If you already renamed one and things look wrong, check whether your redirects are pointing away from pages that are still live, because that is the likeliest explanation and the quickest fix. Then test five old URLs by hand before you believe any dashboard.

If you are staring at a site with a tangle of old structures and broken links and you are not sure what is safe to change, reach out. Untangling this is unglamorous work and it is a lot cheaper than the traffic you lose while guessing.