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 →To secure WordPress pages with SSL, first enable a trusted TLS certificate for every hostname your visitors use. Then switch both WordPress URLs to HTTPS, redirect HTTP traffic, and fix any page resources that still load over HTTP. WordPress cannot provide HTTPS on its own: the certificate must be installed and served by your host, web server, CDN, or reverse proxy.
Before you switch WordPress to HTTPS
SSL is the familiar name for the technology now implemented as TLS. WordPress uses HTTPS once the web server can present a valid certificate for the requested domain. WordPress’s HTTPS guidance says a TLS/SSL certificate must be installed and available to the web server before HTTPS administration can work.
- Check every hostname: If visitors can reach your site at both
example.comandwww.example.com, make sure the certificate covers both. Also check any other active hostname you intend to serve. - Back up the site: Save the WordPress database and files before changing URLs or redirect rules, so you can restore the prior configuration if the migration breaks access.
- Know where HTTPS terminates: Your host, web server, CDN, or reverse proxy may manage the certificate. Follow that provider’s current setup instructions; the correct steps depend on the hosting arrangement.
Switch WordPress pages from HTTP to HTTPS
- Enable and verify the certificate. Activate TLS for the site’s hostnames through your hosting control panel or the service that terminates HTTPS. Confirm that opening the HTTPS version of the domain presents a valid certificate before changing WordPress settings.
- Preserve the original protocol behind a proxy. If a CDN or reverse proxy connects to WordPress over HTTP while the visitor connects over HTTPS, configure the proxy to pass the original protocol, commonly with
X-Forwarded-Proto: https. If WordPress does not recognize the visitor’s request as HTTPS, it may repeatedly redirect between HTTP and HTTPS. - Update both WordPress URLs. In the dashboard, open Settings → General. Change both WordPress Address (URL) and Site Address (URL) to their
https://versions, then save. These settings identify where WordPress is installed and the public site address; both should use the intended secure hostname. - Redirect HTTP requests. Configure a single canonical HTTP-to-HTTPS redirect at the host or web-server layer. Test the HTTP and HTTPS versions of each active hostname, including apex and
www, to confirm that they reach the intended HTTPS address without looping. Let’s Encrypt recommends offering a configurable HTTP-to-HTTPS redirect, in part because existing sites may contain HTTP subresources; see its integration guide. - Check the site and its key functions. Visit representative pages, sign in, test forms and media, and check embeds and REST/API endpoints. WordPress 5.7 added HTTPS detection and migration improvements to Site Health; use the dashboard’s Site Health checks alongside browser testing.
If changing the URLs locks you out, use your host’s documented database or wp-config.php recovery method to restore access or correct the values. Remove any temporary configuration overrides after the migration; leaving them in place can make later URL changes harder.
Fix mixed content when a page still looks insecure
Mixed content occurs when an HTTPS page requests a resource using HTTP—for example, an image, script, stylesheet, embed, or font. A certificate can be valid while a page still has this problem. Depending on the resource and browser, insecure content may be blocked or the page may lose its secure indicator.
#1 Best Overall
- Open an affected page in a browser and inspect the developer console for requests that begin with
http://. - Identify where each URL comes from: it may be hard-coded in a page or post, stored in the database, or supplied by a theme, plugin, embed, or external service.
- Update the source to use HTTPS where the resource supports it. For URLs stored across the database, back up first and use a migration method that safely handles WordPress’s serialized data; a blind database-wide text replacement can damage stored settings.
- Reload the affected page and check the console again. Repeat on other pages with insecure requests.
Mixed content can affect individual pages rather than the whole site, so one page may show as secure while another does not. WordPress.com’s HTTPS support guidance explains this page-by-page behavior.
Why WordPress may still say “Not secure”
- Certificate warning: Check that the certificate matches the exact hostname in the address bar, is within its validity period, and chains to a trusted certificate authority. Confirm that the server is presenting the current certificate.
- Mixed-content warning or missing padlock: Inspect the page’s browser console for HTTP resources and update their source URLs, as described above.
- Some pages work, others do not: Check each affected page separately; its images, scripts, stylesheets, or embeds may differ from those on secure pages.
- Redirect loop: Check that the reverse proxy or CDN forwards the original protocol and that WordPress interprets the request as HTTPS. Also review for overlapping redirect rules at the proxy, host, and web-server layers.
- Admin lockout after forcing HTTPS: Revert the forcing setting through the recovery method documented by your host, fix certificate or proxy detection first, and enable it again only after HTTPS works.
Force secure logins and administration
Once the certificate and HTTPS host are working, you can require WordPress logins and administration sessions to use SSL. Add this line to wp-config.php:
Rank #2
define( 'FORCE_SSL_ADMIN', true );
WordPress documents this constant for forcing logins and admin sessions over SSL in its HTTPS administration guidance. Do not use it as a substitute for configuring server-side TLS: if WordPress or a proxy misidentifies the connection protocol, forcing SSL can trigger a redirect loop or lock you out.
Keep certificates renewed automatically
Let’s Encrypt describes its certificates as valid for 90 days and recommends renewal about 30 days before expiration. Because certificates have a short lifetime, arrange automatic renewal through your host or ACME client rather than relying on manual renewal. Confirm that renewal is enabled and that the renewed certificate is actually served by the site. See Let’s Encrypt’s integration guidance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Add HSTS only after HTTPS is stable
HTTP Strict Transport Security (HSTS) tells compatible browsers to use HTTPS for a site. It is a hardening measure, not a first step in the migration: browsers can cache the policy, and a cached policy can make a site inaccessible if HTTPS is later removed or unavailable. Let’s Encrypt warns about that risk in its integration guide.
First confirm that all intended hostnames work over HTTPS and that redirects and subdomains behave correctly. Then introduce a conservative HSTS policy and expand it only after you have verified the effect of including additional subdomains. Avoid enabling a policy that commits subdomains you have not confirmed can serve HTTPS.
Quick Recap
Best Value
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.
