Insecure HTTP Links Example
I took my guests down to the ship by way of the whale, which I had not told them about.
The short answer
- What it is
- An insecure HTTP link is a link on an HTTPS page that points to an internal http:// URL. External HTTP links are a separate matter, since you don't control those sites.
- Why it matters
- Each click starts on an unencrypted request, even if it redirects to HTTPS a moment later. It also adds a hop and sends a mixed signal about your preferred URL.
- How a crawler should report it
- Report one row per link with the source page, the http:// target, and its status or redirect target. Only count links to the same site, and check PDFs and other files by status alone.
- Live examples
/lab/insecure-links/(positive)/lab/insecure-links/near-miss/(near miss)
Internal Links Still Using the Old Protocol
Insecure HTTP links are internal links that still use http:// on a site that runs on HTTPS. They are the usual leftovers of a migration. The server moved, but old article text did not. Absolute URLs are stored in the database, in menus, or in shortcodes. PDFs and email templates keep them too. A developer may also hard-code one protocol into a template when building a link to another section.
A browser requests the HTTP address first, then follows the redirect. That first request is unencrypted, so someone on the same network could see or change it. This is the gap that HSTS closes after the first visit, for browsers that have stored the policy. If a site has no redirect at all, the visitor stays on HTTP and sees a not secure label. Referrer data is also lost, since browsers by default send no referrer when moving from HTTPS to HTTP.
Search engines handle these links as links to a redirect. Google prefers the HTTPS version in most cases, but a steady stream of internal HTTP links argues against that choice. Crawlers don't always use HSTS, so each link costs an extra request. If HTTP has no redirect, you may have a full duplicate of the site. This is different from mixed content, which is about embedded files and can break how a page looks.
To detect the issue, scan every href on your HTTPS pages for http:// pointing at your own hosts. Include both the www and non-www names. To fix it, run a careful search and replace in your database, and take a backup first. Update menus, templates, and widget settings. Use root-relative paths in new content when your CMS allows it. Keep a site-wide 301 from HTTP to HTTPS in place, so old bookmarks and outside links still work.