Visitors To This Post

Search This Blog

Showing posts with label google. Show all posts
Showing posts with label google. Show all posts

Wednesday, March 27, 2019

AdSense and SSL

Ad code SSL Review implementation



Does SSL negatively affect Adsense revenue?

Recently, I discovered that bloggers saw a significant hit to their Adsense revenue after switching over to SSL. This is because Adsense requires that SSL web sites also support SSL-compliant ads. Google maintains that most ads are compliant, but users across the Internet have reported widespread reductions to Adsense revenue.

Financial Samurai reported on this issue earlier in January: “I spoke to the folks at Adthrive, and they said they’ve seen publishers experience a 30% to 90% decline in ad revenue.” Ouch.

This used to be an issue in the past. I have no hard data that indicates one way or another whether this problem continues to exist.

My personal beef with the SSL rankings signal

I vehemently oppose using SSL as a rankings signal, for several key reasons:
  1. It seems arbitrary. To reward or penalize a web site based on unrelated qualifiers to the search query and content quality seems wrong.
  2. I reject the notion that SSL makes web sites safer. Like I mentioned in this blog post, SSL only encrypts data in transmission from Point A to Point B, which is a relatively tiny element of overall web site security. Developing secure web sites is a blindingly complex and sophisticated subject and cannot possibly be solved by slapping a certificate on to a web site. If only it were that easy.
  3. It makes bloggers spend money for no practical benefit. Trusted SSL certificates are not free. Prices range from around $60 a year to hundreds of dollars (or thousands!) depending on the certificate’s capabilities. For bloggers who don’t transfer sensitive information, this is completely wasted money on a capability that provides very little benefit.
  4. Encryption and SSL isn’t automatically “better”. I find it curious that many resources flatly state that SSL is nearly always better than non-SSL. Why? Because data is encrypted. Okay, so what? The vast majority of blogs do not require encryption and the overhead necessary to provide it. Whether this article was encrypted before it was sent to YOU is of very little concern to either of us!
  5. Encryption takes CPU resources. Although the impact has been minimized with the influx of inexpensive high-powered computer hardware, SSL web sites require additional processing power to support encryption. For blogs that don’t need encryption, these are wasted resources.
Moreover, I find it shocking that people find it shocking that the large majority of web sites do not support SSL. The majority of web sites don’t support SSL because the majority of web sites simply do not need it, and the additional CPU resources it takes to establish and maintain the encrypted pathway for data that does not need encryption is simply not worth the price of admission.

 

AdSense ad code support for SSL

AdSense ad code supports secure ad serving through Secure Sockets Layer (SSL) on all pages, including Hypertext Transfer Protocol Secure (HTTPS) pages. This means that publishers with secure sites, i.e., sites that are served over the HTTPS protocol, can use AdSense ad code to serve SSL-compliant ads. All sites should be secured with HTTPS — HTTPS provides critical security and data integrity both for your sites and for the people who entrust your sites with their personal information.
Some important things to know about the SSL-compatible ad code:
  • HTTPS-enabled sites require that all content on the page, including the ads, be SSL-compliant. For most users, AdSense ad requests are always SSL-compliant and always served over HTTPS, even when the surrounding site is HTTP. The same ads compete in the auction, so switching your site to HTTPS will have no effect on the ads most users see, or on auction pressure. The only exception is for users located in countries that block or otherwise degrade HTTPS traffic.
  • If your site can be accessed over HTTPS, then you may need to update older versions of AdSense ad code to avoid the AdSense script being blocked as mixed content. If your AdSense ad code has a script starting with "http://", then you should update it to "https://" instead:
    1. <script src="https://pagead2.googlesyndication.com/pagead/show_ads.js">
    2. <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js">
    The HTTPS version of the ad code is also safe for HTTP pages; you don't need to serve two different versions.
  • The SSL-compatible ad code also works on HTTP sites and doesn’t change how ads are served on these sites.

How to use the SSL-compatible ad code

To use the new ad code on your HTTPS-enabled pages, use either of the options outlined here:

Option 1: Create new ad code

Generate your ad code, and then copy and paste the ad code into the HTML source code of your page where you'd like the ad to appear.

Option 2: Modify your existing ad code

To do this you'll need to make the following code change:
  • Synchronous ad code
    <script>
      google_ad_client=“ca-pub-xxxxxxxxxxxxxx”;
      google_ad_slot=“yyyyyyyyyyy”;
      google_ad_width=300;
      google_ad_height=250;
    </script>
    <script src="//pagead2.googlesyndication.com/pagead/show_ads.js"></script>
  • Asynchronous ad code
    <script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
    <ins class="adsbygoogle"
      style="display:inline-block;width:300px;height:250px"
      data-ad-client="ca-pub-xxxxxxxxxxxxxx"
      data-ad-slot="yyyyyyyyyyy">
    </ins>
    <script>
      (adsbygoogle=window.adsbygoogle || []).push({});
    </script>
In the examples above, “http” has been removed from both script sources. The source URLs now begin with two forward slashes, like this:
  • Synchronous ad code: "//pagead2.googlesyndication.com/pagead/show_ads.js"
  • Asynchronous ad code: "//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"