Wildcard Redirects: When and How to Use Them

You have a bunch of subdomains that all need to redirect to the same destination. Or you don't know exactly how many subdomains exist because users create them dynamically. Creating individual redirect rules for each one isn't practical. A wildcard redirect handles all of them with a single rule.

This guide covers when wildcards are the right approach, how to configure DNS for wildcard redirects, and how to handle SSL certificates for subdomains you haven't created yet. For redirect fundamentals and setup guidance, see our Complete Guide to URL Redirects.

Key Takeaways

• Wildcards (*.domain.com) match any subdomain with one rule - ideal for consolidation and multi-tenant migrations
• The apex domain needs its own record - wildcards only match subdomains, not domain.com itself
• SSL options: per-subdomain certificates (auto-provisioned on first visit) or wildcard certificates (requires DNS delegation)
• Explicit DNS records override wildcards - use this for exceptions that shouldn't redirect
• Test systematically: known subdomains, random subdomains, apex domain, www, and HTTPS for each

When Wildcard Redirects Make Sense

A wildcard redirect matches any subdomain and applies the same redirect logic to all of them. Instead of creating rules for blog.old.com, shop.old.com, and help.old.com individually, you create one rule for *.old.com that catches everything.

Subdomain consolidation

You're shutting down an old domain and moving everything to a new one. The old domain has accumulated subdomains over the years: blog.old.com, shop.old.com, help.old.com, staging.old.com, and probably others you've forgotten about.

A wildcard redirect (*.old.com to new.com) handles all of them, including subdomains you don't know exist. When someone visits forgotten-campaign.old.com six months from now, the redirect still works.

Multi-tenant platform migration

Your SaaS platform gives each customer their own subdomain: customer1.platform.com, customer2.platform.com, and so on. You're migrating to a new domain and need all customer subdomains to redirect to equivalent subdomains on the new domain.

Some redirect services support dynamic subdomain mapping: *.platform.com can redirect to *.newplatform.com, preserving the subdomain name. This is more advanced functionality than a basic wildcard. If your service doesn't support it, you may need individual rules for each customer, or redirect all customer subdomains to a single destination (newplatform.com) and handle routing there.

Regional subdomain consolidation

Your brand uses regional subdomains: nl.brand.com, de.brand.com, fr.brand.com. You're consolidating to a single domain with path-based regions: brand.com/nl/, brand.com/de/, brand.com/fr/.

If your redirect service supports variable substitution (mapping the subdomain to part of the destination path), a single wildcard rule can handle this. If not, you'll need individual redirect rules for each region, but that's still simpler than managing ongoing DNS records for each regional subdomain.

When NOT to use wildcards

Wildcards apply the same logic to every subdomain. They're the wrong choice when:

Different subdomains need different destinations. If blog.old.com should go to newblog.com but shop.old.com should go to newshop.com, you need individual rules.

Some subdomains should remain active. If you're keeping staging.old.com running while redirecting everything else, a wildcard would incorrectly redirect your staging environment.

Path mapping differs per subdomain. If blog.old.com/post needs to become new.com/blog/post but shop.old.com/product needs to become new.com/products/item, the logic is too different for a single wildcard rule.

The decision is simple: if all subdomains follow the same redirect pattern, use a wildcard. If they don't, use individual rules.

DNS Configuration for Wildcards

Wildcard redirects require specific DNS records. The setup differs slightly from standard domain redirects. For a deeper comparison of DNS-level versus server-side approaches, see DNS-Level vs Server-Side Redirects.

The wildcard record

A wildcard DNS record uses an asterisk (*) as the subdomain:

*   300   IN  A   203.0.113.50

This record matches any subdomain that doesn't have its own explicit DNS record.

The apex domain needs its own record

Here's a common mistake: assuming the wildcard covers everything. It doesn't. A wildcard record (*.domain.com) matches subdomains, but it does NOT match the apex domain (domain.com) itself.

You need two records:

@   300   IN  A   203.0.113.50
*   300   IN  A   203.0.113.50

The @ record handles domain.com. The * record handles any subdomain (blog.domain.com, shop.domain.com, anything.domain.com).

Explicit records override wildcards

If you create an explicit A record for blog.domain.com, that record takes priority over the wildcard. DNS resolvers always prefer specific matches over wildcards.

This is useful when you need exceptions. Want to redirect all subdomains except one? Create individual DNS records for the exceptions pointing elsewhere, and let the wildcard handle everything else.

SSL Certificates for Wildcard Subdomains

HTTPS requires a valid SSL certificate for every subdomain. With wildcards, you're redirecting subdomains that might not exist yet. How do you get certificates for domains you can't predict? For background on why SSL matters for redirects, see How to Redirect with HTTPS.

Option 1: Per-subdomain certificates on demand

Some redirect services provision individual certificates for each subdomain when traffic first arrives. The first HTTPS visitor to any-subdomain.domain.com triggers certificate generation. This typically takes a few seconds to a few minutes. During this window, visitors may see a certificate error until provisioning completes.

Advantage: no special DNS setup required beyond the wildcard A record. Each subdomain gets its own certificate automatically.

Disadvantage: the first HTTPS visitor to a new subdomain may encounter a certificate error while the certificate is being provisioned. HTTP traffic (without the S) works immediately.

Option 2: Wildcard certificates

A wildcard SSL certificate covers all subdomains under a domain. One certificate for *.domain.com handles blog.domain.com, shop.domain.com, and any other subdomain, including ones that don't exist yet.

The catch: Let's Encrypt (the most common certificate authority for automated provisioning) requires DNS-based validation for wildcard certificates. This means proving you control the domain by creating a specific DNS TXT record.

For automated wildcard certificate provisioning, the redirect service needs the ability to create DNS records on your behalf. This typically requires delegating a specific subdomain to the service's nameservers:

_acme-challenge   IN  NS   ns1.redirectservice.com.

This NS record delegates control of _acme-challenge.domain.com to the redirect service, allowing them to complete the DNS validation required for wildcard certificates.

Which option to choose

Per-subdomain certificates work well when you have a manageable number of subdomains and can accept that the first HTTPS visitor to a new subdomain may see a certificate error. No special DNS configuration required.

Wildcard certificates work better when you have many subdomains, subdomains are created dynamically, or you can't tolerate any certificate errors on first visits. Requires the NS record delegation for ACME challenges.

Check your redirect service's documentation for which approach they support and what DNS configuration they require.

Testing Wildcard Redirects

Wildcards are harder to test than individual redirects because you're testing a pattern, not a specific URL. A systematic approach catches problems before they affect users.

Before changing DNS

If possible, test the redirect configuration before pointing DNS to the redirect service. Some services offer a preview or test mode. If yours doesn't, you can test locally by adding entries to your hosts file:

1. Find the redirect service's IP address
2. Add entries to your hosts file for a few test subdomains:

123.45.67.89 test1.olddomain.com
123.45.67.89 test2.olddomain.com
123.45.67.89 random.olddomain.com

3. Visit those URLs in your browser (HTTP first)
4. Remove the hosts entries when done

This only affects your local machine and lets you verify the redirect works before making public DNS changes. Note that HTTPS testing via hosts file may show certificate errors because the certificate was provisioned for the real DNS, not your local override.

After changing DNS

Once DNS is live, test systematically:

Test a known subdomain that existed before the migration. Verify it redirects to the correct destination.

Test a random subdomain that never existed. Make up something like test-wildcard-xyz.olddomain.com. If the wildcard is working, this should redirect correctly even though you never created a rule for it.

Test the apex domain (olddomain.com without any subdomain). Remember, wildcards don't cover the apex. Verify your @ record is working.

Test www specifically. Many users type www.olddomain.com. The wildcard record covers www (it's just another subdomain), but verify the redirect destination is correct. If you have an explicit www record from before the migration, it will override the wildcard and may point to the wrong place.

Test HTTPS for all of the above. Certificate issues often only appear on HTTPS. Verify there are no certificate warnings for any subdomain you test.

What to check

For each test URL, verify:

• The redirect happens (you land on the new domain, not an error page)
• The status code is correct (301 for permanent redirects)
• The destination URL is correct (especially if you're preserving paths or mapping subdomains to paths)
• HTTPS works without certificate warnings

Path and Query String Handling

Wildcards redirect the domain, but what happens to the rest of the URL?

Path forwarding

If someone visits blog.old.com/my-post-title, do they land on new.com or new.com/my-post-title?

With path forwarding enabled:blog.old.com/my-post-title redirects to new.com/my-post-title (path preserved).

With path forwarding disabled:blog.old.com/my-post-title redirects to new.com (path lost).

For most migrations, you want path forwarding enabled so deep links continue working.

Query string forwarding

If someone visits shop.old.com/product?id=123&utm_source=email, do the query parameters survive the redirect?

With query forwarding enabled: the full query string (?id=123&utm_source=email) is appended to the destination URL.

With query forwarding disabled: query parameters are stripped and lost.

For any site using analytics tracking (UTM parameters) or dynamic URLs (product IDs, search queries), enable query forwarding. Track these metrics after migration using redirect analytics.

Subdomain-to-path mapping

Some redirect services support dynamic destination URLs where the subdomain becomes part of the path:

nl.brand.com  redirects to  brand.com/nl/
de.brand.com  redirects to  brand.com/de/

This requires the redirect service to support variable substitution in the destination URL. Check your service's documentation for the specific syntax (often $1 or similar placeholder notation).

Frequently Asked Questions

Related Guides

• Redirect Troubleshooting - Fix common issues if your wildcard redirect isn't working
• DNS-Level vs Server-Side Redirects - Why DNS-based wildcards differ from server config
• How to Redirect with HTTPS - SSL certificate handling for secure redirects
• Domain Migration Guide - Complete checklist for large-scale migrations

Ready to Redirect?

redirect.pizza supports wildcard redirects with automatic SSL certificate provisioning. View pricing to see wildcard availability on different tiers, or get started for free to test with individual domains first.