SEO Mythbusting エピソード5のまとめ: ウェブフレームワークとSEO

概要

1. 検索エンジンがJavaScriptを実行できるか
2. Google サーチコンソールの新機能でレンダリングの問題をデバッグする方法
3. Googleクローラーができることとできないこと
4. pushStateが認識されるかどうか
5. ボタンのクリックイベント認識について
6. 無限スクロールの対応
7. ウェブワーカーを利用しているサイトについて
8. フレームワークサイズの影響があるか

Q&A

以下、エピソード5の内容をまとめます。一部省略や言い換えをしておりますが、主な意味が失われないようにまとめるようにしております。

Splitt氏：

SEOとフレームワークでたくさんの誤解があるので、そこを解いていきたいですね。

Miller氏：

理由はわからないですが、「検索エンジンがJavaScriptを実行しない」という誤解はよく聞きます。Webの初期だったらそうだったし、他にJavaScriptを実行できない検索エンジンがまだ存在するからかもしれないです。

Splitt氏：

確かに、まだJavaScriptを実行できない検索エンジンやクローラーは存在します。
[サイト・コンテンツの]見つけやすさで気になることはありますか？

Miller氏：

例えばHTMLペイロードがスタイルシート内のスクリプトタグにあるアプリが存在したり…今Splitt氏笑ったけれどこれは良くありますよね。

Splitt氏：

確かに、そういうケースもありますね。ユーザーエクスペリエンスの観点から、ブラウザがコンテンツをフェッチし終わるまで空なページを眺めることになってしまいよくないですが、クローラーにも影響がありますね、JavaScriptをうまく実行できないクローラーには特にそうです。そのクローラーについては詳しくは言えないですが、GooglebotはJavaScriptを実行できますので、基本的に皆さんのコンテンツにアクセスできます。もちろんJSエラーやネットワークエラーがあれば別の話です。

Miller氏：

Splitt氏がこの間セミナーでGoogle サーチコンソールの新しいエラー確認機能について話していたかと思います。

Splitt氏：

そうですね、以前のFetch & Renderツールがあり、そこでページのスクリーンショットを表示できていました。そこでもし空なスクリーンショットが出たらどうしますか？

Miller氏：

泣きます。

Splitt氏：

その気持ち、わかります。その際の回避策はモバイルフレンドリーテストツールを利用することです。名前の通り、モバイルフレンドリーかどうかの確認ができますが、フェッチできなかったリソースの情報も表示されて、スタックトレースを含めてコンソールログをすべて提供しています。もし空なスクリーンショットが表示されたとしても、何がうまく行かなかったかのデバッグができます。
更に、新しいサーチコンソールにURL検査機能があって、その機能ではページ単位でワンストップソリューションを提供しようとしています。特定のページが最後にいつクロールされたか、インデックスされているか、AMPやモバイルフレンドリーの問題がないかなど確認できて、今後は構造化データマークアップとJavaScriptエラーもカバーされていくと思います。

Miller氏：

Googleのクローラーが持っていると考えていい機能は何ですか？

Splitt氏：

HTMLはパース(解読)しています。
ステート(セッション等の情報)は持っていないので、各ページは別シークレットウィンドウで開かれるイメージです。
クッキーは保持しますが、ページ遷移で破棄されるため、ページ間のクッキー引き渡しはされません。
WebGLは実行されません。キャンバスにあるものは確かレンダリングしなかったと思います。

Miller氏：

そこはどちらにしても検索できないですよね。

Splitt氏：

おっしゃる通り、その中にあるものは補助技術を利用するユーザーにはアクセスできないですが、クローラーもある意味で補助技術を必要とするユーザーと考えて良いと思います。

Miller氏：

ウェブサイトをクライアントサイドレンダリングのフレームワークで作ったとします（例えばReactフレームワーク）。History APIを利用してpushStateルーティングをしていれば、GoogleがpushStateを認識しますか？

Splitt氏：

example.com/…/listingなどちゃんとしたURLを渡してくれるのであれば、認識します。Hashでのルーティングを使う場合、認識できないので使わないことをおすすめします。History APIがベストです。
一つ注意してほしいのは、例えばトップページにランディングしてそこでリンクをクリックして遷移をして[ページが問題なく表示されるか確認する]というテストでは不十分です。先程言った通り、クローラーはステートを持たないので、そのような動きをしているわけではありません。各ページのURLに直接ランディングできるようにしなければなりません。サーバーがページをどう返せばいいかちゃんとわかるようにする必要があります。例えばすべてのルールのindex.htmlを返すサーバーを利用して、JavaScriptで適切なコンテンツを表示させるなどで良いです。ただ404などを返さないように注意してください。

Miller氏：

私は結構怠けてCDNを使っています。例えば200.htmlでファイル以外のURLでそのコンテンツを返すということができます。

Splitt氏：

これは素晴らしいですが、自分はそれで一度失敗したことがあります。GitHub PagesやS3などで静的ホスティングを使うことがあるかと思いますが、カスタムの404ページを返す機能があって便利です。すべてのルートを把握しきれず、そのカスタム404ページを表示させるという形でその機能を悪用したことがあります。ただステータスコードが404なのでインデックスされることがないです。

Miller氏：

すごく使えるエラーページということですね。

Splitt氏：

そうです。このような使い方はやめておくべきです。ページがクローラーに正しく認識されません。

Miller氏：

HTMLのリンクを使えばリンクが問題なく認識されるのはわかりますが、もしクリックイベントのボタンを使用して、そのクリックイベントがpushStateを呼び出していれば、どうですか？あまり批判しないでください！

Splitt氏：

ここは本当にリンクを使うべきです。AからBに遷移するならリンクを使います。ボタンはアクションのトリガーに使います。例えば、ポップアップの表示、ファンクションやカウントダウンのトリガー、ページ内のアクションに使うのが良いです。URLがある別コンテンツで、そのコンテンツを検索エンジンにアクセスできるようにしたい場合、リンクを使うべきです。

Miller氏：

例えばモーダルウィンドウですごく有用なコンテンツがあって、ページ内にボタンのクリックイベントで表示されるものがあれば、検索結果に表示させたい場合はURLを与えて、リンクを置くべきということですね。

Splitt氏：

そうです。アプリケーションステートの一部をURLに利用するというのも悪くないと思います。Googleがパラメータを認識するので、例えば「/action?modal=true」、このリンクを使ってモーダル表示にします。GoogleがURLにアクセスするときですが、例えばそのURLをコピーして友達にチャットツールで送って、その友達がサイトにアクセスしたことないデバイスから初めてそのURLを開くイメージです。そこであなたと友達のデバイスで同じ内容が表示されていれば、そのURLをインデックス対象にできます。

Miller氏：

Googleが検索結果に表示するリンクをユーザーがクリックすると何が表示されるか考える必要がありますね。

Splitt氏：

その通りです、ユーザーのために適切な表示をしなければいけません。ミスマッチがあると良くないです。

Splitt氏：

これと似たようなシナリオは無限スクロールです。例えば友達からURLが送られてきて、「あの鳥見た？」と聞かれて、「何の鳥？」となって、「あっちょっとスクロールしないと表示されないんだ」というシナリオは嫌でしょう？

Miller氏：

600メートルぐらい下にスクロールしないと表示されないとか。

Splitt氏：

600メートル下にあるコンテンツを表示可能にするのは課題ですね。

Miller氏：

アンカーリンクなどあれば…

Splitt氏：

その通りです。pushStateでURLをアップデートして、更にサイトに戻ったときにそれをJavaScriptに認識させて適切なコンテンツをロードさせれば良いです。

Miller氏：

スクロールをしていますが、Googleがそれを「前」「後」リンクとして見ているというイメージですか？

Splitt氏：

その通りです。Offsetを与えて、このJavaScriptがページ５から始まる…のようなイメージです。そこにGooglebotが来て、そのURLを5ページ目へのリンクとして判断して、そこに25個の画像が表示されて鳥が3番目に表示されて、完璧です。

Miller氏：

ページ読み取りにウェブワーカーを使っているとします。例えば、ステート管理やDOMレンダリングをウェブワーカーで行っています。実際に画面にピクセルを表示させるために、そのウェブワーカーを通ってHTMLやDOM操作をメインスレッドに取得する必要があります。そこで少し時間がかかってしまうことは問題ですか？

Splitt氏：

基本的に問題ないと思いますが、必ずGoogleが提供しているツールで予想通りの実行ができているかしっかりテストを行うことをおすすめします。モバイルフレンドリーテストツールがレンダー済みHTMLも出していますので、そこに存在すべき要素が存在しているか確認できます。サイトは他のところでも時間がかかったりすることがありますし、時間が少しかかるというところはおそらく問題ありません。

Miller氏：

DOM操作を行っている場合、モバイルフレンドリーテストツールに表示されるのはその後のHTMLですか？

Splitt氏：

はい。そのため、HTMLに何かが足りていないと気づいたら、問題があったということがわかります。

Miller氏：

フレームワークのサイズはクロールに影響がありますか？

Splitt氏：

クロールバジェットの観点から、フレームワークのサイズはあまり関係ありません。ただ、コンテンツを取得するのに必要なリクエスト数が多ければ多い程、Googleがカウントするリクエスト数が多くなります。例えば各ページが100リクエストを送信していれば、10ページをクロールしただけで1000リクエストに達します。ユーザビリティの観点から考えても、不安定なネットワーク環境でサイトを閲覧していると中途半端なコンテンツが表示されたり、コンテンツが全然表示されないと良くないでしょう。クロールバジェット観点でも役立つサーバーサイドレンダリングやハイブリッドレンダリングでリクエスト数を短縮することを検討すると良いでしょう。ただクロールバジェットは非常に複雑で、Googleはキャッシュも使っているので、コンテンツが既にキャッシュされていれば問題がなかったりします。

Miller氏：

それでは例えばトップページで色々なリクエストを送信して、商品詳細ページが同じリクエストでキャッシュを使っていればクロールバジェットに収まる可能性もあるということですよね。

Splitt氏：

その通りです。そしてクロールバジェットはサーバー負荷をかけすぎないよう常に調整されています。

まとめ

JavaScriptを利用したサイト作成自体は問題ありませんが、やはりURLルーティングや無限スクロールの扱いなどで工夫が必要だったり、今回挙げられたようなフレームワークでサイトを作成する場合には注意し、開発を始める前の慎重なプランニングが必要のようです。