Webサイトのコンテンツガバナンスとは？更新責任・承認・廃止を回す運用設計
企業のWebサイトでは、サービスページ、導入事例、記事、採用情報、規約、キャンペーンLPが部門ごとに増えていきます。公開時は正しくても、料金改定、組織変更、製品終了、法令対応の後に古い説明が残れば、問い合わせの行き違い、ブランド毀損、検索流入の分散につながります。
結論として、Webサイトのコンテンツガバナンスとは、各ページの目的・責任者・承認者・次回レビュー日を決め、公開後も更新・統合・保存・廃止まで追跡する運用です。CMSの編集権限だけでは足りません。ページ台帳を正本にし、情報の変化リスクに応じて見直し期限を設定し、URLを閉じるときまで判断と証跡を残します。
本記事のポイント
- コンテンツガバナンスはCMSの権限設定ではなく、ページの目的、責任者、期限、承認、廃止判断をつなぐ運用である。
- 全ページを同じ頻度で見直さず、法令・料金・製品条件など変更リスクが高い情報ほど短いレビュー周期を設定する。
- 古いページは一律削除せず、更新、統合、恒久リダイレクト、保存、404・410を利用者の目的と代替先で使い分ける。
この記事で扱うテーマ
関連キーワード
- コンテンツガバナンス とは
- Webサイト 更新ルール
- Webページ 廃止 運用
- コンテンツ オーナー
- Webサイト 承認フロー
- Webページ 更新期限
このページで答える質問
- コンテンツガバナンスとは何ですか？
- ページごとの責任者はどう決めますか？
- 更新期限とレビュー周期はどう設計しますか？
- 古いページを削除・統合するときに何を確認しますか？
コンテンツガバナンスは公開後から始まる
コンテンツガバナンスは、文章のトーンやデザインをそろえるルールだけではありません。「なぜこのページが必要か」「誰が内容の正しさを保証するか」「いつ見直すか」「不要になったときに何へつなぐか」を決める意思決定の仕組みです。制作担当者が異動しても、判断が止まらない状態を作ることが目的です。
管理対象は記事本文だけではありません。タイトル、description、構造化データ、PDF、画像、フォーム、CTA、関連リンク、同意文、広告の遷移先まで含めます。表示面とデータを分離するHeadless CMSを導入しても、責任者や廃止基準がなければ、複数チャネルへ古い情報を速く配信するだけになりかねません。
| 管理項目 | 最低限記録する内容 | 判断に使う場面 |
|---|---|---|
| 識別情報 | URL、ページ種別、対象読者、目的 | 重複ページと役割の競合を見つける |
| 責任 | コンテンツオーナー、編集担当、承認者 | 変更依頼と最終判断の行き先を決める |
| 期限 | 最終確認日、次回レビュー日、期限の根拠 | 古い情報を公開したままにしない |
| 根拠 | 一次資料、契約条件、権利、同意、監修記録 | 事実確認と説明責任を支える |
| 状態 | 下書き、審査中、公開、更新待ち、統合、保存、廃止 | 作業中と公開中を混同しない |
| 後継関係 | 統合先、後継URL、リダイレクト、保存理由 | 削除後の利用者と検索導線を守る |
最初から高機能なDAMやワークフロー製品を導入する必要はありません。ページ数が少なければスプレッドシートでも始められます。ただし、URLごとに一意の行があり、更新担当者だけでなく判断権を持つオーナーと次回レビュー日が入っていることが条件です。
ページ責任者と承認者を分けて決める
ページごとの責任者は、CMSを操作できる人ではなく、掲載内容の事実と事業上の判断に責任を持てる役割から選びます。サービスページなら事業責任者、料金ページなら価格決定部門、採用情報なら採用部門、法務文書なら所管部門がコンテンツオーナー候補です。個人名だけを台帳に書くと異動で空席になるため、部門・役割と代替連絡先も持たせます。
一方、編集担当は読みやすさ、表記、リンク、画像、CMS反映を担います。承認者は公開してよいかを最終判断します。作成者と承認者を分けると、事実誤認や権利漏れを見つけやすくなります。GOV.UKの公開ガイダンスでも、公開前にプレビューし、変更理由を内部記録へ残し、別の編集権限者による「2nd eyes」のレビューへ送る流れが示されています。
| 役割 | 主な責任 | 止めるべき状態 |
|---|---|---|
| コンテンツオーナー | 目的、対象読者、事実、公開継続の判断 | 根拠が古い、後継サービスが未確定 |
| 編集担当 | 構成、表記、リンク、画像、CMS反映 | 出典不明、リンク切れ、表示崩れ |
| 承認者 | 公開、差し戻し、条件付き承認 | 法務・権利・ブランド確認が不足 |
| 技術担当 | URL、redirect、canonical、計測、フォーム | 旧URL処理や計測確認が未完了 |
| 専門確認者 | 法務、セキュリティ、アクセシビリティなど | 高リスク項目が基準を満たさない |
すべてのページを5人で承認する必要はありません。事故時の影響で承認段階を変えます。誤りが契約、法令、価格、個人情報、応募者対応に影響するページは専門確認を追加し、読み物記事の軽微な表記修正は編集担当とオーナーで閉じるなど、過剰な待ち時間を防ぎます。UIや表現の一貫性はデザインシステムの運用と接続すると、ページごとの自己流を減らせます。
更新期限は情報の変化リスクで設計する
更新期限は「公開から半年」のように全ページ一律で決めるより、情報が変わる頻度と、誤ったまま残る影響で決めます。GOV.UKのコンテンツ管理では、次回レビュー日と通知先を設定し、期限が来たら内容を更新するか、問題がなければ次のレビュー日を設定する運用が示されています。レビュー日は公開期限ではなく、判断を発生させる日です。
| リスク | ページ例 | レビュー周期の目安 | 追加トリガー |
|---|---|---|---|
| 高 | 料金、契約条件、規約、法令、セキュリティ、応募条件 | 1〜3か月 | 改定、障害、組織変更の発生時 |
| 中 | サービス、導入手順、比較、事例、イベント後資料 | 3〜6か月 | 製品更新、顧客条件、導線変更時 |
| 低 | 基本用語、企業理念、長期的な考え方 | 6〜12か月 | 検索意図や参照先が変化した時 |
この周期は法定期限ではなく、運用開始時の目安です。実際には、問い合わせで誤解が繰り返される、検索流入が大きく落ちる、CTAが使われない、リンク切れが発生する、引用元が更新されるといったシグナルでもレビューを起動します。既存記事の優先順位はコンテンツリライトの判断手順を使い、事業影響と改善余地を分けて整理できます。
レビュー結果は「変更なし」でも記録します。確認した日、確認者、見た根拠、次回日を残せば、単に更新日だけを新しくする運用を避けられます。オーナー不在、期限超過、根拠切れのページは、通常公開の一覧とは別の要対応キューへ移します。
企画から公開・レビューまでを6ステップで回す
コンテンツガバナンスを定着させるには、公開前と公開後を別の業務にしないことが重要です。公開の前後を一枚の台帳でつなぎ、次の6ステップを同じページIDで追跡します。
- 作成依頼を受付ける
対象読者、解決する問い、事業目的、希望公開日、公開期限、関連ページを記録します。「とりあえず1ページ作る」依頼は、既存ページへの追記で足りないかを先に確認します。 - オーナーと廃止条件を先に決める
内容の責任者、編集担当、承認者、次回レビュー日を決めます。キャンペーン終了、製品終了、制度改定など、公開を見直す条件も制作前に置きます。 - 根拠と素材の権利を確認する
一次資料、数値の時点、画像・ロゴの利用許諾、個人情報、顧客同意を確認します。根拠URLと確認日を台帳に残します。 - プレビューと役割別レビューを通す
事実、読者理解、ブランド、アクセシビリティ、技術、法務のうち必要な項目を確認します。差し戻し理由はチャットに散らさず、ページの履歴へ残します。 - 公開直後の実体を検証する
URLのGET、canonical、title、主要見出し、フォーム、画像、計測、内部リンクを確認します。公開ボタンの成功だけを完了条件にしません。 - 利用状況と期限で再判断する
レビュー日、問い合わせ、検索、CV、リンク切れ、事業変更を見て、継続、更新、統合、保存、廃止を選びます。判断日と次回日を更新します。
GitとVercelのような構成でサイトを内製する場合も、役割は同じです。Webサイト制作を内製化する手順に、レビュー担当、mainへの反映条件、公開後検証を追加すると、制作速度と統制を両立しやすくなります。
古いページは更新・統合・保存・廃止を使い分ける
古いページを見つけても、アクセスが少ないという理由だけで削除しません。利用者が何を探していたか、代替情報があるか、契約や法令上の保存が必要か、外部リンクや広告が残っているかを確認します。内容が現行ページと重複しているなら統合し、旧URLから最も近い後継ページへ恒久リダイレクトします。
| 判断 | 選ぶ条件 | URLの扱い | 確認事項 |
|---|---|---|---|
| 更新 | 目的とURLは有効で、情報だけ古い | 同じURLを維持 | 根拠、日付、CTA、構造化データ |
| 統合 | 複数ページが同じ問いに答えている | 代表ページへ恒久redirect | 固有情報の移植、内部リンク、canonical |
| 保存・撤回表示 | 履歴として必要だが現行情報ではない | 状態と後継先を明示して維持 | 誤認防止、保存根拠、検索表示 |
| 廃止 | 代替がなく、公開継続の価値もない | 404または410 | sitemap、内部リンク、広告、外部導線 |
Google Search Centralは、重複ページを廃止するときは恒久リダイレクトを強いcanonicalシグナルとして扱い、移転先がない削除ページは404または410を返すよう案内しています。関連性のない旧URLをすべてトップページへ送ると、利用者を混乱させ、soft 404として扱われる可能性があります。統合前にはcanonicalと重複ページの整理も確認し、代表URLを決めてから転送します。
廃止前チェックでは、内部リンク、サイトマップ、パンくず、関連記事、広告、メール、PDF、QRコード、フォーム完了画面、外部提携先のリンクを確認します。廃止後も、旧URL、処理日、処理理由、後継URL、承認者、保持すべきデータを台帳に残します。URLが消えても、判断証跡まで消してはいけません。
運用が続いているかを指標で確認する
ページ数の多さではなく、責任と期限が機能しているかを測ります。最低限見る指標は、オーナー未設定率、レビュー期限超過率、根拠切れページ数、リンク切れ件数、重複候補数、統合後のredirectエラー、公開後検証の未完了数です。流入やCVが高いページだけでなく、料金・規約・採用条件のように誤りの影響が大きいページも優先します。
W3C WAIは、アクセシビリティを一度の改修で終わらせず、方針、責任、予算、定期評価、進捗追跡、利用者フィードバックを継続的に回すことを示しています。コンテンツガバナンスの台帳にアクセシビリティ基準と確認日を加えれば、公開時だけ合格して、その後の更新で崩れる問題を減らせます。
| 頻度 | 確認すること | 異常時の対応 |
|---|---|---|
| 公開ごと | 承認、GET、主要表示、フォーム、計測 | 公開を止めるか直ちに修正する |
| 週次 | リンク切れ、期限超過、高リスク変更 | オーナーへ割り当てて期限を再設定する |
| 月次 | 重複、孤立ページ、検索・CVの急変 | 更新・統合候補を優先順位付けする |
| 四半期 | 役割、基準、承認時間、廃止結果 | 不要な承認を減らし、欠けた統制を追加する |
レビュー期限を守ること自体が目的ではありません。問い合わせの誤解が減ったか、古い価格表示がなくなったか、統合後に利用者が後継ページへ到達できたかまで確認します。承認に時間がかかりすぎる場合は、事故影響の低い変更を簡略化し、高リスク変更へ確認時間を振り向けます。
よくある質問
コンテンツガバナンスとは何ですか？
Webページの目的、責任者、承認者、根拠、レビュー期限、公開状態を管理し、企画から更新・統合・廃止まで判断できるようにする運用です。文章ルールやCMS権限は、その一部にすぎません。
ページごとの責任者はどう決めますか？
CMSを操作する人ではなく、掲載内容の正しさと公開継続を判断できる事業・業務上の役割をオーナーにします。異動に備え、個人名だけでなく部門・役割、代替連絡先も記録します。
更新期限とレビュー周期はどう設計しますか？
情報が変わる頻度と、誤りが残る影響で決めます。料金、契約、法令、セキュリティは短く、長期的な基本情報は長くします。事業変更や根拠更新が起きたときは、定期日を待たずにレビューします。
古いページを削除・統合するときに何を確認しますか？
代替ページ、固有情報、内部・外部リンク、広告、フォーム、canonical、サイトマップ、保存義務を確認します。近い後継ページがあれば恒久リダイレクトし、代替がなければ404または410を返します。
小規模なWebサイトにもページ台帳は必要ですか？
必要です。ただし、専用ツールは必須ではありません。URL、目的、オーナー、承認者、最終確認日、次回レビュー日、状態、後継URLの8項目から始めれば、少ないページでも担当者依存を減らせます。
CMSの承認機能を入れればガバナンスは完成しますか？
完成しません。CMSは下書きや承認を支援できますが、誰が何を根拠に判断するか、公開後いつ見直すか、廃止時にURLをどう処理するかは組織の運用として決める必要があります。
実務で参照できる公式ガイダンス
- GOV.UK：Manage existing GOV.UK contentでは、更新日・レビュー期限を含む台帳出力、定期監視、更新・廃止の判断を確認できます。
- GOV.UK：Send standard content types for reviewでは、プレビュー、変更理由の内部記録、2人目のレビューへ送る手順を確認できます。
- Google Search Central：canonicalの指定と重複URLの統合では、恒久リダイレクト、canonical、sitemapのシグナルを確認できます。
- Google Search Central：クロールエラーのトラブルシューティングでは、代替ページがない削除URLに404または410を返す方針を確認できます。
- W3C WAI：Planning and Managing Web Accessibilityでは、方針、責任、継続評価、進捗追跡、利用者フィードバックを運用に組み込む考え方を確認できます。
