Googleの検索結果がhttpsのURLになってしまう -SSL化推奨アルゴリズム-

公開:2016-07-02 / 制作・開発 / , , , ,
更新:2017-02-12

先日、サイト全体のSSL暗号化(常時SSL)の検証環境として、レンタルサーバの共有SSLについて紹介しました。

コチラの記事を参照)

 

そちらの記事で、Googleの「現状まだ軽微ではあるが、HTTPSを検索順位決定のシグナルとして使用開始している」という旨に触れました。

このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。

引用元:http://googlewebmastercentral-ja.blogspot.jp/2014/08/https-as-ranking-signal.html

 

そこで、常時SSL化のSEO効果がどの程度あるのか気になったので検証してみたところ、

 

Googleの検索結果に常時SSL化されたサイトのURLしか表示されない

(非SSLのURLであるhttp://のURLが検索結果に引っかからない)

 

という問題が発生してしまいました。。。

 

僕の調べ方だとこの問題を解決しないといけないので、まずはコチラからやっつけることにしました。

 

ところがかなりの難問だったので、本日はこの問題について言及したいと思います。

 

どうやってSEO効果を調べようとしたのか

まず、サイト全体のSSL暗号化(常時SSL)によるSEOの影響をどのように調べようとしたかについて説明します。

 

僕は「drunken-penguin.com」という独自ドメインをlolipopというレンタルサーバで利用しており、コチラの記事で紹介したとおり、デフォルトで共有SSLサービスを利用できます。

 

lolipopの共有SSLは、利用にあたり特別な設定は必要なく、契約時に割り当てられたWebサーバにファイルを配置した時点で共有SSLのURLでもサイトにアクセスできるようになります。そのため、公開期間やコンテンツ内容などURLを除いてすべて同じ条件であるといえます。

 

また、共有SSLのドメインはlolipop社のものになるため、ドメイン名が異なるURLになります。

これはGoogleの「HTTPSが優先してインデックスされる条件」(下記参照)には該当しない事になります。

 

HTTP ページに対応する HTTPS ページのクロールを開始します。これは、対応する HTTPS ページがどのページからもリンクされていない場合にも対象となります。同じドメインの 2 つの URL が同じコンテンツを掲載していると思われ、かつ、両者が異なるプロトコル スキームで配信されている場合、通常、以下の条件を満たしていれば HTTPS URL を選択してインデックスに登録します。

  • セキュアでない依存関係が含まれていない。
  • robots.txt によってクロールがブロックされていない。
  • セキュアでない HTTP ページに(または HTTP ページを経由して)ユーザーをリダイレクトしていない。
  • HTTP ページへの rel=”canonical” リンクが含まれていない。
  • noindex robots メタタグが含まれていない。
  • 同一ホスト上の HTTP ページヘのリンクが含まれていない。
  • サイトマップに HTTPS URL が掲載されている(または URL の HTTP バージョンが掲載されていない)。
  • サーバーに有効な TLS 証明書がある。

引用元:http://googlewebmastercentral-ja.blogspot.jp/2015/12/indexing-https-pages-by-default.html

 

この環境を利用して、単純に「非SSLサイトと常時SSL化されたサイトを比較する」を実現できると考えたしだいです。

 

検証、そして事象発生

次に実際に比較して確認した結果についてです。

 

非SSL・常時SSLサイトのURLとIPアドレスは、それぞれ以下のとおりです。

  • 非SSL : http://drunken-penguin.com (157.7.107.112)
  • 常時SSL : https://lolipop-dp25166794.ssl-lolipop.jp (210.172.144.10)

 

サイトにアクセスすると、どちらも以下の画面が表示されます。

drunken-penguin.com

 

この2つのサイトが引っかかるキーワードでGoogle検索し、その順位結果を見るだけです。

 

わかりやすいユニークな文字列として、ページにデカデカと表示されている「WEB屋 飯塚幸雄」というテキストがh1で括られているのでこのキーワードを利用しました。

 

検索した結果、共有SSLサーバで常時SSL化されている「https://lolipop-dp25166794.ssl-lolipop.jp/」が1ページ目に表示されました。

google検索結果

 

えっ!これってSSLが優遇されてるってことじゃね?

じゃあ非SSLのページが何ページ目表示されるかな〜、なんて考えながらページをめくり続けましたが、最後のページになっても現れませんでした。。。

 

???

icatch_memory

これは一体どういうことだ???

 

ということで調査開始です。

 

調査内容と導き出した仮説

先に説明したとおり「drunken-penguin.com」と「lolipop-dp25166794.ssl-lolipop.jp」はドメイン(URL)、IPアドレスが異なるので、別サイトとして扱われるものだと考えていましたので、これを前提にいくつか仮説を立てて見ました。

 

1.インデックスされてない?

まずはじめに、1年近く更新していなかったので「インデックスされていないのかも」ということで、両サイトがインデックスされているかどうか確認してみました。

 

Googleでインデックスされているかどうかを調べるためには、Googleで「site:【サイトURL】」で検索すれば確認できます。

実際に表示された結果は以下の画面キャプチャのとおりです。

SSLと非SSLサイトのインデックス

 

両方ちゃんとインデックスされてますね。。。

これが原因では無いということです。

 

2.重複コンテンツとして扱われてる?

別ドメインでソースが全く同じコンテンツということを思い出し、「もしかして重複コンテンツとして、一個にされちゃってるかも」ということで、フィルタを解除して見ました。

(フィルタってなんのこと?という方はコチラを参考にしてください)

 

フィルタを解除する方法は、検索結果URLの最後に「&filter=0」を入れてみればOKです。

重複コンテンツのチェック結果

 

次のページも見てみましたが、やはりSSLのURLしか表示されませんでした。

 

う~ん、わからない。。。

 

3.同一のWebサーバであることを判定している?

実は、lolipopの共有SSLは、ドメインは別ですがインターネットに公開するファイルを格納するWebサーバは同一になります。

そのため「もしかしたら同一のWebサーバで展開されているとhttpsが優先されるのかも」ということで調べてみました。

 

PHPでサーバのIPアドレスを調べる「$_SERVER[ ‘SERVER_ADDR’ ]」を記述したPHPファイルをドキュメントルートにアップし、

  • http://drunken-penguin.com/index.php
  • https://lolipop-dp25166794.ssl-lolipop.jp/index.php

 

にアクセスしてサーバのIPアドレスを確認したら、やはり両方とも同じIPアドレスでした。

(index.phpは削除してあります。あしからず)

 

もし、これが原因となると「この2つのURLが同一サーバにあるとどうやって判断しているのか?」が問題になります。

 

確かに、Googleの検索エンジンはかなり優秀で、DNS正引きだけでなく、逆引きも行って様々な確認をしているという情報はあります。

 

最近は格安レンタルサーバが数多く存在しており、その多くがHTTPサーバーのバーチャル・ドメイン設定を使って特定のIPアドレスに複数のサイトを割り当てることができるため、SEOの効果を得るために、1台のサーバー上に何十ものサイトを作り、互いに相互リンクを張るようなことが可能です。

(サテライトサイトと呼ばれるものです)

 

もしかしたら、Googleクラスの規模になるとスーパーnslookupコマンドのようなものを実行する権限を与えられているのかもしれません。。。

 

4,常時SSL化の優先アルゴリズムに伴い新たな処理が加わっている?

Googleは検索結果に同一サイトがたくさん入らないように重複コンテンツのチェックを行っています。

 

そこで、

 

ドメイン違いでもソースが同じページが存在した場合、それぞれのプロトコルをチェックし、http、httpsの組み合わせだった場合、httpsを優先して表示させる

 

なんてことをしている可能性も否定はできません。

 

実際に、重複コンテンツと判断した場合、オリジナルを表示させるというアルゴリズムが存在し、オリジナルじゃないほうが表示されてしまったりしてGoogleに問い合わせしているブログを幾つかみたことがあります。

 

結論

1,2は問題なく、3は調べる方法がない(と思われる)ことから4の「ドメイン違いであっても同じページでhttpとhttpsが存在したらhttpsを表示させる」という説が有力かと思っています。

 

Googleのロジックは公開されていないので、どちらが正解か判断はできませんが、どなたか知っている方がいたらご教示いただければ幸いです。。。

 

そもそもこの4つ以外にも考えられると思うので、また思いついたら追記していきたいと思います。

 

最後に

 

結局、こんなに調べたのに、結果わからなかったという事実がすごく悔しいです。。。

 

この問題について調べている方、答えがわかったら僕にも教えてください!

 

あ、当初の目的である「サイトの常時SSL暗号化におけるSEO効果」についても調べないと、、、

 

 

Author:yukio iizuka
プロフィール画像
フリーランスとしてUX視点で業務支援しています。 HCD-Net認定 人間中心設計専門家 LEGO®︎ SERIOUS PLAY®︎ メソッドと教材活用トレーニング修了認定ファシリテーター Hi-Standard好きです。
http://yukioiizuka.com
mislead
MISLEADの記事に共感いただけましたら
いいねをお願いします。

コメント一覧

コメントはありません

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



       

© yukio iizuka All Rights Reserved...