ホームページの公開前チェック｜確認用サイト・動作テスト・修正確認の進め方

制作会社から「確認用のホームページができました」とURLが届いたら、まず何を見ればよいでしょうか。トップページの印象や誤字を確認するだけでは、スマートフォンでメニューを閉じられない、資料が旧版のまま、問い合わせの通知が届かない、といった問題を見落とす場合があります。公開前には、掲載する情報と、利用者や更新担当者が行う操作をセットで確かめましょう。

この記事は、企業サイトの制作・リニューアルを発注し、動く確認用サイトを受け取った経営者や担当者に向けた実務ガイドです。確認範囲の決め方、ページとリンク、画面の状態、フォーム、WordPressなどの更新機能、修正の伝え方、公開後の照合までを整理します。制作会社の技術試験に加えて、発注者が自社の業務や掲載原稿と照らし合わせるために使ってください。

GOV.UK、W3C、Google、WordPressの一次資料を参照しています。資料の確認日は2026年9月10日です。記事中の設備会社、修正メモ、日程は説明用の架空例で、特定のお客様の案件や成果ではありません。デザイン案の見方はデザイン確認とフィードバックの記事、利用者が迷う理由を観察する方法はLPのユーザーテストの記事で詳しく説明しています。

1. 確認用サイトを開く前に、対象と完成範囲を揃える

同じURLと、同じ更新状態を見ているか確認する

確認を始める前に、制作会社から届いた案内を読み、今回使うURL、更新された日時、対象ページを揃えます。以前の確認URLをブックマークしていた場合や、チャットの古いリンクから開いた場合には、修正前の画面を見ている可能性があります。「直っていません」と伝える前に、開いているページのURLと確認日時をメモしましょう。

URLが同じでも、制作中は内容が更新されます。社内で複数人に確認を頼むなら、「本日午後に共有された版を、明日の午前中までに確認」のように区切ると、意見を集めやすくなります。その間に修正が入る場合は、制作会社に変更箇所を知らせてもらいます。画面のスクリーンショットだけでは版が分かりにくいため、共有メモにも日付を残します。

「サイト全体を確認してください」という依頼が曖昧なら、ページ一覧を添えて対象を決めます。トップ、サービス、事例、会社情報、問い合わせのようなページ単位に加え、メニューやフッターなど共通部分も含めます。確認済みの印は、実際に見たページと操作に付けることが大切です。

見た目の完成と、機能の完成を分けて聞く

確認用サイトには、まだ動かないボタン、仮の文章、仮画像、送信を止めているフォームが含まれることがあります。これらを不具合と混同しないよう、「今回試せる機能」「次回確認する機能」「公開時だけ設定する項目」を制作会社に確認します。未実装の機能は、予定と確認担当を記入しておきましょう。

例えば、資料請求の画面ができていても、自動返信に資料URLを載せる処理は未接続かもしれません。その状態なら、入力欄の説明や画面遷移は確認できても、資料が届くところまでは完了にできません。反対に、送信処理は完成していても原稿が仮なら、機能だけを先に試し、掲載内容は後日確認する進め方ができます。

確認用サイトの呼び名だけで品質を判断する必要はありません。「テスト環境」「ステージング」「プレビュー」などの名称より、公開サイトと何が同じで、何が異なるかを聞く方が具体的です。ログインの有無、メールの宛先、決済や予約との接続、登録データの保存先などは、試す前に違いを把握します。

GOV.UKの公開手順から、確認場所の役割を学ぶ

英国政府の公開前環境についてのガイドは、開発する場所、変更をまとめる場所、公開環境に近い条件で試す場所の役割を説明しています。2016年公開の資料内にあるGOV.UKの例では、公開前の変更をチームが確認するためにステージングを使うと記されています。

この例から企業サイトに応用できるのは、制作途中の試行と、公開を判断する確認を区別する考え方です。同じ数の環境や同じツールを導入する必要がある、という意味ではありません。発注者は「今回の確認結果を、どの公開予定版に対して使えるのか」を制作会社と揃えれば、確認のやり直しを整理しやすくなります。

2. 掲載原稿と画面、リンク先の内容を照合する

社内で確定した原稿を手元に置く

画面だけを読んでいると、もっともらしい表現や古い数値を見逃すことがあります。社内で掲載を決めた原稿や資料を手元に置き、会社名、住所、電話番号、営業時間、サービスの対象、費用の条件などを照合します。制作会社は表示を整えられますが、現在の営業条件を最終判断するのは、その情報を管理する自社の担当者です。

お客様の名称や事例説明は、正式な表記、敬称、担当範囲、掲載できる写真を確認します。文章を短くした結果、自社が担当していない工程まで請け負ったように読めないかも見ます。実績の数字があるなら、原稿に示した期間や条件が省かれていないか確かめます。読みやすさと、事実を正確に伝えることを一緒に確認しましょう。

トップページに載る短い紹介文も対象です。詳細ページが正しくても、一覧の抜粋や画像の見出しに旧名称が残ることがあります。事例を一件確認するときは、一覧から詳細へ進み、関連紹介まで見ると、同じ情報が複数箇所で食い違っている状態を見つけやすくなります。

リンクは押して、到着したページまで読む

リンクの色が付いているだけでは、正しい行き先へ進めるとは限りません。「詳しく見る」を押して別サービスへ移動しないか、資料ボタンから最新版を開けるか、会社情報の地図が別拠点を示していないかを確認します。行き先が開いたら、そのページの見出しや資料の表紙も読み、期待した内容と一致するか確かめます。

PDFはファイル名だけで判断せず、本文の内容と版を見ます。例えば、ボタンには新しい年度が書かれているのに、開く資料が前年版という組み合わせも点検できます。資料の確認担当に、Webのボタンと開いたPDFを一緒に見てもらうと、サイトと社内資料を別々に承認するより食い違いを発見しやすくなります。

電話番号やメールアドレスのリンクは、文字列と設定された宛先の両方が対象です。意図せず電話やメールを送らないよう、動作確認の方法を制作会社と相談します。外部の予約サイトや地図が開く場合も、遷移したサービス名や店舗名を確認し、実際の予約や投稿はテストの対象に含めると決めた場合に限って行います。

ページ一覧に、見た場所と残った疑問を記入する

ページが多いときは、共通の型と固有情報を分けて点検します。事例詳細のレイアウトは代表的な長文・短文・写真の多いページで確認し、会社名や担当範囲などの固有情報は各事例で照合します。代表ページだけで全件の原稿が正しいと判断することも、全ページで同じ共通メニューを何度も記録することも避けられます。

記録は「会社情報：住所と電話番号を総務原稿に照合、地図の位置を確認。沿革の創業年は社内回答待ち」のように書きます。疑問を曖昧なままチェック済みにせず、誰の回答があれば判断できるかを残しましょう。公開日までに確定しない情報は、仮の数値を出すのかではなく、掲載範囲をどうするかから相談します。

リニューアルでは、以前の資料や営業メールに書いたURLからも訪問者が来ます。旧URLと新ページの対応は、全体の移行計画に含めて確認してください。原稿収集から整理したい場合は写真・原稿の準備ガイド、移行全体はリニューアルの進め方が参考になります。

3. PCとスマートフォンで、画面の状態を変えて操作する

最初の画面から、最後の案内までたどる

トップだけでなく、サービスの説明を読み、比較する情報を探し、問い合わせ入口へ進むところまで操作します。ページの下部では、追従ボタンが文章に重ならないか、フッターのリンクが押せるか、長い見出しが不自然に途切れないかを見ます。画像の多いページは、下まで移動して読み込みが終わった後も確認します。

端末やブラウザーの対象は、制作会社と合意した範囲を出発点にします。社内のPC一台で見えたことを、すべてのスマートフォンで問題ないという報告に置き換えないようにしましょう。確認した機種、ブラウザー、画面の向きが分かる記録があれば、制作会社も不具合を再現しやすくなります。

PC上のスマホ表示は、幅による変化を探す際に役立ちます。ただし、GoogleのChrome DevToolsの公式説明は、端末モードが実機の動きを近似するものであり、実際のモバイル端末上で動かしているわけではないと説明しています。画面幅の確認と、実機での入力や操作は、実施した内容を分けて記録します。

開く・閉じる・戻る・拡大する状態を試す

メニューを開いた状態、よくある質問を展開した状態、画像を拡大した状態など、初期表示とは違う状態も試します。開くことができても、閉じるボタンが画面の外へ出ることがあります。別ページへ移動した後に戻ったとき、メニューが不自然に残らないかも確認しましょう。

横に長い表は、右側の情報まで読めるかを確かめます。文字を小さくして一画面に押し込めることだけが解決ではありません。横スクロールの案内や項目名を頼りに読み進められるかを見ると、比較表として使えるかを判断できます。図解は、スマホで読みにくいときに拡大して内容を確認できるかも対象です。

ブラウザーで表示を拡大した場合には、文字が読める大きさになるだけでなく、ボタンや入力欄まで進めるかを見ます。画像の中へ入った文字は拡大しても読みづらい場合があるため、重要な条件が本文にも書かれているかを併せて確認すると、情報の抜けを探せます。

キーボード操作と、読める説明を点検する

マウスだけでなく、Tabキーでリンクや入力欄へ移動してみます。現在選ばれている場所が分かるか、順番が画面の流れに合うか、メニューを操作した後に先へ進めるかを確かめます。すべての専門試験を発注担当者が行う必要はありませんが、操作できなかった場所を報告することはできます。

W3CのEasy Checksは、ページタイトル、見出し、画像の代替テキスト、キーボードのフォーカス、拡大表示などの初歩的な点検を案内しています。同時に、簡単な点検だけでは網羅的な評価にならないと明記しています。この確認をしただけで、サイト全体がアクセシビリティ基準に適合したとは判断しません。

発注内容に専門的な評価が含まれる場合は、制作会社から対象ページ、方法、結果、残る課題の説明を受けます。自分が操作して困った箇所と、その評価結果を合わせると、改善の相談が具体的になります。見た目の好みと操作不能を同じ優先度にせず、利用者が仕事を進められるかを見て整理してください。

4. 問い合わせフォームは、入力から受付まで確かめる

試す前に、送信先とテストの扱いを共有する

フォームの試験は、制作会社と社内の受付担当を含めて準備します。確認用サイトの送信先、利用者向けメールの有無、保存される場所、外部システムとの連携を確認しましょう。本番の顧客対応と混ざるなら、テストと分かる名前や件名、実施時刻をあらかじめ共有します。実在するお客様の情報を試験用に流用する必要はありません。

入力には、テスト担当者が管理しているメールアドレスなど、確認に使える情報を選びます。自動返信が知らない人へ届くような架空の宛先は避けます。予約、見積もり発行、CRM登録などが連動する場合は、どこまで処理を動かすかを決めてから操作します。連携を止めた試験では、その範囲まで確認したと記録します。

例えば、設備会社の相談フォームで「現場写真を添付できる」仕様なら、添付を含む経路も必要です。通常の本文だけの送信が成功しても、添付付きの受付を確認したことにはなりません。試す項目は、実装された機能と普段受け付ける相談内容に合わせて選びます。

入力ミスから修正し、最後まで進めるかを見る

通常入力に加えて、必須項目の未入力や形式が違うメールアドレスなど、利用者が起こしやすい入力ミスを試します。エラーが表示されたら、どの項目をどう直せばよいか分かるか、ほかの入力が残っているか、修正後に先へ進めるかを確かめます。「赤い文字が出た」だけで終わらず、解消するところまで見るのがポイントです。

確認画面がある場合には、修正のために戻って入力内容を変え、再び確認画面へ進みます。問い合わせ種別を変更した際に、表示される項目や必要な入力が変わるなら、その条件も対象です。スマートフォンでは入力用キーボードが出たときに、欄の説明や次へ進むボタンを確認できるかを見ます。

試験のたびに無制限に送信する必要はありません。途中の入力確認と、受付まで通す送信を分け、送信する回数と目的を決めます。エラーが見つかった場合は、入力内容を必要な範囲で伏せた画面と、操作順を記録して制作会社へ伝えます。原因を推測して設定を変えるより、再現できる材料を渡す方が役立ちます。

完了画面、社内通知、利用者への案内を照合する

送信後は完了画面の文面を読み、次に何が起きるかが実際の受付体制と合うかを確認します。「当日返信」と表示されていても、社内で翌営業日の対応になるなら、案内か運用を揃える必要があります。電話が必要な場合の説明や、営業時間外の扱いも、受付担当に確認してもらいましょう。

社内の通知は、受信した事実だけでなく、名前、問い合わせ種別、本文、添付など必要な情報が読めるかまで見ます。利用者向けメールがある仕様なら、その受信と文面も確認します。完了画面が表示されたこと、社内通知が届いたこと、担当者が内容を確認できたことは別々の記録です。

受信を確認できない場合は、同じ操作を何度も繰り返す前に、送信時刻と試験用の識別情報を制作会社へ伝えます。未着なのか、宛先が異なるのか、通知まで未接続なのかを切り分けてもらいます。入力や受付の設計そのものを見直す場合は、問い合わせフォーム改善ガイドも併せて確認してください。

5. 公開後に担当する人が、更新機能を試す

日常の更新に使うアカウントで確認する

WordPressなどでお知らせや制作事例を更新する予定なら、制作会社の管理者画面を見せてもらうだけでなく、実際の更新担当者が使う権限で操作します。管理者には見える項目が、担当者のアカウントでは表示されない場合があります。逆に、担当業務には不要な設定まで変更できる状態になっていないかも、制作会社と確認します。

WordPressの公式ドキュメントでは、管理者、編集者、投稿者などの役割と、それぞれが行える操作を説明しています。サイトでは設定や追加機能によって権限が調整される場合もあるため、役割名だけで判断せず、「自社で行う予定の更新を、このアカウントで完了できるか」を確かめましょう。

代表的な原稿と画像で、一件の更新を通してみる

空の画面を見るだけでは操作の難しさが分かりにくいため、説明用の原稿で一件を作ります。題名、本文、画像、カテゴリ、日付など、普段使う項目を入力し、下書き保存、プレビュー、修正まで進めます。確認用サイトへ公開するところまで試す場合は、試験後のデータをどう扱うかも決めておきます。

例えば、事例に写真を三枚載せる運用なら、各写真の説明、並び順、縦長写真の見え方まで試します。短い題名で整っていても、正式な会社名を含む長い題名では一覧で読みにくくなることがあります。本文が長い場合や、画像が一枚しかない場合など、実際に起こりそうな違いを選んで確認します。

表示の確認は、詳細だけでなく一覧、トップの新着枠、関連記事など、更新内容が出る場所へ広げます。「投稿したのにトップへ出ない」という結果が、設定ミスなのか、掲載条件に合っていないのかを説明してもらいます。表示条件が分かれば、公開後も担当者が判断して更新できます。

公開時に引き継ぐデータと、試験データを分ける

確認用サイトへ入れた内容が、そのまま本番へ移るとは限りません。正式なお知らせ、修正した事例原稿、試験用の記事を分け、どれを公開時に反映するか制作会社と確認します。試験の記事が公開されたり、確認中に直した原稿が移行で戻ったりしないよう、反映対象を一覧に残しましょう。

旧サイトを公開直前まで更新する場合は、その更新分を新サイトへいつ取り込むかも必要です。「今週追加した採用情報は新サイトにも必要」といった差分を、公開の担当者へ伝えます。切り替え前に更新を止める時間が必要なら、停止する対象と再開時刻を社内に共有します。

操作説明は、使い方の動画や手順書があるかだけでなく、自社の担当者が迷った場所を補える内容かを見ます。試した結果をもとに「画像の差し替え」「掲載順の変更」「公開済み記事の修正」など、必要な手順を追加してもらうと、公開後の引き継ぎに使える資料になります。

6. 修正依頼と再確認を、一つの記録で管理する

場所・操作・結果・望む状態を具体的に書く

修正メモには、ページのURL、確認日時、端末とブラウザー、操作した順番、起きたこと、期待した状態を記入します。「スマホが変です」だけでは、制作会社が同じ状態を再現するのに時間がかかります。「事例詳細でメニューを開き、会社情報へ移動後に戻ると、画面をスクロールできない」のように書くと、調査の出発点が明確になります。

画面の見た目に関する指摘には、場所を示したスクリーンショットを添えます。動画なら、問題が起きる前の操作から撮ると役立ちます。画面に個人情報や社内情報が映る場合は、共有する相手と内容を確認します。画像だけを何枚も送るより、一件ごとに短い説明を付ける方が、対応状況を追いやすくなります。

正しい状態を判断できない場合は、「仕様を確認したい」と書いて構いません。「資料ボタンは別の画面で開く想定でしょうか。戻る方法が分かりにくく感じました」のように、質問と観察を分けます。不具合と決めつけず、合意した仕様に照らして相談できます。

公開前に直す項目と、追加相談を整理する

集まった指摘は、社内窓口で整理して制作会社へ渡します。問い合わせを送れない、社名が違う、非公開予定の情報が見えるなど、利用や掲載判断に関わる項目は、公開前に対応が必要かを先に相談します。新しいページの追加や承認済みデザインの変更などは、作業範囲や日程への影響も確認します。

「軽微だから後でよい」と名称だけで判断するのは避けます。一文字の違いでも電話番号や料金条件なら影響があります。一方、社内で好みが分かれる余白調整は、いま公開を止める理由になるのかを考えます。件数ではなく、利用者と業務への影響、現在の約束、修正に必要な時間を材料に順番を決めます。

公開後に対応する項目が残るなら、内容、期限、担当者、対応までの案内を記録します。合意せずに「保留」とだけ書くと、双方が相手の作業待ちになりがちです。制作会社に技術的な見通しを聞き、自社の公開判断を担う人が、残る項目を理解して決める形にします。

修正済みの連絡を受けたら、同じ手順で確かめる

「対応しました」という報告を受けたら、対象の更新版を開き、最初に問題を見つけた操作をもう一度試します。別のページや違う操作だけで確認を終えないよう、元の修正メモへ結果を追記します。共通メニューを直した場合は、代表ページでほかの表示にも影響がないか確認します。

架空の記入例なら、「事例詳細のメニュー：更新版をスマホで確認。同じ手順で戻ってもスクロール可能。会社情報から開いた場合も確認。タブレットは未確認」と書けます。確認できた範囲が明確で、未確認の項目も残るため、制作会社と次の作業を相談しやすくなります。

公開判断の記録には、承認した版と範囲、残る項目、公開予定、公開後の確認担当を含めます。社内確認が済んだという事実と、公開作業を行う指示が伝わったことを確認しましょう。意見を送っただけで公開日が確定したと思わず、作業予定までやり取りを揃えます。

7. 公開後は本番のURLで照合し、運用へ引き継ぐ

本番だけで変わる条件を、公開前から把握する

確認用サイトで問題がなくても、公開後はURL、メールの接続、予約などの外部サービス、検索向け設定が変わる場合があります。公開前の確認表に、これらを「公開後に確認する項目」として残します。どの設定を切り替えるかは制作会社が説明し、発注者は業務上必要な結果を確認する担当を決めます。

検索に載せないための設定も、公開時の確認対象です。Googleのnoindexの説明では、検索結果に登録しない指示を読み取るために、Googleがページをクロールできる必要があると説明されています。robots.txtによる巡回の制限と、検索への登録を制御する設定を同じものとして扱わず、制作会社に意図した公開状態を確認してもらいましょう。

noindexは閲覧者へのログイン要求ではありません。未公開の情報を見せない必要がある確認用サイトでは、閲覧を制限する方法も別に相談します。本番へ移す際には、必要な閲覧制限を誤って残していないか、逆に確認用サイトの制限まで外していないかを確認します。検索結果への反映は、設定確認と同時に完了するものではありません。

実際に公開されたページと、受付を確かめる

公開完了の連絡が来たら、確認用のURLではなく、一般の訪問者が使うURLを開きます。トップ、主力サービス、問い合わせ、重要な資料などを確認し、意図した原稿と画像が出ているか、主要なリンクが使えるかを見ます。リニューアルでURLが変わる場合は、利用されている旧URLからの到着先も対象です。

GOV.UKの公開作業に関するガイドは、反映後に重要な機能が期待どおり動くかを短い試験で確かめることと、失敗時の対応を事前に考えることを説明しています。企業サイトでは、主要ページの表示と受付など、自社の業務に必要な経路を選んで公開直後に確認する考え方として応用できます。

本番フォームの試験も、事前に決めた宛先と手順で行います。受信担当者の確認まで揃え、試験データの扱いを記録します。問題が出た場合は、公開作業の担当へ連絡し、修正を進めるのか、以前の状態へ戻す必要があるのかを相談します。発注者が独自に設定を動かす前に、発生時刻と影響範囲を伝えます。

確認メモを残し、次の更新に使う

公開後の確認メモは、次の更新時にも役立ちます。ページを追加したらどの共通部分を見るか、フォームを変えたら誰が受信を確認するか、資料を差し替えたら一覧と詳細のどちらを見るかを残します。毎回すべてを同じ深さで確認するのではなく、変更箇所と影響する範囲から確認内容を決められます。

最終メモは、次の項目をコピーして記入できます。未確認項目には、いつ、誰が、何を確かめるかを添えてください。

• 確認URLと版：
• 対象ページと機能：
• 確認した端末・ブラウザー・操作：
• 未確認項目・担当・確認予定：
• 修正内容と再確認の結果：
• 公開後の表示・受付の確認結果：
• 運用担当と連絡先：

公開前チェックは、きれいにできたサイトを安心して使い始めるための仕事です。専門用語を覚えることよりも、正しい内容が載り、必要な操作ができ、担当者が更新と受付を続けられるかを具体的に確かめましょう。Acquaへの制作・リニューアルの相談では、ホームページ制作の案内を確認し、現在のサイト、困っている箇所、希望する公開時期をお問い合わせからお知らせください。