ホームページ公開前チェックリスト｜発注側と制作会社の確認を分ける

ホームページの公開前確認は、項目を増やすだけでは終わりません。先に決めたいのは、誰が判断する項目か、何をもって確認済みとするか、最後に誰が公開を承認するかです。

発注側は、会社情報、サービス内容、表現、連絡先、写真や文章の権利、社内承認など、「その内容を世の中へ出してよいか」を確認します。制作会社は、表示、リンク、フォーム、検索向け設定、計測、セキュリティ、バックアップなど、「公開できる技術状態になっているか」を確認します。フォームの送信から通知、計測までのように両者の仕事がつながる部分は、共同で一往復させます。

この分け方をしないと、発注側は技術項目まで背負い、制作会社は事業上の事実まで正しいと判断したつもりになりがちです。以下では、担当、確認方法、証拠、公開可否を一つの一覧へまとめる方法と、そのまま使える公開前チェックリストを示します。

公開前チェックリストは、項目より先に「誰が判断するか」を決める

公開直前に「全ページを確認してください」とだけ依頼しても、確認者ごとに見る場所が変わります。文章を読んだ人はリンクを見落とし、表示を確認した人は価格や対象地域の正誤まで判断できません。そこで、チェックリストには項目名だけでなく、最低でも次の欄を持たせます。

• 確認項目
• 主担当
• 確認するURLまたは画面
• 確認方法と合格条件
• 結果と証拠
• 未解決事項、期限、対応者
• 最終承認者

主担当は「作業した人」ではなく、「正しいかを判断できる人」です。たとえば制作会社が会社概要ページを実装しても、所在地や代表者名が正しいと最終判断できるのは発注側です。反対に、発注側がスマートフォンでページを見ても、対象ブラウザの範囲、リダイレクト、noindex、計測タグの発火条件まで責任を持つのは難しいため、制作会社が技術的な確認結果を示します。

確認領域	主に判断する側	もう一方の役割	確認済みの証拠例
会社情報、サービス内容、価格、営業条件	発注側	制作会社は指定内容を正しく反映	元資料名、確認者、確認日
表現、写真、文章、ロゴ、掲載許可	発注側	制作会社は掲載箇所とファイルを照合	許可記録、出典、対象URL
表示、リンク、メニュー、ダウンロード	制作会社	発注側は重要ページの使い勝手を確認	端末別の画面、検査結果
フォーム、通知、自動返信、受付後の運用	共同	両者が同じテスト送信を追う	送信内容、受信時刻、通知画面
SEO設定、サイトマップ、計測	制作会社	発注側は計測したい行動とページ名を確認	設定画面、ソース、テストイベント
公開日時、未解決事項、公開可否	発注側が最終承認	制作会社は技術判定と戻し方を提示	承認記録、公開手順、戻し条件

発注側・共同確認・制作会社の担当を分け、最後に一つの承認記録へまとめます。

この三つの担当区分を作ったうえで、チェックリストは一つに統合します。発注側用と制作会社用を完全に別ファイルへ分けると、フォームや公開日時のような接点が抜けやすいからです。一つの表の中で「発注側」「制作会社」「共同」を明記し、同じ項目について別々の合格条件がある場合は行を分けます。

状態も「済／未」だけでは足りません。実務では、すぐ直す誤り、公開後の対応でよい軽微な修正、確認待ち、仕様として許容する差が混在します。少なくとも「OK」「修正中」「要判断」「公開後対応」のように状態を分け、公開後対応にする項目には担当者と期限を入れます。そうすれば、未解決が残っていても、何を承知して公開したのかが分かります。

発注側が確認するのは、画面の完成度ではなく「公開してよい内容」

発注側の確認では、見た目の好みから入るより、事業上の事実と約束から見ます。公開後に影響が大きいのは、色の微差よりも、電話番号、価格、受付条件、対応範囲、申込先の間違いです。元になった会社資料、商品資料、社内規程、許諾記録と照合し、ページを眺めた印象だけで「たぶん合っている」と済ませません。

最初に、会社名、所在地、電話番号、メールアドレス、営業時間、休業日、代表者名などの基本情報を確認します。ヘッダー、フッター、会社概要、問い合わせページなど、同じ情報が複数箇所にある場合は、すべて同じになっているかを見ます。画像の中へ文字として入っている情報、PDF、構造化データ、問い合わせ後の自動返信文にも古い連絡先が残ることがあるため、ページ本文だけで終わらせません。

次に、サービス名、対象者、提供範囲、価格、税の表示、追加条件、申込期限、納期、対応地域などを、公開時点の正式資料と照合します。条件が複雑な場合は、短く見せるために重要な例外を消していないかも確認します。「必ず」「最短」「業界初」「No.1」のように、根拠や適用範囲が必要な表現は、制作会社が文章を整えたから正しいのではなく、発注側が根拠を示せるかで判断します。

写真や文章の権利も発注側の重要な確認です。社員や顧客が写る写真、取引先のロゴ、口コミ、事例、制作物、商品写真、地図、外部サイトから引用した文章などについて、Web掲載の許可範囲と期限を確かめます。撮影を依頼した写真でも、契約によって利用範囲が異なることがあります。制作会社は掲載箇所を一覧にできますが、誰からどの条件で許可を得たかは、発注側で記録しておく必要があります。

プライバシーポリシー、利用規約、特定商取引に関する表示、免責事項などは、サイトの種類や事業によって必要性と内容が変わります。既存サイトの文章をそのまま移す場合も、現在の受付方法、取得する個人情報、外部サービス、保存や利用の実態と一致しているかを確認します。法律や業界規制に関わる判断を制作会社だけへ委ねず、必要に応じて社内の責任者や専門家へ確認します。

最後に、ページ内の行動案内を事業の流れと照合します。問い合わせ、予約、資料請求、購入、電話など、読者にしてほしい行動が現在の受付体制と合っているか、担当部署が実際に対応できるかを見ます。たとえば「当日中に返信」と書いていても運用できなければ、フォームが動いていても公開内容としては未完成です。

発注側の確認を進めやすくするには、ページごとに自由記述で感想を集めるのではなく、次の順序にします。

1. 元資料と照合し、事実の誤りを直す
2. 読者に約束する条件と例外を確認する
3. 写真、文章、ロゴ、事例の掲載許可を確認する
4. 問い合わせ後に社内で対応できるかを確認する
5. 最終承認者が、残課題を含めて公開可否を判断する

部署ごとに確認を回す場合も、全員へ全ページを送る必要はありません。総務は会社情報、営業はサービス条件、採用担当は募集内容、法務や管理部門は規約と権利というように、判断できる範囲だけを渡します。意見が分かれたときに決める最終承認者を先に置くと、「全員の返事待ち」で公開日だけが近づく状態を避けられます。

制作会社は、閲覧環境が変わっても使える状態と検索・計測の設定を確認する

制作会社の確認は、制作中の端末で見た一画面が整っているかではなく、公開環境へ移した後も主要な機能が使えるかを確かめる作業です。対象とするブラウザや端末は無限ではないため、プロジェクトで合意した範囲を基準にします。そのうえで、少なくともパソコンとスマートフォンの主要な画面幅で、ヘッダー、メニュー、追従要素、表、フォーム、動画、埋め込み、フッターまで確認します。

表示確認では、文字や画像が枠からはみ出していないかだけでなく、操作を妨げる重なりがないかを見ます。固定ヘッダーやバナーが見出しを隠す、Cookie同意表示が送信ボタンへ重なる、横長の表が画面外へ飛び出す、モーダルを閉じられない、といった問題は、静止画では気づきにくいため実際に操作します。キーボードだけでメニューやフォームを移動できるか、現在位置が見えるか、重要な機能が特定のマウス操作だけに依存していないかも確認対象です。

リンクは、機械的な検査と人の操作を組み合わせます。内部リンク、外部リンク、電話、メール、PDF、地図、SNS、パンくず、ロゴ、ページ内リンクを確認し、リンク先が正しいだけでなく、公開環境のURLになっているかを見ます。テスト環境のドメイン、仮のファイル名、アクセス制限付きURLが残っていないかは、全体検索でも確認します。リニューアルでURLが変わる場合は、旧URLと新URLの対応表を作り、重要ページだけでなく、旧サイトから流入していた記事や資料もリダイレクト対象に含めます。

検索向けの設定では、各ページのタイトル、説明文、正規URL、インデックス可否、サイトマップ、内部リンクを確認します。特にテストサイトで使っていたnoindexが本番へ残ると、公開したページがGoogle検索へ出ない原因になります。robots.txtでクロールを制限している場合は、noindexの確認とは別に扱います。サイトマップには本番で公開するURLが入っているか、テストURLや非公開ページが混ざっていないかを見ます。サイトマップの送信はURLの発見を助けますが、掲載を保証するものではないため、公開後はSearch ConsoleのURL検査やインデックス状況でも確かめます。

計測は、タグが設置されているかだけでは合格にしません。公開前の環境で検証できる範囲を確認し、公開直後に本番URLでページ閲覧、主要ボタン、フォーム完了など、計測対象の操作を実行します。GA4ではリアルタイム表示やDebugViewを使い、期待したイベント名とページ情報が届くかを確かめます。外部予約フォームや別ドメインへ移動する導線、Cookie同意の状態、広告計測がある場合は、通常のページ閲覧より条件が複雑になるため、どの状態を合格とするかを先に決めます。

セキュリティ確認では、「安全です」と一言で済ませず、公開時に必要な具体項目へ分けます。HTTPSで表示されるか、HTTPから適切に転送されるか、管理画面やサーバーの不要な共有アカウントが残っていないか、利用中のCMS・テーマ・プラグインがプロジェクトで採用した状態になっているか、フォームに必要な迷惑送信対策があるかを確認します。公開作業に使った一時的なアクセス権やテスト用データは、削除または権限変更の担当と時期を決めます。

制作会社が提出する確認結果は、「確認しました」という報告だけでなく、発注側が公開可否を判断できる形にします。対象URL、確認端末、確認日、検査結果、残課題、影響、対応予定を示し、重要な設定は画面や出力結果を証拠として残します。技術用語を並べるのではなく、「このまま公開すると何が起きるか」「公開後対応でよい理由は何か」が分かる説明にします。

フォームは発注側と制作会社が同じ操作を一往復して確かめる

問い合わせフォームは、入力画面が表示され、完了画面へ進めただけでは確認不足です。読者が入力してから、社内担当者が内容を受け取り、返信を始められるところまでを一つの流れとしてテストします。技術的に送信できても通知先が退職者のアドレスなら、事業上は使えません。反対に、通知先が正しくても、必須項目の設定やエラー表示が壊れていれば利用者は送れません。

共同テストでは、一つのテスト送信に識別しやすい件名や本文を入れ、次の順に追います。

1. パソコンとスマートフォンで入力し、必須・任意、文字数、形式、同意欄、エラー表示を確認する
2. 送信前の確認画面がある場合は、戻って修正しても入力内容が不自然に消えないか確認する
3. 送信後に完了画面が出て、連打や戻る操作で意図しない重複送信が起きないか確認する
4. 発注側の通知先へ、入力内容と送信元ページを判断できるメールが届くか確認する
5. 利用者向けの自動返信がある場合は、差出人名、返信先、本文、案内内容を確認する
6. 迷惑メールフォルダー、転送、共有メールボックス、担当者への振り分けを含めて、実際の受付手順を確認する
7. フォーム完了を計測する場合は、完了イベントが一回だけ記録されるか確認する

発注側は、質問項目が受付業務に必要か、通知文を見て担当者が対応を始められるか、自動返信の案内が実際の返信目安や連絡方法と一致するかを判断します。制作会社は、入力制御、送信処理、通知先、差出人設定、迷惑送信対策、完了画面、計測を確認します。両者が別々のテストデータを使うより、同じ送信を送信側と受信側で追跡すると、どこで止まったかが分かります。

電話、予約システム、ECの注文、資料ダウンロードなど、フォーム以外の主要導線も考え方は同じです。リンク先へ移動できるかだけでなく、予約枠の表示、決済前後の案内、ダウンロードファイル、社内通知、担当者の次の作業までを、可能な範囲で実際に一往復させます。本番決済のようにテスト方法が限られる場合は、決済事業者のテスト環境、少額テスト、公開後の即時確認など、採用する方法と責任者を公開手順へ記録します。

公開作業ではバックアップの有無より、戻す条件と担当者を決める

バックアップは「取ってあります」で終わらせず、何が含まれ、どこにあり、誰が戻せるかを確認します。WordPressの一般的なサイトでは、ファイルとデータベースの両方が復元に必要です。サーバー会社の自動バックアップだけに頼る場合も、取得時刻、保存期間、復元の依頼方法、復元に必要な権限を確認します。

公開直前に一式を保存しても、戻す判断が決まっていなければ、障害発生時に「修正を続けるか、旧状態へ戻すか」で時間を使います。公開手順には、少なくとも次を入れます。

• 公開前に変更を止める時点
• バックアップする対象と取得時刻
• 公開作業の担当者と連絡手段
• 公開後に確認する代表ページと主要機能
• 公開を中止または元へ戻す条件
• 戻す作業を行う人と必要な権限
• 旧サイトやメンテナンス表示の扱い
• 復旧後に発注側へ報告する内容

戻す条件は、軽微な余白のずれまで一律にする必要はありません。トップページが表示できない、主要フォームが受信できない、HTTPSやドメイン転送に問題がある、重要なページが誤ったURLへ移動する、公開してはいけない情報が見える、といった事業影響の大きい状態を基準にします。文言の軽微な修正や一部端末の装飾差は、影響と対応時期を記録したうえで公開後対応にできる場合があります。

新規サイトとリニューアルでも注意点が違います。新規サイトでは、ドメイン、メール、検索向け設定、問い合わせ受付の立ち上がりを重点的に見ます。リニューアルでは、旧URLからのリダイレクト、旧サイトの更新停止、メールや外部サービスへの影響、既存の計測設定、検索流入のあるページの移行を追加します。旧サイトをすぐ削除せず保持する場合は、誰がアクセスできる状態で、いつまで保管するかも決めます。

公開後の確認時間も担当者の予定へ入れておきます。公開作業を終えた直後は、キャッシュやDNS、外部サービスとの連携など、テスト環境と異なる条件が表れます。制作会社が技術確認をし、発注側が主要ページと受付を確認し、問題の連絡先を一本化しておくと、同じ不具合が複数経路から重複して届くことを防げます。

最終承認は未解決項目を隠さず、公開可否と残作業を記録する

公開前の最終承認は、すべての指摘をゼロにする儀式ではありません。公開を止める問題、公開前に直したい問題、影響を理解したうえで公開後に回せる問題を分け、誰がどの状態を承認したかを残す作業です。

公開を止める候補には、会社情報や価格など重要事実の誤り、掲載許可のない情報、主要ページが見られない状態、フォームが受信できない状態、公開対象全体へnoindexが残っている状態、HTTPSやドメインの重大な不具合、戻し方が用意されていない大規模な切り替えなどがあります。ただし、どの問題を停止条件にするかはサイトの目的や公開方法によって変わるため、プロジェクトの責任者が事前に決めます。

一方、公開後対応にできることは、事業影響が限定され、代替手段があり、対応者と期限が決まっているものです。「時間がないから残す」だけでは承認になりません。対象URL、現在の状態、利用者への影響、暫定対応、修正予定を一覧へ入れます。公開後に直す項目が増えた場合は、優先順位を付け、公開直後の確認項目と混ぜません。

最終承認記録には、次の内容があれば、後から経緯を追いやすくなります。

• 対象サイトと確認した環境・版
• 公開予定日時
• 発注側の内容確認者と最終承認者
• 制作会社の技術確認者
• 未解決項目、影響、対応者、期限
• バックアップの場所と戻す担当者
• 公開後に確認するURLと機能
• 公開作業中の連絡方法
• 公開可否を判断した日時

承認は専用システムでなくても構いませんが、メール、チャット、表計算、タスク管理へ分散させず、最終的な判断が一か所で分かるようにします。口頭で承認した場合も、制作会社が内容を文章にして発注側へ返し、認識違いがない状態にします。修正版を再提出したときは、どの版を承認したかが分かるよう、URL、更新日時、ファイル名などを記録します。

そのまま使えるホームページ公開前チェックリスト

以下は、新規制作と一般的なリニューアルの両方で使える基本形です。サイトに予約、決済、会員機能、多言語、外部システム連携などがある場合は、その機能の入力から社内処理までを追加してください。合格条件は案件ごとに具体化し、「見た」「大丈夫そう」ではなく、確認方法と証拠を残します。

No.	確認項目	主担当	合格条件・確認方法
1	会社名、所在地、電話、メール、営業時間	発注側	正式資料と照合し、全掲載箇所が一致
2	サービス名、対象者、範囲、価格、条件	発注側	現行の正式資料と一致し、重要な例外を省いていない
3	日付、受付期間、納期、休業案内	発注側	公開日以降も有効な内容になっている
4	実績、比較、保証、強い訴求表現	発注側	根拠と適用範囲を確認できる
5	写真、文章、ロゴ、口コミ、事例の権利	発注側	Web掲載の許可と利用範囲を記録済み
6	プライバシー、規約、法令・業界上の表示	発注側	実際の取得情報と運用に一致し、必要な確認を完了
7	問い合わせ・予約・購入後の社内対応	発注側	通知先、担当者、返信や処理の流れが決まっている
8	社内確認と最終承認者	発注側	誰が最終判断するか、承認期限とともに明記
9	パソコン・スマートフォンの表示	制作会社	合意した端末・画面幅で主要ページと共通部品を操作確認
10	メニュー、固定要素、表、モーダル	制作会社	内容を隠さず、開閉・移動・スクロールができる
11	内部リンク、外部リンク、電話、メール、PDF	制作会社	リンク切れやテストURLがなく、意図した先へ移動
12	画像、動画、埋め込み、代替情報	制作会社	表示と再生に問題がなく、必要な代替情報を設定
13	フォーム入力、エラー、完了画面	制作会社	想定入力と誤入力の両方で挙動を確認
14	通知メール、自動返信、迷惑メール対策	共同	同じテスト送信を送信側と受信側で追跡し、受付できる
15	HTTPS、HTTPからの転送、公開ドメイン	制作会社	主要URLがHTTPSで表示され、意図しないURLへ分岐しない
16	ページタイトル、説明文、正規URL	制作会社	各ページの役割と公開URLに合う設定になっている
17	noindex、robots.txt、サイトマップ	制作会社	公開・非公開の意図と一致し、サイトマップが本番URLを示す
18	旧URLからのリダイレクト	制作会社	リニューアル時の対応表どおりに代表URLを実測
19	GA4などのデータ収集	制作会社	本番操作がリアルタイムまたはデバッグ画面で確認できる
20	主要行動のイベント計測	共同	ボタンやフォーム完了が想定どおり一回記録される
21	管理者、共有アカウント、不要な権限	制作会社	公開後に必要な人だけが必要な権限を持つ
22	CMS、テーマ、プラグイン、外部連携	制作会社	採用した構成と版を記録し、更新・接続状態を確認
23	ファイルとデータベースのバックアップ	制作会社	復元に必要な一式、取得時刻、保存場所を記録
24	公開中止・切り戻し条件と担当者	共同	条件、連絡先、権限、戻す手順を共有済み
25	未解決事項と公開可否	発注側が最終承認	影響、対応者、期限を確認し、対象版を明記して承認

チェックリストを渡すタイミングも重要です。公開直前に初めて見せるのではなく、制作の途中で発注側の確認項目を共有し、写真の許可や社内承認のように時間がかかる作業を先に動かします。制作会社の技術確認は実装後に行いますが、対象ブラウザ、計測する行動、URL変更、公開方法、バックアップ方針は設計段階で合意しておくと手戻りを減らせます。

発注側へ確認を依頼するときは、サイト全体のURLだけを送りません。「会社概要は基本情報」「サービスページは価格と条件」「フォームは通知と自動返信」のように、ページごとの判断事項を添えます。制作会社側も、技術検査の結果を長い専門用語の一覧にせず、公開停止か、公開前修正か、公開後対応かを付けて返します。

近い既存記事との使い分け

この記事が扱うのは、完成したホームページを公開してよいか判断する直前の工程です。見積もり比較や制作会社選びの段階では、対応範囲、追加費用、契約、所有、公開後の支援を確認します。公開後は、事実の更新、問い合わせ内容の変化、検索やアクセスの反応を見ながら改善の優先順位を付けます。

そのため、公開前の承認が終わった後の運用まで同じチェックリストへ詰め込まないほうが管理しやすくなります。公開後に何を更新するかは、ホームページ公開後、何を更新する？小さな事業の優先順位で、事実の変更、問い合わせにつながるページ、計測結果の順に分けて確認できます。

まとめ｜発注側は内容を、制作会社は公開できる状態を確認する

ホームページ公開前チェックリストは、確認項目の多さより、責任の境目が明確であることが重要です。発注側は、事実、表現、連絡先、権利、受付体制、社内承認を確認します。制作会社は、表示、リンク、機能、検索向け設定、計測、セキュリティ、バックアップを確認します。フォーム、通知、主要行動の計測、公開日時、切り戻し、最終承認は、両者が同じ記録を見て共同で閉じます。

一つの一覧に主担当、合格条件、証拠、未解決事項、期限、最終承認者を入れれば、「誰かが見たはず」という状態を減らせます。公開後に直す項目が残る場合も、影響と担当を承認記録へ残しておけば、公開可否と残作業を混同せずに進められます。