常時SSL化の際に必要なGoogle系ツールの設定

[目次]

Webディレクターの方は、Webサイトの管理/運営のために、おそらく何らかのGoogle系のツール類を利用されていると思います。

これらのツール類は、常時SSL化の際に設定の確認や変更などが必要です。

SEOの面でも効果があるかもしれませんので、正しい手順で実施しておきましょう。

Google Analyticsの設定

標準でHTTPSに対応しているので、特に必要な作業はありません。

疑り深い筆者は、念のためHTTPSのURLでもプロパティを登録してみましたが、常時SSL化前から使っていたプロパティと解析結果に差異はありませんでした。

カスタム検索の設定

ファーストサーバのWebサイトの一部では、有料版のSite Searchでサイト内検索を利用しています。

このサイト内検索は常時SSL化後に実装したため、特に作業は行っていませんが、昔から利用されている場合はWebサイトにに埋め込むJavascriptのコードを確認しましょう。

カスタム検索だけの話ではありませんが、埋め込むコードは時々更新されていますので、定期的にチェックして常に最新のコードを埋め込んでおけば問題は出ないはずです。

Search Consoleの設定

常時SSL化に伴ってURLが変わりますので、対象のWebサイトは別サイトとしてプロパティを追加し、それぞれ設定する必要があります。

1. Webサイトのプロパティを追加する

Search Consoleのプロパティとして、以下の4つを登録します。

「www.」付きのURLは使わないよ、という場合でも登録しておく必要があります。
常時SSL化前にすでに登録済みの「http://」のものは変更せず、そのままにしておきます。

  • http://ドメイン名
  • http://www.ドメイン名
  • https://ドメイン名
  • https://www.ドメイン名

2. 優先するバージョンを選択する

Search Consoleでプロパティを追加すると、おそらく『https://example.com/ の検索パフォーマンスを改善できます』というメッセージが届きます。

メッセージの中にあるバージョンの設定を行います。

(図5-1-1)パフォーマンス改善のメッセージ

「バージョン」といってもメッセージ内の説明にある通り『Google 検索結果でサイトを「www」付きで表示するかどうかを選択します。』というだけで、難しいものではありません。

「https://」で登録した2つのプロパティのうち、通常使用する方のダッシュボードで優先するドメイン名を選択するだけです。

(図5-1-2)優先するバージョンの選択

3. 新しいサイトマップを送信する

あらかじめHTTPSのドキュメントルートに、新しいURLを記述したXMLのサイトマップを設置します。

常時SSL化後に使用するURLで登録したSearch Consoleのダッシュボードから、サイトマップを送信します。
これにより、Googleの検索ロボットは新しいURLをクロールするようになります。

※ CMSなどでXMLサイトマップを自動生成している場合は、http://のURLが残っていないかなど、設定を確認してからGoogleに送信しましょう。

4. クロールを依頼する

サイトマップを送信すれば、いずれ検索ロボット(クローラー)が来てくれるのですが、常時SSL化が完了したら一刻も早くクロールして欲しいと思うのが普通だと思います。

そのような場合には、Search Consoleの「Fetch as Google」にある「インデックスに送信」機能でページの再クロールを依頼します。

「Fetch as Google」にアクセスし、テキストボックスには何も入力せずに「取得」ボタンをクリックします。

ページへのアクセスに問題がなければ、同じ画面に下部に表示されるリクエストの結果一覧の「インデックスに送信」ボタンをクリックします。

(図5-1-3)Fetch as Googleの操作

メッセージが表示されますので「このURLと直接リンクをクロールする」を選択して送信します。

(図5-1-4)インデックスに送信

※ クロールの依頼は、一定期間内に送信できる回数が決まっていますので、その範囲でやりましょう。

5. 反映状況を確認しながらひたすら待つ

検索エンジンに新しいURLが反映されるまで、具体的にどれくらいの時間がかかるかは正直わかりません。
Googleのアルゴリズム次第なので、とにかく待つしかないです。

また、反映されたからといって連絡があるはずもなく精神衛生上よくないので、Serach Consoleの「インデックスステータス」や「検索トラフィック」を確認しましょう。

検索エンジンからの流入状況を常時SSL化前の「http://」のプロパティの同じ数字と比較したり、実際にインデックスされたHTTPSのページ数などを見れば、おおよその反映状況を確認できます。

(図5-1-5) インデックスステータスの変化

筆者の経験では、だいたい2週間程度で検索エンジンからの流入がほぼHTTPSに変わったように見えました。

6. 古いサイトマップを削除する

Search ConsoleのHTTPのプロパティ(常時SSL化前の古いURL)で、ほぼ検索エンジンからの流入がなくなったら、そのプロパティ上で登録した古いサイトマップを削除します。

7. 否認するリンクのリストをアップロードする

この作業が必要な人は少ないかもしれませんが、念のため書いておきます。

「否認するリンク」を簡単に説明すると、Googleは検索結果の表示内容や順序を決定するための評価基準の1つに、そのWebサイトに対するリンクの品質をチェックします。

外部からの悪質なリンクはWebサイトの評価を下げる原因になるため、Googleに「ここからリンクは評価の中に含めないで!」とお願いするのが「否認するリンク」です。

Search Console ヘルプ – バックリンクを否認する

常時SSL化前にアップロードしていた場合は、常時SSL化後に新しいURLで再度アップロードが必要になります

※ Googleのアルゴリズムの変更(「ペンギン4.0」の導入)に伴い、リンクの否認の意味は薄れつつあるかもしれませんが、念のため実施しておきましょう。

この記事のポイント

  • Google系のツール類はWebサイトの常時SSL化の際に設定の確認/見直しを
  • 正しく対応すれば、SEO面での効果も期待できるかも