How to Redirect HTTP to HTTPS Without Losing Rankings

Start by deciding which method fits your host. Some hosts handle HTTPS redirects at the server level, while others require you to edit configuration files. Pick the method you control end to end so you can verify each step as you go, rather than opening a support ticket halfway through and guessing what happened next.

Method by host and CDN

Your hosting setup determines where the redirect lives. Most B2B SaaS sites run on one of four common stacks.

Take Apache first. You can force HTTPS through the virtual host configuration by redirecting port 80 traffic to port 443. The alternative is an .htaccess file if your host allows it. Use one or the other, not both, because duplicate rules can create redirect loops that keep pages from loading at all.

Nginx handles this inside the server block. You add a rewrite directive that sends every HTTP request to the HTTPS version of the same URI, then listen on port 443 for the secure traffic. If you manage your own server this is the cleanest approach because the rule lives in one place and applies to every domain on that block.

Cloudflare and similar CDNs sit between the visitor and your origin server. They offer an HTTPS rewrite option in the dashboard that handles the redirect before a request ever reaches your host. This is useful when you cannot edit server configuration, but it means the redirect is not visible in your own files. If you later move hosts or change CDNs, you need to remember the rule lives with the provider, not with your site.

Windows IIS uses the URL Rewrite module. You create a rule that matches any HTTP request and rewrites it to HTTPS. This is common for older B2B SaaS applications still running on Windows infrastructure. If your team does not have access to IIS Manager, the host or administrator must add the rule for you.

Say you run a project-management SaaS with about thirty people and your site sits on Apache. You would edit the virtual host file, add the redirect from port 80 to port 443, restart Apache, and then open your homepage in a browser to confirm the address bar shows HTTPS and stays there when you refresh. If it bounces back to HTTP or throws a too many redirects error, the rule is fighting another rule somewhere else in the stack.

Update canonicals and sitemap after the redirect

Redirects send visitors and crawlers to the secure version, but your pages still carry their original signals until you tell search engines the secure URL is the canonical one. Update every self-referencing canonical tag so it points to the HTTPS version of that page. Do this across templates, not one page at a time, or you will miss the deep pages that drive qualified traffic.

Your sitemap should list only HTTPS URLs. If it still contains HTTP addresses, search engines will keep trying to crawl the old scheme even though the redirect sends them elsewhere. Regenerate the sitemap after the redirect is live, submit it through Search Console, and check that the URLs indexed under HTTP are dropping out while the HTTPS versions move in.

Internal links also need updating wherever you control them. A link that points to an HTTP page works because of the redirect, but it adds an unnecessary hop and can dilute the signal you are consolidating on the secure URL. Change navigation, footer links, and in-body links to the HTTPS versions so crawlers follow a direct path.

Verify the redirect worked

Open your site in a browser and type the HTTP version of the homepage. The address bar should switch to HTTPS immediately and remain there. Then do the same for a blog page, a product page, and a deep page several levels down. If any page loads over HTTP or shows a certificate warning, the redirect is incomplete or the SSL certificate does not cover that hostname.

Use Search Console to confirm Google is crawling the HTTPS version. Look at the coverage report for pages still indexed under HTTP and watch whether they decline over the next few crawls. The URL Inspection tool lets you request indexing on a few key HTTPS pages to speed up recognition.

A redirect chain happens when HTTP goes to HTTPS, then to www, then to the final page. Each hop slows the visitor and wastes crawl budget. Test with your browser developer tools or a redirect checker so every HTTP request goes straight to its HTTPS equivalent in a single step.

What usually goes wrong and how to spot it

Mixed content is the most common failure after a redirect. The page loads over HTTPS, but images, scripts, or stylesheets still request over HTTP. Browsers block those requests or show a warning that the connection is not fully secure. Open the browser console on several pages and look for mixed content warnings. Fix them by updating the source URLs to HTTPS or protocol-relative paths.

A redirect loop sends the browser back and forth between HTTP and HTTPS until it gives up. The symptom is a too many redirects error. This usually means two rules are fighting, such as one in .htaccess and one in the virtual host, or a CDN rule conflicting with your origin server. Disable one rule at a time until the loop stops, then keep the one you can control most easily.

Forgetting to renew the SSL certificate makes the secure site unreachable. Visitors see a certificate error before they ever reach your content. Set a reminder well before expiry and check the certificate details in the browser lock icon after the redirect is live.

Canonical tags left on HTTP confuse search engines about which version is preferred. If your canonical still says HTTP while the page redirects to HTTPS, you are sending mixed signals. Audit a sample of pages after the migration and confirm every canonical points to the secure URL.

SaaS sites with subdomains for app access, documentation, or marketing campaigns need the redirect applied to each one. A redirect on the root domain does not cover app.yourdomain.com or docs.yourdomain.com. Check each subdomain individually and apply the same method where it is publicly accessible.

How AI search treats the move

AI answers cite pages they can reach and trust. If your HTTPS pages are new to the index, citation systems may not immediately associate them with the authority the HTTP version built. The redirect consolidates ranking signals, but AI systems still need to recrawl and reattribute those signals to the secure URL. Monitor whether your pages continue appearing in AI answers after the move, and if citations drop, check that the HTTPS versions are indexed and that canonicals are consistent.

Pages that were already cited in AI answers under HTTP should recover their visibility faster under HTTPS because the redirect preserves the relationship between the URL and its content. The risk is not the redirect itself but an incomplete rollout where some pages move and others do not, splitting the signal across two schemes.

Choose the right method for your setup

If you manage your own server, use Apache or Nginx configuration because the rule is in your files and survives host changes. If you are on a managed platform where you cannot edit server configuration, use the CDN rewrite option but document where the rule lives so your team does not forget it. If you are on Windows IIS, use the URL Rewrite module and confirm with your administrator that the rule is applied before you update canonicals and sitemaps.

Start with the redirect, then update canonicals and sitemap in the same session, and verify the next day. Doing them in that order means crawlers encounter the secure version first and the canonicals they find match what they see.

Take a help desk SaaS with a documentation subdomain and a marketing site on the root. The team redirects the root domain through Cloudflare because they cannot edit the host configuration, but they forget the docs subdomain. Visitors to the main site see HTTPS, while documentation pages remain on HTTP and show certificate warnings. The fix is to apply the same redirect method to the subdomain, then update its canonicals and sitemap separately.

Do not guarantee that rankings will stay exactly the same. A redirect preserves most signals, but search engines recrawl at their own pace and AI citation systems update on their own timelines. Your job is to make the move clean and complete so nothing is lost to a technical mistake rather than to a change in how search evaluates your site.

Want us to look at your site? Book a call with Comppound and we'll map out the biggest growth opportunities.

Comppound helps teams make these infrastructure changes without losing the organic visibility they already have. See how we do it.