Moving a website to HTTPS without losing traffic

Most traffic losses after switching to HTTPS are not caused by the switch itself. They come from redirects that point to the wrong place, pages that still call insecure images, or a Search Console property nobody updated. An HTTP to HTTPS migration is one of the safer site changes you can make, as long as the steps happen in the right order and someone checks the result.

Below is a working plan you can follow or hand to your developer, from preparation through to the weeks after launch.

Before you start: take stock of the current site

Ten minutes of preparation saves hours of guesswork later. Gather the following:

• A full backup of files and database, stored somewhere other than the server.
• A list of the site’s URLs, either from your XML sitemap or a crawl with a desktop crawler tool.
• A note of which domain version is currently primary: www or non-www.
• Your current organic clicks from Google Search Console, so you have a baseline to compare against.
• Any third-party services that reference your address, such as payment gateway callback URLs, ad campaigns, email templates and your Google Business Profile.

Pick a quiet time for the change. For most Indian B2C sites that means late night or early morning on a weekday, not during a festival sale.

Step 1: Install and test the certificate

Get a certificate that covers every hostname you use, typically both example.in and www.example.in. Most control panels offer free Let’s Encrypt certificates with auto-renewal, and Cloudflare can provide one at its edge.

Before redirecting anyone, load the https:// version of a few pages manually. Confirm the padlock appears, the certificate name matches, and the page renders. If you use Cloudflare, set its SSL mode to Full (strict) once the origin server has a valid certificate, rather than “Flexible”, which leaves the connection between Cloudflare and your server unencrypted.

Step 2: Fix mixed content before visitors see it

Mixed content happens when an HTTPS page loads resources such as images, scripts, stylesheets, fonts or iframes over plain HTTP. Browsers block insecure scripts outright, which can break menus, sliders and forms, and they may upgrade or flag insecure images.

Where insecure links usually hide

• Hard-coded http:// URLs inside page and post content in the database.
• Theme files and custom CSS with background image paths.
• The site URL setting in your CMS configuration.
• Old embed codes for maps, videos or chat widgets.

Run a careful search-and-replace on the database for your own domain, changing http://yourdomain to https://yourdomain. Use a tool that handles serialised data correctly if you are on WordPress, and test on a copy first. Then open key pages with Chrome DevTools and check the Console for mixed content warnings. External resources that do not support HTTPS at all should be replaced or removed.

Step 3: Set up permanent 301 redirects

Every old HTTP address must send visitors and search engines to its exact HTTPS equivalent with a 301 status code. This tells Google the move is permanent so it can transfer signals to the new URLs.

Redirect rules to get right

1. Page to page, not everything to the homepage. http://example.in/services should go to https://example.in/services, keeping the path and query string.
2. One hop only. Avoid chains like http://example.in to https://example.in to https://www.example.in. Redirect straight to the final preferred version.
3. Server-level where possible. Rules in Nginx, Apache or at the CDN are faster and more reliable than plugin or JavaScript redirects.
4. No loops. A common cause is a CDN talking to the server over HTTP while the server forces HTTPS, bouncing forever. Test after enabling.

Check several URLs with a redirect checker or with curl, and confirm each returns a single 301 followed by a 200.

Step 4: Update internal signals and references

Redirects are a safety net, but your own site should link directly to the new addresses. Update:

• Internal links in menus, footers and content.
• Canonical tags, which should reference HTTPS URLs.
• Hreflang tags, if you run language versions.
• The XML sitemap, which should list only HTTPS URLs.
• Structured data and Open Graph image URLs.
• robots.txt, particularly the Sitemap line.

Outside the site, change the website link on your Google Business Profile, social media bios, WhatsApp Business profile, and paid ad destinations. Ask payment gateways and any webhook providers to use the new callback addresses.

Step 5: Tell Google through Search Console

If you already use a Domain property, verified by a DNS record, it covers both protocols and all subdomains, so nothing new is needed. If you only have a URL-prefix property for http://, add an https:// property as well and keep the old one for comparison.

Submit the updated sitemap in the new property. Use the URL Inspection tool on your homepage and a couple of important service or product pages to confirm Google sees the HTTPS version. There is no separate “change of address” tool for protocol moves; that tool is for moving to a different domain.

Step 6: Add HSTS once everything is stable

HTTP Strict Transport Security is a response header that tells browsers to use HTTPS for your domain automatically, even if someone types http://. It closes a small window where the first request could be intercepted.

Introduce it cautiously. Start with a short max-age, such as a few minutes or a day, confirm nothing breaks, then raise it gradually to a year. Only add includeSubDomains once every subdomain, including old ones like mail or staging, works over HTTPS. Joining the browser preload list is a long-term commitment that is slow to undo, so hold off until you are certain.

What to watch in the weeks after the switch

A short wobble in reported traffic is normal while Google recrawls. Watch these during the first month:

• Page indexing report in the HTTPS property, where indexed pages should gradually rise.
• Performance report clicks compared with your pre-migration baseline.
• 404 errors in server logs from any URL that redirected incorrectly.
• Certificate auto-renewal, confirmed before the first expiry date.
• Form submissions and payments, tested end to end.

If clicks fall sharply and stay down beyond a few weeks, recheck for redirect chains, canonical tags still pointing to HTTP, or pages accidentally set to noindex.

Your migration checklist in one place

Print this and tick through it on the day: backup taken, certificate covers all hostnames, mixed content cleared, single-hop 301s tested, internal links and canonicals updated, sitemap regenerated, Search Console property confirmed, external profiles updated, HSTS introduced with a short max-age, renewal checked.

If you would rather have it handled, our team can plan the move as part of website development and maintenance work, or you can raise a request through support.

Frequently asked questions

Will switching to HTTPS drop my Google rankings?

Done correctly with page-to-page 301 redirects, rankings usually hold steady. Brief fluctuations can occur while Google recrawls, and they generally settle within a few weeks.

How long should I keep the HTTP redirects in place?

Permanently. Old links on other websites, bookmarks and printed materials will keep pointing at HTTP addresses for years, and the redirect costs almost nothing to maintain.

Do I need a new Search Console property after moving to HTTPS?

Only if you used a URL-prefix property. A Domain property verified through DNS already includes both HTTP and HTTPS versions.

Why does my site show a redirect loop after enabling HTTPS?

Usually two systems disagree, such as a CDN in flexible SSL mode requesting pages over HTTP while the server forces HTTPS. Aligning the CDN setting and removing duplicate redirect rules normally fixes it.