Redirect HTTP to HTTPS: HTTPS redirects and staying indexed

Redirect every HTTP URL to the same path on HTTPS

The mapping has to be one to one. http://example.com/blog/pricing-guide goes to https://example.com/blog/pricing-guide, not to https://example.com/. This sounds obvious and it is the single most common way an HTTPS migration destroys traffic.

Redirecting the whole HTTP site to the HTTPS homepage is a redirect that Google will usually treat as a soft 404, because the destination has nothing to do with the requested page. Every ranking URL you do that to loses its position and starts again from nothing. Rules that capture the path and reattach it are the same length as rules that do not, so there is no reason to get this wrong.

Use a permanent redirect. Google's documentation on redirects says that for permanent redirects, meaning 301 and 308, Googlebot follows the redirect and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. For temporary redirects, 302, 303 and 307, Googlebot still follows it but the indexing pipeline does not use it as a canonical signal. A 302 on an HTTPS move means you did the work and withheld the signal that makes it count.

• Capture the request path and append it to the HTTPS host
• Send 301, not 302, because the change is not going to be reverted
• Redirect in one hop, never HTTP to www to HTTPS as separate steps
• Keep the redirects in place long term, not just for launch week

Set the redirect at the server, not inside the page

Google's own guidance ranks the options. It says a server side redirect has the highest chance of being interpreted correctly by Google, and that you should only use JavaScript redirects if you cannot do server side or meta refresh redirects. That ordering is worth following literally.

There is a practical reason beyond correctness. A redirect that lives in your application only fires after the request has reached PHP, Node or Python, which means the server has already accepted an insecure connection and done work. A rule in nginx, in Apache's vhost, or at the CDN edge answers on the first byte and costs nothing.

If you genuinely cannot reach the server config, Google does treat an instant meta refresh redirect as a permanent redirect and a delayed one as temporary, so an instant meta refresh is a workable fallback. It is still slower and more fragile than the real thing.

Update internal links, canonicals and the sitemap to HTTPS

Once the redirect is live the site works, so most teams stop here. The problem is that every internal link still written as http:// now costs an extra round trip, and every one of those is a redirect Googlebot has to follow before it reaches real content.

Google's guidance on enabling HTTPS is to make sure intrasite URLs and external URLs do not depend on a specific protocol, and to use relative paths or protocol relative forms. Doing a find and replace across templates, content and the database is tedious and it is the difference between a crawl that reaches your pages directly and one that spends its budget on 301s.

The sitemap matters more than people expect, because sitemap presence is one of the four canonicalization signals Google names. A sitemap still listing HTTP URLs is actively arguing for the version you are trying to retire. Regenerate it, make sure every entry is HTTPS, and submit it in Search Console so Google learns the new URLs quickly.

Check the canonical tags at the same time. A page that redirects to HTTPS but then declares a canonical pointing back at its HTTP self is sending Google two contradictory instructions, and this is a genuinely common bug in templates that build the canonical from a hardcoded base URL.

What to change in Search Console, and the tool you should not use

Search Console splits data by property type, and this trips people up immediately after a move. A URL prefix property is protocol specific: http://example.com/ and https://example.com/ are two different properties with two different sets of data. If you only ever verified the HTTP one, your reporting appears to collapse on migration day even though the site is fine.

A domain property covers every protocol and subdomain at once, so it is the version worth having through a migration. Add the HTTPS URL prefix property as well if you want to watch the two protocols separately while the move settles, which is useful for spotting URLs that never made it across.

The tool to skip is Change of Address. Google's site move documentation states it plainly: if you are moving your site from HTTP to HTTPS, you do not need to use the Change of Address tool. That tool is for moving between domains and it operates at the domain level, so it has nothing to offer a protocol change. Plenty of migration checklists still tell people to run it, and following that advice wastes time on a step Google has said is unnecessary.

• Verify a domain property so HTTP and HTTPS data stay together
• Keep or add the HTTPS URL prefix property for granular diagnosis
• Submit the regenerated HTTPS sitemap
• Do not run Change of Address, it is the wrong tool for a protocol move

Mixed content, HSTS and the certificate itself

Mixed content is when an HTTPS page pulls a script, stylesheet or image over HTTP. Browsers block active mixed content outright, which means the page can render without the JavaScript or CSS it depends on. If Google renders that broken version, it indexes the broken version.

HSTS is the finishing move rather than the starting one. Google describes it as telling the browser to request HTTPS pages automatically even if the user types http in the address bar. It removes the redirect hop entirely for returning visitors. The warning attached to it is real: do not enable HSTS until you are certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors, because clients that have your site listed as a known HSTS host are likely to hard fail if your TLS configuration ever breaks.

On the certificate, Google's advice is unglamorous. Use a 2048 bit key, because a shorter key can be broken by brute force guessing while a longer one uses resources for no benefit. Any publicly trusted certificate authority is fine, and a free automated certificate renews itself, which removes the most common cause of an unplanned outage.

How long the move takes, and what a normal dip looks like

Google's site move documentation gives the honest range: a small to medium sized website can take a few weeks for most pages to move, and larger sites take longer. It also says visibility may fluctuate temporarily during the move, and that this is normal.

That sentence is worth keeping somewhere visible, because week two of an HTTPS migration is when somebody suggests rolling it back. Rolling back is much worse than waiting. You would be asking Google to reverse a canonical decision it is halfway through making, and you would need a second set of redirects to do it.

What is not normal is a drop that does not recover, or one where the HTTP URLs stay indexed for months. That points at a specific fault rather than at latency: a redirect that is missing on some paths, a canonical still declaring HTTP, a robots.txt on the HTTPS host that blocks crawling, or a sitemap that was never regenerated. Those are all findable in an afternoon.

Keep the redirects long after the move looks done. Google recommends keeping redirects for as long as possible, generally at least one year, and there is no reason to remove them at all when they cost nothing to leave in place.

The HTTPS mistakes that actually cost indexing

Almost every failed HTTPS migration we see comes down to a short list, and none of the items on it are about cryptography.

The one that hides longest is the robots.txt file. Each host serves its own, and a staging or pre launch configuration that disallowed everything on the HTTPS host will quietly prevent the entire new version of the site from being crawled while the padlock looks perfect to you.

• Redirecting all HTTP URLs to the HTTPS homepage instead of matching paths
• Using 302 instead of 301, which withholds the canonical signal
• Chaining HTTP to www to HTTPS as separate hops, when Google follows up to 10 by default and every hop is wasted crawl
• Leaving rel=canonical pointing at the HTTP version
• A sitemap that still lists HTTP URLs, which argues against your own redirect
• A robots.txt on the HTTPS host left over from staging that disallows crawling
• A noindex tag that was fine on staging and shipped to the live HTTPS site
• Internal links still hardcoded to http://, turning every click into a redirect
• Mixed content that stops the page rendering the way Google needs to see it