テクニカルSEOのチェックリスト｜ECサイトで定期確認する項目

テクニカルSEOのチェックでは、検索エンジンが重要ページを発見し、取得し、正規URLとして登録できる状態かを確認します。ECサイトは商品公開、在庫、カテゴリ再編、機能追加でURLと設定が日々変わるため、公開時だけでなく定期運用が必要です。

すべての項目を同じ頻度で見る必要はありません。重要ページの異常は日次、サイト全体の傾向は週次・月次、大規模な構造監査は四半期など、影響と更新頻度に合わせます。

クロールのチェック

• 主要商品とカテゴリへ通常リンクで到達できるか
• 商品カードやページ送りにhrefがあるか
• robots.txtで重要URLや必要リソースを塞いでいないか
• 5xx、429、応答遅延が増えていないか
• 不要なパラメータURLへクロールが偏っていないか

新商品、売れ筋、深い階層の商品をサンプルに選びます。サーバーログが使える場合は、Googlebotのアクセス先とステータスをページ種別ごとに確認します。

インデックスのチェック

• 検索対象ページが200で表示されるか
• 誤ったnoindexが付いていないか
• Googleが選択したcanonicalが意図どおりか
• 主要ページが「クロール済み・未登録」に偏っていないか
• 操作用URLが大量に登録されていないか

Search Consoleの件数だけで判断せず、理由ごとのURL例を確認します。会員ページのnoindexは正常でも、販売中商品が含まれていれば優先対応です。

canonicalと重複のチェック

• 正規ページが自己参照canonicalを持つか
• 一ページに異なるcanonicalが複数ないか
• 内部リンクとサイトマップが正規URLを使うか
• 計測・並び替え・表記違いのURLが増えていないか
• ページネーションを一ページ目へまとめていないか

商品バリエーションや複数カテゴリ所属は、サイトのルールと実際の出力を照合します。URL生成ルールが変わったときは、既存ページだけでなく新規商品でも確認します。

XMLサイトマップのチェック

• 200の正規URLだけを含むか
• noindex、404、転送元が混ざっていないか
• 商品・カテゴリ・記事のURL数が想定と合うか
• lastmodが実際の重要な更新を反映するか
• Search Consoleで正常に取得されているか

ファイル生成が止まる、空になる、全URLが毎日更新扱いになる事故を監視します。URL数の急増・急減は商品入れ替えで説明できるか確認します。

HTTPステータスのチェック

• 販売中商品が200か
• 移動URLが一回の適切な転送か
• 終了商品が404、410または関連ページへの転送か
• エラー画面が200を返していないか
• 5xxや429が継続していないか

販売中、在庫切れ、販売終了、誤ID、再公開の状態別にURLを用意し、自動テストします。画面の文言だけでなく最初のHTTP応答を確認します。

URLとリダイレクトのチェック

• 同じ内容へ複数形式でアクセスできないか
• 大文字・小文字や末尾スラッシュが統一されているか
• セッションIDや一時値が内部リンクにないか
• 転送チェーンとループがないか
• 旧URLから関連性の高い新URLへ転送するか

商品改廃が多いサイトでは、転送一覧に理由、公開日、最終URLを残します。無関係なトップページへの一括転送を避けます。

モバイルのチェック

• 商品説明、価格、在庫、仕様がパソコン版と同等か
• 主要な内部リンクがモバイルにもあるか
• title、robots、canonical、構造化データが一致するか
• 画像やJavaScriptが取得できるか
• 固定バナーが購入操作を妨げないか

モバイルファーストインデックスを前提に、スマートフォン用Googlebotのレンダリング結果を確認します。高性能端末だけでなく一般的な端末と回線でも操作します。

JavaScriptのチェック

• 商品やカテゴリに固有URLがあるか
• レンダリング後に主要情報がDOMへ存在するか
• 商品リンクがa要素のhrefを持つか
• 初期HTMLからrobotsとcanonicalが正しいか
• API失敗時に適切な応答と案内があるか

機能追加やフレームワーク更新後は、商品、カテゴリ、フィルタ、バリエーションを再検証します。画面で動くことと検索エンジンが理解できることを分けて見ます。

Core Web Vitalsのチェック

• LCP要素と読み込み時間を確認したか
• カート追加や絞り込みのINPに問題がないか
• 画像や広告の領域を確保してCLSを抑えているか
• 第三者スクリプトの必要性を見直したか
• 実データとラボデータを使い分けたか

トップ、カテゴリ、商品などテンプレートごとに確認します。指標だけでなく、商品画像が見える、操作が反応する、誤タップしないという体験を目視します。

構造化データのチェック

• 画面上の商品情報と一致するか
• 価格、通貨、在庫が最新か
• 商品識別子とバリエーションが正確か
• 架空の評価やレビューを含んでいないか
• リッチリザルトテストとSearch Consoleで確認したか

商品マスタ変更や価格連携の改修後は、構造化データも同時に確認します。エラーがなくてもリッチリザルト表示は保証されないため、正確性を基準にします。

HTTPSとセキュリティのチェック

• 証明書が有効で自動更新を監視しているか
• HTTPから対応するHTTPSへ転送するか
• mixed contentがないか
• Cookie、ログイン、カート、決済が正常か
• WAFがGooglebotを誤って拒否していないか

セキュリティとSEOを別々に扱わず、公開URLとリソースが安全に取得できる状態を確認します。障害や証明書期限切れは監視と通知の対象にします。

変更管理のチェック

• 変更日、対象テンプレート、担当者を記録したか
• 公開前の検証環境と受け入れ条件があるか
• 複数の大規模変更を同時にしていないか
• 問題時の切り戻し条件があるか
• 公開後に同じURL群を再確認したか

テクニカルSEOは一度の診断ではなく、開発と商品運用の変更管理です。チェック結果を課題、影響範囲、優先度、担当、期限へ落とし込みます。

優先順位の付け方

主要ページが取得できない、全商品にnoindexが付く、canonicalが一斉に誤る、5xxが続く問題は最優先です。次に、不要URLの増加、表示速度、構造化データの警告などを影響範囲と事業価値で並べます。

件数だけでなく、売れ筋、新商品、重要カテゴリへの影響を見ます。個別修正より、テンプレートや生成ルールを直して再発を防げる課題を優先します。

監査結果の管理方法

課題ごとに、対象URL例、ページ種別、発見日、影響範囲、現在の状態、期待する状態、担当、期限、検証方法を記録します。「canonicalがおかしい」ではなく、どのテンプレートがどのURLを出しているかまで具体化します。

修正済みになった課題は、公開直後の確認とSearch Consoleでの後日確認を分けます。HTMLが直っただけで完了にせず、再クロール後の状態まで追います。一方、検索結果の変化を保証する期限は置かず、技術的な受け入れ条件を明確にします。

チェックリストを更新する

新しい決済機能、商品バリエーション、サイト内検索、JavaScriptフレームワークを導入したら、監査項目も追加します。使わなくなった機能の確認を残し続けると、重要項目が埋もれます。

障害が発生したときは、原因と再発防止をチェックリストや自動テストへ反映します。担当者の記憶ではなく、公開フローの中で確認できる状態にすることが継続運用の要点です。

まとめ

テクニカルSEOのチェックは、クロール、インデックス、正規化、HTTP応答、モバイル、速度、JavaScript、構造化データを一貫して確認する作業です。ECサイトでは商品状態や機能追加で設定が変わるため、定期運用へ組み込みます。

まず重要なページ種類からサンプルを決め、異常を早く見つける日常監視と、サイト全体を見直す定期監査を分けてください。課題を生成ルール単位で直すことで、ページ数が増えても安定したSEO基盤を維持できます。

次に読みたい関連記事

• テクニカルSEOとは？ECサイト担当者が押さえる基本と優先順位
• Googleのクロールとは？ECサイトのページが発見される仕組み
• SEOにおけるインデックスとは？登録状況の確認と改善方法
• noindexの使い方｜ECサイトで検索結果から除外するページの判断
• canonicalの使い方｜ECサイトの重複URLを整理する基本
• ECサイトのURL構造をSEO視点で設計する方法
• SEOで重要なHTTPステータスコード｜200・3xx・4xx・5xxの意味
• 301と302リダイレクトの違い｜ECサイトでの正しい使い分け
• モバイルファーストインデックスとは？ECサイトで確認すべき項目
• ECサイトのJavaScript SEO｜商品情報とリンクを正しく伝える方法