Reference guide · technical-seo · Published 2026-08-15 · 3 min read
HTTPS and SEO: what the switch changes
HTTPS SEO guide: what the switch changes historically, mixed content, hardcoded http links, and the correct migration order.
- ·What HTTPS changes
- ·Mixed content and links
- ·Migration order
What HTTPS changes for SEO
For years HTTPS was treated as a ranking signal: a secure site gained a small edge, and Google pushed the web toward encryption. Today HTTPS is effectively table stakes. It is no longer a differentiator so much as a baseline expectation, and its SEO value now shows up as prevention rather than bonus.
What still matters:
- A valid certificate avoids the "not secure" warning and keeps visitors, bounce, and trust intact, which indirectly protects engagement signals.
- Secure pages load without browser warnings, so no user experience penalty.
- Mixed-content errors where a secure page loads insecure resources can break layout and interactivity.
The real ranking risk today is not being plain http, but doing it inconsistently, with hardcoded http links and mixed assets that leak back to an insecure state.
Mixed content
Mixed content is a secure (https) page that also loads sub-resources such as images, scripts, or fonts over http. Browsers block the dangerous kinds, JavaScript and fonts, and the page can visibly break or render a lock warning.
<!-- http asset inside an https page: blocked or flagged -->
<img src="http://example.com/logo.png" />
The correct state is that every absolute internal asset uses https:
<img src="https://example.com/logo.png" />
Scan for insecure sub-resources after migration, because a single hardcoded http URL creates the mixed state.
Hardcoded http links
Hardcoded http:// references to your own domain are the classic migration miss. They appear in:
- Images, scripts, and stylesheets written in the HTML or CMS fields.
- Links stored in the database, open graph tags, and canonical tags.
- Redirect maps that still point at the old protocol.
Each hardcoded http link either loads the insecure copy or forces an extra hop through a redirect the new protocol should have made unnecessary. After migration, search for http:// in the source and update every self-referencing instance to https://.
Migration order
- Install and validate the certificate across every host you serve, including the www variant, so no host shows a certificate error. See SSL/TLS certificate errors.
- Decide the final host first, and migrate host and protocol together, because a combined 301 avoids double hops.
- Redirect every
http://URL to its exacthttps://counterpart with a 301, preserving path and host. See HTTP to HTTPS redirect. - Audit and fix mixed content: replace all hardcoded http asset URLs with https, then re-probe with a mixed-content check.
- Update canonicals, internal links, the sitemap, and referenced images so they use the https URLs. See canonical tags explained.
- Confirm no page still references
http://internally, and that oldhttprequests land on the https version in one redirect. - Re-request the new https URLs in Search Console and update any external tools that hold the old protocol.
The SEO-correct order
The rule is: choose the final host, then redirect protocol and host in one clean hop per URL, then fix assets and links, then request indexing. Doing protocol after host, or leaving a mix of http and https URLs, reopens the duplication risk that a clean migration removes. Compare with the host decision in www versus non-www.
Reference summary
| Item | Correct state |
|---|---|
| Certificate | Valid on the www and non-www hosts over https |
| http to https | 301 preserving path and host |
| Asset URLs | All https, no mixed content |
| Canonicals and sitemap | https URLs throughout |
| Internal links | Consistent with the chosen host and protocol |