技術 SEO 監査 playbook

ストアの SEO 問題は編集的というより構造的です:クロールの浪費、ファセットの混沌、孤立商品、無効なマークアップ。監査の価値は発見でなく——修正の順序にあります。

汎用の監査ツールは 400 件の問題とゼロ件の計画を出します。回す価値のあるストア監査はより鋭い問いを立てます——クロールバジェットは転換するページに使われているか、インデックスはカタログと一致するか、マークアップは検証を通るか、ユーザーの実際にいる所でストアは速いか——そして修正をトラフィックリスク順に並べます。この playbook はその監査と、より重要な、その後のトリアージを回します。

ステージ 1:クロールとインデックスの現実

検索エンジンと同じ方法でストアをクロールし、3 つの集合を比べます:存在するページ、クロールされるページ、インデックスされたページ。差分が発見です。クロールバジェットを食うファセット URL、どの内部リンクも指さない孤立商品ページ、ソフト 404 のコレクション、長年のリプラットフォームが残したリダイレクト連鎖——一定の店齢を過ぎたストアは 4 つ全部持っています。

  • クロール可能な URL 台帳対、意図したカタログ——乖離は皆の予想を超える

  • ファセットナビ:どの組み合わせがクロール・インデックス可能で、どれが本当に値するか

  • 孤立商品、リダイレクト連鎖、ソフト 404 の列挙

  • テンプレート種別のインデックスカバレッジ——商品、コレクション、コンテンツ

ステージ 2:成績を縛る層

構造化データはテンプレート別に検証——抜き取りでなく検証。テンプレート 1 つの誤りは、それを使う全ページに増幅されるからです。レンダリングの確認:クローラーが受け取るもの対、出すつもりだったもの——スクリプトの重いテーマとヘッドレス構築での古典的な静かな失敗。速度はテンプレート別の実測データから。多言語ストアなら hreflang の完全性。どの層も確認は機械的で、放置は高価です。

ステージ 3:トラフィックリスクでトリアージし、予定で再監査

400 件の問題は、トラフィックリスクで重みづけると短い順序つきリストに畳まれます:テンプレート級の修正が先(1 修正でカタログ全体に効く)、次に高価値ページの修正、それからロングテール。その順で公開し、Search Console で検証し、再監査を予定します——テーマ更新、アプリ導入、カタログの成長が技術的負債を絶えず再生するからです。監査はスナップショット。予定こそが資産です。

動作の流れ

01

クロールして比較

エンジンの見る形でストアをクロール。存在・クロール・インデックスの 3 集合を diff して本物の発見を。

02

縛りの層を検証

構造化データ、レンダリング、実測速度、hreflang をテンプレート別に確認。

03

レバレッジで修正、予定で再監査

テンプレート級が先、高価値ページが次、Search Console で検証、リズムで反復。

得られるもの

  • ファセットノイズから収益ページへ回されたクロールバジェット

  • 実際に売っているカタログと一致するインデックス

  • 大半でなくすべてのテンプレートで検証を通るマークアップ

  • トラフィック損失でなく予定で捕まる技術的負債

よくある質問

ストアの再監査頻度は?

フル監査は四半期ごと。壊れやすい層——構造化データの有効性、インデックスカバレッジ、速度退行——は継続監視。監査の合間に静かに壊れるからです。リプラットフォームや大きなテーマ変更の後は:即時。

ストアで最も多い単一の発見は?

制御されないファセットナビ——何千ものクロール可能なフィルター順列がクロールバジェットを薄め、コンテンツを複製します。修正はテンプレート級でカタログ全体に効くため、トリアージの筆頭になるのが普通です。

トラフィックが好調でも監査は要る?

伸びるトラフィックは構造の無駄を隠します。監査は未回収の分を教えます。そして捕まえる価値のある故障——誤った robots 変更によるインデックス除外、テーマ更新によるマークアップ無効化——は数週間の被害の後でしかトラフィックに現れません。

どのエージェントが実行?

Visibility がクロール・検証・トリアージを、Ops が実測速度データを、Builder がテンプレート修正を担当。再監査のリズムと直近の正常状態は共有メモリにあり、退行は謎でなく diff です。

あなたのストアにチームを配置する

ストアフロント、アナリティクス、メール基盤を接続し、目標を設定すれば、あとはエージェントが一気通貫で実行します。無料プランなら自分のモデルキーですぐに始められます。