Chrome 68 Is Here: Every HTTP Page Now Says “Not Secure”

As of last Tuesday, July 24th, the most-used browser in the world tells your visitors your site isn't secure if you're still on HTTP. Chrome 68 shipped with the change Google announced in February: every page served over plain HTTP now carries a "Not Secure" label in the address bar. Not just checkout pages or login forms, but your homepage, your blog and your brochure site.

The label doesn't consider what your site does. HTTP means "Not Secure". If you've been putting off the HTTPS migration, the cost of waiting is now visible to every Chrome user who visits.

The end of an eighteen-month rollout

Google announced each step in advance:

• January 2017, Chrome 56: HTTP pages with password or credit card fields get "Not Secure".
• October 2017, Chrome 62: the label extends to any HTTP page once the user types into a form field, and to all HTTP pages in Incognito mode.
• July 2018, Chrome 68: every HTTP page, unconditionally.

It isn't finished. Google has said that in an upcoming release the "Not Secure" text will turn red when users enter data on HTTP pages, and that it plans to drop the positive "Secure" wording from HTTPS pages, because encryption is meant to be the unremarkable default, with only its absence called out.

The timing is reasonable rather than punitive. By Google's transparency report numbers, HTTPS now carries the large majority of Chrome traffic, and most of the top sites on the web default to it. Certificates are free, setup is largely automated, and HTTPS has been a lightweight search-ranking signal since 2014.

The migration checklist

A well-planned HTTPS migration is a solved problem. Here's the sequence that avoids the common mistakes.

1. Get a certificate (free is fine)

For most sites, a free domain-validated certificate from Let's Encrypt is the right choice; the encryption is the same as with paid certificates. Many hosts and CDNs now provision certificates for you with a checkbox. On your own server, an ACME client like Certbot issues and renews automatically:

certbot --nginx -d example.com -d www.example.com

Let's Encrypt certificates last 90 days by design. Automation handles renewal, but you should verify the automation (more on that below).

2. Redirect everything with 301s

Every HTTP URL should answer with a 301 permanent redirect to its exact HTTPS equivalent. Not just the homepage: every path, preserving the full URL so deep links and search rankings carry over:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Or with Apache:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Use 301, not 302. Search engines treat a 301 as "the new address is the real one" and transfer ranking signals accordingly.

3. Sweep for mixed content

The classic migration problem: the page loads over HTTPS, but an image, script or stylesheet still points at http://, and the padlock breaks anyway (browsers block insecure scripts outright). Fixes, in order of preference:

• Use relative URLs (/img/logo.png) or protocol-relative references so assets inherit the page's scheme.
• Search your templates and database for hardcoded http:// references. In a CMS, old post content is the usual culprit.
• Let CSP report the stragglers. A Content-Security-Policy-Report-Only header with a report URI surfaces mixed content across the whole site without breaking anything while you look.

4. HSTS, once you're confident

The Strict-Transport-Security header tells browsers to skip HTTP entirely for your domain, eliminating even the first insecure request. It's the right end state, but it's a commitment, because browsers will enforce it for the duration you declare. Start with a short max-age, confirm nothing's broken, then extend it:

# start conservative, raise to a year (31536000) once stable
add_header Strict-Transport-Security "max-age=300" always;

Hold off on preload until you're certain. Getting your domain out of browsers' preload lists is slow and manual.

5. Re-verify with search engines

Google Search Console treats https://example.com as a different property from http://example.com. Add and verify the HTTPS property, submit your sitemap with HTTPS URLs, and update the property in Analytics too. Expect some ranking fluctuation for a few weeks while the index catches up; the 301s ensure it settles.

6. Update the stragglers

CDN origin settings, canonical tags, Open Graph URLs, email templates, social profiles, ad destination URLs. Anything still generating HTTP links costs a redirect hop at best.

You've traded one risk for another

Once you finish, you have a new failure mode. An HTTP site can't have an expired certificate. An HTTPS site with an expired certificate shows every visitor a full-page browser warning, which is effectively a total outage. Renewal automation fails quietly: the cron job stops, a DNS change breaks validation, the renewed certificate never reaches one server behind the load balancer. And the industry is pushing certificate lifetimes shorter, so renewals will only get more frequent.

The answer is independent verification: an external check that reads the certificate your servers actually serve and alerts you weeks before expiry, whatever your automation believes.

After the migration

Chrome 68 made HTTPS the baseline expectation. The browser now tells visitors which sites haven't moved. For a typical site the migration takes a weekend, the certificate is free, and every step above is well documented. After that, the job is keeping it healthy.

CompleteStatus handles that part: certificate expiry monitoring with alerts at 30, 14 and 7 days, plus uptime checks that catch TLS failures when a visitor would. Create a free account and plan the migration for this month.