この記事をシェアシェアする
Google Search Relations TeamのMartin Splitt（マーティン・スプリット）氏に、弊社執行役員の鈴木謙一がインタビュー！レンダリングについての最新情報はもちろん、LLM（大規模言語モデル）と構造化データについても解説してくださいました。ぜひ最後までお読みください！
※この動画は、2025年5月に投稿されたものです。
▼動画で見たい方はこちら▼
▶︎https://50linesofco.de/
X（旧Twitter）
▶︎https://x.com/g33konaut
海外SEO情報ブログ – SuzukiKenichi.COM: 海外SEO
▶︎https://www.suzukikenichi.com/blog/
Web担当者フォーラム執筆記事
▶︎https://webtan.impress.co.jp/user/1730/articles
X（旧Twitter）
▶https://x.com/suzukik
鈴木：みなさんこんにちは。今日はイギリスで開催されているBrightonSEOに来ているのですが、ミエルカチャンネルですでにお馴染みのGoogle Search Relations Team のMartinに、色々話を聞いてみようと思います。
Martin、今日もお越しいただきありがとうございます。
Martin Splitt：今回もお招きいただき、本当にありがとうございます。
鈴木：またお越しいただけて嬉しかったです。
今日は、私たちにも馴染みのあるJavaScriptについて、いくつか質問させていただきます。
GoogleはなぜJavaScriptを正しくレンダリングできるのか
鈴木：最初の質問です。Vercelの調査[1]によると、ChatGPTやClaudeといったAIチャットボットは、JavaScriptで生成されたコンテンツを理解するのに苦労しているとのことでした。どうやら、それらのクローラーはJavaScriptをうまくレンダリングできていないようです。
一方で、Google Geminiについては、JavaScriptによって生成されたコンテンツを理解することができました。これは、GoogleがGoogle Cloudでレンダリングされたコンテンツを自社のAIツールと共有しているからなのでしょうか？
Martin Splitt：必ずしもそうとは言えません。
Googlebotがウェブ検索で見ている内容を私たちが共有しているわけではありません。ただし、”Google Extended”[2]と呼ばれている、Geminiが使用しているAIクローラーもレンダリングを行っています。
このレンダリングには、WRSという仕組みが使われているのですが、これは基本的には私たちが提供している一つのサービスのようなものです。 Googlebotもこのサービスを使っていますし、Geminiも同様に使っています。
※WRS：Web Rendering Serviceのことで、Google検索のプロセスにおいてGooglebotが取得したWebページをレンダリングする仕組み
鈴木：つまり、WRSという仕組みは共有されているということですね。
Martin Splitt：そうですね、共有されています。WRSは、Google内のさまざまなシステムで利用可能なサービスなのです。
鈴木：つまり、GoogleのAIは他と比べて有利な点がある、ということですね。
Martin Splitt：はい、言語システムがそのようなインフラを構築することも可能です。
[1]以下文献を参照
How Google handles JavaScript throughout the indexing process – Vercel
Googleレンダリングの都市伝説： JavaScript SEOの誤解と対策【SEO情報まとめ】 | 海外&国内SEO情報ウォッチ | Web担当者Forum
[2]Google の一般的なクローラー | Google 検索セントラル | Documentation | Google for Developers
レンダリングの速度に関して
鈴木：Vercelの調査によると、GoogleやBingはページをクロールした後、JavaScriptをレンダリングするまでに数週間かかることがあるそうです。
私自身は、手動処理なのであれば、もっと早く行われると思っていました。
レンダリングにかかる時間の中央値は5秒とのことですが、そんなに時間がかかるケースは、実際にあるのでしょうか？
Martin Splitt：この件については、二つのポイントに気をつける必要があります。
まず一つ目は、確かにそれだけ時間がかかる場合もあります。
ただし、それはレンダリング自体の問題ではなく、インデックス処理のスケジューリングに関する問題です。つまり、クロールはされているけれども、あるシステムが「このページはあまり重要ではない」と判断したために、インデックス用の処理に入らないことがあるのです。最終的には処理されますが、他のものが優先されるために遅れることがあります。
二つ目は、計測方法に問題がある可能性を考慮しなければならないという点です。実際に「いつレンダリングされたか」を正確に測るのは非常に難しいため、誤ったデータが表示されることもあります。
こうしたいろいろな要因があるのですが、ほとんどのケースでは、かなり早くレンダリングされています。
鈴木：つまり、特に心配する必要はない、という理解で合っていますか？
Martin Splitt：はい、全体の99%は数分以内にレンダリングされていると思います。
鈴木：ということは、Vercelが報告したケースは、かなり特殊な例だということですね。
Martin Splitt：そうですね、もう一度その調査を確認する必要はありますが、やはり特殊なケースだと思います。
SSRは推奨される？利点と欠点
鈴木：では次の質問です。現在、GooglebotのJavaScriptレンダリング能力はかなり向上していますが、それでもクライアントサイドレンダリング（CSR）よりもサーバーサイドレンダリング（SSR）の方が、一般的には推奨されているのでしょうか？
もし答えが「はい」であれば、サーバーサイドレンダリングの利点を教えていただけますか？ あわせて、考えられる欠点についても知りたいです。
Martin Splitt：ケースバイケースで判断する必要があると思います。
たとえば、情報をユーザーに提示するだけの一般的なウェブサイトであれば、JavaScriptを必須にすることはマイナス要因になります。壊れたり、不具合が起きたりする可能性があるからです。動作が遅くなったり、スマートフォンのバッテリーを多く消費したりもします。
そのため、もし私だったら、静的なコンテンツの場合はクライアントサイドレンダリングは使いません。静的HTMLのような形で表示するサーバーサイドレンダリングやプリレンダリングを選びます。
逆に、CADアプリケーションや動画編集ツールのような非常に動的なサービスであれば、コンテンツの中身自体は二次的な位置づけになります。そういった場合は、クライアントサイドレンダリングを選ぶのが合理的です。高いインタラクティブ性を持つウェブAPIの利点を活かせますし、非常に対話的なアプリケーションを構築できます。
ウェブ上でアプリケーションを作るのであれば、クライアントサイドレンダリングは良い選択です。そうでなければ、サーバーサイドレンダリングの方が適していると言えます。
ただし、サーバーサイドレンダリングはインタラクティブ性が非常に制限されるという欠点があります。また、インフラの構築が少し複雑になる可能性もあります。
ですので、どちらか一方が常に正しいというわけではなく、これは二つのツールなのです。ハンマーが必要なのか、それともドライバーが必要なのか、という話です。何をしようとしているのかによって、必要な道具は変わってきます。ネジを締めるなら、ドライバーの方が適しています。釘を打つなら、ハンマーの方が向いています。ウェブサイトを作るなら、SSR（サーバーサイドレンダリング）の方が適しているでしょう。逆に、よりインタラクティブなウェブアプリケーションを構築するなら、CSR（クライアントサイドレンダリング）の方が適しています。
つまり、SSRとCSRのどちらを使うかは、提供するサービスや使っているシステムによって大きく変わります。
LLMにおいてSSRは好ましい手法なのか
鈴木：次の質問です。LLM（大規模言語モデル）にとっても、SSRは好ましい手法なのでしょうか？
Martin Splitt：現時点では、ChatGPTなど他のAI企業はレンダリングをしていないようです。もしそれらにコンテンツを認識してもらいたいのであれば、SSRの方が適しているかもしれません。
ただ、それがどれくらいの期間続くかは分かりません。今でもそうなのかも正直分かりませんし、他社についてコメントすることはできません。私たちにとってはあまり関係ありません。
Googleも構造化データで理解精度は上がるのか？
鈴木：次の質問はJavaScriptではなく、構造化データについてです。
Microsoft Bingのファブリス・カナルさんによると、構造化データはBingやMicrosoftのLLMがコンテンツをより正確に理解するのに役立つそうです。
Googleの場合はどうでしょうか？
Martin Splitt：同じです。構造化データが多いほど、より多くの情報を得られ、信頼度も上がります。なので、構造化することには十分意味があります。
鈴木：では、LLMでも、構造化データを追加することを推奨されますか？もちろん、どんな結果が得られるかが保証されないことはわかっています。
Martin Splitt：構造化データを使うのが妥当なのであれば、構造化データは使うべきです。意味がない場合は、無理に当てはめる必要はありません。
鈴木：構造化データによって順位は上がりますか？（笑）
Martin Splitt：上がりません。（笑）
日本のSEO担当者にメッセージ
鈴木：最後に、日本のSEO担当者にメッセージをお願いします。
Martin Splitt：ああ、この件については、Garyの方が詳しいかもしれません（笑）。彼は日本のエコシステムをよく知っていますから。
ですが、今の良い取り組みはぜひ続けて欲しいと思っています。ユーザーのことを考え、自分たちのビジネス目標やユーザーをどう喜ばせるかを明確にして、素晴らしいコンテンツを作っていってください。
鈴木：これで以上です。本日はありがとうございました。お話できて嬉しかったです。
Martin Splitt：こちらこそ、楽しい時間でした。皆さんの幸運をお祈りしています。鈴木：本当にありがとうございました。
#構造化データ #JavaScriptSEO #LLMO #サーバーサイドレンダリング #SSR
株式会社 Faber Company 執行役員 Search Advocate（サーチ・アドボケイト）。「海外SEO情報ブログ」の運営者。正しいSEOをウェブ担当者に習得してもらうことをミッションに掲げている。検索関連のカンファレンス/イベントの取材やセミナーでの講師が Faber Company での主な役割。最近では、海外カンファレンスでの登壇も経験している。海外SEO情報ブログは、日本では、最も有名な SEO をテーマにしたブログの1つ。Google 公式ヘルプコミュニティのプロダクトエキスパートとして認定を受けており、Google 社員とのつながりも深い。
