Install a certificate covering every version of your address, redirect each old HTTP page permanently to its HTTPS match, fix anything still loading insecurely, update internal links, and tell Search Console, Analytics and your ads.

Not secure, beside your name

Since last July, Chrome has shown the words Not secure in the address bar of every page served over plain HTTP. Since the autumn, the label turns red when a visitor starts typing into a form on one.

For a business asking visitors for their name, phone number and address, that is an unhelpful thing to have printed beside the form.

Many small business sites responded by installing a certificate, which lets pages load over HTTPS, and stopped there. A certificate on its own is only the start of the move.

What a half-finished move looks like

The first is the most common. If the plain address still loads without redirecting, visitors who type it, or follow an old link, still see Not secure, and search engines see two copies of the site.

The certificate

Certificates from Let's Encrypt are free, and many hosts now install and renew them automatically. For a typical small business site, a free certificate does the same job as a paid one.

It must cover every name the site answers to: the address with www and without it, and any subdomain in use, such as a shop or a booking system.

Let's Encrypt certificates last ninety days, and the host's automatic renewal works until a change to the account quietly stops it. Somebody should be warned before one expires, rather than learning from a browser warning.

Redirects from every old address

Every old address needs a permanent redirect, known as a 301, to its exact HTTPS equivalent: the services page to the secure services page, not to the home page.

There are usually four versions of the address to cover: with and without www, over HTTP and over HTTPS. Three of them should lead, in a single step, to the one you have chosen.

Test each version in a browser, along with a few deep pages from old emails and printed material. Chains of redirects still work, but they slow every visit down.

Mixed content

A secure page that pulls in anything over plain HTTP, such as an image, a script or a font, is said to have mixed content.

Images still appear, but the padlock goes, replaced by a note that the connection is not fully secure. Scripts are worse: browsers refuse to run insecure scripts on a secure page, so sliders, maps and forms can quietly stop working.

The usual culprits are addresses typed into the theme, images inserted into posts years ago, and widgets embedded from other services. The browser's developer console lists each one, and a crawl of the whole site finds the rest.

A worked example

A music school offering lessons for children and adults moved to HTTPS last autumn by asking its host for a certificate. The secure address worked, and that was where the job stopped.

The plain HTTP version still loaded, so the school's Google listing, its ads and three years of newsletters all led to pages marked Not secure.

On the secure pages, the logo was still loaded from an HTTP address written into the theme, so no page showed a padlock. That included the enrolment page, where parents type in their children's details.

The proper move took a morning: redirects from every old address, the logo and older images fixed at source, internal links updated, and the listing, ads and reporting tools pointed at the secure address.

Internal links and settings

On a WordPress site, the site address in the general settings needs to change to HTTPS, and so do the links already stored inside pages and posts.

Those links work through the redirects, but each adds a hop, and some pull in insecure images. A careful search and replace in the database fixes them, with a tool that understands how WordPress stores its settings.

Check the menus, the sitemap and any canonical tags as well, since each tells search engines which address is the real one.

Search Console, Analytics and listings

Search Console treats the HTTPS site as a separate property. Add it, or use the domain property introduced last month, which covers every version at once, and submit the sitemap again.

The change of address tool is for moving to a new domain, not for this. The redirects tell Google what it needs to know.

In Universal Analytics, the property and view settings each record the site's address with a choice of HTTP or HTTPS; switch both. In Google Ads, update the final URLs so every click lands directly on the secure page.

One side effect is welcome. Visitors coming from secure sites to an insecure one arrive without referral details, so some are counted as direct. After the move, more are credited to the site that sent them.

Then update the links you control elsewhere: Google My Business, the Facebook page, the Instagram profile, directory listings, email signatures and newsletter templates. Each one updated is one fewer redirect for every visitor who uses it.

Once everything works

When the site has run cleanly on HTTPS for a few weeks, whoever maintains it can add a setting called HSTS, which tells browsers to use the secure address every time.

Start with a short duration and lengthen it once nothing has broken, since browsers that have remembered the setting cannot easily be told to forget it.

The counter-case

The move is simpler on some sites than others.

A small site of plain pages with no forms, no shop and few images can move in an hour or two, with a short list to check.

A site with a rebuild booked for the coming weeks can make the move at launch instead, provided the launch date is real.

But no site is better off on plain HTTP. The label appears whether or not there is a form, and every visitor sees it before anything else.

Install the certificate, then finish the move: redirects, mixed content, links and settings.

The move, in order

  1. Install a certificate covering every version of the address.
  2. Redirect each HTTP page to its HTTPS match.
  3. Fix mixed content at its source.
  4. Update internal links and the site address setting.
  5. Add the HTTPS property in Search Console.
  6. Switch Analytics and ad URLs to HTTPS.
  7. Update your listings and email signatures.

Step two is the one that finishes the job. Without it, every old link, bookmark and printed address still leads to a page labelled Not secure, however well the secure version works.

Domains that only work over HTTPS are covered in the new .dev domains and what they require.

Frequently asked questions

Is installing a certificate enough?

No. Without redirects, the old HTTP pages still load and still show Not secure. The move also needs mixed content fixed, links updated and reporting tools told.

Is a free certificate good enough?

For a typical small business site, yes. Let's Encrypt certificates are free, many hosts renew them automatically, and they do the same job as a paid certificate.

Where should old HTTP pages redirect?

Each to its exact HTTPS equivalent, with a permanent 301 redirect in a single step. Sending every old page to the home page loses visitors along the way.

Why is the padlock still missing?

Usually because something on the page, often an image or the logo, still loads over plain HTTP. The browser developer console lists each insecure item.

What changes in Search Console?

The HTTPS site is a separate property, so add it, or use a domain property covering every version, and submit the sitemap again. No change of address is needed.

What does HSTS do?

A setting that tells browsers to use the secure address every time. Add it only after the site has run cleanly on HTTPS, starting with a short duration.

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.

Certificate installed, padlock still missing?

Send us the address. We will find each old link, insecure image and setting the move still needs.

Start a Conversation