Canonical Points to the HTTP Version: How to Fix It

TL;DR: The page is served over HTTPS, but its canonical points at the http:// version of the very same URL. You are telling Google to treat the insecure twin as the master copy. Left alone it can undo an HTTPS migration and get the wrong, non-secure URL indexed. The fix is almost always trivial: correct one hardcoded protocol in a template so the canonical reads https://.

What this means

A canonical names the preferred version of a page when several URLs serve the same content. This flag fires when an HTTPS page declares a canonical using http:// instead of https://. The secure page is nominating its own insecure version as the one that should rank and be indexed. Same path, same content, wrong protocol — the page reachable at HTTPS is pointing search engines back to HTTP. It nearly always traces to an HTTP-to-HTTPS migration where the canonical logic in a template kept emitting the old protocol.

Why it matters

Google prefers HTTPS and uses it as a lightweight ranking signal, but the bigger risk here is index confusion. If Google honors the canonical, it may index the HTTP URL — which then hits your HTTPS redirect and creates a mismatch between the version you point at and the version that actually serves. On sites that still answer on both protocols, this can split signals, waste crawl budget, and surface "not secure" URLs to users. It is a mid-severity issue: rarely fatal, but it quietly erodes the migration you paid for.

A real failing tag, and the fix

<!-- Served at https://example.com/pricing/ -->
<link rel="canonical" href="http://example.com/pricing/" />

The page loads securely, then tells Google the insecure URL is canonical. Correct the protocol so the tag matches the secure address the page is actually served from:

<!-- Served at https://example.com/pricing/ -->
<link rel="canonical" href="https://example.com/pricing/" />

Root cause is usually a stored site URL or a template variable frozen at http://. In WordPress that is often the Site Address / WordPress Address still on HTTP, or a plugin building canonicals from a hardcoded base. Fix the base value and the whole site's canonicals flip to HTTPS at once.

Protocol-mismatch cases and what each needs

How to detect it

1. Screaming Frog: crawl the HTTPS site, open the Canonicals tab, and look at Canonical Link Element 1. Sort or filter that column for values starting with http://. Any secure page whose canonical begins with plain HTTP is a hit. A custom search filter for http:// in the canonical extraction isolates them in bulk.
2. GSC URL Inspection: inspect the HTTPS URL and read "User-declared canonical." If it shows the http:// variant, the mismatch is confirmed. Also check whether "Google-selected canonical" flipped to HTTP, which tells you Google is acting on the bad signal.
3. curl: curl -s https://example.com/pricing/ | grep -i canonical — inspect the protocol in the returned href. If it reads http:// while you requested https://, that is the defect, visible in one line.

How to fix it

1. Find where the protocol is set: the CMS site-URL option, a theme constant, or a plugin's base-URL config. That single value is stamping HTTP onto every canonical.
2. Switch it to https:// and clear any page/object cache so regenerated HTML carries the corrected tag.
3. Make sure every HTTP URL 301-redirects to its HTTPS equivalent, so the protocol you canonicalize to is also the only one that serves. See HTTP Does Not Redirect to HTTPS.
4. Re-crawl and confirm no canonical still starts with http://. Verify in GSC that Google-selected canonicals are now HTTPS.
5. If both protocols still answer with 200, close the split entirely — details in URL Works on HTTP and HTTPS.

FAQ

Is an HTTP canonical on an HTTPS page a serious problem?

It is mid-severity. It will not always deindex you, but it muddies which protocol Google indexes and can partially unwind an HTTPS migration. It is cheap to fix, so there is no reason to leave it.

Will Google always index the HTTP version if I point at it?

Not always — Google prefers HTTPS and may override an obviously wrong canonical. But you should not rely on Google to correct your markup; declare HTTPS explicitly.

Why did this appear after our HTTPS migration?

Because the canonical logic was never updated. Migrations flip the served protocol but often leave a stored base URL or template constant on HTTP, so the tag keeps emitting the old scheme.

Do I still need HTTP-to-HTTPS redirects if I fix the canonical?

Yes. The canonical is a hint; the 301 is the enforcement. Together they ensure both users and crawlers land on and index the secure version. Fixing one without the other leaves a gap.

What about mixed content after switching to HTTPS canonicals?

Separate but related issue: subresources still loaded over HTTP will trigger insecure-content warnings even with a correct canonical. Audit those too — see Mixed Content: How to Find and Fix HTTP Resources on HTTPS and the HTTPS Migration Technical Checklist.

Related canonical checks: Canonical Points to External URL · Canonical Points to Another Canonicalized URL