Table of Contents
HTTPS Encryption
Every URL on a website begins with a protocol, either HTTP or HTTPS. 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.
Checking the HTTPS Encryption
To check if you have 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, most likely you don’t have HTTPS encryption
- If your website is avaiable under both HTTP and HTTPS versions simoultaneously, your HTTPS encryption may be directly causing Duplicate Content issues across your website.
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 sets of URLs.
In the context of SEO and URL Structure Optimisation in particular, HTTPS encryption is a must-do because the encryption is done once for the entire website, but is reflected across every single URL and their ability to rank in organic search. Not only is HTTPS Encryption important, but so is its error-free implementation, accounting for:
- Testing HTTPS Encryption Implementation
- Diagnosing HTTPS Encryption Issues
- Applying HTTPS Encryption 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 a supplimentary web security policy mechanism that forces browsers to interact with websites exclusively over secure HTTPS connections and never over HTTP.
HSTS is optional in HTTPS Encryption and a stricter security alternative to Hostinger’s Force HTTPS toggle. However, only enable HSTS when SSL certificate works perfectly on the domain (and any subdomains), namely when:
- the domain opens with no certificate warning
- HTTPS also works for any active subdomains
- the website doesn’t load any assets over HTTP (images, scripts, CSS)
- the redirects from the HTTP to HTTPS are set-up correctly
The Importance of HTTPS Encryption
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.
How to Implement HTTPS Encryption in WordPress
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 via Let’s Encrypt. Log into your hosting account, locate the SSL section within your hosting dashboard and follow the installation process provided. If your host does not offer a free SSL option, a paid certificate can be obtained through providers such as DigiCert or Sectigo and installed via your hosting control panel.
Once installation is complete, verify that the certificate is correctly configured before proceeding. The most thorough method is to run your domain through the SSL Installation Checker, which will confirm the certificate is valid, correctly chained, and covering the right domain. As a final check, type your domain into a browser using the https:// prefix and confirm the lock icon appears in the address bar.
After Installing the SSL certificate, ensure that all your website visitors are redirected to the HTTPS version of your website instead of the previously-available HTTP version. To do this, log into your Hostinger account, find the “Websites” panel and click on the “Dashboard” next to the website in question. Then in WordPress > Overview find the Force HTTPS toggle and ensure it’s activated, just as illustrated below.
Next, you will need to ensure your website address uses HTTPS instead of HTTP by logging into your WordPress Admin, navigating to Settings > General and making sure the “WordPress Address” and “Site Address” fields use HTTPS, just like illustrated below.
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 proper 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.
Setting the Preferred (Canonical) Domain
The preferred domain (canonical domain) specifies the version of the preferred domain (www or non-www) that precedes the domain name. To be technically accurate the www version of a website actually means the website will be placed on the www subdomain. Although there is no set preference by search engines for either one of these options, only one single version must be used across all the URLs on the website for consistency purposes.
If you use both domain versions on and outside your website, search engines will treat the two versions of the same page as references to separate pages, resulting in duplication issues on a large scale. When you set your preferred domain, you’re telling search engines which domain you want to be crawled and indexed. Although search engines do not give preference to any one version over the other, one argument for using the non-www version is that it makes for a shorter URL, allowing more space for what may, in fact, be important.
To set your preferred domain, you will need to login into your WordPress Dashboard and navigate to “Settings” > “General”, where you’ll need to ensure you have the preferred version of the domain specified, as illustrated below.
If it just so happens that you can’t access your WordPress website after doing this, you must change the settings in your database. You may reach out to your hosting provider’s customer support, explain that you’ve changed the preferred domain (a.k.a. canonical domain) in WordPress and kindly ask them to fix it for you. If you prefer fixing it yourself and you’re using Hostinger, just follow the steps below:
- Log into your Hostinger account
- On the left sidemenu find “Websites” > “Website list”, then click on “Dashboard” next to the website in question.
- On the left sidemenu find “Databases” > “phpMyAdmin” and click “Enter phpMyAdmin” next to your database.
- Once in the phpMyAdmin, find the “wp_options” subfolder (you may also use the search function) and select it.
- Depending on how many websites you host, you may have a multiple “MySQL Databases”. If so, you’ll need to check them one by one to find the one you need and you can do so by following the next step.
- With the “wp_options” selected you will find a table with a list of options, the first 2 of which will be “siteurl” and “home”.
- If both of these text fields specify your domain URL (as illustrated below), you’re in the right place.
- To amend your preferred domain (canonical domain), click “edit” and remove the “www” for the setting your preferred domain to the “non-www” version and vice versa.
- This applies to both “site url” and “home” options.
Make sure to redirect the www version of the domain to the non-www to prevent duplication issues. Failing to do so will result in duplicate content issues as well as issues surrounding the consolidation of your backlink profile across the entire website.
Domain-wide redirects from www to non-www versions of the page or vice versa can be done in the .htaccess file, but you will need a developer to implement that for you. Forcing the “https” across the website (in case you’re not able to do it through Hostinger) can be done in a similar fashion using the same file.