How to Move WordPress to HTTPS Without Breaking Anything

Every WordPress site worth running serves over HTTPS now. If you still have visitors landing on plain http:// pages, browsers flag you as “Not secure”, Google prefers your HTTPS competitors, and any login form on your site is transmitting credentials in the clear. Learning how to move WordPress to HTTPS properly is one of the highest-value admin tasks you’ll ever do — and it takes about 30 minutes if you follow the right order.

This guide walks through the full migration: installing a free SSL certificate, pointing WordPress at the HTTPS URLs, rewriting the database, adding the 301 redirect, fixing mixed content, and telling Google — plus how to fix the three classic things that break. Last verified: October 4, 2026.

Table of Contents

Why HTTPS Is Non-Negotiable in 2026

Google has used HTTPS as a (lightweight) ranking signal since 2014, and these days well over 98% of top search results are HTTPS. Chrome labels HTTP pages “Not secure” right in the address bar, which quietly murders trust — especially on contact forms and checkout pages. And if you ever take admin logins or user submissions, HTTPS isn’t a nicety; it’s the encryption that stops anyone on the same network from reading that traffic.

The good news: the certificate itself is free. The bad news: most tutorials cover either the plugin-click path or the manual path, and the real work lives in the seam between the two — the database URLs, the redirect, and the SEO cleanup. Here’s the complete order of operations.

Step 0: Back Up Everything Before You Touch Anything

You’re about to rewrite URLs across your entire database. Before that:

Take a full backup: files and database. Use your host’s backup tool or a plugin like UpdraftPlus.
Verify the backup actually restores (at minimum, confirm the database dump file exists and is recent).
If you have SSH, a quick database snapshot is one command:
```
wp db export ~/backup-before-https-$(date +%F).sql
```

Don’t skip this. A search-replace gone wrong is trivially fixable with a backup and hours of pain without one.

Step 1: Install a Valid SSL Certificate

WordPress can’t serve HTTPS until your server has a certificate for your domain. Two common routes:

Shared hosting / managed WordPress: your control panel almost certainly has free SSL (usually Let’s Encrypt) in the SSL/TLS or Security section. Install it for your domain and wait a few minutes for it to provision. Confirm https://yourdomain.com loads with a padlock before continuing.
Your own VPS: use Certbot with the Nginx plugin (or Apache plugin). The standard command installs the certificate, rewrites your server block, and adds the HTTP-to-HTTPS redirect in one shot:
```
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
```
Certbot will ask for an email (renewal/expiry notices) and agreement to the Let’s Encrypt terms. Certificates last 90 days; Certbot installs auto-renewal for you — test it with sudo certbot renew --dry-run.

Check that the certificate covers both the www and non-www versions of your domain. If your site is https://yourdomain.com but https://www.yourdomain.com throws a certificate error, visitors (and Googlebot) will see a scary warning on that variant. Certbot’s -d flags above handle both.

Step 2: Point WordPress at the HTTPS URLs

Go to Settings → General in wp-admin and change both WordPress Address (URL) and Site Address (URL) from http:// to https://. Save — WordPress will log you out, and you’ll log back in over HTTPS.

Alternative if you can’t reach the dashboard: hardcode the URLs in wp-config.php (above the “That’s all, stop editing!” line):

define( 'WP_HOME', 'https://yourdomain.com' );
define( 'WP_SITEURL', 'https://yourdomain.com' );

Note: when these constants are defined, the Settings → General fields become greyed out. That’s expected — the constants override the database values.

Step 3: Force SSL in the Admin Area

Add this to wp-config.php, above the “That’s all, stop editing!” line:

define( 'FORCE_SSL_ADMIN', true );

This is a fail-safe that forces your login page and dashboard to always load over HTTPS. (Ignore any older tutorial that tells you to also set FORCE_SSL_LOGIN — that constant was deprecated and removed back in WordPress 4.0; FORCE_SSL_ADMIN covers both.) Use straight quotes in this file, not curly ones — a curly quote here is a PHP syntax error that takes your whole site down.

Step 4: Rewrite Every Old URL in the Database

Changing the settings above only fixes what WordPress generates. Your posts, pages, widgets, menus, and options tables still contain thousands of hardcoded http://yourdomain.com URLs pointing at images, links, and embeds. Until those are rewritten at the source, you’ll get mixed-content warnings — and you’ll be one plugin deactivation away from breaking things again.

Important: WordPress stores many URLs inside PHP-serialized arrays (options, widgets, page-builder data). A raw SQL find-and-replace or a text editor will corrupt those and silently break things. Use a tool that understands serialized data:

No SSH access? Install the free Better Search Replace plugin (Plugins → Add New). Go to Tools → Better Search Replace, enter http://yourdomain.com in “Search for” and https://yourdomain.com in “Replace with”, select all tables, and tick “Run as dry run” first. Review the counts, then run it for real.
Have SSH + WP-CLI? It’s faster and more precise:
```
cd /var/www/yourdomain.com/public
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --dry-run
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid
```
--dry-run previews every change; the real run uses --skip-columns=guid because GUIDs are meant to be permanent identifiers — replacing them can break feeds and confuse plugins. Only touch GUIDs if you’re solving a specific problem and understand the trade-off.

Skip the Velvet Blues “Update URLs” plugin if an old tutorial recommends it — it was closed in the WordPress plugin directory in May 2024 over a security issue and can’t be installed anymore. Better Search Replace is the current standard replacement.

Step 5: Redirect All HTTP Traffic to HTTPS with a 301

Without a redirect, both versions of every URL exist — that’s duplicate content for Google and a confusing experience for visitors. You want every http:// URL to 301-redirect to its HTTPS equivalent in a single hop.

On Apache (.htaccess)

Add this above the # BEGIN WordPress block:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

On Nginx

Add a dedicated server block that redirects everything on port 80 (if Certbot didn’t already create one):

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

Then sudo nginx -t && sudo systemctl reload nginx. Test with curl -I http://yourdomain.com — you should see 301 and a Location: https://... header, with no intermediate hops.

Behind Cloudflare or a reverse proxy? Your origin may see every request as plain HTTP even though the visitor is on HTTPS, which creates a redirect loop. Check %{HTTP:X-Forwarded-Proto} instead of %{HTTPS}, or set your CDN’s SSL mode to “Full (strict)”. And pick one redirect location — app-level plugin, .htaccess, or server config. Stacking a “force HTTPS” plugin on top of server redirects is the most common cause of redirect loops.

Step 6: Hunt Down Mixed Content

Mixed content is what kills the padlock: your page loads over HTTPS, but an image, script, stylesheet, or font still loads over http://. Browsers block active mixed content (scripts) and warn on passive content (images) — either way, visitors lose trust.

Open your homepage with DevTools (F12 → Console). Every blocked resource is listed with its exact URL. The fix order:

Run Step 4’s search-replace again — most mixed content is internal URLs you missed.
Check theme and plugin files for hardcoded http:// asset URLs and update them.
For external resources (fonts, embeds, widgets), switch the embed code to https:// or drop the provider if they don’t support it.
Clear every cache after fixing: your caching plugin, any CDN cache, and your browser cache (or test in incognito). Stale caches are the #1 reason “fixed” mixed content seems to come back.

Tools like WhyNoPadlock scan a page and list insecure resources for you if you’d rather not dig through the console.

Step 7: Tell Google (and Everyone Else)

Google treats http:// and https:// as different properties. Skip this step and your rankings dip while Google slowly figures things out.

Add the https:// property in Google Search Console (it’s a separate property — the old http one doesn’t carry over).
Resubmit your XML sitemap in the new HTTPS property. Verify the sitemap URLs all use https://.
Confirm canonical tags now point at https:// versions (Rank Math and Yoast handle this automatically once the site URL is HTTPS).
Update the site URL in Google Analytics / any analytics tool, and in third-party services that call back into your site (payment webhooks, email tools, APIs).
If you ever submitted a disavow file, resubmit it to the HTTPS property — disavow files are property-specific.
Update external profiles pointing at you: social bios, directories, email signatures. Internal links you own are already fixed by Step 4.

Keep both the HTTP and HTTPS properties in Search Console for about 4 weeks and watch for crawl errors and traffic shifts. Expect minor fluctuation for a few days — that’s normal.

Troubleshooting the Three Classic Breakages

1. “Too many redirects” (redirect loop)

Usually a mismatch: WordPress thinks the site is http:// while the server redirects to https://, or two redirect systems fight each other. Check Settings → General has https:// in both fields, remove duplicate force-HTTPS rules (keep only one location), and check caching/security plugins for their own “force HTTPS” toggles. Behind a proxy, add this to wp-config.php so WordPress recognizes the real protocol:

if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

2. The padlock still won’t stick

That’s mixed content (Step 6). The DevTools console names the exact culprits. The other sneaky cause: a caching layer serving the old HTTP page — purge everything and re-test in incognito.

3. Locked out of wp-admin

If changing the URLs broke your login (mismatched scheme, bad cookie), log in directly at https://yourdomain.com/wp-login.php, or fix the values with WP-CLI: wp option update home 'https://yourdomain.com' and wp option update siteurl 'https://yourdomain.com'.

The Post-Migration Checklist

☐ https://yourdomain.com and https://www.yourdomain.com both load with a valid padlock
☐ http:// versions 301-redirect to https:// in a single hop (check with curl -I)
☐ No mixed-content warnings in the browser console on homepage, a post, and the checkout/form pages
☐ Search Console HTTPS property added, sitemap resubmitted
☐ Canonical tags and sitemap URLs all use https://
☐ Analytics and third-party callbacks updated to the HTTPS URL
☐ Login/logout, forms, search, and media uploads all tested
☐ Certificate auto-renewal verified (certbot renew --dry-run on a VPS, or the host’s renewal status on shared hosting)

Moving WordPress to HTTPS is one of those tasks that looks trivial and goes wrong in exactly the places most tutorials skip: the database rewrite, the redirect loop behind a proxy, and the Search Console property. Do the steps in this order — backup, certificate, URLs, database, redirect, mixed content, Google — and your migration takes an afternoon instead of a weekend. Your visitors get the padlock, Google gets the right signals, and you get to stop thinking about it.

How to Move WordPress from HTTP to HTTPS Without Breaking Anything (2026)