手動対策とセキュリティの通知を確認する｜順位低下と切り分ける

二つのレポートと通常の順位変動を分ける

手動対策のレポートとセキュリティの問題のレポートは、同じものではありません。Googleの案内では、前者は検索のポリシーに関する問題、後者はハッキングや利用者に害を及ぼす挙動などを扱います。片方だけを見て確認を終えないようにします。

通知がない場合、流入が下がったことだけで再審査を求める手順には進みません。検索語、掲載ページ、公開変更など通常の調査へ戻ります。まず画面で観測した事実と担当者の推測を分けます。

権限と対象プロパティを確認する

どのアカウントでどのプロパティを見たかを記録します。新旧ドメインやサブドメインがある場合は、対象サイトと一致するかを確認します。担当者に権限がなく見られない状態を、問題がない状態と同じ扱いにしないようにします。

表には通知種別、対象範囲、例示URL、確認日、責任者、対応状態を残します。メール内のリンクだけで判断せず、自分で正規のSearch Consoleを開いて通知の内容を照合します。

通知に書かれた問題を対象範囲全体で調べる

通知の例示URLだけを直して終えず、同じ仕組みで作られたページや投稿を調べます。構造化データなら公開内容との一致、投稿型の問題なら投稿経路や権限など、指摘された種類に合わせて担当を分けます。

セキュリティの問題が示されている場合は、記事の書換えだけで済ませず、ホスティングや開発の担当へ渡します。公開ファイル、アクセス権、再発経路の調査が必要かを決め、証拠を消す前に適切な記録を残します。

対応表の状態は、調査中、修正中、公開確認済み、レビュー待ちなどに分けます。担当者が返信したことと、サイトの状態が変わったことを別に記録します。例示されたページが直っていても、同じ原因の新規ページが作られ続ける場合は完了にしません。再確認ではURLだけでなく、そのページを作る設定や入力経路も見て、再発を防ぐ変更が公開されているかを確かめます。

構造化データの通知を整理する例

架空の例で、一部の商品記事に本文では表示していない評価が出力されていたとします。対象の一ページだけでなく、同じ共通部品を使う記事を調べ、出力内容を確認します。修正表には問題、共通原因、対象URL群、変更、再確認結果を残します。

画面に評価を追加して数字を正当化するのではなく、根拠を確認できないデータを除きます。修正後は公開本文と出力データを再照合します。この例は対応の整理方法で、実際に通知を受けたという報告ではありません。

作業の引継ぎでは、通知の原文、対象範囲、確認済みのページ、未確認の仕組みを分けます。対応を始めた人の推測が、いつの間にか確定した原因として残らないようにします。公開作業の担当には、修正を戻した場合に同じ問題が再発する箇所も伝えます。レビュー待ちの期間に別の担当者が旧設定へ戻すことを防ぐため、変更理由と責任者を記録します。

修正の説明と再発防止をまとめる

該当レポートの案内に従い、必要な修正と確認を済ませてからレビュー手順へ進みます。提出する説明には、何が原因で、どこを直し、どう確認したかを簡潔にまとめます。処理期間や検索順位の回復時期を保証しません。

修正後も通知の状態を確認する担当を決めます。再発防止には、公開前の検査、権限の見直し、入力経路の制限など、原因に対応する変更を残します。無関係な大量改稿を同時に行うと検証しにくくなります。

通常の更新管理とは別の記録にする

確認だけなら新しいSEOサービスの契約は必要ありません。必要なのは対象プロパティへの適切な権限と、修正できる担当です。費用を考える場合は、調査、技術対応、確認、監視を分けます。

完了条件は通知がなくなったように見えることだけではなく、原因への対応を説明でき、公開状態を確認し、残る対応が担当者に渡っていることです。通常の記事更新表には概要だけ残し、詳細な調査資料は必要な担当者が見られる場所で管理します。

• Google Search Consoleの使い方｜登録・検索掲載・記事改善を順に確認する
• 技術SEOの点検ガイド｜クロール・内部リンク・修正確認
• ソフトウェア記事の構造化データを点検する｜未知の価格と評価を作らない