Mastering Domain Redirects: Using Wildcards in .htaccess for Multi-Domain Changes

Dealing with domain migrations and SEO redirects is a common pain point for site owners. As you’ve experienced, manually writing dozens of RewriteCond and RewriteRule blocks for every URL variation becomes tedious, error-prone, and frankly, silly when dealing with many changes. The desire to use a single wildcard expression to handle complex rules efficiently is completely understandable.

The core challenge here isn't just replacing strings; it’s ensuring that the redirect adheres strictly to SEO best practices (301 status code) while handling variations like www prefixes and specific TLDs (.co.uk). While simple, generic wildcards like (.*) are powerful, they need careful context when applied to hostnames in .htaccess files.

Why Simple Wildcards Fall Short for Host Redirection

You proposed a pattern like (.*)example-old(.*) = www.example-new.co.uk. While this looks concise, applying it directly to the RewriteRule structure often fails because the conditions (RewriteCond) need to precisely match the current request's host header (%{HTTP_HOST}).

The issue with using a broad wildcard is that you lose the specificity needed for reliable server-side redirection. You need to explicitly check what the user requested versus what the server currently hosts, ensuring that only the intended old domain maps to the new one according to your precise rules.

The Robust Solution: Specificity Over Generality

Instead of relying on a single overly broad wildcard, the most robust approach for managing multiple specific redirects is to use targeted RewriteCond checks. This method provides maximum control and clarity, which is essential when SEO consequences are involved.

For dynamic domain changes, you should structure your rules to check for the existence of old hostnames and explicitly map them to the new destination. This keeps the logic clean and debuggable, regardless of how many domains you manage.

Here is a template demonstrating how you can consolidate these checks efficiently, ensuring both www and non-www versions are handled correctly for any given domain transition:

# Redirect 1: Handle www to non-www (or vice versa) for the old domain structure
  RewriteCond %{HTTP_HOST} ^www\.example\.co\.uk$ [OR]
  RewriteCond %{HTTP_HOST} ^example.co.uk$
  RewriteRule ^(.*)$ https://www.example-new.co.uk/$3 [L,R=301]
  
  # Redirect 2: Handle specific subdirectories if necessary (e.g., for /directory)
  RewriteCond %{HTTP_HOST} ^example\.co\.uk$
  RewriteRule ^directory(/.*)?$ https://www.example-new.co.uk/directory/ [L,R=301]
  
  # Further rules would follow for other domains...
  

As a senior developer, I always emphasize that while powerful tools like the one provided by Laravel are fantastic for application logic, server configuration like this requires meticulous attention to detail on the web server level. When configuring complex routing or redirects, understanding how parameters interact is key—a principle that applies equally to building robust applications and managing infrastructure. For scalable architecture, ensuring your routing logic is sound is paramount.

By focusing on precise RewriteCond statements that check the exact value of %{HTTP_HOST}, you eliminate ambiguity. You are not just using a wildcard; you are using pattern matching to enforce specific migration policies across your entire site structure. This approach ensures that every request is correctly identified and redirected according to your desired destination, satisfying all three criteria: always pointing to www, handling the TLD variations, and ensuring a proper 301 change.

Stefan

SEO engineer and Laravel developer. Building tools to help Laravel applications rank higher in search results.