SEO Mythbusting エピソード3のまとめ: JavaScriptについて

概要

1. JavaScriptって悪魔ですか？(Googleから見たJavaScript利用について)
2. Ajaxの利用とクロールバジェットへの影響
3. GooglebotとJavaScriptの関係について
4. 事前レンダリングについて
5. JavaScriptをSEO向けにしっかり実装することのメリット
6. 注目すべきパフォーマンス指標・テストツールについて

Q&A

以下、エピソード3の内容をまとめます。今回も楽しそうな余談が多い会話でしたので、一部省略や言い換えをしており、主な意味が失われないようにまとめるようにしております。

Q：JavaScriptって悪魔ですか？

いい質問ですね！特にうまく行かないときはそう思われがちですね。SEOの観点からでも、開発の観点からでも誤解が多いですが、悪魔ではないと思います。

JavaScriptにはメリットがあります。素晴らしいものが作れて、ユーザーの行動や要望に合わせた物を作ることができる。JavaScriptがウェブをドキュメントベースのプラットフォームから、アプリケーションプラットフォームに移してくれた素晴らしいものだと思います。我々は現在「JavaScriptは悪魔だ」、「JavaScriptを使うとインデックスされない」という誤解と戦っています。この考えは古くて、現在ではヘルプドキュメントのアップデートもされてきていて、注意すべき点などを表示しています。
（英語のみになりますが、例えば検索関連のJavaScript問題のトラブルシューティングガイドがあります）

例えば、SPA（シングルページアプリケーション、コンテンツの表示とページ間の遷移をJavaScriptで実行するウェブサイト）はリスクが高いと思われがちです。特に1点、多くの開発者が把握しておらず、SEO担当者が伝えそびれる大事なポイントがあります。それは、Googleがステートレスであることです。SPAにはアプリケーションのようなステートがあり、常にどのページを見ていて、どのような遷移をしているかわかっています。しかし、ユーザーが検索結果のリンクをクリックする際には、そのステートを持たずに、Googleがインデックスしたページに飛ばされます。Googleは直接アクセスできるページしかインデックスしません。JavaScriptに依存する機能は、ユーザーの遷移をベースにすることが多く、開発者がデバッグする際には、例えば、TOPページからグロナビのリンクをクリックして、商品をクリックして、その後に表示される画面に問題がないかなど確認しています。これだけでは不十分なケースがあります。「＃」でないユニークなURLが必要で、そのURLからサーバーがコンテンツを素早く正常に返せるようにしなければなりません。先程の例の動作を行った結果で表示された画面のURLがシークレットウィンドウからアクセスしたらTOPページや404ページではなく、該当するページが正常に表示されなければなりません。

またLazy Load（遅延読み込み）も良く話題に出ると思います。特にスマートフォン、画面が小さいデバイスで一気に全コンテンツを表示させるのは良くないでしょう。
（遅延読み込みコンテンツをGoogleに認識させることについてはこちらのヘルプにて確認できます。）

Q：Ajaxを利用するのはどうですか？

皆が使っているのに、最近あまり話に上がっていないですね。もちろん、ajaxは実行可能なので使って問題ありません。

Q：クロールバジェットへの影響はどうですか？例えば、商品ページで多くのパーツをajaxで取得している場合、Googlebotが１URL をリクエストしたのに、ajaxコールがユニークな文字列を持つため結果９URL程になってしまうようなケースがあると思います。これらの処理と、クロールバジェットへの影響が気になります。

このケースではクロールバジェットへの影響はさほどないと思います。クロールバジェットはとてもシンプルに見えて、実はかなり複雑なものです。Googleはコンテンツが頻繁に変わらないものだと想定して、キャッシュを使っています。GooglebotがURLから商品ページをリクエストして、そのページが更に9つのリソースをリクエストしたとします。GoogleがCSS、JavaScript、画像やAPIコールの読み込みを区別しないため、確かに1ページロード当たり9つのコールが存在していれば、クロールバジェットの観点では10コールになります。
ただし、その一部は既にキャッシュに存在している可能性があります。既にキャッシュされたものはクロールバジェットに加算されません。

Q：つまり、ajaxコールをバージョン化すれば、それがキャッシュされて、毎回読み込まれないで済むということですね。

その通りです。その方法が1つの解決策です。また、クロールバジェットだけでなく、ユーザーのことも考えると、例えば接続が悪い環境で途中問題が発生したらコンテンツが正常に表示されず、UXとして良くないです。そのため、事前レンダリング、ハイブリッドレンダリングやサーバーサイドレンダリング辺りも検討すると良いです。

クロールバジェットは常にサーバー負荷に応じて変動しています。そのためajaxに影響される以前にサーバー負荷に影響されて調整されている可能性が高いです。そのため、さほどの影響はないと思います。
（英語になってしまいますが、クロールバジェットについてはこちらのGoogleウェブマスターブログ記事にて確認できます。）

Q：Googlebotについてもう少し詳しく聞きたいです。Googlebotの動きにいくつかのステップがあって、まずはHTMLがパースされて、次に実行が必要なCSSとJavaScriptが見つかって、そのパーツがコールされて、最初のHTMLパースと最終的なレンダリングの間にタイムラグがあると理解しています。GooglebotはHTML、HTML5のプロトコルに従っていて、普段聞かないようなニュアンスがあると思います。例えば、Head内にiframeタグが存在するとします。そこにの終了スクリプトがあると、Googlebotにとってheadタグが終了します。ただ、その下にはまだmetaタグやcanonicalタグが存在する場合がありますね

そうですね。Googlebotは、たくさんの要素を持つ複雑なものです。まずはURLをサーバーから取得する部分があり、CSS、JavaScript、画像、そして初期のHTML内にあるリンクについての情報を取得します。それで既に多くの情報を取得できているため、レンダリング対象のJavaScriptを取得したり、それと別に初期HTMLにあるリンクから次のページへのクロールを続けたり、同時に動く部分が多いです。キレイにステップ１、ステップ２、というわけではありません。リンクがクロールされつつ、レンダリング用の待ち行列に追加されていきます。インデックスのために更にコンテンツを取得する必要があるため、レンダリングが完了するまでにページがインデックスされません。

Q：それを聞くと SPAにもメリットがあり、Googleが初めからテンプレートを取得していれば、そのテンプレートに当てはまるコンテンツだけ取得すれば終わりですね。ということは、Googlebotが実はこのようなJavaScriptプラットフォームを好むということですか？

おそらくそうです。最初のステップで素早く提供できるコンテンツが多ければ多い程良いです。常にレンダリングを待つのではなくその情報を持って前に進めるためです。

Q：常に事前レンダリングを使用した方がベストですか？

難しい質問です。クローラーだけでなく、ユーザーにもメリットがあり、ほとんどのケースではおそらくそうですが、注意が必要です。より多くのコンテンツを渡すのは良いことですが、一気に画像数が無限大なページを渡すべきかと言うとそうでもありません。ユーザーの観点からはよくなく、例えば古い端末から見る際に画像が多すぎるとサイトが使い物にならないと判断されてしまうかもしれません。

そのため、事前レンダリングが100％のケースで使うべきとは言えません。重要なコンテンツを最初から表示させつつ、どのコンテンツを遅延読み込みで追加できるか考えてバランスを取ることが必要です。

Q：SEO担当の観点からでは、クエリによってユーザーの意図が違うことがわかるため、その意図に該当する要素は最初のパース内に入っているべきということですね。

その通りです。1ページに存在するコンテンツに対しての検索意図が大きく異なり、コンテンツが大きく異なっている場合、別ページ、またはSPAの場合は別ビューに分けることを検討すると良いでしょう。そのコンテンツを検索結果に表示させるために、個別の入り口を持たせることが必要なためです。

Q：1ページをハブ扱いして、ユーザーに（意図によって）経路を選ばせるということですね。そこで例えばCSSのvisibility toggleを使うといいですか？

それは一つの選択肢で、また別URLを持つのも選択肢の1つです。特にSPAでHistory APIを使って経路別にどのコンテンツを表示させるべきかなど動的に区別することができると思います。Googleがパラメータにも対応するので、ユーザーに適切なページステートをURLに出せば良いと思います。

Q：我々の最終的な目的はユーザー満足です。（JavaScriptをSEO向けに正しく実施することは）上記の話とは別に、他にもメリットがありますか？

Googleもサイトの開発者も同じく、ユーザーに必要な情報をより早く表示させたいという目的があると思います。特にハイブリッドレンダリングやサーバーサイドレンダリングをユーザーのデバイスに負荷をかけすぎずにうまく実現していると、コンテンツをユーザーに素早く表示できるというメリットがあります。そしてユーザーは直接重要なコンテンツに飛ばされます。ユーザーとして特定なものを探しているときに、それに関する情報を持つURLが渡されたら、すぐにアクセスできて満足します。サイトパフォーマンスの改善ができていれば、古いデバイスや接続が悪い環境でもそのコンテンツに無事にアクセスできるはずです。

Q：パフォーマンスは様々な要素に影響されますよね。テクノロジーのスタックがあって、その中でSEO担当はどの部分に注目すればいいですか？

まずは、SEO担当ではないですがビジネス側や開発者によく無視されがちなのはコンテンツ部分ですね。コンテンツはユーザーが望んでいるものであり、役立つものである必要があります。

Q：ちょっと待ってください、例えば、ファーストビューによくある、メインビジュアルからの500文字の紹介文など、商品を買いたいという目的が色々なものに邪魔されてしまっていますよね！

そうですね。やめた方がいいです (笑)
少なくとも、ページを分けて、ダイレクトマーケティング向けのページを持ちつつ、商品を探しているユーザーには単純にその商品を買わせてください。

「パフォーマンス」は様々な要素が混ざっており、例えばコンテンツがいつ表示されるか、操作がいつからできるかなどです。KPIで言うとFirst Contentful Paint、TTFB（最初の1バイトが到着するまでの時間）などです。TTFBは少し時間がかかったとしても、そのあとにすぐにコンテンツが表示されればそれで良いので、First Contentful Paintの方が重要かと思います。ユーザーの観点から、最初のバイトが早かったとしてもそのあとでJavaScriptの実行やリソースがブロックされているなどでずっと空の画面が表示されていれば意味がないです。到着に少し時間がかかったがページがすぐに表示されたらそれで良いでしょう。
実現方法は様々ですが、たくさんテストをすることをおすすめします。

Q：テストで何かおすすめのツールはありますか？

（Chrome拡張機能の）Lighthouseをおすすめします。また、Webhintはもっと範囲が広いツールです。ページスピードインサイトやLighthouse内のSEO Auditsを活用すると良いです。モバイルフレンドリーテストよりも様々な情報が確認できます。

まとめ

エピソード１と２と比較して、エピソード3は一気に難易度が上がり、技術的な内容をたくさん聞くことができました。視聴者の評判も今まで一番高いエピソードでした。

日本ではまだSPAサイトの進出度が海外程高くないですが、JavaScriptは広く使われており、今後もJavaScript向けSEOの要件の理解を深めつつ、SEO担当と開発側のコミュニケーションがより重要になってくるかと思います。