Redirect HTTP to HTTPS in WordPress: 3 Simple Methods

HTTP and HTTPS both work at the Application layer, but HTTPS uses TLS/SSL for security, so TLS/SSL runs between the Application layer and the Transport Layer.

In short, HTTP and HTTPS are Application layer protocols and HTTPS is HTTP plus TLS for encryption.

I’ll show the easiest three methods: Server level, WordPress and database level solutions. And you can use these medthods for HTTP to HTTPS for a WordPress-hosted websites with a testing and verification checklist. I have also covered the HSTS and preload, and mixed content warnings in the DevTool Console.

Requirements Checklist

• Make sure a valid SSL certificate is installed and working for your domain.
• You will need access to FTP, SSH, or a hosting control panel to change server settings.
• You will also need phpMyAdmin, Adminer, or WP-CLI to make changes to the database.
• You must be able to reload or restart the web server if you apply server-level redirects or use hosting controls.

Server-level Redirects

Server level redirects are handled by the web server before the page loads. These server redirects are used for redirecting HTTP to HTTPS, moving old URLs to new ones or enforcing a single domain version. The more common types are 301 permanent redirect and 302 temporary redirect. Server-level redirects are faster and better for SEO than from page-level redirects. I have included three of the most popular web servers: Nginx, Apache, and Microsoft IIS.

Nginx

NGINX is a high-performance, open source web server. It is commonly used as a reverse proxy, load balance, HTTP cache and mail proxy. Nginx handles the redirects at the server level, before content/page is served and commonly used to force HTTPS.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Nginx config file locations:

• Ubuntu / Debian
  /etc/nginx/sites-available/
/etc/nginx/sites-enabled/
• CentOS / RHEL / Rocky / AlmaLinux
  /etc/nginx/nginx.conf
/etc/nginx/conf.d/
• Arch Linux
  /etc/nginx/nginx.conf

Useful Commands

• Test configuration: The given command is used to test your Nginx configuration before applying it.
  sudo nginx -t
• Reload Nginx: It applies configuration changes without stopping active connections.
  sudo systemctl reload nginx
• Restart Nginx: It completely restarts Nginx, stopping and starting the service and dropping active connections.
  sudo systemctl restart nginx

Apache Vhost

Apache HTTP server is a free, open source, and widely used web server software that processes client requests and delivers the requested content. Apache handles the redirects at the server level to force HTTPS before content loads. The common redirect methods are: .htaccess, which is discussed in the WordPress-level redirect and another is Virtual Host (vhost) configuration that is given below:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

With Rewrite for full URI preservation:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    RewriteEngine On
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

Apache config file locations:

Apache config file locations on different Linux distributions are given below:

• Ubuntu / Debian
  /etc/apache2/sites-available/
/etc/apache2/sites-enabled/
• CentOS / RHEL / Rocky / AlmaLinux
  /etc/httpd/conf/httpd.conf
/etc/httpd/conf.d/
• Arch Linu
  /etc/httpd/conf/httpd.conf

Useful Commands

• Test configuration: This command checks Apache configuration files for syntax errors and reports whether the configuration is correct.
  sudo apachectl configtest
• Reload Apache: These commands reload the Apache service to apply configuration changes without stopping the server.
  sudo systemctl reload apache2   # Debian/Ubuntu
sudo systemctl reload httpd     # RHEL/CentOS
• Restart Apache: The given commands restart the Apache service, stopping and then starting it again to fully apply changes.
  sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL/CentOS

Microsoft Internet Information Services (IIS)

Microsoft Internet Information Services (IIS) is a secure and flexible web server used to host and manage websites and web applications. IIS also handles the redirect at the server level using its URL Rewrite extension before the site loads. Follow these steps:

1. If the URL Rewrite extension is not already installed on the server, then download and install it.
2. Open IIS Manager.
3. Select your website, then open “URL Rewrite” and click on “Add Rule” while choose the blank rule.
4. Name the rule HTTP to HTTPS or any understandable name.
5. In the “Match URL” section, select “Matches the Pattern” in the Requested URL, while in the “Using” dropdown select “Regular Expressions” and set the “Pattern” to (.*) and make sure “Ignore case” is checked.
6. Under the “Conditions” section, click on “Add”, then write {HTTPS} in the “Condition Input” while set Check if input string to Matches the Pattern while also set the pattern to off and also check “Ignore case.” You can also use “Is Equal To” with off. Either option works.
7. In the Action section, set “Redirect” to the “Action Type” dropdown. Add https://{HTTP_HOST}{REQUEST_URI} to “Redirect/Rewrite URL”, also leave “Append query string” unchecked while the request URI already includes it.
8. Set Redirect type to Permanent (301) and check Stop processing of subsequent rules.
9. Save or apply the rule, then open the site with http:// and confirm it redirects to HTTPS.

WordPress-level Redirects

WordPress-level redirects are handled by the WP CMS, in which we add the configurations to wp-config.php, .htaccess or functions.php. These CMS redirects are used for forcing HTTPS/SSL, redirecting old URLs to new ones or enforcing a single domain version with a 301 permanent redirect or 302 temporary redirect.

wp-config.php

wp-config.php is a core WordPress configuration file located in the root directory. It stores critical settings such as database credentials and security keys, and it also manages advanced WordPress functionalities.

1. FORCE_SSL_ADMIN = true makes sure that to enable SSL/HTTPS for /wp-admin/ and login pages. If force SSL is enabled, then WordPress will send secure cookies for all requests to redirect admin/login endpoints to HTTPS.
2. WP_HOME and WP_SITEURL override the stored values of home and site URLs in the database, setting them to https://, so then WordPress generates HTTPS links for pages, assets, and admin URLs.
3. The third configuration is for a reverse-proxy snippet which checks for X-Forwarded-Proto. This says that the original request used HTTPS when a load balancer or proxy terminates TLS. This reverts to $_SERVER['HTTPS'] so WP considers the request secure and avoids redirect loops.

// Force SSL for admin pages and logins
define('FORCE_SSL_ADMIN', true);
// If you want WordPress to always use HTTPS for site URLs
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
// Handle reverse proxy (if your load balancer sets X-Forwarded-Proto)
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

functions.php

functions.php is a specific file located in the theme directory which is automatically loaded by WordPress. The below code snippet runs during the page load before the theme template is served. If a request is not over TLS, then this sends a 301 redirect to the same URL but with https:// and stops the execution.

Cons & Risks

1. This method is slower than a server-level redirect because it requires an extra PHP boot.
2. The code snippet may not run or work for non-frontend endpoints like REST API, XMP-RPC and some admin AJAX requests unless you explicitly handle them.
3. Also, dependent on is_ssl(), which can be false behind the TLS terminating proxies unless you handle X-Forwarded-Proto.

add_action('template_redirect', function() {
    if ( ! is_ssl() ) {
        wp_safe_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301);
        exit;
    }
});

.htaccess

A .htaccess file is an Apache configuration file that controls how a website behaves in each directory. It allows things like URL rewriting, security rules, and redirects without changing the main server configuration.

Place the rules in the .htaccess file of the WordPress root directory after or before the WordPress rules. The rules can be used for www and non-www sites.

# BEGIN Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# END Force HTTPS

If a reverse proxy is used, apply the conditions below to set X-Forwarded-Proto.

#  BEGIN X-Forwarded-Proto
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#  END X-Forwarded-Proto

Non-WWW to WWW

This rule forces all traffic to use HTTPS and the www version of the domain. The rules redirect any HTTP request or non-www request to HTTPS and www with the same URL path as https://www.example.com/. Replace example.com with your domain name.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

WWW to Non-WWW

This rule forces all traffic to use HTTPS and the non-www version of the domain. Any HTTP request or www request is redirected to HTTPS and non-www with the same URL path as https://example.com/. Replace example.com with your domain name.

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Database Changes

The third method works at the database level: queries run on the database to replace all http:// URLs with https:// in the chosen tables. You can do this with direct SQL queries or with WP-CLI’s search-replace. Be careful not to change serialized strings stored in the database, altering them can break your site. Replace example.com with your domain name

UPDATE wp_options SET option_value = replace(option_value, 'http://', 'https://') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://', 'https://');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://','https://');
UPDATE wp_comments SET comment_content = replace(comment_content , 'http://', 'https://');

WP-CLI

WP-CLI is a command-line tool for WordPress. You can manage tasks like updating plugins, themes, and multisite setups. WP-CLI handles PHP-serialized strings correctly and doesn’t run a blind SQL REPLACE() on serialized data. In the below commands --skip-columns=guid avoids changing the GUIDs.

A dry run shows what would change without making updates, and if everything looks correct, rerun the command without --dry-run to apply the changes.

wp search-replace 'http://' 'https://' wp_options wp_posts wp_postmeta wp_comments --skip-columns=guid --dry-run

wp search-replace 'http://' 'https://' wp_options wp_posts wp_postmeta wp_comments --skip-columns=guid

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --all-tables

Mixed Content Warnings

Mixed content warnings show when a page loads over HTTPS, but some resources like images, scripts, or stylesheets load over HTTP. Open any page and check the DevTools Console for mixed content warnings, then identify the listed URLs in the console and replace hard-coded http:// to https:// in themes, plugins, widgets, stylesheets, and scripts. After fixing them, clear all caches such as page cache, object cache, and CDN cache.

HSTS and Preload

HSTS (HTTP Strict Transport Security) preload is a mechanism that forces a website to use a secure HTTPS connection from the very first visit. The preload token indicates that you can submit your domain to browser preload lists (Chrome, Firefox, Safari, etc.). Only enable preload when you have verified HTTPS across all subdomains. Below are the Apache and Nginx HSTS header rules, which you can add to the same configuration file

Apache

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Testing & Verification Checklist

1. curl -I sends a request to a URL and shows only the HTTP response headers, not the page content. It is used to check redirects, confirm HTTP to HTTPS behavior, and view headers like Location, Server, and Content-Type.
   
   curl -I http://example.com
   
   Result:
   HTTP/1.1 301 Moved Permanently
Location: https://example.com
2. The curl -IL command fetches only the HTTP headers and follows the full redirect chain, making it easy to confirm HTTP to HTTPS and verify the final status code, which is usually 200.
   
   curl -IL http://example.com
   
   Result:
   First response: 301 Moved Permanently
Final response: 200 OK
3. Open your site in multiple browsers and devices to confirm the padlock icon and check for mixed content warnings.
4. Properly test the /wp-admin/ area and login pages.
5. Also test REST API endpoints and any other external integrations.

Troubleshooting Common Problems

1. Redirect loop: Sometimes a virtual host, .htaccess, or a plugin conflicts, or proxy headers are missing. Temporarily comment out or remove the redirect to isolate and fix the problem.
2. Proxy / load balancer: Ensure X-Forwarded-Proto is forwarded and $_SERVER['HTTPS'] is set in wp-config.php.
3. Search/replace broken serialized data: Restore the database from backup and use WP-CLI or another tool that is serialization-aware.
4. Caching: Purge CDN and server caches after making changes.

Conclusion

The best option is a server-level setup, such as a Nginx or Apache vhost redirect, if you have access. For shared hosting without vhost access, .htaccess is a good solution. If you use managed hosting or a load balancer, set WP_HOME, WP_SITEURL, and FORCE_SSL_ADMIN in wp-config.php, and make sure proxy headers are passed correctly. I hope this article helps. If you have any related questions, feel free to comment below.