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. This distinction matters in real-world projects. If you're migrating a site with 5,000 pages, writing 5,000 individual redirect rules is impractical. A handful of well-crafted wildcard rules can handle the same job in a fraction of the time.
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 all your old URLs to their new equivalents. Wildcard redirects for site migration make this manageable. Rather than mapping hundreds or thousands of pages individually, you can write rules that handle entire sections of the site at once.
For example, if you're moving from `olddomain.com` to `newdomain.com` and the URL structure stays the same, a single wildcard rule can redirect every page automatically. The rule captures the URL path from the old domain and appends it to the new domain. This preserves the destination page structure while moving all traffic to the new domain. Without wildcard redirects, you'd need to maintain a full URL-by-URL mapping file, which is error-prone and time-consuming to manage.
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
Wildcard subdomain redirect setup is useful when you have multiple subdomains that should all point to a single destination. For example, you might want `shop.example.com`, `store.example.com` and any other subdomain variation to redirect to `www.example.com/shop/`.
It's worth noting that server-level configuration must align with your DNS wildcard records for subdomain redirects to work correctly. A wildcard DNS record (such as `*.example.com`) must be in place before the server can receive and process requests for arbitrary subdomains. Without the DNS record, the traffic never reaches your server in the first place.
How to configure wildcard redirects
How wildcard redirects work in Apache
To understand how wildcard redirects work in Apache, you need to know how `mod_rewrite` processes rules. Apache uses `mod_rewrite` to evaluate incoming requests against a set of rewrite rules defined in your `.htaccess` file or server configuration. Each rule has a pattern and a substitution. When the pattern matches the request, the substitution is applied.
Here's a basic `htaccess` wildcard redirect example that redirects everything under `/old-section/` to `/new-section/`:
```apache
RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
```
The `(.*)` is a capture group that matches any characters after `/old-section/`. The `$1` in the destination inserts whatever was captured. The `R=301` flag tells Apache to send a 301 permanent redirect. The `L` flag stops processing further rules once this one matches.
For subdomain redirects in Apache, you'd typically handle these in the virtual host configuration rather than `.htaccess`. A wildcard virtual host can catch requests for any subdomain and redirect them accordingly:
```apache
<VirtualHost *:80>
ServerAlias *.example.com
RewriteEngine On
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
</VirtualHost>
```
Wildcard redirect Nginx configuration
Nginx uses a different syntax but follows similar logic. You define location blocks or server blocks with regex patterns to match incoming requests.
Here's a wildcard redirect Nginx configuration example for redirecting an old path structure to a new one:
```nginx
server {
listen 80;
server_name example.com;
rewrite ^/old-section/(.*)$ /new-section/$1 permanent;
}
```
The `permanent` keyword tells Nginx to issue a 301 redirect. For subdomain redirects, you'd use a wildcard `server_name` value:
```nginx
server {
listen 80;
server_name ~^(?<subdomain>.+)\.example\.com$;
return 301 https://www.example.com$request_uri;
}
```
This captures any subdomain and redirects all traffic to the main domain, preserving the original request URI.
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, in .htaccess, an Nginx config or a CDN dashboard. 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 uses partial path matching. 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 the wildcard migration rule earlier produces, without writing or testing a regex.
There is a real trade-off. Partial path matching is not a regex engine. If you need to rewrite the path itself, like stripping /YYYY/MM/ date segments out of /2024/03/post-title/ to reach /blog/post-title/, that still needs capture-group logic at the server or CDN level. What you give up in raw flexibility, you get back in safety: a path 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.
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: 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 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/. 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 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 the Apache and Nginx rules 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.
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, 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.
How do you set up a wildcard redirect in htaccess?
You use Apache's `mod_rewrite` module to set up wildcard redirects in `.htaccess`. A basic example looks like this: `RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]`. The `(.*)` captures everything after the matched path segment and the `$1` inserts it into the destination. Always test your rules in a staging environment before deploying to production.
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)
