Chrome 62, released yesterday, labels a plain HTTP page Not secure once a visitor starts typing in any field. The fix is HTTPS across the whole site, done in the right order.

What changed yesterday

Chrome 62 was released yesterday, and copies on office and home computers will update themselves to it over the coming days and weeks.

On a page whose address starts with http rather than https, Not secure now appears beside the address the moment someone starts typing into a field: a contact form, a search box, a newsletter signup, a calculator.

In Incognito mode, Chrome's private window, the label shows on every plain HTTP page, whether anyone types or not.

The change was announced in April and flagged to site owners in August. Now it is simply what visitors see.

A five-minute check in Chrome

The fifth matters even for sites that moved months ago. A secure page that loads even one image over plain HTTP loses its padlock, and the pages that do it are usually old ones nobody checks.

What the label does

The label is grey text, not a red alarm, and some visitors will not notice it.

But it appears just as a visitor decides whether to hand over a name, a phone number or a personal question. Some will pause, some will phone instead, and some will quietly leave.

Businesses that ask for personal or financial details feel it most, because their visitors are cautious already.

Sites that moved halfway

Some sites made a start after the August message and stopped partway. Chrome 62 exposes each of the usual loose ends.

A certificate that covers the address with www but not without it, so some visitors get a full-page warning. A contact page moved to https while the search box on every other page stays plain.

Both versions of the site left reachable, so Google sees two copies and visitors land on whichever one an old link points to. Secure pages still pulling images, fonts or scripts from http addresses.

Each leaves visitors meeting a warning somewhere, and each is quicker to finish than it was to start.

Why the order matters

Moving to HTTPS is a short list of steps, and most of the trouble comes from doing them out of order.

Send visitors to https before the certificate is working, and every one of them meets a full-page error instead of your site.

Redirect everyone to https before the links written into old pages are fixed, and visitors land on secure pages full of plain images and scripts, with no padlock and sometimes a broken menu.

Change the listings, ads and email templates before testing, and customers are sent straight to whatever is still broken. Done in order, each step can be checked before the next begins.

What usually holds a move up

Old embedded tools: a booking widget, a calculator, a review badge or a map pasted in years ago. If the supplier offers no secure version, the tool has to be replaced, which can take longer than everything else.

Links written into old posts. Changing them in the database is routine for a developer, but a careless find-and-replace can break settings stored in a particular format.

And the redirects. Each old http address should lead to the same page at https, permanently and in one hop, rather than everything landing on the home page.

A worked example

A financial planning practice with two planners and an assistant has a site on plain HTTP: services, profiles, a retirement savings calculator and a form to book a review meeting.

Yesterday afternoon a client typed her age into the calculator, saw Not secure appear beside the address, and emailed the office asking whether the site was safe to use.

Nothing had happened to the site. The calculator runs in the browser and sends nothing anywhere, but Chrome labels the typing, not what happens to it afterwards.

The practice had received the August message and put the move off until the autumn.

Their developer started that afternoon: a free certificate from the host, the address settings switched, and the calculator's script found still loading from an old http address, which a secure page would block.

By this morning the redirects were in, page by page, and the Google listing, the newsletter template and both planners' signatures carried the new address.

What to tell a customer who asks

Some customers will ask, as that client did. A short, honest answer is better than silence.

Say what the label means: the page was not encrypted, so the browser warns as soon as anything is typed. Say whether anything was actually sent, and when the site will show a padlock.

Avoid calling it a browser glitch. The customer will see the same label next visit, and the excuse will not survive it.

After the move

Add the https version to Search Console as a new property and submit its sitemap, then update the default address in Analytics and the final URLs in AdWords.

Visitors arriving from other secure sites lose their source when they land on a plain page and are counted as direct. After the move they appear under their real source again.

Once everything has worked for a few weeks, a setting called HSTS can tell browsers to ask only for the secure version from then on.

The counter-case

A site with nothing to type into, no form, no search box, no signup, shows no change in a normal Chrome window this week. Only Incognito visitors see the label.

That lowers the urgency, not the need. Google has said where this is heading, and a plain HTTP site will be among the last still showing a warning.

Nor should the move be rushed past its checks: a half-finished switch, with warnings on some pages and broken scripts on others, is worse than the grey label.

Move the whole site to HTTPS, in order, and check each step before starting the next.

The order to do it in

  1. Get a certificate for the address, with and without www.
  2. Switch the site's address settings to https.
  3. Update old links in the database, carefully.
  4. Replace embedded tools that only work over HTTP.
  5. Redirect each old address to its https page.
  6. Test every form in Chrome and in Incognito.
  7. Then update listings, ads and Search Console.

Step five is where moves most often go wrong. Without page-by-page redirects, every link and bookmark collected over the years points at a plain page, and search engines have to rediscover the site one page at a time.

The warning many owners received in August is explained in the Search Console email about not secure forms.

Frequently asked questions

What did Chrome 62 change?

Plain HTTP pages now show Not secure beside the address once someone starts typing in a field. In Incognito windows, every plain HTTP page shows it.

Which fields make the label appear?

Any of them: contact forms, search boxes, newsletter signups, calculators and booking forms. Chrome labels typing on an unencrypted page, not what the page does with it.

What does a half-finished move look like?

A certificate missing one form of the address, a secure contact page beside plain ones, both versions reachable, or secure pages still loading images and scripts over HTTP.

Why does the order of steps matter?

Because each depends on the one before. Redirecting to https before the certificate works shows every visitor an error, and redirecting before old links are fixed leaves pages without a padlock.

What should I tell a customer who asks?

That the page was not encrypted, so the browser warned as soon as anything was typed, whether anything was actually sent, and when the site will show a padlock.

What else needs the new address?

Search Console, the default address in Analytics, AdWords final URLs, the Google listing, social profiles, email templates and signatures, so nothing sends people to the old address.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Seeing Not secure on your own site?

Send us the address. We will finish the move to HTTPS in the right order, including any parts left half done.

Start a Conversation