Webサイト更新の承認フロー｜担当・確認・公開を決める実務表

Webサイトの更新が滞るときは、編集できる人がいないだけでなく、「誰の資料を正とするか」「誰が公開を許すか」「公開後に誰が画面を見るか」が決まっていないことがあります。少人数でも、書く人、事実を確かめる人、公開を承認する人、本番を確認する人を分けて記録すれば、差し戻しの理由を追いやすくなります。

この記事は、Webサイト公開後の運用・改善サイクルのうち、個々の更新依頼を公開するまでの承認手順に絞ります。以下の表は公式資料を踏まえた一般的な設計例で、SEVEN PEBBLESの社内運用実績を示すものではありません。

依頼時に「何を、なぜ、いつ」変えるかをそろえる

依頼票には対象URL、現在の文言、変更案、変更理由、根拠となる最新版の資料、希望公開日、依頼者、事実確認者を記録します。添付資料の版や日付が分からなければ、編集者が推測で補わず、担当部署へ確認します。価格、採用条件、法的表示、障害情報のように誤りの影響が大きいものは、通常の文章修正より承認を明確にします。

変更種類ごとに確認者と本番QAを変える

次は小規模な事業サイト向けの責任分担のたたき台です。役職名ではなく、自社で実際に責任を持つ人に置き換えて使います。

変更の種類	正本となる原資料	事実確認・承認	公開後の確認
誤字・リンク切れ	現行ページと正しいリンク先	ページ責任者が内容の変化を確認	対象箇所とリンク先を開く
価格・サービス条件	承認済みの価格表・仕様書	事業担当が照合し、決裁権者が公開を承認	サービスページから申込・問い合わせ導線まで確認
採用条件	現行の募集要項	人事と採用責任者が照合	募集ページと応募フォームの整合を確認
障害・緊急告知	時刻を含む障害記録・対応方針	運用責任者と対外発信の承認者	公開URL、表示時刻、連絡先を確認

原資料に矛盾があれば、公開を急いで一方を選ばず、事実を持つ部署へ戻します。表の承認者は例示であり、実際の権限や法的確認の要否は各組織の規程に合わせて決めます。

WordPressの状態と権限を、承認ルートに合わせる

WordPressには下書き（draft）、承認待ち（pending）、公開（publish）、予約（future）などの投稿状態があります。また、管理者、編集者、投稿者、寄稿者などの標準ロールと権限が用意されています。たとえば原稿担当が下書きを作り、確認担当が承認待ちの内容を見て、公開権限を持つ人が公開する流れは設計できます。ただし、実際のサイトでどの役割が設定されているか、プラグインで権限が変わっていないかは管理画面で確認が必要です。

「確認済み」とチャットで伝えるだけでは、どの版を見たか曖昧になりがちです。承認時はURL、原稿の版、確認日、承認者、差し戻し理由を同じ記録に残します。WordPressのリビジョン機能は保存した下書きや公開更新の差分確認・復元に使えますが、事実確認や組織の承認そのものを自動で代行する機能ではありません。

差し戻しと緊急修正の経路も先に決める

差し戻しは「誤りの箇所」「参照すべき資料」「再確認する人」を具体的に伝えます。急ぎの訂正でも、誰が事実を確かめ、誰が公開を許し、いつ本番URLを見たかを残します。営業時間外に承認者が不在なら、代行者と連絡経路を事前に定めます。権限を広く配り過ぎて解決するのではなく、必要な担当に必要な権限を割り当てます。