SEO監査に有効な「Googlebotブラウザ」の必要性（前編）

自分のウェブサイトをGooglebotに適切にクロールしてもらい、インデックス化してもらうのに苦労していないだろうか。テクニカルSEOの担当者にとって、（特にJavaScriptを多用しているサイトにおける）レンダリングの問題は、検索順位の低下やコンテンツの非表示につながることもある。

そのような場合に必要なのが、Chrome（またはChrome Canary）を使ってGooglebotをエミュレートすることだ。この方法では、ユーザーが閲覧する内容と検索エンジンが閲覧する内容の違いを明らかにして、サイトを想定通りに動作させられる。

Googlebotを偽装するかどうかにかかわらず、特定のテストブラウザを使えば、テクニカル監査の効率と精度が向上する。

このガイドでは、

• 手元で使えるGooglebotブラウザの作り方（Chrome利用）
• レンダリング問題のトラブルシューティング
• SEO監査の改善方法

を紹介する。

Chromeを使ったGooglebotブラウザの作り方は、後編（4/14公開予定）で解説する。まずは、なぜGooglebotブラウザが必要なのか、SEO監査における注意点、その他の選択肢などを理解してもらおう。

ウェブサイトをGooglebotとして閲覧するべき理由

昔は、テクニカルSEOの監査はもっと単純だった。ウェブサイトは主にHTMLとCSSで作らており、JavaScriptはアニメーションのような小さな機能拡張に限られていた。

今日では、ウェブサイト全体がJavaScriptで構築され、ページ内容構築の役割がサーバーからブラウザに移動している。つまり、Googlebotなどの検索ボットはクライアントサイドでページをレンダリングする必要があるということだ。ページをレンダリングする処理はリソースを大量に消費し、遅延が発生しやすい。

Google検索セントラルの「Google が JavaScript を処理する仕組み」より

検索ボットは往々にしてJavaScriptに手を焼いている。たとえば、Googlebotは最初に生のHTMLを処理するが、最終的にJavaScriptコンテンツを完全にレンダリングするのは、ウェブサイトによっては数日後から数週間後になることもある。

サイトによっては、そうした課題を回避する対処をしていることもある。具体的には、ボットにはサーバー側でHTMLをレンダリング済みのバージョンを表示し、ユーザーにはクライアント側でJavaScriptを使ってレンダリングするバージョンを表示するという仕組みだ。

ちょっと批判

前述のような動的な配信構成は、ウェブサイトが複雑になりすぎるほか、サーバーサイドレンダリングや従来のHTMLによるウェブサイトと比べてテクニカルSEOの問題が多くなる。幸い、そうした構成の利用は減少傾向にある。

例外はあるが、僕はクライアントサイドでレンダリングするウェブサイトという考え方には賛成できない。ウェブサイトは、できるだけ多くのデバイスで動作するように設計するべきであり、そのうえでJavaScriptを利用可能ならばさらに良い体験を実現する「プログレッシブエンハンスメント」として使うべきだ。

僕が実際に聞いた話によると、スクリーンリーダーなどのアクセシビリティソリューションを利用している人には一般に、クライアントサイドでレンダリングされるウェブサイトが使いにくい場合があるということだ。さまざまな研究がこれを裏付けているが、僕が目にした研究はアクセシビリティに投資している企業や慈善団体によるものだ（どのような偏りも共通善のために正当化されると僕が思う例だ）。

ただし、テクニカルSEOとユーザビリティが重なる例もある。

朗報

自分でChromeを「Googlebotブラウザ」として設定し、それを使ってウェブサイトを閲覧することで、「ボットが目にするもの」と「ユーザーが目にするもの」の違いを明らかにできるようになる（繰り返すが、具体的な設定方法は後編（4/14公開予定）で解説する）。

両者がまったく同一である必要はないが、ナビゲーションやコンテンツなどの重要な要素は一貫していなければならない。

このアプローチは、レンダリングの制限やその他の検索ボット特有の癖に起因するインデックス化や検索順位の問題を特定するのに役立つ。

Googlebotと同じように閲覧することは可能か

いや、完全に同じものとはならない。

GooglebotはChromeブラウザのヘッドレスモードでウェブページをレンダリングしているが、この記事で紹介している手法を使っても、その動作を完全に再現することは不可能だ。

たとえば、GooglebotによるJavaScriptの処理方法は予測不可能なこともある。

2024年9月には、多くのReactベースのウェブサイトにおいて、クライアントサイドでレンダリングされたコード内のmeta noindexタグをグーグルが検出できなくなるバグが注目を集めた。このような問題は、特にタグやメインコンテンツといった重要なSEO要素に関して、Googlebotをエミュレートすることの限界を浮き彫りにしている。

しかし、目的はGooglebotのモバイルファーストインデックスをできる限り忠実にエミュレートすることだ。そのために、僕は以下のツールを組み合わせて使っている：

• 「Googlebotブラウザ」を自分で用意して閲覧に使う。
• Screaming Frog SEO Spiderで、Googlebotを偽装してレンダリングする。
• Google Search ConsoleのURL検査ツールやリッチリザルトテストといったグーグルのツールで、スクリーンショットやコードを分析する。

注意すべきこととして、次のことがある：

グーグルのツール、特に2023年にユーザーエージェント「Google-InspectionTool」に切り替わって以降のツールは、Googlebotが閲覧している内容を完全に正確に表しているわけではない。

しかし、GooglebotブラウザやScreaming Frog SEO Spiderと組み合わせて使うことで、潜在的な問題の特定やトラブルシューティングに大いに役立つ。

Googlebotとしてウェブサイトを閲覧するために別のブラウザを使う理由

通常使うブラウザとは別に「Googlebotブラウザ」を用意することで、テクニカルSEOの監査が簡素化され、結果の精度が向上する。その理由は次のとおりだ：

1. 利便性

専用ブラウザを使えば、複数のツールを利用しなくても、Googlebotをすばやくエミュレートできるため、手間と時間を節約できる。

標準的なブラウザ拡張機能でユーザーエージェントを切り替えるやり方では、特にサーバーレスポンスが一貫していないサイトや動的コンテンツを含むサイトを監査する場合、非効率ともなる。

加えて、Googlebot固有のChrome設定のなかには、タブやセッションをまたいで有効にならないものもあるし、逆に特定の設定が作業中の他のタブに干渉する可能性もある（JavaScriptの無効化など）。

「SEO監査に使うブラウザ」を、「通常使っているブラウザ」と別で用意すれば、こうした問題を回避して監査プロセスを効率化できる。

2. 精度の向上

ブラウザの拡張機能は、ウェブサイトの外観や動作を意図せず変えてしまうことがある。Googlebot専用ブラウザを用意しておけば、拡張機能の数を最小限に抑え、干渉を減らし、Googlebotの体験をより正確にエミュレートできる。

3. 誤りの回避

標準のブラウザでは、Googlebotの偽装を無効にするのを忘れがちだ。そうすると、ウェブサイトが誤動作したり、アクセスがブロックされたりすることがある。

僕もGooglebotを偽装してウェブサイトからブロックされたことがあり、自分のIPアドレスをメールしてブロックを解除してもらわなければならなかった。

4. 課題はあるが柔軟

僕のGooglebotブラウザは長年、問題なく動作していた。しかし、Cloudflareが台頭し、eコマースサイトのセキュリティプロトコルが厳しくなったことで、状況が変わってきた。実際にGooglebotを偽装しながらサイトをテストするには、クライアントに「このIPアドレスを許可リストに追加してほしい」と依頼しなければできない場合も増えてきた。

ホワイトリストが使えない場合は、代わりにBingbotやDuckDuckBotなどのユーザーエージェントに切り替えている。Googlebotを偽装するよりも信頼性は低いが、それでも貴重な知見を得られる。

また、Google Search ConsoleでレンダリングされたHTMLを確認するという手もある。グーグルのクローラーとは異なるユーザーエージェントという制限はあるものの、Googlebotの動作をエミュレートする信頼性の高い方法であることに変わりはない。

Googlebotをブロックしているグーグル以外のサイトを監査する場合、自分のIPアドレスを許可してもらえるのであれば、Googlebotブラウザは今でも僕のお気に入りのツールだ。単なるユーザーエージェントスイッチャーにとどまらず、Googlebotが何を見ているかを最も包括的な方法で理解できる。

Googlebotブラウザが特に役立つSEO監査

Googlebotブラウザの最も一般的な用途は、クライアントサイドまたはダイナミックレンダリングを利用しているウェブサイトの監査だ。「Googlebotが見ているもの」と「一般ユーザーが見ているもの」を比較し、検索結果でサイトのパフォーマンスに影響を与え得る相違を簡単に浮き彫りにできる。

Googlebotブラウザでは、拡張機能は必要最小限に抑えることを推奨する。たとえばChromeに組み込まれているDevToolsやLighthouseを使って速度を監査する場合などは特に、拡張機能を多用しているブラウザと比べて、実際のChromeユーザーがウェブサイトをどのように体験しているかを正確にテストできることにもなる。

ダイナミックレンダリングを利用していないウェブサイトでも、Googlebotを偽装することで、何かがわかるかもしれない。僕は8年以上にわたってeコマースサイトを監査しているが、今でも特異な問題に遭遇して驚くことがある。

Googlebot監査で調査すべきこと

• ナビゲーションの違い ―― 「ユーザーが見た場合」と「Googlebotが見た場合」で、メインナビゲーションは一致しているか。

• コンテンツのビジビリティ ―― インデックス化してほしいコンテンツをGooglebotが閲覧できるか。

• JavaScriptのインデックス化の遅れ ―― サイトがJavaScriptのレンダリングに依拠している場合、新しいコンテンツはすぐにインデックス化されるか（たとえば、イベントや新製品情報など）。

• サーバーレスポンスの問題 ―― URLは正しいサーバーレスポンスを返しているか。たとえば、URLが間違っている場合、ユーザーには正しく「404 Not Found」と表示するが、Googlebotには「200 OK」と表示しているような可能性がある。

• ページレイアウトのばらつき ―― Googlebotを偽装すると黒い背景にリンクが青いテキストで表示されるサイトが存在する。機械には読めるが、まったくユーザー本位ではない。Googlebotが君のサイトを適切にレンダリングできなければ、何を優先すべきか判断することもできない。

• ジオロケーションベースのリダイレクト ―― 多くのウェブサイトは位置情報に基づいてリダイレクトしている。Googlebotは主に米国のIPアドレスからクロールしているため、自分のサイトがそのようなリクエストをどのように処理しているかを確認することが重要だ。

どの程度詳細に行うべきかは監査によって異なるが、ChromeにはテクニカルSEOの監査用ツールが数多く組み込まれている。たとえば、僕はよく「コンソール」タブと「ネットワーク」タブのデータを比較して、一般ユーザーとGooglebotによる見え方の違いを把握している。

このプロセスにより、Googlebotに対してブロックされているファイルや、普通なら見落とされる可能性のあるコンテンツの欠落を検出できる。