You can enable HTTPS on a WordPress site without buying a certificate. The important part is to secure both connections: from a visitor's browser to your site, and from your hosting server to any reverse proxy in front of it. A certificate installed only at the edge does not necessarily encrypt the connection to your server.
This guide uses a certificate provided by your web host (often through Let's Encrypt) and explains the correct Cloudflare setting when Cloudflare proxies your site. Back up your files and database first, and keep access to your hosting control panel while changing URLs or redirects.
What you need before switching
- Access to your domain's DNS settings and WordPress administrator account.
- A hosting provider that can install and renew a TLS certificate for your domain. Ask its support team if the control panel does not show a certificate or Let's Encrypt option.
- A backup and a record of your current WordPress and Site Address values.
- A certificate that covers every hostname you use, such as both
example.comandwww.example.com.
HTTPS is not a substitute for keeping WordPress, plugins, and themes updated, using strong account security, or backing up the site. It encrypts data in transit and helps browsers verify the website connection.
1. Install a certificate on your hosting server
Start with your web host's certificate or security section. Many hosts can provision and renew a free Let's Encrypt certificate for a site. Follow the host's current instructions and verify that the certificate covers the exact domain names visitors use. See Let's Encrypt and its getting-started guide for how certificates work, or ask your host which certificate process it supports.
If you use Cloudflare as a reverse proxy, add or manage the domain using its current site setup guide, but do not treat a Cloudflare edge certificate as a replacement for a certificate on the origin server. The origin is the web server that hosts WordPress.
Optional: use a Cloudflare Origin CA certificate
If all visitor traffic will continue to pass through Cloudflare, you can install a Cloudflare Origin CA certificate on the hosting server instead of using a publicly trusted certificate. Origin CA certificates are intended for the Cloudflare-to-origin connection; browsers do not generally trust them when connecting directly to the server. Keep Cloudflare proxying enabled and do not expect visitors to connect directly to the origin using this certificate.
For a site that may be accessed directly or moved to another proxy, a host-installed Let's Encrypt or other publicly trusted certificate is usually the more portable choice.
2. Secure the connection from Cloudflare to WordPress
Skip this step if Cloudflare is not acting as a reverse proxy for your site.
After a valid certificate is installed on the origin, open SSL/TLS > Overview in Cloudflare and select Full (strict). In this mode, Cloudflare encrypts traffic to the origin and verifies that the origin certificate is valid for the hostname.
Do not use Flexible for a WordPress site that needs secure logins or form submissions. Flexible encrypts the browser-to-Cloudflare connection but sends the Cloudflare-to-origin request over HTTP. That can leave credentials unencrypted on that part of the route and can also cause redirect loops. Full encrypts the origin connection but does not validate the origin certificate; use Full (strict) when the origin is correctly configured. See Cloudflare's documentation on encryption modes.
If strict mode reports an origin error, fix the certificate or hostname mismatch rather than switching to Flexible. Cloudflare documents 525 handshake errors and 526 invalid-certificate errors.
3. Set WordPress to use the HTTPS address
Once the HTTPS version of the site loads successfully, go to Settings > General in WordPress and change both WordPress Address (URL) and Site Address (URL) from http:// to https://. Keep the hostname and path otherwise unchanged. If those fields are locked or your site uses constants in wp-config.php, follow the WordPress HTTPS administration guide or ask your host to make the corresponding configuration change.
Test the homepage, a post, and /wp-admin/ over HTTPS before forcing all HTTP requests to redirect. If any of these fail, fix the certificate and site URL first.
4. Redirect visitors to HTTPS
Choose one place to enforce the HTTP-to-HTTPS redirect: your host, your WordPress setup, or Cloudflare. Avoid stacking multiple redirect rules, which can create loops or unnecessary hops.
For a Cloudflare-proxied site, Cloudflare's Always Use HTTPS option can redirect visitor requests at the edge. Read the current setting documentation and enable it only after the HTTPS site works. If your host already provides a working canonical HTTPS redirect, you may prefer to keep that as the single redirect instead.
After enabling the redirect, visit an http:// URL and confirm it reaches the corresponding https:// page once, with the correct hostname and path.
5. Find and fix mixed content
A page can load over HTTPS while still requesting an image, stylesheet, script, or font over HTTP. Browsers may block active mixed content or show security warnings for affected resources. Open the browser developer tools and check the Console and Network panels for http:// requests. The MDN mixed-content guide explains the different resource types.
Update the affected URLs at their source where possible. If old site URLs are stored in WordPress content or settings, WP-CLI can replace a specific old site prefix while safely handling serialized data. From the WordPress installation directory, preview a domain-specific replacement first:
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
Replace example.com with the exact old hostname, review the preview, and make a database backup before repeating the command without --dry-run. If your site has both www and non-www URLs in stored content, review each exact hostname separately. Do not blindly replace every http:// URL: external services may not support HTTPS, and WordPress GUIDs should not be changed. See the WP-CLI search-replace reference.
Clear relevant page, object, and CDN caches after fixing URLs, then check the affected pages again.
6. Verify the finished setup
Check the homepage, several posts, images, stylesheets, forms, and the WordPress login over HTTPS. Confirm that:
- The browser reports a valid certificate for the hostname visitors use.
- Cloudflare, if used as a proxy, is set to Full (strict) and the origin certificate covers the hostname.
- HTTP requests reach the matching HTTPS URL without a redirect loop.
- The browser console has no remaining mixed-content errors.
- The certificate renewal process is enabled and you know how your host reports renewal failures.
Keep the hosting-panel recovery path and your backup available until these checks pass. If you are locked out, use your host's recovery process to restore the correct HTTPS site settings and disable only the redirect you just added. Do not accept login or payment details over an unverified HTTP connection.
Historical screenshots from the original guide
These images are retained from the 2016 version of this article for context. They show the old Flexible SSL, plugin, and Page Rules workflow; do not use them as current setup instructions.