How to Redirect One Domain to Another in Apache

Abdul Wahab Junaid

3 years ago

How to redirect one domain to another in Apache

I bought a slightly-too-clever domain name years ago, realized my mistake about six months later, and ended up buying the “correct” domain too. Rather than losing every visitor and every bit of SEO value from the old one, I set up a proper redirect. That experience taught me the different ways Apache can handle domain redirects, and when to use each one. In this post, I’ll walk through exactly how I redirect one domain to another using Apache.

What Domain Redirection Is and Why It Matters

Domain redirection tells browsers and search engines “the content you’re looking for has moved — go here instead.” Done correctly, it preserves SEO value, avoids broken links, and gives visitors a seamless experience. Done incorrectly, it can create redirect loops, lose search rankings, or leave visitors stuck on error pages.

I use domain redirects for:

Consolidating multiple domains (typos, old brand names) into one primary domain
Enforcing www vs non-www consistency
Migrating a site to a new domain after a rebrand
Redirecting HTTP to HTTPS as part of the same logic

Prerequisites

Apache installed with mod_rewrite and/or mod_alias enabled
Two domains pointing to the same server (or the redirecting domain pointing anywhere Apache can respond)
Root or sudo access
A basic understanding of HTTP status codes (301 vs 302)

Step 1: Choose the Right Redirect Type

This decision matters more than people think:

301 (Permanent Redirect) — tells browsers and search engines the move is permanent. Use this for real domain migrations; it passes along the vast majority of SEO ranking value.
302 (Temporary Redirect) — tells them this is temporary. Use this for short-term campaigns or maintenance, not permanent moves.

I default to 301 unless I have a specific reason to use 302.

Step 2: Simple Redirect Using mod_alias

For a straightforward, whole-domain redirect, I use the Redirect directive inside the old domain’s virtual host:

<VirtualHost *:80>
    ServerName old-domain.com
    ServerAlias www.old-domain.com
    Redirect permanent / https://new-domain.com/
</VirtualHost>

This sends every request to old-domain.com, regardless of path, to the root of new-domain.com. It’s fast, simple, and works for most “I just want everything to point to my new domain” scenarios.

Step 3: Redirect While Preserving the URL Path

If I want old-domain.com/blog/post-1 to land on new-domain.com/blog/post-1 instead of just the homepage, I use mod_rewrite instead:

<VirtualHost *:80>
    ServerName old-domain.com
    ServerAlias www.old-domain.com

    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
    RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</VirtualHost>

This preserves the entire path and query string automatically, which matters a lot for SEO — search engines much prefer a 1:1 mapping over everything funneling to the homepage.

First, I make sure mod_rewrite is enabled:

sudo a2enmod rewrite
sudo systemctl restart apache2

Step 4: Redirect www to non-www (or Vice Versa)

This is a very common variant of the same pattern — I decide on one canonical version and redirect the other:

<VirtualHost *:80>
    ServerName www.example.com

    RewriteEngine On
    RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</VirtualHost>

Step 5: Redirect HTTP to HTTPS Alongside the Domain Change

I often combine both redirects into a single rule set so visitors land on the secure, canonical domain in one hop instead of two:

<VirtualHost *:80>
    ServerName old-domain.com
    ServerAlias www.old-domain.com

    RewriteEngine On
    RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</VirtualHost>

Since this vhost only listens on port 80, and the target URL is https://, this handles both the domain change and the HTTPS upgrade in a single redirect — avoiding an unnecessary extra round trip.

Step 6: Test the Redirect

I always verify with curl, checking headers rather than trusting a visual browser check alone:

curl -I http://old-domain.com/some/page

I look for a 301 Moved Permanently (or 302 Found) status and a Location header pointing to the correct new URL.

Real-World Example: Migrating an Entire Blog to a New Domain

When I migrated a client’s blog from oldblog.com to newblog.com, I used the path-preserving mod_rewrite method so every single post URL mapped 1:1 to its new equivalent, rather than sending years of accumulated backlinks to a generic homepage. Within a few weeks, Google Search Console showed the new domain picking up ranking signals from the old one — a good sign the 301s were being properly recognized.

Step 7: Redirecting Specific Paths Only

Sometimes I don’t want to redirect an entire domain, just a handful of specific pages — for example, when a single blog post moved to a new site but the rest of the old domain should keep working normally. For this, I target individual paths rather than the whole domain:

RewriteEngine On
RewriteRule ^old-post-slug/?$ https://new-domain.com/new-post-slug [R=301,L]
RewriteRule ^another-old-page/?$ https://new-domain.com/another-new-page [R=301,L]

This lets the rest of the old domain continue operating unaffected while specific, individual URLs get redirected precisely where they need to go.

Step 8: Verifying Redirects Don’t Break Query Strings

A mistake I made once was setting up a redirect that dropped query string parameters, which broke a set of tracking links a client had been using in email campaigns for months. Now I explicitly test that query strings pass through correctly:

curl -I "http://old-domain.com/page?utm_source=newsletter"

If the Location header in the response doesn’t include the original query string, I add the QSA (Query String Append) flag to my rewrite rule to make sure it’s preserved:

RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L,QSA]

Troubleshooting Common Issues

Redirect loop (“too many redirects”) Usually caused by redirecting a domain to itself accidentally, or mixing an HTTP-to-HTTPS redirect with a domain redirect in a way that loops back. I check RewriteCond carefully to make sure it only matches the old domain, not the new one.

Redirect works in a browser but curl shows 200 OK This often means browser caching from a previous visit is masking the real response. I clear cache or test with curl -I for a clean check.

Only the homepage redirects, not other pages This is the classic symptom of using a simple Redirect directive when path-preserving mod_rewrite rules were actually needed.

SEO rankings drop after migration Confirm every redirect is a genuine 301, not a 302 — search engines treat these very differently in terms of passing ranking signals.

Security Best Practices

I avoid open redirects — never build a redirect target dynamically from unsanitized user input, since that’s a classic phishing vector.
I make sure the redirecting domain’s SSL certificate (if any) is still valid, so visitors aren’t hit with certificate warnings before the redirect even fires.
I keep DNS and Apache config in sync — if a domain is being fully retired, I still keep the redirect vhost alive rather than letting the domain go completely dead.

Performance Optimization Tips

I keep redirect rule sets minimal and specific — broad regex patterns evaluated on every request add unnecessary overhead.
For single, unconditional redirects, Redirect permanent (mod_alias) is slightly lighter weight than mod_rewrite, since it skips the regex engine entirely.
I avoid chaining multiple redirects (domain A → domain B → domain C) — each hop adds latency and can lose SEO value.

Step 9: Monitoring Redirects with Search Console After Launch

After a domain migration goes live, I don’t just consider the job done once the redirect works technically — I keep an eye on Google Search Console for the old domain over the following weeks, watching for crawl errors or a sudden spike in reported redirect issues. I also submit an updated sitemap for the new domain and use the “Change of Address” tool in Search Console, which explicitly tells Google about the migration rather than making it infer the change purely from encountering 301s during normal crawling.

Step 10: Keeping the Old Domain Registered

A mistake I’ve seen other people make — thankfully not one I’ve made myself — is letting the old domain’s registration lapse a few months after migration, once traffic seems to have moved over. Search engines and old backlinks can keep sending traffic to that domain for years, so I always recommend keeping the old domain registered and the redirect vhost active indefinitely, even long after the migration feels “complete.”

Frequently Asked Questions

What’s the difference between Redirect and RewriteRule? Redirect (from mod_alias) is simpler and best for whole-domain or whole-path redirects. RewriteRule (from mod_rewrite) supports pattern matching and path preservation, which is usually what you want for real migrations.

Will a 301 redirect pass my SEO rankings to the new domain? Generally yes, though it can take search engines time (weeks to months) to fully re-index and transfer signal.

Can I redirect just one specific page instead of the whole domain? Yes — use a specific Redirect or RewriteRule targeting that exact path instead of a catch-all pattern.

Do I need mod_rewrite for a simple domain redirect? No, mod_alias‘s Redirect directive is enough if you don’t need to preserve individual URL paths.

Summary and Key Takeaways

Redirecting one domain to another in Apache comes down to choosing the right tool for the job: mod_alias for simple whole-site redirects, mod_rewrite when you need to preserve paths, and always using a 301 for permanent moves. Testing with curl -I rather than relying on browser caching gives me confidence the redirect is actually behaving the way I expect before I consider the migration complete.