How to import 301 redirects into Webflow (CSV and wildcards)

In the site settings, under publishing, in the section called 301 redirects. Rules belong to the site rather than to a page, they are edited there one at a time or imported as a file, and they start working when the site is published — not when the file finishes uploading. If a test says the old url still 404s, publishing is the first thing to check.

Two practical consequences. Redirects are part of the site, so a rule from a relaunch three years ago is probably still sitting there. And because the section is one flat list, its length is the constraint that shapes everything below.

A header line and one row per redirect:

fromUrl,toUrl
/ueber-uns,/unternehmen
/produkte/seitenschneider,/produkte/seitenschneider-vde
/kontakt/formular,/kontakt

Both columns are paths. Not https://old-domain.com/ueber-uns, just /ueber-uns. That is the difference between the two files Silentfrog exports: the generic csv carries absolute urls and match metadata because it doubles as an audit report, and the Webflow csv carries nothing but the path pairs an importer wants (the two downloads).

Leading slash on both sides, no domain, no trailing whitespace. If your redirect map was built from absolute urls somewhere else, strip the origin before importing — otherwise every rule looks valid in the file and matches nothing on the site.

A relaunch usually moves whole sections rather than individual pages, and writing one row per page for a blog with 400 posts is both tedious and close to the importer’s limit. A wildcard rule is one row that covers everything below a path — including urls no crawl and no sitemap ever listed.

Webflow’s wildcard notation is a capture group: (.*) in the old path stands for “whatever comes here”, and %1 in the redirect path puts that captured part back. So /old-folder/(.*) → /new-folder/%1 moves a whole folder and keeps every slug. A second group is %2. It looks like a regular expression but is not one — Webflow’s matcher understands only this form, and a plain * is read as a literal character, not a wildcard.

Silentfrog writes a directory rule with export as wildcard rule ticked as exactly one row in that notation:

fromUrl,toUrl
/blog/(.*),/magazin/%1
/blog,/magazin
/moved,/moved-here

Three things about that file are worth knowing. The wildcard rows come first, before the individual ones — Webflow applies rules in order, so a more specific redirect has to be listed above the wildcard that would otherwise catch it. Every row the wildcard covers is left out, which is why the Webflow csv can be far shorter than the results table. And the directory’s own index page keeps its own row — /blog/(.*) does not cover /blog, so /blog,/magazin is written separately.

A directory rule set to all to one page instead of keep sub-paths exports as /blog/(.*),/magazin: everything below the folder lands on one target, with no sub-path carried over.

One limit to test rather than assume: the capture group is meant for one path segment. After importing, open an old url with a nested path, such as /blog/2019/post, and check where it lands before trusting the rule for the whole tree.

A redirect you were not sure about is worse than no redirect, so three kinds of row are deliberately excluded from the Webflow export:

identity rows — fromUrl and toUrl are the same path. The page did not move; a rule pointing a url at itself is at best noise and at worst a loop.

unmatched rows — no target was found. They stay in the generic csv with an empty target so you can see what was left undecided, but they have nothing to import.

unverified needs-review rows — a match the tool is only 60 to 85 % sure of. Tick the checkbox on the ones that are right — or use verify n shown after filtering — and they are in the next download. Leave them and they stay out.

This is why the Webflow csv is regularly much shorter than the table you were just looking at. It is not losing rows; it is refusing to guess on your behalf.

Before you import anything, look at what the redirect section already holds. Sites that have been relaunched before carry rules from the previous move, plus whatever somebody typed in by hand after a page was renamed. Treat the import as a replacement of that list rather than an addition to it: copy the existing rules out and include them in the file you upload, so nothing that was working yesterday quietly stops.

Where the two lists disagree — the same fromUrl with a different target — your new map should win, but that is a decision worth making on purpose. An old rule pointing at a url the new site does not have is also the classic source of a redirect chain.

Around a thousand rows is where the importer stops being dependable. Silentfrog warns when an export goes past that and says what to do about it, because the answer is almost always the same: turn the biggest directories into wildcard rules. One row replacing four hundred is not a workaround, it is the better rule — it also covers urls nothing ever listed.

If you are still over the limit after that, the map is probably carrying urls that should be 410 rather than 301. Expired campaigns and event pages with no successor do not need a row.

Yes, and it is the right time to do it. A Webflow staging domain (your-site.webflow.io) is an ordinary server-rendered site, so it can be crawled as the new side of the pair while the production domain still serves the old one. You get the redirect map finished and reviewed before launch day instead of during it (starting a run).

Two caveats. If staging sits behind a password or an ip allowlist, a hosted crawler cannot reach it — that is what the desktop app is for, since it crawls from your own machine. And if the old site has already been switched off, the old urls come from a file instead (when the old site is gone).

There is a redirects endpoint in the Webflow Data API — POST /v2/sites/{site_id}/redirects, documented as available on Enterprise workspaces, with a rate limit of 60 requests per minute. On a workspace that has it, rules can be written straight onto the site instead of going through a file.

For everyone else the csv is the route, and the practical difference is small: the same rows go out either way, and the reviewing you did in the table is what actually decides the quality of the map.

Publish the site, then check the redirects rather than assuming them. Crawl your list of old urls against the live domain: every one should answer 301 and then 200, in a single hop. Watch Search Console over the following weeks — pages with a redirect should grow, not-found errors should not. The full sequence is in the relaunch checklist.

One thing a wildcard rule cannot tell you: whether the target it produces actually exists. /blog/(.*) → /magazin/%1 happily sends /blog/typo-slug to /magazin/typo-slug, which is a 404. That is why the individual preview matters before you switch a rule to wildcard.

• Redirects live in the site settings under publishing, and only take effect once the site is published.
• The csv is two columns, fromUrl,toUrl, both of them paths with a leading slash and no domain.
• A wildcard row exports in Webflow's notation, /blog/(.*),/magazin/%1, and replaces every individual row it covers; the folder's own index page keeps its own row.
• All to one page exports as /blog/(.*),/magazin — no sub-path carried over.
• Identity rows, unmatched rows and unverified needs-review rows are left out on purpose.
• Copy the rules the site already has into the file before importing, and expect trouble past about a thousand rows.
• Build the map against the .webflow.io staging domain before launch, then re-crawl the old urls after publishing.