Information for: DEVELOPERS   PARTNERS

Redirecting visitor requests with the .htaccess file

Your website’s .htaccess file controls how your website’s visitors access your website, and can be configured to handle many different visitor scenarios. Some of the configuration methods you can use with you Acquia-hosted website’s .htaccess file include the following:

When implementing redirects in your .htaccess file, be aware of the following best practices:

  • Place all of the following code examples immediately after the RewriteEngine On line in your .htaccess file.

  • Include this line in your rewrite code:

    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 the redirect rules, requiring additional 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 server-side redirects. Acquia Cloud Enterprise customers can use a custom VCL file to alter this behavior.

For more information about .htaccess rewrite rules, see Introduction to htaccess rewrite rules.

Redirects on Acquia Cloud Site Factory

Acquia Cloud Site Factory subscriptions must modify the examples provided on this 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 use instead of

Redirecting bare domain names to the “www” subdomain

You can modify your application’s .htaccess file so that when visitors request your application’s URL without the www subdomain, the request redirects to the www subdomain. For example, requests to will redirect to

The following lines in the Drupal 8 and Drupal 7 versions of .htaccess accomplish this, but can cause problems in development:

# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Because these lines unconditionally redirect visitors to a www subdomain, it can cause problems if the website is intended to work with different domains, for example, with non-production environments. Instead, replace the commented lines with code similar to the following, modifying it for 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 terminate at the load balancer level, which can cause many common .htaccess recipes for HTTPS redirects to not work as expected. Because the X-Forwarded-Proto Varnish header indicates to the webserver if a request came in over HTTPS, you must validate this 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.

Redirecting all HTTP traffic to HTTPS

This 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 website visitors receive insecure content warnings due to Google indexing documents using the HTTPS protocol, traffic may need to be redirected from HTTPS to HTTP. For this case, use the following rule set:

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:

# 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

Acquia Cloud Enterprise customers with dedicated load balancers have the option of redirecting all traffic to the bare domain using the HTTPS protocol. To do this, use rules similar to the following:

# Redirecting and
# to
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [L,R=301]
# Redirecting to
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

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]

As an example, if you wanted to ensure that all the domains redirected to https://www. except for Acquia domains, you would use rules like the following:

# ensure www.
RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC]
# exclude Acquia domains
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]


The information in this section applies only to legacy SSL certificates.

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, and the load balancer covering the bare domain contains no SSL certificate. A request for 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/Hostname CNAME A

For Acquia Cloud, the CNAME record for points to the hostname of the elastic load balancer, because that’s where the self-service UI installs the SSL certificate. However, bare domains/non-FQDNs such as cannot have CNAME records without a service similar to Route 53. Because of this limitation, the domain must point to the elastic IP address of the balancer pair behind the Elastic Load Balancer (ELB).

If the .htaccess file contains a redirect that will take all requests for the bare domain and redirect them to www, due to how the DNS records are set up, the following process occurs if you request

  1. The request for hits the load balancers behind the ELB.
  2. The .htaccess rule 301 redirects request to
  3. A new request for hits the ELB (where the certificate exists), and the procedure completes successfully.

However, if a specific request is sent to with the HTTPS protocol, the following occurs:

  1. A request for 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
  5. A new request for hits the ELB (where the certificate exists), and the procedure completes successfully.

Depending on your Acquia Cloud subscription type, there may be more requirements or steps to remove the security warning:

  • Acquia Cloud Professional

    Acquia Cloud Professional uses shared balancers, so you must use a bare domain service (such as Route 53 or CloudFlare) 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 hostname of the ELB.

  • Acquia Cloud Enterprise

    Acquia recommends you upload a SSL certificate that covers all needed domains as described in Managing SSL certificates, or use another bare domain service such as Route 53 or Cloudflare.