仕事柄、Google Search Consoleを毎日のように見ています。
しかし、意外とお客様は確認されていないことが多く、理由を尋ねてみると『どこを見て、何をしたらいいかわからないから』という回答をいただきます。
そこで今回は、普段私がGoogle Search Consoleのどこを見て、何をしているのかをお話ししていきたいと思います。
しかし、すべてを話し出すと１記事では終わらないので、今回のテーマは「SSL化のミスの見つけ方」としています。
「今さらSSL化？」と思う方も多いかもしれませんが、私がこのテーマを選んだ理由は、今まで見てきたサイトの約８割が、大なり小なりSSL化のミスを抱えたままになっていたためです。
中にはそれが原因で順位を落としているサイトもありました。
もしかしたら、あなたが運営しているサイトも同じことが起きているかもしれませんので、ぜひご覧ください。
そもそも SSL化とは？
暗号化通信によって安全性を高める技術です。これによりユーザーの個人情報やログイン情報を悪意のある第三者から守ります。
SEOの観点からいうと、GoogleはSSL化をランキングシグナルにすることを公式ブログで公表しています。
HTTPS をランキング シグナルに使用します
●引用元：「Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用します」
https://webmaster-ja.googleblog.com/2014/08/https-as-ranking-signal.html
しかし、ランキングシグナルの強さは被リンクやコンテンツなどに比べると弱いものになります。
※参考：httpsとは？
SSL化のミスが与えるSEOへの悪影響
では、なぜ私がSSL化を重要視しているかというと、SSL化への移行の際のミスが大きい場合、順位の大幅な下落など、SEOに与える悪影響が大きいためです。
また、そのミスに気づいていないサイトが数多く存在しているのも事実としてあります。
例えば下記のグラフをご覧ください。
こちらは某レシピサイトのあるキーワードにおける順位の推移とランディングページを表したグラフです。
緑色のグラフが「http」のページ、青色のグラフが「https」のページを表しており、2019年4月にグラフが入れ替わっていることから、この時期にSSL化が行われたことが推測できます。
１位だったキーワードが、SSL化を機に12位（2020年8月14日現在）にまで下落しています。
この状態のまま１年以上放置されていることから、サイトオーナーはSSL化が原因で順位が下落していることに気づいていない可能性が高いです。
もう一つのパターンを見てみましょう。
こちらの場合、「http」のページと「https」のページが何度も入れ替わりが起き、順位も不安定です。
このケースもSSL化の移行がうまくいっていない場合に起きる現象。
このように、SSL化のミスの度合いによってはSEOへ与える悪影響は大きいため、私が担当する案件では、「SSL化が正しく行われているのか」を必ずチェックするようにしています。
「SSL化のミス」を見つける方法
前置きが長くなりましたが、Google Search ConsoleのどこをみればSSL化のミスが見つけられるか説明します。
やり方は簡単で、「http」のGoogle Search Consoleの「カバレッジ ＞ 有効」が「０」になっているかを確認するだけです。
「有効」が表しているのは、インデックスされているページ数。
SSL化は「http」から「https」へ移行するため、下記のように「http」の「有効」が「０」になるべきですよね。
それにも関わらず、下記のように「http」の「有効」が「０」以外になっている場合、「http」のページがまだインデックスされている、つまり、SSL化の移行が不完全である可能性が高いです。
インデックスされてしまっている原因は、だいたい下記の４つのケースになります。
では一つ一つ解説していきます。
ケース① canonicalで正規化をしている
通常、SSL化に移行する際に「http」から「https」へ301リダイレクトを行います。
しかし、301リダイレクトの代わりにcanonicalで正規化を行っているケースが見受けられます。
Googleはcanonicalを「命令」ではなく「ヒント」として扱うため、必ずしも正規化される保証はありません。
もし301リダイレクトを設定できる環境でしたら、canonicalではなく301リダイレクトで正規化を行うことを推奨します。
ケース② 「https」から「http」にcanonicalを向けている
先述しました通り、SSL化に移行する際に「http」から「https」へ301リダイレクトを行います。
しかし この際に「https」から「http」にcanonicalを向けてしまうと、下記のようにお互いが相手を正規ページとして指定し合うという矛盾した状態になります。
もしこのようなケースになっていましたら、「https」のcanonicalを削除するか、自己参照canonicalに変更することを推奨します。
ケース③ 302リダイレクトで正規化をしている
「301リダイレクト」と「302リダイレクト」の違いは下記のとおりです。
- 301リダイレクト：「恒久的な転送」
- 302リダイレクト：「一時的な転送」
SSL化への移行は「恒久的な転送」のため、「一時的な転送」である302リダイレクトを使用するのは誤りです。
しかし、302リダイレクトの状態がしばらく続くと、301リダイレクトとして処理することをGoogleのジョン・ミューラー氏はオフィスアワーで述べています。
私たちがリダイレクトを認識しそれが302なら、まず、一時的なリダイレクトだと想定する。そして、リダイレクト先のURLではなく元々のURLをインデックスさせたいのだろうと想定する。一般的には、これが私たちが302に対してやろうとすることの1つだ。
しかし、実際には恒久的なリダイレクトっぽくて、ひょっとしたら間違えて構成された302なのではないかと認識したら、そういった302を301として本当に扱う。
●引用元：「301も302もどちらのリダイレクトもPageRankを渡す。実際にはどちらをインデックスするかどうかの問題 | 海外SEO情報ブログ」
ただ、302リダイレクトを301リダイレクトとして認識するまでの時間分、302リダイレクトの方が PageRankを移行する時間が遅くなることを、Googleのゲイリー氏が鈴木謙一さんのインタビューで回答しています。
どちらも PageRank を完全に渡すとして、処理にかかる時間も同じなのか？
それについてもセッションで言いたかったことなんだけど、時間がなくて言えなかったんだ。時間は違ってくる。302 のほうが長くかかるだろう。
そのため302リダイレクトを使用することで、SSL化への移行が遅延することになるため、301リダイレクトに変更することを推奨します。
ケース④ リダイレクトチェーンに302リダイレクトを使用
ケース③では302リダイレクトを単体で使用した場合でしたが、今回はリダイレクトチェーン、つまりリダイレクトを繰り返し行う際に、302リダイレクトを1度でも使用しているケースです。
Googleのジョン・ミューラー氏がウェブマスター向けハングアウトにおいて、下記のように発言しています。
やむを得ず復数のリダイレクトを繰り返すときは、必ずすべてに301リダイレクトを使う。途中に302リダイレクトを挟んではいけない。
●引用元：301リダイレクトによるサイト移転時に重要なTIPSほか、気になる最新SEOのQ&A | 海外SEO情報ブログ
私が担当した案件にこのケースがありましたが、2年以上経ってもSSL化への移行ができていない状態でした。
そのため、やむを得ずリダイレクトチェーンを使用する際は、すべて301リダイレクトにすることを推奨します。
原因個所の特定に役に立つツール
リダイレクトやリダイレクトチェーンを確認する際には、chromeの拡張機能の「Redirect Path」がおすすめです。
下記のようにビジュアル的にリダイレクトの過程が見れるので、私はよく使用しています。
●参考：Redirect Path – Chrome ウェブストア
またcanonicalのチェックでしたら、chromeの拡張機能の「SEOTagViewer」がおすすめです。
下記のように開いているページの右下に、canonicalで指定しているURLが表示されます。
●参考：SEOTagViewer – Chrome ウェブストア
「Screaming Frog SEO Spider」を使用した原因分析
対象となるページが少ないと原因個所を特定するのに時間はかかりませんが、数百～数万ページとなると手間がかかります。
そこで効率よく原因を特定するために、私は「Screaming Frog SEO Spider」というツールを使います。
500URLまでなら無料で使用可能です。
●ダウンロード先：「Screaming Frog SEO Spider」
手順① 「http」のGoogle Search Consoleから「有効」のURLをダウンロード
「http」のGoogle Search Consoleの「カバレッジ ＞ 有効」をクリックします。
「インデックス登録されましたが、サイトマップに送信していません」もしくは「送信して登録されました」をクリック（sitemap.xmlが送信されているかどうかで異なります）。
次に右上にある「エクスポート」をクリックし、「Excelとしてダウンロード」を選択します。
ダウンロードしたExcelのタブ「表」にあるURLをコピーし、新しいファイルに貼り付けて保存します。
手順② Screaming Frog SEO Spiderの設定・クロール
Screaming Frog SEO Spiderを起動させ、「Mode」の「List」を選択します。
「Upload」の「From a File」を選択し、先にGoogle Search Consoleからダウンロードして作成したURL一覧のファイルを開きます。
ファイルが読み込まれたら「OK」をクリック。
クロールが始まりますので、ゲージが100％になるまで待ちます。
100%になったらクロールが完了です。
手順③ 原因個所の特定
ケース別に該当ページの見つけ方を説明します。
「ケース① canonicalで正規化を行っている」ページの見つけ方
「canonicals」タブを選択し、「canonical Link Element 1」が「https」になっている個所が、「http」のページから「https」ページにcanonicalを向けているページになります。
「ケース③ 302リダイレクトで正規化をしている」ページの見つけ方
「Response Codes」タブを選択し、「Status Code」が「302」になっている個所が該当ページになります。
「ケース② 「https」から「http」にcanonicalを向けている」ページの見つけ方
「手順① httpのGoogle Search Consoleから「有効」のURLをダウンロードする」で作成したURL一覧のExcelを開きます。
「http」を「https」に置換することで、「https」のURL一覧を作成。
作成したファイルを使用して、「手順② Screaming Frog SEO Spiderの設定・クロール」を行います。
「canonicals」タグを選択し、「Canonical Link Element 1」が「http」になっている個所が該当ページになります。
「ケース④ リダイレクトチェーンに302リダイレクトを使用」しているページの見つけ方（有料版のみ）
こちらの方法はScreaming Frog SEO Spiderの有料版（年間149ユーロ、約20,000円）のみできる方法です。
「configuration」＞「Spider」を選択。
次に「Advanced」タブを選択し、「Always Follow Redirects」にチェックを入れます。
あとは先の「手順② Screaming Frog SEO Spiderの設定・クロール」と同じ。
クロールが終わったら、「Reports」＞「Redirects」＞「Redirect Chains」を選択。
出力されたファイルにはリダイレクトごとの「Status Code」が記載されています。
そのため その中に「302」が入っているページが該当箇所になります。
まとめ
いかがだったでしょうか？
もしSSL化にミスがあり、改善を行った場合、下記のように「http」の「有効」の数が徐々に減っていき「０」になっていくはずです。
そして それが原因で順位の下落が起きていた場合、回復傾向に向かうはずです。
では、また次の記事でお会いしましょう！
アイオイクスではSEOを軸としたWebコンサルティングサービスを提供しています。
いわゆるSEOの型に沿った施策ではなく、お客様の事業やWebサイトの構成を踏まえた最適な施策のご提案を重要視しています。SEOにお困りの際はぜひご相談ください。
→SEOコンサルティング サービスページ
アイオイクスでは一緒に働く仲間を募集しています
アイオイクスのWebコンサルティング事業部では、「一緒に挑戦し、成功の物語を共有する」という理想像を掲げ、本質的な取り組みを推進しています。私たちと汎用性の高いスキルを突き詰め、自由に仕事をしていきませんか。
メールマガジンの登録はこちら
SEOに関連する記事の更新やセミナー情報をお届けします。
