Googleサイト徹底解説｜機能一覧・作り方・料金・制限・代替案まで

2025年5月30日2026年1月20日

「Googleサイトって、無料でホームページが作れるらしいけど……実際どこまでできるの？」
そう思って調べ始めたものの、情報が断片的でモヤモヤしていませんか。

「とにかく早く公開したい。最短で作る手順を知りたい」
「料金は本当に無料？どんな条件で使えないことがあるの？」
「社内ポータルやプロジェクトサイトにも使える？権限や共有が不安」
「独自ドメインは設定できる？反映しないって聞くけど大丈夫？」
「SEOはどこまでできる？ Search ConsoleやAnalyticsは使える？」
「後からWordPressなどに移行したくなったら詰む？バックアップは？」

Googleサイトは、Googleドライブやフォーム、カレンダーなどと相性がよく、“早く作って、チームで更新する”用途に強い一方で、デザインや機能、SEOの細かな制御には限界もあります。
つまり「向いているケース」を選べば最高にラクですが、「向いていない目的」で使うと遠回りになりがちです。

この記事では、初心者でも迷わないように、Googleサイトを1記事で俯瞰できる形にまとめました。

できること／できないこと（制限と回避策）
最短で公開する作り方（ページ構成・導線設計）
料金と必要なもの（個人アカウント／Workspaceの違い）
公開範囲・権限・共同編集（事故防止の考え方）
独自ドメイン・URLの注意点（反映しない時のチェック含む）
SEOとアクセス解析（できる範囲で最大化する方法）
代替案（WordPress/Wix/STUDIO/Notion等）との選び方

公式ヘルプなどの一次情報をベースに、実務でつまずきやすいポイントを先回りして整理しているので、読み終える頃には「自分はGoogleサイトで行くべきか」「どう作れば迷わないか」がはっきりします。

【※Googleサイトは簡易的なホームページ作成向きです。本格的なホームページを検討している場合は以下をおすすめします↓】

専門知識は不要！プロ級の美しいホームページがつくれる【とりあえずHP】
こんなに簡単！店舗向けホームページがすぐ始められる「グーペ」
ありえないほど簡単にホームページができる【ジンドゥー】
無料ホームページ制作・作成なら作り方かんたんなペライチ
手軽にホームページを作成【おちゃのこさいさい】

記事でわかること（最短で作って、迷わず運用できる状態まで）

このパートでは、Googleサイトを「とりあえず作れた」で終わらせず、公開・共有・更新がスムーズに回る状態まで、迷いやすいポイントを先回りして整理します。

具体的には、次のことがわかります。

最短で公開するまでの流れ（何から手を付けるべきか）
公開範囲の決め方（一般公開／限定公開／組織内公開）
共同編集の進め方（担当分け・権限・事故防止）
独自ドメインの考え方（必要なケースと注意点）
“伸びる運用”の型（更新しやすい構造・ルール・テンプレ）

また、初心者がつまずきがちな「結局どこまでできるの？」「何ができないの？」を、用途ごとに短く整理します。
読むだけで、次の一手が決まる構成にします。

対象：個人の簡易サイト／小規模ビジネス／社内ポータル・プロジェクトサイト

Googleサイトは、ざっくり言うと “速く作れて、共有・更新がラクなWebページ” を作るのに強いツールです。
特に、次のような人に向いています。

1) 個人（簡易サイト）

自己紹介／プロフィール
ポートフォリオ
イベント告知ページ（参加案内・地図・申込）

2) 小規模ビジネス

1枚の案内ページ（サービス概要／料金の目安／問い合わせ）
採用ページ（募集要項／選考フロー）
店舗の案内ページ（アクセス／予約導線）

3) 社内ポータル・プロジェクトサイト

情報が散らばりがちな「リンク集・手順・FAQ」の集約
プロジェクトの議事録・資料・最新情報の置き場
新人向けオンボーディング（最初に読むページ）

ポイントは、「頻繁に更新する」「複数人で扱う」「見た目はシンプルでOK」な用途ほど相性が良いことです。

この記事の結論（Googleサイトが“刺さる”ケースを先に整理）

先に結論です。Googleサイトが強いのは、次の3タイプです。

スピード重視：今日中に公開したい／サクッと立ち上げたい
共有・運用重視：社内やチームで編集し、最新情報を保ちたい
Google連携重視：ドライブ、フォーム、カレンダー等を“そのまま”載せたい

逆に、次の要件が強いなら、最初から別手段（例：WordPressや高機能なWeb制作ツール）を検討した方がラクです。

デザインを細部まで作り込みたい
ブログ運用・高度なマーケ施策をガッツリやりたい
EC／会員機能など、複雑な仕組みが必須

用途別の相性早見表

スクロールできます

やりたいこと	相性	理由（短く）
社内ポータル／プロジェクトの情報集約	◎	共同編集と共有が主役。更新がラク
イベント案内（申込・地図・日程）	◎	フォームやカレンダーを載せやすい
1枚もののサービス紹介・会社案内	○	すぐ公開できる。シンプル運用向き
しっかりSEOで集客するブログ	△	“作りやすさ”が強みで、拡張性は限定的
EC・予約システム・会員制サイト	×	機能面で不足しやすい

最短で迷わないための「3つの原則」

初心者が詰まりにくくなる、運用のコツだけ先に置きます。

ページ構成を先に決める（増やしても破綻しない）
公開範囲を先に固定する（公開事故を防ぐ）
更新ルールを作る（誰が・どこを・いつ直すか）

この3つを押さえるだけで、「作ったのに放置」「誰も更新できない」「情報が散らばる」をかなり防げます。

Googleサイトとは何か（できること・立ち位置を1ページで把握）

Googleサイト（Google Sites）は、Googleが提供する“かんたんWebページ作成ツール”です。
コードを書かなくても、文章・画像・ボタン・埋め込みなどを組み合わせて、公開用ページや社内向けページを作れます。

まずは全体像を3行でまとめます。

作る：テンプレート＋ドラッグ＆ドロップでページを組み立てる
共有する：共同編集・公開範囲の調整がしやすい
運用する：Googleドライブ等と相性がよく、更新が続けやすい

「凝ったWeb制作」よりも、スピードと運用が重視される場面で強い立ち位置です。

Googleサイトの特徴：ドラッグ＆ドロップで作れる／共同編集しやすい

1) ドラッグ＆ドロップで“見たまま”作れる

Googleサイトは、ブロック（部品）を配置して作ります。初心者が迷いにくい理由は、次の2点です。

テンプレートがある：白紙が苦手でも始めやすい
自動で整列する：レイアウトが崩れにくく、スマホ表示も意識しやすい

ページに置けるものの例（よく使う順）

見出し／本文テキスト
画像、ボタン
Googleドライブのファイル（ドキュメント、スプレッドシート、スライド）
Googleフォーム（問い合わせ・申込）
カレンダー、地図、YouTube などの埋め込み

「資料はドライブに置き、サイトには“見せ方”だけ作る」という運用ができるので、更新の手間が増えにくいのが利点です。

2) 共同編集が“最初から前提”で作られている

Googleサイトは、個人制作だけでなく、チーム運用に向きます。

編集者を招待して、同じサイトを複数人で更新できる
下書き（編集画面）と公開版（閲覧画面）で共有範囲を分けられる
設定次第で、編集者が勝手に公開・権限変更しないよう制限もできる

運用で失敗しないコツ（初心者向け）

編集者は最小限（増やすほど事故が起きやすい）
変更ルールを短く決める（例：更新は「お知らせ」だけ、資料はドライブで管理）
公開担当を1人決める（公開ボタンを押す人）

料金と必要なもの（無料で始める条件・利用できないケース）

料金の考え方

Googleサイトは、基本的にサイト作成・公開そのものに追加料金はかかりません。
ただし、次のような“周辺コスト”は別です。

独自ドメインを使うなら：ドメイン取得費（年額など、取得先により異なる）
法人運用でWorkspaceを契約するなら：ユーザー数に応じたライセンス費用

目安として、費用の分かれ方はこう考えるとシンプルです。

スクロールできます

やりたいこと	追加費用の発生	補足
とにかく無料で公開して使う	なし	Googleアカウントがあれば開始可能
独自ドメインで公開したい	あり	ドメイン代＋DNS設定などが必要
組織で管理・統制したい	あり	Google Workspaceの契約を検討

必要なもの

Googleアカウント（個人アカウント or Google Workspaceアカウント）
作業しやすい環境：基本はPCブラウザ推奨（編集の操作がしやすい）

利用できない／制限がかかる代表例

初心者がハマりやすいのは「自分のアカウント側の制限」です。

保護者管理のGoogleアカウントでは、Googleサイトを新規利用できない場合がある
会社・学校のアカウントは、管理者ポリシーで
- そもそも作れない
- 外部公開ができない
- 共有範囲が制限される
  といったケースがある

「作れない／公開できない」と感じたら、まずアカウント種別と管理設定を疑うのが近道です。

個人GoogleアカウントとGoogle Workspaceの違い（管理・権限・運用の差）

Googleサイト自体の操作感は近いのですが、運用の安心感が大きく変わります。

ざっくり結論

個人アカウント：自分で作って自分で管理（小さく始めやすい）
Workspace：組織で統制して管理（退職・異動・情報統制に強い）

違いを「運用」の視点で比較

スクロールできます

観点	個人Googleアカウント	Google Workspace
所有の考え方	個人に紐づく	組織（会社・学校）に紐づく
権限の統制	個別に共有設定	管理者がポリシーで制御しやすい
外部共有	基本は自己責任で設定	外部共有の可否・範囲を制限しやすい
運用の継続性	アカウントが変わると引継ぎが面倒になりがち	異動・退職時も管理しやすい
サポート	基本はヘルプ中心	プランによりサポート体制が手厚くなる

初心者のおすすめ指針

個人・小規模で“まず作る”なら：個人アカウントで十分
社内ポータルとして“継続運用する”なら：Workspaceが安心

「新しいGoogleサイト」と「以前のGoogleサイト」の違い（移行が必要な人向け）

ここは混乱しやすいので、最初に前提を揃えます。

現在主流なのは 「新しいGoogleサイト」（一般にGoogleサイトと言えばこれ）
以前の仕組みは 「Classic（旧）Googleサイト」 と呼ばれ、移行が必要になった時期があります

何が違うのか（初心者向けに要点だけ）

新しいGoogleサイト：
- レイアウトが自動で整いやすい（レスポンシブ意識）
- 直感的な編集（ブロック配置）
- 共同編集・共有がわかりやすい
以前のGoogleサイト（Classic）：
- 古いUIで、機能や移行の都合で扱いが別枠
- 現在は「新しいGoogleサイト」への移行が前提になった

自分が移行対象かどうかの見分け方

以前作ったサイトを編集しようとして
- 編集画面の見た目が今と大きく違う
- 「Classic Sites Manager」「変換」などの文言が出る
  → この場合は移行対象の可能性が高いです。

移行が必要な人がやること（最短ルート）

旧サイトが残っているか確認
変換（コンバート）機能で「新しいGoogleサイト」の下書きに移す
レイアウト崩れ・リンク切れをチェック
公開し直す（公開範囲も再確認）

ポイント：移行は「変換したら終わり」ではなく、公開設定の確認が重要です。
特に社内運用だと、公開範囲が意図せず広がる／逆に見えなくなる、が起きがちです。

まず結論：Googleサイトが向いている人／向いていない人

Googleサイトは、ひとことで言うと 「素早く作れて、共有・更新がラクな“情報サイト”」 に強いツールです。
逆に、デザインや機能を作り込む“本格サイト” には不向きになりやすいです。

迷ったら、次の考え方がいちばんシンプルです。

“作る”より“運用する”が大事 → Googleサイト向き
“表現・機能の自由度”が最重要 → 別ツール向き

向いている：スピード優先・情報共有・小規模で十分なサイト

次のどれかに当てはまるなら、Googleサイトはかなり相性が良いです。

1) 最短で公開したい（とにかく早く形にしたい）

「今日中に案内ページが必要」
「まずは仮のサイトを作って、あとで情報を足したい」
「Web制作に時間をかけられない」

✅ 理由：テンプレ＋ブロック配置で、ページの骨組みがすぐ作れるためです。

2) 情報共有・共同編集が中心（更新が多い、担当が複数）

社内ポータル（手順書、FAQ、リンク集）
プロジェクトのハブ（資料、議事録、タスク導線）
イベント運営ページ（申込、日程、会場案内）

✅ 理由：共有範囲や編集権限を前提に設計されていて、「誰が更新しても破綻しにくい」 からです。
（※下書きと公開版でアクセスを分ける運用もしやすいです）

3) “Googleの中で完結させたい”（ドライブやフォーム中心で回す）

申込はGoogleフォーム
資料はGoogleドライブ
日程はGoogleカレンダー

✅ 理由：外部ツールを増やさずに “いつものGoogle”で運用 しやすいからです。

用途別の相性（ざっくり早見）

スクロールできます

目的	相性	コメント
社内ポータル／共有ハブ	◎	更新が多いほど真価が出る
イベント案内（申込・地図・日程）	◎	必要要素を載せやすい
小規模ビジネスの案内（1〜数ページ）	○	まず公開して改善が向く
採用ページ（簡易）	○	変更が多い運用に強い
しっかり集客するメディア運用	△	拡張性・施策の幅で不利になりがち

向いていない：凝ったデザイン、EC/会員制、細かなSEO制御が必須

次の要件が強い場合、Googleサイトは「作れはするけど、途中で詰まりやすい」側です。

1) デザインを細部まで作り込みたい

セクション余白や装飾をミリ単位で揃えたい
アニメーションや凝ったUIを入れたい
ブランド表現が重要（見た目の差が成果に直結）

⚠️ Googleサイトは、良く言えば“整う”、悪く言えば“自由に崩せない”ため、表現の自由度が足りないと感じやすいです。

2) EC／会員制など、機能が中心のサイトにしたい

商品販売（カート・決済・在庫）
会員登録／ログイン／マイページ
予約管理、顧客管理などの業務機能

⚠️ こうした機能は、標準機能だけで完結させるのが難しく、外部サービス連携前提になります。
「サイトはGoogleサイト、機能は別サービス」という形にできないなら、最初から別手段が安全です。

3) 細かなSEO制御が必須（施策の自由度が必要）

記事を量産して検索流入を伸ばすメディア型
構造化データや細かなメタ制御を積極的に使いたい
SEOのテクニカル施策が重要な領域

⚠️ Googleサイトでも“基本はできます”が、ツールとしての思想は 「運用しやすい情報ページ」寄り。
SEOを主戦場にする場合は、施策の幅が広い環境（例：WordPress等）の方が進めやすいことが多いです。

判断チェックリスト（Yes/Noで3分診断）

次のチェックで、直感的に判断できます。
Yesが多いほどGoogleサイト向きです。

目的・成果のタイプ

[ ] とにかく早く公開したい（スピード優先）
[ ] 情報共有が主目的（説明・手順・資料集約）
[ ] ページ数は少なめで十分（1〜10ページ程度から開始）

運用体制

[ ] 更新担当が複数いる／今後増える可能性がある
[ ] 更新頻度が高い（月1以上の見直しがある）
[ ] 退職・異動があっても回るように “属人化を避けたい”

必要機能・拡張性

[ ] 機能は「問い合わせ」「申込」「資料閲覧」程度で足りる
[ ] EC・会員制などの複雑機能は不要（または外部サービスでOK）
[ ] デザインは シンプルで問題ない（見やすさ重視）

SEO・集客の前提

[ ] 検索集客は「最低限できればよい」or 別施策（SNS/広告/名刺URL）が中心
[ ] SEOのために、構造化データや細かな制御までやる予定はない

判定（目安）

Yesが8〜12個：Googleサイトで始める価値が高い 👍
Yesが4〜7個：用途を絞ればアリ（社内用／イベント用など）
Yesが0〜3個：別ツールを先に検討した方が早い（作り直しを避けやすい）

迷ったときの最終判断（超シンプル）

1週間以内に公開したい → Googleサイトで試作
半年以上“資産として育てたい” → 拡張性がある環境も比較してから決定

Googleサイトで“できること”一覧（機能を用途別に整理）

ここでは、Googleサイトの機能を「何ができるか」だけでなく、どんな場面で役立つか（用途）に寄せて整理します。
初心者でも「自分がやりたいこと＝どの機能を使えばいいか」がすぐ結びつくようにまとめます。

ページ作成とサイト構造（ナビ、階層、複数ページ運用）

Googleサイトは、ページを増やして「小さなサイト構造」を作れます。ポイントは “運用しやすい導線作り” が標準でできることです。

できること（サイト構造まわり）

複数ページを作成して、メニュー（ナビ）で移動できる
ページをドラッグして、並び替えや階層化（サブページ化）ができる
サブページは最大5階層まで作れる（深すぎる構造にも一応対応）
ページごとにURLの末尾（カスタムパス）を設定できる
例：/about、/contact のようにわかりやすく整理
ページをメニューから非表示にできる（ただしリンクを知っていればアクセスは可能）
“ページ”とは別に、メニュー内に外部リンクやメニュー見出し（セクション）を追加できる
→「社内ルール」「申請」「FAQ」などをカテゴリっぽく整理しやすい

初心者が失敗しにくい構造の作り方（ミニ指針）

まずは トップ＋下層3〜6ページくらいで開始（増やすのはあとでOK）
階層は深くしすぎない（深くなるほどURLが長くなり、管理が難しくなる）
“メニューから非表示”ページは、用途を決めて限定運用（例：お礼ページ、限定案内）

デザイン（テーマ、配色、フォント、ヘッダー画像）

Googleサイトのデザインは、細部を作り込むというより 「破綻しない統一感を、短時間で作る」 のが得意です。

できること（見た目の基本）

テーマを選んで、全体の雰囲気を揃えられる
テーマ上で、配色・背景・テキストの見え方をまとめて調整できる
文字スタイル（タイトル、見出し、本文など）のフォントや書式をある程度統一できる
ヘッダー画像の設定や、ヘッダーのサイズ（表示タイプ）を選べる
必要に応じて、フッターを付けて共通情報（連絡先、注意事項など）を固定できる

もう一歩“それっぽく”するコツ（初心者向け）

配色は 2色までに絞る（メイン＋アクセント）
ヘッダー画像は「情報が読みやすい」ものを優先（派手さより視認性）
文字サイズの強弱は 見出しで作る（装飾を増やしすぎない）

💡 Googleサイトは、テーマに加えて「ボタン」「区切り線」「リンク」「画像カルーセル」などの見た目もまとめて整えられるため、統一感を崩しにくいのが強みです。

埋め込みと連携（ドライブ、フォーム、カレンダー、地図、YouTube など）

Googleサイトの大きな強みがここです。
“中身はGoogle（ドライブ等）に置き、サイトで見せる” という運用ができます。

できること（Google連携）

Googleドライブのファイルをそのまま載せられる
- ドキュメント、スプレッドシート、スライドなど
Googleフォームを埋め込める（問い合わせ／申込／アンケート）
Googleカレンダーを載せられる（イベント日程、予約枠の共有にも便利）
Googleマップを載せられる（アクセス案内が簡単）
YouTube動画を載せられる（説明動画、手順動画など）
Googleグループを埋め込むなど、チーム向けの使い方も可能

できること（外部コンテンツの埋め込み）

URLを貼って、外部ページを埋め込み表示できる
埋め込みコードでも挿入できる（※コードには条件がある）
さらに、埋め込みを「ページの中」だけでなく、埋め込み専用の1ページとして作ることもできる
→ 例えば「予約ページ」「外部サービス画面」を1ページ丸ごと表示、など

見落としがちな重要ポイント（権限）

埋め込んだドライブ資料は、サイト側を公開しても 資料側の共有権限が合っていないと閲覧できません。

✅ 公開サイトで見せたいなら「資料の共有設定」も合わせる
✅ 社内限定なら「組織内のみ」など、意図した範囲に揃える

さらに便利な点として、サイト内検索で 埋め込んだドライブ資料の中身も探せるケースがあります。
（社内ポータル用途だと体感が大きいポイントです）

共同編集（編集者追加、同時編集、変更履歴の考え方）

Googleサイトは「1人で作る」より、複数人で回す設計が得意です。
“担当が変わっても運用が止まりにくい”のが強みになります。

できること（共同編集）

編集者を追加して、複数人で同時編集できる
編集中に、相手がどこを触っているか追える機能がある（迷子になりにくい）
編集権限の調整ができる（不要な人は外す／オーナー変更も可能）
「編集者が勝手に公開・権限変更できない」 ように制限できる
→ 事故防止にかなり効きます

※注意（初心者が混乱しやすい点）
非Googleアカウントの編集者は「下書きの閲覧」はできても、編集はできないなど挙動が異なる場合があります。チーム運用は Googleアカウント前提で考えるとスムーズです。

できること（変更履歴＝バージョン管理）

変更履歴（バージョン履歴）を見られる（誰が何を変えたか辿れる）
過去の状態に復元できる（サイト全体／ページ単位の復元も可能）
バージョンに名前を付けて、節目を管理できる

初心者におすすめの運用ルール（例）

大きな更新前に、履歴に「2026-01 改定前」など名前を付ける
公開ボタンを押す担当を決める（公開事故が激減します）

公開（一般公開／限定公開／組織内公開の切り替え）

Googleサイトは「作る」と「公開する」を分けて考えられます。
公開の仕組みを理解すると、迷いが一気に減ります。

できること（公開の基本）

公開前にプレビューして、PC/スマホ表示を確認できる
公開時に、サイトの公開URL（アドレス）を設定できる
公開範囲を切り替えできる
- 一般公開：誰でも見られる
- 限定公開：指定した人・グループだけ見られる
- 組織内公開：仕事/学校アカウントでは、組織内だけに限定できる選択肢が出る場合がある

検索エンジンとの関係（“できること”の範囲で整理）

一般公開の場合、検索に出る可能性はあります
ただし、公開設定で「検索エンジンに表示しないよう依頼する」オプションがあり、“依頼”はできる（※保証ではない）

閲覧体験を整える機能（地味に便利）

見出しへ飛べるアンカーリンクを表示する／しないを切り替えられる
→ 長いページの読みやすさが上がります
公開されたサイトにサイト内検索を付けられる（情報が増えても探しやすい）

Googleサイトで“やりにくい/できないこと”と回避策

Googleサイトは「速く作って、みんなで更新する」用途に強い一方で、自由度や拡張性が必要な場面では壁が出ます。
ここでは、初心者がハマりやすい“つまずきポイント”を先に知って、現実的な回避策までセットで整理します。

デザイン自由度の壁（CSS直編集・細かなレイアウトの限界）

やりにくいこと

サイト全体に対して、任意のCSSを当てて細部を調整する（ナビの影、余白のpx指定など）
“この位置にこの要素を固定したい”のような、ミリ単位のレイアウト制御
独自アニメーションや、凝ったUI（高度な表現）を標準機能だけで作る

Googleサイトのデザインは、基本的に テーマ（配色・フォント・部品の見た目）＋ブロック配置で整える思想です。
そのため「自由に崩せる＝自由に作れる」タイプの制作とは方向性が違います。

回避策（現実的にうまくいく順）

テーマ設計を先に固める（最優先）
- 配色は メイン＋アクセントの2色に絞る
- 見出しの段（H2/H3…）でメリハリを作り、装飾を増やしすぎない
- ボタン・区切り線・リンクなどの“部品”は、テーマ側で統一する
“作り込みたい部分”だけ外部で作って埋め込む
- 例：料金表、動く図解、予約ウィジェット、比較UIなど
- 外部で作ったページやウィジェットを埋め込み（iframe）にして、Googleサイトには「見せる枠」として置く
デザインで勝負するサイトは、最初から別の土俵を選ぶ
- 会社・ブランドの世界観が成果に直結するなら、WordPress / STUDIO / Wix 等の方が、結果的に早いケースが多いです

高度な機能の壁（EC、会員、DB連携、複雑な動的処理）

やりにくいこと

EC（カート・決済・在庫・注文管理）をサイト内で完結
会員制サイト（ログイン、権限ごとの表示切替、マイページ）を本格運用
DBを前提にした機能（検索・絞り込み・一覧自動生成）を、柔軟に構築
サイト側で複雑な動的処理（高度なJSアプリ）を安定稼働

Googleサイトは“Webアプリ基盤”というより、情報を整理して見せるためのツールです。
埋め込みで拡張はできますが、動作しない/制限が出るケースもあるので、重要機能ほど「外部サービスに任せる」発想が安全です。

回避策（目的別のおすすめパターン）

A) 物販・決済をしたい場合

Googleサイトは「商品説明・導線」に徹し、
購入（決済）はECサービス側で完結させるのが王道です。
具体例
- 商品ページ → 「購入ボタン」または「購入ページへのリンク」
- 申込・問い合わせ → Googleフォーム（受付）＋自動返信

B) 会員制っぽく見せたい場合（簡易）

できる範囲：限定公開で「見られる人」を絞る（共有ベースの考え方）
できない範囲：ログイン後のマイページ、会員ランク別コンテンツ、課金連動など
→ ここが必要なら、会員基盤があるサービスを選ぶ方が早いです。

C) データを扱いたい場合（DBの代替）

スプレッドシート＋フォームで「疑似DB」運用は可能
ただし、検索・絞り込み・表示制御の自由度は限定的になりやすいです。
データが増える/要件が複雑になるなら、
最初からDBやアプリ基盤（業務アプリ系）に寄せた方が後悔しにくいです。

D) 動くコンテンツを載せたい場合（埋め込み活用）

“動く部分”は外部で完結させ、Googleサイトは表示枠として使う
重要：埋め込む側のページが https対応・iframe埋め込み許可などを満たさないと表示できないことがあります

バックアップ・移行の壁（いざという時の復元設計）

起きやすい誤解

「サイトを丸ごとバックアップして、あとで同じように戻せるはず」
→ 実際は、復元の考え方を先に設計しておく方が安全です。

Googleサイト側でできる“復元”

バージョン履歴から、過去の状態に戻せます（サイト単位／ページ単位）
大きく編集する前に「節目の版」を作っておくと、復元がラクになります

“バックアップ”として現実的な選択肢

Google Takeout（またはDriveのエクスポート）でアーカイブを作る
ただし、これは主に「手元保管」「監査」「万が一の参照」向けになりやすく、
そのまま同じ形で“再インポート”できるとは限らない点に注意が必要です。

初心者向け：失敗しにくい復元設計（おすすめ運用）

変更前に、バージョン履歴で節目を作る（例：月次更新前）
画像や資料は、サイト内に散らさず Drive側で整理してから埋め込む
→ サイトの引継ぎ・差し替えがラクになります
URLやページ構成を変える前に、簡単な「サイト構成メモ」を残す
- 主要ページ一覧
- 重要リンク（申込・問い合わせ）
- 更新担当者

旧版（Classic）を使っていた人の注意点

旧版のサイトは、新しいGoogleサイトへの変換やアーカイブ出力など、扱いが別になります。
旧サイト資産が残っている人は、まず「どこに何が残っているか」を棚卸しするのが先決です。

「最初から別サービスにすべき」代表パターン

次のどれかに当てはまるなら、Googleサイトで頑張るより、最初から別サービスを選ぶ方が失敗しにくいです。

デザインが成果に直結する
- ブランディング重視（コーポレート、採用、LPでCVを取りたい）
EC・会員・予約など“機能が主役”
- カート、決済、会員権限、マイページ、注文管理が必須
SEOを主戦場にして、施策を積み上げたい
- メディア運用（記事量産・内部施策・構造化など）で伸ばす前提
大規模運用が前提
- ページが増え続ける、複数サイト展開、権限設計が複雑
バックアップ/移行を厳密に求められる
- 規制業種、監査要件、長期保全、厳格な復元プロセスが必要

迷ったときの結論はシンプルです。
「情報共有の箱」ならGoogleサイト、「本格的に作り込むなら別サービス」が基本方針になります。

最短で公開する：基本の作り方（初心者でも迷わない手順）

「何となく触っていたら迷子になった…」を防ぐために、先に決める → 作る → 整える → 公開するの順で進めます。
この順番にすると、後戻り（作り直し）が最小になります。

0) 事前準備：目的・ターゲット・必要ページを先に決める

ここをサボると、途中でページが増殖して「どこに何があるか分からないサイト」になりがちです。
3分だけでいいので、先に型を作ります。

サイトの目的を1行で言えるようにする（例：問い合わせ獲得／社内周知）

まずは、次のテンプレで1行を書いてください（メモでOK）。

誰に：
何を：
してほしい（ゴール）：

例）

個人：初めて来た人に「実績」を見せて、問い合わせにつなげたい
小規模ビジネス：サービス概要と料金目安を伝えて、相談フォームへ誘導したい
社内：業務手順とリンクを集約して、質問の往復を減らしたい

この1行が決まると、必要ページも自然に決まります。

最低限のページ構成テンプレ（1ページ型／複数ページ型）

1ページ型（最短公開向け）
「とりあえず公開したい」「情報量が少ない」ならこれが最速です。

ファーストビュー（何のページか）
概要（誰向け／何が得られる）
特徴・実績（信頼材料）
よくある質問（不安つぶし）
問い合わせ／申込（ゴール）

複数ページ型（運用向け）
更新が増える・社内で回すなら、最初から分けた方がラクです。

トップ（全体の入口）
サービス/概要（説明）
料金・プラン（目安）
実績・事例（信頼）
FAQ（問い合わせ削減）
お問い合わせ（ゴール）
（社内なら）手順／申請／資料／リンク集

✅ 迷ったら「1ページ型で公開 → 後から複数ページへ拡張」が失敗しにくいです。

1) 新規サイトを作成（テンプレ or 白紙）

Googleサイトのトップから、新しいサイトを作ります。
ここでは「何で始めるか」を決めるだけでOKです。

テンプレを選ぶ基準（“見た目”より“用途”で決める）

テンプレは「完成形」ではなく、ページの型（配置の雛形）です。
選ぶ基準はシンプルに次でOKです。

最短で公開したい → 既存テンプレ（近い用途のもの）
運用しながら作りたい／迷いを減らしたい → テンプレ
細部はあとで自分で決めたい → 白紙（Blank）

迷ったら、まずはテンプレで始めて、不要なブロックを消す方が速いです。

サイト名・ロゴ・ファビコンの整え方

初心者が最初に整えるべきは、凝ったデザインではなく“識別できる状態”です。

サイト名：短く、用途が伝わる名前に
例）「採用情報」「〇〇プロジェクト」「手順・申請ポータル」
ロゴ（任意）：会社・チーム運用なら設定推奨
ロゴがない場合は、無理に入れずサイト名を明確に
ファビコン（任意）：運用サイト（社内ポータル等）だと地味に便利
タブで見分けやすくなり、開きっぱなしでも迷いません

ポイント：これらは「公開後に直してもOK」ですが、サイト名だけは早めに確定しておくと管理が楽です。

2) ページを増やして構造を作る（迷子を作らないナビ設計）

本文を書き始める前に、ページの骨組みを作ります。
ここでサイト全体の見通しが決まり、あとが一気にラクになります。

ページ名の付け方（検索・導線・運用を意識）

ページ名は、装飾せずに中身が想像できる日本語が最強です。

良い例：
- 「料金」「お問い合わせ」「よくある質問」「アクセス」「手順」「申請」
迷う例：
- 「概要」「詳細」「サービス」など、意味が広すぎる言葉

ちょっとしたコツ👇

迷ったら「読者が探す言葉」を優先（例：「連絡先」より「お問い合わせ」）
社内向けは「動詞＋目的語」も強い（例：「申請する」「アカウントを作る」）

階層ルール（増やしても破綻しないコツ）

階層（サブページ）は便利ですが、深くしすぎると運用で詰まります。
初心者はこのルールで十分です。

原則：2階層まで（トップ → 下層）で回す
例外：社内ポータルなど、カテゴリが明確な場合だけ3階層目
追加する前に「このページ、FAQに吸収できない？」を1回考える

おすすめの分類（社内ポータル向け）

手順（How to）
申請（フォーム・依頼）
資料（テンプレ・規程）
FAQ（よくある質問）
お知らせ（更新情報）

3) コンテンツを配置（ブロック/セクションで“読ませる”）

ここから本文を入れていきます。
Googleサイトは「文章を詰め込む」より、セクションで分けて読みやすくするのが得意です。

よく使うコンテンツブロック（見出し・文章・画像・ボタン）

初心者は、まずこの4つだけ覚えれば十分です。

見出し：内容の区切り（読みやすさが一気に上がる）
文章：短めの段落＋箇条書き中心がおすすめ
画像：スクショ、図、ロゴ、事例画像など
ボタン：行動導線（問い合わせ、申込、資料DLなど）

配置のコツ（読みやすさ重視）

1セクション＝1メッセージ（言いたいことは1つ）
文章は3〜5行で改行、箇条書きを混ぜる
ボタンはページ内に1〜3個（多すぎると迷います）

埋め込み（フォーム/地図/動画/外部ページ）の使い分け

埋め込みは「便利な反面、増やすと重くなる」ことがあります。
用途で使い分けるとスッキリします。

フォーム：問い合わせ、申込、社内申請（ゴールに直結）
地図：アクセス案内（店舗、会場）
動画：手順の説明、サービス紹介（文章を減らせる）
外部ページ埋め込み：予約ツール、別サービスの画面など（必要最小限に）

さらに、外部ページを「ページ丸ごと」で見せたい場合は、フルページ埋め込みという選択もあります（用途がハマると強力です）。

フォーム：問い合わせ・申込・社内申請での設計ポイント

フォームは作って終わりではなく、運用で揉めない設計が大事です。

最低限のチェック（初心者向け）

入力項目は最小（多いと離脱します）
目的が違うならフォームを分ける
例）「問い合わせ」と「見積もり」は別フォーム
送信後に“次にやること”を表示
- 例）「2営業日以内に返信します」「必要資料はこちら」

地味に効くポイント

社内申請は「申請の前提条件」「よくある差し戻し理由」を先に書くと、やりとりが減ります。

スプレッドシート：一覧・FAQ・更新情報の“準DB化”

スプレッドシートは、更新しやすい一覧に向いています。

使いどころ例

更新履歴（いつ何を変えたか）
FAQ一覧（質問と回答を表で管理）
リンク集（カテゴリ別に一覧化）
担当者一覧（窓口の可視化）

運用のコツ

シート側は「編集担当」を決める（誰でも編集は事故が増えがち）
サイト側は「見せる」だけにして、データの更新はシートで行う

4) テーマと見た目を整える（最小コストで“それっぽく”）

見た目をいじり始めると沼りやすいので、ここはルールで時短します。
目的は「おしゃれ」ではなく、読みやすく、迷わないことです。

配色とフォントの決め方（ブランド/可読性の優先順位）

おすすめの優先順位は次の通りです。

可読性（読みやすさ）
統一感（ブレない）
ブランドっぽさ（余裕があれば）

やり方（初心者向け）

テーマはまず1つ選んで固定
色は2色まで（メイン＋アクセント）
フォントは変えすぎない（統一が正義）

ヘッダー画像・セクション余白・視線誘導の基本

最短で整えるなら、この3点だけ意識すれば十分です。

ヘッダー画像は「文字が読める」ものに（情報が主役）
セクションを増やしすぎない（1ページに詰め込まない）
ボタンは“次にしてほしいこと”だけ置く
例）「お問い合わせ」「申し込む」「資料を見る」

✅ 1ページの中で「説明 → 納得 → 行動」が自然に流れるように配置すると、成果につながりやすいです。

5) 公開して共有（公開範囲と権限を先に固定）

最後に公開です。初心者が一番ミスしやすいのが公開範囲なので、ここは慎重に。

一般公開／限定公開／組織内公開：どれを選ぶべきか

目的別のおすすめはこうです。

一般公開：誰でも見てよい（店舗案内、イベント告知、簡易LPなど）
限定公開：特定の人だけ（顧客向け資料、限定案内など）
組織内公開：社内ポータル、学校内向け（Workspace環境で出ることが多い）

迷ったら…

外部に見せないなら、まず限定 or 組織内にして、必要になってから一般公開に切り替えるのが安全です。

公開後の更新フロー（下書き→確認→公開の型）

更新が始まると、運用ルールがないサイトはすぐ崩れます。
最小限の型を作っておくと、ずっと楽になります。

おすすめの最小フロー

編集（下書き状態で更新）
確認（別の人が軽くチェック）
公開（担当者がPublish）

運用の小ワザ

大きな更新の前に「節目」を作る（後で戻しやすくなります）
公開担当を1人決める（事故が激減します）
更新頻度が高いなら「更新ルール」ページを1つ作る（誰が見ても迷わない）

社内ポータル・プロジェクトサイトで成果を出す情報設計

Googleサイトで社内ポータルを作るときの失敗パターンは、だいたいこの2つに集約されます。

「情報はあるのに見つからない」
「資料が増えるほど散らばって混乱する」

ここでは、初心者でも再現しやすい形で、トップページ設計 → ページ構成 → FAQ設計 → 全社展開のルールまでを一気につなげます。

「探せない」「散らばる」を潰すトップページ設計

トップページは「会社のホームページ」ではなく、社内の“作業開始画面”にします。
理想は、社員がトップを開いた瞬間に次のどれかが即決できる状態です。

今すぐやる手続きに行く（申請・依頼）
目的の情報を探す（規程・手順・テンプレ）
直近の更新を確認する（お知らせ・変更点）

トップページの鉄板レイアウト（迷子を減らす型）

1) 最上段：クイック導線（最重要）
ここは“3〜7個”に絞るのがコツです。

よく使う手続き（例：アカウント申請、経費精算、稟議）
よく使う資料（例：ロゴ、テンプレ、規程）
よくある質問（FAQ）
困ったとき（問い合わせ窓口）

2) 探す：検索と索引の置き場
「探せない」を潰すために、検索導線を目立つ場所に置きます。

サイト内検索（使える場合は最優先で活用）
カテゴリ別の索引（手続き／規程／テンプレ…）
“部署別・業務別”の入口（必要な会社だけ）

※検索を強くする小ワザ

ページ名を「人が探す言葉」に寄せる（例：問い合わせ先 → お問い合わせ）
1ページの冒頭に「結論」を置く（検索結果から開いても迷いにくい）

3) 知る：更新情報（新着・変更点）
社内ポータルは“更新があるほど”価値が上がるので、更新情報をトップに固定します。

お知らせ（新着3〜5件）
重要な変更（規程改定、申請フロー変更など）
今月のよくある問い合わせ（FAQ誘導に使える）

4) 信頼：運用情報（E-E-A-Tの社内版）
社内でも「この情報は正しい？」が起きます。そこで、各ページに最低限これを入れます。

最終更新日
担当部署／責任者（窓口）
関連する一次資料（規程原本、申請フォームなど）へのリンク

これだけで「古い情報が残り続ける問題」「誰に聞けばいいか分からない問題」が激減します。

トップページに置くべき“箱”の例（そのまま使える）

よく使う手続き（ボタン6個まで）
よく使うテンプレ（3カテゴリまで）
FAQ（人気の質問5つ＋“もっと見る”）
お知らせ（新着3件）
困ったとき（窓口・問い合わせ・緊急連絡）

区分	役割	置くものの例
トップ	入口と導線	クイックリンク／検索／更新情報
手続き	“やる”を完結	申請フロー、必要書類、期限
規程	根拠の保管	就業規則、経費、セキュリティ
申請	実行導線	Googleフォーム／外部申請ツールへのリンク
FAQ	問い合わせ削減	よくある質問、エラー対応、差し戻し理由
テンプレ置き場	作業の標準化	稟議、議事録、見積依頼、ロゴ、資料雛形

ナレッジ/FAQサイトの作り方（問い合わせを減らす構造）

FAQが機能しない原因は「情報量が少ない」より、構造が悪いことが多いです。
ポイントは、FAQを“辞書”ではなく、問題解決の導線として設計することです。

問い合わせを減らすFAQの型（1ページの構成）

各FAQページは、次の順にすると解決率が上がります。

結論（まず一言）：できます／できません／この手順です
手順（3〜7ステップ）：画面操作は箇条書き
つまずきポイント：よくある原因と対処
必要な場合だけ問い合わせ：窓口＋必要情報（スクショ、エラー文など）

例（社内向けの強い書き方）

結論：申請はこのフォームから。期限は毎月25日です。
手順：①〜⑤
つまずき：差し戻し理由TOP3
問い合わせ：添付すべき情報（これがあると往復が減ります）

FAQを増やすときの“分類ルール”（散らばり防止）

FAQが増え始めたら、分類を固定します。

業務別（経費／勤怠／IT／総務）
状況別（新入社員／異動／退職／在宅勤務）
トラブル別（ログインできない／権限がない／表示されない）

さらに効く工夫として、トップに「よく見られる質問」を置き、下層でカテゴリ分類に分けると、探す時間が短くなります。

FAQのネタは“現場”にあります（作る順番）

初心者でも失敗しにくい作り方はこれです。

まず、直近1〜2か月の問い合わせ（メール/チャット）を10件だけ集める
「同じ質問」を1つにまとめて、FAQ化
差し戻しが多い申請から先に整備（効果が出やすい）

💡 成果が見えやすい指標

問い合わせ件数の減少
差し戻し回数の減少
“窓口への到達前に解決”した割合（体感でもOK）

全社展開のコツ（テンプレ統一・作成権限・公開ルール）

社内ポータルは、全社に広げるほど「統一ルール」がないと崩れます。
ここでは、最低限のガバナンス（運用の決め事）だけに絞ります。

1) テンプレ統一（増やしても崩れない）

ページを量産すると、見た目以上に困るのが「書式バラバラ問題」です。
そこで、最初にテンプレを固定します。

ページ冒頭に必ず置く：目的／対象者／最終更新日／担当
見出し階層（H2→H3）を統一
“手続きページ”は同じ並び（必要書類→手順→期限→FAQ）

おすすめ：代表的なページを3つだけテンプレ化

手続きページテンプレ
規程ページテンプレ
FAQページテンプレ

2) 作成権限（事故が起きない編集体制）

全社展開で多い事故はこれです。

誰かが誤って公開範囲を変える
誰かが勝手に公開して古い手順が残る
担当が退職して更新できなくなる

回避するための“最小ルール”

オーナー（管理者）を2名以上にする（属人化防止）
編集者は必要最小限にし、公開・権限変更は制限する
公開担当を決める（下書き→確認→公開）

3) 公開ルール（公開範囲を固定する）

社内ポータルでは「基本は社内限定」です。公開範囲は次の考え方が安全です。

社内だけ：組織内限定（可能な環境） or 限定公開
外部共有が必要：専用サイトを分ける（社内ポータルと混ぜない）

加えて、公開運用の型を作ります。

重大変更は「更新履歴」に残す（いつ・何を・なぜ）
月1回、棚卸し（古いページを削除/統合）
大きな改定の前は履歴を残して戻せるようにする

公開範囲・権限・共同編集（セキュリティと事故防止）

Googleサイトで一番起きやすい事故は、「公開範囲の設定ミス」と「編集権限が広すぎる」です。
ここでは、初心者でも迷わないように「役割の分け方 → 外部共有の確認 → 変更の戻し方」を“型”として整理します。

権限の種類（閲覧者／編集者／オーナー）と責任分界

Googleサイトは、ざっくり言うと 「作る人（編集）」「見る人（閲覧）」「管理する人（オーナー）」に分かれます。
まずは責任（事故が起きたときに誰が止めるか）を分けるのが重要です。

スクロールできます

役割	できること	典型的な責任（おすすめ）
閲覧者（Published viewer）	公開済みのサイトを見る	情報の参照・リンク先の利用
編集者（Editor）	下書き含め編集する（権限設定次第）	コンテンツ更新（文章・画像・ページ作成）
オーナー（Owner）	共有設定・権限・所有者変更などを管理	公開範囲の管理、事故防止ルール、復元判断

事故が減る“最小ルール”

オーナーは最低2人（属人化防止）
編集者は必要最小限（増やすほど事故率が上がる）
公開（Publish）に関する操作は、できる限りオーナーが握る

編集者に「やらせない」設定が最重要

Googleサイトには、オーナーが 「編集者が公開や権限変更をできない」ように制限する設定があります。
これを入れるだけで、事故の大半（勝手に公開／共有範囲変更／編集者追加）が止まります。

共同編集の注意点（意外とハマる）

Googleアカウントでない編集者は、下書きを見られても編集できないなど制限が出る場合があります（運用は原則Googleアカウント前提がスムーズ）。
公開版の閲覧者（Published viewer）は、公開されるまで内容が見えない前提で設計すると混乱が減ります。

外部共有のチェックポイント（意図しない公開を防ぐ）

公開事故は「最後の1分の確認」で防げます。
公開前に、次の順でチェックしてください。

1) 公開版の公開範囲を先に固定する

公開範囲は、基本的にこの2択が軸です（仕事/学校アカウントは追加選択肢が出ることがあります）。

Restricted（制限付き）：指定した人・グループだけ閲覧
Public（公開）：誰でも閲覧（一般公開）

⚠️ 初心者の安全策
迷ったら Restrictedで公開 → 必要になったらPublicに変更 が一番事故が少ないです。

2) 下書き（Draft）と公開版（Published）を分けて考える

Googleサイトは「作業中の下書き」と「公開されているページ」が別物です。
共有設定でも Draft と Published site を分けて調整できます。

Draft：編集者・関係者だけに限定（基本これでOK）
Published：公開範囲（Restricted/Public）を明確にする

この分離ができていると、「編集中の内容が外に見えた」系の不安がほぼ消えます。

3) “公開できる人”を絞る（最重要の事故防止）

次の設定がONだと、編集者が

公開（Publish）
権限変更（閲覧範囲を変える）
新しいメンバー追加
をできてしまうケースがあります。

対策：オーナー設定で、編集者にこれらをさせない（チェックを外す）
→ これが“事故防止の本丸”です。

4) 埋め込み資料（Drive/フォーム等）の権限は別管理

よくある落とし穴がこれです。

サイトを公開しても、埋め込んだDriveファイルの共有権限が合っていないと見えない
逆に、資料だけ誰でも見える設定になっていて、サイトより広く公開されてしまうこともある

対策（シンプル）

サイトの公開範囲と、埋め込み資料の共有範囲を一致させる
「公開時に、埋め込み資料の共有を合わせる」ことを手順に入れる

5) 検索エンジンに出したくないときの考え方

公開（Public）にした場合、検索に出る可能性があります。
Googleサイトには「検索エンジンに表示しないよう依頼する」設定がありますが、“依頼であり保証ではない”点に注意が必要です。

本当に外部に見せたくない → そもそもPublicにしない（Restricted/組織内）
Publicだけど検索に出したくない → 依頼設定を使いつつ、運用上も注意（URL拡散など）

公開前の3分チェックリスト（そのまま使えます）

[ ] Published site が Restricted / Public のどちらか意図通り
[ ] Draft は関係者だけ（必要以上に開いていない）
[ ] 編集者が「公開・権限変更・追加」をできない設定になっている
[ ] 埋め込みDrive資料の共有範囲が、サイトと一致している
[ ] 公開後、別ブラウザ（シークレット等）で表示確認した

変更履歴の見方と“戻し方”のルール化

共同編集の安心材料が 変更履歴（Version history）です。
ただし、見られる人・戻せる人・戻し方を決めておかないと、いざという時に混乱します。

まず前提：履歴を見られるのは誰？

変更履歴を閲覧するには、基本的に編集権限が必要です。
つまり、「閲覧者」は困ったときに自分で戻せません。ここが責任分界の根拠になります。

“戻し方”は2種類ある（使い分けが大事）

サイト全体を戻す：広範囲に壊れた／大規模変更の失敗
特定ページだけ戻す：誤って削除した／そのページだけ崩れた

復元後は、公開サイトに反映させるために再公開（Publish）が必要になるケースがあるため、公開担当の運用とセットにします。

事故が起きない「履歴運用の型」

おすすめは、次の3つだけルール化です。

大きな変更の前に「版に名前を付ける」
例：2026-01-18 公開前（手順改定）
→ いざ戻すときに迷いません。
公開フローを固定する（下書き→確認→公開）
- 編集者：下書き更新
- 確認者：内容チェック
- 公開担当（オーナー推奨）：Publish
“戻す判断”をオーナーに寄せる
- 戻す（復元）は影響が大きいので、勝手に戻さない
- 迷ったら「ページ単位で戻す」から試す（被害が小さい）

よくある失敗と対策

「直したつもりが公開されてない」
→ 公開と下書きは別。更新後にPublishが必要な運用にする
「勝手に戻されて、変更が消えた」
→ 復元できる人（編集者/オーナー）と手順を決める。復元前に版名を付ける

独自ドメイン設定とURLの考え方（失敗しやすい所を先回り）

独自ドメインは「見た目を整える最後の仕上げ」になりがちですが、実際は 公開範囲・権限・埋め込み・運用ルールに影響します。
ここでは、つまずきやすい点を先に潰しながら、最短で安定運用できる形にまとめます。

標準URLと独自ドメインの違い（何が変わる？）

標準URL（GoogleのURL）のイメージ

Googleサイトを公開すると、基本は sites.google.com/ から始まるURLが付きます。
速くてラク。DNS不要。まずはこれで運用を開始できます。

独自ドメイン（自分のURL）のイメージ

www.example.com のように、会社や個人で保有するドメインに紐付けられます。
覚えやすい・名刺や資料に載せやすい・ドメインから“公式感”が出るのがメリットです。

「何が変わるか」を先に整理（重要）

独自ドメインにすると、URLが変わるだけでなく、次のような違いが出ます。

所有者（オーナー）だけがドメイン接続できる（編集者では不可）
反映に時間がかかる（DNS反映＋証明書発行の都合）
Googleアカウント前提の一部機能が動きにくくなる場合がある
（例：Googleアカウント認証が絡む挙動、埋め込みの一部など）
公開範囲が“外部公開”になっていないと、独自ドメインURLで見えない／標準URLへ戻されることがある

つまり、独自ドメインは「作って終わり」ではなく、運用設計とセットで考えると事故が減ります。

事前準備：ドメイン所有権・DNS・HTTPSの基礎

独自ドメインで詰まる原因の9割は、ここが曖昧なまま進むことです。
最低限、次の3つを押さえるだけで失敗率が大きく下がります。

1) ドメイン所有権（＝DNSを触れる権限）

ドメインは「買った人」ではなく、DNSレコードを編集できる人が強いです。
社内なら「誰がDNSを管理しているか」を先に確認しておきます。

2) DNSの基本（CNAMEが中心）

Googleサイトの独自ドメインは、一般的に サブドメイン（例：www）をCNAMEで向ける運用が基本です。

例：www を ghs.googlehosted.com に向ける（CNAME）
DNSには反映待ち（数分〜最大1〜2日程度）が起きます

💡 まずは “wwwあり” を通すのが鉄則

example.com（wwwなし＝ネイキッドドメイン）まで完璧にやろうとすると難易度が上がります。
先に wwwを成功させてから、必要なら example.com → www.example.com の転送や追加設定を検討するのが安全です。

3) HTTPS（SSL証明書）の考え方

Googleサイトの独自ドメインは、通常 証明書（HTTPS）が自動で用意されます。
ただし、証明書は“自分で持ち込む”タイプではなく、発行・反映に時間がかかることがあります。

⚠️ 盲点：CAAレコード

DNS側で「この認証局の証明書しか発行させない（CAA）」の制限をかけていると、証明書が作れず詰まることがあります。

事前に揃えるもの（チェック用ミニ表）

スクロールできます

用意するもの	具体例	つまずきポイント
ドメイン	example.com	DNS編集権限がない
DNS管理画面アクセス	レジストラ/Cloud DNS等	CNAMEの競合がある
公開済みサイトURL	標準URL	そもそも未公開だと進まない
公開範囲の方針	公開/限定/組織内	“外部閲覧不可”だと独自URLが効かないことがある

設定手順の分岐（Workspace管理者がいる/いない）

独自ドメイン設定は、環境によって「入口」が変わります。
迷いやすいので、まずはどちらかを選んでください。

A) Workspace管理者がいる（会社・学校アカウント）

この場合、管理者（Admin Console）側でURLマッピングする流れになることが多いです。

やること（全体像）

サイトを公開（公開範囲も確認）
管理者が Admin Console で「新しいGoogleサイト」を対象に カスタムURL（Custom URL）を追加
DNSで CNAME を設定（www → ghs.googlehosted.com など）
反映待ち（最大24時間程度のことも）

ポイント（勘違いしやすい）

管理者がマッピングできるのは 基本的に“サブドメイン”（例：www）で、条件や制約があります
サイトが「組織内だけ」共有だと、独自URLではなく標準URLへ誘導されるケースがあります
（社内ポータル用途はここで混乱しやすいです）

B) Workspace管理者がいない（個人運用／自分が所有者）

この場合は、Googleサイト編集画面の 設定 → カスタムドメイン から進めるのが基本です。

やること（全体像）

サイト所有者でログインして、設定からカスタムドメイン設定開始
ドメインを入力し、案内に従ってDNSを更新
所有権確認が求められたら、表示される手順（TXT追加など）で確認
反映を待って表示確認

ポイント

「所有者だけが接続できる」ので、編集者でログインしていると詰まります
反映は時間差があるため、設定直後に見えなくても“即ミス”とは限りません

反映されない時のチェックリスト（DNS/公開状態/キャッシュ）

独自ドメインが表示されないときは、下から順に潰すと最短です。
（上からやるより、成功率が高い）

1) 公開状態（これが最優先）

公開（Published）が適切か
公開範囲が「外部閲覧OK」になっているか（必要な場合）

2) DNS（CNAMEの基本ミスを潰す）

www のCNAMEが ghs.googlehosted.com を向いているか
既存の www レコード（別CNAMEやAレコード）と競合していないか
TTLが長すぎないか（すぐ直したいときは短いほうが確認が楽）

3) “wwwなし”で見えない（ネイキッドドメイン問題）

example.com は www.example.com と別物です
まず wwwが開くことを確認し、必要なら
- レジストラの転送機能で example.com → www.example.com
- もしくはDNS/サービス側の“ネイキッドドメイン対応”を検討

4) HTTPS（証明書）待ち／失敗

証明書がまだ発行されていない（時間差）
DNSのCAA制限が原因で発行できない

5) キャッシュ（見えてないだけ）

シークレットウィンドウで確認
別端末・別回線（スマホ回線など）で確認
OSのDNSキャッシュを疑う（特にWindows）

✅ 最短の確認方法

「シークレットで www にアクセス」→ OKならDNSは概ね正しい
NGならDNSか公開範囲の問題の可能性が高いです

公開後の運用（URL変更・リンク切れ・案内ページの作り方）

独自ドメインを設定した後に事故が起きるのは、だいたい URL変更とリンク切れです。
Googleサイトは自由に作れる反面、Webサーバーのように細かなリダイレクト制御ができるとは限りません。
なので、運用ルールで守るのが現実的です。

1) URLは「変えない前提」で決める

最初に決めるべきは、URLの方針です
- 例：社外向けは www.example.com
- 社内向けは標準URL（または組織のルールに従う）
途中でドメインや構成を大きく変えると、名刺・資料・社内ドキュメントのリンクが壊れます

2) ページ構成変更のときは“案内ページ”で吸収する

もしURLが変わりそうなら、次のやり方が安全です。

旧ページを消さずに残し、冒頭に案内文を置く
- 例：「このページは移動しました。最新版はこちら →（新URL）」
旧ページはナビから外しつつ、外部リンクの受け皿としてしばらく保持

💡 これだけで「404対応」「社内リンク切れ対応」の工数が激減します。

3) ドメインを変更したい場合の基本方針

旧ドメイン → 新ドメインへの転送ができるなら、一定期間は転送を維持
できない場合は、旧ドメイン側に「案内ページ（入口）」を残すのが現実解

4) 運用を仕組みにする（おすすめ）

更新履歴（いつ何を変えたか）をスプレッドシート等で管理
重要URL（トップ・申込・問い合わせ・FAQ）だけは固定化して、変更しない運用にする

アクセス解析（Analytics等）で改善する運用サイクル

Googleサイトは「作って終わり」より、公開後に少しずつ直して成果を上げるのが向いています。
そのために、アクセス解析は“多機能に使う”より、目的に合う指標だけに絞るのがコツです。

前提として、Googleサイトは設定画面から Google Analytics（GA4）の測定ID（G-XXXX）を入力して計測できます。反映まで時間がかかる場合があるため、公開直後は焦らず「翌日以降」で確認するのが安全です。

“見るべき指標”を目的別に決める（問い合わせ／社内利用率）

アクセス解析で失敗しやすいのは「見られる数字を全部見る」ことです。
初心者は、まず KPIを1〜3個に固定してください。

目的別：おすすめ指標マップ（このまま使えます）

スクロールできます

目的	まず見る指標（1〜3個）	次に見る指標（原因分析用）	改善の当たり
問い合わせ・申込を増やす（外部向け）	キーイベント（コンバージョン）数／CTAクリック数／ユーザー数	参照元（どこから来たか）／ページ別の離脱傾向／スクロール	CTA位置、ページ構成、FAQ追加
社内ポータルの利用率を上げる（内部向け）	アクティブユーザー／閲覧数（Views）／1人あたり閲覧数	よく見られるページ／検索（使うなら）／ファイルDL・外部リンククリック	トップ導線、カテゴリ整理、検索性
問い合わせ・差し戻しを減らす（FAQ/手順）	FAQページ閲覧数／窓口リンククリック数の減少	“つまずき”ページの集中／更新前後の変化	手順の順番、例の追加、注意点の見える化
資料配布（テンプレ・規程など）	ファイルDL／関連ページ閲覧数	参照元／ページ内の導線クリック	置き場の一本化、リンクの目立たせ方

ポイントは、「成果（ゴール）」の指標 → 「原因（なぜ）」の指標の順に見ることです。

外部向け（問い合わせ）の「測り方」具体例

Googleサイトはコードを入れて細かなイベントを作り込むのが得意ではないため、現実的には次で十分です。

CTAクリックをキーイベント化
例：
- お問い合わせボタン（外部リンク／フォームへの遷移）
- mailto:（メールリンク）や tel:（電話リンク）
  → クリックが取れれば、問い合わせの“前段”が見えます
Googleフォームの場合は、二段で確認する
1. GA：フォームへ遷移したクリック数（サイト側）
2. フォーム：回答数（フォーム側）
  → 「押されたけど送られてない（離脱）」が推測できます
UTMで流入元を判別（SNS/メルマガ/社内チャット等）
URLにパラメータを付けるだけで、「何が効いたか」が見えます

社内向け（利用率）の「測り方」具体例

社内ポータルは“滞在時間が長いほど良い”とは限りません。
「迷って長い」のか「目的を達成して長い」のかが混ざるため、次の組み合わせが安全です。

アクティブユーザー（使われているか）
1人あたり閲覧数（迷子か、回遊が必要な構造か）
トップページ → 手続きページへの遷移（導線が機能しているか）
よく見られるページTOP（どこにニーズが集中しているか）

“キーイベント（コンバージョン）”の最小設計

初心者はこれだけでOKです。

外部向け：
「問い合わせ」ボタンのクリックをキーイベントにする
社内向け：
「申請フォームへ行く」クリック、「テンプレDL」をキーイベントにする（できる範囲で）

※GA4では「イベント」を重要指標として“キーイベント（旧：コンバージョン相当）”に設定できます。まずは1〜2個に絞ると、改善が速くなります。

改善の優先順位（導線→内容→信頼→見た目の順）

改善は、見た目から触ると迷走しがちです。
成果が出やすい順に、次の流れで直すのが鉄板です。

1) 導線（迷わずゴールに行けるか）

最優先は「クリックされるべき場所がクリックされているか」です。

チェック項目

トップに「よく使う導線（3〜7個）」があるか
重要ページへのボタンが、上（冒頭）と下（読み終わり）にあるか
メニュー名が分かりやすいか（抽象語が多すぎないか）

改善アイデア（効きやすい）

CTAボタンを 1〜2種類に統一（例：お問い合わせ／申し込む）
トップに「手続き」「FAQ」「テンプレ」を固定（社内向け）

2) 内容（読めば解決するか）

導線が整っても、内容が薄いと成果は伸びません。

チェック項目

冒頭3行で「誰の・何の・何が得られる」が伝わるか
手順は 箇条書き（3〜7手順）で書けているか
“よくある詰まり”が先回りできているか（FAQ/注意点）

改善アイデア

“差し戻し理由TOP3”をFAQに入れる（社内申請系で強い）
例・スクショを1つ足す（文章量を増やさず理解を上げる）

3) 信頼（この情報は正しいと言えるか）

外部向けはもちろん、社内でも信頼がないと「結局聞く」が起きます。

最低限入れると強い情報

最終更新日
担当部署／窓口
根拠リンク（規程原本、公式手順、申請フォームなど）
更新履歴（変更点の要約）

これだけで「古い情報の放置」「誰に聞けばいいか不明」が減ります。

4) 見た目（読みやすいか、疲れないか）

最後にデザインです。ここは“凝る”より“整える”が正解です。

1セクション1メッセージ（詰め込みすぎない）
文章は 3〜5行で改行＋箇条書き中心
配色は2色まで、ボタンの種類を増やさない

改善サイクルの回し方（初心者向けの最短）

週1回・15分で回せる形にします。

指標を見る（KPI 1〜3個だけ）
原因ページを1つ決める（例：トップ or 問い合わせ前のページ）
1つだけ直す（導線 or FAQ追加など）
次週、同じ指標で差分を見る

“まとめて大改修”より、小さく直して早く検証がGoogleサイトでは勝ちやすいです。

GoogleサイトのSEO：できることだけで最大化する

前提：メタ情報を細かくいじれないぶん、本文設計が勝負

Googleサイトは、WordPressのように「title/description/OGP/構造化データ/robots」などをページ単位で細かく調整するタイプではありません。
そのぶん、成果が出るサイトは次の“土台”が強いです。

1ページ＝1目的（混ぜない）
冒頭で要点がわかる（検索結果→クリック→即納得）
見出しで情報が探せる（スクロールしても迷子にならない）
内部リンクで次の行動に誘導（回遊＝評価と成果につながる）

また、検索結果の説明文（スニペット）は、設定したメタディスクリプションだけで決まらず、本文の一部が採用されることも普通にあります。
だからこそ、本文の“見せ方”がSEOの中心になります。

コンテンツ設計で効く施策

ページタイトルと見出し構造（H2〜H4で意図を明確化）

やることはシンプルで、効果が大きい順に並べます。

1) ページタイトルは「誰の何を解決するか」を入れる

悪い例：

ホーム / TOP / 案内 / まとめ

良い例：

社内ポータルの申請手順（経費精算）
Googleサイトで問い合わせページを作る方法（最短手順）
プロジェクトX：資料・議事録・進捗（入口ページ）

ポイント

先頭付近に主要語（探される言葉）を置く
“対象”か“状況”を入れて、同名ページの量産を避ける
タイトルと本文の冒頭がズレないようにする（クリック後の離脱が減ります）

2) 見出しは「検索者が探している順」に並べる

おすすめはこの型です。

H2：結論・要点（または手順の全体像）
H2：手順（または具体例）
H2：よくあるミス・注意点（詰まる所の先回り）
H2：FAQ（問い合わせ削減）
H2：参考・根拠・更新履歴（信頼）

3) H2〜H4は“意味が重複しない”ように切る

ありがちな重複はこれです。

「作り方」「手順」「設定方法」が別見出しで同じ内容
→ 「手順」に統合して、手順内で小見出し（H3）にする

4) URL（ページパス）も整えると運用が楽

GoogleサイトはページごとにURLの“末尾（カスタムパス）”を設定できます。
SEOだけでなく、社内共有や資料掲載のときにリンクが読みやすいのが強みです。

例：

/apply-expense
/project-x/meeting-notes
/faq/account

注意

あとから変えるとリンク切れが起きやすいので、最初に方針を決めるのが安全です

内部リンクとナビ（回遊性・探しやすさ）

GoogleサイトのSEOは、内部リンクが“ほぼ生命線”です。理由は2つあります。

検索エンジンも人も、リンクを辿って重要ページを理解する
サイト内で迷うと、すぐ戻られて成果が落ちる（問い合わせ・申請など）

1) グローバルナビは「7項目まで」が基本

増えるほど探しにくくなります。おすすめの考え方は、

ナビ：カテゴリ（入口）だけ置く
実務ページ：入口から2クリック以内に配置する

例（社内ポータル）

手続き / 規程 / 申請 / テンプレ / FAQ / お知らせ / 窓口

2) “次に進めるリンク”をページ内に必ず置く

特に効果が出やすいのは、この3箇所です。

冒頭：結論の直後（急いでいる人用）
中盤：手順の途中（「ここから申請」など）
末尾：読了後（FAQ・関連手続き・問い合わせ）

3) アンカーテキストは「ここを押す」禁止

リンク文字は、内容が一瞬でわかる表現にします。

悪い：こちら / 詳細 / ここをクリック
良い：経費精算の申請フォーム / 稟議テンプレ（Googleドキュメント）/ アカウント発行手順

画像の代替テキスト（アクセシビリティ＋理解補助）

画像の代替テキスト（alt）は、SEOというより品質と信頼の底上げに効きます。
（読み上げ対応・理解補助ができ、結果として離脱が減りやすい）

altテキストの基本ルール（迷ったらこれ）

画像の役割が「情報」なら書く（スクショ、図、表、比較など）
画像が「飾り」なら無理に盛らない（説明がノイズになる）

書き方の型

何の画像か＋何が重要かを短く
例：
「Googleサイトの公開設定画面。公開範囲を制限付きにする項目」
「ページのプロパティ画面。カスタムパスを設定する場所」

検索結果の説明文に“使われやすい要約”の置き方

Googleサイトでは、メタディスクリプションを思い通りに編集できない前提で、本文側に“要約ブロック”を置くのが現実的に強いです。

インデックス状況の確認と促進

site:検索での確認手順

まずは“今どう見えているか”を軽く把握します。

Google検索で site:あなたのURL を入力
ページが多い場合は site:あなたのURL キーワード で絞る
例：site:example.com 申請 / site:example.com FAQ

見たいポイント

重要ページが出ているか
古いページ名が残っていないか
意図しないページ（下書き的なページ）が出ていないか

Search Consoleでの所有権確認と登録

Search Consoleは「検索での表示状況」と「インデックス可否」を確認するための必須ツールです。
Googleサイトでも、独自ドメイン運用なら特に入れておく価値があります。

1) どっちで登録するか（最短で迷わない判断）

独自ドメインがある → ドメインプロパティが管理しやすい（DNSが必要）
とりあえず試したい／URL単位でOK → URLプレフィックスでも可

2) 検証（所有権確認）で詰まりにくい順

GoogleサイトはHTMLを自由に編集できないため、初心者は次が安全です。

DNS（TXT）で検証：最も堅牢（DNSを触れる人向け）
Google Analyticsで検証：GA4を入れていて権限があるなら有力

進め方（ざっくり）

Search Consoleでプロパティ追加
検証方法を選ぶ（DNSまたはGA）
指示どおりに設定して「確認」
所有権が取れたら、URL検査やパフォーマンスを使える

URL検査で再クロール依頼（更新が反映されない時）

更新したのに検索結果が変わらないときは、URL検査が最短です。

流れ

Search Consoleの上部検索窓に、対象ページURLを入れる
「インデックス登録済みか」「クロール日時」「検出方法」などを確認
変更後なら、インデックス登録をリクエスト（可能な場合）

よくある“反映されない理由”

公開範囲が制限されていてGoogleが見られない
ページがナビや内部リンクから辿れず、発見されにくい
内容が薄い／他ページと重複していて評価が乗りにくい
大幅変更直後で、反映待ちの段階（時間差は普通にあります）

よくあるトラブルと対処（詰まりポイントをまとめて解決）

Googleサイトで詰まりやすいのは、だいたい次の4つです。

公開したのに見られない（共有設定・URLの勘違い）
スマホ表示で崩れる（レイアウト設計）
独自ドメインが反映されない（DNS・公開状態・時間差）
検索に出ない（限定公開・noindex・インデックス未完了）

まずは「症状→最短チェック→原因の切り分け」の順で進めると迷いません。

公開したのに見られない（公開範囲・権限・アカウント要因）

最短で切り分ける3分チェック

次を上から順に確認してください（ここで8割解決します）。

「公開（Publish）」が済んでいるか
- 編集画面で内容を直しただけでは、公開版に反映されないことがあります
- 変更後は基本的に再公開が必要です
「公開サイト（Published site）」の閲覧範囲が意図どおりか
- 制限付き（Restricted）のままだと、許可した人以外は見られません
- 仕事/学校アカウントだと「組織内のみ」などの選択肢が出ることがあります
相手が“正しいURL”で開いているか
- 編集者向けのURL／下書きのURLを渡していると、表示できなかったり、権限要求が出たりします
- いったん「シークレットウィンドウ」で自分でも開いて確認するのが確実です

それでも見られないときの“原因別”対処

A. 「アクセス権限が必要です」になる

原因：公開範囲が制限付き、または相手のアカウントが違う
対処：
- 公開範囲を見直す（公開/制限付き）
- 制限付きの場合は、相手を「公開済み閲覧者（Published viewer）」として追加
- 相手が複数アカウント（個人/会社）を使っているなら、許可したアカウントでログインしてもらう

B. 「見えるけど、埋め込み（ドライブ資料・動画・カレンダー等）が見えない」

原因：サイトは見えても、埋め込み元の共有権限が合っていない
対処：
- 埋め込み元（Driveファイル等）の共有設定を、サイトの公開範囲に合わせる
- 例：サイトが一般公開なら、資料も閲覧可能にしておく（必要範囲で）

C. 相手には“古い内容”が表示される

原因：再公開していない／ブラウザのキャッシュ
対処：
- もう一度公開（Publish）する
- シークレットで確認、別端末で確認

再発防止の運用ルール（これだけで事故が激減）

編集者＝更新、オーナー＝公開と公開範囲管理に分ける
公開前チェック（固定化）
- 公開範囲
- 共有相手
- 埋め込み資料の権限
- シークレット表示確認

スマホ表示で崩れる（セクション設計の見直し）

Googleサイトは自動的にレスポンシブに調整されますが、“PCで美しく見える配置”がスマホでは破綻しやすいです。特に「2〜3列レイアウト」「横長の表」「画像＋テキストの詰め込み」で崩れます。

よくある崩れ方と、直し方の鉄板

1) 2列（横並び）がスマホで窮屈になる

対処：
- 重要セクションは 1列（縦積み）を基本にする
- 2列を使うのは「カード3つまで」「文章は短め」など軽い用途に限定

2) 画像が大きすぎて、文字やボタンが押しづらい

対処：
- 画像は「説明のため」だけに絞る（飾り画像を減らす）
- ボタンは密集させず、上下に余白を取る（誤タップ防止）

3) 表が横にはみ出す／読めない

対処（おすすめ順）：
- 表をやめて、箇条書き＋小見出しに置き換える
- どうしても比較表が必要なら、項目数を絞り「縦比較（A→B→C）」にする

4) セクション内に要素を詰め込みすぎて“情報の塊”になる

対処：
- 1セクション＝1メッセージ（結論→補足→リンク）
- 長文は「折りたたみ」やFAQに逃がす

最短で見栄えを整えるテンプレ

冒頭：2〜4行の要約（誰向け・何ができる）
本文：手順は番号付き（3〜7手順）
途中：注意点（箇条書き3〜5個）
末尾：次の行動ボタン（問い合わせ／申請／関連ページ）

独自ドメインが反映されない（DNS/公開/時間差）

独自ドメインは、つまずく原因がだいたい決まっています。
また、反映には時間差があり、最大48時間かかることがあるため、焦って設定をいじり直すのが逆効果になることもあります。

最短で潰すチェックリスト（上から順に）

あなたがサイトの「所有者（オーナー）」か
- 独自ドメイン接続は基本的にオーナーしかできません
サイトが公開済みか
- 公開していないと、独自ドメインで見えない／挙動が安定しません
公開範囲が“世界に公開”になっているか
- 独自ドメインに紐付けたサイトは、公開閲覧者の共有設定が“世界向け”でないと、標準URL側へ誘導されることがあります
- 社内限定サイトはここでハマりやすいです
DNSに誤り・競合がないか（特に www）
- 典型：www のCNAMEが指定先になっていない／別のAレコード等と競合している
- DNSサービスの「プロキシ（CDN）」系機能が有効だと挙動が不安定になる場合があるので、まずは標準のDNS解決で確認
待つ（反映待ち）
- 変更直後は、端末や回線によって見え方がズレます
- シークレット＋別回線で確認すると切り分けが早いです

よくあるエラーの考え方（現場で多い）

「証明書がない」系
- いったんカスタムURL設定を外して、再度割り当てし直すと直ることがあります（証明書発行のやり直し）
「そのURLは他サービスで使用中」系
- 以前に同じサブドメインを別サービスに割り当てた履歴があると衝突します
- 既存のマッピング解除が必要です

検索に出ない（限定公開、クロール、インデックスの確認）

まず大前提として、限定公開（Restricted/組織内のみ）だと、検索結果に出ない（出すべきでもない）ケースが大半です。
外部向けに検索から来てほしいなら、公開範囲が適切かを最初に確認します。

まず確認すること（ここで大半が決まる）

1) 公開範囲は外部に開いているか

「限定公開」のままでは、Googleがクロールできません

2) “検索エンジンに表示しない”設定をONにしていないか

公開設定の中に、検索エンジンに表示しないよう依頼する項目があります
これをONにすると、検索に出にくくなります（そもそも出したくない用途で使う機能です）

Search Consoleで確認と促進（更新が反映されないときに強い）

検索結果に出す・更新を早く反映させたいなら、Search ConsoleのURL検査が最短です。

手順（ざっくり）
1. Search Consoleにサイトを登録（所有権確認）
2. URL検査で、対象ページURLを入力
3. 「インデックス可能か」を確認
4. 問題がなければ インデックス登録をリクエスト

注意点（初心者が誤解しやすい）

リクエストしても 必ず掲載される保証はありません
リクエストには 上限（回数制限）があります
インデックスは早いと1日程度でも、状況次第で時間がかかることがあります

“検索に出ない”ときの実務的な直し方（安全順）

まず：公開範囲を確認（限定公開なら、検索の話はここで終わり）
次：検索に表示しない設定を見直す
次：Search ConsoleでURL検査→問題がなければリクエスト
次：コンテンツの重複や薄さを改善（1ページ1目的、冒頭要約、見出し整理）

他サービスとの比較（結局どれを選ぶべき？）

「Googleサイトが良いかどうか」は、サービス単体の優劣というより 目的と運用体制に合うかで決まります。
ここでは、ありがちな選定ミス（あとで作り直し）を避けるために、各サービスの“刺さる場面”を整理します。

WordPress：拡張性・SEO・資産性を重視する場合

WordPressが向くのは、ひとことで言うと “伸ばす前提のサイト”です。

向いているケース

ブログやオウンドメディアを育てたい（記事数が増える前提）
SEOを本気でやりたい（タイトル/説明文/構造化/速度/内部リンク設計などを詰めたい）
将来的に機能追加したい（会員、予約、EC、多言語、LP量産…）
“サイトが資産”として長く残る形にしたい（移転・拡張がしやすい）

強み（現場で効くところ）

テーマ＋プラグインで機能を増やせる（SEO系も含む）
運用が成熟すると、改善の打ち手が尽きにくい（分析→施策→検証が回る）

弱み（初心者がつまずくところ）

サーバー/ドメイン/更新/セキュリティ/バックアップなど、運用の責任範囲が広い
最初の形にするまでの手間が、Googleサイトより大きい

判断の目安

「検索から継続的に集客する」「記事を増やす」なら、最終的にWordPressが優位になりやすいです。
逆に「短期で簡易サイト」「社内共有」が主なら、WordPressは過剰装備になりがちです。

あわせて読みたい

WordPress 徹底解説｜特徴・仕組み・始め方まで初心者向けに総まとめ「ブログを始めるならWordPressがいいって聞くけど、正直よく分からない」「サーバー？ドメイン？専門用語が多すぎて、どこから手をつければいいのか不安……」「無料ブ…

Wix/STUDIO/ペライチ：デザインや機能を盛りたい場合

この3つは共通して、ノーコードで“見た目と機能”を早く整えやすいカテゴリです。
ただし性格が違うので、用途で切り分けると選びやすくなります。

Wixが向くパターン

向いているケース

予約・会員・ECなど、サイト内でやりたいことが多い
ある程度のSEO設定（タイトル/説明文など）も触りたい
サイト運用を「サービス側に寄せて」楽にしたい

注意点

できることが多い分、設計が雑だとページが増えたときに管理が散らかりやすい
→ 最初に「ページ構成」「カテゴリ」「導線」を決めてから作るのがコツです。

あわせて読みたい

Wixとは｜できること・料金・評判・向き不向き・他社比較を初心者向けに完全ガイド「Wixってよく聞くけど、結局どんなサービス？」ホームページ作成を調べ始めると、こんな疑問が一気に出てきませんか。「無料でどこまでできるの？本番運用だと結局い…

STUDIOが向くパターン

向いているケース

コーポレート/採用/サービス紹介など、デザイン品質を上げたい
CMSやフォームも含めて、制作〜運用をノーコードで回したい
“制作会社っぽい見た目”を、なるべく短期間で作りたい

注意点

予約・ECなどの領域は、要件によっては外部連携（別サービス）前提になります
→ 「サイト内で完結したいか」「外部連携でもOKか」で判断が変わります。

あわせて読みたい

Studioホームページの教科書｜初心者でも失敗しない作り方と運用の全手順「ホームページを作らなきゃ」と思って調べ始めたものの、いきなり壁にぶつかっていませんか？「Studioってよく聞くけど、本当に初心者でも作れるの？」「おしゃれなサ…

ペライチが向くパターン

向いているケース

1ページ完結のLPで、すぐ公開したい（キャンペーン、講座、相談受付など）
決済や予約など“売る”導線を軽く作りたい
とにかく最短で「形」と「販売」を始めたい

注意点

サイト全体を育てる（情報量を増やす）より、単発LPに強い設計
→ SEOで記事を積み上げる用途は、別手段（WordPress等）のほうが噛み合います。

ペライチ公式サイト

あわせて読みたい

ペライチとは｜できること・料金・評判・向き不向き・他社比較を初心者向けに徹底解説「ホームページを作りたい。でも、難しそうで手が止まる…」そんなときによく候補に挙がるのが、ノーコードでページを作って公開できる「ペライチ」です。ただ、初め…

Notion/社内Wiki：ナレッジ管理が主目的の場合

Notion（や社内Wiki系）が強いのは、検索される“Webサイト”というより、更新され続ける“知識の置き場”です。

向いているケース

社内ルール、手順書、議事録、テンプレ、FAQなどを一元化したい
共同編集・権限管理・情報の構造化（データベース）が重要
“更新される前提”で、運用を仕組みにしたい

弱み（外部向けに使うと起きやすいこと）

外部集客（SEO）をメインにする設計ではない
公開ページを作れても、LP/コーポレートとしての見せ方は別サービスのほうが整えやすい

現実的な使い分け

外部向け：Googleサイト / Wix / STUDIO / WordPress
内部向け：Notion（ナレッジ）＋ Googleサイト（社内ポータル入口）
のように、役割を分けると運用が崩れにくいです。

判断表：目的×運用体制×必要機能で選ぶ

「目的」と「運用できる体制」で選ぶと、ブレません。
（“作れるか”より“回せるか”が重要です）

スクロールできます

目的/要件	いちばん相性が良い候補	理由（初心者向けに短く）
とにかく早く公開、簡易サイトでOK	Googleサイト	最短で公開・共有できる。社内/小規模向けに強い
社内ポータルの入口、情報共有が主	Googleサイト / Notion	Googleサイトは“入口”。Notionは“中身（知識）”で強い
1ページLPで申込/販売を最短で	ペライチ	LP運用＋決済/販売の導線が作りやすい
デザイン品質を上げたコーポレート/採用	STUDIO	見た目の完成度を上げやすい。CMS/フォームも扱える
予約・会員・ECなど機能を盛りたい	Wix	機能が揃っていてノーコード運用に寄せやすい
記事を増やし、SEOで育てて資産化	WordPress	拡張性とSEOの打ち手が多く、長期運用に強い
将来の拡張（会員/EC/多言語等）も想定	WordPress（本命） / Wix（運用寄せ）	どこまで自分で持つかで選ぶ（自由度 vs 手軽さ）

迷ったときの“即決”ルール

検索集客を伸ばしたい（記事が増える） → WordPress
デザインを重視して早く整えたい → STUDIO（機能盛りならWix）
LPで売る/申し込ませるのが先 → ペライチ
社内の入口・共有が主 → Googleサイト（中身の整備はNotion併用が強い）

まとめ

Googleサイトは、スピード・共同編集・Google連携に強い、シンプルで実用的なサイト作成ツールです。
個人の簡易サイト、小規模ビジネスの案内ページ、社内ポータルやプロジェクトサイトなど、“早く作って、運用しながら整える”目的なら、非常に高いコストパフォーマンスを発揮します。

一方で、次のような要件では壁が出やすい点も押さえておきましょう。

デザインを細部まで作り込みたい（CSS直編集など）
EC・会員制・複雑な動的機能をサイト内で完結したい
SEOを細かく管理してメディアを伸ばしたい（高度な制御が必要）
移行・バックアップを厳密に求められる運用

だからこそ重要なのは、最初に「目的」と「運用体制」を決め、Googleサイトで勝てる形に寄せることです。

最短で公開する：1ページ型で始め、必要になったら複数ページへ
迷子を作らない：ナビは絞り、重要導線（申込・問い合わせ・申請）を固定
事故を防ぐ：公開範囲と権限（閲覧者／編集者／オーナー）を分ける
詰まりを減らす：FAQ・手順・更新履歴・担当窓口を明記して運用する
改善で伸ばす：Analytics/GA4で目的に合う指標だけを見て、導線から直す

もしあなたの目的が「早く、正しく、みんなで更新できるサイトを運用すること」なら、Googleサイトはかなり有力な選択肢です。
逆に、作り込みや拡張が主目的なら、WordPressやWix/STUDIO、ナレッジ用途ならNotionなど、最初から別サービスを選ぶ方が結果的に早いこともあります。

本記事の内容をもとに、まずは「最小構成で1つ公開」してみてください。
運用しながら改善していくことで、Googleサイトの強み（速さと共有性）が最大化され、迷わず運用できる状態に近づきます。

【※Googleサイトは簡易的なホームページ作成向きです。本格的なホームページを検討している場合は以下をおすすめします↓】