テクノロジー観測所

この記事は運営堂様のメールマガジン（毎日堂）で紹介されました！

テクニカルSEOの手法は多岐にわたりますが、最初からSQLを眺めたり、Pythonでサイトをクローリングさせるなどの高度な解析を行う必要はありません。

そういうのは目視チェックが難しい大規模で複雑なサイトがお金をかけてやることです。

たとえばページ数が多くても、特定のディレクトリ配下のページは全て同じテンプレートを適用している場合、内部対策に限っていえば、1ページ分のソースコードをチェックすれば問題点は見つかるはずです。

またCMSにWordPressを使っている場合などは、ページごとに異なる要素であるリンクが切れているかどうかを自動的に検出してくれるプラグインなんかも存在します。

しかも、個人的には内部対策を行うにあたって必要な有料ツールはほとんどないと考えています。

無料で最強（これを超えるツールは存在し得ない）のGoogle Search Consoleだけでもかなりのことがわかるので、今回はその調べ方をご紹介します。

なお、やたら長くなっちゃったので細かく目次をつけておきます。

有料ツールが不要な理由　全てはSearchConsoleの中に

Google Search Consoleでは、Googleのクローラーが自分のウェブサイトをどう見たかがわかります。

なぜ（これを超えるツールは存在し得ない）といえるかというと、Googlebot（＝Googleのクローラー）の動きを一番よく知っているのはGoogle自身だからです。

ただし、逆の見方をすれば、BOTを含む「訪問者」がサイト内でどう振る舞ったかを一番よく知っているのは、自分のサイトリソースを格納しているサーバーになります。なので可能であればサーバーログも一緒に見られると尚良し……ですが、サーバーログは膨大なので目視ではとても追いつかないかと思います。
そういう時はツールを使いますが、Google Search Consoleだけでもかなりのことがわかるので、まずはそちらから手を付けると良いでしょう。

Google Search Consoleであれば閲覧・編集権限を他人に渡すこともできるので、信頼関係等がしっかりしていれば、比較的容易に作業に取りかかれます。

ただ、Search ConsoleもGAもたまに問題が出ることがあるので、100%の過信は禁物です。

Search Consoleで見るべきポイント：URL検査

Search Consoleの「URL検査」では、検査対象のURL（ページ）に対し、Googleのクローラーがどういう判定を下したかを見ることができます。

これによって、ページのインデックスが行われるまでのプロセスにおいて、問題が発生しているかどうかがわかります。

こんな感じで例を表示します。

ここからは、URL検査で調べられる項目をご紹介します。

サイトマップ – 検査したURL（ページ）がsitemap.xmlに記載されているか？

記載がない場合、URL検査結果は「URLはGoogleに登録されていますがサイトマップに送信されていません」等になるかと思います。
ここをチェックする時のポイントは、判定結果を2つに分けて考えることです。
「URLはGoogleに登録されている」と表示があれば、インデックスはされています。（＝Googleは検査対象のURLを発見済み）
「URLはGoogleに登録されていない」と表示があれば、インデックスされていません。（＝Googleは検査対象のURLを未発見、またはNoindexされている可能性がある）
その上で「サイトマップに送信されていない」と表示があれば、sitemap.xmlへの記載がないことになります。
これだけでもわかるかと思いますが、Googleのクローラーは訪問したページの内部リンクを辿るので、サイトマップに記載（送信）しなくてもページを発見することができます。
それでもなおサイトマップに記載したいかどうかはご自身で判断を。

参照元 – クローラーがどこから来たか？

「参照元」にページURLが記載されている場合、Googleのクローラーは直接ではなく間接的に訪問した可能性があります。
要するに「参照元」に記載されているページ内のどこかに、検査対象のページに遷移できるリンクが存在し、クローラーはそのリンクを辿ったということです。
なお、サイトマップを参照して検査対象のページを訪問した場合、ここにはsitemap.xmlのURLが表示されます。
また、大規模サイトでサイトマップインデックスを利用している場合、サイトマップインデックスと対象のサイトマップの2つのURLが表示されることもあります。
逆に、インデックスではないサイトマップ（サイトマップのURLではなくページのURLを書いたsitemap.xml）が複数表示される場合は、複数のサイトマップに同じURLを書いてしまっている可能性がありますので要確認です。

ただし、この結果はあくまでも直近に訪問したクローラーがとった行動です。いつも同じ経路で訪問するとは限りませんので、そこは留意する必要があります。

前回のクロール – クローラーがいつ来たか？

では「直近」とはいつなのか？というのがここで確認できます。
サイトパフォーマンスやページ構造などによっては、ここが1年前などになっていることもたまにあるので必ず確認されることをおすすめします。

ちょっと補足すると、こういう時はよくいわれる「クロールバジェット」によりGoogleのリソースが圧迫されてクロールが遅れたという可能性を考える方が多いかと思いますが、どちらかというと「クロールレート」を考えるべきです。
クロールレートとは、「Googlebotが訪問することでパフォーマンスを下げる可能性がある場合、Googleは訪問頻度を下げる」というようなものです。Googlebotが頻繁に訪問することでDDoS攻撃のようにサーバーリソースが圧迫され、レスポンスが遅れては本末転倒ですからね。
要するにクローラーは訪問するサイト/ページのパフォーマンスもチェックしており、「重たい」場合には訪問頻度を落とすことがありえます。ページ表示に時間がかかるだけでなく、サーバーのパワーが低い場合もネックとなり、回り回ってクロール頻度が下がることがあるというわけです。
常に最新の情報をインデックスしてもらいたい場合、これは致命的です。

ユーザーエージェント – PC/SPどちらのクローラーが訪問したか？

ここも注意点としては、ここに表示されるのはあくまでも直近で訪問したGooglebotのユーザーエージェントです。
PC版のクローラーが訪問したあとでURL検査を行えば「パソコン」と表示されますし、モバイル版のクローラーが訪問したあとでURL検査を行えば「スマートフォン」となります。
つまり、ここで「パソコン」と表示されたからといって、即座に「なんで！？MFIに対応しているはずなのに！」と慌てる必要はありません。

それよりも重要なことは、パソコンならパソコン版、スマートフォンならスマートフォン版のクローラーにきちんとページを認識してもらえたかです。

PCではきれいに表示されるけどSPでは表示が崩れるとか、PCとSPで評価が異なることがないか？を見るために、URL検査の他の項目と一緒に見ることをおすすめします。

クロールを許可？ – 検査したURL（ページ）のクロールを拒否しているか？

Robots.txt等によって、ページへのクローラーの訪問を拒否している場合、Noindexを入れていなくても、インデックスされることはないでしょう。
「クロールを拒否しているならそもそもインデックスされないじゃん」と思うかもしれません。しかし、繰り返しになりますがこれは「直近に訪問したクローラーの判定結果」であるところがポイントです。
つまりここが「はい」になっている場合、インデックスされた後で（Robots.txt等をいじって）クロールを拒否した可能性があることになります。
それが正しい判断か？を確認する必要がありますね。

ページの取得 – クローラーはきちんとページにアクセスできたか？

この項目の注意点として、おそらく厳密にはHTTPステータスコード「200」が返ってくればここは「はい」になると思います。
どういうことかというと、アクセスはできたけど表示（レンダリング）ができた（うまくいった）かはわからないということです。
これについては、Search Consoleの「カバレッジレポート」や「拡張レポート」で調べることができます。

これ以外にも、「公開URLをテスト」や「モバイルフレンドリーテスト」「Lighthouse」でも調べることができます。

また、「前回のクロール」に表示されたタイミングでは合格（不合格）だったけど、現在は違うということもありえます。
URL検査を行った動機がヘルスチェックではなく異常を察知した等である場合、より踏み込んで調査する必要があるでしょう。

インデックス登録を許可？ – Noindexが入っているか？

インデックスを許可しているか、拒否しているかの判定のため、noindexの指定の有無を見ているものと思われます。
ここも「前回のクロール」のタイミングでの判定になるので、インデックスされているけどNoindexが入っている、インデックスされていないけどNoindexは入っていないといった矛盾を見つける際にも役立ちます。

ユーザーが指定した正規URL – canonicalやリダイレクトが適切に設定されているか？

canonicalやリダイレクトによってURLを正規化している場合、それが適切に行われており、Googleが正確に理解したかどうかをここで確認できます。
以下に沿って確認してみてください。

Googleが選択した正規URL – それは正しい判断か？

サイト側で正規化を行っていない場合、あるいは行っていた場合でも、何らかの要因によってGoogleが「こっち側を正規と判断しました」という場合があります。
その際はこの項目を確認してみましょう。
なぜGoogleはこのURLを正規と判断したのか？を注意深く探る必要があります。
挙動に問題なければ放置でもいいですが、URLが異なると拡張レポートやGA等での集計に影響が出ることもあるので、ご注意を。

「現在はどうなっている？」を調べる：公開URLをテスト

URL検査結果画面の右上に「公開URLをテスト」という項目があります。

これは簡単にいうと、検査対象のURLをインデックスできるかどうかをテストできる項目です。
URL検査ですでにインデックスされていると検出された場合でも、ここで問題が起きていると、もしかしたら現在はインデックスが外されているかもしれません。

公開URLテスト（ライブテスト）には少し時間がかかるので、コーヒーでも飲みながらゆっくり行うと良いでしょう。

ライブテストでは、URLがGoogleに登録「できる」か「できない」かが判定されます。
先程のURL検査では「されている」か「されていない」かの判定でしたよね。ここが違いとなります。

Googleに登録というのは、インデックスするという意味です。

もうちょっと厳密にいうと、これはGoogleのインデックス用クローラーによるクローリングではありません。
どういうことかというと、ライブテストで合格判定が出たからといって即座にインデックスされるわけではありません。

判定結果の右下に「インデックス登録をリクエスト」というリンクが置かれています。

ここをクリックすることで、Googleのクローラーに対し「インデックス登録作業（＝クローリング）」をリクエストすることができます。
ちょっと専門的な言い方をするとキューに追加されることになります。キューとは「待機リスト」のようなもので、キューに登録された順番に1つずつクロールされます。

こんな感じで、ライブテストはURL検査と同じような項目が並びます。

ただ、「サイトマップ」と「参照元」はテストされません。つまり、ライブテストを行ってもサイトマップは参照されないし、ライブテスト時にどこか他のページからリンクを辿ってくるということもない、あくまでも検査対象のURL1ページだけを見るということです。

このテストが有効な点としては、「時間」の欄にテストを行った日付だけでなく時間まで記録されている通り、ほぼリアルタイム（現在の状態）の確認ができるところです。

たとえばこの記事で最初に貼り付けたURL検査画像では「URLはGoogleに登録できますが問題があります」と判定されていましたが、ライブテストを行ったところ「URLはインデックスに登録できます」と表示されました。

実はURL検査時には、特定の拡張レポートにエラーが出ていたのですが、ライブテストではそのエラーが解消されていることが確認され、合格しました。

つまり、変更・改修などの作業を行った際、それがGoogleにどう判断されるかをリアルタイムに確認できるというわけです。

キーワード対策などの場合、実装してから効果が出るまで（＝主な指標として順位変動や流入数・CV数の変化が確認できるまで）待つ必要がありましたが、一部の内部対策（特に、Search Console上でエラーが検出されていたもの）に関しては、改修後すぐにインデックス登録の可否確認が行えるというのは結構便利だと思います。

この機能の使い方をまとめると以下のようになります。

また、ライブテスト結果の下に置かれた「テスト済みのページを表示」をクリックすると、以下のことがわかります。

• 対象ページのソースコード
• 対象ページをライブテストした際のレンダリング結果
• 対象ページをライブテストした際の様々な判定結果

ただ、ここでも注意点があります。

見ての通り「スクリーンショット」タブに表示されたページのレンダリング結果では、ページをきちんと表示できていません。

ただ、これはあくまでも今回のライブテストを行った際に読み取られた結果となります。その時たまたま回線が重かったとか、何らかの事情で一部リソースのロードに失敗（あるいはギリギリタイムアウトなど）されることもありえます。

どうしても気になる場合は（過去にアクセスしているならば、キャッシュを消した上で）実際にそのページにアクセスしてみる、PageSpeed InsightsやLighthouseにかけてみたほうが具体的なことがわかります。

「様々な判定結果」とした「その他の情報」項目では、HTTPレスポンスコードや、ページの表示時に使用する各種リソース（Javascript等）のうち読み込めなかったもの、Javascriptコンソールに吐き出されたエラーなどを確認できます。

ページの表示に必要な（装飾等を記述した）CSS/Javascriptはクローラーがアクセスできるようにしておく必要があるので、このリストの中に検出されている場合はRobots.txt等をチェックする必要があります。
ただ、広告の表示などに使用する一部のJavascriptは、クロールされないものもあるようです。
このへんは正直詳しくは知らないのですが、googleadsとかdoubleclickとかのドメインがついているJSがこのリストには頻繁に出てくるように思います。

なお、今回ご紹介しましたURL検査およびライブテストに関して、より詳細な情報をお探しの場合は、Googleの公式Search Consoleヘルプをご覧ください。

URL 検査ツール – Search Console ヘルプ

他にも見るべきポイントはいっぱい

続いてはSearch Consoleの別のレポートを……と思ったのですが、長くなっちゃったので分けます。

URL検査では、「ページ単体」のパフォーマンスを確認することができます。

ライブテストでは、「そのページが現在インデックスできる状態か」がわかります。

そのページにクローラーがいつ来て、どう判定したかってことです。

これに対して、「サイト内のどの領域にどんな問題が起きているのか」とか「サイト内でインデックスされていないページはどのくらいあるのか」といった、全体を俯瞰して見るレポートも存在します。

次回はそれについてご紹介したいと思います。

▼書きました。

Search Consoleのカバレッジレポートは、テクニカルSEOのヒントが満載！