There are common scenarios where you need to redirect one domain to another: consolidating multiple domains into one, migrating a site to a new domain name, or redirecting a retired domain to its replacement so existing links and bookmarks don’t break. Apache’s Before you set up domain redirection with .htaccess, make sure you have:<\/p>\n\n\n\n Before editing any files, it helps to understand what actually happens when a redirect rule fires:<\/p>\n\n\n\n This matters because a Domain redirection via Look for On Ubuntu\/Debian:<\/strong><\/p>\n\n\n\n On CentOS\/RHEL<\/strong>, Then restart Apache:<\/p>\n\n\n\n You’ll need to know the correct document root to place or edit the On a cPanel server:<\/strong><\/p>\n\n\n\n On a plain Ubuntu server:<\/strong><\/p>\n\n\n\n Alternatively, confirm the exact document root Apache is actually using for a specific virtual host with:<\/p>\n\n\n\n This lists all configured virtual hosts along with their document root paths \u2014 useful when a server hosts multiple domains and you need to be certain you’re editing the right one.<\/p>\n\n\n\n This step is easy to overlook, and its absence is one of the most common reasons a correctly written redirect rule silently does nothing. By default, some Apache configurations set Check your virtual host or Apache configuration file for the relevant If you had to change this, restart Apache to apply it:<\/p>\n\n\n\n (Substitute Navigate to the document root you identified in Step IV, and open (or create) the Here’s a corrected, complete version of the redirect rule. A commonly seen mistake in quick-reference examples is missing the What each line does:<\/strong><\/p>\n\n\n\n Note on HTTPS:<\/strong> The example above hardcodes Replace Save the file, then test it in a browser by visiting:<\/p>\n\n\n\n and<\/p>\n\n\n\n Both should automatically redirect to Tip:<\/strong> Browsers aggressively cache 301 redirects. If you’re testing changes and not seeing the expected behavior, test in a private\/incognito window or clear your browser cache to rule out a stale cached redirect from a previous test.<\/p>\n<\/blockquote>\n\n\n\n Redirect only a specific subdirectory, not the whole domain:<\/strong><\/p>\n\n\n\n Redirect everything to a single fixed URL, without preserving the path:<\/strong><\/p>\n\n\n\n Redirect non-www to www on the same domain (a common companion rule):<\/strong><\/p>\n\n\n\n The redirect doesn’t happen at all, and no error appears:<\/strong> This is almost always the “Internal Server Error” (500) after adding the rule:<\/strong> Check Apache’s error log for specifics:<\/p>\n\n\n\n (Path may differ on CentOS \u2014 commonly The redirect works but creates a redirect loop:<\/strong> This typically happens when the new domain’s own The path isn’t preserved after redirecting:<\/strong> Confirm you’re using Once traffic is redirecting to the new domain, it’s worth also confirming the new domain itself forces HTTPS, rather than allowing HTTP access to remain available alongside it. Add this rule to the new domain’s own This checks whether the request arrived over plain HTTP ( Note:<\/strong> If you already handle HTTP-to-HTTPS redirection elsewhere \u2014 for example, in your Apache virtual host configuration or via a reverse proxy\/load balancer in front of Apache \u2014 adding this same logic again in Setting up domain redirection with For the complete reference on Apache’s rewrite syntax and available flags, see the official mod_rewrite documentation<\/a>.<\/p>\n\n\n\n Why doesn’t my redirect rule work even though the syntax looks correct?<\/strong> The two most common causes are a missing Should I redirect at the .htaccess level or in the main Apache virtual host configuration?<\/strong> Both work, but placing rewrite rules directly in the virtual host configuration (rather than Will this redirect preserve query strings, like ?ref=email?<\/strong> Not by default with the examples shown here \u2014 you’d need to add the Can I redirect multiple old domains to the same new domain?<\/strong> Yes \u2014 adjust the What’s the difference between RewriteRule and the simpler Redirect directive?<\/strong> If you have any questions about this setup or run into an issue not covered here, feel free to reach out to us at Pheonix Solutions<\/a> \u2014 we’re happy to help.<\/p>\n\n\n\n Related Articles:<\/p>\n\n\n\n.htaccess<\/code> file, combined with the mod_rewrite<\/code> module, is the standard way to handle this at the web server level.<\/p>\n\n\n\n
\n\n\n\nImplementation<\/h2>\n\n\n\n
I. Prerequisites<\/h3>\n\n\n\n
\n
mod_rewrite<\/code> module available (verified in Step III)<\/li>\n<\/ul>\n\n\n\nII. Architecture Overview<\/h3>\n\n\n\n
\n
domain.com<\/code><\/li>\n\n\n\n.htaccess<\/code> file exists in the document root (and whether it’s permitted to read one \u2014 covered in Step V)<\/li>\n\n\n\nmod_rewrite<\/code> is enabled and a matching RewriteCond<\/code>\/RewriteRule<\/code> pair is found, Apache generates an HTTP redirect response (301 or 302) pointing the browser to the new domain, instead of serving the requested page<\/li>\n\n\n\n![\"\"](\"https:\/\/pheonixsolutions.com\/blog\/wp-content\/uploads\/2017\/08\/htaccess_redirect_architecture-scaled.png\")
<\/a><\/figure>\n\n\n\n.htaccess<\/code> redirect never actually “serves” the old domain’s content \u2014 it’s a server-level instruction that gets caught before the requested page loads at all, which is what makes it reliable for handling every single request to the old domain, regardless of which specific page was requested.<\/p>\n\n\n\nIII. Verify the Rewrite Module Is Enabled<\/h3>\n\n\n\n
.htaccess<\/code> depends on Apache’s mod_rewrite<\/code> module. Confirm it’s loaded:<\/p>\n\n\n\napachectl -M\n<\/pre>\n\n\n\n
rewrite_module<\/code> in the output. If it isn’t listed, enable it:<\/p>\n\n\n\nsudo a2enmod rewrite\nsudo systemctl restart apache2\n<\/pre>\n\n\n\n
mod_rewrite<\/code> is typically compiled in by default with Apache from the standard package, but if it’s missing, ensure the corresponding line in httpd.conf<\/code> is uncommented:<\/p>\n\n\n\nLoadModule rewrite_module modules\/mod_rewrite.so\n<\/pre>\n\n\n\n
sudo systemctl restart httpd\n<\/pre>\n\n\n\n
IV. Locate the Document Root<\/h3>\n\n\n\n
.htaccess<\/code> file in the right location.<\/p>\n\n\n\n\/home\/username\/public_html\n<\/pre>\n\n\n\n
\/var\/www\/html\n<\/pre>\n\n\n\n
apachectl -S\n<\/pre>\n\n\n\n
V. Confirm .htaccess Overrides Are Allowed<\/h3>\n\n\n\n
AllowOverride None<\/code> for a given directory, which causes Apache to ignore .htaccess<\/code> files entirely<\/strong> \u2014 no error is shown, the rule just never takes effect.<\/p>\n\n\n\n<Directory><\/code> block, and confirm it allows overrides:<\/p>\n\n\n\n<Directory \/var\/www\/html>\n AllowOverride All\n<\/Directory>\n<\/pre>\n\n\n\n
sudo systemctl restart apache2\n<\/pre>\n\n\n\n
httpd<\/code> for the service name on CentOS\/RHEL.)<\/p>\n\n\n\nVI. Create or Edit the .htaccess File<\/h3>\n\n\n\n
.htaccess<\/code> file:<\/p>\n\n\n\ncd \/var\/www\/html\nvi .htaccess\n<\/pre>\n\n\n\n
VII. Add the Redirect Rule<\/h3>\n\n\n\n
RewriteEngine On<\/code> directive \u2014 without it, mod_rewrite<\/code> won’t process any RewriteCond<\/code> or RewriteRule<\/code> lines at all, even if the module itself is enabled server-wide:<\/p>\n\n\n\nRewriteEngine On\nRewriteCond %{HTTP_HOST} ^(www\\.)?domain\\.com$ [NC]\nRewriteRule (.*) https:\/\/www.newdomain.com\/$1 [R=301,L]\n<\/pre>\n\n\n\nLine<\/th> Purpose<\/th><\/tr><\/thead> RewriteEngine On<\/code><\/td>Turns on the rewrite engine for this .htaccess<\/code> file \u2014 required before any rule will function<\/td><\/tr>RewriteCond %{HTTP_HOST} ...<\/code><\/td>Matches requests to domain.com<\/code> or www.domain.com<\/code>, with [NC]<\/code> making the match case-insensitive<\/td><\/tr>RewriteRule (.*) https:\/\/www.newdomain.com\/$1<\/code><\/td>Redirects to the new domain, preserving the original request path via $1<\/code><\/td><\/tr>[R=301,L]<\/code><\/td>R=301<\/code> issues a permanent redirect (important for SEO \u2014 see Step XI); L<\/code> stops processing further rewrite rules once this one matches<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n
https:\/\/<\/code> in the destination. If your old domain serves both HTTP and HTTPS traffic and you want to preserve that dynamically rather than forcing everything to HTTPS, you can reference %{HTTPS}<\/code> conditionally \u2014 though in nearly all modern cases, redirecting everything to HTTPS on the new domain (as shown) is the better practice regardless, given HTTPS is now the standard expectation for any public-facing site.<\/p>\n<\/blockquote>\n\n\n\ndomain\\.com<\/code> with your actual old domain (keeping the backslash before each literal dot, since .<\/code> is a special regex character that needs escaping to match a literal period), and newdomain.com<\/code> with your actual new domain.<\/p>\n\n\n\nVIII. Test the Redirect<\/h3>\n\n\n\n
http:\/\/domain.com\n<\/pre>\n\n\n\n
http:\/\/www.domain.com\n<\/pre>\n\n\n\n
https:\/\/www.newdomain.com<\/code>, preserving whatever path was originally requested \u2014 for example, domain.com\/blog\/post-1<\/code> should land on newdomain.com\/blog\/post-1<\/code>, not just the new domain’s homepage.<\/p>\n\n\n\n\n
IX. Common Redirect Variations<\/h3>\n\n\n\n
RewriteEngine On\nRewriteCond %{HTTP_HOST} ^(www\\.)?domain\\.com$ [NC]\nRewriteRule ^oldsection\/(.*)$ https:\/\/www.newdomain.com\/newsection\/$1 [R=301,L]\n<\/pre>\n\n\n\nRewriteEngine On\nRewriteCond %{HTTP_HOST} ^(www\\.)?domain\\.com$ [NC]\nRewriteRule ^(.*)$ https:\/\/www.newdomain.com\/ [R=301,L]\n<\/pre>\n\n\n\nRewriteEngine On\nRewriteCond %{HTTP_HOST} ^domain\\.com$ [NC]\nRewriteRule (.*) https:\/\/www.domain.com\/$1 [R=301,L]\n<\/pre>\n\n\n\nX. Troubleshooting Common Issues<\/h3>\n\n\n\n
AllowOverride None<\/code> issue from Step V \u2014 Apache is silently ignoring the .htaccess<\/code> file entirely. Double-check the <Directory><\/code> block for the relevant document root.<\/p>\n\n\n\nsudo tail -f \/var\/log\/apache2\/error.log\n<\/pre>\n\n\n\n
\/var\/log\/httpd\/error_log<\/code>.) A malformed regex or a missing RewriteEngine On<\/code> combined with other rewrite rules elsewhere in the file are common causes.<\/p>\n\n\n\n.htaccess<\/code> also matches the same condition, redirecting back to itself indefinitely. Double-check that your RewriteCond<\/code> pattern only matches the old<\/em> domain, not the new one.<\/p>\n\n\n\n$1<\/code> in the destination (as shown in Step VII) and that your RewriteRule<\/code> pattern actually captures the path with (.*)<\/code>. Omitting the capture group, as shown in the “fixed URL” variation in Step IX, is sometimes done intentionally but will drop the path if that wasn’t the goal.<\/p>\n\n\n\nXI. Companion Rule: Forcing HTTPS on the New Domain<\/h3>\n\n\n\n
.htaccess<\/code> file:<\/p>\n\n\n\nRewriteEngine On\nRewriteCond %{HTTPS} off\nRewriteRule ^(.*)$ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [R=301,L]\n<\/pre>\n\n\n\n%{HTTPS} off<\/code>), and if so, redirects to the same path over HTTPS instead. Combined with the domain-to-domain redirect from Step VII, this ensures visitors always end up on the new domain over an encrypted connection, regardless of which protocol or domain they originally typed or clicked.<\/p>\n\n\n\n\n
.htaccess<\/code> is redundant. Check your existing setup first to avoid an unnecessary duplicate redirect hop, which adds latency for no benefit.<\/p>\n<\/blockquote>\n\n\n\nXII. SEO Considerations for Domain Redirects<\/h3>\n\n\n\n
\n
domain.com<\/code> redirects to newdomain.com<\/code>, which itself redirects somewhere else, each additional hop adds latency and can dilute the SEO signal. Redirect directly to the final destination in one hop wherever possible.<\/li>\n\n\n\nXIII. Conclusion<\/h3>\n\n\n\n
.htaccess<\/code> comes down to a few key pieces: confirming mod_rewrite<\/code> is enabled, making sure AllowOverride All<\/code> is actually permitted for the directory in question, and writing a rule that includes the often-missing RewriteEngine On<\/code> directive alongside a correctly escaped domain pattern. With HTTPS handled explicitly and a 301 status code in place, this approach reliably redirects an entire domain \u2014 preserving paths and SEO value \u2014 with a single small file.<\/p>\n\n\n\n
\n\n\n\nFrequently Asked Questions<\/h2>\n\n\n\n
RewriteEngine On<\/code> directive (required once per .htaccess<\/code> file, even if mod_rewrite<\/code> is enabled server-wide) and AllowOverride None<\/code> on the relevant directory, which causes Apache to ignore .htaccess<\/code> files entirely without any visible error.<\/p>\n\n\n\n.htaccess<\/code>) is generally faster, since Apache doesn’t need to check for and parse a .htaccess<\/code> file on every single request. If you have access to the main server configuration, that’s the more efficient long-term choice \u2014 .htaccess<\/code> remains useful when you only have access to the document root itself, such as on shared hosting.<\/p>\n\n\n\nQSA<\/code> (Query String Append) flag to the rule, for example [R=301,L,QSA]<\/code>, to automatically carry query parameters through to the new URL.<\/p>\n\n\n\nRewriteCond<\/code> pattern to match multiple domains using alternation, for example: RewriteCond %{HTTP_HOST} ^(www\\.)?(olddomain1\\.com|olddomain2\\.com)$ [NC]<\/code>, which matches either old domain and redirects both to the same destination.<\/p>\n\n\n\nRedirect<\/code> (and RedirectMatch<\/code>) is a simpler, more limited directive from mod_alias<\/code> that handles basic path-based redirects without the pattern-matching power of mod_rewrite<\/code>. RewriteRule<\/code>, used throughout this guide, supports conditional logic via RewriteCond<\/code>, regex capture groups, and far more complex matching \u2014 which is why it’s the standard choice for domain-level redirects that need to preserve paths or match multiple conditions.<\/p>\n\n\n\n
\n\n\n\n