From January, Chrome 56 will mark plain HTTP pages with password or card fields "Not secure", and Google plans to label all HTTP pages eventually. Move the whole site to HTTPS this autumn, not just the login page.

What was announced yesterday

Google announced yesterday that Chrome 56, due in January, will show "Not secure" beside the address of any plain HTTP page containing a password box or a credit card field.

Today such pages carry a neutral icon, neither good nor bad. From January they carry a warning, on the very page where a visitor is about to type something sensitive.

Google called it a first step. Later versions will widen the label, for example to HTTP pages in Incognito mode.

The stated plan is to mark all HTTP pages as not secure, eventually with the red triangle now used for broken HTTPS.

So January touches a few pages on most small business sites. The direction touches all of them.

Pages that will get the label

The first catches people out. Customers never see the login page, but staff and developers do, and it exists on every WordPress site, whether or not anyone thinks of the site as having logins.

Payment pages hosted elsewhere

Many small shops send customers to a payment provider's own page to pay. That page sits on the provider's address, already on HTTPS, and is not affected.

What matters is where the card field actually sits. A card form embedded in your own plain HTTP page is exactly what the label targets, and it should never have been on plain HTTP.

Why not just the login page

It is possible to put a certificate on the site and serve only the login and checkout pages over HTTPS. That meets January's rule and nothing after it.

Every later step in Google's plan widens the label, and a site that is half on HTTPS has to be revisited each time.

Half-converted sites also break in small ways. A login form on an HTTP page that sends to an HTTPS address is still a password field on an HTTP page, and that page is the one Chrome judges.

One move for the whole site costs less than a series of partial ones.

What else the move brings

HTTPS has been a lightweight ranking signal for Google since August 2014. Small, but it points the same way.

It is also what browsers require in practice for HTTP/2, the newer way of loading a page's many files at once.

And it protects everything visitors type into every form, not only passwords, from anyone sharing the same public Wi-Fi.

A worked example

A dental lab making crowns, bridges and dentures for dental offices across the region runs a WordPress site with a client area. Offices sign in to check case status, download invoices and print pickup labels.

The whole site, both login pages included, runs on plain HTTP. From January, every office signing in through Chrome would meet the warning on the lab's own sign-in page.

The office manager's first thought was to secure the client area alone.

The developer advised moving the whole site: every other page would be caught by a later step, and the client area loaded images and scripts from the main site anyway.

The host issued a free certificate that renews itself.

Over two evenings the developer switched the site address to HTTPS, replaced old image links and redirected every HTTP address to its HTTPS twin. Signing in, uploads and label printing were then tested in several browsers.

The lab's monthly email told client offices that the address now starts with https, and that old bookmarks still work.

Planning the move this autumn

September to November is the right window. It leaves time to fix whatever breaks before January, and it keeps the change clear of December, when shops are busiest.

Start with an inventory: every login box and card form, every other form, every outside script, and every place the site's address is written down beyond the site itself.

Then book the move for a quiet week, with someone available to fix problems for a few days afterwards.

What breaks, and how to check

The usual problem is mixed content: files the page still pulls in over plain http, such as images, scripts and fonts. Browsers block insecure scripts outright and drop the padlock for insecure images.

Each old address should redirect permanently to its own page on HTTPS, not everything to the home page.

Forms, logins, checkouts and file uploads all need testing on a phone and a computer, because that is where problems hide.

Everything that points at the old address

Search Console treats the HTTPS version as a separate property, so add it and submit the sitemap there.

Update the website link in Google My Business and on social profiles, the default URL in Analytics, the final URLs in AdWords ads and sitelinks, and email signatures.

Redirects catch what you miss, but each one is a small delay, and some tools report against exactly the address you gave them.

The counter-case

A small brochure site built without WordPress, with no login, no forms and no shop, is not affected in January at all. Its move can come later in the year.

A site already scheduled for a rebuild before January can make the switch within the new build instead, as long as that date holds.

For most small business sites, though, January touches at least one page, and the sensible answer is to move the whole site to HTTPS this autumn.

Before January

  1. List every login box and card form.
  2. Get a certificate your host renews automatically.
  3. Book the move for a quiet autumn week.
  4. Fix every insecure image and script link.
  5. Redirect each HTTP page to its HTTPS address.
  6. Test logins, forms and checkout on two devices.
  7. Update every outside link to the site.

Step two decides how much work the rest is. A host that issues and renews certificates automatically turns HTTPS into a setting rather than a yearly job somebody has to remember.

What a free certificate proves, and why its automatic renewal matters, is covered in free certificates are out of beta.

Frequently asked questions

What exactly did Google announce?

That Chrome 56, due in January, will label plain HTTP pages asking for passwords or card numbers "Not secure", as a first step towards labelling all HTTP pages.

Which pages on my site are affected?

Any plain HTTP page holding a password box or a card form: the WordPress login page, shop accounts, checkouts on your own address, client portals and card-taking booking forms.

Why move the whole site?

Because Google plans to label every HTTP page eventually, and a half-converted site must be revisited at each step. One whole-site move costs less than several partial ones.

Is a hosted payment page affected?

No. A payment provider's own page is already on HTTPS. The label applies where the card field sits, so a card form embedded in your HTTP page is affected.

What usually breaks during the move?

Mixed content: images, scripts and fonts still loaded from http addresses. Redirects sending every page to the home page, and untested forms and logins, are the other common problems.

When should the move happen?

Between September and November, in a quiet week with someone available to fix problems afterwards. That leaves time before January and keeps the change away from December.

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.

Login page still on plain HTTP?

Point us to your site. We will mark which pages Chrome is about to flag and plan the whole move before January.

Start a Conversation