Have set up the redirects as described in the documentation, but it’s returning a 404. Any idea what’s going on? I can’t find any reason for this to not work.
EDIT: Answer in post 7 and 8
1 Like
Hi there,
To resolve the 404 error with your redirect, you’ll need to prepare the original page before setting up the redirect. First, handle the existing page by either:
- Deleting it
- Saving it as a draft
- Changing its slug
For Collection item pages, you can:
- Archive the item
- Delete it
- Unpublish it
- Save it as a draft
- Change its slug
Once you’ve handled the original page, go to Site settings > Publishing > 301 redirects to set up your redirect. Remember to publish your site for the changes to take effect. You can verify the redirect is working by entering the old URL in a new browser tab.
Hopefully this helps! If you still need assistance, please reply here so somebody from the community can help.
1 Like
Your Old path redirect has a wildcard, which means the hyphen needs to be escaped properly.
1 Like
Hi @memetican. It’s clearly something I’m not getting here. Can you please give me a clue? 
1 Like
Try this-
/kontakt%-oss/ansatte/(.*)
1 Like
Thanks @memetican, this works!! But I’m struggelig a bit to see the logic! 
1 Like
I can’t help with that 
It’s clear that when the routing engine encounters an old path with a (.*) wildcard construction it goes down an entirely different processing path, with a bit of regex-like string matching but customized and simplified.
I suspect that more complex patterns were planned, or that it may even exist but is undocumented, that required the escaping to differentiate pattern terms.
It’s entirely possible that they are transforming the string directly into a regex pattern, which is probably how I’d do it. So the escaping is needed to either protect undocumented syntax, or for backwards compatibility with previously supported patterns.
But we’re both just guessing here.
2 Likes
Thanks for taking the time to try explaining the unexplainable @memetican! ;) I asked ChatGPT to explain this mystery, this is what I got:
This is one of those strange, undocumented Webflow quirks that even experienced devs trip over. Let’s unpack exactly why /kontakt%-oss/ansatte/(.*) works when /kontakt-oss/ansatte/(.*) didn’t 
The short answer
Webflow’s redirect engine doesn’t use a full regex parser — it uses a custom “pattern matcher” where certain characters (like -) can get misinterpreted as control or range symbols when combined with wildcards like (.*).
When you insert %, you’re telling Webflow’s system to treat the following text literally, not as part of a pattern.
So in /kontakt%-oss/..., the %- sequence means:
“Treat the hyphen as an actual dash, not a special pattern character.”
What’s actually happening under the hood
From experiments and Webflow staff replies over time:
- Webflow converts your redirect path into an internal pattern using a simplified syntax.
- Certain characters (
*,(,),-,%,:) are parsed specially. - The
%symbol acts as an escape operator, telling Webflow’s parser:
“The next character is literal — do not interpret it.”
So /kontakt%-oss/ansatte/(.*) is internally read as:
Match any URL starting with
/kontakt-oss/ansatte/and capture the rest.
While /kontakt-oss/ansatte/(.*) without % can confuse the parser, making it think the dash is part of a range or malformed token → causing a failed match (404).
Think of it like this:
| You type | Webflow reads as | Meaning |
|---|---|---|
/kontakt-oss/ansatte/(.*) |
invalid/misparsed pattern | doesn’t match anything |
/kontakt%-oss/ansatte/(.*) |
/kontakt-oss/ansatte/(.*) |
correctly escaped literal dash |
TL;DR
%in Webflow redirects = escape character for the next symbol.- It forces Webflow to interpret the following character literally, even if it’s normally special.
- You rarely need it — but for paths with hyphens next to dynamic wildcards (
(.*)), it can fix otherwise unexplainable 404s.
Would you like me to write a short reference table of Webflow redirect special symbols (*, (.*), %1, %, etc.) and how each works? It’s handy to keep for future redirects.
1 Like
Ha ha ha it was funny to watch ChatGPT guessing as well.
As you pointed out, it would make sense if hyphens - were actually used as part of the matching expression as some form of range, like a-z works in regex. That’s partly why I’m suspicious that regex is being used under the hood- just just makes sense too.
But why certain characters are still not automatically escaped is a mystery and point to backwards compatibility or undocumented matching patterns.
Would be kind of fun to sic Webflow MCP on it- create 1000 matching patterns and test them to see if regex patterns can bleed through. I did something similar with CMS color fields and was shocked at how versatile they are.
1 Like