How to redirect HTTP to HTTPS in WordPress

Redirecting a WordPress site from HTTP to HTTPS keeps logins, cookies, and form traffic off clear text while giving the site one canonical public scheme for browsers, search engines, and plugins that build absolute URLs.

On Apache-based WordPress installs, the redirect normally happens before WordPress handles the request, so the reliable pattern is to let Apache issue the 301 upgrade while WordPress itself treats the site URL and admin area as secure. That keeps the front end, wp-login.php, and wp-admin aligned instead of drifting between schemes.

A working certificate and HTTPS virtual host should already be in place before enabling the redirect. The direct-Apache path assumes Apache terminates TLS itself; when a load balancer, reverse proxy, or CDN terminates HTTPS first, a plain .htaccess redirect can loop unless the origin is made proxy-aware first.

1. Open a shell in the WordPress document root and create timestamped backups of wp-config.php and .htaccess.

   $ cd /var/www/example.com/public_html
   $ sudo cp wp-config.php wp-config.php.bak-$(date +%Y%m%d%H%M%S)
   $ [ -f .htaccess ] && sudo cp .htaccess .htaccess.bak-$(date +%Y%m%d%H%M%S) || sudo touch .htaccess

   Keeping clean copies of both files makes it possible to roll back a bad redirect rule or duplicated constant without touching the database.

2. Confirm that Apache can honor WordPress rewrite rules before editing .htaccess.

   # Ubuntu or Debian
   $ sudo apache2ctl -M | grep rewrite
    rewrite_module (shared)
   
   # Fedora, Red Hat, or CentOS Stream
   $ sudo httpd -M | grep rewrite
    rewrite_module (shared)

   <Directory /var/www/example.com/public_html>
       AllowOverride All
       Require all granted
   </Directory>

   AllowOverride All is the common WordPress setting, but FileInfo is enough when local policy is more restrictive. If overrides are disabled, the redirect rule is ignored even when the file content is correct.

   Related: How to locate Apache configuration files
   Related: How to enable or disable Apache modules

3. Open wp-config.php and add FORCE_SSL_ADMIN in the custom-values section; if WP_HOME or WP_SITEURL are already defined there, make sure they use https://.

   $ sudo vi wp-config.php

   define( 'FORCE_SSL_ADMIN', true );
   define( 'WP_HOME', 'https://www.example.com' );
   define( 'WP_SITEURL', 'https://www.example.com' );

   Only keep the WP_HOME and WP_SITEURL lines when those constants are already used on the site. If the URLs live only in the database, leave them out of wp-config.php and update the stored values separately.

   On proxied or CDN-fronted sites, add the trusted forwarded-HTTPS mapping before WordPress loads and use the redirect-loop workflow rather than trusting a generic forwarded header on a directly reachable origin.

   Related: How to update WordPress URLs from HTTP to HTTPS
   Related: How to fix HTTPS redirect loop in WordPress behind a load balancer

4. Insert the HTTPS redirect rule near the top of .htaccess, above the autogenerated WordPress rewrite block.

   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteCond %{HTTPS} !=on
   RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
   </IfModule>
   
   # BEGIN WordPress
   ##### snipped #####
   # END WordPress

   Placing the redirect first upgrades the request before normal permalink handling begins, while preserving the original path and query string automatically.

5. Test the Apache configuration when the earlier checks required a module change or an edit to the site VirtualHost or Directory block.

   # Ubuntu or Debian
   $ sudo apache2ctl -t
   Syntax OK
   
   # Fedora, Red Hat, or CentOS Stream
   $ sudo httpd -t
   Syntax OK

   Skip this step when only wp-config.php and .htaccess changed. Those file updates do not require an Apache syntax test on their own.

   Related: How to test Apache configuration

6. Reload the Apache service after the configuration test passes when module or server configuration changed.

   # Ubuntu or Debian
   $ sudo systemctl reload apache2
   
   # Fedora, Red Hat, or CentOS Stream
   $ sudo systemctl reload httpd

   No reload is needed when the change was limited to wp-config.php and .htaccess, because those updates apply on the next request.

   Related: How to manage the Apache web server service

7. Verify that HTTP requests for the WordPress login page now redirect to HTTPS and that the HTTPS endpoint responds normally.

   $ curl -I http://www.example.com/wp-login.php
   HTTP/1.1 301 Moved Permanently
   Location: https://www.example.com/wp-login.php
   
   $ curl -I https://www.example.com/wp-login.php
   HTTP/1.1 200 OK
   ##### snipped #####

   The first command proves the redirect rule, while the second proves that the existing HTTPS virtual host and certificate are already serving the site correctly.

   If the redirect works but the page still emits http://// links or assets, the WordPress URL and stored-content cleanup is still pending.</WRAP>

   Use -k only on a lab or self-signed certificate while testing the redirect path.

   Related: How to update WordPress URLs from HTTP to HTTPS