Skip to content
Issue docs

Page reached over HTTP before redirecting to HTTPS

Standardhttp_to_https_redirectIssue 123

What is this issue?

This check reports a page that was requested over HTTP and reached its final HTTPS address only after a redirect.

The redirect itself is correct. A site should send http:// to https://, and one that did not would be reported by a different, more serious check. What this finding says is that the insecure address is still being reached: something -- an internal link, a sitemap entry, a hard-coded URL in a template -- is still publishing the http:// spelling.

The judgement is made on the first hop, because that is the address something linked to and the only one you can change. A chain that starts on HTTPS and drops to plaintext part-way through is a different and worse fault, and is not what this reports.

For a URL to pass this check:

  • It was requested at its https:// address directly, with no HTTP hop first.

Why it matters

Everything ends up in the right place, which is why this is graded standard rather than higher. The costs are small and entirely avoidable:

  • A plaintext round trip. The first request, including the full URL and any cookies not marked Secure, crosses the network unencrypted before the upgrade happens. That request is interceptable and modifiable.
  • A wasted hop. Every visit pays an extra round trip, which is most noticeable on a slow mobile connection.
  • Diluted signals. External links to the http:// form pass their value through a redirect rather than directly.
  • Crawl budget. Search engines fetch both addresses.
  • It hides the source. Each instance points at something in your own site or sitemap that still hard-codes the old scheme.

Fixing it is a search-and-replace plus, ideally, an HSTS header so browsers stop making the insecure request at all.

How to fix it

  1. Find what links to the HTTP address. The finding names the address that was requested; search your templates, content and configuration for it.

  2. Update internal links to HTTPS, or make them relative so they inherit the page's scheme automatically.

  3. Check the XML sitemap. A sitemap that lists http:// URLs is telling every search engine to request the insecure form of every page.

  4. Send an HSTS header. Strict-Transport-Security tells browsers to make the request over HTTPS from the start, so the plaintext round trip stops happening even when an old link is followed. This is a separate check in PixyScan (Delivery and Trust).

  5. Keep the redirect. Do not remove the http:// to https:// rule; the addresses already published elsewhere still need it.

  6. Update canonical tags, hreflang and structured data if any of them still name the http:// form.

Examples

Example 1: Linked directly to HTTPS

Scenario: An internal link written with the secure scheme.

Passes because: no redirect was needed.

GET https://example.com/pricing  ->  200

Scenario: A footer template that hard-codes the old address.

Fails because: the request started in plaintext, and the upgrade cost a redirect.

GET http://example.com/pricing   ->  301 -> https://example.com/pricing
GET https://example.com/pricing  ->  200

Corrected version: change the footer link to the HTTPS address (or make it relative), keep the redirect for the links you do not control, and send an HSTS header.

Example 3: A chain that stays on HTTP

Scenario: A site that has not migrated.

Not reported here because: the chain never reaches HTTPS. That is a page not served over HTTPS, which is a separate and more serious finding.

GET http://example.com/page      ->  301 -> http://example.com/page/
GET http://example.com/page/     ->  200

How PixyScan detects this

  1. Records the redirect chain for each page, hop by hop, in the order it was travelled.

  2. Looks at the first hop that has a URL. That is the address the request actually started from -- the one something linked to.

  3. Reports when that first hop is http:// and the chain resolved to https://. The scheme comparison ignores case.

  4. Does not report a chain that ends on HTTP. That is a page not served over HTTPS at all, which has its own check and a different fix.

  5. Does not report an HTTP hop in the MIDDLE of an otherwise HTTPS chain. The page was reached securely, so "reached over HTTP" would be untrue of it, and the reader would be sent looking for an http:// link that does not exist.

  6. Lists every insecure hop it saw, so a chain that touches plaintext more than once shows all of them.

What we store

Storage Level

Page Level

Database Table / Prisma Model

audit_issues.details

Stored Fields

Field Type Description
originalUrl String The http:// address that was requested
finalUrl String The https:// address the chain resolved to
insecureHops String[] Every http:// hop in the chain

Detection Dependencies

  • HTTP Response
  • Redirect Chain

Note

The chain is also stored on the RedirectChain row for this scan. The finding keeps the insecure hops separately so the row names the address that needs changing without re-reading the chain.

Further reading