導入：「filter[]=123」と「filter%5B%5D=123」は同じURLか？
絞り込み検索（ファセットナビゲーション）を持つサイトでは、?filter[]=123 のように角括弧（[ ]）を含むパラメータがよく使われます。環境によっては角括弧が %5B%5D とパーセントエンコードされた形で送られることもあり、「どちらも同じ URL として Google に扱われるのか」は長く曖昧でした。
2026年10月、Vanessa Fox（ヴァネッサ・フォックス）氏が Bluesky でこの疑問を投げかけ、Google の John Mueller（ジョン・ミューラー）氏が RFC 3986 を根拠に「厳密には別の URL」と回答しました（出典：Vanessa Fox 氏の Bluesky 投稿とスレッド）。本記事では、このやり取りと Google 公式ドキュメントを照らし合わせ、サイト運営者が確認すべき点を整理します。2026年10月25日時点の情報です。
何が語られたか：Mueller 氏の回答の要点
Fox 氏の投稿は 2026年10月18日（UTC）、Mueller 氏の回答は 19日〜20日（UTC）です。スレッドを確認した要点は次のとおりです（出典：同スレッド）。
- 両者は等価ではない。 Mueller 氏自身「等価だと思っていたが、そうではなかった（TIL）」と前置きしつつ、RFC 3986 セクション 2.2 の「予約文字を対応するパーセントエンコード形に置き換えた URI は等価ではない」という文を引用し、角括弧とプラス記号は予約文字だと説明。JavaScript の
new URL()で両者のhrefを比較するとfalseになることも示しました。 - サーバー側で「実質的に同じ」にはできる。 両方が同じコンテンツを返せば「ソフトに等価」になり、Google は両方をクロールし、重複を検出して1つを選ぶ、という見方です。
- どちらかに統一する。 「1つを選び、リンク・canonical・サイトマップ・構造化データで一貫して使う」ことを推奨。
%5Bと%5bのような16進数の大小文字は問題にならない（"%5B" === "%5b"）としています。 - 生の角括弧は厳密には無効。 角括弧が許されるのはホスト部で IPv6 アドレスを囲む用途だけで、
?filter[]=123は RFC 3986 上「厳密には無効」。ブラウザは入力時にエンコードすることが多い一方、JavaScript などのコードから要求する場合は生のまま送られることがあるため、使うなら「常にエンコードし、生の[ ]を表示しない」ことを勧めています。 - 既存サイトはおそらく動き続ける。 Fox 氏の「あるサイトは生の角括弧を全面的に使っているが、インデックスは問題ないようだ」に対し、「ウェブは雑然としており動き続けると思う。ただ新規サイトをこの形では構築しないし、内部リンクや rel=canonical・構造化データの一貫性に特に注意する」と回答しました。
Search Engine Roundtable は、Mueller 氏が「この種の文字で社内的に起きた問題を見ている（ただし10年以上前のこと）」と述べ、他のクローラーやインデクサーは Google ほど厳密ではないかもしれないので気になるものは確認した方がよい、と補足したと報じています。同記事は後に、Mueller 氏が「問題はない。URL のインターネット標準がとても厳密なだけだ」と述べたという更新を加えています（出典：[Google Search Internal Issues With Square Brackets [] Punctuations In URLs](https://www.seroundtable.com/google-square-brackets-urls-42332.html)）。「社内的な問題」の中身は公表されておらず、本記事では推測しません。
根拠となる仕様：RFC 3986 セクション 2.2
RFC 3986（IETF STD 66）は URI の構文を定める標準で、セクション 2.2 は予約文字として gen-delims（: / ? # [ ] @）と sub-delims（! $ & ' ( ) * + , ; =）を定義し、予約文字をパーセントエンコードした形に置き換えた URI は元の URI と「等価ではない」と明記しています（出典：RFC 3986 Section 2.2）。角括弧は gen-delims、プラス記号は sub-delims に含まれるため、filter[]= と filter%5B%5D= が別物になるのはこの定義からの結論です。またセクション 3.2.2 は、角括弧が許される唯一の場所は IP リテラルを囲むホスト部だと述べ、セクション 6.2.2.1 はパーセントエンコードの16進数（%3a と %3A など）は大文字小文字を区別せず、大文字に正規化すべきだとしています（出典：同 RFC 3986）。
Google 公式ドキュメントとの関係
「URL 構造のベスト プラクティス」は角括弧を非推奨例に挙げている
Google 検索セントラルの「Google 検索における URL 構造のベスト プラクティス」（ページ記載の最終更新日：2025-12-31 UTC）は、Google 検索は IETF STD 66 で定義された URL をサポートし「この規定で予約文字として定義されている文字には、パーセント エンコーディングを行う必要があります」と述べています。パラメータの非推奨例として「Key-Value ペアを区切るのにコロン（:）を使用し、パラメータを追加するのにかっこ（[ ]）を使用します」が、https://example.com/category?[category:dresses][sort:price-low-to-high][sid:789] という URL とともに挙げられています（出典：Google 検索における URL 構造のベスト プラクティス）。今回の発言は新方針ではなく、既存ガイドラインを RFC の観点から補足したものと読めます。
重複排除と canonical
「rel=”canonical” などを利用して正規ページを指定する方法」（最終更新日：2026-07-14 UTC）では、rel=”canonical” は正規ページを「強く示すシグナル」、サイトマップは「シグナルとしては弱い」とされ、「サイト内でリンクする場合は、重複 URL ではなく正規 URL にリンクしてください」「異なる正規化方法を使用して、複数の異なる URL を同じページの正規版として指定しないでください」と書かれています（出典：rel=”canonical” などを利用して正規ページを指定する方法）。Mueller 氏の「表記を1つに揃える」助言はこの文書の実践です。canonical の基本は「URLの正規化方法 canonical属性の使い方」もご参照ください。
実務での読み方：日本のサイト運営者がやること
1. 現状を棚卸しする
角括弧・プラス記号・スペースを含む URL が、どこで・どの表記で生成されているかを確認します。対象は HTML のリンク、JavaScript が組み立てる URL、canonical、XML サイトマップ、構造化データ、og:url です。ライブラリが自動でエンコードするため、テンプレートと実際の出力がずれていることがあります。
2. ファセットナビ・絞り込みパラメータの設計
- 新規開発では
?key=value&key2=value2を基本にし、複数値はカンマ区切り（?color=red,blue）など角括弧を使わない設計を検討します。 - 既存の角括弧を今すぐ撤廃する必要はありません。優先すべきは「表記を1つに揃える」ことで、使い続けるなら常にエンコード済み（
%5B%5D）の形を出力し、生の[ ]を HTML 上に出さない運用が安全です。 - 絞り込み結果を検索結果に出す必要がないなら、noindex や canonical で集約することも検討します。
3. canonical・サイトマップ・内部リンクを同じ文字列にする
内部リンクの href、<link rel="canonical">、サイトマップの <loc>、構造化データ、hreflang を、エンコードの有無・16進数の大小文字・末尾スラッシュまで同一の文字列にします。canonical は絶対 URL で書き、可能なら非正規表記へのアクセスは正規表記へ 301 リダイレクトします。
4. Search Console の URL 検査で確認する
URL 検査ツールには「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」の欄があり、ヘルプは「Google は、ユーザーが指定した正規 URL を選択することもありますが、別の URL の方が正規バージョンとしてふさわしいと判断することもあります」と説明しています（出典：URL 検査ツール – Search Console ヘルプ）。[ 版と %5B 版の両方を検査し、Google が選択した正規 URL が意図と一致しているかを見るのが最も手軽なチェックです。なお Fox 氏は ' と %27 は等価に扱われているように見えると報告しており、文字ごとに挙動が異なる可能性があります（公式説明ではありません）。
URL 設計全般の考え方は「GoogleがURLテーマの新動画シリーズを開始｜URLのキーワードは「極めて小さな」シグナル、区切りはハイフン推奨」もあわせてご覧ください。
まとめ
- RFC 3986 では
[ ]と+は予約文字で、filter[]=123とfilter%5B%5D=123は厳密には別の URL です。 - Google は同じ内容を返す URL を重複として集約しますが、選ばれる URL を安定させるには、リンク・canonical・サイトマップ・構造化データの表記統一が必要です。
- 角括弧は IPv6 ホスト部以外では厳密には無効で、Google のガイドラインでも非推奨例です。既存サイトは慌てて変える必要はないものの、新規設計では避け、使い続けるならエンコードした形に揃えることが推奨されています。Search Console の URL 検査で自サイトの実態を確認してください。
