Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Move a WordPress site to HTTPS in a controlled order: back up the files and database, install and test a TLS certificate, change both WordPress URL settings, replace stored HTTP links, remove mixed content, add permanent redirects, update search signals, and test every public and administrative function. Changing only the address in WordPress is not enough; old links, cached assets, integrations, and proxy settings can still keep the site partly on HTTP.
This guide covers the full migration and gives you a rollback path. It applies whether TLS terminates on your origin server, a CDN, or a reverse proxy.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
What changes when a WordPress site moves to HTTPS?
HTTP and HTTPS are different URL schemes. A page at http://example.com/about/ and one at https://example.com/about/ are separate URLs to browsers and search engines, even when they serve identical content. A successful migration makes the HTTPS version canonical, sends visitors and crawlers from every old HTTP URL to its HTTPS counterpart, and removes insecure references inside the site.
HTTPS works when a valid TLS/SSL certificate is installed and available for the web server to use. WordPress describes itself as fully compatible with HTTPS under that condition. The certificate may be installed on the origin server, a CDN, or a reverse proxy; whichever component accepts the browser connection must present a valid certificate, and the connection from that component to the origin must be configured consistently.
- URL settings: WordPress must generate HTTPS links for the home page, admin area, feeds, and APIs.
- Stored content: Posts, widgets, custom fields, theme options, and plugin settings can contain absolute HTTP URLs.
- Browser security: HTTP scripts, styles, fonts, frames, images, and API calls loaded by an HTTPS page create mixed content. Active resources can be blocked.
- Search signals: Canonicals, internal links, XML sitemaps, feeds, hreflang, and structured-data URLs must agree on HTTPS.
- Infrastructure: Redirects, caches, webhooks, cron jobs, and proxy headers must all recognize the new scheme.
Plan a maintenance window if the site handles orders, registrations, or frequent publishing. Keep the HTTP endpoint reachable for redirects after the switch; taking it offline removes the path by which old links are migrated.
Before changing anything: prerequisites and a rollback plan
Do not edit the WordPress URLs until HTTPS already works in a browser. Complete these checks first:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- You can log in to the hosting control panel, server, CDN, or reverse proxy that terminates TLS.
- The certificate covers the exact hostnames visitors use, including the chosen
wwwor non-wwwform and any required subdomains. - You have a recent copy of every site file and a database export stored outside the live document root.
- You know whether
WP_HOMEorWP_SITEURLis defined inwp-config.php; constants override values entered on the General Settings screen. - You can edit redirect rules and clear caches at the web server, CDN, and WordPress layers.
- You have access to both HTTP and HTTPS properties (or URL-prefix variants) in Google Search Console.
Write down the current canonical hostname, home URL, login URL, hosting topology, and any special integrations. If a change causes an outage, you should be able to restore the database and files, temporarily remove the redirect, and return the URL settings to their previous values.
Step 1: Back up the files and database
WordPress’s migration guidance places file and database backups before URL changes. Make both backups even if your host advertises automatic snapshots.
Download the site files
Copy the entire WordPress installation, including wp-content/uploads, themes, plugins, and wp-config.php. Store the archive outside the directory served by the web server and, ideally, in a second location. Confirm that the archive can be opened and that its size is plausible.
Export the database
Use your host’s export function or WP-CLI. A typical WP-CLI export is:
Recommended Free Tools
wp db export ../wordpress-before-https.sqlRun it from the WordPress directory, adjust the destination to a protected location, and verify that the SQL file was created. If the database is large, use the host’s documented dump method and record the database name, table prefix, and character set.
Record dynamic data
Note the time of the backup and pause jobs that write important data if practical. For a busy shop or membership site, schedule the final database export close to the URL change so new orders or registrations are not omitted. Do not place backup archives in a publicly downloadable folder.
Step 2: Install and verify the TLS certificate
Install a certificate through the origin server, CDN, or reverse proxy that receives browser traffic. Configure the HTTPS virtual host with the correct document root, PHP handler, and certificate chain. If TLS terminates at a proxy, also configure the proxy-to-origin connection and the header that tells WordPress the original request was HTTPS.
Test HTTPS before touching WordPress
- Open the exact HTTPS home URL in a private browser window.
- Open a known post, an image URL,
/wp-login.php,/robots.txt, and/sitemap.xml(if your site has one). - Confirm that the certificate is valid, trusted, unexpired, and issued for the hostname in the address bar.
- Check that the HTTPS virtual host serves this WordPress installation rather than a default server page.
- Use browser developer tools or a header checker to confirm that the response is coming from the intended CDN, proxy, or origin.
Do not interpret a certificate warning as a WordPress problem. Fix hostname coverage, certificate-chain, DNS, or server-binding errors first. Keep HTTP available while you test; the redirect is added later.
Reverse-proxy warning
When a proxy accepts HTTPS and forwards plain HTTP to the origin, WordPress can believe every request is insecure unless the forwarded-protocol information is trusted and mapped correctly. That mismatch commonly creates an infinite redirect loop after HTTPS is enabled. Configure the proxy and origin according to your hosting platform’s documented forwarded-header method; do not blindly add a PHP constant without knowing which proxy is trusted.
Step 3: Change WordPress Address and Site Address
Once the HTTPS URL loads correctly, change both URL values. In the WordPress dashboard go to Settings → General and edit:
- WordPress Address (URL): the location of the WordPress core files.
- Site Address (URL): the public address visitors use.
Change each value from http:// to https://, keep the same hostname and path, and omit a trailing slash. Save the settings once. You may be logged out because the authentication cookies are now scoped to HTTPS; sign in again at the HTTPS login URL.
When constants control the values
If wp-config.php defines WP_HOME or WP_SITEURL, the dashboard fields may be disabled or may not persist. Update the constants instead, for example:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Use your real hostname and path. Do not define one value in wp-config.php and a conflicting value in the database. WordPress’s URL migration implementation updates the home and siteurl options to their HTTPS variants; those are the same two settings represented on the General screen.
Step 4: Replace old HTTP URLs in the database and files
Changing the two options does not rewrite every URL stored elsewhere. Search for the old origin in posts, reusable blocks, widgets, menus, theme settings, plugin settings, custom fields, and any configuration files or templates.
Use a serialized-data-safe replacement
WordPress documentation identifies search-and-replace plugins and WP-CLI as supported approaches. Use a tool that understands PHP serialized data; a raw SQL replacement can corrupt string lengths and break options or widgets.
With WP-CLI, first perform a dry run across tables that use the site’s prefix:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutewp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-runReview the reported locations and count. If the result is correct, run the same command without --dry-run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefixInclude the exact old hostname, including www when applicable. If the site used several HTTP hostnames or subdirectory paths, run separate, reviewed replacements. A database search should not rewrite third-party URLs that merely happen to contain a similar string.
Handle GUIDs deliberately
Post GUID values are identifiers rather than display links. Many migration procedures leave them unchanged, while some installations have a policy that requires updating them. Decide this before running a replacement and follow the documented behavior of the tool you choose; never use an unverified SQL statement that bypasses serialized-data handling.
Inspect files and generated settings
Search theme templates, child-theme files, CSS, JavaScript, environment files, and deployment configuration for hard-coded http:// references. Also check image optimization, caching, analytics, form, and page-builder settings. A replacement in the database cannot change a URL embedded in a PHP template or a static asset deployed outside the database.
Rank #3
Step 5: Find and remove mixed content
Load an HTTPS page, open the browser developer console, and reload without relying on a stale cache. Look for mixed-content warnings and blocked requests. Inspect the page source and the Network panel for requests beginning with http://.
Resources that commonly cause warnings
- Images and background images in post content or CSS.
- JavaScript and CSS files enqueued by themes and plugins.
- Web fonts and font stylesheets.
- iframes, video players, maps, and other embeds.
- AJAX, REST, webhook, and third-party API calls.
- Form actions and login or checkout endpoints.
Replace each URL with an HTTPS endpoint offered by the same provider, or remove the dependency. Do not simply hide warnings with a browser setting. Active mixed content, especially JavaScript, CSS, fonts, and iframes, can be blocked or can undermine the security of the page. If a provider has no HTTPS endpoint, choose a secure alternative or host the asset yourself where licensing permits.
When the source looks clean but the warning remains
Check CSS loaded from a cache, inline styles generated by a page builder, responsive image attributes, redirects from an HTTPS URL to HTTP, and content injected after page load. Purge page, object, CDN, and browser caches only after fixing the source, then retest in a private window. Test a logged-in page separately because admin-only plugins often enqueue different assets.
Step 6: Redirect every HTTP URL to its HTTPS counterpart
After HTTPS pages and content work, add a permanent redirect at the earliest reliable layer: web server, CDN, or edge proxy. Each old URL should keep its path and query string. For example, an HTTP request for /guide/?print=1 must become the same path and query on HTTPS, not merely redirect to the home page.
Apache example
In the HTTP virtual host or the appropriate rewrite configuration, a common pattern is:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L,NE]Use the hostname that is canonical for your site. The exact placement depends on whether Apache, a control panel, or another layer owns the virtual host. Test that this rule does not intercept an already-HTTPS request.
Nginx example
A separate HTTP server block commonly contains:
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}Adapt the server names and IPv6 configuration to your deployment. If a CDN or load balancer handles redirects, configure the rule there instead of creating competing rules at multiple layers.
Test redirects for chains and loops
- Request the bare HTTP home page.
- Request an old deep link, an attachment, and a URL with a query string.
- Confirm one redirect goes directly to the matching HTTPS URL.
- Check that the final HTTPS response is successful and does not redirect back to HTTP.
- Test both the
wwwand non-wwwhostnames if both have existed.
Keep the HTTP listener and DNS route available for these redirects. Removing the old endpoint prevents search engines and bookmarked visitors from reaching the migration rule.
Step 7: Align SEO signals and monitor the move
Google treats a protocol change as a site move. Redirects and consistent canonical signals tell crawlers which version to index, but crawling can temporarily increase after a migration, so monitor the site rather than assuming the change is instantaneous.
Update on-site signals
- Canonical link elements should use the HTTPS URL.
- Internal links, navigation, pagination, and attachment links should use HTTPS.
- XML sitemaps and RSS or Atom feeds should list HTTPS URLs.
- Hreflang alternates should point to the HTTPS version of every language or region URL.
- Structured-data fields such as
url,image, andlogoshould use HTTPS where they describe your site. - Open Graph and other social metadata should not point to HTTP.
robots.txtshould remain reachable over HTTPS and should reference the HTTPS sitemap.
Use Search Console methodically
- Verify the HTTPS property and retain the HTTP property so you can compare old and new URLs.
- Inspect representative HTTPS home, post, category, media, and feed URLs.
- Submit the HTTPS sitemap after confirming its contents.
- Watch indexing, redirect, crawl, and “Not found” reports for missing paths or accidental URL changes.
- Investigate traffic or coverage changes by URL pattern rather than reacting to a single day’s data.
Do not block the old HTTP URLs in robots.txt while redirects are being discovered. Crawlers need to fetch them to see the permanent redirect.
Step 8: Test the complete live site
Run the following checks from an anonymous browser session and then while logged in:
- Home page, posts, pages, categories, tags, search, author archives, and 404 pages.
- Images, downloadable files, video, audio, and responsive variants.
- Login, logout, password reset, registration, comments, and profile updates.
- Contact forms, newsletter forms, carts, checkout, payment return URLs, and confirmation emails.
- REST API endpoints, XML-RPC if intentionally enabled, AJAX actions, webhooks, and third-party callbacks.
- Scheduled tasks, external cron jobs, feeds, and cache warmers.
robots.txt,sitemap.xml, canonical tags, structured data, and redirects.- CDN, reverse-proxy, image-optimization, and cache behavior on both desktop and mobile.
Submit a test form and, if applicable, a low-value test transaction. Confirm that email providers, payment services, identity providers, and webhook senders accept the HTTPS callback URL. Check server logs for HTTP requests that are not redirects, TLS handshake errors, PHP warnings, and repeated redirect responses.
Free tools Windows power users keep installed
One-click scans. No signup required.
WordPress 5.7 and automatic HTTPS handling
WordPress 5.7 introduced improved HTTPS detection and migration support. When WordPress recognizes that the site is HTTPS and the domains match, core can replace insecure home URLs in front-end output. This is useful for legacy content, but it is conditional and is not a substitute for a complete audit. Plugin settings, theme files, external embeds, CSS, JavaScript, and arbitrary database fields can still contain HTTP values. Treat automatic replacement as a safety net, not proof that the migration is finished.
Common failure modes and precise fixes
“Too many redirects” after enabling HTTPS
Check whether the proxy terminates TLS while the origin receives HTTP. Configure the trusted forwarded-protocol header and ensure only one layer owns the HTTP-to-HTTPS redirect. Clear CDN and application caches, then test the origin path separately if your host permits it.
The dashboard is inaccessible after changing the URLs
Use the HTTPS login URL. If a typo or wrong path was saved, temporarily correct WP_HOME and WP_SITEURL in wp-config.php, or update the home and siteurl options directly through the hosting database tool. Remove the temporary override after the correct values are restored.
The padlock is missing on some pages
Use developer tools to identify every HTTP request, including those generated by CSS, JavaScript, iframes, fonts, and delayed scripts. Fix the originating plugin, theme, database field, or external provider; then purge caches and reload.
Images or downloads return 404 errors
Verify that the HTTPS virtual host uses the same document root and that rewrite rules preserve the path. Check case-sensitive filenames, upload directories, CDN origin paths, and attachment URLs generated before the migration.
Forms or webhooks stop working
Inspect the form action and callback URL, then update the remote service’s allowlist or endpoint. Confirm that the service follows the redirect or, preferably, is configured directly with the HTTPS URL. Review firewall, CORS, authentication, and signature settings separately from WordPress URL settings.
Search traffic or indexed URLs look wrong
Confirm that HTTPS canonicals, sitemap entries, internal links, hreflang, and structured data are consistent. Check that HTTP URLs return a single permanent redirect and that no redirect points to an unintended hostname or path. Continue monitoring both protocol properties in Search Console.
Choosing where TLS should terminate
The migration steps are similar, but operational responsibility differs by architecture.
| Approach | Where TLS terminates | Database and serialized data | Redirect control | Backup, staging, and rollback | Renewal ownership |
|---|---|---|---|---|---|
| Origin server | The WordPress web server presents the certificate. | You or the host run a serialized-data-safe replacement and verify the origin directly. | Apache or Nginx rules usually provide the redirect. | Managed by the server or hosting workflow; maintain an independent backup. | Server administrator or hosting provider. |
| CDN or edge | The CDN presents the public certificate; traffic is forwarded to the origin. | The WordPress database still needs the same careful replacement. | Configure the edge redirect and avoid a second rule that creates a chain. | Coordinate cache purges, staging, and origin rollback with the CDN. | CDN account owner, unless the provider automates it. |
| Reverse proxy or load balancer | The proxy presents the certificate before forwarding to WordPress. | Use the same backup and serialized-data safeguards. | Proxy rules and origin rules must agree on the forwarded protocol. | Test health checks and failover paths as well as the primary origin. | Proxy or platform administrator. |
Choose the arrangement your team can monitor and renew reliably. The certificate location does not remove the need to update WordPress URLs, stored content, redirects, or SEO signals.
Rollback if the migration causes an outage
- Disable or soften the new redirect while keeping the server reachable.
- Restore the previous URL values, either in the General Settings screen or by removing temporary constants and correcting the database options.
- Restore the pre-migration database and files only if data has been captured since the backup or the replacement damaged serialized values.
- Clear application, CDN, and browser caches.
- Review web-server, PHP, proxy, and browser-console logs to identify the failing layer.
- Fix one issue at a time on staging or a maintenance copy, then repeat the migration sequence.
Do not delete the certificate or DNS records as a first response; doing so removes the evidence and endpoint needed to diagnose the problem.
Quick Recap
A practical completion checklist
- Verified backups exist outside the document root and can be restored.
- HTTPS certificate and virtual host serve the correct site.
- Both WordPress URL settings use matching HTTPS URLs with no trailing slash.
WP_HOMEandWP_SITEURLdo not conflict with database values.- Database and file searches replaced old first-party HTTP URLs safely.
- No mixed-content requests remain on representative pages.
- HTTP redirects preserve paths and query strings without chains or loops.
- Canonicals, links, sitemaps, feeds, hreflang, and structured data use HTTPS.
- Search Console properties, sitemap submission, and indexing reports are being monitored.
- Forms, commerce, APIs, webhooks, cron, robots.txt, certificate renewal, and proxy paths have passed live tests.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
