Homepage redirect
Opening the HTTP version of the homepage should redirect to the HTTPS version automatically.
HTTP to HTTPS redirect
An HTTP to HTTPS redirect ensures that anyone visiting the insecure version of your site is sent to the secure HTTPS version automatically. This check helps confirm that WordPress, the server, and the public URL all point to a single secure destination instead of leaving HTTP accessible as a parallel version.
For broader launch validation, use the WordPress pre-launch checklist. You should also verify that HTTPS is correctly enabled in WordPress so the secure destination itself is valid before redirect behavior is assessed.
Why this matters
Redirecting HTTP to HTTPS is one of the core technical checks before publishing or handing off a WordPress site. It helps consolidate the secure version of each URL, reduces duplication between HTTP and HTTPS, and supports a cleaner canonical setup for search engines. It also improves trust and avoids leaving visitors on an outdated insecure version of the site.
If HTTP does not redirect properly, the site can expose two live versions of the same content, create inconsistent indexing signals, and weaken the final setup of the website before launch. This becomes more problematic when meta robots, canonicals, sitemap references, or internal links are not aligned with the secure version.
What to review
Before marking this check as correct, review the following points:
Permanent redirect
The redirect should be permanent, not a temporary workaround.
Single-step resolution
The final destination should resolve in a single step whenever possible.
No parallel HTTP version
HTTP should not remain accessible as a separate indexable version.
Consistent secure signals
Canonical, sitemap, and internal links should consistently use HTTPS.
How PreFlight checks this check
PreFlight requests the HTTP version of the site and verifies whether the final resolved URL uses HTTPS. It also reviews the redirect behavior to detect missing redirects, inconsistent destinations, or setups where the insecure version remains available instead of being consolidated into the secure version.
This check is focused on the existence and outcome of the redirect. It does not replace a full server audit, but it helps identify whether the site behaves as expected from the outside before delivery.
PASS / WARN / FAIL
The HTTP version redirects correctly to the HTTPS version, the destination is clear, and the secure version is the one consistently exposed as the public URL.
A redirect exists, but the setup may be weaker than expected. For example, the redirect may rely on extra hops, mixed signals, or an inconsistent final destination that should be cleaned up before launch.
The HTTP version does not redirect to HTTPS correctly, remains accessible as its own version, or resolves in a way that leaves the secure version unconsolidated.
Common mistakes
Leaving both HTTP and HTTPS accessible at the same time.
Using a temporary redirect instead of a permanent one.
Creating redirect chains before reaching the final HTTPS URL.
Updating the certificate but forgetting to force HTTPS.
Keeping canonicals, sitemap entries, or internal links on HTTP.
FAQ
Is HTTPS alone enough if the site already loads securely?
No. The HTTPS version can work and still leave the HTTP version accessible. This check is about forcing all traffic to the secure version consistently.
Should this redirect be permanent?
In normal launch conditions, yes. A permanent redirect is the expected setup when the public version of the site is HTTPS.
Can this affect SEO?
Yes. If HTTP and HTTPS coexist, search engines may receive inconsistent signals about which version should be indexed and treated as canonical.
Check your WordPress site before delivery
Reduce rework, catch last-minute issues and review critical points before launch.