Webflow 301 redirects: the real limit, and the order they run in
Three different redirect limits are published for Webflow and none of them is quite right. Here is what Webflow documents, the file every rule is written into, and the ordering rule that makes a specific redirect fail silently.
Search for Webflow's redirect limit and you get three answers that cannot all be true. One says 500 on the CMS plan and unlimited on Business. One says no limit at all. One says 1,000. Webflow's own help page settles it, and along the way it states two things about how redirects behave that almost nothing else on that page of results mentions.
The first answer is easy to dispose of. The CMS and Business plans stopped being sold on 13 May 2026, which we cover in the May 2026 plan changes, so a limit stated per plan for those two plans is describing a lineup that no longer exists. The other two are both half right.
There is no hard limit, and there is a recommended one
Webflow's page says it plainly: there is currently no hard limit on the total number of redirects, and 1,000 is recommended as best practice. Both of the surviving answers are quoting one half of that sentence. What matters more is the reason Webflow gives, because the reason tells you which redirects are expensive.
Each redirect rule is uploaded into the site's manifest.json, the file that gives browsers information about the site. As that file grows, there is more for every visitor's browser to download. So a redirect on Webflow is not a line in a server config that costs nothing until it matches. It is payload, shipped to everyone, whether or not anybody ever requests the old URL. That is why Webflow's advice is to reach for wildcards, which cover many old paths in one rule.
The order they run in is the opposite of what you expect
Webflow executes redirects in the order they were added to the site. Older rules are tried first, newer rules after. Nothing about specificity enters into it.
Anyone who has written redirects in nginx or an .htaccess file carries the opposite instinct, where a more specific rule is expected to win. Here it does not. Add a broad wildcard such as /blog/(.*) early in a migration, then add a specific rule for /blog/the-one-post-that-moved-elsewhere a week later, and the specific rule never fires. The wildcard catches it first, because it is older. Nothing errors, nothing warns, and the page resolves to the wrong destination for as long as nobody checks it.
The practical rule that follows: add specific redirects before broad ones, and when you inherit a redirect table you did not write, sort it by date created in Site settings and read it in that order. Webflow exposes the date created filter for exactly this reason.
What else the page states
| Behaviour | What Webflow documents |
|---|---|
| Plan requirement | A paid Site plan, or a Workspace with a paid Workspace plan |
| Localized paths | Redirects are relative to the root domain and do not apply to localized slugs, so /old and /es/old need two rules |
| Redirecting a live page | Delete the page, save it as a draft, or change its slug first, otherwise the redirect does not take |
| Redirecting a CMS item | Archive, delete, unpublish, draft or reslug the item first |
| Wildcards | Capture groups are written (.*) and referenced as %1, %2 in the target path |
| Bulk changes | 301 redirects can be imported and exported as CSV |
| Slug changes | Ticking the permanent redirect box in Page settings creates the 301 for you |
The localized paths row is the one that catches multilingual migrations. A site with three locales needs three rules for every moved URL, not one, and a redirect table sized for the English tree will silently 404 the other two. That triples the count against the 1,000 recommendation faster than anyone expects.
How this changes a migration plan
- Map to wildcards before you map to rules. A folder that moved wholesale is one rule, not two hundred, and the difference is bytes on every page load rather than a line in a config file.
- Enter the exceptions first, the wildcards last. The order of entry is the order of execution, and it cannot be reordered afterwards.
- Count locales, not URLs. Three locales means three rules per moved path.
- Export the table to CSV once the migration is live and keep it with the project. It is the only readable record of what the old site was, and it is the first thing anyone needs when a ranking drops.
The reason to get this right on the day rather than later is that a missed redirect does not look like a missed redirect. It looks like a ranking that fell after a launch, which is the ambiguity we untangle in indexed but not ranking, or not indexed at all. The redirect table is the first place to look, and on Webflow the order of the rows is part of what you are looking at. The same applies whichever platform you came from, whether that is WordPress, Wix or Squarespace.
