What HTTPS is and why Google cares
HTTPS is HTTP over TLS, the encryption layer that prevents anyone between the browser and the server from reading or tampering with the traffic. The padlock in the address bar means the connection is encrypted and the certificate matches the domain. On HTTP, every request and response travels in plain text: anyone on the same WiFi network, anyone at the ISP, anyone at any router between you and the server can read what is being sent. Passwords, credit card numbers, the actual content of the page. HTTPS fixes that.
Google announced HTTPS as a "lightweight ranking signal" in August 2014, in a Webmaster Central blog post by Zineb Ait Bahajji and Gary Illyes. The framing was deliberately understated. Google wanted to nudge the web toward HTTPS without making the signal a blunt weapon. The lift, they said at the time, was small and affected fewer than 1 percent of global queries. Over the following years Google made noises about increasing the weight, but the signal has stayed small in practice. What changed was browser behaviour: Chrome started marking HTTP pages as Not Secure in 2018, which did far more to push the web toward HTTPS than any ranking signal ever did.
In 2026 the signal still exists, now absorbed into the Page Experience umbrella that also covers Core Web Vitals, mobile usability and intrusive interstitials. The competitive value of being on HTTPS is essentially zero because everyone is on HTTPS. The cost of not being on HTTPS is high: user trust, browser feature loss, and a small ranking penalty. Treat HTTPS the way you treat having a functional DNS record: required, not optional, not interesting.
How the signal works in 2026
Three things are worth being precise about with how Google handles HTTPS today.
The signal applies per URL. Google evaluates HTTPS at the URL level, not the site level. A site with most pages on HTTPS and a single HTTP page can have the HTTP page ranked lower than its HTTPS counterpart would be. Most sites with mixed HTTPS/HTTP coverage have leftover HTTP URLs from incomplete migrations: a /wp-admin/ path on HTTP, an old /blog-archive/ subdirectory on HTTP, a forgotten subdomain. The fix is the same: redirect everything to HTTPS and serve every URL securely.
The type of certificate does not matter. Google has been clear since the original 2014 announcement that any valid certificate counts. A free Let's Encrypt domain-validated certificate produces the same ranking signal as a $400-per-year Extended Validation certificate from a major certificate authority. EV certificates used to display the company name in green in the browser address bar, but Chrome and Firefox removed that indicator in 2019 because users did not pay attention to it. EV certificates are now an expensive way to get the same outcome as a free cert.
HTTP/2 and HTTP/3 are HTTPS-only in practice. Modern protocols deliver substantial performance improvements (multiplexed requests, header compression, faster handshakes) but browsers only negotiate them over TLS. Staying on HTTP also means staying on HTTP/1.1, which forces an unnecessary page speed penalty. On a site with 40 to 60 resources per page, the HTTP/2 multiplexing alone can shave 200 to 400ms off LCP. See LCP optimisation for the wider speed picture.
Practical effect of all three: there is no scenario in 2026 where staying on HTTP makes sense for a production site. The ranking penalty is small but real, the user-trust penalty is large, the feature loss is significant, and the cost to migrate is mostly engineering hours rather than money. The remaining HTTP sites we see in audits are usually legacy WordPress installs that nobody touched between 2014 and now.
Step-by-step HTTPS migration
The migration is straightforward but unforgiving. Skipping or fumbling a step can cost organic traffic for months. Run through these in order and the migration is invisible to rankings.
1. Get the certificate sorted
For most Australian SMB sites, the right answer is a free Let's Encrypt certificate provisioned via the host. Most modern Australian hosts (Cloudflare, SiteGround, Kinsta, WP Engine, Vercel) provision Let's Encrypt automatically with one click. If your host charges $300 per year for an SSL certificate, change hosts; that fee is a rip-off in 2026. For larger sites with strict compliance requirements, a paid certificate from a recognised CA may be needed, but the ranking outcome is identical.
2. Test HTTPS works before you flip the switch
Visit https://yourdomain.com directly in a browser. The site should load with a padlock and no warnings. Check on Chrome, Firefox and Safari. Check on mobile. Check key URLs (homepage, top blog post, top service page, contact page) individually. If anything is broken (mixed content warnings, broken images, broken forms), fix it before going further. The HTTP version stays as the canonical version until HTTPS is genuinely ready.
3. 301-redirect every HTTP URL to its HTTPS equivalent
This is the most important step. Every single HTTP URL on the site needs a 301 redirect to the matching HTTPS URL, preserving the path and query string. On Nginx, Apache or Cloudflare this is one redirect rule. On WordPress with a plugin it is one toggle. Test it by visiting http://yourdomain.com and confirming the URL becomes https://yourdomain.com (and similarly for a deep URL like http://yourdomain.com/services/seo). 301 redirects preserve link equity; 302 redirects do not, so the redirect type matters. See the redirects and HTTP status chapter for the wider redirect-handling picture.
4. Update internal links to HTTPS
Search the entire codebase and database for hardcoded http://yourdomain.com references. Replace them with https://yourdomain.com or, even better, with protocol-relative URLs (//yourdomain.com) or root-relative paths (/services/seo). 301 redirects from HTTP to HTTPS work, but every internal link that has to bounce through a redirect adds latency and wastes crawl budget. Fix the source. WordPress sites can use the Better Search Replace plugin for the database; static sites can use a find-and-replace across the codebase.
5. Update the canonical tags
Every page should have a canonical tag pointing to the HTTPS version. Most CMSes handle this automatically once the site URL is updated in settings, but verify manually on key templates. A wrong canonical (pointing to HTTP, or to a different URL) is one of the highest-impact ways to break an HTTPS migration.
6. Update the sitemap and robots.txt
Regenerate the XML sitemap with HTTPS URLs only. The robots.txt should be served from the HTTPS version and should reference the HTTPS sitemap location. Submit the new sitemap in Google Search Console. See sitemaps for the wider sitemap workflow.
7. Add the HTTPS property in Search Console
Google Search Console treats http://, https://, http://www. and https://www. as four separate properties. Add the HTTPS version (and the HTTPS www version if you use www). Keep the HTTP versions registered so you can monitor the redirect behaviour and any leftover HTTP traffic. The newer Domain property in GSC covers all four protocols at once and is the recommended setup. See Google Search Console for the property-management workflow.
8. Update Google Analytics, Tag Manager, and any third parties
The site URL setting in GA4 needs to be updated to HTTPS. Tag Manager containers do not usually need changes but verify they fire on the HTTPS pages. Update the site URL in any CDN, in any third-party widgets (chat tools, schedulers, embeds), and in any backlink monitoring tools.
9. Configure HSTS
HTTP Strict Transport Security (HSTS) is an HTTP response header that tells browsers "always load this site over HTTPS, even if the user types http:// or follows a stale http link". It locks in the secure version and prevents downgrade attacks. The header is one line of server config:
Strict-Transport-Security: max-age=31536000; includeSubDomains
That means: cache the HTTPS-only rule for a year, and apply it to subdomains. Add HSTS only after you are confident the HTTPS migration is fully working and you do not need to roll back to HTTP. Once a browser has seen the HSTS header, the user cannot accept a certificate warning or fall back to HTTP for the cached duration. It is a one-way door. Worth doing, but commit before you ship.
10. Monitor for two months
Watch the GSC Coverage report, the Performance report, the Core Web Vitals report and the organic search traffic in GA4 for the first 8 weeks. Expect a small dip in indexed URLs as the HTTP versions are de-indexed and the HTTPS versions are indexed (usually 2 to 4 weeks). Expect no meaningful organic traffic change. If traffic dips more than 10 percent, audit the redirects and the canonical tags first; these are the most common failure points.
Common mistakes and how to avoid them
- Free Let's Encrypt certificates from a modern Australian host
- 301 redirects on every HTTP URL to the matching HTTPS URL
- Updated internal links so nothing routes through redirects
- HSTS configured after the migration is verified working
- HTTPS property added in Google Search Console
- Monitoring traffic and indexation for at least eight weeks
- Paying $300 per year for a basic SSL certificate
- Using 302 redirects which do not transfer link equity
- Forgetting subdomains, staging environments, or legacy paths
- Hardcoded http:// references in CSS, JavaScript, or the database
- Mixed content from old image URLs or third-party scripts
- Enabling HSTS before the migration is fully verified
The mixed-content trap. An HTTPS page that loads an HTTP image, stylesheet or script is called mixed content. Browsers block mixed active content (scripts, stylesheets, iframes) outright and downgrade or warn for mixed passive content (images, videos, audio). The page may not render correctly, scripts may not run, and users see a broken padlock icon. Open Chrome DevTools, go to the Console tab, and look for "Mixed Content" warnings. Fix every one by updating the source URL to HTTPS. WordPress sites often inherit mixed content from old database entries pointing to http://yourdomain.com/wp-content/uploads/... images; a database find-and-replace fixes it in one pass.
Forgetting the www variant. http://www.yourdomain.com and http://yourdomain.com are different URLs from Google's perspective. The migration needs to redirect both to one canonical HTTPS version. Most sites choose the non-www HTTPS as canonical and redirect everything else to it; some choose www. Pick one, redirect everything else, set the canonical tags consistently. See canonical tags for the wider canonicalisation picture.
Subdomains left on HTTP. The main site is on HTTPS but blog.yourdomain.com or shop.yourdomain.com is still on HTTP. Each subdomain needs its own certificate (or a wildcard certificate covering all subdomains) and its own redirect rules. Let's Encrypt wildcard certificates are free and cover *.yourdomain.com in one cert.
Tools and certificate options
Free tooling that covers the full HTTPS workflow:
- Let's Encrypt. Free domain-validated certificates that auto-renew every 90 days. Built into nearly every modern Australian host.
- Cloudflare. Free TLS termination, free certificate, free HTTP/2 and HTTP/3, free HSTS configuration. The fastest way to add HTTPS to a legacy site is to put Cloudflare in front of it.
- SSL Labs Server Test (ssllabs.com/ssltest). Free. Audits your TLS configuration and grades it A through F. Useful for catching weak ciphers, missing HSTS, certificate-chain issues. Aim for A or A+.
- Why No Padlock (whynopadlock.com). Free. Scans a URL for mixed content and reports every offending resource. The fastest way to find leftover HTTP references.
- Google Search Console. Free. The Coverage report shows HTTP versus HTTPS URLs in the index. The URL Inspection tool confirms what Google sees for any single URL. See Google Search Console.
- Lighthouse Best Practices audit. Free. Checks HTTPS is configured, no mixed content, no deprecated APIs. See Lighthouse explained.
- Screaming Frog SEO Spider. Free up to 500 URLs, paid above. Crawls the site and reports every HTTP URL still being linked internally. Worth running post-migration to catch leftovers.
For paid certificates, the use cases are narrow in 2026: regulated industries with compliance requirements, e-commerce sites that want explicit assurance from a recognised CA, sites where stakeholders specifically requested it for non-technical reasons. Otherwise, free is fine and the ranking outcome is identical.
Perth and WA context
Three HTTPS patterns we see across Perth and WA businesses.
Legacy WordPress sites on shared hosting. Perth small businesses with WordPress sites built in 2013 to 2017 on cheap shared hosting often did not get HTTPS turned on. The host charged extra for it, the site owner did not understand the value, and the certificate never got provisioned. In 2026, every Perth host worth using includes free Let's Encrypt. If your host still charges for SSL, switch hosts. We frequently make this migration the first move on website audits for legacy sites because it unlocks the HTTP/2 speed wins and removes the Not Secure browser warning at the same time.
Trades and service-area businesses with subdomains they forgot about. A Perth plumbing or electrical business has the main site at example.com.au on HTTPS but a forgotten blog at blog.example.com.au on HTTP, or a quote-form widget hosted on a subdomain that still serves HTTP. Cross-domain mixed content warnings, broken padlock icons, and a small ongoing ranking penalty on the subdomain. The fix is one wildcard certificate and matching redirect rules. Trades SEO sites are particularly prone because the original web designer often set up multiple subdomains and never returned to maintain them.
E-commerce sites on HTTPS but with mixed content from old product photos. A Perth e-commerce site we audited last year had migrated to HTTPS in 2018 but had 4,000 product images still served from http://cdn.example.com.au/... URLs in the product database. Chrome auto-upgraded the requests where it could but blocked the ones it could not, leading to broken images on roughly 12 percent of product pages. The fix was a database find-and-replace and an updated CDN configuration. E-commerce SEO sites have this problem most often because product databases tend to outlive migrations.
Related guides
For the wider Page Experience picture: the Core Web Vitals pillar, Core Web Vitals explained, LCP optimisation, INP explained, CLS fixes, mobile usability, intrusive interstitials and Lighthouse explained.
For the technical-SEO depth: the technical HTTPS implementation guide, redirects and HTTP status codes, canonical tags, sitemaps, and the Technical SEO pillar. For measurement: Google Search Console and GA4 for SEO.
For services, the speed optimisation service includes HTTPS migration when needed. The website audits service flags HTTP and mixed-content issues on every audit. The SEO service handles the migration as part of broader technical work. New sites should start with the free SEO audit. For geography see Perth services, Fremantle and Local SEO Perth. For industry context, e-commerce, trades and healthcare sites all face HTTPS edge cases unique to their data and integrations.