Chrome 62 Marks Your Forms “Not Secure”: Time to Finish the HTTPS Migration

Chrome 62 is rolling out to users now, and it brings the change Google warned site owners about in the spring. When a visitor types into any form field on an HTTP page (a search box, a newsletter signup, a comment form), the address bar shows a gray "Not Secure" label. In Incognito mode, every HTTP page gets the label all the time, typing or not, on the theory that Incognito users have asked for a privacy that plain HTTP can't deliver.

That first part is broader than it sounds, because search boxes count. If your site has a search field, a login form, a contact form or a comment box, which describes nearly every site, and still serves those pages over HTTP, a meaningful share of your visitors are now being told in the address bar that your site is not secure.

What 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; now every text input, search box and textarea does too.
• All HTTP pages in Incognito. No interaction needed.

The label is gray text, not the red treatment reserved for broken HTTPS. But it sits right next to your domain name, at the moment a user is deciding whether to type something.

How we got here, and where it's going

This is a deliberate strategy, announced in advance and applied in steps:

• January 2017, Chrome 56 put "Not Secure" on HTTP pages containing password or credit-card fields. Firefox added similar in-context warnings on login forms around the same time. Most sites with logins took the hint and moved.
• October 2017, Chrome 62: all text inputs, plus everything in Incognito.
• Eventually, all HTTP. Google has said the long-term plan is to mark every HTTP page as not secure, with timing driven by how fast HTTPS adoption grows. No date has been given, but each release has moved in that direction.

So stop asking whether a given Chrome version affects your pages and assume all HTTP is on borrowed time. Migrating now, on your own schedule, beats migrating later in a hurry when a release finally catches your homepage.

The migration checklist

An HTTPS migration in 2017 is much easier than its reputation. Certificates are free, hosting support is widespread, and the performance objection has mostly reversed: HTTP/2, which browsers only speak over HTTPS, is generally faster than what you're leaving behind. The checklist:

• Get a certificate. Let's Encrypt issues free, automatically renewable certificates, and many hosts and CDNs now offer one-click or fully managed HTTPS. Cost is no longer a reason, and for most sites the certificate is the easiest step.

• Redirect everything, permanently. Every HTTP URL should 301 to its HTTPS equivalent in one hop, not a chain of redirects. 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 problem: 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. Search your templates and database for hardcoded http:// references, both 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 page. Fix templates first, then sweep stored content.

• Update canonicals, sitemaps and analytics. rel="canonical" tags should point at HTTPS URLs, and your sitemap should list HTTPS URLs. Google Search Console treats the HTTPS site as a separate property, so add it and submit the sitemap there. Switch your analytics property's default URL to HTTPS, and update hardcoded links in email templates and social profiles while you're at it.

• Consider HSTS once 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 it. 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 rely on your 301s indefinitely, which is fine. Anything that breaks on a redirect (hardcoded API clients, old embedded widgets) will show up in the weeks after cutover, so keep an eye on the logs.

For a typical small site this is an afternoon. For a large, old content site the mixed-content sweep takes the longest. Either way it's finite, well-understood work.

After the migration, HTTPS is something to monitor

Here's what catches people six months later: once you're on HTTPS, everything depends on your certificate. An expired certificate doesn't show a gray label; it shows a full-page browser warning that stops almost every visitor. Moving to HTTPS really means operating HTTPS: renewals happening on time, the certificate chain staying valid and, since last month's rule change, your CAA records staying in sync with whoever issues for you.

CompleteStatus checks your certificates from outside and alerts 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 and point it at your new HTTPS site.