Website Silk have lots of experience in migrating websites from HTTP to HTTPS and offer an affordable move to HTTPS while minimising the ranking impact.


Blog Post written by Ronel Pieterse

Ronel has 24 years corporate experience at senior levels (finance, mining, IT, manufacturing & agriculture), a B.Com degree (Business Management & IT) and postgrad Business Management (Henley). She has also started 5 small businesses over the past 20 years, 4 of which are still operational today due to her expertise in Digital Marketing. Ronel helps entrepreneurs to grow their businesses via a sustainable competitive advantage in the Digital Arena.

POST DATE: 2019-04-07

POST UPDATED: 2020-04-26


With the current hype about the HTTPS protocol - which essentially means offering a website on the internet to web users via a secure transfer protocol - it is difficult to know what is really required, what the benefits of HTTPS are, what the impact of switching to HTTPS may be and what steps are involved in migrating from HTTP to HTTPS.

Many people switch to gain some website ranking points yet unintentionally harm their Google ranking in the process. I'll explain why.

This blog post on HTTPS will endeavour to cover everything you need to know about HTTPS, including why this is NOT just something your hosting company quickly "switches on".

With this article I aim to inform website owners on what the process involves and who they should expect what from. I'd also like to help other website developers understand what they can do to avoid Google confusion that can lead to indexing problems and lost page rank in some cases.

I use Google, Apache Servers and simple structure domains in the screen shots and examples, as they are most generally used by small business owners, though the principles apply to all search engines and domain & server configurations.

Please don't fear this migration to HTTPS; it's not a difficult (or expensive) process. The move from HTTP to HTTPS has implications that need to be understood to avoid negative impact and the migration steps need to be thought through to avoid the pitfalls of moving to HTTPS.

Let's start.


HTTPS is short for Hyper Text Transfer Protocol with the S indicating that it is Secure. The benefit of secure web data transfer to web users is that when they fill in forms on your website, their private information is secured so that cyber-snoopers can't pinch it while it is being transferred between their browser and your server.

An important distinction to make is that HTTPS doesn't "make your website secure" - although this is how many people talk about making the switch to HTTPS. HTTPS only protects information while it is in transit between the web user's browser and the web server where the website is hosted, called encryption-in-transit. It stops cyber attacks performed by what is known as a "Man In The Middle" (MITM) that attempts to access information in the process of being transferred. Encrypting information-in-transit with HTTPS is also not infallible, though that is a technically challenging topic for another day (and perhaps another author - haha!)

"Securing your website" is a much broader and more complex subject since HTTPS does not cover encryption-at-rest! Cyber attackers can still hack your website, or the web server where your website is hosted. They can exploit software vulnerabilities or use brute forcing of your access controls, for example. Think of it like this: a cash-in-transit truck is responsible for the security of money while in transit, but not for a crook robbing the bank itself.

HTTPS does NOT make your website secure.  Encryption-at-Rest technologies are need to stop brute force attacks or hacking into your website.

HTTPS is clearly required in cases where:

  • Online payments or transfers are being made (e.g. banking, e-commerce applications)
  • Transactions are in progress (e.g. sale of shares, bidding processes)
  • Where secrets or security is paramount (e.g. secret voting system, or a distribution map of rhinos)
  • Information that can identify a person, or where related sensitive information is transferred (remember the Dating Site scandal?)

But how necessary is it for an informational brochure website where the web user might impart with only basic personal information like an e-mail address?


Google & HTTPS

Whereas Google is crystal clear about website speed becoming an increasingly important ranking factor, it used to only gently hint at HTTPS being rewarded with a small ranking boost. For SEO experts working with this every day, evidence to support this was rather contradictory, so the jury was hung about how HTTPS versus HTTP impacts website ranking by search engines. The data may have been skewed by the incorrect implementation of HTTPS as any small SEO gains might have been counterbalanced by not carrying the change through to all affected facets - negatively impacting ranking due to conflicting signals to Google.

Google has been sending increasingly clear messages about secure transfer protocol being preferred though1. For a while now, Chrome has been displaying a visible "Site Insecure" message to highlight this and Firefox offers a similar informational message albeit not as visibly. I interpret signals such as these that the migration to HTTPS is becoming a must-do if you want to stay ahead of the curve; it's a matter of time before HTTPS as a Google ranking factor increases in importance.

More than 73% of internet traffic is already protected by secure transfer protocol according to a threat report released in Jan 20192.

Website Users & HTTPS

More website owners and web users are becoming aware of some websites showing a lock, others showing an open lock, a lock with a warning, or an informational message about the site not being secure. If user awareness starts driving requests for websites to be moved to the HTTPS protocol on their web servers, it's best to not let your website users worry about the safety of your website, even if the risk to them is relatively low.

You want your website users to feel safe in sending their information across your HTTPS data transfer protocol.

Website Owners & HTTPS

If there is any chance that your users' personal information, or the nature of their queries may be leaked by cyber-hackers, wouldn't you want to rest easy that you are doing what you can to prevent a reputational scandal for your business?

Given such advantages, even IF they are small for non-payment websites, why ARE some websites still on HTTP? I think it's due to a combination of a lack of awareness, fear of the unknown as well as a legacy issue.

Much of the custom website development that we do is to replace a broken legacy website for a client, when the platform has become unstable or unsupported, or the original web developer went AWOL (why is that so common??). At such a time there is often extreme time pressure to get something up and running speedily, in other cases the client feared all the documentation and even signage they may need to update to keep everything in sync. So websites still on HTTP may often have inherited that legacy status and it takes trust and building awareness to lead a client towards making the switch to HTTPS.


There may be a temporary impact on your website traffic1 as Google treats the change as a "site move" and pages will need to be re-crawled, re-indexed and page rank transferred. Until this process is complete, you may see a dip in your website traffic.

This means the timing of an HTTP to HTTPS migration should not coincide with a big brand awareness campaign, or when something juicy is happening in your immediate area or industry. If you work with professional web development experts, this impact can also be minimized by good webmaster site hygiene protocols.


Grrrr. A little Googling today informed me that some web dev companies offer a "special" of R3500 for a once-off conversion from HTTP to HTTPS. Generally these HTTPS conversion offers range from about R4000 - R6000 and promises to do "all the complex redirecting required".

This is exploitation of website users who lack knowledge. I get the same volcanic feeling that I got in 1999 when consultants were creaming it with Y2K and performance bonuses went to the loudest managers with the scariest slide-shows, instead of the studious programmers who knew exactly what needed to get done and who could have just done it in 10% of the time it took to have all those soul-destroying meetings about it.

Even the lower end of these quotes on moving to HTTPS is ludicrous in my opinion, especially for what they palm off as an expert service. Please read on to understand for yourself what is involved so as to not be taken for a ride by these unscrupulous operators!

I DO believe that you need to have the work outlined below done by a website expert (or your website developer, given the HTTP 2 HTTPS Cheatsheet for developers and this article), but since it shouldn't take more than a couple focused hours to implement and test, I'm on the wrong planet if the average web developer earns R2000 an hour! Put differently, if your web developer has gone AWOL, we can do it for you, properly and affordably.

Moving from HTTP to HTTPS can be done at a very affordable cost.  Not having it done by a website developer clued up on the move to HTTPS can cost you a lot more!


It starts with you: It might be worth checking whether there isn't already an SSL Certificate for the domain in question. Sometimes web hosting companies try to be proactive and they arrange it without asking you or informing you (yip, this has happened to people I know who found out with a shock that their website hasn't been displaying correctly for a while already!).

TIP: You can use this link to check if a server hostname has an SSL Certificate:

Web Hosting Company's Role in HTTPS

The hosting company where your website is hosted on a web server (i.e. where it lives), needs to be contacted to inform them of the decision to move from HTTP to HTTPS. There are different security certificates (called SLL Certificates) available and your webhosts can advise you re options, costs and perhaps some guidance based on the nature of your website. SSL Certificates can be self-signed or issued by an SSL Digital Certificate Authority that vets the domain and its ownership. You then decide: there is no need to grab the most expensive security certification option - just make sure it is appropriate for your website. Many website hosting companies will offer an "entry level" free certificate to users on shared hosting which may be good enough for informational brochure sites.

The hosting company will then install the certificate on your domain and so enable HTTPS. They should inform you once this is done. Some hosting companies also add the permanent redirect instruction on your server so that your automatically serves as and then they proudly tell you nothing else needs to be done...

This is NOT true!

Web Developer's Role in HTTPS

Ideally you've involved your website developer from the word go, or they may have even contacted you to suggest the migration to HTTPS. Either way, it's best that they know in advance so that they can plan to spend an hour or two on your website. If you didn't, it is important that you immediately inform your website developer of HTTPS having been enabled on your domain, as some pages may NOT show correctly, or may suffer from mixed content (where both HTTP and HTTPS resources are called on to render a web page). In short, in moving from HTTP to HTTPS, some website work is required.

The correct redirection directive on your server will serve the HTTPS version of your website even if the user typed in the HTTP version of the URL. This relies on the redirect being executed, though, which not only means extra work (thus extra time, however little) to load a page but could also result in "chained redirects" which Google warns against. Imagine A redirecting to B which redirects to C etc - you get the picture.

The website developer should first check how the pages load to ascertain if any display incorrectly, thereby determining the priority of the work. For example, in the case of "mixed content" and incorrect URL's in the css, a page may render incorrectly or incompletely. Or it may render well but display a message about having mixed content or being partially insecure. A good website developer will tackle these issues first so as to not impact on the website's audience.

Next the website developer will check the website AND the Old Google Webmaster Search Console (while still available) to be absolutely certain whether the www or non-www version of the website is preferred. This is an article all by itself but the short version is that both and will show the website correctly, though Google sees these as different versions of the website and this can affect indexing. There is no real indication that one form is better than another so this remains a matter of personal preference. However, it is very important to consistently apply whichever format you choose!

Your website developer should be doing some work on your website when you move to HTTPS and not just rely on the re-direct instruction.

Next, all the internal links on your website should be changed to show the correct version of the website directly. It is better to refer to your home page as (or the www version if you prefer) rather than as index.html for indexing clarity anyway, so this is the ideal time to get two birds with one stone.

This is especially important if your website uses CANONICAL meta-tags in the Header as I have personally seen Google index part of a website against the HTTP version and another part against the HTTPS version (diluting overall website strength and issuing a Google warning) because of conflicting instructions coming from the CANONICAL tag, site-maps and other such signals.

The website developer should check css, js and such files too as they often point to resources on HTTP which will result in mixed resources impacting the security (see above point regarding the first step a good developer will take). Where the web developer looks after other websites that link through to your site, they can also alter the link on those sites to link to the correct URL first time.

Next a good website developer will review any instructions added to the .htaccess file by the hosting company as they are often in conflict with other goals of the website, e.g. whether the website owner prefers the website to be shown with or without the "www". The code should be altered to ensure that ALL versions of the website should redirect to the correct (www/non-www as preferred) and HTTPS version of the website.

Another reason to revisit the .htaccess file is that it may already contain permanent redirects from older page name changes or amalgamations and as stated before, it's best to redirect only once wherever possible and not create "chains" of redirects, so the redirect target URLs should also be altered to contain the correct HTTPS version of the URL.

TIP: mess with your .htaccess file at your own risk.
It's one of the quickest ways to break a website.
Your website developer should be checking and updating your website's .htaccess file to correctly redirect ALL versions of the website to the preferred HTTPS version and www/non-www version of your website URL.

The .htaccess file is working when all 4 versions of the website automatically redirect to the version you prefer when you test it in browsers, e.g. & & & should all redirect to (in my website's case, where I prefer the non-www version).

But we're not done yet.

If your website developer is half-decent, they would have previously submitted a sitemap.xml file to Google to encourage indexing. This sitemap.xml file should also be updated with the correct HTTPS form of the URLs. And STILL, we're not done.

In the New Google Webmaster Search Console, the website developer will now add the additional versions of the website until all 4 versions as previously outlined, are on there. It's not just me saying so either3.

It is important that the website developer should REMOVE the old sitemap that would have previously been submitted against an HTTP version of the website, and then add the NEW sitemap.xml against the preferred HTTPS version of the website.

It fairly simple to load all versions of your website URL to Google's Search Console.  It will require a verification step and that is also pretty straightforward.

For good measure, I also do a URL inspection of the correct form of the home page URL and then submit that URL for indexing too.

TIP: Google may return a not-found message when you first do this. Don't worry, this is because Google sees the new form of your website as a different index, and since it hasn't crawled and indexed your "new" pages yet, they are not yet in this separate index. Click on the button that checks for a "live version" and once that's found, submit it for indexing.

In short, we ideally do whatever we can to avoid redirects and to help Google have absolute clarity about which version of a website to index, before we nudge Google to please re-index what it essentially sees as a new website. The biggest pitfall in moving to HTTPS is confusing Google with conflicting instructions coming from the sitemap, links, canonical directives and preferred website version (if set on old Search Console).

Then we wait and watch. I like to check back 2 days, 4 days, a week, 3 weeks later etc to check for any site errors picked up by Google and to see how many pages in the sitemap.xml had been indexed.

In the meantime, your web developer or PPC / Adwords Specialist (because you ARE clever enough to not wing this one yourself...) should be updating the URL's of your Bing and Google Ads Landing Pages, Sitelinks etc, and related as well as any Facebook Marketing Landing Pages. While not currently strictly necessary, it will eventually be4, so I suggest this is done earlier rather than later to have less impact. If you want to keep stats, don't change the Ads, duplicate them and use the correct link in the new Ads, then pause the old Ads.

The above work should take about 1-2 hours on most small business websites but depends on the size and complexity of the website of course.

Trust me, it's well worth paying a website expert the price of a dinner-for-2 to do all of this for you - if you had to figure it out for yourself (and some people try) it may take you several very frustrating days while your website continues to load erratically and you may lose page rank as Google is becoming increasingly confused in the process.

Old version/s of sitemap.xml must be removed from the HTTP version of the website it was previously loaded against.

Website Owner's Role in HTTPS

A good web developer will provide a website owner with a list to prompt other changes to be made in the business. While none of this is time-critical, it's best to avoid redirects, so a website owner may decide to tackle this all at once, or to roll it out over time as and when they are working on each element needing to change. In small businesses it may be possible to make all changes in a day.

Either way, having changed to HTPPS, it is a good opportunity for some PR to let your audience know that you've pro-actively moved to a more secure internet transfer protocol.

The obvious points that should be changed straight away, are links in any social media accounts and in the personal Facebook pages of employees. E-mail signatures should also be updated. You may have e-courses or e-mail journeys that you'd need to re-visit. On Facebook, I may change the links of any website-linked posts going back about 2-3 weeks as they are most likely to be clicked on in the near future. I don't worry about older posts.

Personally I believe it is important for the link to also show correctly on letterheads, PDF download documents, business cards, signage etc for one key reason: Getting back-links to your website is a key SEO goal and if clients, suppliers or friends are going to back-link to your website (with or without informing you), you want them to use the correct HTTPS form of your website.

I've found that the key to rolling out these changes successfully is to keep someone responsible for monitoring all media and communications for 6-12 months until the changes have rolled out everywhere. In small businesses, this may be YOU, the entrepreneur.

Many people do none of the above because of the redirects being in place... but I believe that absolute consistency in any branding message is critical for brand building, and this includes the consistent use of one's website home page URL.

Now we're done : )

I've seen firsthand how Google can index pages in unexpected ways when the above list is not followed. Why risk the page rank of any of your pages?

Wishing you, and your clients, secure browsing!

Need a good website developer? We can help! We'd also love a safer, and cleaner, internet.

Vote for a cleaner, safer Internet by moving to HTTPS today.


0. In case you missed it: HTTP 2 HTTPS Cheatsheet for developers

1. Google Support

2. Ethereal Mind

3. Search EngineLand

4. Advertiser Community


2019-04-11 Jurie: Great detail, thanks for sharing. Changing from http to https is ridiculously more cumbersome than it should be and I'm surprised Google hasn't figured it out on its own without us having to tell it so. At least the Search Console's new "domain" setup is better, see

Ronel: I agree 100% Jurie. Hopefully the cheat sheet provided above can help users navigate this quickly. The below snippet from the link you shared confirms that Google does not see different versions as a match - I also find it odd and keep wondering why such matching isn't automated. What good reason could Google have that we are missing?

Use whatever form of your URL that you choose, absolutely consistently.


We love to hear your thoughts! Please comment below; once vetted, we'll post your comment here (usually within a day at most).




Powered by Tectite FormMail.


Be notified of our new articles (only 2-3 a year, since they are in-depth), by subscribing to our Newsletter
Receive Website Silk's Newsletter