HTTPS Encryption is the first step in the broader practice of URL Structure Optimisation, followed by Canonical Domain set-up and URL Taxonomy Optimisation.
Table of Contents
Every URL on a website begins with a protocol, either HTTP or HTTPS for web pages. Unlike HTTP, HTTPS (Hypertext Transfer Protocol Secure) uses an SSL (Secure Sockets Layer) certificate to encrypt the data exchanged between a user’s browser and the web server. This ensures that sensitive information remains accessible only to the website owner and the visitor, protected from interception by third parties.
Why is HTTPS Encryption Important for SEO?
Google confirmed HTTPS as a ranking signal in 2014. Put simply, all things being equal between two competing pages, the one served over HTTPS will be favoured in organic search results. The absence of HTTPS, on the other hand, can undermine the effectiveness of the other SEO efforts towards uplifting the website in organic search results.
Browsers display a lock icon in the address bar for HTTPS websites, signalling to users that their connection is secure. In the absence of HTTPS encryption, modern browsers display a “Not Secure” warning on HTTP pages, eroding user trust before a visitor has has a chance to interact with the page. This directly reflects in lower engagement rates on the website, a signal search engines employ to rank organic search results.
HTTP connections are vulnerable to third-party injection, most commonly employed by free public Wi-Fi networks that insert their own advertising into unencrypted pages. This means users on your website may see ads you did not place on your website, damaging the user experience.
Without HTTPS encryption, data transmitted between a user’s browser and your web server travels in plain text, making it readable to anyone positioned between the two endpoints. This is a class of vulnerability known as a man-in-the-middle attack, where a malicious actor can intercept, read, modify, and inject content into the communication without either party’s awareness. For website visitors, this can mean stolen form inputs, session hijacking, or credential theft. For the website owner, it means loss of user trust and potential liability. HTTPS eliminates this attack surface by encrypting the entire data exchange end to end.
HTTPS has a direct impact on the accuracy of traffic data in analytics. When a user navigates from an HTTPS page to an HTTP page, the referrer information is stripped by the browser, and that visit is recorded as direct traffic rather than attributed to its actual source. Running HTTP means consistently underreporting referral and organic traffic, which distorts both reporting and decision-making.
In the context of SEO, optimising for HTTPS also includes ensuring the entire website runs on HTTPS and that no HTTP version of any URL on the website remains accessible, preemptively addressing Mixed Content and Duplicate Content issues, commonly caused by incomplete or incorrect setups.
- Mixed Content: Mixed content occurs when an SSL certificate is installed but individual page resources, like images, scripts, or stylesheets continue to load over HTTP. This partially undermines encryption, triggering “Not Secure” browser warnings on otherwise HTTPS pages. In other words, this means the page is not considered as fully secure by browsers and search engines.
- Content Duplication: When both HTTP and HTTPS versions of a URL are simultaneously accessible without a redirect enforced between them, search engines treat both pages (HTTP and HTTPS) as duplicates. Duplicate content leads to split authority and ranking signals between the two versions of the same URL.
In the context of SEO and as part of Domain Actuation in particular which itself is a part of broader URL Structure Optimisation, HTTPS encryption is a must-do because the encryption is done once for the entire website, but is reflected across every single URL and its ability to rank in organic search. Not only is HTTPS Encryption important, but so is its error-free implementation, accounting for:
- HTTPS Encryption Process
- Normalising HTTPS URLs across Platforms
- Testing the HTTPS Encryption
- Applying HTTPS Encryption Best Practice
- Diagnosing HTTPS Encryption Issues
HTTPS Encryption Process
How you obtain and install an SSL certificate will depend on whether you are setting up a new WordPress website or migrating an existing HTTP site to HTTPS.
- New WordPress websites: Most reputable hosting providers include a free SSL certificate as part of their hosting package, installed automatically at the point of WordPress installation. If you are hosting with Hostinger, this is the case by default and no additional action is required at this stage.
- Existing WordPress HTTP websites: If your site is already live but running on HTTP, you will need to obtain an SSL certificate through your hosting provider. Most providers offer free SSL certificates. Log into your hosting account, locate the SSL section within your hosting dashboard and follow the installation process provided.
Normalising HTTPS URLs across Platforms
Once you’ve deployed HTTPS Encryption you must specify your new website address in WordPress and any tools that have been historically using HTTP. Failure to do so will prevent these platforms from working as expected.
To specify your new website address with HTTPS instead of HTTP in WordPress log into your WordPress Admin > Settings > General and make sure the WordPress Address and Site Address fields use HTTPS.
If you’re using Google Search Console and more specifically your Google Search Console property is using a URL prefix property (not a domain property), you’ll have to verify your Google Search Console from scratch as a new property.
Once you successfully migrate to “HTTPS”, you won’t continue to receive data for the old “HTTP” property in Google Search Console. To verify a new property in Google Search Console, log into your account and expand the menu listing your website, then find and click “add property”. You will get the choice of using a “domain property” or “URL prefix property”, along with a “Learn more” button explaining the key differences between the two, as illustrated below. Once you’ve decided on one of the two options, you will need to upload a code snippet on your website to verify it. The data will start to become visible in no longer than a few days.
If you’re using GA4, log into your GA4 account and select the property in question, then click “Admin”. Find the “Data collection and modification” panel and click on “Data Streams”. Your Data Stream will list the domain that is being tracked with the corresponding HTTP or HTTPS in front of it. If needed, replace HTTP with HTTPS by clicking on the stream and then the pencil icon, as illustrated below.
Testing the HTTPS Encryption
For a quick check of your HTTPS Encryption, type your domain name into the web browser and check the protocol.
- If it’s HTTPS, then your website has HTTPS Encryption enabled. Most websites have it by default.
- If your website is only available under the HTTP version, you don’t have HTTPS encryption
- In the rare event your website is avaiable under both HTTP and HTTPS versions simoultaneously, you do have the HTTPS encryption enabled but it is not implemented according to best practice.
Testing HTTPS Encryption Implementation
While you can just type your domain name into the web browser and check the protocol to see if you have HTTPS Encryption enabled, you will need a stricter process to test if its’ implementation is error-free.
- Visit SSL.org and type your domain name in the SSL Checker input field.
- Click “Check SSL“
- Scroll Down for the SSL Checker Summary
Go through the SSL Checker Summary list, scanning for anything obvious not passing the test.
If you’re using Hostinger, you’ll likely find no issues, with the exception of HSTS Support, which is an optional, supplimentary web security policy mechanism that forces browsers to interact with the website exclusively over secure HTTPS connection and never over HTTP.
To enable HSTS Support for your HTTPS Encryption certain HTTPS Encryption Best Practices must be applied and tested first. If any parts of your website still rely on HTTP when implementing HSTS Support for HTTPS Encryption, after deploying HSTS, those HTTP parts will cease to work.
It’s also worth noting the following HTTPS Encryption Best Practices are useful to follow even in the absence of HSTS Support. Applying these best practices will ensure your HTTPS Encryption will optimally translate into positive organic ranking signals, as interpreted by search engines.
Additionally the following best practice disambiguates how the website must behave in certain scenarios, pre-emptively addressing HTTPS-related errors before they get a chance to affect your organic ranking signals.
Applying HTTPS Encryption Best Practice
1. The domain and any active subdomains open with no certificate warning
To ensure the domain loads with no certificate warning, type the domain and separately, any active subdomains into the browser. Below is example of a domain with certificate warning, meaning it is not encrypted and thus not ready for HSTS Support set-up.
2. The redirects from the HTTP to the HTTPS counterparts are set-up correctly
If you’re using Hostinger, enabling domain-wide redirects from HTTP to HTTPS URLs can be achieved through the Hostinger’s Force HTTPS toggle, within the “Dashboard” > “WordPress” view for the website in question.
Forcing HTTPS pre-emptively addresses possible Duplicate Content issues caused by landing pages that may be available using both the HTTP and HTTPS URLs.
Diagnosing Duplicate Content Issues caused by HTTPS
To test if all website URLs are available exclusively over HTTPS, you will need to carry out a crawl using Sitebulb. Start a new Project, specify a Project Name and Start URL, then Save and Continue.
For this particular check you will only need to only enable the Search Engine Optimisation toggle.
Having Search Engine Optimisation enabled will instructuct the crawler to crawl all the website pages when performing the crawl. Depending on whether any pages are served over both HTTP and HTTPS, you will determine if the website has Duplicate Content issues.
- To check if there are any pages served over HTTP, from the Audit Overview window select URL Reports > URLs > Internal.
- In the Internal Report, find the Security section and hover over it to reveal if the Sitebulb crawler has identified issues with the encryption of pages.
If your website has any pages loaded over HTTP instead of HTTPS, they’ll show up under the HTTP URLs report.
3. The website loads all assets over HTTPS (images, scripts, CSS)
As a general rule if all of your website assets use relative URIs for resources and not absolute URIs which hardcodes the HTTP protocol into the URLs, then your website is likely to not have any Mixed Content issues. In case you’re unsure if your website uses relative URIs for resources, you can carry out some simple checks as explained below in the Diagnosing section.
Diagnosing Mixed Content Issues caused by HTTPS
To test if all website resources are available exclusively over HTTPS, you will need to carry out a crawl using Sitebulb with slightly different Audit Settings. Start a new Project, specify a Project Name and Start URL, then Save and Continue.
For this particular check you will also need to enable enable the Page Resources toggle.
Having Page Resources enabled will instructuct the crawler to consider all the website resources when performing the crawl (stylesheets, scripts, images). Depending on whether some resources are served over HTTP instead of HTTPS, you will determine if the website has Mixed Content issues.
- To check if there are any resources served over HTTP, from the Audit Overview window select URL Reports > URLs > Resources.
- In the Resources window, find the Security section and hover over it to reveal if the Sitebulb crawler has identified any issues with the encryption of resources.
If your website has any resources loaded over HTTP instead of HTTPS, they’ll show up under the Loads Mixed Content report.
In the absence of a certificate warning in the web browser, any Duplicate Content issues caused by HTTP and HTTPS versions of the same URL (fixed through the Force HTTPS toggle in Hostinger or other methods), any Mixed Content issues casued by landing pages loading resources over HTTP (diagnosed using Sitebulb), the website can be considered ready for deploying HSTS Support as part of HTTPS Encryption.
Implementing HSTS Support for HTTPS Encryption
Once again, HSTS Support is an optional web security policy mechanism, supplimentary to the default HTTPS Encryption implementation, it forces browsers to interact with websites exclusively over secure HTTPS connections and never over HTTP.
Although implementing HSTS Support for HTTPS Encryption involves the use of code, the RankMath SEO Plugin simplifies the process.
- Ensure you’re using the Advanced Mode in Rankmath SEO Plugin by navigating to Rankmath SEO > Dashboard and selecting Advanced Mode.
- Navigate to Rankmath SEO > General Settings > Edit .htaccess. You may need to read the disclaimer, and confirm you accept the risks using the checkbox.
- Copy the following code snippet onto the last line of the .htaccess file and Save Changes.
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"- Allow anywhere between 30 minutes to 24 hours before testing the successfull implementation of HSTS Support for HTTPS Encryption on SSL.org.
