Chrome 62 Marks Your Forms "Not Secure" — Time to Finish the HTTPS Migration

Chrome 62 is rolling out to users right now, and it brings the change Google warned site owners about back in the spring: the moment a visitor types into any form field on an HTTP page — a search box, a newsletter signup, a comment form — the address bar flips to a gray "Not Secure" label. And in Incognito mode, every HTTP page gets the label all the time, typing or not, on the theory that Incognito users have declared an interest in privacy that plain HTTP can't deliver.

Read that first part again, because it's broader than it sounds: search boxes count. If your site has a search field, a login form, a contact form or a comment box — which is to say, if your site is nearly any site — and it still serves those pages over HTTP, a meaningful share of your visitors are now being told, in your own address bar, that your site is not secure. Whatever the nuances, that's the sentence they read.

What exactly changed

Chrome 62's warning has two triggers:

• Any text input on an HTTP page. The label appears when the user starts entering data. Password and credit-card fields already triggered it — the news is that every <input type="text">, search box and textarea now does too.
• All HTTP pages in Incognito. No interaction needed; the label is simply there.

The label is gray text, not (yet) the red-triangle treatment reserved for broken HTTPS. But it sits in the most-read pixel real estate in the browser, next to your domain name, at the exact moment a user is deciding whether to type something.

How we got here — and where it's going

This is deliberate, telegraphed strategy, arriving one ratchet-click at a time:

• January 2017 — Chrome 56 put "Not Secure" on HTTP pages containing password or credit-card fields. Firefox shipped similar in-context warnings on login forms around the same time. Most sites with logins felt the nudge and moved.
• October 2017 — Chrome 62, today's step: all text inputs, plus everything in Incognito.
• Eventually — all HTTP, full stop. Google has said plainly that the long-term plan is to mark every HTTP page not secure, timing driven by how fast HTTPS adoption climbs. No date is promised, but the direction is unmistakable — each Chrome release turns the screw, and the only question about the all-HTTP label is when.

The strategic takeaway: stop asking "does this Chrome version affect my pages?" and accept that all HTTP is on borrowed time. Migrating now — calmly, on your schedule — beats migrating later during whichever release finally catches your homepage.

The migration checklist

The good news: an HTTPS migration in 2017 is dramatically easier than the folklore suggests. Certificates are free, hosting support is widespread, and the performance objection has mostly inverted — HTTP/2, which browsers only speak over HTTPS, is generally faster than what you're leaving behind. The checklist:

• Get a certificate — free. Let's Encrypt issues free, automatically-renewable certificates, and a long list of hosts and CDNs now offer one-click or fully-managed HTTPS. Cost stopped being a reason this decade; for most sites the certificate is now the easiest step.

• Redirect everything, permanently. Every HTTP URL should 301 to its HTTPS twin — one hop, not a redirect chain. On nginx:

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

A 301 (not 302) tells search engines the move is permanent, so ranking signals consolidate on the HTTPS URLs.

• Hunt down mixed content. The classic migration wound: the page loads over HTTPS but an image, script or stylesheet still points at http://, and the browser blocks it or marks the page insecure anyway. Crawl your templates and database for hardcoded http:// references — your own domain and third-party embeds — and switch them to https:// (or root-relative paths for your own assets). The browser console lists every offender on a given page; fix templates first, then sweep stored content.

• Update canonicals, sitemaps and analytics. Search and measurement need to be told about the move: rel="canonical" tags should point at HTTPS URLs, your sitemap should list HTTPS URLs, Google Search Console treats the HTTPS site as a new property (add it, submit the sitemap there), and your analytics property's default URL should flip to HTTPS so referral data stays coherent. Update the hardcoded links in your email templates and social profiles while you're in there.

• Consider HSTS — after things are stable. The Strict-Transport-Security header tells browsers to skip HTTP entirely for your domain. It's the right end state, but it's a commitment — start with a short max-age, live with it, then lengthen. Don't ship it on migration day.

• Watch the long tail. Old QR codes, paid ads, partner links and password-reset emails pointing at HTTP will ride your 301s indefinitely — fine — but anything that breaks on redirect (hardcoded API clients, ancient embedded widgets) surfaces in the weeks after cutover. Keep an eye on logs.

For a typical small site this is an afternoon; for a big old content site the mixed-content sweep is the long pole. Either way it's finite, well-trodden work — thousands of sites have done it this year alone.

After the migration, HTTPS becomes something to monitor

Here's the part that bites people six months later: once you're on HTTPS, your certificate is load-bearing. An expired certificate doesn't show a gray label — it shows a full-page browser warning that stops essentially every visitor cold. The move to HTTPS is really a move to operating HTTPS: renewals happening on time, the certificate chain staying valid, and — as of last month's rule change — your CAA records staying in sync with whoever issues for you.

That's precisely the tedium CompleteStatus automates: we check your certificates from the outside and alert you by email, Slack or webhook well before expiry, alongside uptime checks that confirm your redirects and pages keep answering correctly. Create a free account, point it at your shiny new HTTPS site, and let Chrome's next ratchet-click be someone else's emergency.