A wildcard redirect is a redirect rule that uses a pattern, typically represented by an asterisk (*), to match multiple URLs at once and forward them to a destination. Instead of defining a separate redirect rule for every individual URL, a wildcard rule captures an entire group of URLs matching a pattern and handles them all with a single rule.

The asterisk in a wildcard rule acts as a placeholder that matches anything. A rule defined for example.com/* matches every URL on that domain (e.g., example.com/about, example.com/blog/post-title, example.com/anything-at-all) and applies the same redirect to all of them. The power of wildcard redirects is that they can handle thousands or millions of URLs with a single rule, making them essential for large-scale redirect management.

How wildcard redirects work

A wildcard redirect rule has two components: a source pattern that defines which URLs the rule matches, and a destination that defines where matched URLs are sent.

The source pattern uses the asterisk as a wildcard character to represent any sequence of characters. When a request comes in, the server checks the requested URL against the pattern. If the URL matches, the redirect rule fires. If it does not match, the rule is skipped.

The simplest wildcard pattern is /*, matching every path on a domain. This is the foundation of a global redirect that sends all traffic on a domain to a single destination regardless of the path requested.

More specific patterns match subsets of URLs. A pattern like /blog/* matches every URL under the /blog/ path, example.com/blog/post-one, example.com/blog/post-two, while leaving all other paths unaffected. A pattern like /products/*/reviews matches any URL with a product identifier in the middle position: example.com/products/widget/reviews, example.com/products/gadget/reviews.

In more advanced implementations, the wildcard value, whatever the asterisk matched, can be captured and inserted into the destination URL. A rule matching olddomain.com/* with a destination of newdomain.com/* forwards olddomain.com/about to newdomain.com/about, olddomain.com/blog to newdomain.com/blog, and so on. This is path-preserving wildcard redirect behaviour and is significantly more powerful than sending all matched URLs to a fixed destination.

Wildcard redirects vs regex redirects

Wildcard redirects and regex redirects are related but differ in complexity and capability.

A wildcard redirect uses a simple * placeholder to match patterns. It is easy to read, easy to configure, and covers the majority of real-world redirect matching needs. The * matches any sequence of characters and the rule is straightforward to reason about.

A regex redirect uses regular expression syntax, a powerful pattern matching language, to define far more precise and complex matching rules. Regex can match specific character types, optional segments, numbered groups for capture and reuse, and patterns that would be impossible to express with a simple wildcard. For example a regex pattern could match only URLs where a segment contains exactly four digits, or only URLs where the path ends with a specific file extension.

The trade-off is complexity. Regex rules are harder to write, harder to read, and easier to get wrong. A subtle mistake in a regex pattern can match too broadly and redirect URLs that should not be redirected, or too narrowly and miss URLs that should be.

For the vast majority of redirect scenarios, domain migrations, domain parking, section-level redirects, wildcard rules are sufficient and preferable. Regex is the right tool when wildcard patterns cannot express the required matching logic precisely enough.

Common wildcard redirect use cases

Global redirect for domain parking - the most common wildcard use case. A single /* rule forwards all traffic from a parked or secondary domain to a primary destination. Every URL on olddomain.com, regardless of path, goes to newdomain.com. Simple to configure, zero maintenance, handles any URL that arrives on the domain.

Domain migration with path preservation: a path-preserving wildcard rule maps olddomain.com/* to newdomain.com/*, forwarding every URL on the old domain to the equivalent URL on the new domain. This preserves path-level link juice from backlinks pointing to specific pages on the old domain without needing to define individual rules for every page.

Section-level redirects: a wildcard rule matching /old-section/* forwards every URL under an old section of a site to a new section, handling the entire restructure with one rule rather than mapping every page individually.

Subdomain redirects: a wildcard rule matching *.olddomain.com forwards all subdomains of the old domain to equivalent destinations on the new domain.

Handling paginated URLs: a wildcard pattern matching /category/*/page/* can capture all paginated URLs in a category structure and forward them to appropriate destinations when pagination is being restructured.

File extension changes: when a site migrates from one technology to another and URL file extensions change - from .php to no extension, for example a wildcard pattern matching /*.php can forward all old-format URLs to their clean equivalents.

Wildcard redirects and SEO

Wildcard redirects are a powerful tool for preserving SEO equity at scale but require careful configuration to work correctly.

Path preservation matters: a wildcard rule that sends all traffic to a single destination homepage rather than preserving paths loses the path-level link juice from backlinks pointing to specific pages. A backlink to olddomain.com/specific-post carries more value when forwarded to newdomain.com/specific-post than when forwarded to newdomain.com. Where the old domain’s URL structure maps to the new domain, always use path-preserving wildcard rules.

Status code choice: as with all redirects, the HTTP status code determines how search engines treat the redirect. A wildcard rule using a 301 transfers SEO equity from matched URLs to their destinations. A wildcard rule using a 302 does not. For permanent domain changes, always use 301.

Crawl budget efficiency: wildcard redirects on large domains with many URLs can generate significant crawl activity as Googlebot follows each redirect. Ensuring wildcard rules resolve in a single hop to a 200 OK destination keeps crawl budget usage efficient.

Avoiding over-broad rules: a wildcard rule that is too broad can accidentally redirect URLs that should not be redirected. A rule matching /* on an active domain redirects everything including URLs that are still serving live content. Always scope wildcard rules precisely to the URLs they are intended to cover.

Wildcard redirects and redirect loops

Wildcard redirects are one of the most common sources of redirect loops because their broad matching can accidentally catch their own destination URLs.

The classic scenario: a wildcard rule on example.com matching /* redirects all traffic to newdomain.com. But newdomain.com has a wildcard rule redirecting back to example.com. The two rules create a loop between the domains.

A subtler scenario: a wildcard rule matching /* on example.com redirects to example.com/new-section/*. The destination URL is on the same domain. If the wildcard rule matches the destination URL as well as the source, the redirect fires on the destination too, creating a loop.

The fix in both cases is ensuring wildcard rules either explicitly exclude their destination patterns or are scoped narrowly enough that they cannot match URLs they are redirecting to.

Wildcard redirects and HTTPS

Wildcard redirects require the same HTTPS handling as any other redirect. For a wildcard rule on a domain to handle HTTPS traffic, that domain needs a valid SSL certificate - specifically a wildcard SSL certificate if the rule covers multiple subdomains.

A wildcard SSL certificate covers a domain and all of its subdomains (*.example.com) with a single certificate. This is distinct from a wildcard redirect, though the two are related in scenarios involving subdomain-level redirects. If a wildcard redirect rule needs to handle HTTPS connections across multiple subdomains, a wildcard SSL certificate ensures the connection is established securely before the redirect response is sent.

For path-level wildcard redirects on a single domain, the most common use case, a standard SSL certificate covering that domain is sufficient. Wildcard SSL is only needed when the redirect rule covers multiple subdomains.

Fallback redirects as wildcard redirects

A fallback redirect, sometimes called a catch-all redirect, is a specific application of wildcard redirect logic. It defines a destination for any URL that does not match a more specific redirect rule, preventing visitors from landing on a 404 error when no exact match exists.

In redirect management tools, a fallback rule typically uses a /* wildcard pattern with the lowest priority: it only fires when no other rule has already matched the requested URL. More specific rules, exact path matches, section-level wildcards, take precedence. The fallback catches everything else.

This is particularly useful during domain migrations where individual redirect rules cover the most important pages but a long tail of lower-traffic URLs may not have been mapped individually. The fallback ensures all of those unmapped URLs forward to a sensible destination rather than returning errors.

Ordering and priority in wildcard redirect rules

When multiple redirect rules are in place — some exact, some wildcard, the order in which they are evaluated matters. The standard convention is most specific first.

An exact match rule (example.com/about → newdomain.com/about-us) takes priority over a wildcard rule matching the same URL (example.com/* → newdomain.com). This allows specific exceptions to be defined within a broader wildcard pattern.

Without a defined evaluation order, conflicts between rules can produce unexpected redirect destinations. Most redirect management tools and server configurations evaluate rules in the order they are defined, with more specific rules placed before broader wildcard rules. Always verify that the intended rule fires for specific URLs when wildcard and exact rules overlap.

Common mistakes with wildcard redirects

Sending everything to the homepage: using a wildcard rule to forward all old domain traffic to the destination homepage rather than preserving paths. This loses path-level link juice from backlinks to specific pages. Use path-preserving rules where the URL structure allows.

Rules that catch their own destination: a wildcard rule that matches the URL it is redirecting to creates an instant redirect loop. Always verify that wildcard destination URLs cannot be matched by the same rule.

Overly broad patterns on active domains: applying a /* wildcard rule to a domain that is still serving live content redirects everything including pages that should remain accessible. Scope wildcard rules precisely.

Using 302 instead of 301 for permanent domain changes: a wildcard rule using a temporary redirect code does not transfer SEO equity. Always use 301 for permanent domain-level wildcard redirects.

Not testing edge cases: wildcard rules should be tested against a representative sample of URLs they are expected to match, including unusual paths, deeply nested URLs, and URLs with query strings, to verify the pattern behaves as intended across the full range of inputs.