identify-search-maintenance について
identify-search-maintenance は、検索メンテナンスの調査対象ページを見つける SEO 分析担当者向けのスキルです。順位低下と需要、CTR、技術面、サイト内競合による変化を区別し、記事の書き換えや公開ではなく、根拠に基づく調査リストを作成します。
主な機能
- 01直近と前年同期の Search Console データ比較
- 02ページ単位とクエリ単位の検索データ確認
- 03独立した需要指標と順位変化の照合
- 04付属 Python スクリプトによる候補選定
- 05順位低下と他の減少要因の分類
- 06優先順位付き診断レポートの作成
活用シーン
- 01SEO 調査対象ページの優先順位付け
- 02順位低下と検索需要減少の判別
- 03候補 URL の技術・インデックス問題の確認
- 04競合ページと検索結果の観察記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ robot-inventor/ agent-skills --skill identify-search-maintenanceインストール後、Claude Code で/identify-search-maintenanceを入力して読み込まれたか確認します。
同梱ファイルreferences/selection-rubric.mdscripts/select_rank_led_candidates.py
詳細
検索メンテナンス対象の特定
検索メンテナンスを行う価値があるページを見つけ、順位による損失と需要の変化を区別できる根拠を示します。成果物は、優先順位を付けた調査バックログと診断です。記事の書き換えや公開作業は決して行いません。
対象範囲とガードレール
- プロパティ、トラフィックチャネル、日付、ロケール/デバイス、およびGoogleの確認にユーザーがログイン済みのChromeセッションを使用する必要があるかを確認します。
- 直近の比較(通常は最新の3か月とその直前の3か月)と、前年同期比の比較(通常は直近の3か月とその1年前の同じ3か月)の両方を使用します。比較可能な最新のSearch Console完了日を期間の末日とし、日数と曜日の構成をそろえます。利用できないベースラインはゼロではなく、必ず
N/Aと記載します。 - 各比較でSearch Consoleの検索タイプ、国、デバイス、プロパティの範囲、canonical URLの処理、ブランドクエリの除外条件を統一します。GA4のタイムゾーン、Organic Searchチャネルの定義、ランディングページURLの正規化方法を記録します。
- ページ単位とクエリ単位のSearch Consoleデータの両方を確認してから、そのページを候補とします。GA4はトラフィックの補足根拠であり、クエリや順位のデータの代わりにはなりません。
- クリック数だけから順位低下が損失の原因だと判断してはいけません。URLで絞り込んだSearch Consoleの表示回数とプロパティ全体の表示回数は、サイト自体の表示状況の影響を受けるため、単独では需要の指標になりません。独立した需要の代理指標(たとえば、クエリ/トピックのGoogle Trends、利用可能であればKeyword Planner、または出典を記録した市場データ)を確認したうえで、プロパティ全体のクエリデータは補足的な根拠としてのみ使用します。URL/クエリの順位変動、カニバリゼーション、実際のSERP構成も確認します。
- CMSのコンテンツ、メタデータ、内部リンク、公開設定を変更してはいけません。ユーザーが変更を依頼した場合は、まずこの調査を完了し、別途、記事更新の範囲について合意を得ます。
ワークフロー
1. 比較可能な根拠を収集する
- 2組の期間について、Search Consoleのページ別パフォーマンスデータをエクスポートします。ページ送りで表示が打ち切られた表を手作業で確認するより、エクスポート/CSVを優先します。
- 各期間のクリック数、表示回数、CTR、平均掲載順位を保持します。フィルター、プロパティ、エクスポート日を記録します。
- 可能であれば、同じ日付範囲のGA4オーガニック検索のランディングページ別セッション数または表示回数を取得します。GA4とSearch Consoleでは計測対象が異なることに注意します。
- 直近比較と前年同期比のページエクスポートを、selection-rubric.mdの列に合わせて正規化します。両方にバンドルされたフィルターを適用し、2つの候補リストを統合して、各URLがどの比較で抽出されたかを記録します。一方の比較だけで条件を満たしたページでも、両方について根拠を十分に確認する必要があります。
python "<skill-directory>/scripts/select_rank_led_candidates.py" normalized-pages.csv --format markdown
<skill-directory>を、このSKILL.mdを含むディレクトリに置き換えます。スクリプトは候補の絞り込みに使用し、最終判断には使用しないでください。レポートで理由を説明できる場合に限り、しきい値を調整します。
2. ページを選ぶ前に原因を切り分ける
大幅に低下した各ページを、次の相互排他的なカテゴリのいずれかに分類します。
| カテゴリ | 根拠 | 対応 |
|---|---|---|
| 順位低下によるメンテナンス候補 | クリック数が大幅に低下し、表示回数はおおむね安定している一方、平均掲載順位/クエリ順位が悪化している | 調査して優先順位を付けます |
| 需要低下/陳腐化 | 表示回数とクリック数がともに低下している、またはタスク/クエリが終了している | 順位低下によるリストから除外します |
| CTR/SERP の変化 | 掲載順位はおおむね安定しているものの CTR が低下しており、SERP の機能やタイトル/スニペットの変化で説明できる | 別枠で扱い、順位低下が原因とは見なさない |
| 技術/インデックス登録の問題 | インデックス登録、canonical、レンダリング、または利用可能性に関する根拠がある | 別途エスカレーションします |
| カニバリゼーション/内部競合 | 同じクエリまたは検索意図で、別のサイト URL が伸びている | このコンテンツメンテナンスリストから除外し、統合/ターゲティングの判断に回します |
| 根拠不足 | ボリュームが少ない、または比較可能なベースラインがない | 無理にトップ 10 に含めません |
選定した URL ごとに、以前価値があり、現在低下しているクエリを少なくとも 3 つ確認します。各クエリについて、検索タイプ/国/デバイス/日付のフィルターを同一にして、3 つのビューを収集します。(a) 対象 URL のクエリ指標と掲載順位、(b) ページフィルターなしのプロパティ全体のクエリ指標、(c) 独立した需要の代理指標です。需要の根拠として扱うのは (c) です。(b) はサイト全体の可視性を把握するためだけに使います。長期的な変化を捉えるには、前年比データを使用します。同じクエリでプロパティ内の別の URL が伸びていないかを確認し、カニバリゼーションが確認された場合は、専用の除外カテゴリに分類します。クエリの構成が変わっている場合は、その旨を記載します。
コンテンツメンテナンス候補として残す前に、最低限の健全性チェックを実施します。URL 検査/インデックス登録状況、ユーザーが選択した canonical、HTTP での利用可能性、レンダリング後のページへのアクセス性を確認します。問題のあるページは、編集上の不足と診断するのではなく、技術/インデックス登録の問題に分類します。
3. Google で選定した各ページを診断する
ユーザーが Chrome または Google を指定した場合は、一般的なウェブ検索バックエンドではなく、Chrome ブラウザーを使用します。選定した URL ごとに、次の手順を実行します。
- Google で、過去に価値があったものの検索数が減少したクエリを少なくとも 3 件検索します。可能な場合は、指定された地域/デバイスのコンテキストを使用します。
- 対象 URL の表示順位または検索結果に表示されないこと、上位の競合 URL、重要な SERP 機能(AI Overview、公式結果、動画カルーセル、PAA、ニュース、フォーラムなど)を記録します。新しいタブを使用し、アカウントやサイトの設定は変更しないでください。
- 検索意図、鮮度、直接的な回答の質、タスクの完了度、事実の網羅性、一次情報の根拠、視覚・メディアによる補足、構成、信頼性のシグナルについて、対象ページと上位ページを比較します。実際のページ内容に基づいて観察結果をまとめ、確認できた事実と推測を区別します。
- 編集内容ではなく、調査すべきギャップを特定します。例:古くなった UI の手順、現在の制約の不足、検索意図との不一致、独自の根拠の不足、公式情報源が SERP を占めるようになったことなどです。
並行して作業するエージェントを利用できる場合は、各エージェントに割り当てるページを 2 件以下にします。各エージェントには、期間別指標、3 件以上のクエリ、Google の競合ページ、SERP 機能、確認されたコンテンツのギャップ、除外項目、情報源 URL を返すよう求めます。すべてのエージェントが根拠を提出してから、結果を統合してください。
4. メンテナンスレポートを作成する
report.md を作成または追記し、ユーザーが置き換えを求めない限り、以前の調査結果を保持します。次の構成にします。
- 対象範囲、日付、データソース、フィルター、制約。
- 選定方法と、順位に基づく明示的なしきい値。
- 順位に基づいて優先順位付けしたページの表(依頼された件数まで、デフォルトは 10 件):URL、直近の指標、前年比の指標、サイト全体のクエリ需要の根拠、順位の根拠、優先度、信頼度。根拠のしきい値を満たすページが少ない場合は、該当件数のみを報告し、不足の理由を説明します。
- ページごとの診断:検索数が減少したクエリを 3 件以上、現在の Google 競合ページ/SERP の観察結果、調査すべきコンテンツのギャップ。
- 除外した惜しい候補と、需要の減少、古くなった検索意図、CTR のみの損失、技術的な問題、カニバリゼーション、またはデータ不足を示す根拠。
- 技術面または編集面での判断が必要な作業を、別のフォローアップキューに記載します。
提出前に、最終的な順位ベースのリストに含まれるすべてのページについて、独立した需要の根拠が十分に安定していること、クエリ単位で順位の悪化が記録されていること、健全性チェックに合格していることを確認します。需要主導の損失で枠数を埋めてはいけません。
リソース
- selection-rubric.md:正規化スキーマ、デフォルトのしきい値、レポートのチェックリスト。
scripts/select_rank_led_candidates.py:正規化された Search Console ページエクスポートを対象とする、決定論的な一次フィルター。