Column 1

How to Force HTTPS in WordPress Without Redirect Loops

WordPress HTTPS redirect checklist for certificates, final URLs, mixed content, and hosting panels

Forcing HTTPS in WordPress is safest when three pieces agree: the final public hostname has a valid certificate, WordPress generates the final HTTPS URLs, and exactly one layer redirects visitors from HTTP. Most broken migrations happen when those decisions are split among WordPress, a hosting panel, a CDN, and a redirect rule that nobody owns.

This guide is for a normal WordPress site that needs to move from HTTP to HTTPS without losing administrator access, creating redirect loops, or leaving browser mixed-content warnings behind. It also applies to WooCommerce stores, contact forms, membership sites, and managed-hosting accounts where a small URL error can affect customers.

Choose the final HTTPS address first

Decide whether the public address uses the root domain or the www host, then use that same HTTPS address everywhere: the certificate, WordPress settings, canonical tags, internal links, and the redirect destination. Do not make a separate decision in each tool.

Before changing settings, confirm that the final address already opens over HTTPS without a certificate warning. If both the root and www host can receive visitors, make sure the certificate and redirect plan account for both. A redirect cannot make an invalid certificate trustworthy.

Map who controls each layer

Domain and DNS: identify the registrar and the provider that answers DNS for the website.
Certificate: identify whether the hosting panel, CDN, or another service issues and renews it.
Public redirect: select one owner, usually the hosting panel or edge service, to send HTTP visitors to HTTPS.
WordPress URLs: confirm who can change the WordPress Address and Site Address in the dashboard.
Critical customer paths: list administrator sign-in, forms, password resets, checkout, payment return pages, and any external callback that must continue working.

Do not turn on a hosting-panel redirect, a CDN redirect, a WordPress redirect plugin, and a custom server rule all at once. Multiple owners are a common source of loops and inconsistent behavior.

Set the WordPress URLs after HTTPS works

For a standard WordPress installation, open Settings > General and confirm the WordPress Address (URL) and Site Address (URL) use the final HTTPS address. These fields can intentionally differ when WordPress lives in a separate directory, so do not force them to match without understanding the existing installation layout.

After saving, sign in again through the final HTTPS address. If the fields are locked, the address may be controlled by hosting configuration or a managed platform. Stop and identify that owner instead of repeatedly changing dashboard settings.

Use the panel control where it fits

In cPanel, the Domains interface includes a Force HTTPS Redirect control for domains that have a valid SSL certificate. cPanel directs administrators to that option for HTTP-to-HTTPS changes rather than treating it as a generic destination redirect.

In Plesk, open Websites & Domains > your domain > SSL/TLS Certificates after confirming the site is reachable with a valid certificate. SSL It! provides the Redirect from http to https option and warns administrators to confirm HTTPS is healthy before enabling it. Review webmail and subdomain coverage before applying a redirect that could affect them.

When a CDN or reverse proxy is in front of the origin, coordinate the redirect with that provider. The public edge, hosting panel, and WordPress should agree on the final scheme and hostname. Change one approved redirect owner at a time, then test before changing another layer.

Fix mixed content without adding a second redirect system

A secure page can still show a warning when a theme, page builder, image, stylesheet, font, script, or embedded service points to HTTP. Inspect a representative public page and the browser's security information, then correct the specific source that still uses HTTP. Do not mask a content problem by adding competing redirects.

Use the mixed-content troubleshooting guide for that focused repair. Keep the redirect decision in one place and the content cleanup in another; they solve different problems.

Verify the customer path

Enter the HTTP version in a clean browser session and confirm it reaches the chosen HTTPS address in one predictable step.
Open a few public pages, a media-heavy page, and the XML sitemap. Confirm the canonical URL is HTTPS.
Sign in to WordPress, save a non-production setting, and confirm the dashboard remains on the expected address.
Send a test through a contact form and complete a normal WooCommerce checkout path when the site uses one.
Check password-reset emails, payment return pages, and external integrations that may retain an old HTTP callback address.
Clear the approved application, host, and CDN caches only after the final URL and redirect behavior are correct.

When to pause

Pause the change when HTTPS itself displays a certificate warning, HTTP and HTTPS bounce between each other, administrator access moves to an unexpected hostname, or a form or checkout stops working. Revert only the most recent redirect or URL decision through the approved control, then identify the conflicting owner. Avoid stacking emergency rules across WordPress, the panel, and a CDN.

Once HTTPS is stable, consider HSTS only after every covered hostname, subdomain, and webmail path has valid certificate coverage. Plesk cautions that an unsuitable HSTS lifetime can prevent visitors from reaching a site when the certificate does not remain valid.