Moving to HTTPS Without Losing Your Rankings

By the spring of 2018, a good number of the small businesses I work with are still running their site on plain HTTP, no padlock in sight. Google has announced that Chrome will soon flag those addresses as "Not secure," starting in July, a warning any visitor sees without knowing what it means. Switching to HTTPS sounds simple: install a certificate, and the padlock shows up. What actually costs a site its rankings is everything around that certificate, not the switch itself. A missed redirect, a Search Console property that never gets created, an internal link still pointing to the old address: any one of those can knock back positions built up over years. Here is the checklist I run through with clients for an HTTPS migration that keeps the rankings intact.

Why is Google pushing sites toward HTTPS?

Google has counted HTTPS as a ranking signal since 2014, and the pressure has grown every year since that announcement. Encryption protects whatever passes between a visitor and the site, which matters the moment a contact form or a quote request is involved. Chrome is adding its own pressure now: the version due in July will mark every HTTP page as "Not secure" right in the address bar, a warning visible to anyone even if they never read a line of the page. For a small business whose site exists to generate calls or quote requests, that warning alone sends part of the audience elsewhere before they even scroll.

What actually costs a site its rankings during a migration?

Most of the losses I see trace back to steps skipped around installing the certificate, things like a missing redirect or a canonical tag nobody updated. These are the mistakes that show up most often on sites I take over after a rough migration:

• No page-by-page 301 redirect: only the homepage redirects, and every other HTTP page stays live next to its HTTPS duplicate.
• Internal links (menu, footer, blog posts) still point to the old HTTP addresses, forcing an extra redirect on every click.
• Canonical tags on every page still point back to the HTTP version.
• The sitemap.xml file never gets regenerated with the new addresses, so Google keeps working from a stale list.
• No HTTPS property gets added in Search Console, so the owner keeps watching the old HTTP property and loses visibility on what happens after the switch.
• Mixed content: one image, script, or font still loading over HTTP, which keeps the padlock from showing even after the certificate is installed.

How do you prepare a migration that does not cost you traffic?

Preparation starts with a full list of every address the site currently has, not just the main pages. I build that list from the existing sitemap plus a crawl of the live site, then prepare a 301 redirect from each HTTP address to its exact HTTPS equivalent, never routing everything through the homepage. Once the certificate is installed and verified (the full chain, not just the primary certificate), I update every internal link in the site's code to point straight to HTTPS instead of relying on a redirect for every click. I correct canonical tags page by page, regenerate the sitemap.xml with the new addresses and resubmit it, and add a new HTTPS property in Search Console before launch day, so tracking starts on day one instead of after the fact. For a client running AdWords campaigns, the display paths on every ad get updated the same day as the migration, so nobody clicks an ad and lands on a redirect chain.

Should both language versions of a site move at the same time?

Yes, always, because a French site living at the root domain and an English version under /en/ depend on each other through hreflang tags, and migrating one language without the other breaks that pairing as far as Google is concerned. I prepare a redirect line for every address, in both languages, then check after launch that each French page still points to its matching English page, and the other way around, with the correct HTTPS address on both sides. An hreflang tag still pointing at an old HTTP address gets ignored by Google, which amounts to losing the link between the two versions of the site until the error gets fixed.

What should you check in the days right after launch?

The first ten days after a migration tell you the most, because that is when a skipped step becomes visible. I open the browser console on the main pages to catch any mixed content still blocking the padlock. I check the coverage report in the new HTTPS property in Search Console for errors such as page not found or a redirect loop. I track how each important page's indexation status changes to confirm the new HTTPS addresses are replacing the old ones one by one, rather than sitting alongside them. If a client emails to say a page stopped working, I check whether a redirect exists for that exact address before looking anywhere else.

How long before rankings settle back to normal?

Expect anywhere from a few days to a few weeks for Google to fully process the change, and some fluctuation during that window is normal even when everything was done correctly. I use Fetch as Google in Search Console, along with a site: search on the domain, to check, address by address, that Google has indexed the new HTTPS version and stopped showing the old one in results. A dip that lasts a few days is not a sign anything went wrong. A dip that drags on for several weeks, or HTTPS pages that never make it into the index while the HTTP pages stay indexed, almost always means a redirect is missing somewhere in the list.

What about external links still pointing to the old address?

The 301 redirects take care of visitors arriving through an old external link, so you do not need to convince every site that ever linked to you to update that link for the traffic to land in the right place. What is worth updating by hand are the places you control directly: the website field on your Google My Business listing, your Facebook and Twitter profiles, any local directory listing you keep active, and your email signature. Those updates matter less for rankings than the redirects themselves, but they stop a client from hitting a security warning after clicking a link from your own listing.

Does this need a developer, or can you do it yourself?

Installing a certificate is something most hosts will walk you through on their own, but the part that protects your rankings takes more than an active certificate. The redirect list, the internal link cleanup, and the Search Console follow-through are what separate a site that keeps its rankings from one that starts over, and skipping any one of those steps is usually what turns a routine certificate install into a support call two weeks later. I run this same checklist on every web design project where an HTTPS migration is part of the work, before design even starts.

Drafted with AI assistance, checked and published by Marven Salgado.