消したいURLが検索結果に残るときの手順｜削除リクエストで消えるものと、統合しないと消えないもの

サイトを運用していると、消したいURLが出てきます。同じ内容のページが二重にできてしまった、テスト用に作ったページが検索に出てしまった、リニューアルで使わなくなったページが残っている。こうしたとき、まずSearch Console（サーチコンソール）の削除リクエストを探す方が多いはずです。

先に結論を書きます。Search Consoleの削除ツールは「検索結果から一時的に隠す」機能であって、URLを消す機能ではありません。約6か月で元に戻ります。隠れている間にサイト側を直さなければ、期限が来たときに同じURLがまた検索結果に並びます。

つまり、正しい順番はこうです。

1. サイト側で「そのURLの正体」を決める（統合するのか、消すのか、残すが検索に出さないのか）
2. その決定に合わせて 301リダイレクト・404・noindex のどれかを実装する
3. そのURLを指し示している発信元（サイトマップ・内部リンク）を止める
4. 急いで隠したいときだけ、時間稼ぎとして削除ツールを使う

削除ツールは4番目です。1〜3を飛ばして4だけをやると、半年後に同じ作業をやり直すことになります。

弊社は名古屋でホームページの制作・運用を行っており、自社ブログ約170本の運用と、クライアントサイトのリニューアル・サーバー移転を実際に手掛けています。その実務で使っている判断基準と検証手順を書きます。

消したいURLは、まず4種類に分ける

対応が変わるので、最初に分類します。

状態	例	正しい対応
中身が生きていて、同じ内容が別URLにもある	重複記事・末尾に連番が付いたコピー	301で統合先へ
ページごと不要	削除した記事・使わなくなったテストページ	404（またはページ削除）
ページは必要だが検索に出したくない	サンクスページ・会員向けページ・管理用ドメイン	noindex
実は消えていない／消す必要がない	移行中に旧URLが残って見えているだけ	何もしない

いちばん多い間違いが、1番目に対して削除リクエストを使ってしまうケースです。中身が生きているページは、隠しても評価が消えるだけで、統合先には何も渡りません。

重複URLは、301で統合する

弊社ブログで実際にあった例です。同一タイトル・同一H1の記事が1組見つかりました。片方はスラッグ（URLの末尾）に連番の-2が付いていました。これはWordPressがURLの衝突時に自動で付ける番号で、後から誤って作られたコピーである証拠です。

判断材料として、次を確認しました。

• 本文2,311字・見出し18個が完全に一致（差分は改行タグと区切り線の装飾のみ）
• 直近90日の実績が 0表示・0クリック
• そのページだけが持っている見出しが 0個

固有の価値がなく、流入もない。統合して失うものが無いと判断できたので、301で正規のURLへ向けました。

逆に、統合しない判断も同じくらい重要です。同じテーマの記事が5本あり「食い合っている（カニバリゼーション）から統合すべき」と考えていたクラスタを実測したところ、受注に近い検索クエリはすべて1本が単独で獲得しており、残りの記事にはクエリが1つも紐づいていませんでした。競合していたのではなく、単に評価されていなかっただけです。この場合は統合しても失うクリックも得る評価もゼロなので、触らないのが正解になります。「重複しているように見える」で動かず、クエリ単位の実績を見てから決めてください。

切り替える前に、巻き込み事故を検証する

リダイレクトの怖いところは、意図した1件だけでなく、似た形のURLをまとめて巻き込むことです。特に日本語を含むURLはサーバー上での扱いが直感と違い、設定した直後に関係ないページが404になる事故が起こり得ます。

そこで、本番に入れる前に次の順で確認します。

1. クエリ付きのときだけ発動する一時ルールを入れて実測する。たとえば?htaccesstest=1が付いたアクセスにだけ反応する検証用ルールを置けば、通常のアクセスは200のまま変わりません。実トラフィックに一切影響を与えずに「本当にマッチするか」だけを確かめられます
2. サイトマップに載っている全URLに、書いたパターンをオフラインで照合する。弊社の事例では231件を全件走査し、マッチするのが対象1件だけであることを確認しました
3. 本番ルールに差し替え、検証用ルールを削除する
4. 切り替え後、サイトマップ全URLを再度実測する。結果は「200が230件・301が1件（対象のみ）」で、巻き込みゼロを数字で確認できました
5. 設定ファイルのバックアップは、公開ディレクトリの中と外の2か所に置く

5番目は、デプロイ時に公開ディレクトリごと上書きされてリダイレクト設定が消える事故への備えです。リダイレクトは「入れて終わり」ではなく、デプロイのたびに生き残っているかを確認する対象だと考えてください。

301を入れても、まだ消えないことがある

ここが見落とされやすい部分です。301を入れたあとも、そのURLが検索結果に残り続ける状態が起こり得ます。原因は、サイト自身が今もそのURLを指し示しているからです。

先ほどの統合事例では、リダイレクトは正しく効いていたのに、元記事のステータスが「公開」のままでした。その結果、

• サイトマップに載り続ける（自分で「このURLがあります」と申告しながら、アクセスすると転送する矛盾した状態）
• 統合先の関連記事欄からリンクが残る（内部リンクで自ら301を踏ませ続ける）

という状態でした。対応は削除ではなく 下書きに戻すだけです。これで両方が同時に解決します。実測では、サイトマップの件数が234→233に減り、消えたのは対象1件のみ。関連記事欄からも該当リンクが0件になり、代わりに別の記事が自動で入りました。

削除ではなく下書き化を選ぶ理由は、元に戻せるからです。本文はそのまま残るので、判断を誤っていた場合は公開に戻すだけで復元できます。実装を伴う変更ほど、可逆な手段を先に選んでください。

静的サイトは、記事を消してもURLが生きていることがある

WordPressの記事を静的HTMLとして書き出す構成（ヘッドレス構成）では、注意点が1つ増えます。CMS側で記事を削除しても、以前に書き出されたHTMLファイルがサーバーに残り続けるため、URLを直接叩くとページが表示されてしまいます。「消したはずのページが検索から消えない」と感じたら、まず実ファイルの有無を疑ってください。

弊社が運用する約160ページの医療系サイトでは、この取り残されたファイルを自動で掃除する処理を追加しました。実装時に守った条件は3つです。

• 「ビルド結果に無いものを全部消す」方式にしない。この判定だと、手動で配置したリダイレクト設定ファイルまで削除対象に入ります。拡張子を.htmlに限定することで構造的に回避しました
• 画像や管理用ディレクトリは除外指定し、シンボリックリンクは辿らない
• 実行前に、削除対象が0件のリハーサルだけで安全と判断しない

3つ目が実務上いちばん大事です。「対象0件」という結果は、安全なのか、そもそも検出できていないのかを区別できません。そこで意図的に不要ファイルを1つ作って再実行し、「その1件だけを検出する」ことを確認してから本適用しました。削除を伴う自動処理では、誤爆しないことと同時にちゃんと見つけられることを証明してから動かしてください。

robots.txtで塞ぐのは、消す手段ではない

検索から消したいときにrobots.txtでDisallowする対処が選ばれがちですが、これは逆効果になる場合があります。robots.txtは「読むな」という指示なので、そのページに書いたnoindexも読まれません。結果として、URLだけが検索結果に残る状態になり得ます。

遮断は範囲を絞る必要があります。とくに注意したいのが、記事のOGP画像（SNSや検索結果に出るサムネイル画像）を管理用ドメインから配信している場合です。そのドメインを全面遮断すると画像を取得できなくなり、サムネイルが一斉に機能しなくなります。弊社の計測では、この条件に該当した記事168本すべてでサムネイルが表示されない状態になることを実測しました。遮断する前に、そのドメインから何を配信しているかを必ず洗い出してください。

管理用ドメインを塞ぐときは、次の形が安全です。

• 原則はDisallow: /で全面遮断
• ただし公開動線に載っているページのパスだけAllowを開ける。そこにnoindexを置いて読ませることで、URLだけが残る事態を防ぐ
• WordPressの設定と、サーバーに置く物理ファイルの二重で持つ

「消えていない」ように見えて、実は問題ないケース

最後に、対処が不要なパターンです。サイトのURL構成を変更した直後は、同じ記事が旧URLと新URLの両方でSearch Consoleに表示されます。旧URL側のグラフだけを見ると、ある日を境にゼロに落ちたように見えます。

弊社サイトでも、URL構成の変更直後に主力記事の評価が3つのURLに分散していました。実挙動を確認すると転送はすべて正常で、サイト全体の表示回数はむしろ増えていました。ページ単位のグラフだけで判断せず、同じテーマのクエリ全体とサイト全体の3層で見てください。

このとき最もやってはいけないのが、焦って追加のリダイレクトや正規URL指定を入れ、短期間で反転させることです。判定は最低でも2〜4週間空けてから行ってください。

よくある質問

Q. 削除リクエストを出せば、そのURLは完全に消えますか

消えません。検索結果から一時的に隠れるだけで、約6か月で戻ります。自分が所有権を持つサイトにしか使えず、隠れている間にサイト側を直すのが本来の使い方です。

Q. 重複ページは削除とリダイレクトのどちらがいいですか

中身が生きていて統合したい先があるなら301です。削除して404にすると、そのページが持っていた評価はどこにも渡りません。逆に、統合先が無く実績も無いページは404で構いません。

Q. 301を入れたのに検索結果が変わりません

サイトマップと内部リンクを確認してください。自分のサイトが旧URLを指し示し続けていると、切り替えが遅れます。反映には数週間かかるため、設定から数日で判断しないことも重要です。

Q. テスト環境が検索に出てしまいました。急いで消したいです

まず削除ツールで隠して時間を稼ぎ、その間に公開ディレクトリから退避するかnoindexを実装してください。robots.txtで塞ぐだけだと、noindexが読まれずURLが残ることがあります。

Q. 消した記事のURLは404のままでいいですか

構いません。ただし内部リンクとサイトマップからは外してください。似た内容の記事が別にある場合のみ、そちらへ301する価値があります。

まとめ

消したいURLが検索結果に残るとき、削除リクエストは最初の手段ではありません。

1. そのURLを 統合・削除・非表示 のどれにするか決める
2. 301・404・noindex のうち対応する実装を入れる。切り替える前に、影響範囲を全URL照合と実測で確認する
3. サイトマップと内部リンクから、そのURLへの指し示しを止める
4. 急ぎのときだけ、時間稼ぎとして削除ツールを使う

判断の中心にあるのは「そのURLが今どれだけ評価されているか」です。実績を確認せずに動かすと、生きているページを隠して損をするか、無価値なページの整理に時間を使うことになります。数字を見てから決めてください。

URLの整理やリニューアルに伴うリダイレクト設計でお困りの場合は、現状の実測からご相談を承っています。