Moving WordPress from http:// to https:// touches more places than people expect — the site URL settings, the database content itself, and the server-level redirect. Done out of order, you'll get redirect loops or a site full of "mixed content" warnings. Here's the sequence that avoids both.
1. Install the certificate first
Before touching WordPress settings, confirm the certificate is actually installed and working by visiting https://yourdomain.com directly in a browser. Most hosts (including cPanel-based hosting) offer free AutoSSL — if you're not sure it's active, check your hosting control panel's SSL/TLS section before continuing.
2. Update the WordPress and Site URLs
In Settings → General, change both "WordPress Address (URL)" and "Site Address (URL)" from http:// to https://. This is what tells WordPress itself to generate links using the secure protocol going forward.
3. Fix existing content (the step people skip)
Changing the settings above does not retroactively fix http:// URLs already saved inside old posts, images, and widgets. You need a proper search-and-replace across the database — a plugin like Better Search Replace, or the WP-CLI command below if you have shell access:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid4. Force the redirect at the server level
Add this to your site's .htaccess (above the WordPress block) so visitors and search engines land on HTTPS even if they land on the old http:// link from a bookmark or old backlink:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]5. Check for mixed content
Reload your homepage and a couple of inner pages with browser DevTools open (Console tab). Any remaining http:// resource — often a hardcoded image URL in an old post, or a theme setting — will show up there directly, with the exact URL to fix.
6. Update everything outside WordPress
- Google Search Console — add the https:// version as a separate property and submit a fresh sitemap.
- Google Analytics — update the default URL under property settings.
- Any hardcoded links in ads, email footers, or social profiles.
7. Handle multisite installations separately
If you're running WordPress Multisite, each site in the network has its own Site URL and Home URL values stored independently — updating the network's primary domain settings doesn't automatically cascade to every individual site's own database entries. A network-wide search-and-replace tool, capable of running across every site's tables rather than just the currently active one, is worth using here rather than repeating the process manually per site.
8. Check theme and plugin settings for hardcoded URLs
Beyond post content, some themes and plugins store their own separate URL settings — a logo image path, a custom CSS file reference, an API endpoint for a contact form plugin — independently of WordPress's core URL fields. Reviewing your active theme's customizer settings and any plugin with its own dedicated settings page is worth doing specifically for hardcoded http:// references the general database search-and-replace might not catch if they're stored in a serialized format the search tool doesn't parse correctly.
What the WordPress REST API needs separately from the standard site migration
If your site's WordPress REST API is consumed by a separate frontend application (a headless WordPress setup, a mobile app, or a JavaScript frontend), that consuming application's own API base URL configuration needs its own explicit update to https://, independent of the standard site migration steps covered above — the REST API endpoint itself follows your site's URL settings automatically, but anything calling into it externally needs its own separate update.
How page builder plugins like Elementor or Divi store URLs differently than core WordPress
Popular page builder plugins often store their page content and settings in a custom, serialized data format distinct from WordPress's standard post content field — a generic database search-and-replace tool that doesn't specifically understand this serialized format can corrupt the data rather than correctly updating it. Using a search-and-replace tool specifically documented as compatible with serialized data (most modern ones are, including WP-CLI's search-replace command) avoids this specific, page-builder-related pitfall.
Why a staging site clone is worth creating before attempting this migration on an established site
For any site with meaningful traffic or business value, cloning the site to a staging environment and running through this entire migration process there first lets you catch and fix any issues, an incompatible plugin, an unexpected serialized data problem, before they affect the live, public-facing site — most managed WordPress hosts offer a one-click staging clone feature specifically for this kind of pre-launch testing.
What multisite network considerations add if this is a network rather than a single install
For a WordPress Multisite network specifically, the database search-and-replace and URL configuration steps covered in this guide need to run across every individual site in the network, not just the primary site — a network-wide capable search-and-replace tool, covered in more detail in our dedicated multisite HTTPS guide, handles this correctly rather than requiring manual repetition per site.
How caching plugins specifically need their own cache cleared beyond WordPress's own
Popular WordPress caching plugins (WP Rocket, W3 Total Cache, and similar) maintain their own separate cached page output independent of WordPress's core behavior — clearing your specific caching plugin's cache explicitly, not just assuming a general WordPress refresh handles it, ensures visitors receive freshly rendered pages reflecting your HTTPS migration.
Why testing with a plugin conflict diagnostic approach helps if something breaks unexpectedly
If an unexpected issue appears after migration, temporarily deactivating all plugins except the essential ones and reactivating them one at a time isolates whether a specific plugin is causing the issue — a standard WordPress troubleshooting technique that applies directly to diagnosing an HTTPS-migration-related conflict.
What a rollback plan specifically looks like for a WordPress-specific migration
A WordPress-specific rollback plan should include a full database backup taken before starting the search-and-replace step specifically, since that operation is the most consequential, hardest-to-manually-reverse change in the entire migration — having a clean backup point immediately before this step provides the most reliable rollback option if something goes wrong.
A final word on why this guide's careful sequencing matters more than any individual step
Every individual step covered in this guide is straightforward in isolation — installing a certificate, updating a URL setting, running a search-and-replace — what actually causes migration problems in practice is skipping steps or doing them out of order, which is why this guide has emphasized sequence throughout rather than just listing the necessary actions.
What ongoing WordPress maintenance helps ensure this migration remains stable long-term
Keeping WordPress core, your theme, and every active plugin updated through your normal maintenance routine, combined with periodically re-running an SSL scan tool against your site, catches configuration drift or a plugin update that might reintroduce a hardcoded URL well before it becomes a visible, customer-facing problem.
A quick closing checklist to confirm before considering the migration finished
Before considering this migration complete, confirm: WordPress and Site URL settings show https://, the database search-and-replace has run successfully, the server-level redirect returns a 301, no mixed content warnings appear in DevTools, and Search Console has the https:// property added with a fresh sitemap submitted.