Canonical Pointing to the Insecure HTTP Version

A canonical tag tells a search engine which URL should hold a page's ranking signals. When a page you serve securely names its own insecure http:// address as that URL, the instruction points backwards, away from the version you actually want indexed.

What this finding means

Crawl Cove's insecure-canonical check looks at every indexable page (HTTP 200, not noindex) that loads over HTTPS. It flags the page when its rel="canonical" is an absolute http:// URL on the same host, a scheme downgrade rather than a genuine cross-domain reference.

A real finding looks like this:

HTTPS page has an insecure canonical: "http://example.com/page" (http:// on the same host)

This is a narrower, deliberately separate check from the general canonical validation Crawl Cove also runs. That check compares a same-origin canonical against the URLs seen in the crawl, but http://example.com and https://example.com are different origins entirely, so a canonical naming the http:// twin slips straight past it unvalidated. This check exists to close exactly that gap.

Why it matters

Naming the insecure address as canonical tells Google to fold this page's ranking signals into the http:// version, the one your HTTPS migration was meant to retire. At best that wastes the consolidation the tag is supposed to do; at worst Google indexes the http:// URL instead of the secure one, which can show visitors a "not secure" warning on a page you worked to rank, and leaves the secure URL doing none of the work its own canonical claims for its insecure twin.

How to fix it

1. Open the flagged page's canonical tag and confirm it reads http:// rather than https:// for a URL on your own domain.
2. Change the scheme to https://, keeping the rest of the URL identical, so the canonical points at the page actually serving it.
3. Check your redirect rules at the same time: if http:// requests to this domain are not already 301-redirected to https://, add that redirect so the insecure version cannot be crawled or linked to going forward.
4. Re-crawl the page to confirm the finding clears.

False positives and edge cases

• Only a same-host downgrade is flagged. A canonical pointing at http:// on a different domain is left to the general canonical check, since that could be a legitimate cross-domain reference rather than a self-downgrade.
• The page itself must be served over HTTPS. A page Crawl Cove sees loading over plain HTTP is out of scope here; there is no secure version for its canonical to have downgraded away from.
• A non-absolute or malformed canonical is not flagged here. That belongs to the general canonical check instead, which owns missing and malformed values.
• A self-referencing https:// canonical, or one pointing at any other https:// URL, is never flagged. Only the http:// scheme on the same host triggers this check.

Related reading

For the case where a canonical points at a URL that redirects rather than one that's simply insecure, see Canonical Pointing to a Redirect. For a canonical that lands somewhere not indexable at all, see Canonical Pointing to a Noindex Page.