Webサイト公開前に確認すること一覧｜担当者向け最終チェック
Webサイトの公開日が近づくと、制作、確認、承認、公開作業が一気に増えます。
一つひとつの項目を確認していても、「誰が最後に見て、公開してよいと決めるのか」が決まっていないことがあります。
その状態では、確認が終わったのかどうか分からないまま公開時刻を迎えてしまいます。
公開前の最終チェックで見るのは、サイトの見た目だけではありません。
誰が何を確認するかという役割、どうなれば完了とするかの条件、公開作業の順番、公開後の連絡先まで、そろえて決めておく場面です。
公開前の確認は、一人で全部を抱え込むものではありません。
この記事では、公開作業をチームで進めるための確認事項を、実務の順番に沿って整理します。
1. 公開担当と確認担当を決める
確認する項目より先に、確認する担当者を決めます。
「誰かが見るはず」で進めず、項目ごとに、確認する人と最終的に公開可否を判断する人を決めておきます。
小さなチームなら、一人が複数の役割を兼ねてもいいです。
ただし、今どの役割として確認しているのかを分けておくと、確認の抜けに気づきやすくなります。
役割 | 主な担当内容 |
|---|---|
公開担当 | 公開時刻の管理、切替作業、完了連絡 |
内容確認 | 文章、料金、連絡先、画像、ページの不足 |
表示・動作確認 | 端末表示、リンク、ボタン、フォーム |
技術担当 | ドメイン、HTTPS、転送、検索設定、計測 |
最終承認 | 未解決事項を確認し、公開可否を決める |
外部の制作会社が公開作業をやる場合も、自社側に確認担当と承認者は要ります。
公開担当へ「全部見ておいて」と任せると、文章や料金が正しいかを見る作業と、サーバーや検索の設定を見る作業が、一人に集まります。
必要な知識がそれぞれ違うため、どちらかの確認が浅くなりがちです。
当日の連絡を詰まらせないために、次の情報を一枚へまとめます。
- 担当者名と連絡方法
- 確認する項目
- 確認期限
- 完了を記録する場所
- 判断できない場合の相談先
- 公開を止める条件
公開を止める条件は、たとえば「問い合わせが送れない」「誤った料金が表示される」「主要ページが開かない」など、影響が大きいものへ絞ります。
文字の余白や追加説明は、操作や理解を妨げない軽微なものなら、担当と期限を決めて公開後へ回す判断もできます。
最終承認者（または承認会議）と、判断を集約する窓口をはっきりさせます。確認担当が複数いても、結論を記録して公開担当へ伝える窓口が決まっていれば、未解決の項目を抱えたまま作業が止まりにくくなります。
2. コンテンツの最終確認
ページの内容は、記憶を頼りにせず、元になる資料と見比べます。
どの資料を正しい内容の基準にするかは、確認を始める前に決めます。
ページ一覧、料金表、会社情報、サービス資料などが基準になります。
ページ単位の確認
- 公開対象のページがすべてそろっている
- 公開しないページが下書き・非公開になっている
- メニューとページ一覧の内容が合っている
- ページ名とURLの対応を記録している
- 各ページの確認担当と結果が分かる
文章と情報の確認
- 会社名、屋号、サービス名の表記がそろっている
- 料金、追加費用、支払条件が原資料と合っている
- 住所、電話番号、メールアドレスに誤りがない
- 営業時間、定休日、対応地域、納期が現在の内容になっている
- 日付、年度、募集期間に古い情報が残っていない
- 仮文章、制作メモ、見本の人物名が残っていない
- 問い合わせ後の流れと返信時期が運用に合っている
同じ料金や連絡先を複数のページに載せている場合、管理画面の検索・置換で直すだけでは終わりません。
実際に表示されるページを開くと、どのページも新しい内容になっているかが分かります。
画像の中の文字、PDF、ダウンロード資料も、古い情報が残りやすいところです。
画像とリンク先の確認
- 見本画像や仮ロゴが残っていない
- 画像の利用条件と必要な表記を確認した
- 重要な画像に内容に合う代替テキストがある
- PDFや資料が最新版になっている
- 外部リンクが現在の情報へ移動する
- 公開後に見せたくない確認用ファイルへリンクせず、URLを知っていても閲覧できない状態を確認した
法務、権利、取引条件で専門的な判断が要る内容は、確認担当の感覚だけで完了になりません。
当てはまる分野の公的情報を調べるか、専門家へ確かめて、確認した日と判断した人を記録に残しておくと、あとで経緯をたどれます。
判断できなかった項目は、誰に確認するかと確認の期限まで一覧へ書き残します。
料金や安全性など公開判断に関わる未確認は、担当と期限を書いただけで完了とせず、承認者へ戻して公開可否を決めます。
3. 機能・表示の最終確認
機能と表示は、実際の端末で、利用者と同じ操作をして確かめます。
確認用のページを開いて眺めるだけでは足りません。
トップページから問い合わせへ進むなど、想定する流れをたどり、どの操作で止まるかを記録します。
端末と表示の確認
- パソコンとスマートフォンで主要ページを開いた
- 想定する主要ブラウザで主要な流れを試した
- 文章、画像、表が画面外へ不自然にはみ出していない
- メニュー、固定ボタン、案内表示が本文を隠していない
- 文字を読み、ボタンを押し、入力欄へ入力できる
- 画像が欠けたり、不自然に切れたりしていない
画面が狭くなっても内容と機能が失われないようにする考え方は、W3Cのリフローに関する解説で説明されています。
スマートフォン表示の点検にも役立ちますが、手元の画面で問題がないだけで、この基準を満たしたとは判断しません。
ページ全体に横スクロールが出る場合は、原因になっている画像、表、部品まで記録します。
表や地図など二方向の配置が必要な部分には例外もあるため、部分的なスクロールとページ全体のはみ出しを分けて見ます。
ナビゲーションと機能の確認
- ロゴ、メニュー、パンくずから予定したページへ移動できる
- 主要ボタンの言葉と移動先が合っている
- 電話とメールのリンクが正しい番号・宛先の画面へ進む（発信・送信は許可された範囲だけ）
- サイト内検索を設置している場合、主要ページを探せる
- 404などのエラーページから主要ページへ戻れる
- SNSなどで共有したときのタイトル、説明、画像が予定どおりか確認した
共有したときの表示は、SNS側の仕様や、SNSがページの情報を読み込んだ時期によっても変わります。
実際に使う予定のSNSで、許可された公開範囲内で確認すると、予定とのずれに気づけます。
確認のために、未公開情報や閲覧制限のある確認用URLをSNSへ投稿しないようにします。
フォームの確認
送信前に管理者と通知先の了承を取り、通知・予約・課金など連携先への影響と、試験後の片づけ方を確認します。
準備できない場合は送信前で止めて「未確認」と残し、予約や決済を伴うものは利用サービスの公式手順に沿って担当者が試します。
- 必須・任意と入力方法が分かる
- 入力エラーの場所と直し方が分かる
- 許可された手順とテストデータで送信できる
- 完了画面や完了メッセージが表示される
- 自動返信を設定している場合、利用者側へ届く
- 運営者側の正しい宛先へ通知が届く
- 個人情報の案内へ移動できる
項目名、入力方法の説明、エラー表示、送信後の案内をどう用意するといいかは、W3Cのフォームに関するチュートリアルが参考になります。
フォームのテストには本物の顧客情報や決済情報を使わず、用意したテストデータだけを使います。
テストデータの削除や試験用設定を戻す作業を誰がいつ行うかも、始める前に決めます。
完了表示と実際の受信を別々に確かめ、試験が終わったら、決めた後処理まで記録します。
表示、リンク、フォームを試す具体的な順番は、「Webサイトのリリース前テスト入門」で確認できます。
4. 公開設定と切替手順の確認
公開作業では、変更する項目と順番を、事前に一枚へまとめます。
当日に口頭で決めるのではなく、担当者、開始時刻、完了条件、元へ戻す条件まで書いておきます。
基本の流れは次のとおりです。
- 現在のサイト、設定、データのバックアップと復元方法を確認する
- 公開対象の最終版を確定し、公開作業中の編集を止める
- ドメイン、DNS（ドメインの接続先を指定する設定）、HTTPS（通信の暗号化）、リダイレクト（別URLへの転送）、検索設定、計測の変更内容を確認する
- 最終版と未解決事項について承認者の公開可の判断を記録してから、決めた担当者が本番環境へ切り替える
- 本番URLで表示、許可されたフォーム試験、転送、検索設定、必要な計測を確認する
- 結果を記録し、関係者へ公開完了または切り戻しを連絡する
バックアップは、保存場所と担当者だけでなく、必要なデータが含まれ、利用環境に合う復元手順があるかまで見ます。
切り戻す場合に、切替後の新しい問い合わせや注文を失わないよう、保存と引継ぎの方法も技術担当と決めておきます。
IPAの中小企業向け情報セキュリティ対策ガイドラインでは、バックアップやWebサイトの安全な運用を含む、中小企業向けの情報セキュリティ対策が案内されています。
ドメインやサーバーの設定は影響する範囲が大きいので、意味の分からない項目を推測で変更してはいけません。
URLを変更する場合は、古いURLごとに、内容が対応する新しいURLと転送方法を一覧へ残します。
引継ぐ内容がないページは、無関係なトップページへまとめて転送せず、終了後にどう応答させるかを技術担当と決めます。
Googleのサイト移転に関する公式資料では、URL変更時の永続的なサーバー側リダイレクトや、サイトマップなどの手順が案内されています。
制作中のページを検索結果へ出さないためのnoindex（対応する検索エンジンへ、そのページを検索結果に載せないよう伝える指定）が、公開するページに残っていないかも確かめます。
ただし、noindexをすべてのページから一度に外すのは避けます。
問い合わせの完了ページのように、公開後も検索結果へ出したくないページがあります。
会員向け・管理用ページや確認用ファイルを見せないためには、検索除外とは別に、認証やアクセス権で閲覧を制限します。
Googleがnoindexを読み取るには、そのページへアクセスでき、robots.txt（クロールを制御するファイル）で遮断されていない必要があります。
noindexを使う条件は、Googleの公式資料で確認できます。
切替の前に、元へ戻す条件を決めます。主要ページが開かない、問い合わせを受け取れないなど、影響が大きい問題が起きたときの連絡先と判断者も決めておきます。
5. 公開後の確認と連絡先
公開完了の連絡を出す前に、本番URLで主要な流れをもう一度たどります。
確認用の環境と本番環境ではURLや設定が違うため、公開前に見た項目も省略せずに確かめます。
公開直後の確認
- 正式なURLが
https://で開く - トップページと主要ページが表示される
- メニュー、画像、資料のリンクが本番URLで開く
- 本番での影響を確認した許可済みの試験で、完了表示と通知の受信を確認できる
- 古い主要URLから新しい対応ページへ移動できる
- 公開したいページに意図しない検索除外が残っていない
- アクセス解析を使う場合、必要な設定を済ませ、予定したアカウントへ記録される
- サイトマップ（検索エンジンへURLを知らせるファイル）に、検索へ出したい対象URLが含まれている
権限のある担当者は、Search Console（Google検索での自社サイトの状態を調べるツール）のURL検査ツールで、Googleが持つ登録情報を確認します。
公開直後の状態は一般公開URLテストでも確かめますが、保存された登録情報とは分けて読みます（2026年10月27日確認）。
このテストはすべての登録条件を調べるものではなく、問題が出なくても検索結果への掲載は保証されません。
登録状況の確認は、トップページと重要なサービスページから始めると進めやすいです。
公開後の連絡先
状況 | 最初の連絡先 | 記録する内容 |
|---|---|---|
文章・料金の誤り | 内容確認担当 | URL、誤り、正しい原資料 |
表示・リンクの不具合 | 制作・表示確認担当 | 端末、ブラウザ、画面、操作 |
フォーム通知の不具合 | フォーム・メール担当 | 送信時刻、入力種別、受信状況 |
ドメイン・サーバー障害 | 技術担当・契約先 | 発生時刻、対象URL、エラー |
法務・安全性の問題 | 責任者・専門窓口 | 影響範囲、公開状態、対応記録 |
緊急時の連絡方法は、問題が起きたサイトの中だけに置かず、別の共有場所にも残します。
公開後に誰が文章を更新し、誰がドメインやサーバーを管理するのかも決めておきます。制作会社の保守がどこまでを含むのかも、公開前の確認に入ります。
制作会社から受け取る管理権限や資料は、「制作会社から納品されたホームページはどこを見る？」で詳しく整理しています。
まとめ
担当者向けの最終チェックを、公開の流れに沿って振り返ります。
- 公開、内容確認、技術対応、最終承認の担当者を決める
- コンテンツをページ一覧と原資料へ照らして確認する
- 端末表示とリンクを確認し、フォームは許可と準備が整った範囲で試す
- バックアップ、切替順、切り戻し条件を決める
- 公開後の再確認と不具合時の連絡先を残す
担当者全員が同じ作業を抱えるものではありません。
誰が何を確認し、どこへ完了を記録するかが分かれば、チームで動きやすくなります。
公開、内容確認、技術対応、最終承認の担当者名を、先に一枚へ書き出します。
並べてみると、まだ決まっていない役割がはっきりします。
