サイトを採点するのではなくレビューを記録する
便利な Webサイト監査チェックリストは、発見した内容を記録し、次に何を調査するかを決定するのに役立ちます。人々が必要とするページ、提供内容の明確さ、その背後にある証拠、検索や技術的なチェックと並行して問い合わせへの道筋を確認します。未チェックの項目をすべて失敗にするのではなく、不足している情報を不明としてマークします。
まず、決定事項と管理しやすい重要なページのセットを選択します。サービス ビジネスの場合、それはホームページ、主なサービスの説明、関連ガイド、連絡経路などです。決定を変更できる場合は他のページを追加します。サンプルがサイト全体を説明しているとは考えないでください。
以下の40項目は、自分で確認するための手順です。すべてのAlytixxのご注文に、全項目が含まれるという意味ではありません。ページ、確認内容、次の対応を記録し、ワークシートで追加確認を整理します。「確認済み」は作業をした記録であり、サイトが良いという判定ではありません。
A. 重要なページとナビゲーション
保存されたリストからすべてのページを開くのではなく、見込み顧客が使用するルートに従います。役立つパスと、必要な答えが見つかりにくい場所の両方を記録します。
チェック1
訪問者はサイトのメインセクションから主要なサービスを見つけることができますか?
ホーム ページとメイン ナビゲーションから開始して、優先される各サービスにアクセスしてみてください。ルートと、不足しているステップや誤解を招くステップを記録します。サービスが意図的に二次的なものである場合は、新しいメニュー項目を推奨する前に、対象ユーザーがどのようにサービスを見つけるべきかをオーナーに尋ねてください。
チェック2
重要な各ページには明確な目的がありますか?
主な見出し、導入文、次の手順を読みます。ページが答える購入者の疑問や、果たす役割を1文で書きます。目的が分からなければ、誰が必要とし、何を理解し、何をするためのページかを確認します。役割が決まるまで、未解決の疑問として残します。
チェック3
リンクには、訪問者が次に見つけるものについて説明されていますか?
リンクの文言とリンク先を比較してください。開いたページとは異なるアクションを示唆する曖昧なラベルやリンクを記録します。背景や条件によって短いラベルが明確になる場合は、それを保持します。読者が推測する必要がある場合は、実際のリンク先を反映した説明を提案してください。
チェック4
訪問者がたどる可能性が高いルートから重要なページが欠落していませんか?
サービスの選択または問い合わせの行程を追跡し、関連するページが存在しない箇所をメモします。開始ページ、不足している回答、および役立つ可能性のあるリンク先を保存します。訪問者のルートが不明な場合は、すべての顧客がそのルートを使用していると主張するのではなく、テストしたルートを説明し、所有者またはユーザーの背景や条件を尋ねます。
チェック5
関連ページは、読者が同じ作業を続けるのに役立ちますか?
ガイドまたはサービスの説明の後にリンクに従ってください。それらが関連する例、詳細な回答、または適切なアクションにつながるかどうかを記録します。リンクによって主題が予期せず変更された場合は、リンクを追加する前に、読者が次に何を必要とするかを決定してください。リンクの量だけが目標ではありません。
B. 検索への対応と、実際の検索データ
一般公開、掲載条件、実際の表示を分けます。Googleの技術要件は、登録の対象になる条件であり、登録を保証しません。公開ページを超える裏付けが必要なら、プロパティ所有者の検査や、適切な検索データを使います。
チェック6
サインインせずに重要なページにアクセスできますか?
認証されたセッションを使用せずに、目的の各公開ページをブラウザーで開きます。ロード、リダイレクト、またはアクセスを要求するかどうかを記録します。ページが設計上非公開である場合は、その目的をマークします。公開する必要がある場合は、その原因を推測するのではなく、責任者に制限を調査するよう依頼してください。
チェック7
ページのタイトルと主要な見出しは実際のコンテンツを説明していますか?
ブラウザのタイトルと主見出しを、ページの主題と提供内容に照らして比較します。不一致、古いサービス名、ページの違いが分からなくなる重複表現を記録します。主題が不明なら、書き換える前に目的を確認します。タイトルを変えただけで、表示の改善は証明できません。
チェック8
重要なページが意図せずに検索から制限されていませんか?
選んだページの検索設定と指示を、サイトの所有者や専門家に確認してもらいます。制限、URL、意図した設定かどうかを記録します。指示やアクセス状態が不明なら、具体的な技術確認を依頼します。全体の整理のついでに、意図した除外を解除しないでください。
チェック9
登録可能なページと、登録済みを確認したページを区別しているか?
適格性チェックと実際のインデックス登録の証拠を別のメモに保管します。可能な場合は、所有者による正確なページ検査のソースと日付を記録します。ページが開くことだけを確認できる場合は、インデックス登録を未確認と書き込みます。ブラウザの訪問は、Google がそのページをインデックスに含めたという証拠にはなりません。
チェック10
検索の可視性に関する主張は、実際のクエリの観察や所有者のデータによって裏付けられていますか?
ページがランク付けされた、または表示されなくなったという記述の背後にある記録を見つけます。クエリ、背景や条件、日付、またはフィルターと期間を含む所有者レポートを保存します。情報源が存在しない場合は、その発言を未検証のままにして、どの観察が疑問を解決するかを尋ねてください。
C. 提供内容の分かりやすさ
公開した説明を、確認済みの事業上の条件と比べます。文章でサービスを分かりやすくできますが、実際に何を含むかは、事業主が確定する必要があります。
チェック11
各サービスが誰を対象としているかは明確ですか?
サービスページで、対象者、状況、提供地域を確認します。誰向けと読み取れるかを書き、食い違う説明をメモに引用します。対象が広い、または未確定なら、文章を絞る前に所有者の意図を確認します。
チェック12
そのページには、顧客が受け取るものについて説明されていますか?
具体的な成果物、サービス、または仕事の結果を探します。説明や大まかな約束だけが出てくる箇所を記録します。結果が異なる場合は、何が一貫しており、何が後で合意されるのかを尋ねます。顧客が望む結果を保証された成果物に変えないでください。
チェック13
訪問者は何が含まれ、何が除外されるかを理解できますか?
主な説明、条件、お問い合わせ文を比較します。購入判断に関係する不足や矛盾を記録します。お客様が期待しそうなことに答えていない場合は、含まれるものや対象外を作り上げず、所有者に範囲を確認し、提供内容の近くで説明します。
チェック14
意思決定に関連する価格設定アプローチは説明されていますか?
実際の固定価格、見積プロセス、または範囲を設定するために使用される要素が該当するページで説明されているかどうかを確認してください。目に見える説明と未解決の質問を記録します。条件が確認されていない場合は、現在の事実を要求します。一般的な市場価格を提供したり、古い金額をコピーしたりしないでください。
チェック15
前提条件、条件、次のステップは明確ですか?
お客様が何を用意し、どの条件が適合性に関係し、行動後に何が起きるかを確認します。フォームや購入の手順の前に分かる情報を記録します。連絡後にしか要件が分からないなら、すべての依頼が同じ手順だと装わず、事前に説明できることを尋ねます。
D. 裏付けと信頼
主張に合った裏付けを使います。関連する背景を添えた実例は、別のサービスについての印象的な言葉を並べるより役立つ場合があります。
チェック16
それぞれの主要な主張には適切な裏付け証拠があるか?
購入に影響を与える可能性のある主張を選択し、そのサポートを見つけます。ソース、それが確立している内容、および欠落している背景や条件を記録します。主張が実証できない場合は、関連する記録を要求するか、証拠と一致する文言を提案してください。裏付けのない確実性がセールスポイントになってはなりません。
チェック17
例は説明されているサービスに関連していますか?
各事例のサービス、開始状況、成果物を現在のページと照らし合わせて確認してください。関係と重要な違いを記録します。例が別の提供内容に関するものである場合は、その成功が現在のサービスに引き継がれると仮定するのではなく、その背景や条件を説明するか、関連するサポートに置き換えてください。
チェック18
お客様の声は実際のもので、出典が分かり、関連性があるか?
担当者に、掲載したお客様の声の出典と許可を確認してもらいます。各レビューの内容と、今回の判断との関係を記録します。出典や許可がなければ確認を依頼します。匿名の評価を、名前のあるお客様の推薦に書き換えてはいけません。
チェック19
サービスの提供者と連絡方法は明確ですか?
提供者の正確な情報と、使える連絡方法を探します。公開されている情報と、その場所を記録します。食い違いがあれば、事業者に確認します。情報を統一する前に、意図した計測や振り分け設定が違いの理由かを考えます。
チェック20
架空の例は顧客の結果と明確に区別されていますか?
すべての説明用の事例や見本レポートで、例の表示と周囲の主張を読みます。実測した仕事と誤解されないかを記録します。位置付けが不明なら、出所を確認し、正確に例と示します。架空の手順が、実際のお客様の成果を示唆してはいけません。
E. お問い合わせまでの導線
受け取りを含むアクション全体を追跡します。合意されたテストを使用して、問い合わせに対応する担当者がそれを認識し、実際の顧客のリクエストと区別できるようにします。
チェック21
ページには適切な次のアクションが示されていますか?
ページの目的と主なアクションを比較してください。読者が関連サービスをリクエストできるかどうか、例を検査できるか、不足している詳細を見つけられるかどうかを記録します。準備が整っているかどうかが不確かな場合は、次にどのような決定が下されるかを尋ねてください。すぐに購入を要求することは、説明ガイドにはふさわしくないかもしれません。
チェック22
主な行動ボタンを押すと何が起きるか、明確か?
ボタンと近くの説明を読み、リンク先を開きます。結果が案内どおりかを記録します。一般的な文言から詳しい申請フォームが開くなら、文言の短さだけで判断せず、必要な負担がクリック前に分かるようにします。
チェック23
フォームの質問は理解でき、リクエストに関連していますか?
各項目名を読み、その段階で回答が必要な理由を確認します。曖昧な質問、説明のない必須情報、不足する案内を記録します。目的が不明なら、削除前に受信担当者に聞きます。対応できる依頼かの判断や振り分けに、必要な情報かもしれません。
チェック24
許可されたテストの問い合わせを完了して受け取ることはできますか?
認識可能なテストに同意し、提出、確認、受領までそのテストに従います。住所、時刻、デバイス、受信者の確認を記録します。リクエストがどこにも届かない場合、または配信アクセスが利用できない場合は、配信を未解決のままにして所有者チェックを割り当てます。成功メッセージだけでは解決しません。
チェック25
確認は、応答時間を考え出すことなく、次に何が起こるかを説明しますか?
取り決めたテストの後、完了メッセージを読みます。何を依頼したことになり、事業者が次にどう対応するかが分かるか記録します。返答の期限があるなら、現行で守れるものか確認します。未確認の約束を加えずに、次の手順を説明します。
F. 使いやすさと技術的な観察
問題を再現可能にします。デバイス、ブラウザ、ページ、手順を記録し、予想したことと何が起こったかを説明します。 1 回のテストが成功しても、すべてのユーザーや条件をカバーできるわけではありません。
チェック26
携帯電話でもコンテンツを快適に読むことができますか?
スマートフォンで重要なページを開き、見出し、本文、表、重なって表示される要素を調べます。文字の欠けや隠れ、主な操作中の横スクロールを記録します。画面幅によって変わる問題なら、その条件を残し、影響する幅の確認を依頼します。
チェック27
フォーム、メニュー、リンクは目的の導線で使用できますか?
必要に応じてマウスなどのポインターとキーボードを使い、メニューの開閉も含めて選んだ導線をたどります。不具合があれば、操作部品と手順を記録します。専門的な評価が必要なら依頼してください。簡単な導線テストだけで、すべての利用者へのアクセシビリティは保証できません。
チェック28
エラーや結果がない状態で、次にできることが説明されているか?
許可された方法で入力エラーを起こすか、実際に結果がない状態を確認します。問題と次にできることが説明されているかを記録します。安全に再現できない場合は、見えない動作が正しいと仮定せず、担当チームに例を依頼します。
チェック29
重要な画像や図には意味のある説明が付いていますか?
重要な事実や操作を伝える画像の周囲の文章を読みます。画像が見られないと、何が伝わらなくなるかを記録します。意味が画像だけに依存するなら、適切な文章の説明を求めます。装飾画像に、近くの文章を繰り返す必要はありません。
チェック30
パフォーマンスに関する懸念は、推測ではなく実際の観察や測定に基づいていますか?
ページ、端末、接続条件、観察した読み込みや操作の問題を記録します。ツールの結果は測定条件と一緒に保存します。測定が1回だけなら、その条件と関連性を調べます。それだけでは、すべての訪問者の体験は分かりません。
G. 競合他社の状況と AI 関連のコンテンツ
関連する決定を比較し、自分自身の事実の一貫性を保ちます。レビューに重要な場合にのみ AI 回答の観察を含め、観察された内容を正確に説明します。
チェック31
競合他社とページの種類は本当に同等ですか?
それぞれの比較で対象ユーザー、サービス、市場、ページの目的を確認してください。ページが同じレビューに属する理由と相違点を記録します。ビジネス モデルが異なる場合は、1 つの Webサイトを万能のベンチマークとして扱うのではなく、特定の共通の質問を比較してください。
チェック32
見た目だけでなく、提供内容、裏付け、次の手順を比較しているか?
各ページに同じ疑問を当てはめます。何が提供され、主張の裏付けは何か、どう進めるか。見える回答と不明点を記録します。レイアウトが好きなだけなら、デザインの好みと記します。売上やサービスが優れている証拠ではありません。
チェック33
製品に関する重要な事実は自分のページ全体で一貫していますか?
ホーム、サービス、お問い合わせページで、サービス名、成果物、条件および除外事項を比較します。矛盾する発言をその場所とともに記録します。バージョンが異なる場合は、最も説得力のあるバージョンを選択するのではなく、所有者に現在の事実を尋ね、関連する説明を一緒に更新してください。
チェック34
あなたのページは、購入希望者が解決する必要がある質問に答えていますか?
可能な場合は実際の問い合わせや販売に関する質問を使用し、その回答をページで見つけてください。答えのない質問と、それが決定にとってなぜ重要なのかを記録します。需要が不明な場合は、実績のある人気の検索ではなく、購入者とテストするための候補として質問にラベルを付けます。
チェック35
AI の回答を確認するとき、言及、引用、推奨事項は個別に説明されていますか?
質問、AI サービスまたは Google 機能、時間、回答を保存します。ブランド名、ページへのリンク、サービスの推奨などを個別に記録します。答えを取得できない場合は、観察を利用不可としてマークします。存在しないレコードを可視性ゼロにしないでください。
H. 決定とフォローアップ
確認した数ではなく、記録した指摘から対応を選びます。確認できたお問い合わせの不具合と、未回答の疑問では、次の手順が異なります。色や重要度のラベルだけで、事業上の優先順位は決められません。
チェック36
提案されたそれぞれの変更は、記録された観察に関連していますか?
タスクの根拠を、ページの状態、所有者が確認した事実、利用者についての具体的な観察までたどります。提案する変更とともに、その関係を記録します。好みだけなら、その旨を示します。根拠が見つからなければ、必要な変更と考える前に調べます。
チェック37
確認された失敗は仮説から分離されていますか?
結論と情報源を並べて読みます。不具合を再現したのか、説明は可能性にとどまるのかを記録します。裏付けなく「範囲が不明確」から「売上を失った」へ飛躍していれば、結論の範囲を狭め、想定する影響を検証する方法を定めます。
チェック38
導線のどのページまたは部分に注意が必要かは明らかですか?
担当者が問題の場所を特定できるよう、タスクを具体的にします。URL、箇所、共通部品、影響する導線を記録します。広がりが不明なら、1つの観察をサイト全体の不具合とせず、類似ページの調査を追加します。
チェック39
選択した各アクションには、完了を確認する実用的な方法がありますか?
期待する結果と、公開後にどう確認するかを書きます。確認済みの文言との比較、導線の確認、許可されたお問い合わせテストなど、目的に合う方法を記します。「使いやすくする」だけなら、タスクの完了が分かる具体的な条件にします。
チェック40
修正されたページの問題と、測定されたビジネスの改善を区別できますか?
変更直後の確認で分かることと、その後の業務データが必要なことを示します。フォームの修正と、有望なお問い合わせの変化は分けて記録します。成果を測定していなければ、売上、検索順位、コンバージョンの主張を加えず、修正を正確に報告します。
メモを役立つ記録に変える
観察、解釈、次のタスクをまとめて読めるようにしておきます。以下の行は、完成したレコードの架空の例です。調査は、決定に必要な何かを解決する場合に有効な次のアクションとなり得ます。
| ページ | 観察 | なぜそれが重要なのか | 次のアクション | 何を確認するか | 状態 |
|---|---|---|---|---|---|
| サービスページ | 成果物については説明されていません。 | 購入者は、サービスが何を提供するかを判断できません。 | 範囲を確認し、成果物を追加します。 | 公開された文言が現在の条件と一致し、読者が説明できること。 | 追加確認が必要 |
| お問い合わせフォーム | 許可されたテストで、入力エラーが繰り返される。 | 記録したテストで、必要な導線を最後まで進めない。 | 障害を再現し、修復します。 | 合意されたテストが完了し、受信されます。 | 問題は確認済み、修正は未完了 |
| 便利なガイド | 検索パフォーマンスの記録は利用できません。 | 削除すると有用なルートが破棄される可能性がありますが、実際の検索用途は不明です。 | 判断前に、プロパティ所有者へ関連データを依頼する。 | この決定では、入手可能な証拠を引用するか、残りの不確実性について述べています。 | 所有者の確認が必要 |
長いリストから次のアクションをいくつか選択します
まず、重要なタスクを妨げる確認された障害に対処し、次に、より大きなコミットメントを変更する可能性がある問題を解決します。壊れた送信パスは、表面的な変更を行う前に注意を払う価値がある可能性があります。不明なインデックス登録は、有用なガイドを削除する前に調査する必要があるかもしれません。
原因が同じ観察はまとめます。条件が食い違う複数のサービスページなら、所有者が1つの決定をし、各ページの文章を併せて変える必要があるかもしれません。先に必要なタスクから順に行い、未確定の情報を基にデザインしないようにします。
選択したアクションごとに、ページ、責任のある役割、および受け入れチェックを書き込みます。その他の調査結果はすべてすぐに作業に移すのではなく、記録しておいてください。合理的なシーケンスを正当化するために、数学的な Webサイトのスコアは必要ありません。
ワークシートを使用してフォローアップを整理する
以下のワークシートでは、この記事を9つの大きな確認段階にまとめています。進捗件数は、この9段階を数えるもので、上の40問を個別に数えるものではありません。各段階のメモ欄に、関連する確認項目、ページ、未完了の作業を記録します。
「未確認」はまだ確認していない状態です。「確認済み」は実施した状態で、問題が残っている場合もあります。「追加確認が必要」は、未完了の調査や対応を示します。「対象外」は、定めた確認範囲に当てはまらない段階です。理由も記録します。
例:「お問い合わせ導線。項目21〜25を確認。必須項目を直した後もテストが失敗。開発者が再現して修正し、取り決めた受信テストを繰り返す」。メモは、次の対応に必要な情報に絞ります。
ワークシートは、サイトの分析、依頼の送信、総合監査の開始を行いません。選択とメモはページを開いている間だけ残り、再読み込みで消えます。残す必要があれば、閉じる前に印刷してください。進捗の件数は、品質スコアではありません。
チェックリストの使用に関する質問
どのページから始めればよいでしょうか?
決定につながるページを選択してください: 主な提供内容、補足説明または例、お問い合わせへのルート。役割が重要な場合は、ガイドまたはその他のエントリ ページを追加します。未レビューのページが黙って含まれないように、選択内容を記録します。
自分で何を確認できますか?
提供内容を読み、ナビゲーションをたどり、関連する条件と裏付けを比べられます。取り決めたお問い合わせテストと、その結果の記録もできます。技術的な解釈、非公開データ、専門的な利用者調査が必要なら、担当者に相談します。
アクセス解析がない場合は?
公開ページと導線チェックを続行します。観察できることを説明し、コンバージョン率、トラフィック構成、ビジネス効果は未確認のままにしておきます。情報が永久に利用できないと判断する前に、どのレコードが存在するかを所有者に尋ねてください。
いつ専門家に相談すべきですか?
問題を確実に再現・解釈できない場合、アカウントデータが必要な場合、変更が重要な導線に影響する場合です。ページ、手順、裏付け、未解決の疑問を伝え、次の確認を具体的にします。
いつレビューを繰り返せばよいですか?
リリース後に変更された領域を再確認し、サービス、対象ユーザー、ナビゲーション、または問い合わせプロセスが変更された場合には、より広範な導線を再検討します。目的とリスクに応じてタイミングを選びましょう。有意義な比較を計画する場合は、以前の対象範囲と定義を保持してください。
観察結果をまとめる
チェックリストで観察を集めます。それらを併せて検討し、明確な計画にまとめたい場合は、総合監査を利用します。レポートの見本では、指摘が、実施できる完了確認を備えた具体的なタスクになる流れを示します。
情報源
このページの検索チェックに関する公式のガイダンス。
- Google:検索の技術要件 — チェック済み
- Google: 正規 URL — チェック済み
- Google: リンクのベスト プラクティス — チェック済み
チェックリストを次の決定に役立てる
検索、提供内容、証明、および問い合わせの観察を総合的に検討する必要がある場合は、Webサイトの総合監査をリクエストしてください。これにより、チームは次に何を調査または変更するかを選択できます。
Webサイトの総合監査を依頼する →