Switching a site from HTTP to HTTPS means installing an SSL certificate on your server, pointing your site at its https URLs, and redirecting the old http ones so nothing is left behind. The work itself takes an afternoon on most sites. Below is the whole process in six steps, plus where the setting lives on the five platforms people ask about most.
Quick answer: get an SSL certificate (most hosts issue one free), install it on your server, change your site’s URLs from http to https in your platform’s settings, add a 301 redirect so old links follow, fix anything still loading over http, then add the https property in Google Search Console and resubmit your sitemap.
SSL (short for Secure Sockets Layer, though certificates issued today all use TLS) is what makes https possible. If you want the background first, read what an SSL certificate is.
How to switch from HTTP to HTTPS in 6 steps
- Get an SSL certificate. Free from your host or Let’s Encrypt, or paid if you need a warranty, verified company details or wildcard coverage.
- Install it on your server. Through your hosting panel, with Certbot, or manually from a CSR.
- Point your platform at its https URLs. Every CMS stores its own site address, and it has to be updated.
- Redirect http to https permanently with a 301, at server level.
- Fix what still loads over http: mixed content, internal absolute links, caches and feeds.
- Tell search engines. Add the https property in Search Console, resubmit your sitemap, check your canonicals.
Each step is expanded below. If you already have a certificate and only need the platform setting, skip to step 3.
Before you start: back up your site and its database, and if you have a staging environment, run the change there first. Two of the steps below can lock you out of your own admin if the certificate turns out not to be working, so a backup is the difference between a five-minute fix and a bad afternoon. On a shop, do this outside peak hours: every minute the checkout is unavailable is a lost order.
Why switch now: Chrome makes HTTPS the default in October 2026
The usual arguments for HTTPS are still true, but there is now a date attached, which changes the calculation for anyone still putting this off.
Chrome is turning on Always Use Secure Connections by default, in two stages. In April 2026, Chrome 147 enabled it for everyone on Enhanced Safe Browsing, which is more than a billion people. In October 2026, Chrome 154 extends it to all users globally. With it on, Chrome tries https first and shows a warning before loading a public http site the user has not visited before.
In other words, if your site is still on http after October 2026, a large share of your visitors will meet an interstitial warning before they reach it. Private addresses such as routers and intranets are treated differently and are not warned about by default.
HTTPS is now a speed decision too
This part gets left out of most migration guides. HTTP/2 does not formally require encryption, but no major browser has ever implemented it over unencrypted connections, so in practice you cannot use it without HTTPS. HTTP/3 goes further: it requires TLS 1.3 and has no unencrypted mode at all. Staying on http therefore locks your site out of both modern transport protocols and the performance that comes with them.
The familiar reasons still apply. Browsers label http pages as Not Secure, form data and passwords travel in the clear without a certificate, payment gateways refuse to operate over http, and Google has treated HTTPS as a ranking signal since 2014. That last one is a real but light signal, so treat it as a bonus rather than the reason.
Step 1: Get an SSL certificate
Check your hosting panel first. Most hosts now issue free Let’s Encrypt certificates through an SSL/TLS or AutoSSL section, and many have already issued one you are not using. A free certificate encrypts traffic exactly as well as a paid one; what differs is what the certificate authority verified before issuing it, and what backs it when something goes wrong.
| Type | What the CA checks | Issued in | Fits |
|---|---|---|---|
| Domain Validation (DV) | That you control the domain | Minutes | Blogs, brochure sites, most small sites |
| Organization Validation (OV) | The domain plus your registered organization | 1 to 3 business days | Business sites, member areas, client portals |
| Extended Validation (EV) | A full legal and operational check of the company | 1 to 3 business days | Stores, finance, anywhere identity matters |
If your site uses subdomains, a wildcard certificate covers them all with one certificate. Not sure which type applies? The SSL Wizard narrows it down in a few questions, or browse the certificates directly.
One thing to plan for whichever you choose: Let’s Encrypt certificates last 90 days and are meant to renew automatically about 30 days before expiry. When that automation breaks, and it does, the site works for weeks and then goes insecure without warning. Confirm auto-renewal is on, and check the certificate once after the first expected renewal date.
Step 2: Install it on your server
- Hosting panel. The fastest route. On cPanel, SSL/TLS sits under Security. Issue for the apex domain and the www version, or whichever you missed will throw a name mismatch warning.
- Certbot on a VPS with no panel. It issues the certificate, configures the server and installs its own renewal timer.
- Manually for a paid certificate: generate a CSR with the CSR generator or one of our over 70 tutorials on how to create a CSR, complete validation, then install the certificate, key and intermediates. We have over 80 SSL installation guides, including cPanel.
Verify before you go further. Run the SSL Checker against your domain. The most common quiet failure is an incomplete certificate chain: the site shows a padlock in your desktop browser, because it has cached the intermediate certificate from somewhere else, while mobile browsers and payment gateways fail. The checker reports it.
Step 3: Point your platform at its HTTPS URLs
A working certificate makes https available. Your site will keep generating http links until you tell it not to, because every CMS stores its own address. Here is where that setting lives.
| Platform | Where the setting lives |
|---|---|
| WordPress | Settings > General, change both WordPress Address (URL) and Site Address (URL). Since version 5.7, core also rewrites insecure URLs in your content once both are on https, and Site Health offers a one-click switch |
| Joomla | System > Global Configuration > Server, set Force HTTPS to Entire Site |
| PrestaShop | Shop Parameters > General, run the HTTPS check, set Enable SSL to Yes, then Enable SSL on all pages, then Save. The second switch stays locked until the first is saved |
| Magento 2 | Stores > Configuration > General > Web, open Base URLs (Secure), set the secure base URL to https, then set Use Secure URLs on Storefront and Use Secure URLs in Admin to Yes and press Save Config, then clear the cache. Those two settings make Magento issue https URLs; only the admin one enforces a redirect, so the storefront still needs step 4 |
| Drupal | No core setting, and nothing in .htaccess to switch on: the commented rules Drupal ships there redirect between www and non-www, not http to https. Add the server-level rule from step 4 to that same file |
| Shopify, Wix, Squarespace | Nothing to do. HTTPS is automatic and cannot be switched off |
That Drupal row is worth reading twice, because a lot of guides get it wrong. Drupal’s .htaccess does contain commented-out redirect rules, so it is easy to assume they are the HTTPS ones. They are not. This is what is actually in there, and it only chooses between www and non-www:
# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Note the protossl variable in that last line: it preserves whichever protocol the request arrived on, so uncommenting those rules leaves an http visitor on http. Use the ordinary Apache rule from step 4 instead.
If your platform is not listed, do not worry about finding an equivalent setting. The server-level redirect in the next step works regardless of what runs on top of it.
Step 4: Redirect HTTP to HTTPS permanently
Your pages now answer on https, but they still answer on http too, and every old link, bookmark and indexed URL points there. A permanent redirect fixes that.
It has to be a 301, not a temporary 302. A 301 tells search engines the move is permanent. Google states that 301 and other permanent redirects do not cause a loss in PageRank, which is worth knowing, because the fear of losing rankings is what keeps most sites on http longer than they should be.
On Apache, add this near the top of .htaccess in your site root:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]The condition must read off, meaning “redirect when the request is not already secure”. Written as “on”, which appears in a surprising number of published snippets, it fires only on requests that are already https and sends them to https again, which is a loop.
On Nginx there is no .htaccess. Edit the server block:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Test with nginx -t, then reload with systemctl reload nginx.
If you get ERR_TOO_MANY_REDIRECTS straight after adding this, the usual cause is a proxy such as Cloudflare set to Flexible SSL: it talks to your server over http while your server redirects to https, so the two bounce the request between them. Set the encryption mode to Full (strict) and keep a valid certificate on the origin.
Step 5: Fix what still loads over HTTP
Mixed content. A page served over https that still pulls in an image, script or stylesheet over http is mixed content. Browsers quietly upgrade some resources, mostly images and media, and refuse others outright, which is why an affected page can arrive completely unstyled. The browser console names the offending file. Our guide on how to fix mixed content covers the diagnosis.
Internal absolute links. Any link on your own site written as a full http address still points at http, and now takes an extra redirect hop on every click. Relative links need nothing. This step is skipped almost universally, and it is the difference between a migration that is finished and one that merely works.
Caches, CDN and feeds. Purge your page cache and CDN, or a cached copy of an http page will keep serving old markup and make a finished migration look broken. Then check the places a database search and replace never reaches: email templates, invoices, product feeds and anything a third-party service stores about your site.
How to know it worked
Four checks, in order.
- Type your http address into a browser and confirm it lands on https rather than loading.
- Do the same for the www and non-www versions of your domain, since a certificate covering only one of them will throw a name mismatch on the other.
- Open a few interior pages, not just the home page, and confirm the padlock holds on each.
- Then run the SSL Checker once more, which catches the chain and expiry problems a browser will hide from you.
Step 6: Tell search engines
- Add the https property in Google Search Console. An http property does not report on https URLs. Add the new one and keep the old, or use a Domain property, which covers both protocols at once.
- Resubmit your sitemap with https URLs. Google notes that submitting a sitemap speeds up discovery during a move.
- Check your canonical tags point at https. Most SEO plugins update automatically once the site URL changes, but confirm it in the page source.
- Update analytics, ad platforms and any third-party service that stores your site URL.
Do not use the Change of Address tool. This one catches out careful people, because filing a change of address is exactly what you would expect to do. Google classifies an http to https switch as a site move with URL changes, so follow Google’s site move guidelines. Those guidelines say in as many words that if you are moving from HTTP to HTTPS, you do not need to use the Change of Address tool. Reserve it for moving to a different domain.
What to expect afterwards
How long the work takes. On a managed host where the certificate is already issued, about fifteen minutes. Issuing a free certificate and configuring the platform, half an hour. A paid certificate adds the validation wait: minutes for Domain Validation, one to three business days for Organization or Extended Validation. Fixing mixed content is the variable part and depends on how much of your content carries hardcoded links.
How long Google takes. Longer than the work does. Google’s guidance on site moves is that a medium-sized site takes a few weeks for most pages to move across in the index, and larger sites take longer. During that period your impressions appear split across the http and https properties, and rankings fluctuate. That is expected behaviour for a site move, not a sign that something broke.
Once https has been stable for a while, consider HSTS, which tells browsers to refuse plain http for your domain outright and closes the gap between the first request and the redirect. Leave the preload directive off at first: it is slow to reverse, and it will make any subdomain still on http unreachable.
If something is still not right, the SSL error guides handle specific browser error codes.
Can you switch back from HTTPS to HTTP?
Technically yes, by removing the redirect and reverting your site URLs. In practice you almost never should. It is a second site move, with a second round of index churn, and the browser warnings come straight back, which after October 2026 means an interstitial for most visitors. If you have enabled HSTS, browsers will refuse http for your domain until the policy expires, so the rollback will not even work cleanly.
The one routine exception is local development, where a self-signed certificate or plain http on a machine nobody else can reach is normal. If a live site is misbehaving on https, the cause is nearly always the certificate, mixed content or a redirect loop, and fixing one of those is far cheaper than reversing the migration.
Frequently Asked Questions
Install an SSL certificate on your server, change your site’s URLs from http to https in your platform’s settings, add a 301 redirect so old http links follow, fix anything still loading over http, then add the https property in Google Search Console and resubmit your sitemap. On most sites the work takes under an hour.
No. HTTPS is HTTP carried over a TLS connection, and that connection cannot be established without a certificate the browser trusts. There is no setting, plugin or redirect that produces https without one. What you can do is get a certificate at no cost: most hosts issue free Let’s Encrypt certificates, and on a server you control, Certbot does it from the command line.
Not by itself. Installing a certificate makes https available; it does not stop http from working. Some platforms redirect once you switch their own setting on, and some hosts add a redirect for you, but you should confirm it rather than assume it. Type your http address into a browser: if it does not land on https, add the server-level rule in step 4.
The work is usually fifteen minutes to an hour, depending on whether the certificate already exists and how much mixed content you have. Getting the certificate itself is instant for Domain Validation and one to three business days for Organization or Extended Validation. Google then needs a few weeks to move most pages across in its index on a medium-sized site, and longer on large ones.
Not permanently, provided every http URL 301 redirects to its https equivalent. Google states that permanent redirects do not lose PageRank. Expect fluctuation for a few weeks while Google recrawls, and expect impressions to appear split across your http and https Search Console properties during that period. Lasting drops almost always trace back to redirects that were missed, not to HTTPS itself.
No, and Google says so explicitly. An http to https switch follows Google’s site move with URL changes guidelines, and those guidelines state that if you are moving from HTTP to HTTPS you do not need to use the Change of Address tool. Reserve that tool for moving to a genuinely different domain.
The protocol is. The certificate can be, through Let’s Encrypt or your host’s free SSL. Paid certificates buy things a free one does not include: a warranty, verified organization details inside the certificate with OV or EV, easier wildcard coverage for subdomains, longer terms with less renewal admin, and support when issuance goes wrong.
Running a specific platform? We have detailed guides for WordPress, Joomla and PrestaShop.
Save 10% on SSL Certificates when ordering from SSL Dragon today!
Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10
