すべてのダッシュボードが問題なく見えるストアを想像してみてください。ホームページはインデックスされ、Lighthouseは緑、構造化データバリデーターもエラーを出していません。しかし同時に、Googleショッピングの価格はカート内の価格と一致せず、モバイルのフィルタードロワーはキーボードユーザーを閉じ込め、すべての購入は二重に記録されています。
こうした問題は、簡単なヘルスチェックでは見つかりません。オンラインストアは単なるページの集まりではなく、つながったシステムだからです。商品データはページ、構造化データ、ショッピングフィードへと流れていきます。スクリプトとサードパーティタグが、全体の読み込み速度を決めます。チェックアウトは関心を売上に変え、アナリティクスはその旅路全体を正確に記録することになっています。どこか1か所が壊れると、それは静かに他のすべてを歪めてしまいます。
だからこそ、役に立つeコマース監査はサイトマップではなく買い物客を追います。以下のチェックリストはストアの発見から始まり、注文の完了で終わります。これによって、証拠、担当者、修正済みかどうかを判断する明確なテストを備えた、実際の問題の優先順位付きリストが得られます。
この監査を実施するタイミングと、順序が重要な理由
新しいeコマースのクライアントを担当したとき、リデザインやプラットフォーム移行の後、大きな成長施策の前、あるいは定例チェックでストア全体の劣化が見つかったときに、完全な監査を実施します。軽い確認なら3〜6時間、重要なテンプレートをすべて適切にテストする標準的な監査なら1〜2日を見込んでください。ログ、フィード、アナリティクスの深掘り調査には、通常は別途時間が必要です。
この順序には意味があります。Googleがカテゴリページをインデックスできないのにコンバージョンの摩擦を評価しても意味がありませんし、購入タグが二重に発火するのにファネルレポートを信用しても意味がありません。
重複した購入イベントは売上が増えた証拠ではありませんし、Googleが見ている価格がカート内の価格と違うなら、速い商品ページも健全とは言えません。だからこそ監査は段階的に進みます。まず最初の発見から始まり、次に商品情報の真実性、速度、購入そのものへと進み、その後にようやく計測へと進みます。
始める前に、必要なものを集めましょう。つまり、以下へのアクセスです。
- Search Console、
- アナリティクス、
- タグマネージャー、
- カタログまたはフィードのソース、
- マーチャントセンター、
- サイトへの最近の変更点のリスト。
ステージ1：検索エンジンはカタログを見つけられるか？
1. ストア全体を代表するサンプルを組む
eコマースのバグの多くは、共有テンプレートと珍しい商品ステータスに潜んでいます。きれいなホームページは、絞り込まれたカテゴリ、バリアントのロジック、在庫切れ、チェックアウトについて何も教えてくれません。だからこそ、正しい市場、通貨、言語で本番サイトをテストしていることをまず確認してください。そのうえで、次のそれぞれについて少なくとも1つのURLを選びます。
- ホームページ
- 優先カテゴリ
- より深い階層のカテゴリ、または承認済みのフィルターページ
- 典型的な商品
- バリアントのある商品
- 在庫切れまたは販売終了の商品
- 内部検索結果ページ（結果が0件のものも含む）
- カート、チェックアウト、注文確認ページ
リスクが高そうに見えるテンプレートには、扱いにくい例や珍しい例を追加します。アナリティクスのランディングページレポートとカタログのエクスポートが、選定の役に立ちます。
すべての重要なテンプレートとチェックアウトの状態に、名前付きのテストURLが割り当てられ、テストできなかったものは「未テスト」と明記されていれば完了です。
2. クロール可能性、インデックス、canonical、サイトマップを確認する
クロール経路が壊れていると、商品を増やしても影響を受けるURLが増えるだけです。シグナルが混在していると、問題の診断はさらに難しくなります。robotsルールが一方のことを言い、canonicalタグとサイトマップがまったく別のことを言っているかもしれません。
robots.txt、XMLサイトマップ、レスポンスコード、robotsメタタグとヘッダー、canonicalタグ、ページネーション、内部リンクを確認します。Search ConsoleのURL検査を使い、サンプルページに対してGoogleが実際にどのcanonicalを選んだかを確認してください。次に、サイトマップと現実を突き合わせます。サイトマップには、リダイレクト、エラー、noindexページ、重複ではなく、200を返す公開中でインデックス可能なページが載っているべきです。
意図したランディングページが200を返し、クロール可能で、一貫したcanonicalとインデックスのポリシーに従い、サイトマップに含まれていれば完了です。重要な除外には、それぞれ説明か担当者がいるべきです。
3. リンクをたどる：リダイレクト、エラー、JavaScript
ストアはブラウザでは完全に見えても、クローラーや支援技術にはずっと薄いバージョンしか見えていないことがあります。クローラーを実行して、壊れた内部リンク、リダイレクトチェーン、ループ、ソフト404を見つけます。次に、レンダリングされたページと生のHTMLを比較します。商品カード、ページネーション、パンくず、カテゴリリンクは実在してクロール可能であるべきで、重要なコンテンツがJavaScriptだけに依存していてはいけません。
内部リンクが最終的な遷移先へ直接向かい、エラーページが正しいステータスコードを返し、優先商品が無限スクロールに頼らずに見つけられれば完了です。
4. カテゴリ、フィルター、ページネーション、サイト内検索をテストする
カテゴリとフィルターの仕組みは、検索エンジンにとってのクロールトラップと、買い物客にとってのいらだちを同時に生み出すことがあります。技術的にインデックス可能でも、掲載商品の半分が無関係なら、そのページは弱いランディングページです。
デスクトップとモバイルの両方でフィルターを試します。複数選択、「すべてクリア」、結果件数、並べ替え、ページネーションまたは「もっと見る」、結果が0件になるフィルターの組み合わせを確認します。フィルターが生成するURLを見て、ストアのインデックス方針と比較してください。長いカテゴリ説明文が商品グリッドを画面外へ押し下げていないかにも注目します。
コントロールが一貫して動作し、無作為なフィルターの組み合わせが意図しないランディングページにならず、買い物客が現在位置を失わずにフィルターを解除できれば完了です。
ステージ2：商品データは真実を語っているか？
5. 商品の同一性、価格、在庫、バリアントを突き合わせる
1つの誤ったフィールドは、買い物客を誤らせるだけでなく、チェックアウトでの不一致にまでつながることがあります。一方で、データは完全に正しい形式でありながら、内容が間違っていることもあります。
代表的な商品をいくつか選び、名前、ブランド、SKU、GTINまたはEAN、選択されたバリアント、価格、通貨、在庫状況、画像、主要な仕様を、それが現れるすべての場所で比較します。ページ上の表示、構造化データ、マーチャントフィード、カート、チェックアウトを確認してください。セール品、バリアント、在庫切れ、予約販売、販売終了の商品も含めます。
サンプルの事実がすべての表示面で一致し、ブランドと製造元の違いのような意図的な差異がある場合は、データモデル上で明示されていれば完了です。
6. 構造化データを買い物客に見える内容と照合して検証する
構造化データは、ページを正確に記述しているときにだけ役に立ちます。ページとチェックアウトがどちらも在庫切れと言っているのに、バリデーターは「InStock」を喜んで受け入れてしまいます。だからこそ、各商品ステータスをGoogleリッチリザルトテストまたはSchema.orgバリデーターに通してください。次に、マークアップされた値と、表示されている内容およびソースフィードを比較します。バリアントのある商品では、マークアップの方法とcanonicalの設定が、実際のページ構築方法と一致しているか確認します。
サンプルの対象ページに必須プロパティの欠落がなく、マークアップが表示内容と一致し、レビューと評価がその商品上で買い物客に見える場合にのみマークアップされていれば完了です。
ステージ3：ストアは実際の買い物客にとって速いか？
7. まずフィールドデータでCore Web Vitalsを測定する
実ユーザーデータとLighthouseの1回の実行では、答える問いが異なります。Lighthouseは問題の再現には役立ちますが、実際の買い物客が合格しているか失敗しているかはわかりません。
PageSpeed InsightsとSearch ConsoleのCore Web Vitalsレポートから始めます。フィールドデータがそのURLちょうどのものなのか、サイト全体のものなのかを記録してください。75パーセンタイルで測定されるGoogleの「良好」なしきい値は次のとおりです。
- LCP（読み込み）：2.5秒以下
- INP（応答性）：200ミリ秒以下
- CLS（視覚的な安定性）：0.1以下
モバイルとデスクトップは別々に見ます。フィールドデータがない場合は、結果を不明として記録し、ラボの結果は暫定的なものとして扱ってください。不明は緑と同じではありません。
優先テンプレートごとに、デバイス別のフィールドでの判定、またはデータ不足の明記があり、その情報源と期間が記録されていれば完了です。
8. スコアだけでなく原因を突き止める
「画像を圧縮しましょう」「JavaScriptを減らしましょう」といった一般的な助言は、多くの場合、本当のボトルネックを見逃し、失敗している指標を動かさない作業を生み出します。原因となっている特定の要素、リクエスト、スクリプトを見つけてください。
LCP要素を特定し、何がそれを遅らせているのかを調べます。次に、よくある容疑者を確認します。画像のサイズ指定、ファーストビュー画像への遅延読み込み、レンダリングをブロックするCSS、フォント読み込み、サードパーティスクリプト、ロングタスク、キャッシュ、サーバー応答時間、レイアウトシフトの発生源、二重に読み込まれたタグなどです。
同じ条件でテストを繰り返し、最良の1回ではなく一貫した統計値で比較してください。Total Blocking Timeは有用なラボのシグナルですが、INPではないことを忘れないでください。
重要なパフォーマンス上の発見すべてに、失敗している指標、影響を受けるテンプレート、再現可能な原因、担当者が明記されていれば完了です。
ニュースレターに登録
最新のヒント、トレンド、お得な情報を無料で入手。
ステージ4：実際に購入できるか？
9. 実際の購買操作でモバイルの使いやすさとアクセシビリティをテストする
自動スコアはすべての操作を網羅しているわけではありません。フィルタードロワーがキーボードフォーカスを閉じ込めたり、Cookieバナーがカートに追加ボタンを覆っていたり、サイズ選択にアクセシブルなラベルがなかったりしても、ストアはスキャンに合格してしまいます。
幅360〜390ピクセルのスマートフォンでテストし、テキストを拡大し、キーボードだけで旅路全体を試してみます。メニュー、ドロワー、ダイアログでのフォーカス順序と可視性を確認してください。ラベル、ボタン、フォームのエラー、タッチターゲットが引き続き意味を成しているかを確認します。
買い物客が、隠れたコントロールやフォーカストラップに妨げられずに主要な旅路を進め、モバイルで価格、在庫状況、バリアントの選択、カートに追加ボタン、チェックアウトを隠すものがないなら完了です。
10. カートとチェックアウトを管理されたテストとして実行する
チェックアウトボタンが見えることは、チェックアウトが機能する証拠にはなりません。チェックアウトのバグは商業的な事故であり、アナリティクスも損ないます。
これをテストするには、通常の商品とバリアントをカートに追加します。数量を変更し、商品を削除し、クーポンがあれば適用します（意図的に無効なものでも構いません）。次に、ゲストとアカウントのチェックアウト、配送オプション、支払い方法の選択、入力エラー、戻るボタン、モバイルのレイアウトをテストします。テスト注文または承認済みの課金なしの経路を使ってください。許可なく実際の注文をしてはいけません。
購入が完了するか合意したテストの境界に達し、合計が正しく保たれ、エラーメッセージが次に何をすべきかを伝え、ブロックされた経路があれば証拠とビジネスへの影響とともに記録されていれば完了です。
ステージ5：旅路を正しく計測しているか？
11. アナリティクス、重複タグ、同意を検証する
重複したタグは、ページビュー、カートに追加イベント、購入を水増しします。値の欠落や不正な形式は、売上レポートを意思決定の根拠として使えないものにします。目標は単純です。1つの買い物客の行動が、正しい商品、金額、通貨、トランザクションID、同意状態を伴う1つのイベントを生み出すことです。
すべてのタグマネージャーコンテナ、Googleタグ、広告ピクセル、アフィリエイトスクリプト、サーバーサイド連携を洗い出します。次に、管理されたセッションでview_item、add_to_cart、begin_checkout、purchaseを追跡します。ブラウザが送信する内容を、GA4のDebugViewとバックエンドの注文レコードと比較してください。買い物客が同意を選択する前と後の両方でテストします。
各行動がそのイベントを正確に1回だけ発火させ、購入が安定したトランザクションIDを持ち、金額と通貨がバックエンドと一致し、必須でないタグが同意ポリシーを守っていれば完了です。
12. Search Consoleとマーチャントセンターを、見つけた内容と突き合わせる
ローカルでのページテストでは、インデックスされたすべてのcanonical、サイトマップの警告、商品の否認、失われた検索クエリまではわかりません。一方で、ダッシュボードのアラートが、すでに修正済みの問題を指していることもあります。
Search Consoleで優先URLを検査し、商品レポートとマーチャントリスティングレポートを確認し、マーチャントセンターの診断を実際のサイトで見た内容と照合します。再クロールやフィード処理はデプロイより遅れるため、日付を記録してください。
重要なダッシュボードの指摘がすべて実地の証拠と一致するか、反映待ちとしてマークされ、未解決の各項目に担当者がいれば完了です。
ステージ6：買い物客はこのストアを信頼するか？
13. 信頼のシグナル、連絡先情報、配送、返品を確認する
隠されている、または矛盾する商業情報は、買い物客をためらわせ、サポートチケットを増やします。ヘッダーとフッター、お問い合わせページ、チェックアウト、ポリシーページを比較してください。
事業者の身元が明確で、配送、返品、支払いに関する記載が旅路全体で一致し、検証できない信頼バッジがなければ完了です。
14. HTTPS、混合コンテンツ、フロントエンドの衛生状態を確認する
これはペネトレーションテストではなく、基本的なデータ衛生の問題です。HTTPがHTTPSへ1ホップでリダイレクトされること、証明書が有効であること、混合コンテンツがないこと、フォームが正しく送信されることを確認します。コンソールで重大なエラーを確認してください。本当のセキュリティ脆弱性と思われるものは、一般的な警告から診断しようとせず、専門家に引き継ぎます。
優先ページとチェックアウトが安全に読み込まれ、リダイレクトが1ホップで、フォームが期待どおりに動作すれば完了です。
発見から修正へ
15. 発見事項を担当者のいる修正キューに変える
スクリーンショットやスコアで終わる監査は、リスクを減らしません。1つの壊れたテンプレートに起因する50の症状が、50の無関係なチケットになってはいけません。発見事項は根本原因ごとにまとめます。それがコンポーネント、テンプレート、フィードルール、トラッキング設定のどれなのかを記録してください。影響を受けるURLは証拠として残します。そのうえで優先順位を付けます。
- P0： ビジネスを止めている進行中の障害、またはサイト全体の重大な問題
- P1： 確信のある重大な欠陥
- P2： 影響範囲が限られた重要な問題
- P3： 監視すべき改善点
重要な発見事項すべてに、1人の担当者、期限、「修正済み」を判断するテスト、リリース後に再確認する日付があれば完了です。
成果物
発見事項ごとに1行、冒頭に短い要約を置いた、バージョン管理されたドキュメントまたはスプレッドシートを引き渡します。各行には次を含めます。
- 動作、
- 期待される動作、
- 影響を受けるURL、
- 証拠と収集した日時、
- 重大度と確信度、
- 推定される原因、
- 推奨される修正、
- 担当者と、完了を証明するテスト。
ただし、誰かがチケットを閉じたからといって、問題を修正済みとしてはいけません。本番環境でテストが通ったときに検証済みとマークしてください。
作業に役立つツール
しっかりした最初の確認を行うのに、サブスクリプションは必要ありません。必要なのは次の無料ツールだけです。
- Google PageSpeed Insights ：フィールドデータ（取得可能な場合）とLighthouseの診断
- Google Search Console ：インデックス、サイトマップ、URL検査、Core Web Vitals、構造化データのレポート
- Googleリッチリザルトテスト とSchema.orgバリデーター ：構造化データ用
- Chrome DevToolsとLighthouse ：ネットワーク、パフォーマンス、レイアウトシフト、アクセシビリティ、コンソールの確認
- Google Tag Assistant とGA4 DebugView ：イベントトラッキング用
- SSL Labs Server Test ：TLS設定用
近道をしたいなら、AmICited を使えば、そうした証拠をすべて1か所に集め、後で使えるベースラインを保てます。Performance Impact ビューは、テンプレートをLCP、INP、CLS、サーバー応答時間で比較します。URL Inspection とSitemaps and Indexing は、優先URLのインデックス状況を追跡します。Products とAssortment は、カタログのどの部分が商業的に最も重要かを示します。レポートハブの注釈 は、各リリースとその後に起きたことを結び付けます。ツールは証拠を提供します。何が正しく、どのトレードオフが許容できるかを決めるのは、依然としてストアのオーナー、開発者、アナリストです。
監査の後
確認された各問題は、それを解消できる専門のワークフローに送ります。クロールとレンダリングの問題はテクニカルSEO監査 へ、フィールドパフォーマンスの失敗はCore Web Vitalsの修正 へ、ファセットと在庫状態の問題はカテゴリと商品のレビュー へ、トラッキングの問題はアナリティクスの責任者へ。
修正のたびに監査全体を再実行する必要はありません。影響を受けた領域を再テストし、リリースに注釈を付けて後で何が変わったかを見られるようにし、次の劣化は定例のヘルスチェックに見つけてもらいましょう。
すべてが問題なく見えていたストアに戻る
冒頭のストアを覚えていますか？ホームページはインデックスされ、Lighthouseは緑、バリデーターもクリーンでした。それでもGoogleショッピングは間違った価格を表示し、フィルタードロワーはキーボードユーザーを閉じ込め、すべての売上は二重に計上されていました。
それを指摘したダッシュボードは1つもありませんでした。このチェックリストなら3つとも捕まえられたはずです。価格の不一致はステップ5、フォーカストラップはステップ9、二重計上された購入はステップ11です。それぞれは買い物客の道のりのどこかで壊れており、監査が見るのはまさにその場所です。
これが、サイトマップではなく買い物客を追うことで得られるものです。「サイトは健全に見えるか？」と問うのをやめ、より難しい4つの問いを立て始めます。人は商品を見つけられるか？ストアがそれについて言っていることは本当か？実際に購入できるか？そして、購入したことを確認できるか？この4つすべてに「はい」と答えられるストアは、完璧なスコアを持つストアより良い状態にあります。
サンプルURLを選び、時間を確保して、ステージ1から始めましょう。最初の確認が最も時間がかかります。その後は、修正したものが修正されたままであることを確かめる作業が大半になります。
