HTTPS SEO

I start with a certificate from Let's Encrypt because it is free and automated. Then I set up 301 redirects at the server level – in Nginx that means a server block, in Apache a .htaccess rule. I always test with curl -I to confirm the response code and the destination. Next, I update every internal link. If your CMS stores absolute URLs, you might have to run a database replace. On a recent migration for a 5,000 page site, I found 1,200 hard-coded HTTP references in post content. I fixed those with a SQL query. After that, I submit the new HTTPS sitemap to Search Console and monitor the Index Coverage report for two weeks. I also set the canonical tag to the HTTPS version in the HTML head. I add an HSTS header with a max-age of one year and include preload if the site is ready. That tells browsers to always use HTTPS, which prevents man-in-the-middle attacks. Use relative URLs for internal links where possible to avoid hard-coding the protocol, making future migrations easier. Some people argue that HSTS preload is risky because once submitted, you cannot easily remove the domain. That is true – so I only preload after the redirects have been stable for at least a month. If your site uses a CDN, check that the CDN handles SSL termination properly and that you are not double-encrypting. For [technical SEO](/technical-seo/) purposes, I run a crawl of the old HTTP site and the new HTTPS site to compare status codes, missing pages, and any issues. I also verify that the [301 redirects](/301-redirect/) are server-level, not JavaScript based. JavaScript redirects are not reliable for search engines. The entire migration should be planned: set a date, measure rankings before, and monitor after. I have seen sites lose rankings simply because the redirects were not in place before the certificate expired or because they forgot to update the sitemap. That is why I always automate the certificate renewal with a cron job.

The most common mistake I see is mixed content. After migration, browsers may block insecure scripts or images, breaking pages. Use a tool like Why No Padlock? or crawl with Screaming Frog to find every HTTP resource. Fix them by updating the URL or using a Content-Security-Policy header that upgrades insecure requests. Do not use 302 redirects for the HTTP-to-HTTPS move. They are temporary and do not pass full link equity. Always use 301, which signals a permanent move. Another watch-out: if you block HTTPS pages in robots.txt, Google cannot crawl them. Keep robots.txt open; you may still want to block staging or duplicated paths, but do it on the HTTPS version explicitly. Edge case: what if you have a multilingual site with [hreflang tags](/hreflang-tags/)? Ensure that all language versions point to the HTTPS versions. If you forget, you confuse search engines. Also, if you have a sitemap, update the URLs inside to HTTPS. Google will still find the old one if you redirect, but it wastes crawl budget. Another watch-out: if you use a CDN like Cloudflare, you can use their SSL settings, but you need to set the redirect mode to 'Full' or 'Full (strict)' to avoid certificate errors. Check that your [canonical tags](/canonical-tags/) are self-referencing to the HTTPS version. I once crawled a site after migration and found 15% of pages still had HTTP canonicals. That creates duplicate content. I also watch out for external scripts: if you load analytics or ads over HTTP, they break on HTTPS pages. Use a protocol-relative URL (//) or force HTTPS. Finally, be careful with HSTS: do not set a long max-age until you are confident the migration is stable. A mistake there could block users if you need to revert.

I used to think HTTPS was a ranking boost, so I would rush the migration. But it is the foundation. I once moved a site over a weekend without checking internal links. Google indexed hundreds of HTTP pages as duplicate content because I had not set canonicals. It took three months to recover. I now do a pre-migration [SEO audit](/seo-audit/) of all URLs. Another mistake: I blocked HTTPS in robots.txt because I thought I was preventing duplicate crawling. Instead, Google could not access the new secure pages at all. I fixed that quickly, but the damage was done. I also ignored mixed content. An e-commerce site I migrated had a third-party checkout iframe loading over HTTP. The entire checkout page showed a warning in Chrome. Revenue dropped by 15% in the first week. I fixed it by forcing HTTPS on the iframe source. I learned the hard way that 302 redirects are not for permanent moves. On a test migration, I used 302 to see if everything worked, but Google treated the HTTP pages as the canonical, so the new HTTPS pages never gained ranking. I switched to 301 and saw the transfer within two weeks. Finally, I did not implement HSTS immediately. I assumed it was optional. Later, a security audit found that users could be downgraded to HTTP by an attacker. I added HSTS headers and submitted to the preload list after a month of stability. I also realised that failing to update the sitemap to HTTPS meant Google kept crawling the old HTTP sitemap, which redirected but wasted crawl budget. I now submit a new sitemap on the day of migration. Another thing: I forgot to update internal links in PDF files and other downloadable assets. Those broke for users. I now script a check for all external URLs in metadata.