Google treats ?filter[]= and ?filter%5B%5D= as separate URLs

Google’s John Mueller said a URL with raw square brackets and the same URL with those brackets percent-encoded are not the same URL, in a Bluesky exchange written up by Search Engine Roundtable this week. He was answering Vanessa Fox, a former Googler, who asked whether example.com/category?filter[]=123 and example.com/category?filter%5B%5D=123 count as distinct URLs when a site uses one form in its links and the other in its canonical tag.

The reason is in the standard. RFC 3986, Section 2.2 places square brackets and plus signs in the reserved set, and says that URIs differing only by the replacement of a reserved character with its percent-encoded form are not equivalent. Reserved characters are protected from normalization, so nothing in the spec permits a crawler to fold the two together. Mueller noted that JavaScript’s own new URL() agrees: compare the two hrefs and the result is false. The raw version is also technically invalid, because RFC 3986 allows brackets only in the hostname, where they wrap a raw IPv6 address. Browsers usually encode them when a person types them in.

None of that means something broke in Google this week. Mueller said that if the server returns the same content on both URLs, Google crawls both, recognizes the duplication, possibly at checksum level, and picks one. The live cost is the familiar one on faceted navigation: two crawls where one would do, and Google rather than the site deciding which address survives.

The “internal issues” in Search Engine Roundtable’s headline are old. Mueller wrote that he was seeing some of the issues that came up internally with these characters, then added “(though they’re 10+ years ago)”, and followed up with “No issues - the internet standards for URLs are just very specific.” The risk he did flag is outside Google: other crawlers, indexers and fetchers may not implement the logic as exactly, so he suggested double-checking the ones you care about. Mueller’s reply named none of them, so that check has to be empirical. Crawling one bracket URL with each tool you depend on shows whether it records the raw and encoded forms as one URL or two.

Fox’s own case is the useful one, because it is a site that already made the wrong choice. Fox said the site uses the invalid bracket form throughout, that it seems to be indexing fine, and that changing it would be a ton of work, so they are leaving it. Mueller expected it to keep working, on the grounds that the web is messy and not all of it is technically correct, but said he would not set up a new site that way and would pay extra attention to internal linking consistency, including rel=canonical and structured data.

What to do

• Pick one form per parameter and emit it everywhere: internal links, rel=canonical, sitemap entries, and any URL inside structured data. For a new build, the encoded %5B%5D form is the one the standard allows.
• Leave a working bracket site alone. A rewrite buys consistency, not rankings, and the text of a URL is a very small ranking signal to begin with. The case worth funding is a template that links to the raw form while its canonical tag carries the encoded form, or the reverse.
• Check spaces and plus signs in the same pass. Mueller said they behave the same way, and that the behavior differs depending on whether the character sits in the path or the query string, so test both positions rather than assuming one result carries over.
• Ignore hex case. Mueller confirmed %5B and %5b are equivalent, so a template that varies the case of its escapes is not generating extra URLs.