概要
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で構造化して資産化する。
現時点では、この使い分けがもっとも現実的な判断だと考えています。
参考情報
- Google Search Central: JavaScript SEO basics
- Google Search Central: How Search works
- Google Search Central: Dynamic rendering
- Google Search Central: Fix search-related JavaScript problems
- Google Sites Help: Publish & share your site
- Bing Webmaster Blog: Evergreen Bingbot
- OpenAI: Overview of OpenAI Crawlers
