

ホームページの公開直前は、見た目に加えて、来店に必要な情報が正しいか、リンク先に着けるか、問い合わせが担当者まで届くかを確かめます。店舗・教室・事務所の小規模サイトを想定し、確認するURLの一覧づくりから、公開直後の再点検、問題が出たときの戻し方までを順にまとめました。各項目に結果と担当を記録しておくと、修正を待つべきか、公開後に手を入れられるかを判断しやすくなります。

公開する予定のアドレスを先に書き出します。トップページのほか、事業内容、料金、営業情報、アクセス、問い合わせ、個人情報の取り扱いなど、訪問者が判断や連絡に使うページを並べます。サイト内から開く画像、PDF、外部の予約画面も対象です。トップページからリンクをたどる人と、案内のQRコードや検索結果から途中のページを直接開く人の両方を想定します。
各URLに「そこでできてほしいこと」を添えます。「料金ページの表示を見る」より、「初回にかかる費用と追加料金の条件を読み取れる」の方が、確認結果をそろえやすくなります。「問い合わせを見る」は、「案内ページからフォームへ進み、受付担当が試験の連絡を確認できる」と書き換えます。検査するページと、そこから始まる操作を一緒に記録してください。
公開作業の四つの確認点
公開ボタンを押したことと、訪問者が利用できることを分けて確認します。
小さなサイトでも、変更が複数ページに及ぶことがあります。電話番号を変えるなら、問い合わせページのほか、各ページの下部、スマホの固定ボタン、PDF、外部サービスの案内にも古い番号がないかを確認します。共通のメニューやページ下部を差し替える場合も、トップと下層の両方で表示を見ます。更新なら、対象外のページを広く調べ直す前に、変更がどこへ反映されるかで範囲を決めましょう。
確認表の先頭に、確認用URL、公開予定URL、確認した版、担当、日時を書きます。作業が一人でも、修正を入れたあとにどの版で見たかが分かります。公開前に社内だけで見られる状態と、公開後に誰でも見られる状態の試験は行を分けます。確認用URLに認証情報や一時的な閲覧用の文字列が付く場合、共有する記録にはページ名か管理用の識別名を書きます。
まず、営業時間、休業日、電話番号、住所、料金などを、店内掲示や業務で使う確定情報と照合します。料金は金額だけでなく、対象、単位、適用開始日、追加費用まで読み合わせます。臨時休業の案内を載せる場合は、いつまでの情報かを分かるようにします。見出しと本文、表と注記、ページとPDFで同じ条件が伝わるかも見てください。確認者が制作と兼務する場合は、項目名を書き出してから確定情報と一つずつ比べると、見慣れた原稿の読み飛ばしを減らせます。
画像は表示できるかに加えて、公開に使える素材かを確認します。自分で撮った写真でも、来店客の顔、表札、車の番号、机の上の書類など、意図していない内容が写ることがあります。提供素材は入手元と利用条件、必要な表記を控えます。条件が分からない写真は、確認が取れるまで外すか、使用できる画像へ置き換えます。写真の中に料金や日程を載せた場合は、本文の情報と照合し、スマホで文字が読めるかも確認します。W3Cの初期点検資料には、見出し、拡大、画像の代替テキストの確認項目があります。W3C WAI「Easy Checks — アクセシビリティの初期確認」
リンクは名前を読むだけで済ませず、実際に押して到着先を確かめます。「地図を見る」が店舗の入口付近を示すか、「申込」が現在受け付けている予約画面を開くか、「料金表PDF」が更新後の版かを見ます。リンクが開いても、別店舗や古いサービスへ着けば修正が必要です。外部リンクは移動先の名前や用途が分かる文言にします。メニューでは、同じ項目名が複数の場所から同じ目的地へ進むかを確かめます。Google検索セントラル「SEOスターターガイド」
電話リンクは、管理された試験で番号の表示までを確かめられます。地図は、画面の目印だけでなく住所と入口の案内も読み合わせます。PDFは、パソコンでファイルを開いた結果とスマホで見た結果を分けて記録します。小さな画面で表が読みにくい場合は、来店や申込に必要な要点をページ本文にも置き、詳しい資料へ案内できるかを見直しましょう。
スマホでは、縦向きの画面で主要な内容を読み、固定メニューを使い、リンク先へ進むところまで試します。余裕があれば普段使わないブラウザーでも主要経路を確認します。見切れ、拡大、ボタンの間隔、入力欄は、スマホ表示を確認する方法の点検表に沿って確認できます。
問い合わせフォームは「フォームが開く」「送信完了と表示される」「受付担当が内容を受け取る」の三つを分けて記録します。フォームを開けても、宛先やサーバーの設定が違えば受付まで届かないことがあります。受付にメールを使う場合は、担当者が運用に使う受信箱で、試験内容を見分けられるか、返信準備ができるかを確認します。管理画面で受付を処理する場合は、試験の受付が一覧に入り、担当者が開けるところまで確認します。
試験の前に、担当者、試験時間、試験用の入力値と宛先、発生し得る通知を決めます。利用者への自動返信がある場合は、管理できる試験用アドレスを使い、既存の顧客を宛先にしないようにします。予約枠の確保や決済、顧客管理サービスへの連携がある場合は、試験用の環境や枠で、通知や受付の記録まで追います。試験できる範囲が限られる場合は、確認できた操作と未確認の処理を分けて残します。
正常系では、案内ページからフォームへ進み、対象や日程などを選び、送信します。完了画面に、受付の成否、控えメールの扱い、今後の連絡が説明されているかを見ます。続いて受付担当の画面を開き、送信した内容と照合します。メールが来ない場合は、迷惑メールフォルダーや管理画面の受付記録を確認し、宛先の設定、送信側のエラー、受信側の振り分けのうちどこを調べるか決めます。公開する環境で送信方法や送信元が変わる場合は、確認用環境で届いた結果と分け、公開後も管理した条件で確認します。
未入力や入力ミスも試します。問題のある欄と直し方が分かり、直したあとに同じ手順を進められるかを見ます。スマホでは、キーボードを開いたときに必須欄や送信ボタンが隠れないか、エラー箇所へ戻れるかも確かめます。エラーが出た試験で正常な受付が残っていないかも確認してください。W3Cのフォーム資料には、入力時の案内と送信結果を伝える方法が示されています。W3C WAI「フォームで利用者に結果を伝える」
こもれび教室の体験申込で、試験用の入力を送ったあとに「受け付けました」と表示されたものの、受付担当が受信を確認できなかったとします。この場合、表示は確認済み、受信は要修正と記録し、申込フォームを使う形での公開判断を止めます。宛先など原因に沿って修正したら、再度トップの案内から送信まで進み、試験を識別できる記録が受付側に一件届くかを確認します。受付後の返信が必要なら、返信先が試験用のアドレスに向くことも確かめます。
公開予定のURLと、制作サービスやサーバーに指定している公開先を照合します。ドメイン名、wwwの有無、ページの置き場所を確認し、別サイトの領域へ公開しないようにします。公開後は、案内に載せるHTTPSのURLをブラウザーに直接入力し、警告が出ないこと、正しいページに着くことを確認します。別のアドレスから転送する設定がある場合は、転送前と最終到着先の両方を控えます。ページだけ開けても画像や資料が欠けている場合は、該当ファイルのURLまで開きます。
サーバーが返した処理結果を示す番号を「HTTPステータス」と呼びます。検索に載せたいページは、Googleに対して正常なページを返せる状態にします。技術要件にあるHTTP 200は、取得に成功したことを示す番号です。内容が期待どおりかは画面も見て確かめます。たとえば、処理結果が成功でも、置き場所を間違えてサーバーの初期画面を配信していれば公開確認は通せません。Google検索セントラル「Google 検索の技術要件」
表は横にスクロールして読めます →
| 設定・場所 | 確認すること | 確認後の判断 |
|---|---|---|
| 公開範囲 | 試験ページは認められた人だけが閲覧でき、公開するページはログインせずに開ける | 機密の内容には認証などの閲覧制限を使う |
| robots.txt | 検索用の取得を制御するルールが、意図したURLに適用されている | 公開したいページを意図せずブロックしていないか調べる |
| noindex | 検索に載せたいページに登録を除外する指示が残っていない | HTMLの設定やサーバーが返すヘッダーを確認できる人に依頼する |
| canonical | 同じ内容のURLが複数ある場合に、意図した代表URLを示している | 公開URL、内部リンク、サイトマップの向き先を照合する |
| 内部リンク・サイトマップ | 重要ページへのリンクがあり、サイトマップを使う場合は公開したいURLを載せている | 古いURLや確認用URLを混ぜず、重要ページへ実際に移動する |
robots.txtは検索エンジンによるページの取得を制御します。noindexはGoogleにインデックス登録から除外するよう伝える指定です。Googleがnoindexを読むには対象を取得できる必要があります。認証なしで開けるページは、どちらを設定してもURLを知っている人が閲覧できる場合があります。試験ページに機密情報がある場合は、認証などの閲覧制限を別に用意します。設定を外すときは、公開対象のページかどうかも確かめてください。Google検索セントラル「robots.txt の概要」、Google検索セントラル「noindex による登録除外」
canonicalは、同じ内容のページに複数のURLがあるときに代表候補を伝える指定です。作成サービスが自動で出力することもあるため、案内に使うURLと矛盾していないかを確認します。サイトマップは検索エンジンにURLを知らせる一覧です。作る場合は公開するURLを入れ、案内用のリンクやcanonicalとそろえます。サイトマップの送信や公開URLテストが成功しても、検索への登録や順位は保証されません。公開時点で登録結果を待つかどうかは、表示と受付が動くかの判定とは別に扱います。Google検索セントラル「正規URLの指定」、Google検索セントラル「サイトマップについて」、Search Consoleヘルプ「URL 検査ツール」
編集画面で設定を変えられるか、公開した出力を確認する必要があるかは作成方式で異なります。項目の場所が分からない場合は、公開用URLと意図を添えて、制作担当やサービスに確認します。検索に出てこないときは、公開とGoogleの登録を切り分ける手順へ進めます。
この表を印刷するか、必要な行を複製して使います。先に対象と期待を書くと、どこまでできれば合格かが明確になります。結果は「合格」「要修正」「未確認」「対象外」を区別し、未確認や対象外の理由も記入します。複数のURLで同じ項目を見る場合は一行ずつ分け、担当と日時を残します。必要な操作が未確認であれば、そのまま公開可と扱わず、確認する人と時間を決めてください。
表には、サイト名、版、確認に使ったURL、端末を別に添えます。公開前と公開直後で同じ表を使う場合も、確認段階ごとに日付と結果を分けます。
表は横にスクロールして読めます →
| 項目 | 確認方法・期待する結果 | 結果・不合格時の対応 | 担当・日時 |
|---|---|---|---|
| 公開URLとHTTPS | 予定URLを直接開き、警告なく正しい版とページへ着く | 結果__/対応__ | __ |
| 事業情報と資料 | 確定情報と照合し、ページ・PDFの料金と営業情報が一致する | 結果__/対応__ | __ |
| スマホ表示 | 縦向きで主要な文字と表を読み、固定メニューから移動できる | 結果__/対応__ | __ |
| リンクと画像 | メニュー・外部リンク・地図・資料・画像を開き、期待した内容へ着く | 結果__/対応__ | __ |
| 入力エラー | 必須欄を空けて試し、直す箇所が分かり、意図しない受付が起きない | 結果__/対応__ | __ |
| 正常な受付 | 管理した試験で完了案内、担当者の受信、必要な自動返信を確認できる | 結果__/対応__ | __ |
| 公開範囲と検索設定 | 確認用と公開用を区別し、検索に載せるURLの設定が意図どおりである | 結果__/対応__ | __ |
| 復旧の準備 | 編集用データと直前の公開物を保全し、戻す版と確認手順が分かる | 結果__/対応__ | __ |
| 公開直後の再点検 | 実URLで表示、画像、重要リンク、受付を確認し、公開した版と一致する | 結果__/対応__ | __ |
「正常な受付/試験用アドレスで体験申込を一回送信し、担当者が受信箱で内容を確認できる/要修正。完了画面は表示、受信を確認できず。宛先設定を見直し、再試験/受付担当・確認時刻」と記入します。対応後は、初回の記録を消さず、修正した版と再確認結果を行として追加します。これで、どの段階の問題が解消したかを追えます。
紙で使う場合は、ブラウザーの印刷画面でこの節を含むページを選び、プレビューで表の右端まで見えるか確認します。必要なら用紙を横向きにします。ブラウザーの印刷設定でページのURLが載る場合は、公開されたこの記事のURLを残します。表示されない場合は、紙に記事のURLと印刷日を書いておくと、改訂版を見つけやすくなります。共有する記録には、フォームに入力した個人情報、認証情報、試験用の秘密のURLを書かず、受付を区別できる管理番号などを使います。
改訂履歴は、2026年11月9日初版です。確認する機能や公開方法が変わったら、印刷済みの表をそのまま流用せず、対象と期待する結果を現状に合わせて見直します。

公開の前に、発見した場合に作業を止める条件を決めます。例は、重要な連絡先の誤り、料金や受付条件の食い違い、申込が届かない、公開URLで警告が出る、公開すべきでない情報が見える場合です。来店や申込に影響する行の結果が未確認なら、影響を見て確認を先に済ませます。装飾の余白など、情報や操作に影響しない修正は、担当と修正予定を残して公開判断と分けることができます。誤字でも、日時、金額、番号を変えてしまうものは影響を基準に判定します。
公開作業の直前に、編集し直せるデータといま配信されている版を保全します。編集データは、次の更新で元の内容を取り出すために使います。直前の公開物やサービスの版履歴は、利用者が見る内容を戻すために使います。画像、添付資料、設定、フォームの外部連携など、サイトに必要なものがどの保全手段に含まれるかを確認します。アプリやサービスによって、版履歴が戻す範囲や保存できるものが異なります。公開物だけで編集元を復元できるか、編集元から公開状態を再現できるかは、それぞれ使っている方式の手順で確かめます。
戻す担当と方法、戻す版の見分け方、元に戻したことを判断するURLを先に決めます。初めての公開で直前版がない場合は、公開を取り下げる方法や、受付の停止案内を出せるかを確かめます。受付データを持つサイトでは、公開前のデータを丸ごと戻すと新規の申込まで巻き戻る場合があります。ページと受付の記録をどう保護するかを整理し、復元の確認は試験環境や管理された対象で行います。日常の編集と保全の手順は、公開後の更新手順にもまとめています。
公開したら、編集画面を閉じた状態、またはログインのないブラウザーで公開URLを開きます。トップ、主要ページ、画像、資料、スマホのメニューを確認し、準備した経路で問い合わせや予約へ進みます。確認用と公開用でフォームの設定や宛先が違う場合は、試験を管理できる条件で送信と受信を確かめます。計測を導入している場合は、試験のアクセスや完了を計測側で区別できるよう記録し、個人情報を計測に含めていないことを設定と送信内容で確認します。導入していない場合は、確認表にその旨を書けます。
更新したはずの内容が古い場合は、まず画面のアドレスと版を照合し、別ブラウザーなどでも同じ結果かを確かめます。ブラウザーや配信側が古い内容を一時保存している場合と、別の場所に公開している場合では対応が異なります。見える問題の範囲が分かるまでは、公開操作を重ねて状況を変える前に、確認したURL、時刻、見えている内容を控えます。
重大な誤りがあれば、影響する案内や受付を止め、用意した手順で正しい版や代わりの案内に戻します。戻した直後に実URLを開き、誤った情報が消え、必要な案内や受付が使える状態になったかを確認します。複数の変更を一度に公開した場合は、影響する経路を一つずつ確認し、直した箇所とその結果を記録に残します。
後日手を加える軽微な項目は、公開直後の記録に担当と見直す日を書き足します。次の営業日には、最新の案内が公開されたことと受付に届いた問い合わせを担当者が処理できることを確認します。更新を続けるときは、この表で毎回すべてを見直す必要があるかを判断し、変更内容に合わせて確認するページと経路を選びます。
確認日 2026年11月9日
関連する作業
公開後に画像やフォームの表示が崩れた場合は、HTTPSに変えた後の確認手順で読み込みや参照先を確認します。