Webサイトのリリース前テスト入門｜表示・リンク・フォームを確認する手順
Webサイトが完成しても、「どこからテストすればいいの？」と迷いますよね。
画面をなんとなく眺めるだけでは、リンク切れや、問い合わせの通知が届かないといった不具合までは見つけられません。
とはいえ、最初からすべての端末をそろえたり、専門的な検査を用意したりする必要はありません。
まずは確認する端末とブラウザを決め、表示、リンク、フォーム、公開直後の順に進めると整理しやすくなります。
この記事では、リリース前テストの具体的な進め方を、この順番にそって紹介します。
1. テストする端末と環境を決める
最初に、どの端末とブラウザで確認するかを決めましょう。
思いついたときに端末を変えながら見るより、確認する環境を書き出した小さなテスト表を先に作る方が、抜け漏れを減らせます。
新しく作ったサイトで、どんな端末で見られるかがまだ分からない場合は、次の組み合わせから始めてみましょう。
- パソコン1台とスマートフォン1台
- お客様が使うと想定している主なブラウザ
- ログインしていない、初めて訪れた人と同じ状態
- 会員機能があるサイトなら、ログイン前とログイン後の両方
既存サイトのリニューアルなら、アクセス解析の数値や、これまで分かっている利用状況を見て、使われることの多い端末とブラウザから確認しましょう。
すべての機種を自分でそろえる必要はありません。
手元にない端末は「未確認」と記録しておき、制作会社やテストを担当できる人へ確認を依頼しましょう。
テストを始める前には、次のものも用意してください。
- 公開対象のページ一覧
- 確認用URL、本番URL、本番へ切り替える日時と手順
- テスト用と分かる氏名、メールアドレス、問い合わせ内容
- フォームの通知を受け取る、運営者側のメールボックス
- 見つけた問題を記録する表や共有資料
問題を記録するときは、ページURL、端末、ブラウザ、行った操作を残しましょう。
あわせて、今どうなっているか、本来どうなるべきか、画面のスクリーンショットも添えておくと、直す人に伝わりやすくなります。
記録表を次の形にしておくと、確認した結果と修正の状況を同じ場所で管理できます。
対象・操作 | 環境 | 期待する状態 | 実際の結果 | 重要度・担当 |
|---|---|---|---|---|
トップページを開く | iPhone・Safari | 横スクロールなく表示される | 料金表が右へはみ出す | 公開前・制作担当 |
問い合わせを送る | Windows・Chrome | 完了表示と通知メールが届く | 運営者側の通知だけ届かない | 公開前・フォーム担当 |
問題がなかった項目も「確認済み」と記録しておくと、どこまで試したかがあとから分かります。
まずはパソコンとスマートフォンで、問い合わせまでの主な流れを一度通して確認しましょう。そのうえで、影響の大きい画面から順に、確認する範囲を広げていきます。
テスト表と記録の形を先に決めておけば、見つけた問題を関係者へ何度も説明し直さずに済みます。
2. 全ページの表示を確認する
表示テストは、トップページだけで終わらせないのがポイントです。
公開対象のページ一覧を上から順に開き、ページごとに結果を残しましょう。
各ページで見る項目はこちらです⇩
- ページがエラーにならず開くか
- 見出しと本文が予定した内容になっているか
- 画像が欠けたり、不自然に切れたりしていないか
- 文字と背景の色が近すぎて、読みにくくなっていないか
- 文章、画像、表が画面の外へはみ出していないか
- 画面に固定されたメニューやボタンが、本文を隠していないか
- 読み込み中の表示が残ったままになっていないか
スマートフォンでは、縦向きだけでなく横向きも一度見ておくと安心です。
パソコンでは、ブラウザの横幅を少しずつ狭めてみましょう。
ある幅になったときだけ起きる、文字やボタンの重なりに気づけることがあります。
画面を狭くしたときに内容がどう並び替わるかは、W3Cのリフローに関する解説でも扱われています。
ページに不要な横スクロールが出たときは、どの画像や表がはみ出しているかまで記録しましょう。
ボタンは、画面に見えているかだけでなく、指で押しやすいかも確認してください。
ボタンの大きさや間隔を判断する基準は、W3Cの操作対象の大きさに関する解説が参考になります。
まずは実際のスマートフォンで押してみて、「隣のボタンを押してしまう」「指で隠れて選びにくい」と感じた場所を記録しておきましょう。
同じレイアウトのページが多いサイトでも、料金、問い合わせ、会社情報など大事なページは、それぞれ個別に確認しましょう。
3. リンクとボタンをたどる
リンクの確認では、「ページが開いたか」だけでなく、「意図したページへ移動したか」まで見ましょう。
お客様がたどる順番で、サイトの入口から目的のページまで実際に移動してみてください。
確認するリンクとボタンは次のとおりです。
- ヘッダーとフッターのメニュー
- ロゴからトップページへ戻るリンク
- パンくずリスト（今どのページにいるかを示す道しるべ）やページ内リンク
- 本文中の関連記事や外部サイトへのリンク
- 料金、予約、購入、問い合わせなどの主要ボタン
- 電話番号とメールアドレスのリンク
- SNSを使っている場合は、自社アカウントへのリンク
リンク先のページが表示されても、そこが古い料金表や終了したサービスの案内であれば、リンク先を直す必要があります。
同じ言葉のボタンが、ページによって違う移動先になっていないかも確かめましょう。
電話番号とメールアドレスのリンクは、スマートフォンで実際に押してみてください。
電話アプリやメールアプリが立ち上がり、正しい番号やアドレスが入るかを確認します。
外部サイトへのリンクは、相手側のページが変更・削除されることもあるため、公開前に一度開いておくと安心です。
リンクの数が多いサイトでは、リンク切れを自動で調べるツールを補助として使う方法もあります。
ただし、ツールが「正常」と表示しても、移動先の内容まで正しいかどうかは判断できないことがあります。
問い合わせや購入など、特に大事な流れは、自分の目で最後までたどるのがポイントです。
担当者向けの確認対象をもっと広く整理したいときは、「Webサイト公開前に確認すること一覧」も使えます。
4. フォームを最初から最後まで試す
フォームは、入力画面から運営者側がメールを受け取るところまでを、一つの流れとして確認しましょう。
フォームが表示されているだけで「動いている」と判断せず、テスト用の内容で実際に送ってみましょう。
確認する順番はこちらです。
- 項目名と入力例が分かりやすいかを読む
- 必須項目を空欄のまま送り、エラー表示を確認する
- メールアドレス欄などに、わざと形式の違う文字を入れてみる
- 正しいテストデータを入力する
- 確認画面がある場合は内容を見直す
- 送信して完了表示を確認する
- 自動返信と運営者側の通知を確認する
W3Cのフォームに関するチュートリアルでは、項目名を示すラベル、入力方法の説明、入力内容の検証、利用者への通知といった考え方が整理されています。
入力を間違えたときに、赤い枠が出るだけで終わっていないかを見てみましょう。
「何をどう直せばよいか」が文章でも伝わることが大切です。
W3Cのフォーム送信結果の通知に関する案内では、エラーの知らせ方だけでなく、送信が完了したことを伝えるメッセージについても説明されています。
完了画面が出ても、確認はまだ終わりではありません。
お客様への自動返信、運営者側への通知、複数の担当者へ届ける設定にしている場合はそれぞれの受信を、別々に確かめましょう。
メールが見当たらないときは、迷惑メールフォルダも開いてみてください。
送信元、件名、返信先が、そのまま返信しやすい内容になっているかもあわせて確認しましょう！
次のような機能をフォームに付けている場合は、その項目も追加で試してみましょう。
- 文字数の上限や入力できる文字の種類が、画面の案内どおりか
- 個人情報の取り扱いや規約への同意欄があり、案内ページへのリンクが正しく開くか
- 添付できるファイルの形式と容量の制限が分かり、送られたファイルを運営者側で開けるか
- 送信ボタンを続けて押しても、同じ問い合わせが重複して登録されないか
- 迷惑送信対策を入れている場合に、通常のお客様が最後まで送信できるか
予約や決済を伴うフォームは、通常の問い合わせより、失敗したときの影響が大きくなります。
利用しているサービスが用意しているテスト機能や、専門の確認手順を使ってください。
テストでは、本物の顧客情報や決済情報を使わないでください。
事前に用意したテストデータだけで試しましょう。
テストが終わったら、残った問い合わせデータや添付ファイルを削除しておきましょう。
5. 公開直後にもう一度確認する
確認用の環境で問題がなくても、本番へ切り替えるときにURLや設定が変わることがあります。
公開作業が終わったら、同じ日に本番URLでもう一度確認しましょう。
公開直後に見る項目は次のとおりです。
- 正式なURLが
https://で開き、ブラウザの警告が出ないか - メニュー、主要リンク、画像が本番URLで開くか
- 問い合わせを送信し、完了表示と通知を確認できるか
- 公開したいページに、検索結果から除外する設定が意図せず残っていないか
- 送信完了ページや管理用ページなど、検索させたくないページが検索対象になっていないか
- URLを変更した場合に、古いURLを開いた人が新しいページへ移動できるか
- アクセス解析の記録が、予定したアカウントに残っているか
- サイトマップ（サイト内のURL一覧を検索エンジンへ知らせるファイル）に、公開対象のURLが入っているか
Google検索では、noindex（そのページを検索結果に載せないよう伝える指定）を使って、ページが検索に登録されるのを防げます。
ただし、Googleがこの指定を読み取るには、そのページをクロール（検索エンジンがページを読みに来ること）できる必要があります。
詳しい条件はGoogleのnoindexに関する公式資料で確認できます。
すべてのページをまとめて同じ設定に変えるのではなく、検索結果に出したいページと出したくないページを分けて設定しましょう。
URLを変更したときの転送（リダイレクト）のやり方は、Googleのリダイレクトに関する公式資料が参考になります。
公開したページが検索エンジンからどう見えているかは、Search ConsoleのURL検査ツールで調べられます。
ただし、URL検査で「登録可能」と表示されても、必ず検索結果に載るとは限りません。
まずはトップページと主なサービスページから確認すると進めやすいです。
公開前全体の見方は、「ホームページ公開前チェック完全ガイド」でも整理しています。
まとめ
リリース前テストの流れを、最後に5段階で振り返ってみましょう。
- 端末、ブラウザ、ログイン状態、テストデータを決める
- 公開対象の全ページを開き、表示の問題を記録する
- メニュー、リンク、ボタンをお客様と同じ順番でたどる
- フォームを入力し、完了表示と通知の受信まで確かめる
- 公開直後に本番URL、検索設定、計測を再確認する
一度で問題を全部見つけようとしなくても大丈夫です。
まずは、公開対象のページ一覧に「端末・ブラウザ・結果」の3列を足して、小さなテスト表を作ってみてください。
そして最初の1ページから確認を始め、問題が見つかったらURL、行った操作、画面のようすまで記録していきましょう！
関連記事
