謎だらけのSEOテクニカル問題を解決する8つのポイントとは？ 【中編】グーグルは正しくクローリングできている？

4. グーグルはいつでもページをクロールできているか？

グーグルが見ている内容を確認するため、ログファイルを入手する必要がある。その時点で、グーグルがどのようにページにアクセスしているかを確認できる。

余談：ログの処理については、それだけで記事が書ける。僕自身もBigQueryによるログ解析についてガイドを書いたし、Screaming FrogのLog File Analyserを試してみることも強くおすすめする。このツールは、ログをめぐる多くの複雑な問題に対処するという素晴らしい仕事をしてくれた。

クローリングを調べるときには、以下の3つのポイントをチェックするといい。

1. ステータスコード：
   ステータスコードを時間をかけて確認しよう。URLをチェックしたとき、グーグルが参照しているステータスコードは自分が見たステータスコードと異なっているか？
2. リソース：
   グーグルは、ページのリソースをすべてダウンロードしているか？
   ページを生成するのに必要なサイト独自のJavaScriptやCSSファイルをすべてダウンロードしているかも確認しよう。
3. ページサイズのフォローアップ：
   すべてのページの最大値と最小値およびリソースの差分を示そう。もし差分があった場合、グーグルはすべてのリソースまたはページを完全にダウンロードできていない可能性がある。（僕がこの素晴らしいヒントを知ることになったきっかけをくれた、@ohgmに感謝したい）

この時点で問題は見つかったか？

ログファイルでは、グーグルがステータスコード200を取得していないのにも関わらず、僕たちが試してみると問題なくページにアクセスできる場合、Googlebotと僕たちの間にはまだ明らかに違いがある。その違いは何だろうか？

1. Googlebotは僕たちよりクローリングする回数が多い。
2. 人間がボットの振りをしているのではなく、間違いなくボットだ。
3. 1日で異なる時間帯にクローリングする。

これはつまり、次のことを意味する。

• もしウェブサイトがボットをうまくブロックできているのなら、僕たちとGooglebotを区別できるのかもしれない。
• Googlebotが私たちのウェブサーバーへより多くの負荷を与えることにより、それぞれ違った動作をする可能性がある。ウェブサイトは一度に多くのボットや訪問者がアクセスすると、オンライン状態を保つために特定の措置を取ったり、より多くのコンピュータを有効にしてウェブサイトを支えたり（これはスケーリングと呼ばれる）、多くのページをリクエストしているユーザーの速度制限を試みたり、軽量化したページを表示したりするかもしれない。
• サーバーは定期的にタスクを実行している。たとえば、リスティングサイトにて古いデータをすべてクリーンアップするタスクを毎日1時に実行している場合、このタスクがサーバーのパフォーマンスに影響を与える可能性がある。

こういった日々のタスク処理の影響で起こっている問題に対処するのは手間がかかるため、バックエンドの開発担当者へ相談したほうがいい場合もある。

解決策を練る議論を具体的にどう進めていけばいいのか分からない場合はどうするか？ 建設的な議論を進めるには、まずはあなたの挙げた要望がどれだけテクノロジの問題を解決するかについて説明したあとに、上で挙げたエッジケースに目を向けるようにすると成功することが多い。

• 重い負荷がかかったサーバーはどうなるか？
• 重要な定期的タスクはいつ実行されているか？

これについて考えるには、次の2つの情報が役に立つ。

1. ログの問題に規則性があるなら、グーグルが使っているのと同じ速度または強度のクローラーでウェブサイトをクローリングしてみることで問題の再現を試み、同じ問題を見つけたり引き起こしたりできるか確認してみよう。サイトの規模によっては常に可能というわけではないだろうが、可能なサイトもある。問題をいつでも再現できることは、解決につながる最善の方法だ。
2. しかし、再現できない場合は、Googlebotが問題を検知した正確な時間帯を特定できるよう努めてほしい。そうすれば、開発担当者が問題を他のログで試して状況をデバッグできる可能性がはるかに高くなる。

グーグルがページを一貫してクローリングできる場合は、次のステップに進もう。

5. グーグルは、こちらが確認できる内容を単発で目にしているのか？

グーグルがページを正しくクローリングできていることがわかったら、次のステップはグーグルがそのページで実際に見ているものを調べてみることだ。あなたのウェブサイトにJavaScriptが多用されている場合は、以前にもこの問題に挑んだことがあるかもしれないが。もしJavaScriptを多用していなくても、この問題は発生する可能性がある。

確認方法は先ほどと同じ、まずは一度、再現を試みる。それを可能にするのが、以下のツールだ。

• Google Search Consoleの「取得してレンダリング」機能
  表示されるもの：イメージ内のレンダリングされたDOM。ただしページソースのHTMLだけが返される。
• モバイルフレンドリーテスト
  表示されるもの：レンダリングされたDOMとレンダリングされたDOMの戻り値。
  レンダリングされたDOMが表示されるだけでなく、コンソールエラーがあれば追跡できる。

「取得してレンダリング」の機能、モバイルフレンドリーテストツール、Googlebot、これらの違いとはなにか？ 実はほとんどないが、タイムアウトに違いがある（だからこそ、この後のステップがあるのだ！）。もし興味があれば、これらのツールのを分析した違いに関する本格的な分析結果の記事を読んでみてほしい。

これらのツールで解析結果を表示したら、ブラウザで表示されるページと比較しよう。より正確に比較をするために、Diff Checkerなどのツールを使うことをおすすめする。

この時点で問題は見つかったか？

この時点で大きな違いが見つかった場合、僕の経験では、JavaScriptかクッキーによるものであることが多い。

それには次のような理由がある。

• Googlebotは、ページリクエストの合間にクッキーをクリアしてクローリングしている。
• GooglebotはChrome 41でレンダリングしているが、Chrome 41は最新のJavaScriptをすべてサポートしているわけではない。

これらは次の方法で特定できる。

• クッキーを使わずにページを読み込む。それには、ページを新しいシークレットセッションで読み込み、ここでレンダリングされたDOMと、通常のブラウザでレンダリングされたDOMを比較するだけでいい。
• モバイルテストツールを使用してChrome 41でページを確認し、「検証」で通常表示されるレンダリングされたDOMと比較する。

ここでも、Diff Checkerなどのツールを使って比較することで、差分を見逃すことなく比較できる。これらの差分をきれいに列挙したい場合は、HTMLフォーマッターを利用するといいかもしれない。

モバイルフレンドリーテストツールを使用すると、JavaScriptのエラーがスローされるのを確認することもできる。これは、JavaScriptに自信がある人には特に役立つかもしれない。

こういった情報やツールを用いれば、検証のためのバグの再現を複数生成できるし、開発者にバグとして修正してもらうためのデータとしても渡しやすくなる。

ここで表示される内容がすべて問題なければ、次のステップに進もう。

6. グーグルは実際、何を目にしているのか？

グーグルが目にしているものが、前のステップでツールを使って再現したものと異なる可能性がある。それはなぜか？ 主な理由をいくつか挙げよう。

• 過度な負荷がかかったサーバーは、あらゆる類の不可解な動作をすることがある。たとえば、ステータスコード200を返すこともあるが、それはデフォルトページかもしれない。
• JavaScriptはGooglebotのクロールの対象となるページとは別にレンダリングされる。、テストツールで検証した結果はGooglebotがJavaScriptのレンダリングにかける時間より短いかもしれない。
• ウェブページが生成される際には大量のキャッシュが蓄積されることが多く、このキャッシュ自体が問題を引き起こす場合がある。

ここに至るまで、Googlebotがクロール処理を行う時間について話していなかったが、ページは瞬間的にクローリングされるわけではなく、クローリングされたページもすぐにインデックス登録されるわけではない。

余談：キャッシュとは？

この段階まで来ると、キャッシュが問題になることが多い。キャッシュについてよく知らない人のために詳しく説明しておくと、キャッシュとは、次回アクセスしたときはさらに素早く利用できるように、何かを保存しておくことだ。

ウェブページをリクエストすると、そのページを生成するために多くの計算が行われる。計算が終わった後に再度ページを読み込むと、それと同じすべての計算をもう一度実行することになり、計算する時間がこの上なく無駄になる。この無駄を省くために、サーバーは多くの場合、ページのリクエスト時にアウトプットした情報を保存しておき、計算を再実行することなくアウトプットを表示する。このアウトプットを保存する処理がキャッシュと呼ばれるものだ。

なぜ、キャッシュについて知っておく必要があるのか？ それは、あなたが抱えるテクニカルな問題がこの時点ですでに、かなり面倒なことになっているからだ。もしかしたらキャッシュの設定が誤っていて、間違った情報がユーザーに返されている可能性もある。

なお、キャッシュについてさらに深く掘り下げた初心者向けの優れたリソースはあまりないが、キャッシュの基本に関するこの記事は比較的分かりやすいもののひとつであると思う。この記事では基本的なキャッシュのタイプについて網羅されている。

グーグルが実際に何を処理しているのか、どうすれば確認できるか？

• グーグルのキャッシュ
  表示されるもの：ソースコードレンダリングされたDOMは表示されないが、Googlebotがページを訪問したときに実際に目にした元のHTMLが表示される。これはJavaScriptを無効にして確認する必要がある。JavaScriptを無効にしないままページを開くと、ブラウザはすべてのJavaScriptのキャッシュを保存した状態のページを表示してしまう。
• 特定のコンテンツのサイト検索
  表示されるもの：レンダリングされたコンテンツの一部ページ上の特定のフレーズ
  例：（inurl:example.com/url "only JS rendered text"など）を検索することで、グーグルが特定のコンテンツの一部をインデックス登録できたかどうかを確認できる。もちろん、これは表示されているテキストコンテンツのみ検索が可能なので、目に見えない多くのコンテンツが見落とされてしまうが、何もないよりはマシだ！ しかも、ランクトラッカーで同じことをすれば、時間の経過とともにどう変化するかを確認できる。
• 実際にレンダリングされたDOMの保存
  表示されるもの：レンダリングされたDOMDeepCrawlのアレック・バートラム氏は、GooglebotからレンダリングされたDOMを保存することについて書いている。要約すると、グーグルはJavaScriptをレンダリングしてエンドポイントにPOSTするので、僕たちはそれを入手して、Googlebotが目にしている、JavaScriptでレンダリングされたバージョンのページを送信できる。次にそのページを保存して調べ、何が間違っていたかを確認できる。

この時点で問題は見つかったか？

ここでも、問題が見つかったら開発者のところへ話しに行こう。そのためのアドバイスは、1つ前のときと同じだ。そこで述べたことはすべて、ここでも有効だ。

開発者と話すにあたって他に知っておくべきなのは、グーグルがどのような仕組みで動いていて、どこで苦労する可能性があるか、ということだ。開発者は、ウェブサイトの技術的なこと全般やどのように構築されているかについて知っているだろうが、グーグルの仕組みについてはそれほど知らないかもしれない。情報が両方あれば、より早く答えを見つけられる可能性がある。

グーグル自らが提供しているリソースやプレゼンテーションの情報源もある。公開されているさまざまなリソースの中でも、僕が見つけた次の2つは、第一原理に知見をもたらすのに特に役立つと思う。

• ポール・ハー氏がグーグルの仕組みについて話したこの素晴らしい講演は必見だ。
• ジョン・ミュラー氏とトム・グリーンウェイ氏は2018年5月に開催されたGoogle I/Oカンファレンスで、グーグルがJavaScriptをレンダリングする方法について有益な講演を行った。

しかし、グーグルによる発表と、SEOの実務で目にするものは異なることが多い。僕たちの業界で人々が懸命に試行錯誤しているSEOのあらゆる取り組みも、知見を得る助けになる。そうしたリソースのリストは膨大になるが、2つの優れた例を挙げよう。

• グーグルはJavaScriptによって挿入されるURL正規化タグを尊重しているたとえば、エオーガン・ヘン氏によるこの素晴らしい分析では、グーグルがJavaScriptのcanonicalを尊重していることを示している。
• グーグルはさまざまなJavaScriptのフレームワークをどのようにインデックス化しているのか？これも広く読まれている試みの好例だ。バルトシュ・ゴラルウィッツ氏は2017年、グーグルがさまざまなフレームワークをどのように扱っているかを調査した。

3回に分けてお届けしているこの記事も、次回で最後となる。後編では、残る2つのチェックポイントについて説明するとともに、前編で紹介した4つの不可解な疑問の解答も示す。謎だらけのSEOテクニカル問題を解決する8つのポイントとは？ 【後編】httpsへの移行が生んだリダイレクトの永遠ループ？