URLパラメータとは？ SEOへの影響と、重複コンテンツを防ぐ設定の基本（2026年8月時点）

01 いま最新版は何か — URLパラメータとGoogleの姿勢の変化

URLパラメータの基本構文

URLパラメータとは、URLの末尾に付く「?」以降の文字列のことです。「項目名=値」という形式で1つ以上の情報を追加でき、複数指定する場合は「&」の記号でつなぎます。たとえば https://example.com/shoes?color=red&sort=price というURLでは、colorとsortという2つの項目名に、それぞれredとpriceという値が入っています。ECサイトの絞り込み・並び替え、広告の流入計測、セッション管理など、幅広い用途で使われている、URLの基本的な仕組みのひとつです。

2022年、GoogleはURLパラメータツールを廃止した

URLパラメータの扱いを考えるうえで、まず押さえておきたい一次情報があります。Search Consoleにはかつて「URLパラメータツール」という機能があり、サイト運営者がGooglebotに対して、どのパラメータをクロール時にどう扱ってほしいかを個別に指定できました。Google Search Central Blogは、2026年から4年半ほど遡る2022年3月、この機能を廃止すると発表しました(Spring cleaning: the URL Parameters tool(訳: 春の大掃除、URLパラメータツール))。2009年に登場したこのツールは、13年間サイト運営者の設定を受け取り続けてきたことになります。

廃止の理由 — Googleは自動処理に切り替えた

廃止の理由についてGoogleは、実際に指定されていたパラメータ設定のうち役に立っていたのは全体の約1%程度だったと説明し、Googlebotのクロールシステムが十分に賢くなり、多くの場合は手動での指定がなくてもパラメータ付きURLを適切に扱えるようになったためだとしています。以後、パラメータの扱いを個別に制御したい場合の主な手段はrobots.txtによるクロール制御と、rel="canonical"による正規URLの指定の2つに一本化されました。この記事では、この2つを軸に、2026年8月時点でWEBディレクターが実際に確認できる手順を整理します。

02 なぜ・背景 — パラメータが増えるとどうして問題になるのか

アクティブパラメータとパッシブパラメータ

URLパラメータは、大きく2つの性質に分けて考えると整理しやすくなります。ひとつはアクティブパラメータで、ページに表示される内容そのものを変える働きを持ちます。商品の色・サイズによる絞り込み、並び替え順の指定などが該当し、条件ごとに異なる内容のページが同じテンプレートから生成されます。もうひとつはパッシブパラメータで、表示内容は変えず、流入元や広告キャンペーンの識別のためだけに付与されます。UTMパラメータ(utm_source・utm_medium・utm_campaign等)がその代表例です。この2つを区別せずに一律で扱うと、対処法を誤ります。

重複コンテンツとクロール効率という2つの懸念

アクティブパラメータが増えると、内容がほとんど同じページが大量のURLとして生成されます。同じ商品一覧を「価格の安い順」で見せるURLと「新着順」で見せるURLは、見た目の並びは違っても検索エンジンにとっては重複に近いコンテンツとして扱われる可能性があります。これ自体はGoogleのスパムポリシー違反ではありませんが、検索エンジンがどのバージョンを検索結果に出すべきか判断しづらくなり、結果として意図しないURLが検索結果に表示されることがあります。もう一つの懸念がクロール効率です。パラメータの組み合わせが増えるほどURLの総数は掛け算的に増え、Googlebotが同じ内容のページを何度も巡回することに時間を使い、本来インデックスしてほしい新規ページの発見が遅れる可能性が出てきます。

ファセットナビゲーションという典型例

この問題が最も起きやすいのが、ECサイトによくある絞り込み検索の仕組み、いわゆるファセットナビゲーションです。Google Search Central Blogは2014年の記事(Faceted navigation best (and 5 of the worst) practices(訳: ファセットナビゲーションの良い実践と、5つの悪い実践))で「ファセットナビゲーションは、サイト運営者から報告されるオーバークロール(過剰なクロール)問題の中で、群を抜いて多い原因」だと述べています。2024年12月に公開された続報(Crawling December: Faceted navigation(訳: クローリング・ディセンバー、ファセットナビゲーション))でも同じテーマが取り上げられており、10年単位で解決されていない根の深い課題であることがわかります。

03 この記事で出てくる用語

canonical(正規化)とは

UTMパラメータとは

クロールバジェットとオーバークロール

Googlebotが1つのサイトに割く巡回量には、実務上の上限があります。この上限を指す言葉がクロールバジェット(クロール予算)で、パラメータ付きURLの組み合わせが際限なく増えると、限られた予算が同じ内容の巡回に消費され続ける状態、いわゆるオーバークロールが起こります。02章で触れた2014年・2024年のファセットナビゲーション記事は、いずれもこのオーバークロールを主題にしています。

日本語や記号を値に使うときの注意

パラメータの値に日本語や記号(スペース・全角文字等)をそのまま使うと、ブラウザやサーバーによって解釈が分かれ、同じページを指しているつもりのURLが表記ゆれを起こすことがあります。一般的には、こうした文字はパーセントエンコード(URLエンコード)という形式に変換して扱われます。たとえば全角スペースは%E3%80%80のような形に置き換わります。パラメータの命名規則を統一する際は、値そのものを半角の英数字とハイフン・アンダースコアだけに限定しておくと、エンコード後の表記ゆれを未然に防ぎやすくなります。02章のファセットナビゲーションの例のように、絞り込み条件の名称に日本語カテゴリ名をそのまま使っているサイトでは、この点を特に確認しておく価値があります。

04 型別 — 適用範囲・限界・手順

🅰 適用範囲 — このガイドが当てはまるサイト・当てはまらないサイト

URLパラメータの整理が特に効くのは、商品点数が多いECサイト、検索結果ページを持つサイト、絞り込み・並び替え機能を提供するメディアサイトなど、パラメータの組み合わせ数が数十から数百以上になりうるサイトです。逆に、コーポレートサイトや記事数の少ないブログのように、パラメータ付きURLがほぼ発生しないサイトでは、この記事の対策の優先度は相対的に低くなります。まずは05章のチェックリストの最初の項目で、自分のサイトにパラメータ付きURLがどの程度存在するかを数えるところから始めるのが妥当です。

🅱 canonicalが保証しないこと

canonicalタグを設置しても、それだけで解決しないことがあります。03章で触れたとおり、Googleにとってcanonicalの指定は示唆であり絶対の規則ではありません。canonicalタグの記述内容と、実際にそのページで使われている他のシグナル(内部リンクの向き先、サイトマップに載っているURL、リダイレクトの有無など)が食い違っていると、Googleが指定と異なるURLを代表として選ぶことがあります。canonicalは「宣言する」ための仕組みであって、「強制する」ための仕組みではない、という前提を持っておく必要があります。

🅲 手順 — パラメータの棚卸しから設定までの4段階

実際の作業は、次の4段階で進めると抜け漏れを防ぎやすくなります。第一に、サイト内で使われているパラメータの一覧を洗い出す棚卸し。第二に、各パラメータを02章のアクティブ・パッシブに分類する作業。第三に、アクティブパラメータについては代表URLを決めてcanonicalを設定し、必要に応じてrobots.txtでクロールを制御する設定作業。第四に、パッシブパラメータ(UTM等)については、命名規則を統一した管理表を作り、今後発行するリンクがその表に沿っているかを確認する運用の整備です。この4段階を、05章のチェックリストにそのまま落とし込んでいます。

よくある失敗パターンと、その避け方

実際の現場では、canonicalとrobots.txtを両方とも設定してしまい、かえって意図が伝わらなくなるケースがよく見られます。Disallowにしたページのcanonicalタグは、Googlebotがそもそも読みに行けません。「重複を統合したい」という意図でcanonicalを設定したページを、同時にrobots.txtでも塞いでしまうと、統合の指示自体が届かなくなります。もうひとつの典型的な失敗が、canonicalの指定先を毎回変えてしまうケースです。並び替え順が変わるたびに違うURLをcanonicalの指定先にしていると、Googleにとってどれが本当の代表URLなのか判断材料が一貫せず、結局は独自に別のURLを選んでしまうことがあります。1つのページ群に対して、canonicalの指定先は常に同じ1本に固定するのが基本です。

05 自分のサイトで確認するチェックリスト

チェックリストの3つの観点

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、パラメータの現状把握、canonical・robots.txtの設定確認、UTMパラメータの運用確認の3つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 主要ページを5件開き、アドレスバーに表示されるURLに「?」が含まれるものが何件あるか数える
• 「?」を含むURLのうち、絞り込み・並び替えなど表示内容を変えるアクティブパラメータが使われているものを3件書き出す
• その3件について、ページの「ソースを表示」を開き、head内にrel="canonical"タグが存在するか確認する
• canonicalタグが指すURLが、パラメータを含まない代表URLになっているか確認する
• robots.txtを開き、Disallow行にパラメータ関連の記述(?や特定のパラメータ名)が含まれていないか確認する
• Search Consoleの「ページ」レポートを開き、インデックス済みURLの上位20件にパラメータ付きのものが混在していないか確認する
• 社内・外部の広告担当者が発行しているリンクを3本集め、UTMパラメータのutm_source・utm_medium・utm_campaignがすべて小文字で統一されているか確認する
• 同じ流入元を指すはずのUTM値に、大文字小文字だけが違う表記ゆれ(例:Emailとemail)が無いか2本以上のリンクを比較する
• 絞り込み検索で条件に合致する商品が0件になるURLを1つ作り、返ってくるステータスコードが200か404かを確認する
• サイト内で使われているパラメータの項目名を5つ書き出し、命名(英数字・大文字小文字)が統一されているか確認する
• Search Consoleの「クロール統計情報」レポートを開き、直近90日間のクロールリクエスト数の推移を確認する
• URLパラメータの一覧・用途・扱い方針をまとめた管理表が社内に存在するか確認する(無ければ「無し」と記録する)

12項目の内訳と、かかる時間の目安

最初の2項目はパラメータの現状把握、3番目から6番目はcanonical・robots.txtの設定点検、7番目から9番目はUTMパラメータの命名確認、10番目から12番目はファセットナビゲーションのクロール状況と管理体制の確認に対応しています。すべてに目を通す時間の目安は1サイトあたり25分程度です。すべてを一度に終える必要はなく、まずは最もパラメータの種類が多いページ群(商品一覧・検索結果ページ等)から手を動かし始めることをおすすめします。

06 パラメータ制御の手段の比較

4つの制御手段、それぞれの向き不向き

URLパラメータへの対処には複数の手段があり、どれか1つですべて解決するわけではありません。以下は、それぞれの手段が「何を制御し、何を制御しないか」を整理した表です。

組み合わせて使うのが前提

この表からわかるとおり、canonicalは「クロールを止める」手段ではなく、robots.txtは「評価を1本に集約する」手段ではありません。パラメータ付きURLが多いサイトでは、canonicalで評価を集約しつつ、真に不要なパラメータの組み合わせだけをrobots.txtで止めるという組み合わせが基本形になります。sitemap.xmlには、canonicalで指定した代表URLだけを載せ、パラメータ付きのバリエーションURLは含めないようにするのが一貫性のある運用です。当サイトの🔧 sitemap.xml作成ツールを使えば、この代表URLのみのサイトマップを手早く作成できます。リンク切れの有無も併せて確かめたい場合は、🔧 リンク漏れチェックツールで一覧ページとパラメータ付きURLの両方を巡回できます。

07 当サイトの実測

自社サイトのパラメータ付きURLの扱い方

このガイドを書く過程で、自サイトのURLパラメータの扱いも実際に確認しました。当サイトのSEO記事一覧ページは、カテゴリで絞り込む?ct=と、タグで絞り込む?tag=という2種類のパラメータを持っています。これらは02章の分類でいうアクティブパラメータにあたり、絞り込み条件によって表示される記事の一覧が変わります。

canonicalが自動でパラメータを剥がす設計にしている

この2種類のパラメータについてページの<head>を確認したところ、canonicalタグは常にパラメータを含まない一覧ページの基本URLを指すよう実装されていました。絞り込み条件がいくつ変わっても、canonicalの指定先は1本に固定されるという設計です。これにより、記事一覧の絞り込みバリエーションが重複コンテンツとして個別に評価される事態を避けています。一方でこの設計は、robots.txtによるパラメータのDisallowとは併用していません。絞り込みページ自体は読者にとって有用なナビゲーションであり、クロール自体を止める必要は無いと判断したためです。

08 このテーマの、これまで

4層の整合性をcurlで確認した回

sitemap・canonical・内部リンク・末尾スラッシュという4つの要素が食い違っていないかを、curlコマンド3行で確認する方法を以前まとめたことがあります(archives/39)。本記事の04章🅱で触れた「canonicalは示唆であり規則ではない」という前提は、この4層が一致していて初めて信頼できる指定になる、という考え方に基づいています。

末尾スラッシュの違いで、Googleから見えなくなっていた回

sitemap.xmlに記載したURLの末尾スラッシュの有無がページ実体と一致せず、Googleから見えていなかった事例を検証した回もあります(archives/38)。本記事の06章で扱った「サイトマップには代表URLだけを載せる」という運用は、こうした表記の細部まで一致させて初めて機能します。

重複記事をタイトル一致と元記事一致の2通りで数えた回

自サイト内に同じ内容の記事が複数存在していないかを、タイトルの一致と元記事URLの一致という2つの異なる基準で数えたところ、45組と139組という3倍の差が出た事例を記録した回もあります(archives/129)。本記事の02章で扱った重複コンテンツは、URLパラメータによるものだけでなく、こうした記事単位の重複としても現れることを示す実例です。

547件の再クロール待ち行列を記録した回

URLを書き換えた際、Googleの再クロールが完了するまでに実際どれくらいの時間がかかるかを、547件の待ち行列とともに記録した回もあります(archives/108)。03章で触れたクロールバジェットの制約は、パラメータ付きURLを整理した直後の反映待ちの期間にも同じ形で表れます。