You can move a site from HTTP to HTTPS without losing rankings, and most sites that plan the move properly see little more than a short wobble while Google recrawls. The trick is to treat it as a full site move, not a server setting. Every old URL needs a single 301 redirect to its HTTPS twin, every page needs to load all of its files over HTTPS, and Google needs clear signals (canonicals, sitemaps, internal links) that the secure version is now the real one.
This guide walks through the move in the order we do it, with the checks that catch the usual problems before they cost you traffic.
Why move to HTTPS now
In August 2014 Google announced that HTTPS is a ranking signal. It was described as very lightweight, affecting fewer than 1% of global queries at launch, with more weight given to content quality. So nobody should expect a jump in rankings from the switch alone.
There are better reasons than the ranking boost:
- Google now prefers the HTTPS version. On 17 December 2015 Google said it will start indexing HTTPS pages by default when both versions of a page exist, as long as the HTTPS page is set up cleanly. If you already serve both, Google may pick the secure one for you, and you want that choice to be deliberate.
- Certificates are getting cheaper and easier. Let’s Encrypt opened its public beta on 3 December 2015, offering free, automated certificates. Many hosts are adding one-click certificates as well.
- Referral data. When a visitor clicks from an HTTPS site to an HTTP site, the browser drops the referrer. Moving to HTTPS keeps that information intact when other secure sites link to you.
- Trust. Forms that collect names, emails or card details should never travel in plain text. Visitors notice the padlock, and they notice warnings even more.
Before you start: pick the right certificate
There are three common types:
- Domain validated (DV): confirms you control the domain. Fast and cheap or free. Fine for most business sites and blogs.
- Organization validated (OV): the certificate authority also checks your company details.
- Extended validation (EV): the strictest checks. Browsers show the company name in the address bar.
For search, all three work the same way. Google’s 2014 guidance asked for 2048-bit key certificates, and that is the standard most providers now issue. Also check the signature algorithm. Browsers are phasing out SHA-1 certificates and certificate authorities stop issuing them from 1 January 2016, so make sure yours uses SHA-2.
If you run several subdomains, a wildcard certificate (for example *.example.com) saves you buying one per subdomain. If you serve several domains from one server, look at a multi-domain (SAN) certificate.
Step 1: Crawl and record the current site
Before touching anything, take a snapshot:
- Crawl the HTTP site with a tool such as Screaming Frog and export every URL, status code, canonical and title.
- Export your top landing pages from Google Analytics for the last few months.
- Note which pages have the most external links. These are the URLs you cannot afford to break.
- Record current rankings for your main keywords.
This list becomes your test plan. After launch you will check that every URL on it redirects once, to the right place, with a 200 at the end.
Step 2: Set up HTTPS on a staging copy
Install the certificate on a staging server or a test subdomain first. Then load key templates (home, category, product or service page, blog post, contact form) and look for problems:
- Mixed content. A page loaded over HTTPS that pulls an image, script, stylesheet, font or iframe over HTTP. Browsers block some of these files outright and show a warning for others. A blocked script can break menus, sliders or checkout.
- Hard-coded URLs in templates, theme options, widgets and page content.
- Third-party embeds such as maps, video players, chat widgets, ad code and tracking tags. Most major providers support HTTPS, but older embed codes may still use
http://.
Open the browser’s developer console on each template. It lists every insecure request so you can fix them one by one.
WordPress sites
On WordPress, update the WordPress Address and Site Address under Settings, General. Then run a careful search and replace on the database to change http://yourdomain.com to https://yourdomain.com in post content and settings. Use a tool that handles serialized data properly, and back up the database before you run it. Check page builder layouts and theme option panels too, since they often store absolute URLs.
Step 3: Plan your redirects
Use a permanent 301 redirect from every HTTP URL to the matching HTTPS URL. Keep the path and query string the same. A few rules:
- One hop.
http://example.com/pageshould go straight tohttps://www.example.com/pageif www is your preferred version. Avoid chains like HTTP to HTTPS, then non-www to www. - Page to page. Never send every old URL to the homepage. That throws away the value of deep links.
- Server level. Do it in the Apache
.htaccessfile, the Nginx config or your host’s control panel rather than with a plugin or JavaScript, so it is fast and works for every file type. - Images and PDFs too. Files that earn links or image search traffic need redirects as well.
Step 4: Update every internal signal
Redirects catch old links, but you do not want your own site leaning on them. Update:
- Canonical tags so they point to HTTPS URLs.
- Internal links in menus, footers, content and breadcrumbs.
- XML sitemaps so they list only HTTPS URLs.
- hreflang tags if you run several languages or countries.
- Structured data that contains URLs, such as logos and breadcrumbs.
- robots.txt, so it does not block the HTTPS version or the files it needs.
Google’s December 2015 note listed the conditions under which it will prefer the HTTPS page. Among them: the page should not have insecure dependencies, should not be blocked by robots.txt, should not redirect back to HTTP, should not carry a canonical pointing to HTTP and should not be noindexed. Your checklist above covers each one.
Step 5: Launch and tell Google
On launch day:
- Switch on the redirects.
- Add the HTTPS version of the site as a new property in Google Search Console. Search Console treats HTTP and HTTPS (and www and non-www) as separate properties, so you need the secure one verified to see its data.
- Submit the HTTPS sitemap in the new property.
- If you use a disavow file, upload it to the HTTPS property as well.
- Set the preferred domain (www or non-www) in the new property to match your redirects.
Note that the Change of Address tool in Search Console is not meant for protocol changes. The redirects and the new sitemap are what tell Google about the move.
Outside Google, update the website URL in Google Analytics property and view settings, your AdWords ads and sitelinks, social profiles, email signatures and your Google My Business listing. Ask partners who link to you often to update the link when convenient.
Step 6: Add HSTS once everything works
HTTP Strict Transport Security (HSTS) is a response header that tells browsers to only use HTTPS for your domain. It removes a redirect for returning visitors and protects against downgrade attacks. Start with a short max-age value, confirm nothing breaks, then raise it. Only consider the browser preload list once you are certain every subdomain supports HTTPS, because leaving it is slow.
What to watch in the weeks after
Expect some movement while Google recrawls and reprocesses the site. Watch these:
- Indexed pages in both properties: HTTPS should rise as HTTP falls.
- Crawl errors in the HTTPS property, especially 404s from missed redirects.
- Organic landing page traffic in Analytics compared with the snapshot you took.
- Rankings for your main keywords.
- Mixed content warnings, which tend to reappear when someone adds an old embed code to a new post.
If traffic drops sharply and stays down after a couple of weeks, check the basics again: redirect chains, canonicals still pointing to HTTP, a robots.txt blocking the secure site, or a sitemap still listing HTTP URLs. These four cause most of the trouble after a move.
Common mistakes
- Using 302 (temporary) redirects instead of 301s.
- Redirecting everything to the homepage.
- Leaving canonical tags pointing to HTTP.
- Forgetting images, CSS and JavaScript referenced from the stylesheet itself.
- Letting the certificate expire. Put the renewal date in a calendar, or automate renewal if your provider supports it.
- Changing URLs, design and hosting at the same time as the protocol. If you can, move to HTTPS on its own so any problem is easy to trace.
FAQ
Will I lose rankings when I move to HTTPS?
A short fluctuation is normal while Google recrawls. With clean one-to-one 301 redirects and updated signals, rankings usually settle back where they were.
Do I need an expensive certificate for SEO?
No. Google does not treat DV, OV and EV certificates differently in ranking. Choose based on the trust signals you want to show visitors.
Should I keep the HTTP version live as well?
No. Serve every page over HTTPS and redirect HTTP requests. Two live versions split signals and create duplicate content.
Do I need to change anything in Google Analytics?
Update the default URL in property and view settings to HTTPS. Your tracking code itself does not need to change.
Need a hand with the move?
An HTTPS migration is mostly careful, repetitive checking. If you would rather have someone plan the redirects, clean up mixed content and watch Search Console with you after launch, our SEO team can help. See how we approach technical SEO at IWS SEO services.
