削除ツールで消したURLが復活する理由と恒久削除の確認手順
半年ほど前、Search Console の削除ツールで古い商品ページを消した。検索結果からは確かに消えた。ところが最近、同じページがまた出てくる。
答えから書きます。削除ツールの申請は、もともと期限つきです。 Search Console ヘルプには「A successful request lasts only about six months. After that, your information can appear on Google search results(申請が通っても効果は約6か月だけ。その後は検索結果に再び表示されることがある)」とあります。期限が切れたとき、サーバーがそのページをまだふつうに返していれば、戻ってくるのは自然な流れです。
だから、直す場所は Search Console ではありません。サーバーです。ページが 404 や 410 を返すか、noindex を付けて返すか。そのどちらかになっているかを、自分の手で確かめる必要があります。
削除ツールは「急ぎで隠す」ための道具
Google 検索セントラルの削除ページは、使い分けをこう書いています。
use the Removals tool for temporary, quick removals within a day. For permanent removal, remove or update the content, password-protect the page, or add a
noindextag, avoidingrobots.txt.
訳すと「1日以内の一時的で素早い削除には削除ツールを使う。恒久的に消すなら、コンテンツを削除または更新する、ページをパスワードで保護する、noindex タグを付ける。robots.txt は避ける」です。同じページには「Requests made in the Removals tool last for about 6 months(削除ツールでの申請は約6か月有効)」とも書かれています。
つまり、削除ツールの役目は時間かせぎです。本当の削除は、サーバー側の処置が引き受けます。
削除ツールのヘルプにも、念を押すような一文があります。サイトを移すときの用途について「This tool won't remove old content or URLs(このツールは古いコンテンツや URL を削除しない)」。そして古いページの片付けについては「like old pages return 404(古いページは 404 を返す)」と、ツールではなくステータスコードを案内しています。
恒久的に消す3つの方法と、選び方
公式の挙げる恒久対応は大きく3つです。どれを選ぶかは「そのページを今後どうしたいか」で決まります。
| したいこと | 処置 | サーバーの応答 | 向いている例 |
|---|---|---|---|
| ページ自体をなくす | 404 または 410 を返す | 404 Not Found / 410 Gone | 販売終了した商品、終わったキャンペーン |
| ページは残すが検索には出さない | noindex を付ける | 200 OK + noindex(メタタグか X-Robots-Tag ヘッダー) | 会員向け案内、印刷用ページ、社内向け資料のPDF |
| 見せる相手を限る | パスワードで保護する | ログインを求める応答 | 取引先専用の資料 |
404 と 410 は、どちらも 4xx(400番台)のステータスコードです。Google の HTTP ステータスコードの説明には「URLs that are already indexed and return a 4xx status code are removed from the index(すでにインデックスされた URL が 4xx を返すと、インデックスから削除される)」と書かれています。どちらを選ぶかで迷ったときの考え方は、末尾の関連記事にまとめています。
noindex には一つ、条件があります。noindex のページには「For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file(noindex が効くには、そのページが robots.txt でブロックされていてはならない)」という注意書きがあります。Googlebot がページを取りに来て、タグやヘッダーを読んだときにはじめて、検索結果から外れる仕組みだからです。
よくある落とし穴:「消えて見える」200
いちばん見落としやすいのは、画面上は「ページが見つかりません」と出ているのに、サーバーは 200 を返している状態です。CMS の設定やテンプレートの作りによって、こうなることがあります。
ブラウザで見ても区別はつきません。Google の説明では、200 で返ってきた内容がエラーや空のページに見える場合、Search Console は「soft 404」として扱います。人の目には消えていても、応答コードの上では「ある」と言っている。この食い違いに気づけるのは、応答コードを直接見たときだけです。
もう一つが robots.txt との組み合わせです。「念のため」と robots.txt で Disallow を書き足すと、Googlebot は noindex を読めなくなります。noindex のページも、noindex が効かない理由の一つとして「the robots.txt file is blocking the URL from Google web crawlers, so they can't see the tag(robots.txt が Google のクローラーをブロックしていて、タグを見られない)」を挙げています。消したい気持ちで重ねた設定が、かえって削除を止めてしまうわけです。詳しくは「noindexが効かない原因はrobots.txt」で扱っています。
5ステップのワークスルー:旧商品ページの場合
ここからは、具体的な場面で通してみます。想定は次のとおりです。
- 対象:
https://www.example.com/products/old-item(販売終了した商品ページ) - 状況: 半年前に削除ツールで一時削除を申請した。最近、検索結果に戻ってきた
- 方針: ページ自体をなくす(410 を返す)
- 対象 URL のバリエーションを洗い出す。 削除ツールのヘルプによれば、一時削除は http と https、www ありとなしをまとめてブロックします。ただし、同じ内容が別の URL(パラメータ付きなど)で検索結果に出る場合は、その URL ごとに申請が必要とされています。恒久対応も同じ範囲で考えます。今回なら
/products/old-item?color=redのような URL が残っていないかを、サイト内リンクやサイトマップから拾います。 - 処置を決める。 上の表に当てはめると、販売終了の商品は「ページ自体をなくす」です。代わりになる後継商品がある場合は、削除ではなく転送(リダイレクト)を検討したほうがよいこともあります。
- サーバーに実装する。 Nginx なら、たとえば次のように書けます。
noindex を選ぶ場合は、HTML の head にlocation = /products/old-item { return 410; }<meta name="robots" content="noindex">を置くか、レスポンスヘッダーにX-Robots-Tag: noindexを付けます。robots メタタグの仕様には、Nginx でadd_header X-Robots-Tag "noindex";と書く例が載っています。ヘッダーでの指定は、PDF や画像など HTML でないファイルにも使えます。 - curl で応答を確かめる。 ターミナルで次を実行します。
1行目がcurl -sI https://www.example.com/products/old-itemHTTP/1.1 410 Gone(または404 Not Found)なら、ページの削除は成立しています。noindex の場合は、1行目が200 OKで、ヘッダーにX-Robots-Tag: noindexが出ていることを見ます。メタタグで指定したならcurl -s URL | grep -i robotsで HTML 内のタグを確認します。あわせてcurl -s https://www.example.com/robots.txtで、対象のパスが Disallow されていないことも見ておきます。手順1で拾ったバリエーションも、同じように1本ずつ確かめます。 - Search Console で確かめる。 URL 検査ツールで対象 URL を調べ、「クロール済みのページを表示」を開くと、ヘルプによれば HTTP のリクエストとレスポンス、返された HTML を確認できます。なお「削除ツールでブロック」の状態はライブテストでは確かめられず、ヘルプは削除ツールの「一時的な削除」ページで見るよう案内しています。申請日を控えておけば、約6か月の期限がいつごろ来るかを見積もれます。
今回のケースでは、手順4の1行目が HTTP/1.1 200 OK でした、という結果がいちばんありがちです。そうなら原因はそこにあります。手順3に戻って 410 を返す設定を入れ、もう一度 curl で確かめます。そのあと Google が再びクロールしたときに 4xx を受け取れば、インデックスから外れていく流れになります。クロールの時期は前後することがあるので、日付を決めて URL 検査で様子を見るのが現実的です。
急ぐときは「隠す」と「消す」を同時に進める
今すぐ見えなくしたい事情があるなら、削除ツールは使ってよい道具です。公式も「1日以内の素早い削除」に使うよう案内しています。
ただし、申請して終わりにしない。申請と同じ日に、サーバー側の処置にも取りかかります。こうしておけば、約6か月の期限が切れる前に恒久対応が効いている見込みが高くなります。
順番を整理すると、こうなります。
- 当日: 削除ツールで一時削除を申請する(時間かせぎ)
- 当日〜数日: 404・410・noindex のいずれかを実装し、curl で確かめる(本対応)
- その後: URL 検査で応答とインデックスの状態を見る。期限切れ前にもう一度確認する
自己点検チェックリスト
削除ツールの申請を出したことがある URL について、次を確かめてください。一つでも「いいえ」があれば、期限切れのあとに戻ってくる可能性があります。
| 確認項目 | 確かめ方 | 「はい」の状態 |
|---|---|---|
| サーバーが 404 か 410 を返している、または noindex を返している | curl -sI の1行目とヘッダー | 404 / 410、または 200 + X-Robots-Tag: noindex(またはメタタグ) |
| 「見つかりません」画面が 200 で返っていない | curl -sI の1行目 | 200 ではない(noindex 方式を除く) |
| 対象パスが robots.txt で Disallow されていない | robots.txt を開いて該当行を探す | 該当する Disallow がない |
| バリエーション URL も同じ応答になっている | パラメータ付きの URL なども1本ずつ curl | すべて同じ処置になっている |
| 申請の期限を見積もれている | 申請日の記録と削除ツールの「一時的な削除」ページ | 期限切れ前に再確認する日を決めている |
二つめの項目は、さきほどのワークスルーで見た「消えて見える 200」そのものです。ここが「はい」になるまでは、削除ツールの申請を何度出しても根本は直りません。
404 と 410 の書き分けや Apache での設定は「404と410はどちらを返す?」に、古い記事をまとめて片付けるときの判断は「古い記事は削除か更新か」にまとめています。
出典
