URL Not Using HTTPS: Why It Matters

URL Not Using HTTPS: Why It Matters

A “URL not using HTTPS” finding means the audited address was requested with http://, so the request and response may travel without Transport Layer Security (TLS). HTTPS adds encryption, integrity protection and server authentication between a visitor’s browser and your website. Without it, someone who can observe or control the network path may be able to read or alter traffic.

This normally needs attention, but the response depends on what the URL does. An HTTP address that immediately redirects to the matching HTTPS page is different from a page that remains available over HTTP, enters a redirect chain, lands on the wrong page or reaches HTTPS with an invalid certificate. This guide helps you identify the case, migrate safely and verify the result.

HTTPS secures the connection. It does not prove that a website is honest, remove application vulnerabilities or guarantee higher Google rankings.

What to Check First

• HTTP returns a normal page: If the public URL responds successfully over HTTP instead of redirecting, enable HTTPS and remove the duplicate insecure version.
• HTTP redirects once to the matching HTTPS URL: The main transport rule is working. Still replace internal HTTP references so visitors and crawlers do not need the redirect.
• The redirect changes the path, drops query parameters, loops or passes through several URLs: Correct the mapping rather than treating the issue as solved.
• HTTPS opens with a certificate error or insecure assets: The migration is incomplete even though the address bar begins with https://.

The target is one canonical HTTPS version of every public page, reached through a direct permanent redirect from its HTTP equivalent.

Why Public Websites Should Use HTTPS

• It protects data in transit: HTTP traffic can be observed or modified by an intermediary. HTTPS makes that interference substantially harder by encrypting the browser-to-site connection and checking that responses have not been altered. Chromium’s HTTPS-by-default guidance explains why browsers increasingly try secure connections first.
• It avoids insecure-connection treatment: Browsers can label HTTP pages as not secure, upgrade requests to HTTPS or warn before loading them. Some browser capabilities are also restricted to a secure context.
• It gives Google one secure canonical version to process: Google historically described HTTPS as a very lightweight ranking signal, while its current canonical guidance says it generally prefers valid HTTPS pages over equivalent HTTP pages. Google’s newer page-experience guidance does not support treating HTTPS as a ranking shortcut. The practical SEO goal is a consistent migration, not a promised ranking increase.
• It supports appropriate handling of personal data: The UK Information Commissioner’s Office gives HTTPS as an example of protecting personal information in transit in its encryption and data-transfer guidance. Its wider data-protection guidance is risk-based, so HTTPS is an important control rather than proof that a site is legally compliant.

HTTPS does not stop phishing, malware, vulnerable plugins, weak passwords or a compromised server. It protects the connection; the website and its systems still need their own security controls.

Diagnose the Finding Before You Change the Site

Test both the reported HTTP URL and the HTTPS version. A command-line header check is useful because it shows the status and redirect destination without loading the whole page:

curl -I http://example.com/services?ref=email
curl -I https://example.com/services?ref=email

The -I option requests headers only. If its result conflicts with a browser or crawl, repeat the test with a normal request because some servers handle HEAD requests differently from GET.

For a normal public page, the first request should usually return a permanent redirect such as 301 or 308 with a Location pointing directly to the exact HTTPS equivalent. The final HTTPS URL should load normally with a certificate valid for that hostname.

• HTTP returns 200 OK: The insecure page is still available and may compete with the HTTPS copy unless other signals intervene. Redirect it and update references to it.
• HTTP redirects directly to HTTPS: This is expected migration behaviour. Check that the path and legitimate query string are preserved and that internal links already use HTTPS.
• There is a chain or loop: Replace it with one direct rule where possible. The ScanMySEO redirect-chain guide explains how to trace and simplify multi-hop redirects.
• The certificate is expired, untrusted or issued for another hostname: HTTPS is not working safely. Correct the certificate, chain and hostname coverage before forcing traffic to it.
• The page is HTTPS but loads HTTP images, scripts, styles, fonts or frames: This is mixed content. Browsers may upgrade some requests and block others, so the page can look broken or remain partly exposed.
• A CDN terminates HTTPS at the edge: A public crawl can verify the visitor-facing connection but cannot prove how the CDN communicates with a private origin. Check the provider’s origin-encryption setting separately.

How to Move a Website from HTTP to HTTPS Safely

1. Record the current setup and choose the final hostname.
   • List the apex domain, www hostname, public subdomains, APIs, image hosts and other origins that visitors or integrations use.
   • Decide whether the canonical site will use https://example.com or https://www.example.com. Avoid combining the protocol move with unrelated URL restructuring unless there is a clear reason.
   • Export important URLs and capture a baseline for traffic, rankings, conversions and indexed pages so you can distinguish migration effects from unrelated changes.
2. Issue and install a valid TLS certificate, often called an SSL certificate.
   • The certificate must cover every public hostname you intend to serve and include the correct certificate chain.
   • Many hosts and content delivery networks provide managed certificates. Let’s Encrypt also provides free, automated certificates. A paid Organisation Validation or Extended Validation certificate is not an SEO requirement.
   • Enable automatic renewal and monitor it. A certificate that silently expires can make the whole site inaccessible to visitors.
3. Test HTTPS before redirecting everyone.
   • Check representative pages, templates, forms, logins, checkout journeys, downloads, APIs and third-party scripts.
   • Confirm that the certificate is valid on desktop and mobile browsers and that the server presents the complete chain.
   • Test integrations that depend on exact callback, webhook or allow-list URLs. Do not assume every non-browser client will follow redirects correctly.
4. Create direct, permanent HTTP-to-HTTPS redirects.
   • Use server-side or CDN rules so each old URL reaches its corresponding HTTPS URL in one hop. Google’s redirect guidance recognises 301 and 308 as permanent redirects and recommends server-side redirects where possible.
   • Preserve the path and legitimate query parameters. Do not send every old URL to the homepage, and do not create a chain such as HTTP → HTTPS non-www → HTTPS www.
   • Test non-GET endpoints separately. For forms, APIs and webhooks, update the submitting client to the final HTTPS endpoint instead of relying on a redirect.
5. Replace HTTP references across the site.
   • Update navigation, body links, image and font URLs, scripts, stylesheets, canonical tags, hreflang tags, structured data, XML sitemaps, feeds and social metadata.
   • Update hard-coded URLs in templates, databases, page builders, email templates, advertising platforms and third-party settings where they are under your control.
   • Google’s site-move guidance recommends self-referencing canonicals on the new URLs, updated internal links and a sitemap containing the new URLs.
6. Remove mixed content.
   • Use the browser developer console and a site crawl to find resources still requested over HTTP.
   • Replace each resource with a tested HTTPS version, host it securely yourself or remove it. Do not blindly change the scheme if the third-party host does not support HTTPS.
   • Review MDN’s mixed-content guidance for the difference between resources browsers may upgrade and those they block.
7. Verify the migration in Google Search Console.
   • Ensure you can inspect the HTTPS site, submit the HTTPS sitemap and check representative URLs with URL Inspection.
   • Use the Search Console HTTPS report where available to review indexed HTTP and HTTPS URLs and the reasons an HTTPS URL could not be indexed.
   • Do not submit Search Console’s Change of Address form for an HTTP-to-HTTPS move; Google’s Change of Address documentation explicitly excludes this type of migration.
8. Monitor after launch and keep the redirects.
   • Recrawl the site, check server logs, certificate alerts, page indexing, analytics, conversions and important search queries.
   • Google notes that URL moves can cause temporary ranking fluctuations while old and new URLs are processed. Investigate sustained losses rather than promising that no movement will occur.
   • Keep HTTP-to-HTTPS redirects in place for old links, bookmarks and crawlers, even after internal references have been corrected.

Add HSTS Only After HTTPS Is Stable

HTTP Strict Transport Security (HSTS) tells supporting browsers to use HTTPS for future requests and prevents users from bypassing certificate errors while the policy is active. It can reduce downgrade risk, but a bad deployment can also lock visitors out.

• Serve the Strict-Transport-Security header only over HTTPS.
• ScanMySEO recommends a staged rollout: Start with a deliberately short max-age while testing, then increase it only after certificate renewal and all covered hostnames are reliable.
• Do not add includeSubDomains until every relevant subdomain supports HTTPS. A forgotten legacy or supplier-hosted subdomain can otherwise become unreachable.
• Treat browser preload as a separate, difficult-to-reverse commitment rather than a default checkbox.
• Keep the HTTP redirect even after enabling HSTS; first-time visitors and crawlers may still request the HTTP URL.

Read MDN’s HSTS reference before deployment. For the wider set of controls around HSTS and related headers, use ScanMySEO’s guide to missing security headers.

Example: Fixing a Redirect That Looks Secure but Is Not Clean

Consider this hypothetical request:

http://example.com/services?ref=email
→ https://example.com/services?ref=email
→ https://www.example.com/services?ref=email

The visitor eventually reaches HTTPS, but the request passes through two redirects. The site also declares http://example.com/services as its canonical URL and loads a hero image over HTTP.

A cleaner implementation would:

• redirect the original address directly to https://www.example.com/services?ref=email;
• change the page’s canonical, internal links and sitemap entry to the final HTTPS URL;
• serve the hero image over HTTPS;
• confirm that the final page returns normally with a valid certificate; and
• recrawl both hostname variants to ensure no alternative HTTP page remains accessible.

Success is measured by a secure connection, correct URL mapping, consistent canonical signals and working user journeys. This example does not assume a ranking or conversion increase.

What to Fix First and Who Should Own It

• Fix immediately: Public pages that return content over HTTP; certificate errors; insecure login, payment or personal-data forms; and HTTP scripts or frames that browsers block.
• Fix next: Redirect chains, wrong destinations, dropped paths or query parameters, conflicting canonicals, and sitemaps or hreflang tags that still advertise HTTP URLs.
• Clean up after the migration is stable: Internal links that create avoidable redirects, certificate monitoring gaps and a carefully tested HSTS policy.

The hosting, infrastructure or development owner should handle certificates and redirects. The web or content team should update hard-coded references and test user journeys. The SEO owner should verify canonicals, sitemaps, hreflang, crawling, indexing and search performance. On a small site, one person may perform all three roles, but the checks remain distinct.

HTTPS Migration Verification Checklist

• Every public hostname has a valid, trusted certificate and a reliable renewal process.
• Each HTTP page redirects once to its exact canonical HTTPS equivalent.
• Paths and legitimate query parameters survive the redirect.
• The final HTTPS page loads normally without loops or certificate warnings.
• Internal links, canonicals, hreflang, structured data and XML sitemaps use HTTPS.
• Images, scripts, styles, fonts, frames and downloads do not create mixed content.
• Forms, logins, checkout, APIs, webhooks and third-party callbacks still work.
• Session and other sensitive cookies are reviewed for the Secure attribute.
• Search Console, analytics and server logs are monitored after launch.
• A crawl finds no indexable HTTP pages, conflicting canonicals or avoidable redirect chains.

You can also test the public certificate configuration with Qualys SSL Labs. A strong grade is useful, but it does not replace page-level checks for redirects, mixed content, forms and canonical consistency.

ScanMySEO can help identify publicly reachable HTTP URLs and related crawl signals. Confirm infrastructure changes in a staging environment where possible, then recrawl the live site after deployment.