How to Audit a SaaS Site for Chrome's New HTTP Warnings

To audit a SaaS site for Chrome's new HTTP warnings, list every hostname you own, request each one over plain HTTP, confirm a single 301 redirect to HTTPS, then crawl for internal HTTP links and fix them. Chrome now prompts users before loading an insecure page, so any stray HTTP URL can cost you a visit.

Cekpr covers technical SEO for B2B software teams. This guide is for the engineer or marketer who owns the website, the docs, the status page and the long tail of old subdomains. It gives you a repeatable audit with commands, a priority order and a way to stop regressions.

What did Chrome change?

Google described the change in a Chrome security post dated October 21, 2026. Chrome asks users for permission before making an insecure HTTP connection. It began with Enhanced Protection users in Safe Browsing earlier this year and now reaches all users by default.

On a first visit to an HTTP site, Chrome shows a dialog saying the site does not support a secure connection. After the user approves, it does not warn again until at least two weeks pass without a visit. The prompt appears on desktop and mobile.

Chrome skips the warning for hosts that cannot get a publicly trusted certificate. Examples include single-label hostnames such as intranet names and local IP addresses. Early rollout data showed nearly 95% of desktop Chrome users saw no warnings in a given week, and fewer than 1% saw three or more.

Why does this matter for a SaaS site?

A warning is a conversion problem first and an SEO problem second. A buyer who clicks an ad, an email link or a review-site link and meets a security prompt may leave. You will see the loss as a dip in demos, not as an error in a report.

It also shows up in how trust forms. B2B buyers are cautious about software vendors, and a security dialog on a vendor's page sends the wrong signal. The page that triggers it is often not your homepage but an old campaign URL or a forgotten docs host.

On the ranking side, the guidance is modest. According to web.dev's HTTPS guide, Google uses HTTPS as a positive ranking signal and advises a 301 redirect from HTTP to HTTPS. Treat that as a small tailwind, and treat the user prompt as the bigger risk.

How do you inventory every hostname?

Start with the full list, because you cannot fix what you have not found. Pull hostnames from DNS records, your certificate inventory, your CDN and hosting dashboards, your marketing tools and your Search Console properties.

Include the oddities. Old trial environments, partner portals, redirect domains and typo domains all count. If a host is public, a user can reach it.

How do you test each host over HTTP?

Request the plain HTTP version and read the response. In a terminal, run curl -sI http://yourhost.example/ for each name. You want one response: a 301 with a Location header pointing to the HTTPS version of the same path.

Watch for four failures. A 200 over HTTP means the page loads insecurely. A 302 instead of a 301 sends a weaker signal. A redirect chain with several hops slows the visit. A redirect to the wrong host or path loses the visitor.

Web.dev gives a sensible order for the rollout. Enable HTTPS first, confirm it works, then add the redirect. It also advises keeping a canonical link on each page that points to the HTTPS URL.

How do you find internal HTTP links?

Crawl the site and filter for links that begin with http:// and point to your own domains. A crawler such as Screaming Frog or Sitebulb can do this, and so can a simple script. Check page links, canonical tags, hreflang, sitemaps, structured data and image sources.

Do not limit the search to HTML. Web.dev notes that URLs also hide in stylesheets, JavaScript, redirect rules, link tags and Content Security Policy declarations. Search your codebase and your CMS for the string "http://" and review each hit.

Leave external links alone unless you can verify the HTTPS version. Web.dev advises against changing the protocol on links to other sites, since you do not control them. If a partner still serves HTTP only, consider removing the link.

Our guide on auditing a SaaS site for back button hijacking uses the same crawl-and-filter approach, and you can run both checks in one pass.

What about email, ads and old content?

Outbound links are the quiet leak. Email templates, ad destinations, press kits and PDF whitepapers often contain old HTTP URLs. Chrome does not care where the click came from, so each stale link can trigger the prompt.

Make a short sweep of your top sources. Check the destination URLs in your active ads. Open your five most-sent email templates and test every link. Search your help center for hard-coded HTTP addresses.

Redirects protect you from most of this. If every HTTP hostname returns a clean 301, an old link still ends on a secure page. The user may still see a brief flash, but the connection that matters is secure.

How should you set up HSTS?

HSTS, the Strict-Transport-Security header, tells browsers to use HTTPS only for your host. It also skips the redirect round trip on later visits. It is powerful and unforgiving, so roll it out in stages.

Web.dev advises starting with a low max-age and raising it gradually. It warns that clients may hard-fail on TLS errors, so do not enable HSTS until your site operation is robust. Set the Secure flag on cookies too.

A staged plan works well. Begin with a max-age of a few minutes on one host. Move to a day, then a week, then a month as you confirm that certificates renew without trouble. Only then consider including subdomains.

One more crawl-related note. Your redirects and hostnames also affect which bots can reach you, so keep your robots.txt consistent across each host. Our robots.txt setup guide for AI crawlers on SaaS sites covers the file, and each hostname needs its own copy.

How do you keep certificates healthy?

An expired certificate turns a fixed site into a broken one. The National Institute of Standards and Technology covers the technical baseline in Special Publication 800-52 Revision 2. It requires government TLS servers to support TLS 1.2 and TLS 1.3 by January 1, 2024, and it is a sound reference for any serious site, though the document is under review.

Automate renewal where you can. Monitor expiry dates with alerts at 30, 14 and 7 days. Test the full chain after each change, using a scanner such as the Qualys SSL Server Test that web.dev recommends. Aim for an A or A+ grade.

Keep your outage plan current as well. Our guide on serving a 503 during an emergency patch without losing rankings explains how to take a site down safely when a certificate or security problem forces your hand.

How do you stop it from coming back?

Add checks to your process. Include an HTTP-to-HTTPS test in your launch checklist for every new hostname. Add a crawl for HTTP links to your release pipeline. Review the DNS inventory every quarter.

Assign an owner for each host. Stale subdomains fail because no one is responsible for them. A one-line owner field in your inventory sheet fixes most of that.

Finally, watch the metrics. Compare landing-page bounce rate before and after your fixes, especially on campaign URLs. A drop in bounces on a fixed page is the best proof that the audit paid off.

How long should the audit take?

For most SaaS companies, the first pass takes a day. The inventory is the slowest part, because ownership of old hosts is unclear. The curl tests and the crawl go quickly once the list exists.

Fixes vary. Adding a redirect is a one-line change on most platforms. Rewriting hard-coded links in a legacy docs site can take longer. Rank the work by traffic and by risk, so the pages that buyers actually see are fixed first.

What is the next step?

Block two hours this week. Build the hostname list, run the curl test on each and fix the worst offenders first. Public marketing pages and ad destinations come before internal tools.

Then schedule the crawl and the quarterly review. Cekpr will keep tracking browser and search changes that touch SaaS sites, so you can fix problems before buyers see them.