Google Siteとクローラー

Google Sitesの本文は検索エンジンやAIにどう読まれるのか

Google Sitesに入力した本文テキストは、Google検索において認識されている可能性が高いです。ただし、Googleに読まれることと、SEOやAIクローラーに対して安定した構造になっていることは別です。Google Sitesと静的HTMLの使い分けを整理します。

概要

Google Sitesで作成したページは、通常の静的HTMLサイトとは少し構造が異なります。

ページのソースを確認すると、本文がHTML内にそのまま並んでいるのではなく、JavaScriptによって画面上に表示されているように見える場合があります。

そのため、「Google Sitesに文章を入力していても、検索エンジンのクローラーは本文を認識できているのか」という疑問が出てきます。

結論から言えば、Google検索においては、Google Sitesに入力した本文テキストは認識されている可能性が高いです。

実際にTime合同会社でも、Google Sitesで公開しているコラムページに対して、Google Search Console上で表示回数やクリックが確認できています。

Search Console上では、ページ単位・検索語句単位で反応が見えているため、少なくともGoogle検索においては、Google Sitesのページ内容が完全に無視されているわけではないと考えられます。

ただし、これは「Google SitesがSEO上強い」という意味ではありません。

Googleに読まれることと、検索エンジンやAIクローラーに対して安定した情報構造になっていることは別です。

GooglebotはJavaScriptをレンダリングできる

Google公式ドキュメントでは、Googlebotはページをクロールしたあと、JavaScriptを実行してレンダリングし、その結果をもとにインデックス処理を行うと説明されています。

つまり、ブラウザ上で表示される本文がレンダリング後のDOMに存在していれば、Googleはその内容を認識できる可能性があります。

Google Sitesのページも、ブラウザで本文が表示され、Google Search Consoleで表示回数やクリックが確認できているなら、少なくともGoogleがページ内容を一定程度理解している可能性は高いと見てよいでしょう。

Search Consoleに検索語句や表示回数が出ている時点で、「JavaScriptだからGoogleが一切読めていない」という状態ではありません。

読めることとSEOに強いことは別

ここで注意すべきなのは、「Googleが読めること」と「SEO上、強い構造になっていること」は別だという点です。

Google Sitesは、簡単にページを作れる一方で、SEO面では細かな制御がしにくい部分があります。

  • ページごとのmeta description
  • canonical
  • 構造化データ
  • HTMLの見出し構造
  • 内部リンク設計
  • sitemap.xml
  • robots.txt
  • OGP設定
  • 表示速度の細かな調整

これらを自由に制御するには限界があります。

Googleが本文を認識できるとしても、検索エンジンに対して「どの情報を、どの構造で、どの優先度で伝えるか」を細かく設計しにくいのです。

そのため、Google Sitesは「読まれる可能性がある」一方で、「SEO資産として育てやすい構造」とは言い切れません。

検索エンジンはGoogleだけではない

検索エンジンはGoogleだけではありません。

BingもJavaScriptレンダリングへの対応を進めていますが、Googleと完全に同じ挙動を期待できるわけではありません。

さらに近年は、AIクローラーの存在も無視できなくなっています。

OpenAI、Anthropic、Perplexityなど、生成AI系のクローラーは、検索エンジンのGooglebotとは目的も仕様も異なります。

AI系クローラーがGooglebotと同じようにJavaScriptを実行し、レンダリング後のDOMまで安定して理解するとは限りません。

そのため実務上は、JavaScript実行後に表示される本文だけに依存するより、初期HTMLや静的HTMLとして本文が明確に存在している構成の方が安全です。

これは、Google Sitesが悪いという話ではありません。どのクローラーに、どの粒度で、どれだけ安定して情報を伝えたいのかという問題です。

Google Sitesは初期検証に向いている

Google Sitesには、明確な強みがあります。

それは、ページを素早く作って公開しやすいことです。

社内で扱いやすく、Google Workspaceとの相性も良く、HTMLやサーバー管理に詳しくない人でもページを作成できます。

そのため、Google Sitesは初期検証には向いています。

  • どのテーマに検索表示が出るか
  • どの検索語句で反応があるか
  • どのページがクリックされるか
  • どの情報に需要がありそうか
  • どのカテゴリを広げるべきか

これらを確認するには有効です。

実際にSearch Consoleで表示回数やクリックが確認できるなら、検索需要の検証媒体としては十分に使えます。

静的HTMLは資産化に向いている

一方で、本格的に検索流入を積み上げたい記事や、会社の情報資産として残したい記事は、静的HTMLやSSRに近い構成で公開した方が安定します。

静的HTMLであれば、title、meta description、canonical、構造化データ、パンくず、内部リンク、関連記事、sitemap.xml、robots.txt、OGP、表示速度などを細かく制御できます。

また、本文がHTML内に明確に存在するため、Googlebotだけでなく、BingやAIクローラーにも伝わりやすい構造を作りやすくなります。

検索エンジンに読まれるかどうかだけでなく、どの情報をどの構造で蓄積していくかを考えるなら、静的HTMLの方が管理しやすい場面があります。

Google Sitesと静的HTMLは使い分ける

Google Sitesを使うか、静的HTMLサイトに移すかは、単純な優劣ではありません。

実務上は、次のように使い分けるのが現実的です。

Google Sitesは、素早く公開して検索需要を確認する場所。静的HTMLサイトは、反応があったテーマを整理し、SEO資産として育てる場所。

この使い分けであれば、Google Sitesの手軽さを活かしつつ、重要な記事はより制御しやすい環境で強化できます。

たとえば、Google Sitesで公開した記事に表示回数が出る。Search Consoleで特定の検索語句に反応がある。問い合わせやアクセスにつながるテーマが見えてくる。

その段階で、静的HTML側に移し、meta情報、構造化データ、内部リンク、関連記事、sitemapまで整える。

この流れは、現実的なWeb運用として扱いやすいです。

Time合同会社での考え方

Time合同会社では、Google Sitesを否定的には見ていません。

むしろ、初期公開や検証には非常に便利なツールだと考えています。

実際に、Google Sitesで公開したページに対してSearch Console上の反応が確認できているため、少なくともGoogle検索向けの初期検証媒体としては機能すると見ています。

ただし、Google Sitesだけで本格的なSEO運用やAIクローラー向けの情報設計まで完結させるのは難しい場面があります。

そのため、Google Sitesは入口として使い、反応が見えたテーマや重要な記事は、静的HTMLサイトで整理し直す。

このような使い分けを重視しています。

Google Sitesは、素早く出すための場所。静的HTMLは、情報資産として育てる場所。

この役割分担を意識すると、Google Sitesの手軽さと、静的HTMLの制御性を両方活かせます。

まとめ

Google Sitesの本文は、Google検索において認識されている可能性が高いです。

GooglebotはJavaScriptをレンダリングでき、Search Consoleに表示回数やクリックが出ているなら、Googleがページ内容を一定程度認識している可能性があります。

ただし、Googleに読まれることと、SEO上強い構造になっていることは別です。

BingやAIクローラーまで含めて考えると、JavaScript実行後に表示される本文だけに依存する構成は、安定性に不安が残ります。

そのため、Google Sitesは検索需要を確認する入口として使い、重要な記事は静的HTMLで構造化して資産化する。

現時点では、この使い分けがもっとも現実的な判断だと考えています。

参考情報