Wildcard redirects are a powerful tool for managing large numbers of URL changes at once. Rather than writing a separate rule for every URL, wildcard redirects use patterns to match groups of URLs. You can redirect all of them to new destinations with a single rule. This saves significant time during site migrations, URL restructuring and subdomain changes. It also helps protect your SEO by ensuring traffic and link equity aren't lost in the process.
What is a wildcard redirect?
A wildcard redirect uses pattern matching to capture multiple URLs under a single redirect rule. Instead of specifying an exact URL to redirect, you define a pattern that matches a range of URLs. Any URL fitting that pattern gets redirected to a specified destination.
These patterns are typically written using regular expressions (regex) or simplified wildcard syntax depending on your server or platform. The asterisk (`*`) is the most common wildcard character, representing any sequence of characters. More advanced configurations use full regex syntax, which gives you much finer control over what gets matched and where it goes.
How wildcard redirects differ from standard redirects
A standard redirect maps one specific URL to another. You define the source and destination explicitly and the rule only fires when that exact URL is requested. This works well for individual pages but becomes impractical at scale.
Wildcard redirects match patterns rather than exact URLs. The distinction matters most during a migration. Say you're moving a site with 5,000 pages. You could write 5,000 individual rules, and if you want every old page to land on its exact counterpart on the new site, that is what you have to do. One-to-one redirects always give users and search engines the best experience, because every request resolves to the page that actually replaces it.
The real question is whether that precision is necessary. Often it isn't. When a group of pages doesn't need to map to specific destinations, a wildcard can send the whole group to a single place, so every request for an old blog post lands on the new blog home page instead of a matching article. A handful of wildcard rules cover the same ground as thousands of individual ones and save the work of writing them. The tradeoff is precision for effort, so the choice comes down to whether each page needs its own destination or the group can share one.
You can also use capture groups in the pattern to carry part of the original URL through to the destination. This means you can redirect `/old-blog/post-title/` to `/new-blog/post-title/` dynamically, without knowing every post title in advance.
When to use wildcard redirects
Wildcard redirects are best suited to situations where a predictable group of URLs needs to move to a new location or follow a new structure. Here are the most common scenarios.
Site migrations
When you move a site to a new domain, you need to redirect your old URLs to their new equivalents. Wildcard redirects for site migration can make this manageable, but only when the new site's URLs follow a structure similar to the old one. If /blog/post-name on the old domain maps cleanly to /blog/post-name on the new one, a single wildcard rule can carry the whole section across and every page still lands where the user expects. When the structure has changed, a wildcard can't know where each page should go, so it points the group at one shared destination and individual pages lose their exact match.
That is the real test, and it is about the visitor, not the person writing the rules. Wildcards save the implementer a great deal of work, but that saving only counts when it doesn't come at the user's expense. If the URL structures line up, a handful of rules handle entire sections at once and the experience holds. If they don't, the question is whether sending a group of pages to one place still serves the visitor, not whether it is easier to configure.
The mechanics are simple. A wildcard rule captures the URL path from the old domain and appends it to the new one, so olddomain.com/blog/post-name lands on newdomain.com/blog/post-name without a rule for each page. It preserves the path structure while moving all traffic across. The alternative is a full URL-by-URL mapping file, which is slow to build and easy to get wrong across thousands of rows, though it is the tradeoff you accept when the new structure doesn't match and each page needs its own destination.
URL restructuring
Sites often change their URL structures over time. A blog might move from `/year/month/post-title/` to `/blog/post-title/`. Rather than writing individual rules for every post, you can write a pattern-based redirect that strips the date components and maps the slug to the new path.
Here's a basic example of the pattern logic:
```
/YYYY/MM/post-title/ → /blog/post-title/
```
A wildcard rule can capture the final slug segment from the old URL and pass it directly to the new path.
Subdomain management
A wildcard subdomain redirect points every subdomain of a domain at a single destination, so shop.example.com, store.example.com and any other variation all resolve to [www.example.com/shop/](https://www.example.com/shop/). It is technically possible, but it is a rare thing to actually want, and worth approaching with caution before you reach for it.
The reason is that a wildcard at the root of a registrable domain matches everything, including subdomains you never intended to create or redirect. That broad match is the whole mechanism, and it is also the risk: it frequently catches traffic you didn't mean to catch and produces consequences you didn't plan for. Most teams are better served by redirecting the specific subdomains they use than by pointing a wildcard at all of them.
If you do have a genuine case for it, the setup depends on DNS. A wildcard DNS record such as *.example.com must be in place before the server can receive requests for arbitrary subdomains, and the server-level configuration has to align with it. Without the DNS record, the traffic never reaches your server in the first place, so the redirect never runs.
How to configure wildcard redirects via CDN and platform-level redirects
Many modern hosting platforms and CDNs allow you to define wildcard redirect rules through their dashboards or configuration files. Netlify, Vercel and Cloudflare all support pattern-based redirects without requiring direct server access.
For example, in a Netlify `_redirects` file:
```
/old-section/* /new-section/:splat 301
```
The `:splat` variable captures everything matched by the `*` wildcard and inserts it into the destination. This is a simplified but powerful alternative to writing full regex rules.
Wildcard redirects for SEO
Getting wildcard redirects right matters for SEO. Done poorly, they can cause ranking drops that are difficult to recover from. Here's what you should keep in mind.
Use 301 for permanent changes.
A 301 status code tells search engines the move is permanent. This passes link equity from the old URL to the new one. Use 302 only when the redirect is genuinely temporary.
Match old URLs to the most relevant new URL.
Search engines reward relevance. If you redirect an old product category page to a homepage using a wildcard rule, you lose the topical relevance that was associated with the original URL. Try to map old URLs to the closest equivalent new destination.
Avoid redirect chains.
If your wildcard rule sends traffic to a URL that already has another redirect on it, you create a chain. Long chains slow crawling and add latency and each extra hop is another step search engines and browsers must follow before reaching the final URL. You should audit your existing redirects before adding new wildcard rules.
Don't send everything to the homepage.
Wildcard redirects can be tempting to abuse. One of the most common mistakes we see during migrations is sending all unmatched URLs to the homepage. Search engines interpret this as a soft 404, which can cause those URLs to lose their rankings entirely.
Testing and validating wildcard redirects
Skipping testing is one of the most common mistakes people make when deploying wildcard redirects. A misconfigured rule can match URLs you didn't intend to capture, create redirect loops or break important pages entirely. We recommend always validating your rules before they go live.
Use a staging environment.
Apply your redirect rules to a staging version of the site first. Test a representative sample of URLs that should be matched and verify that they land on the correct destination.
Test near-matches.
Think about URLs that are similar to your pattern but shouldn't be matched. Make sure your rules aren't too broad and encompassing URLs that they shouldn’t.
Check for redirect loops.
A redirect loop happens when the destination of a redirect matches the same pattern as the source. This causes an infinite loop that results in a browser error. Tools like `curl` or browser developer tools can help you spot these quickly.
Run a post-deployment crawl.
We recommend running a crawl with a tool like Screaming Frog after deploying new redirect rules. This helps you catch any unexpected behavior across a wider range of URLs before it affects your rankings or user experience.
A simpler alternative: partial path matching
Everything above assumes you write and maintain the rules yourself. That is fine when you have server access and someone comfortable with regex. It is a poor fit when a marketing or SEO team needs to move a group of URLs without filing an engineering ticket or when a single stray pattern taking down live pages is a risk you cannot take.
Managed redirect platforms handle the same jobs differently. Rather than raw wildcard patterns, urllo supports partial path matching and path forwarding. Instead of matching the exact, full URL, you match on part of the path, so a whole group of URLs can share one rule. Combined with path forwarding and query parameter forwarding, the path and query string can carry through to the destination, which is what most migrations and restructures actually need.
Take a simple case, moving an old URL structure such as example.com/news/** to a dedicated subdomain such as news.destination.com/**. Nothing has to be mapped by hand. This is the same outcome as the wildcard migration rule earlier produces, without writing or testing a regex.
Partial path matching handles more than it first appears. It is not a regex engine, but many jobs that look like they need one don't. Stripping /2024/03/ date segments off /2024/03/post-title/ to reach /blog/post-title/ is a good example: you mark /2024/03/ as the fixed section, point the rule at /blog/ and let path forwarding carry post-title/ across. urllo does this with partial path matching and forwarding, no regex to write or test. And because there is no pattern to construct, the match is much harder to accidentally make too broad and much less likely to produce the loops and soft 404s that the sections above warn about, so you get the reshaping without the failure surface.
For teams moving or restructuring URLs across many domains, that is often the better trade. The rules stay readable; they do not need server access and SSL and DNS sit in the same place as the redirects.
Wildcard matching vs partial path matching
Both approaches solve the same problem and urllo offers both natively: move a whole group of URLs with one rule instead of writing a rule per URL. Carrying the rest of the URL through is not automatic. With path and query forwarding switched on, the path tail and query string land on the destination unchanged, which handles the two most common jobs cleanly: a same-structure domain move and consolidating a section under a new prefix.
The difference between the two is control versus safety. A wildcard is a regex engine, so it can reach into the path and rewrite it, like stripping /2024/03/ out of /2024/03/post-title/ to reach /blog/post-title/. urllo gives you that capability without a server config file, so the reshaping power is available to you directly. That power is also where the risk lives: an over-broad pattern is what produces the loops and soft 404s described above.
Partial path matching is urllo's second tool, and it gives up the path-rewriting to remove that failure surface. You mark the fixed part of the path and place ** where the variable section begins, and the rule matches on that section without any regex to write or test. With path or query forwarding enabled, whatever the ** captures carries to the destination. Because there is no pattern to construct or debug, a marketing or SEO team can run it without server access or an engineering ticket.
There is a performance dimension too. Partial path matching is a literal comparison, so its cost stays low and predictable no matter what the incoming URL looks like. A regex-based wildcard, like above, runs through a backtracking engine such as PCRE, where evaluation time depends on both the pattern and the input, and a poorly formed pattern can tip into catastrophic backtracking, where the time to match a single URL climbs exponentially as the string gets longer.
That is not a lab-only concern at the edge. On July 2nd 2019, a single badly written regex in a Cloudflare firewall rule triggered catastrophic backtracking that drove CPU to nearly 100 percent across its global network and took the service down for 27 minutes. Redirects run on that same request path, so a runaway pattern does not just misroute one URL; it can slow every request sitting behind it.
Choose wildcard when the destination path is genuinely different from the source and you need capture-group logic to reshape it. Choose partial path matching when the paths line up either at the beginning or end of the URL and you need the move done safely. Both live in the same product, so the choice is which tool fits the job, not which vendor to reach for.
Partial path matching with urllo
Wildcard redirects are one of the most efficient tools available for managing URL changes at scale in a URL redirect tool. When you configure them correctly, users and search engines follow the redirect without any friction or ranking disruption. When configured incorrectly, a single bad rule can create loops, misguide traffic and cause ranking drops that take time to recover from.
Of all the steps involved, testing is where most issues are caught. Deploy to staging first, crawl a sample of URLs and check your redirect chains before anything goes live. That single habit will save you from the majority of problems that wildcard redirects can introduce.
If you’re looking for a platform to create and manage your redirects, consider urllo. urllo, previously EasyRedir, has managed redirects since 2014. More than 1,000 companies across 75+ countries rely on it, from small teams through to enterprises. urllo handles over 25 billion requests a year.
We cover common migration and restructuring cases through partial path matching and path forwarding, with SSL, DNS and the redirect rules in one place. You can try it on your own domain on a 14-day free trial with no credit card.
Frequently asked questions about wildcard redirects
What is a wildcard redirect?
A wildcard redirect is a redirect rule that uses a pattern to match multiple URLs at once. Rather than defining a source and destination for each individual URL, you write a rule that captures any URL matching the pattern. This means you can handle large numbers of redirects with just one rule.
How do wildcard redirects affect SEO?
When you implement wildcard redirects correctly with 301 status codes, you pass link equity from old URLs to new ones. This helps you preserve rankings during site migrations and URL restructuring. The key is making sure each old URL maps to the most relevant new destination rather than sending everything to a generic page like the homepage.
What is the difference between a wildcard redirect and a regular redirect?
A regular redirect maps one specific URL to one specific destination. A wildcard redirect uses a pattern to match a range of URLs and redirect all of them in a single rule. Wildcard redirects are far more efficient when you're dealing with large numbers of URLs that follow a predictable structure.
Can wildcard redirects cause redirect loops?
Yes, they can. A redirect loop happens when the destination URL matches the same pattern as the source, causing the server to keep redirecting indefinitely. You should always test your rules with tools like `curl` or browser developer tools to verify the response chain before deploying. Staging environments are particularly useful for catching loops before they affect live traffic.
When should you use wildcard redirects instead of individual redirects?
You should use wildcard redirects when you have a large number of URLs that follow a consistent pattern and all need to move to a predictable new location. Site migrations, URL restructuring and subdomain consolidation are the most common use cases. If you only need to redirect a handful of specific pages, individual redirects are simpler and easier to maintain.
Does urllo support wildcard redirects?
Not in the regex sense. urllo uses partial path matching rather than wildcard patterns. You match on part of a path and, with path forwarding, the rest carries through to the destination. That handles the common jobs, section moves and same-structure domain migrations without hand-written regex. For redirects that transform the path structure itself, you would still use server or CDN rules.
By Shannon Young
Customer Success Manager
Shannon is a seasoned professional in the customer success space. She has years of experience in a wide variety of customer-facing roles in various sectors.
Always ready to take on the next challenge, whether it be a new offensive cross stitch pattern or making her dogs sit still for another themed photo, she is prepared for anything.
.png&w=2560&q=88)
