Search Consoleを確認したら、自分たちでは作った覚えのないURLが大量に見つかった。会社のサービスとは関係のない文字列がURLに付いている。公開している記事は数百本しかないのに、それを大きく上回る数のURLが検出されている。
こうした状況で確認したいのは、被リンクの数だけではありません。「第三者が勝手に作ったURLに対して、自分たちのサイトがどのような応答を返しているのか」です。
たとえば、存在しないページにもかかわらず正常なページとして表示していたり、用途のないパラメータを付けただけで別のURLとしてアクセスできたりするなら、サイト側のURLの扱いを見直す余地があります。
そこで考えたいのが、存在しないページには404を返し、必要なパラメータだけを許可し、恒久的に廃止する不要なパラメータURLには410 Goneを返すという設計です。
ただし、最初に大切な前提があります。これは、外部サイトがスパムリンクを貼ること自体を止める方法ではありません。外部でどのようなURLを作られても、自分たちのサイトがそれを無条件に正常なページとして受け入れないための対策です。
また、Googleは、429を除く4xxのステータスコードを基本的に同じように扱います。404でも410でも、その応答をGoogleが取得・処理すればインデックスからの除外につながります。「410なら必ず404より早く消える」「410を使うだけで順位が上がる」という話ではありません。（出典：Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」）
この記事で扱うのは、410という数字を使った裏技ではなく、サイトが公開するURLの範囲を決めるための実務です。
存在しないページを存在するように見せない。必要なパラメータを壊さない。不要なURLを公開し続けない。
この三つを同時に成立させることが、今回の対策の中心になります。
「スパムリンク」と「スパムページ」は、まず分けて考える
外部からリンクを貼られただけなのか、サイト内に問題があるのか
「スパムリンクを貼られた」と聞くと、すぐにリンク否認やドメイン評価の話になりがちです。しかし、今回のような問題では、最初に現象を分けて考える必要があります。
一つ目は、外部の不審なサイトから、自社の正常なページにリンクされているだけのケースです。
たとえば、自社の会社概要ページに対して、無関係な海外サイトからリンクが貼られている状態です。この場合、自社サイトの会社概要ページが正常なのであれば、そのページを404や410にする理由はありません。リンクされたからといって、正常なページまで削除してしまえば、正規の訪問者も検索エンジンもそのページを利用できなくなります。
なお、Googleは、多くのサイトではリンク否認ツールを使う必要はないと説明しています。大量の不自然なリンクが存在し、それによって手動による対策を受けた、または受ける可能性が高い場合などに慎重に検討するものです。「知らない被リンクが増えた」という理由だけで、何でも否認するものではありません。（出典：Search Consoleヘルプ「サイトへのリンクを否認する」）
二つ目は、第三者が勝手に作ったパラメータ付きURLに、自社サイトが応答しているケースです。
たとえば、本来の記事URLが次のようなものだったとします。
https://example.com/blog/seo-guide/ところが、外部から次のようなURLでリンクされていたとします。
https://example.com/blog/seo-guide/?spam_id=abc123このURLでアクセスすると、元の記事と同じ内容が表示される場合があります。この状態は、必ずしも「不正な記事が新しく作成された」という意味ではありません。サイトが、そのパラメータを無視して元の記事を返しているだけかもしれません。
一方で、パラメータの内容がタイトルや見出しに反映されたり、検索結果のようなページが生成されたりするのであれば、対処すべき内容は変わります。単なるURLの重複なのか、意図しないコンテンツの生成なのかを確認する必要があります。
三つ目は、サイトが改ざんされ、実際に不正なページやコードが追加されているケースです。
Googleは、ハッキングされたコンテンツの例として、不正なコードの挿入や新しいページの追加を挙げています。この場合、必要なのはURLの整理だけではありません。侵入経路の修正、不正ファイルやデータの除去、再発防止まで含めた対応が必要です。（出典：Google 検索セントラル「Google ウェブ検索のスパムに関するポリシー」）
外部の不審なリンク、不要なパラメータURL、不正に追加されたページ。この三つは、同じ問題として処理しません。
今回の404・410による制御は、主に「サイト側が不要なURLを正常なページとして返してしまう問題」に対する施策です。改ざんがある場合は、その修復と並行して進めることになります。
404と410 Goneは、ページに貼るタグではない
404や410を「設定する」「付ける」と表現することはありますが、実際にはHTMLに貼るSEO用のタグではありません。サーバーがリクエストに対して返す、HTTPステータスコードです。
ブラウザでページを開くと、通常は本文や画像に目が向きます。しかし、検索エンジンに対しては、ページの内容だけでなく、そのページがどのような状態なのかを応答として伝えています。
正常にページを返す場合の代表的な応答が200 OKです。存在しないページなら404 Not Found。恒久的に利用できなくなったことを伝える場合には410 Goneを使います。（出典：Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」）
ここで重要なのは、画面に表示される文章と、実際のHTTPステータスが一致していることです。
画面に「このページは存在しません」と書いていても、HTTPステータスが200であれば、実装としては正常な応答を返しています。反対に、わかりやすい案内やサイト内へのリンクを表示しながら、正しく404を返すこともできます。
404は「見つからない」、410は「恒久的に利用できなくなった」
HTTPの仕様では、404は対象のリソースが見つからないことなどを表し、それが一時的なのか恒久的なのかまでは示しません。410は、そのリソースが利用できなくなり、その状態が恒久的である可能性が高いことを表します。恒久的かどうかわからない場合は404を使うべきだとされています。（出典：RFC 9110「HTTP Semantics」）
この違いを実務に置き換えると、次のように考えられます。
自分たちが一度も作っていないURL、存在しない記事番号、実在しないページ番号などには、まず404が自然です。一方、以前は公開・配信していたものの、今後は提供しないと決めたページやURL群には410を使う意味があります。
そのため、「許可したパラメータ以外はすべて410にする」というルールを採用するなら、それを単なるスパム判定ではなく、不要なパラメータURL群の誤配信をやめ、恒久的に廃止するためのルールとして設計する必要があります。
単に知らないパラメータが付いているというだけで、必ず410でなければならないわけではありません。未定義のURLとして404を返す設計も成立します。
大切なのは、404と410のどちらがSEOに強いかではなく、そのURLをどのようなものとして扱うかです。
「パラメータがないURL＝正規URL」でもない
もう一つ、言葉を整理しておきたい点があります。
正規URLとは、必ずしもパラメータが付いていないURLのことではありません。パラメータによって商品、記事、言語などを識別するサイトでは、パラメータ付きURLが正式なページのURLである場合もあります。
たとえば、WordPressには投稿を指定するp、固定ページを指定するpage_id、検索語を指定するsなどの仕組みがあります。パラメータを一律に不要とみなすと、こうした正規の機能まで壊す可能性があります。（出典：WordPress Developer Resources「WP_Query」）
したがって、「存在しない正規URLには404を返す」という考え方は、より正確には、サイトの正規のルーティングや公開コンテンツに対応しないURLには、正常なページを返さないという意味で捉えるとよいでしょう。
最初に直したいのは、「何を付けても正常なページが出る」状態
ここからは、説明用の架空のサイトを例にします。実際の運用成果や特定サイトの実測事例ではありません。
あるサイトに、次のサービスページがあるとします。
https://example.com/service/seo/このページが200を返し、正しいサービス内容を表示するのは問題ありません。
ところが、次のように存在しないパスでアクセスしても、同じサービスページやトップページが表示されるとしたらどうでしょうか。
https://example.com/service/seo/not-a-real-page/サイト側は、そのページを作っていないにもかかわらず、正常な応答として受け入れていることになります。
存在しないURLでエラー画面を表示しながら200を返すような状態は、soft 404の問題になります。Googleも、実際に存在しないページについては、適切な404や410を返すよう案内しています。（出典：Google 検索セントラル「Google 検索のクロールエラーのトラブルシューティング」）
この場合、まず取り組むべきなのは、パラメータのブラックリストを増やすことではありません。存在しないパスに対して、正しい404を返すことです。
正常なパラメータを付けても、存在しないページは存在しない
たとえば、次のURLにアクセスしたとします。
https://example.com/not-a-real-page/?utm_source=newsletterutm_sourceが許可された計測パラメータであっても、それによって存在しないページが存在するようになるわけではありません。
今回の設計では、ページ自体が存在せず、適切な移転先もなければ404を返します。
この考え方は意外に重要です。「許可されたパラメータが付いていれば通す」という判定だけを先に作ってしまうと、存在しないURLまで正常な処理に流してしまうことがあるからです。
許可リストは、存在しないページを有効化するためのものではありません。正しく存在するページに対して、どの追加情報を受け入れるかを定めるものです。
何でもトップページにリダイレクトしない
存在しないURLを、すべてトップページに301リダイレクトする方法も避けたいところです。
記事が別のURLへ移転したのであれば、その記事の新URLへ転送する意味があります。しかし、存在しないURLや無関係なスパムURLを、何でもトップページに送ればよいわけではありません。
Googleの案内でも、明確な移転先や代替ページがある場合は301を使い、ページがなく適切な代替先もない場合は404または410を返す、という区別がされています。（出典：Google 検索セントラル「Google 検索のクロールエラーのトラブルシューティング」）
「被リンクが付いているから、とりあえずトップページに転送しておこう」という発想ではなく、そのURLを訪れた人に対して、内容として適切な移転先があるかどうかで判断することが大切です。
存在しないページは、存在しないと正しく伝える。それ自体が必要な仕事です。
パラメータ制御は、「怪しい言葉探し」より「許可する仕様づくり」
不要なパラメータを見つけるたびに、禁止リストへ追加する運用を考えるかもしれません。
たとえば、見覚えのない名前が付いたパラメータを一つ禁止する。次に別の名前が見つかったら、それも禁止する。この方法は、すでに確認できている特定の問題を止めるには使えますが、サイトが受け入れる入力の範囲は明確になりません。
そこで役立つのが、許可リスト方式です。
許可リスト方式とは、何が怪しいかを延々と探すのではなく、そのサイトで必要な入力は何かを先に定義する方法です。セキュリティの入力検証でも、OWASPは、許可する値や形式を定義する方法を重視しています。（出典：OWASP「Input Validation Cheat Sheet」）
ただし、入力検証に許可リストを使うことと、不許可の入力に対して410を返すことは別の判断です。前者は入力の扱い、後者はHTTP応答の意味に関わります。この二つは分けて考えます。
許可するのは、パラメータの名前だけではない
たとえば、ブログの一覧ページで、次のパラメータが必要だったとします。
page
category
sortここで「この三つの名前なら何でも許可する」と決めるだけでは、まだ仕様として不十分です。
pageにはどのような値が入るのか。categoryには実在するカテゴリだけを指定できるのか。sortには何種類の並び順があるのか。複数を組み合わせて使うことができるのか。こうした条件まで含めて整理します。
たとえば、この架空サイトでは、次のようなルールを設計できます。
page：実在するページ番号
category：公開中のカテゴリ識別子
sort：newest または oldestこれはGoogleが定めた共通ルールではなく、そのサイトの機能に合わせた設計例です。
入力の形式が正しいかだけでなく、そのサイトの文脈で意味があるかまで確認する。この二段階を持つことが、URLの無制限な派生を抑えるうえで役立ちます。
「許可されたものが一つあれば通す」ではない
許可リストの実装で特に注意したいのが、複数のパラメータが混ざった場合です。
https://example.com/blog/seo-guide/?utm_source=newsletter&spam_id=abc123このURLには、許可された計測パラメータと、許可されていないパラメータが混在しています。
utm_sourceが存在するから問題ない、と判定してはいけません。許可リスト方式で厳密に制御するなら、リクエストに含まれているパラメータ全体を調べます。
このサイトでspam_id付きURLを恒久廃止する方針なら、そのパラメータを含むリクエスト全体に410を返す、と決めます。未定義のURLとして扱う方針なら404です。
その一方で、次のURLは引き続き正常に表示できる必要があります。
https://example.com/blog/seo-guide/https://example.com/blog/seo-guide/?utm_source=newsletterここで拒否する対象は、記事そのものではありません。サイトの仕様に合わないURLの組み合わせです。
未知のパラメータを無視して200を返す設計も、直ちに間違いではない
ここは、過剰な対策を避けるために押さえておきたい点です。
未知のパラメータを無視して、元のページを200で返すこと自体が、必ずしもSEOの失敗とは限りません。広告や外部サービスとの互換性を保つために、追加パラメータを受け入れる必要がある場合もあります。実際、Google広告の資料でも、URLパラメータを許可しないサイトで自動タグ設定によるエラーが起こることが説明されています。（出典：Google 広告ヘルプ「自動タグ設定について」）
したがって、厳格な許可リストを導入するかどうかは、そのサイトで実際に起きている問題と、必要な機能を比較して決めるべきです。
不要なURLが大量に派生している。パラメータによって意図しない内容が生成される。特定の不要なURL群を恒久的に廃止したい。こうした目的が明確なときに、その範囲へ制御を入れていくと考えるとよいでしょう。
広告・メルマガ・計測のパラメータを壊さない
パラメータ制御で最も避けたいのは、SEO対策のつもりで、広告や問い合わせの導線を壊してしまうことです。
自然検索で使われるURLだけを見て許可リストを作ると、広告クリック時やメルマガ経由でのみ付くパラメータを見落とします。すると、通常のアクセスでは問題がないのに、広告をクリックした人だけ410ページに着地する、といった事故が起こり得ます。
パラメータの棚卸しには、SEO担当者だけでなく、広告運用、アクセス解析、メール配信、サイト開発の担当者も関わるべきです。
UTMパラメータを「知らない文字列」として拒否しない
Google Analyticsでキャンペーンを識別するためには、utm_source、utm_medium、utm_campaignなどのパラメータが使われます。ほかにもutm_id、utm_term、utm_content、utm_source_platformなどがあります。（出典：アナリティクス ヘルプ「URL 生成ツール: カスタム URL でキャンペーン データを収集する」）
たとえば、次のURLはメルマガからの流入を識別するために使う、正規のURLである可能性があります。
https://example.com/service/seo/?utm_source=newsletter&utm_medium=email&utm_campaign=autumnこのようなURLを、パラメータが付いているという理由だけで拒否してはいけません。
ただし、インターネット上で見つけたUTM一覧をそのまま許可すれば、すべての問題が解決するわけでもありません。自社で使っている配信ツールや、実際の運用ルールを確認する必要があります。
「使っていると思う」ではなく、「どの施策で、どのURLに、何が付くのか」まで確認しておくと、実装後の事故を減らせます。
Google広告のクリック識別子も確認する
Google広告の自動タグ設定では、広告クリック先のURLにgclidが付くことがあります。Googleは、リダイレクトがある場合にも、コンバージョンを計測するためにGCLIDを最終的なランディングページへ渡すことが重要だと説明しています。（出典：Google 広告ヘルプ「自動タグ設定について」）
また、広告計測に関係するパラメータとして、gbraidやwbraidもあります。gclidだけを許可すればすべての広告流入に対応できる、とは限りません。（出典：アナリティクス ヘルプ「iOS 14 以降のキャンペーン測定に関する更新」）
これらの値は、人間が読んで意味を理解できる文章とは限りません。文字列が長い、英数字が混ざっている、意味がわからないといった見た目だけで、不正と判断しないようにします。
値の形式を検証する場合も、思いつきで短い文字数制限を設けるのではなく、利用するサービスの仕様に合わせる必要があります。
別ドメインへの移動では、_glも確認する
たとえば、サービスサイトと予約サイト、ブランドサイトと購入サイトが別のドメインになっている場合です。
Google Analyticsのクロスドメイン測定では、_glというパラメータが使われます。Googleの公式資料でも、リダイレクトやサイト側のパラメータ非対応によって_glが失われると、測定に問題が起こり得ることが説明されています。（出典：アナリティクス ヘルプ「クロスドメイン測定を設定する」）
「記事ページは表示できるから大丈夫」と考えていても、購入直前や予約直前のドメイン移動で計測が切れてしまうかもしれません。
このため、公開ページ単体ではなく、広告クリックから問い合わせ、予約、購入までの経路を通して確認する必要があります。
許可リストは、一度作って終わりではない
広告媒体、配信ツール、予約システム、分析ツールが増えれば、必要なパラメータも変わります。
そのため、許可リストには更新手順が必要です。新しいツールを導入するとき、広告の計測方式を変えるとき、外部サイトと連携するときに、パラメータの確認を行う運用にしておきます。
ログを数日見ただけでは、月に一度しか送らないメルマガや、季節限定のキャンペーンで使うパラメータを把握できない可能性もあります。アクセスログと、運用担当者が管理する仕様の両方を確認することをおすすめします。
SEOのために、正規の見込み客を410ページへ送ってしまっては本末転倒です。
サイト全体の一括ルールではなく、ページの役割ごとに設計する
記事ページと検索ページでは、必要なパラメータが違う
ブログ記事の詳細ページ、記事の一覧ページ、サイト内検索、商品一覧、商品詳細、会員ページ。これらは、それぞれ役割が異なります。
したがって、サイト全体で一つの許可リストを共有するより、ページの種類ごとに必要なパラメータを整理した方が、仕様が明確になる場合があります。
たとえば、今回の架空サイトでは、記事の詳細ページには計測用パラメータだけを許可し、記事一覧ページでは計測用パラメータに加えてpageやcategoryを許可する、と設計できます。
サイト内検索では検索語を受け付ける必要がありますが、それを会社概要ページでも意味のある入力として扱う必要はありません。
「このパラメータはサイト内で使っている」だけではなく、どのページで、どの目的に使っているのかまで定義すると、不要な組み合わせを減らせます。
存在しないページ番号を200で返さない
たとえば、記事一覧が5ページまでしか存在しないのに、次のようなURLでも正常なページを表示しているとします。
https://example.com/blog/?page=999999このURLに対応する一覧が存在しないのであれば、元の1ページ目を返したり、空の一覧を無制限に200で返したりするのではなく、存在しないページとして扱う設計を考えます。
Googleは、ファセットナビゲーションのガイドで、結果が存在しないフィルタの組み合わせや存在しないページネーションURLなどに404を返すことを案内しています。（出典：Google「ファセット ナビゲーション URL のクロール管理」）
ここでも、410にこだわる必要はありません。存在しないページ番号は、まず404で扱うべき対象です。
一方、商品が一時的に欠品しているだけのカテゴリや、引き続きユーザーに価値を提供するページは別です。「今は一覧が少ない」「今は商品がない」というだけで、すべてを永久廃止と判断しないようにします。
値・重複・組み合わせまで確認する
パラメータの名前が許可されていても、値や組み合わせが不正な場合があります。
たとえば、ページ番号に文章が入っている、同じキーが複数回指定されている、想定していない形式で値が渡される、といったケースです。
実装時には、重複キーを許可するか、複数選択をどの形式で扱うか、空の値を許可するか、値の順番に意味があるかなどを決めておきます。
形式上壊れているリクエストには400、実在しないコンテンツや組み合わせには404、恒久廃止したURLには410というように、理由に応じて分ける設計が考えられます。何でも410に変換する必要はありません。
入力の構文だけでなく、業務上の意味も検証するという考え方は、OWASPの入力検証ガイドでも示されています。（出典：OWASP「Input Validation Cheat Sheet」）
許可されたパラメータの値を、無条件に公開コンテンツへ使わない
許可リストがあれば、外部からの不審なURLが一切作れなくなるわけではありません。
たとえば、utm_sourceを許可していれば、第三者もその名前を使ったURLを作れます。そこで重要になるのが、計測用パラメータを、記事タイトルや本文を生成する材料として扱わないことです。
今回の設計では、UTMは流入元を識別する情報として処理し、コンテンツの内容を決める入力とは分けます。
検索語のように画面へ表示する必要がある値については、検索ページとしての公開方針を別に決めます。
パラメータ名の許可は、その値の内容を信用するという意味ではありません。
URLの入口を整理することと、受け取った値を安全かつ適切に使うことは、別々に必要です。
404・410・canonical・noindex・robots.txtを使い分ける
このテーマで混乱しやすいのが、異なる目的の仕組みを、すべて「インデックス対策」としてまとめてしまうことです。
404、410、canonical、noindex、robots.txtは、それぞれ役割が違います。
正常な重複URLにはcanonicalを検討する
計測パラメータが付いていても、表示する記事の内容が同じであれば、正規URLを示すことができます。
たとえば、次の二つが実質的に同じ記事を表示する場合です。
https://example.com/blog/seo-guide/https://example.com/blog/seo-guide/?utm_source=newsletterこのとき、パラメータ付きURLから、記事の代表となるURLへcanonicalを向ける設計が考えられます。
Googleは、canonicalを、重複または非常に類似したページの正規URLを示す強いシグナルとして説明しています。ただし、これは削除命令ではありません。また、別の商品や別の言語など、内容が異なるページを何でも一つへまとめるための仕組みでもありません。（出典：Google 検索セントラル「rel="canonical" などを利用して正規ページを指定する方法」）
使い分けとしては、ユーザーには正常に使ってもらいたい重複URLは正規化し、そもそも提供しないURLは適切な4xxで応答すると考えると整理しやすくなります。
ページは必要だが検索に出したくないならnoindex
サイト内検索など、ユーザーには必要でも、検索結果への掲載を望まないページがあります。
こうしたページを引き続き提供するのであれば、200で表示しながらnoindexを指定する選択肢があります。noindexは、Googleがページをクロールしてその指定を読み取ることで、検索結果から除外するための仕組みです。（出典：Google 検索セントラル「noindex を使用して検索インデックス登録をブロックする」）
一方、実在しないページや恒久廃止したURLを、わざわざ200で作り直してnoindexを付ける必要はありません。そのURLの状態に応じて、404や410を返す方が意味が明確です。
また、noindexは閲覧制限ではありません。秘密にすべき情報や会員限定の情報を保護する場合は、検索表示の制御とは別に、適切なアクセス制御が必要です。
robots.txtは、検索結果から消すための削除命令ではない
robots.txtは、主にクローラーのアクセスを制御するものです。
Googleは、robots.txtでクロールを禁止したURLでも、外部からリンクされている場合などには、URLが検索結果へ表示される可能性があると説明しています。つまり、クロール禁止とインデックスからの除外は同じではありません。（出典：Google 検索セントラル「robots.txt の概要とガイド」）
ここで、すでにインデックスされている不要なURLを410に変更したとします。
しかし、同時にrobots.txtでそのURLをブロックしていると、Googleは新しい410の応答を確認できません。noindexの場合も同様で、クロールがブロックされていると、その指定を読み取れません。（出典：Google 検索セントラル「noindex を使用して検索インデックス登録をブロックする」）
そのため、既存の不要URLをインデックスから外したい場面では、Googleが404・410やnoindexを確認できる状態かどうかも、セットで確認します。
無限に増えるURLのクロール抑制は、別の目的として考える
一方、フィルタや並び替えによって非常に多くのURLが発生するサイトでは、クロールの制御も重要です。Googleも、検索結果に出す必要のないファセットURLについて、robots.txtによるクロール制御などを案内しています。（出典：Google「ファセット ナビゲーション URL のクロール管理」）
したがって、「robots.txtは使わない方がよい」という話ではありません。
すでに検索結果に出ているURLを除外したいのか。大量のURLへのクロールを抑えたいのか。正常な重複URLを正規化したいのか。この目的を分けて、それぞれの手段を選ぶことが大切です。
実装は「URLの判定順序」と「キャッシュ」まで含めて考える
先に設計するべきなのは、数行の設定コードではない
「許可したパラメータ以外は410にする」という条件だけを見ると、サーバー設定へ数行追加すれば終わりそうに見えます。
しかし、実際には、正規のページ判定、CMSのルーティング、広告計測、管理画面、外部サービスからの通知、キャッシュなどが関係します。
そのため、サイト構成を確認せずに共通の設定をそのまま貼り付けるのではなく、まず処理の順序を決める必要があります。
今回の設計を概念的な処理フローにすると、次のようになります。これは実行用コードではなく、開発担当者と共有するための考え方です。
公開HTMLページへのアクセスかを確認する
↓
URLとクエリを安全に解析する
↓
正規の経路、コンテンツ、移転・廃止履歴を確認する
↓
明示的に恒久廃止したURLなら410
↓
存在せず、適切な移転先もないURLなら404
↓
そのページで許可するパラメータ・値・組み合わせを確認する
↓
恒久廃止したパラメータURL群に該当するなら410
↓
その他の未定義URLや不正な入力は、仕様に応じて404や400
↓
適切な移転先があるURLは、定義済みの移転処理
↓
正常なページを表示し、必要な正規化・計測を行うここでいう「正規の経路の確認」は、単純にパラメータを全部取り除いてアクセスしてみることではありません。コンテンツの識別にパラメータが必要なシステムでは、その仕様を理解したうえで判定します。
また、判定の順序は利用するシステムによって調整が必要です。大切なのは、存在しないページが正常な処理へ紛れ込まないことと、正規の機能をスパム対策の条件で壊さないことです。
管理画面や外部連携に、公開ページ向けのルールをそのまま適用しない
管理画面、プレビュー、認証、決済結果の通知、外部サービスからのコールバックなどは、公開記事とは役割が異なります。
公開ページのSEO対策として作った許可リストを、すべてのリクエストへ無条件に適用すると、こうした機能に必要な入力まで拒否してしまう可能性があります。
だからといって、それらを無検証で通してよいという意味ではありません。公開HTML向けのSEOルールとは分けて、その機能に必要な認証や入力検証を行う、という意味です。
「SEO対策の対象外」と「セキュリティ対策の対象外」を混同しないようにします。
キャッシュによって、正常なURLまで410になる事故を防ぐ
パラメータ制御で見落としやすいのが、CDNやサーバーのキャッシュです。
キャッシュは、どのリクエストを同じものとして扱うかを、キャッシュキーで判断します。たとえばCloudflareでは、クエリ文字列をキャッシュキーへ含めるか、特定のパラメータを除外するかなどを設定できます。（出典：Cloudflare Docs「Cache Keys」）
ここで、次の二つに異なる応答を返す設計を考えます。
https://example.com/blog/seo-guide/https://example.com/blog/seo-guide/?spam_id=abc123前者は200、後者は410にしたいとします。
ところが、キャッシュがパラメータを無視し、両者を同じキーとして扱っていたらどうでしょうか。処理順序や保存設定によっては、不適切な応答が共有されるおそれがあります。
反対に、正常ページの200が先にキャッシュされていて、拒否したいパラメータ付きURLにもその200が返されるかもしれません。
したがって、パラメータによって応答を変える場合は、URLの拒否判定とキャッシュの判定が矛盾していないことを確認する必要があります。
導入初期のエラー応答をキャッシュさせない方針なら、次のような応答ヘッダーを使う設計も考えられます。
Cache-Control: no-storeno-storeは、その応答を保存・再利用しないようキャッシュへ指示するものです。ただし、すでに存在するキャッシュの削除や、CDN側の独自ルールの確認は別途必要です。ヘッダーを一つ追加しただけで、すべてのキャッシュ問題が解消したと考えないようにします。（出典：RFC 9111「HTTP Caching」）
Search Consoleでは、件数よりも「どのURLに何が起きているか」を見る
「検出された」と「インデックスされた」を区別する
Search Consoleに知らないURLが表示されたからといって、そのすべてが検索結果に出ているとは限りません。
たとえば、「クロール済み - インデックス未登録」は、Googleがクロールしたものの、インデックスには登録していない状態です。今後登録される場合も、登録されない場合もあると説明されています。（出典：Search Consoleヘルプ「ページ インデックス登録レポート」）
そのため、不要なURLを見つけたら、まず、そのURLが検出されただけなのか、クロールされているのか、実際にインデックスされているのかを分けます。
「見たことのないURLがある」という事実だけでは、被害の程度も、対処の優先順位も決まりません。
インデックス上の情報と、現在の応答を分けて確認する
URL検査では、Googleが保持しているインデックス情報と、公開URLのライブテストを区別することができます。
前者は、Googleが過去に取得・処理した情報です。後者は、現在のページの状態を確認するためのものです。現在の設定を変更したからといって、インデックス情報も同時に更新されるわけではありません。（出典：Search Consoleヘルプ「URL 検査ツール」）
たとえば、以前は200だった不要URLを410に変えた直後であれば、現在の応答は410でも、Search Consoleには以前の状態が残っている場合があります。
このとき、「まだ表示されているから設定が失敗した」とすぐに判断するのではなく、現在のHTTP応答、Googleの最終クロール、インデックス上の状態を分けて確認します。
本当に改ざんされていないかも確認する
ページの本文、タイトル、リンク先が意図せず変わっている場合は、パラメータ制御だけで終わらせず、改ざんの調査に進みます。
Search Consoleの「セキュリティの問題」を確認し、問題が報告されていれば、その内容に沿って修復します。Googleのガイドでは、不正なページの例が完全な一覧とは限らないことや、閲覧条件によって問題が再現しない場合があることも説明されています。（出典：Search Consoleヘルプ「セキュリティの問題レポート」）
画面を一度見て正常だったという理由だけで、調査を終了しないようにします。
特に、感染が疑われるページを通常のブラウザでむやみに開くのではなく、URL検査や、適切に管理した環境でのHTTP取得などを用いて確認することが大切です。（出典：Search Consoleヘルプ「セキュリティの問題レポート」）
site:検索は補助として使う
自社ドメインに、無関係な語句を組み合わせて検索すると、不審なページを見つける手がかりになることがあります。
site:example.com 無関係な語句ただし、Googleは、site:検索がインデックスされたURLの完全な一覧を返すものではないと説明しています。検索に出なかったから問題がない、表示件数がそのまま正確なインデックス数である、と判断しないようにします。（出典：Google 検索セントラル「site: 検索演算子の使い方」）
Search Console、アクセスログ、実際のHTTP応答、サイト内のデータを組み合わせて判断します。
実装後は、ブラウザの見た目ではなくHTTP応答を検証する
設定を変更したら、最初に確認するのは、実際に何のステータスコードが返っているかです。
以下は、macOSやLinuxなどのシェルで使う確認例です。example.comは説明用なので、検証対象の自社サイトのURLへ置き換えます。
正常なページが200を返すことを確認する
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/blog/seo-guide/'この例では、レスポンス本文を表示せず、ヘッダーを確認します。-D -は受信したヘッダーを標準出力へ出す指定です。（出典：curl公式マニュアル）
記事が正常に公開されているという前提なら、200であることを確認します。
実際のサイトにHTTPS化や末尾スラッシュの正規化がある場合は、そのリダイレクトも含めて、事前に期待する動作を決めておきます。
存在しないページが404を返すことを確認する
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/not-a-real-page/'このURLが実在せず、移転先や廃止履歴にも該当しないという前提なら、404を期待します。
画面に「見つかりません」と表示されるだけでなく、実際の応答が404になっているかを確認します。
恒久廃止したパラメータURLが410を返すことを確認する
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/blog/seo-guide/?spam_id=abc123'これは、このサイトでspam_idを含むURL群を恒久廃止し、410にすると決めた場合のテストです。
未知のパラメータだから、すべてのサイトで410が正解という意味ではありません。テストの期待値は、先に決めた仕様に合わせます。
正常な計測パラメータ付きURLが表示できることを確認する
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/blog/seo-guide/?utm_source=newsletter&utm_medium=email'このURLが正規のメルマガ運用で使われるなら、正常に表示できることを確認します。
同様に、利用中の広告・予約・購入経路でも、パラメータが付いた状態で正しいページへ到達できるかを調べます。
なお、テスト用の文字列を付けてページが表示されたことと、本番の広告計測が正しく行われることは別です。広告計測については、実際のタグや連携の確認も必要です。
パラメータが混在した場合を確認する
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/blog/seo-guide/?utm_source=newsletter&spam_id=abc123'このテストでは、許可されたパラメータが付いていても、廃止対象のパラメータが混ざったリクエストを正しく処理できるかを確認します。
同時に、パラメータの順番を入れ替えても判定が変わらないかを確認します。順番に意味がないという仕様なのに、並び順によって200になったり410になったりする状態は避けたいところです。
存在しないパスに正常なパラメータを付けても404か
curl -sS --max-time 20 -D - -o /dev/null \
'https://example.com/not-a-real-page/?utm_source=newsletter'これも重要なテストです。
パラメータが正常でも、ページ自体が存在しなければ404にするという設計が、実際に守られているかを確認します。
リダイレクトがある場合は、途中の応答も確認する
リダイレクト先まで追跡する場合は、-Lを付けます。
curl -sS -L --max-redirs 5 --max-time 20 -D - -o /dev/null \
'https://example.com/blog/seo-guide/?spam_id=abc123'-Lは、リダイレクト先へアクセスを続ける指定です。最初の応答だけを見る確認と、最終的な到達先まで見る確認を分けると、意図しない転送を見つけやすくなります。（出典：curl公式マニュアル）
さらに、キャッシュがない状態とある状態、ログインしていない状態、実際の公開URLなどでも確認します。
一度だけ期待したステータスが出たことではなく、同じ条件なら一貫した応答になることを確かめるのが検証です。
すでにインデックスされた不要URLは、応答の修正と削除対応を分ける
すでに不要なURLが検索結果に出ている場合は、まず、そのURLが今後どのような応答を返すべきかを修正します。
存在しないページなら404。恒久廃止したURLなら410。ページは残すが検索に出さないならnoindex。適切な移転先があるなら移転処理です。
そのうえで、緊急に検索結果から隠したい事情がある場合は、Search Consoleの削除ツールを検討します。
Googleの削除ツールによる一時的な削除は、約6か月の措置です。恒久的な対応には、ページの削除と404・410、noindex、アクセス制限など、サイト側の変更が必要です。（出典：Search Consoleヘルプ「削除ツール」）
削除ツールだけで、サイト側の問題を放置しない
検索結果から一時的に見えなくなっても、サイトが同じ不要URLを200で返し続けていれば、URLの生成・配信の問題は残ります。
また、別のパラメータや別の組み合わせで同じ問題が起きれば、個別の削除申請を繰り返すことになりかねません。
そのため、削除ツールは、サイト側の恒久対策を置き換えるものではなく、必要なときに組み合わせる手段と考えます。
「見えているURLを消したか」だけでなく、「同じ種類の不要URLが今後も正常なページとして配信されるのか」を確認することが大切です。
プレフィックス削除は、対象範囲を慎重に決める
削除ツールでは、特定のURLだけでなく、指定したプレフィックスで始まるURL群を対象にできる場合があります。
ただし、対象範囲を広く取りすぎれば、正常な記事やサービスページまで巻き込みます。Googleの説明でも、ドメインのルートを指定するとサイト全体を対象にし得ることが示されています。（出典：Search Consoleヘルプ「削除ツール」）
パラメータ付きURLだけを処理したいのに、記事ディレクトリ全体を削除対象にする、といった操作は避けるべきです。
削除対象を決める前に、代表的な正常URLと不要URLを並べ、どこまでが一致するのかを確認します。
サイト内から不要URLを出し続けない
外部からのリンクだけでなく、自社サイトが不要なURLを出していないかも確認します。
サイトマップ、記事内リンク、関連記事、パンくず、一覧ページ、テンプレートなどで、廃止したURLへリンクし続けていないかを調べます。
Googleは、サイト内リンクでは正規URLへリンクすることや、サイトマップとcanonicalの指定を矛盾させないことを推奨しています。（出典：Google 検索セントラル「rel="canonical" などを利用して正規ページを指定する方法」）
サーバーでは410を返しているのに、サイトマップでは公開中のURLとして提出している。こうした状態は避けたいところです。
不要URLの整理は、外から来るアクセスへの応答だけでなく、内側から出すURLの整備まで含めて考えます。
いきなり全面導入せず、観測・限定導入・拡張の順に進める
許可リスト方式は、必要な入力を正確に把握できているほど運用しやすくなります。反対に、サイトの仕様が十分に把握できていない状態で厳しく制御すると、正常なアクセスを拒否する危険があります。
そこで、実務では段階的な導入をおすすめします。
最初は、拒否する代わりに記録する
まず、許可リストにないパラメータが付いているアクセスを記録し、どのようなものがあるかを確認します。
その際、すべての値を無制限に保存するのではなく、調査に必要な範囲を決めます。認証情報や機密性の高い値を不用意にログへ残さないよう、記録項目やマスキングも検討します。
ここで見たいのは、未知のパラメータの名前、使われるページ、頻度、正規の施策との関連などです。
外部の不審なリンクに見えたものが、実際には自社のメール配信ツールや、古いキャンペーンの計測だったとわかるかもしれません。
不明なものをすぐに悪意と決めつけず、仕様と照合する段階を設けます。
次に、影響範囲が明確な部分から適用する
たとえば、使っていないことを確認できた特定のパラメータURL群や、機能が単純な記事詳細ページなどです。
まず限られた範囲へ適用し、正常なアクセスや計測が維持されていることを確認します。その後、一覧や検索など、条件が複雑な場所へ対象を広げます。
記事詳細ページで問題がなかったからといって、同じルールが商品検索や会員機能でも使えるとは限りません。
ページの役割ごとに確認しながら、適用範囲を広げる方が判断しやすくなります。
すぐに戻せる状態を用意する
導入時には、ルールを無効にする方法、キャッシュを消す方法、正常な許可リストへ戻す方法も決めておきます。
特に、広告や予約の導線に影響する可能性がある変更は、担当者間で共有します。変更直後にアクセスやコンバージョンの異常があった場合、パラメータ制御も原因候補として確認できるようにしておきます。
「正しいはずだから全面適用する」のではなく、「正しく動いていることを確認しながら広げる」という進め方です。
この段階的な導入は、SEO上の裏技ではありません。URL制御の変更を、通常のシステム変更として安全に進めるための運用です。
対策の成功を「404が減ったかどうか」で判断しない
404・410の対策を行うと、Search Consoleやログ上で4xxのURLが目立つようになるかもしれません。
しかし、それがただちに悪化を意味するわけではありません。
以前は存在しないURLを200で返していたものが、正しく404を返すようになったのであれば、応答としては改善しています。廃止したURLが410を返していることも、設計どおりです。
Googleも、サイト内のすべてのURLがインデックスされることを目指すべきではなく、正規ページを対象として考えるよう案内しています。（出典：Search Consoleヘルプ「ページ インデックス登録レポート」）
重要なのは、どのURLが未登録になっているのかです。
スパム由来の不要URLが未登録になっているなら、意図した結果かもしれません。一方、正常なサービスページや記事が誤って410になっているなら、重大な不具合です。
同じ「未登録」「4xx」という集計でも、中身はまったく違います。
評価すべきなのは、正常なページを守りながら不要URLを整理できたか
今回の対策では、次のような観点で確認するとよいでしょう。
不要なURLが正常なコンテンツとして配信されなくなったか。正規のページは変わらず表示されているか。広告やメルマガの着地は正常か。フォームや購入が機能しているか。Googleが新しい応答を取得したあと、不要URLのインデックス状態がどう変化したか。
このように、SEOの状態と事業上の機能の両方を見ます。
「410がたくさん出るようになった」という数字だけでは、成功かどうかは判断できません。必要なアクセスを拒否していないことが、必ず条件になります。
クロール効率の改善を、順位上昇の保証にしない
不要なURLの整理は、クロールの無駄を減らすという文脈でも語られます。しかし、削減したクロールが必ず重要ページへ再配分されるわけではありません。
Googleのクロールバジェットのガイドは、主に大規模・高頻度更新のサイトを対象としており、クロール能力の上限に達していないサイトでは、空いたリソースがそのまま他のページへ配分されるとは限らないと説明されています。（出典：Google「クロール バジェットの管理」）
したがって、「不要URLを1万件消したら順位が上がる」といった単純な計算はできません。
この施策の価値は、まず、サイトが公開するURLを適切に管理できることにあります。不要なページを正常なページとして返さず、本当に見せたいコンテンツと正規の利用経路を維持する。そのうえで、クロールや検索表示にどのような変化があるかを観察します。
404・410を返しても、再アクセスが完全に止まるとは限らない
不要URLへのアクセスが残っているからといって、すぐに対策が失敗したと判断する必要もありません。
Googleは、404になったURLにも、しばらくアクセスを試みる可能性があることや、GooglebotにURLを永久に忘れさせる方法はないことを説明しています。（出典：Search Consoleヘルプ「ページ インデックス登録レポート」）
また、外部の第三者が新しいURLを作ってリンクする行為まで、こちらのHTTP応答で止められるわけではありません。
目標にするべきなのは、「二度とアクセスされないこと」ではなく、どのようなアクセスが来ても、サイトが決めた仕様どおりに一貫して応答することです。
制作会社や開発担当者には、こう伝えると話がずれにくい
「スパム対策として、パラメータが付いたURLを全部410にしてください」という依頼では、範囲が広すぎます。
実装担当者に伝えるなら、たとえば次のように、目的と保護すべき機能を合わせて説明します。
公開HTMLページについて、正規のルーティングや公開コンテンツに対応しないURLを、正常なページとして返さないようにしたいです。存在せず、適切な移転先もないURLは404としてください。過去に誤配信していた不要なパラメータURL群については、恒久廃止する対象を定義したうえで410を返す方針を検討したいです。
その際、広告・アクセス解析・メルマガ・検索・ページネーションなどに必要なパラメータを棚卸しし、ページの種類ごとに許可する名前、値、組み合わせを決めてください。許可されたパラメータと廃止対象のパラメータが混在する場合も、全体を検証してください。
管理画面、認証、決済、外部連携などに公開ページ向けのルールを無条件で適用しないでください。また、CDNやサーバーのキャッシュによって正常なURLへ410が返ったり、廃止対象URLへ200が返ったりしないよう、キャッシュキーと処理順序を確認してください。導入前後のテストと、問題があった場合の切り戻し手順も用意してください。
ここまで伝えると、「410を返す」という作業だけではなく、守るべき範囲まで共有できます。
さらに、正常なURL、存在しないURL、許可するパラメータ付きURL、廃止するURL、混在したURLを実例として渡すと、テストしやすくなります。
開発依頼では、抽象的な「SEOに良い状態」だけでなく、どのURLにどの応答を期待するのかまで合意しておくと、実装とテストの食い違いを防げます。
まとめ｜守るべきなのは、410という設定ではなく、サイトが公開するURLの範囲
スパムリンクを貼られたとき、外部のリンクだけを追いかけていると、自分たちのサイトが不要なURLを受け入れ続けている問題を見落とすことがあります。
存在しないページを200で返していないか。用途のないパラメータによって、意図しないURLやコンテンツが生まれていないか。広告や計測に必要な入力と、公開する必要のないURLを区別できているか。
こうした確認を積み重ねることが、今回のSEO対策の中心です。
存在しないURLには404。恒久廃止するURLには410。必要なパラメータは許可し、正常な重複URLは正規化する。
ただし、「未知のパラメータはすべて410」が、どのサイトにも当てはまる共通の正解ではありません。まず自社サイトの仕様を整理し、どのURLを提供し、どのURLを提供しないのかを決める必要があります。
そのうえで、不要なパラメータURL群を恒久的に廃止する運用として、410を使う。存在しないだけのURLには404を返す。検索結果からの除外とクロール抑制を区別し、設定後は実際の応答と正規の利用経路を検証する。
この順序で進めれば、単に「スパムっぽいURLを消す」という場当たり的な作業から、継続して管理できる仕組みへ変えられます。
SEOは、ページを増やすことだけではありません。存在しないものを、存在するように見せないこと。必要なものを守りながら、不要なものを公開し続けないこと。
404と410 Goneを使う意味は、その基本をサーバーの応答として明確にすることにあります。
