--- title: "Redirecting visitor requests with the .htaccess file" date: "2024-02-14T06:18:38+00:00" summary: "Learn how to redirect visitor requests using .htaccess file configurations. Discover best practices for handling HTTP/HTTPS traffic, bare domains, and multiple domains to improve your website's security and SEO performance." image: type: "page" url: "/acquia-cloud-platform/redirecting-visitor-requests-htaccess-file" id: "dd373ff8-5228-4114-a469-b1adb902af18" --- Table of contents will be added Your website’s [.htaccess](https://en.wikipedia.org/wiki/.htaccess) file controls how your website’s visitors access your website, and can be configured to handle different visitor scenarios. Making changes to your .htaccess requires familiarity with [Git](/acquia-cloud-platform/develop-apps/repository/git). When implementing redirects in your `.htaccess` file, be aware of the following best practices: * Place the following code examples immediately after the `RewriteEngine On` line in your `.htaccess` file. * Include the following line in your rewrite code to exclude Acquia [default domains](/acquia-cloud-platform/manage-apps/domains#cloud-default-domain-names): RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC] # exclude Acquia domains * Too many redirects can cause minor to serious performance issues for your website. Every page request must follow the redirect rules, requiring added load time on a per-request basis. Acquia recommends regular reviews of rules for consolidation and removal as part of your normal maintenance practices. * Redirects do not preserve Google campaign tracking information. If you rely on this information, ensure your links do not rely on Acquia infrastructure-side redirects.  For more information about `.htaccess` rewrite rules, see [Introduction to htaccess rewrite rules](/acquia-cloud-platform/help/92451-introduction-htaccess-rewrite-rules "Introduction to .htaccess rewrite rules"). Redirects on Site Factory Site Factory subscriptions must alter the examples provided on the following page, such as: * When testing for `AH_SITE_ENVIRONMENT`, you may need values other than `prod` for environment names, such as `_01live` or `01live`. * [Default domain names](/site-factory/manage/domains#acsf-default-domain) use `acsitefactory.com` instead of `acquia-sites.com`. Redirecting bare domain names to the “www” subdomain ---------------------------------------------------- You can change your application’s `.htaccess` file so when visitors request your application’s URL without the `www` subdomain, the request redirects to the `www` subdomain. For example, requests to `http://example.com` will redirect to `http://www.example.com`. The following lines in your Drupal application’s `.htaccess` file can enforce the redirection, but may cause problems in development: # RewriteCond %{HTTP_HOST} !^www\. [NC] # RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Since the preceding lines unconditionally redirect visitors to a `www` subdomain, the redirection can cause problems if you configured the website to work with different domains, for example, with non-production environments. Instead, replace the commented lines with code like the following, changing the example to your own domain name: RewriteCond %{HTTP_HOST} ^example\.com$ [NC] RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC] RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting traffic between HTTP and HTTPS ------------------------------------------ For Acquia-hosted websites, secure HTTPS connections end at the load balancer level, which can cause common `.htaccess` recipes for HTTPS redirects to not work as expected. Since the `X-Forwarded-Proto` [Varnish header](/acquia-cloud-platform/performance/varnish/headers) indicates to the web infrastructure if a request came in through HTTPS, you must confirm the header in your rewrite conditions. The examples in each of the available redirect methods use rewrite rule flags. For a thorough explanation of the flags you can use, see [RewriteRule Flags](https://httpd.apache.org/docs/2.4/rewrite/flags.html). Redirecting all HTTP traffic to HTTPS ------------------------------------- The following sample rule sets `HTTP_X_FORWARDED_PROTO` to `https` when accessing the website using HTTPS: RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all HTTPS traffic to HTTP ------------------------------------- If your website displays insecure content warnings because Google indexed your documents using the HTTPS protocol, you must redirect traffic from HTTPS to HTTP using the following group of rules: RewriteCond %{HTTP:X-Forwarded-Proto} =https RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic to the “www” SSL domain ----------------------------------------------- To force all traffic to use both the `www` domain and SSL (even if not initially requested), use the following rules: Important When you have other sites that you don’t want to be redirected to the `www` domain, you must exclude them. The following snippet shows how to exclude Acquia domain sites and Cloud IDE preview sites from this rule. For more information, see [Introduction to htaccess rewrite rules](/acquia-cloud-platform/help/92451-introduction-htaccess-rewrite-rules "Introduction to .htaccess rewrite rules"). # exclude Acquia domains RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC] # exclude Acquia Cloud IDE preview sites RewriteCond %{HTTP_HOST} !\.web\.ahdev\.cloud [NC] # ensure www. RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # ensure https RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic to the bare SSL domain ---------------------------------------------- Cloud Platform Enterprise subscribers using the [standard certificate model](/acquia-cloud-platform/manage-apps/ssl#cloud-ssl-standard-vs-legacy) have the option of redirecting all traffic to a bare domain using the HTTPS protocol by using rules like the following: # Redirecting http://www.domain.com and https://www.domain.com # to https://domain.com RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC] RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [L,R=301] # Redirecting http://domain.com to https://domain.com RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic from two or more domains to a single domain ------------------------------------------------------------------- If you have two or more domains pointing to your website, your search rankings can be demoted for duplicate content. Use the following code to redirect visitors from two or more domains to a single domain: RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC,OR] RewriteCond %{HTTP_HOST} ^domain.com$ [NC,OR] RewriteCond %{HTTP_HOST} ^domain.net$ [NC] RewriteRule ^(.*)$ https://www.domain.net/$1 [R=301,L] Acquia recommends placing these rules after other redirects, such as [Redirecting all HTTP traffic to HTTPS](#redirect-all-http-to-https) or [Redirecting all traffic to the bare SSL domain](#redirect-all-bare-https). Redirecting all traffic for multi-sites with symlinks ----------------------------------------------------- For a new language, you don’t need to add separate blocks for redirection rule. You can add more languages by using the pipe separator. The following snippet shows the redirection rules for English and French. #only language arguments in URL RedirectMatch 301 ^/(en|fr)(/en|/fr)+/(en|fr)$ /$1/ #language arguments followed by path RedirectMatch 301 ^/(en|fr)(/en|/fr)+/(.*)$ /$1/$3 Excluding Acquia domains and non-production environments -------------------------------------------------------- To exclude the default Acquia domains from your redirects, or specific environments (such as Dev and Stage), add one or more of the following conditionals to the top of any group of rewrite rules: RewriteCond %{ENV:AH_SITE_ENVIRONMENT} prod [NC] # only prod RewriteCond %{ENV:AH_SITE_ENVIRONMENT} !prod [NC] # not prod # exclude Acquia domains RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC] # exclude Acquia Cloud IDE preview sites RewriteCond %{HTTP_HOST} !\.web\.ahdev\.cloud [NC] As an example, if you wanted to ensure all the domains redirected to `https://www.` except for Acquia [default domains](/acquia-cloud-platform/manage-apps/domains#cloud-default-domain-names), you would use rules like the following: # exclude Acquia domains RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC] # exclude Acquia Cloud IDE preview sites RewriteCond %{HTTP_HOST} !\.web\.ahdev\.cloud [NC] # ensure www. RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # ensure https RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Identifying and blocking nuisance bots -------------------------------------- Bot traffic is the non-human traffic generated on your website. Some bot traffic is useful for search engines and digital assistants. However, malicious bots or unauthorized web crawlers can be a nuisance because they disrupt site analytics and create an outsize impact on your infrastructure utilization. To keep such traffic at bay, Acquia recommends adding nuisance bots to **.htaccess**: # BLEXBot marketing crawler. #Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)" RewriteCond %{HTTP_USER_AGENT} ^(.*)BLEXBot(.*)$ RewriteRule .* - [F,L] # Moz Link Index Crawler. #Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/ dotbot, help@moz.com)" RewriteCond %{HTTP_USER_AGENT} ^(.*)DotBot(.*)$ RewriteRule .* - [F,L] # Paid SEO bot. #Curious George - www.analyticsseo.com/crawler" RewriteCond %{HTTP_USER_AGENT} ^(.*)Curious\ George(.*)$ RewriteRule .* - [F,L] You can get a list of all nuisance bots by accessing your website from your historical web analytics data. Example ------- Note The information in this section applies only to [legacy SSL certificates](/node/56289#types-of-ssl). The preceding examples of how and when you would use a rewrite are complex. Here is a breakdown of the scenarios, which may help you determine what your website needs. A security warning will occur on a bare domain only if the request specifically includes the HTTPS protocol (such as `https://example.com`), and the load balancer covering the bare domain contains no SSL certificate. A request for `http://example.com` using the HTTP protocol will not produce a security warning because a secure connection to the bare domain was not requested. Domain DNS record type IP/Host name `www.example.com` CNAME dc–0000–000000000.us-east-1.elb.amazonaws.com `example.com` A 123.45.67.89 For Cloud Platform, the CNAME record for `www.example.com` points to the host name of the elastic load balancer where the [self-service UI](/acquia-cloud-platform/manage-apps/ssl) installs the SSL certificate. Bare domains/ non-FQDNs such as `example.com` cannot have CNAME records without a service like [Route 53](/acquia-cloud-platform/help/92946-using-route-53-enable-ssl-your-bare-domain "Using Route 53 to enable SSL on your bare domain"). Due to the limitation, the domain must point to the elastic IP address of the balancer pair behind the [Elastic Load Balancer (ELB)](/acquia-cloud-platform/glossary). If the `.htaccess` file contains a redirect taking all requests for the bare domain and redirecting them to `www`, due to how the DNS records are configured, the following process occurs if you request `http://example.com`: 1. The request for `http://example.com` hits the load balancers behind the ELB. 2. The `.htaccess` rule 301 redirects request to `https://www.example.com`. 3. A new request for `https://www.example.com` hits the ELB (where the certificate exists), and the procedure completes as expected. If you send a specific request to `https://example.com` with the HTTPS protocol, the following occurs: 1. A request for `https://example.com` hits the load balancers behind the ELB. 2. Your browser displays the normal security warning. 3. You examine the certificate and decide to move ahead. 4. The `.htaccess` rule 301 redirects the request to `https://www.example.com`. 5. A new request for `https://www.example.com` hits the ELB (where the certificate exists), and the procedure completes as expected. Depending on your Cloud Platform subscription type, there may be more requirements or steps to remove the security warning: * _Cloud Platform Professional_ Cloud Platform Professional uses shared balancers, so you must use a bare domain service (such as Route 53 or [CloudFlare](https://www.cloudflare.com/)) to remove the security warning. Bare domain services allow you to use a CNAME record for the bare domain, and point the bare domain at the host name of the ELB. * _Cloud Platform Enterprise_ Acquia recommends you upload a SSL certificate covering all needed domains as described in [Managing SSL certificates](/acquia-cloud-platform/manage-apps/ssl/cert), or use another bare domain service such as Route 53 or Cloudflare.