HTTPS Redirect & Canonical URL Checker
Test all 4 domain permutations (http://, http://www., https://, https://www.) to verify seamless 301 HTTPS canonicalization.
Understanding HTTPS Canonicalization & the 4-Variant Redirect Problem
What This Tool Actually Checks
Every domain has 4 distinct entry points that a visitor, search engine crawler, or old backlink can arrive through: http://example.com, http://www.example.com, https://example.com, and https://www.example.com. This tool issues a live HTTP request to each of the 4 variants in parallel, follows any redirect chain the server returns, and records the final destination URL, the HTTP status code, and whether that final destination loaded over HTTPS.
It then compares the 4 final destinations. If all 4 variants land on the exact same HTTPS URL, the domain is reported as fully canonical and secure. If even one variant fails to upgrade to HTTPS, or resolves to a different final URL than the others, the tool flags it as a redirect gap and lists the specific issue.
How to Use It
- Enter a bare domain name (e.g.
example.com) — you don't need to include a protocol or the www prefix. - Click Test 4 Variants. The tool fires all 4 requests concurrently with an 8-second timeout per variant.
- Review the scorecard at the top: it shows the primary canonical destination and whether the domain passed with "Clean 301 HTTPS" or has "Redirect Gaps Found."
- Expand each of the 4 permutation rows to see exactly which variant was tested and where it actually ended up.
- If issues are listed, use them as a direct to-do list for your web server or WordPress site configuration.
Why 4 Variants Matter: Canonicalization, Not Just Encryption
Moving from HTTP to HTTPS is only half the job. Search engines and browsers treat http://example.com, https://www.example.com, and the other 2 permutations as 4 separate URLs unless the server explicitly tells them otherwise. Without a single canonical destination, link authority, crawl budget, and analytics data can fragment across multiple "versions" of the same page.
The correct fix is an HTTP 301 Moved Permanently redirect (not 302) chaining every non-canonical variant to one final HTTPS URL. A 301 is cached indefinitely by browsers and passes essentially all link equity to the destination, while a 302 signals a temporary move and search engines will continue to index the original URL alongside the new one.
HSTS (HTTP Strict Transport Security) complements this: once a browser has seen an HSTS header from your domain, it rewrites http:// requests to https:// internally before any network request is sent, removing the unencrypted round trip entirely. You can verify HSTS separately with our SSL/TLS Configuration Checker.
Worked Example
Testing a domain with a correctly configured HTTPS canonical setup typically produces a result like this:
http://example.com→ HTTP 301 →https://example.com/http://www.example.com→ HTTP 301 →https://example.com/https://example.com→ HTTP 200 →https://example.com/(already canonical)https://www.example.com→ HTTP 301 →https://example.com/
All 4 destinations match, so the report shows "100% Fully Canonical & Secure." Now contrast that with a common misconfiguration: http://www.example.com returns HTTP 200 directly, serving the full page over plaintext instead of redirecting. The tool flags this immediately as "1 variant(s) failing to redirect to HTTPS," because any visitor or old link using the www-prefixed HTTP URL is now browsing an unencrypted, non-canonical copy of the site.
Practical Use Cases
- Post-migration verification: After moving a WordPress site to a new host or CDN, agencies re-run this check to confirm the new server block still enforces the same canonical redirects as before.
- Pre-launch QA checklist: Before pointing DNS at a new server, developers confirm all 4 variants converge correctly rather than discovering the gap after go-live traffic starts arriving.
- SEO migration audits: When consolidating www and non-www versions of a domain (a common technical SEO cleanup task), this tool confirms the redirect direction actually took effect site-wide, not just on the homepage.
- Client hosting handoffs: Agencies inheriting a client's existing WordPress install use this as a quick first check for legacy HTTP fallback holes left over from an incomplete SSL certificate installation.
Common Mistakes & Limitations
- Mismatched WordPress Site Address: If
wp-config.phpor Settings > General has a hardcodedsiteurlthat doesn't match the tested domain, WordPress itself can issue redirects that fight your web server's rules. - CDN "Flexible SSL" loops: If a CDN edge terminates HTTPS but forwards plaintext HTTP to an origin that also insists on HTTPS, you get an infinite redirect loop rather than a clean 301 chain. This tool will show a connection failure or excessive hop count in that scenario.
- This tool checks canonicalization, not certificate health: A site can pass this 4-variant check while still running an expired or misconfigured TLS certificate — that's a separate audit, covered by the SSL/TLS Configuration Checker.
- One-time snapshot: Results reflect the redirect behavior at the moment of the test. Server configuration changes, plugin updates, or CDN rule edits made afterward are not monitored continuously.
Frequently Asked Questions
Why must all 4 URL variants redirect to a single HTTPS destination?
Every website has 4 distinct entry points: http://example.com, http://www.example.com, https://example.com, and https://www.example.com. If any variant fails to redirect to HTTPS, users and search engines can access insecure pages, splitting SEO link authority and exposing cookies.
What is the recommended redirect code for HTTPS canonicalization?
Use HTTP 301 (Moved Permanently). A 301 redirect passes 100% of SEO link equity to the canonical HTTPS version and is cached permanently by web browsers.
How does HSTS complement HTTPS redirects?
While 301 redirects require one initial unencrypted HTTP round trip, HSTS (HTTP Strict Transport Security) ensures the browser never attempts the unencrypted HTTP connection in the first place.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
What is an "insecure fallback hole" and why is it dangerous?
An insecure fallback hole exists when at least one of the 4 URL variants (typically http://www.example.com) fails to redirect to HTTPS and instead loads content directly over plaintext HTTP. Any visitor, bookmark, or old backlink that hits that specific variant transmits form submissions, session cookies, and page content unencrypted, and can be intercepted or modified by anyone on the same network path.
Why do the 4 variants sometimes redirect to different canonical destinations?
This usually happens when DNS, WordPress Site Address (wp-config.php or Settings > General), and the web server virtual host are not aligned. For example, DNS may route www.example.com to a different server block than example.com, or WordPress's hardcoded siteurl option may not match the domain a visitor typed, producing two separate "canonical" destinations instead of one.
Can a misconfigured CDN cause a redirect loop between these 4 variants?
Yes. This is common with Cloudflare "Flexible SSL" mode combined with a WordPress "Force HTTPS" plugin rule. The CDN edge terminates TLS and forwards plaintext HTTP to the origin; the origin sees HTTP and redirects back to HTTPS; the CDN receives that redirect and re-initiates the cycle. Switching the CDN encryption mode to "Full" or "Full (Strict)" so the origin also sees HTTPS resolves this.
Does a passing result from this tool mean my HTTPS setup is fully secure?
No. This tool only verifies that all 4 entry points converge on a single HTTPS destination — it does not audit certificate validity, cipher strength, or HSTS configuration. Pair it with the SSL/TLS Configuration Checker and Security Headers Checker for a fuller picture, and treat all of them as diagnostic aids rather than a substitute for a professional security audit.