Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

To secure WordPress with SSL, first install a trusted TLS certificate on the server, host, CDN, or reverse proxy. Then change both WordPress URLs to https://, redirect HTTP traffic, remove mixed-content requests, and verify renewals. WordPress cannot provide HTTPS by itself: the web server must present a valid certificate before secure URLs and administration can work.

What SSL does for a WordPress site

“SSL” is the older term; modern connections use TLS. The certificate encrypts traffic between a visitor and the HTTPS endpoint, proves that the certificate covers the requested hostname, and lets browsers establish a trusted connection. WordPress is compatible with HTTPS when a TLS/SSL certificate is installed and available to the web server.

The certificate must cover every hostname visitors actually use. If both example.com and www.example.com are active, configure coverage and redirects for both. A certificate for only one hostname will still produce browser warnings on the other.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose where HTTPS terminates

Route Advantages Responsibilities
Managed WordPress host Certificate issuance, installation and renewal are often automated. Confirm all required domains are included and that the host serves the renewed certificate.
Self-managed web server Full control over certificate clients, web-server rules and deployment. Configure the ACME client or certificate files, reload the server safely and monitor expiry.
CDN or reverse proxy HTTPS can be handled at the edge, with caching and other traffic controls. Install or enable TLS at the proxy and pass the original protocol to the origin so WordPress knows a request was HTTPS.

In a proxy setup, the origin must receive the correct forwarded protocol, commonly X-Forwarded-Proto: https. If the proxy serves HTTPS but the origin believes every request is HTTP, WordPress can repeatedly redirect and create a loop.

Migration checklist: HTTP to HTTPS

  1. Confirm certificate readiness

    Enable a trusted certificate for each active hostname and test the HTTPS URL before changing WordPress settings. Check the certificate’s hostname, expiration date and trust chain.

  2. Back up the site

    Save a current database dump and copies of the WordPress files. URL replacement and redirect changes are reversible only if you can restore the original data and configuration.

  3. Enable HTTPS at the infrastructure layer

    Use your host’s current certificate process, configure the web server, or enable TLS on the CDN/reverse proxy. Do not add WordPress HTTPS constants as a substitute for a working server certificate.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  4. Change both WordPress URLs

    In the dashboard, open Settings → General. Change both WordPress Address (URL) and Site Address (URL) from http:// to their https:// equivalents, then save.

    If the change locks you out, use the hosting provider’s documented database or wp-config.php recovery method to restore access. Remove temporary overrides after the migration so the dashboard values are authoritative.

  5. Redirect HTTP to the canonical HTTPS URL

    Create one permanent HTTP-to-HTTPS redirect at the hosting or web-server layer. Test the bare domain, the www variant and representative old URLs. Keep one canonical hostname rather than chaining several redirects.

  6. Update stored and hard-coded URLs

    Replace old absolute http:// references in content, widgets, theme files, custom CSS, embeds and database fields with HTTPS or protocol-relative site-aware URLs. Back up before running any database replacement, and use a migration tool only if you can review its scope and compatibility.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Fix mixed content and missing padlocks

Mixed content occurs when an HTTPS page still requests an image, JavaScript file, stylesheet, font, iframe or other resource over http://. Browsers may block active resources, omit the padlock or show a warning. It is page-specific, so one URL can appear secure while another still fails.

Find the insecure request

  • Open the affected page in a current browser.
  • Open Developer Tools and inspect the Console for “Mixed Content” messages.
  • Record the exact HTTP resource and identify whether it comes from post content, a plugin, the theme, an embed or a database value.

Correct the source

  • Edit image, script, stylesheet and embed URLs to use https://.
  • Update plugin or theme settings that contain an old site URL.
  • Replace third-party resources that do not support HTTPS; do not leave an insecure fallback for convenience.
  • Clear page, object and CDN caches, then retest the page and its source.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Force secure logins and administration

After server-side HTTPS works, add this line to wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

WordPress uses this constant to force login pages and administration sessions over SSL. Add it only after the certificate, proxy protocol handling and normal HTTPS front end are confirmed. If it causes an admin lockout, temporarily remove or disable the constant using your host’s documented recovery path, correct HTTPS detection, and then enable it again.

Verify the finished migration

Use Tools → Site Health and browser checks. WordPress 5.7 added HTTPS detection and migration improvements to Site Health.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Load the home page, several content pages, search results and attachment or media URLs over HTTPS.
  • Sign in, open the dashboard and test logout, password-reset links and forms.
  • Submit contact, comment or checkout forms where applicable.
  • Check images, scripts, stylesheets, fonts, video embeds and iframes.
  • Test REST and other API endpoints used by plugins or the theme.
  • Confirm HTTP requests reach HTTPS in one redirect and that the chosen apex or www hostname is canonical.
  • Inspect the certificate served to visitors for hostname coverage, validity and a complete trust chain.

Certificate renewal: Let’s Encrypt’s 90-day cycle

Let’s Encrypt describes its certificates as valid for 90 days and recommends renewing about 30 days before expiration. Manual renewal is therefore risky. Enable the host’s automatic renewal or configure an ACME client, and verify that the renewed certificate is actually deployed by the web server or proxy.

  • Check the renewal job, timer or host status rather than assuming it is enabled.
  • Confirm the renewal process can complete domain validation.
  • After a renewal, test the live endpoint and certificate expiry date.
  • Keep an alerting path for failed renewals, especially on self-managed servers.

Add HSTS only after HTTPS is dependable

HTTP Strict Transport Security (HSTS) tells compatible browsers to use HTTPS for a domain. It is a hardening step, not a repair for an incomplete migration. Start with a conservative policy after every hostname, subdomain, redirect and application endpoint works over HTTPS. Expand the policy only when you are certain HTTPS will remain available: cached HSTS can make a site inaccessible if it later moves to hosting without working HTTPS.

Troubleshooting by symptom

Symptom Likely checks
“Not secure” or no padlock Inspect hostname coverage, expiry, trust chain and browser-console mixed-content errors.
Redirect loop Verify the reverse proxy sends the original protocol and that WordPress interprets the forwarded HTTPS request correctly.
Only some pages are insecure Inspect each affected page; mixed content is commonly caused by page-specific HTTP resources.
Admin lockout after forcing SSL Temporarily revert FORCE_SSL_ADMIN, repair certificate or proxy HTTPS detection, then re-enable it.
Certificate expires unexpectedly Check automated renewal, domain validation and deployment; a 90-day lifetime makes manual renewal unreliable.

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.