You’ve successfully migrated your site to HTTPS, and every page now has a secure padlock. However, a crucial cleanup step is often missed: auditing and updating all internal links that still point to old, insecure HTTP URLs. While your server-wide redirect will catch these requests, forcing every internal link through a redirect is inefficient and can cause other technical SEO problems, such as mixed content warnings.

Think of your website as a newly renovated building with a new, secure main entrance. Leaving old internal signs pointing to the back alley (HTTP) instead of the new front door (HTTPS) is confusing and inefficient for visitors and security guards (search engines) alike. For a broader look at website security, see our guide on the security category.

An illustration of an unlocked padlock, symbolizing the lingering risk of internal HTTP URLs.

The Lingering Problems of Outdated Internal Links

Even with a site-wide redirect in place, internal links to HTTP URLs are harmful:

  • Unnecessary Redirects: Every click on an internal HTTP link triggers an extra server request and a 301 redirect. This adds a small but cumulative delay to page load times, harming user experience and wasting crawl budget. This can even lead to an internal redirect chain if not managed carefully.
  • Mixed Content Errors: This is the most critical issue. If an HTTPS page loads a resource like an image, script, or stylesheet via an insecure HTTP URL, it creates a mixed content error. Browsers will often block these insecure resources and display a security warning, breaking page functionality and eroding user trust.

A Comprehensive Cleanup Strategy

The goal is to eliminate every internal reference to an HTTP URL, ensuring a clean, secure, and efficient site. For a detailed overview of the importance of HTTPS, Google’s documentation on securing your site with HTTPS is the best resource.

Example: Updating an Internal Link

<!-- Before: Insecure internal link --> <a href="http://www.example.com/about-us">About Us</a> <!-- After: Secure internal link --> <a href="https://www.example.com/about-us">About Us</a>

For another excellent resource, check out this guide to HTTPS from Moz.

An illustration of a checklist for finding and fixing internal HTTP URLs.

Frequently Asked Questions

I already have a 301 redirect from HTTP to HTTPS. Do I still need to update my internal links?

Yes, absolutely. The redirect is a crucial safety net, but it’s inefficient. Every internal link to an HTTP URL forces an unnecessary redirect hop, which slows down page loading for users and wastes crawl budget for search engines. Updating the links at their source is the correct and most efficient solution.

What about protocol-relative URLs (//example.com)?

Protocol-relative URLs were once a common practice, but they are now considered an anti-pattern. Since your site should be fully on HTTPS, there is no need for the ambiguity of a protocol-relative URL. It’s always better to use absolute HTTPS URLs for all your internal and external links.

What is HSTS and should I use it?

HSTS (HTTP Strict Transport Security) is an HTTP header that tells browsers to *only* ever connect to your site using HTTPS for a set period. It’s a powerful security feature that prevents downgrade attacks. Implementing HSTS is an excellent final step after you have successfully migrated to HTTPS and fixed all internal linking. For more information, the MDN Web Docs provide a great overview.

Ready to secure your site completely? Start your Creeper audit today to find and fix every insecure internal link.