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.

Steps to redirect HTTP to HTTPS in WordPress:

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.
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
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
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.
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
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
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