?filter[]= i ?filter%5B%5D= to dla Google dwa różne adresy

Krótka odpowiedź

Tak, dla Google ?filter[]=123 i ?filter%5B%5D=123 to dwa różne adresy. John Mueller z Google napisał 19 października 2026, że Google pobiera obie wersje osobno, a gdy widzi tę samą treść, usuwa duplikat i wybiera jedną z nich. Przyznał też, że wcześniej najpewniej odpowiadał na to pytanie błędnie.

Co z tego wynika dla sklepu: wybierz jedną formę zapisu i trzymaj się jej w linkach, tagu canonical, mapie witryny i danych strukturalnych. Dla nowego serwisu wybierz formę zakodowaną, z %5B i %5D.

Co dokładnie powiedział Mueller

Pytanie zadała Vanessa Fox, była pracowniczka Google, która tworzyła Google Webmaster Central. Najpierw w komentarzach pod pierwszym odcinkiem serii wideo Google „Non-Canonical Cabinet”, potem na Bluesky. Opisała prawdziwy przypadek: w linkach serwisu jest example.com/category?filter[]=123, a w tagu canonical example.com/category?filter%5B%5D=123. Czy to ten sam adres?

Mueller odpowiedział, że sam założyłby, że tak, ale sprawdził i to nie jest ten sam adres. Najważniejsze punkty jego odpowiedzi z 19 i 20 października, które opisały Search Engine Roundtable (20 października) i Search Engine Journal (21 października):

• Google pobiera obie wersje. Jeśli treść jest taka sama, „może nawet na poziomie sumy kontrolnej”, usuwa duplikat i wybiera jedną.
• Zalecenie: wybrać jedną formę i stosować ją konsekwentnie w linkach, canonical, mapach witryny i danych strukturalnych. W tym samym wątku ujął to krócej: jeśli musisz używać nawiasów w adresach, zawsze je koduj i nigdy nie pokazuj [].
• To samo dotyczy spacji, znaku + i %20, z tą komplikacją, że ich znaczenie zależy od tego, czy stoją w ścieżce, czy w parametrach adresu.
• Wielkość liter w kodzie nie ma znaczenia: %5B i %5b to to samo.
• Serwis, który wszędzie używa nawiasów i dobrze się indeksuje, raczej nadal będzie działał. Mueller nie budowałby jednak tak nowej strony.
• Inne roboty, indeksery i narzędzia mogą obsługiwać to mniej dokładnie niż Google, więc warto sprawdzić te, na których Ci zależy.

Ta wypowiedź jest ciekawa z jednego powodu: rzecznik Google publicznie przyznał, że wcześniej najpewniej doradzał błędnie. Jeśli ktoś kiedyś usłyszał, że zakodowane i niezakodowane nawiasy to dla Google to samo, ta rada była błędna.

Skąd ta różnica: znaki zarezerwowane

Adresy internetowe opisuje standard RFC 3986. Dzieli on znaki na zwykłe i zarezerwowane. Zarezerwowane pełnią rolę separatorów: ? otwiera parametry, & je rozdziela, = łączy nazwę z wartością. Nawiasy kwadratowe też są na tej liście, podobnie jak + i przecinek.

Standard mówi wprost, że adresy różniące się tym, czy znak zarezerwowany jest zapisany wprost, czy zakodowany jako %XX, nie są równoważne. Programy nie mogą ich więc same „wyrównać”, bo zmieniłyby znaczenie adresu. Mueller pokazał to na prostym teście w JavaScripcie: obiekt URL dla obu zapisów daje różne wyniki, a porównanie zwraca false.

Jest jeszcze jeden szczegół, o którym wspomniał Mueller. Według RFC 3986 nawiasy kwadratowe mogą stać w adresie tylko w jednym miejscu: w nazwie serwera, wokół adresu IPv6 albo przyszłego formatu adresu IP przewidzianego w standardzie (IPvFuture). Zapis ?filter[]=123 jest więc formalnie niepoprawny. Mimo to w praktyce zwykle działa: Mueller zauważa, że sieć jest chaotyczna i nie wszystko w niej jest „technicznie poprawne”.

Dokumentacja Google o strukturze adresów mówi to samo językiem wytycznych: wyszukiwarka obsługuje adresy zgodne ze standardem IETF STD 66, który obejmuje RFC 3986, a znaki zarezerwowane muszą być zakodowane. Jako przykład niezalecanego adresu Google podaje parametry zapisane w nawiasach, w rodzaju ?[category:dresses][sort:price-low-to-high].

Skąd w sklepie biorą się dwie formy

Cztery popularne platformy w swoich standardowych filtrach nie używają nawiasów. Sprawdziliśmy to w dokumentacji i kodzie źródłowym:

Nawiasy pojawiają się tam, gdzie filtry są przekazywane jako tablice. Tak działają sklepy i aplikacje pisane na zamówienie, na przykład w Laravelu z popularnym pakietem do filtrowania, który używa zapisu ?filter[name]=. Standard JSON:API, używany w aplikacjach opartych na API, rezerwuje parametry filter[...] i page[...], na przykład filter[post]=1 i page[number]=2. Nawiasy mogą też dodać moduły filtrów innych firm, więc w każdym sklepie warto to sprawdzić na żywo.

Dwie formy pod jednym sklepem mogą powstać, gdy różne części serwisu budują adresy w różny sposób. Sprawdziliśmy to na typowych narzędziach:

• Formularz filtrów wysłany przez przeglądarkę koduje nawiasy: z pola filter[] powstaje filter%5B%5D=.
• Funkcje do kodowania parametrów, na przykład http_build_query() w PHP i urllib.parse.urlencode() w Pythonie, też kodują nawiasy.
• Obiekt URL w JavaScripcie zostawia nawiasy bez zmian, gdy parametry są doklejane jako tekst. Dopiero searchParams je koduje. Filtry przeładowywane skryptem mogą więc tworzyć linki z surowymi nawiasami.
• Adres wpisany ręcznie w szablon, na przykład w link „Pokaż czarne”, zostaje dokładnie taki, jak go wpisano.

Efekt to sytuacja z pytania Vanessy Fox: linki w jednej formie, canonical albo mapa witryny w drugiej.

Jedna forma wszędzie: co ujednolicić

Wybierz formę zakodowaną i sprawdź, czy każde z tych miejsc jej używa:

• Linki wewnętrzne: filtry, sortowanie, stronicowanie, okruszki, linki w opisach kategorii.
• Tag canonical: jeśli strona z filtrem ma być w Google, tag canonical wskazuje ją dokładnie w tym samym zapisie, co linki.
• Mapa witryny: adresy z filtrami, jeśli w ogóle je tam umieszczasz.
• Dane strukturalne: pola url w danych produktu, ofercie i okruszkach.
• Hreflang: Mueller go nie wymienił, ale to też adres, który Google porównuje z innymi, więc zasada jest ta sama.

Przykład spójnego tagu canonical dla strony z filtrem:

<link rel="canonical" href="https://example.com/buty/?filter%5B%5D=123">

Osobna sprawa to plik robots.txt. W otwartym kodzie parsera robots.txt Google reguła i adres są porównywane znak po znaku, a parser zamienia tylko znaki spoza ASCII i wielkość liter w kodach %XX. Standard robots.txt (RFC 9309) każe przed porównaniem zakodować znaki zarezerwowane, a dokumentacja Google odsyła do tej zasady. Nie pokazuje jednak przykładu z surowymi i zakodowanymi nawiasami. Jeśli blokujesz filtry, wpisz regułę dla obu form:

User-agent: *
Disallow: /*filter[
Disallow: /*filter%5B

Więcej o tym, jak robots.txt traktuje nietypowe znaki, piszemy w tekście o polskich znakach w pliku robots.txt.

Co zrobić w trzech typowych sytuacjach

Jak sprawdzić, które formy pobiera Google

Najpewniejszym źródłem są logi serwera. W domyślnym formacie logów nginx (combined) pole $request zapisuje adres w takiej postaci, w jakiej przyszło żądanie, więc od razu widać, czy Googlebot prosi o nawiasy, czy o kody. Przy własnym formacie logów sprawdź, czy zapisujesz $request albo $request_uri. Przykładowe polecenie dla programisty, dla logów w standardowym formacie:

grep "Googlebot" access.log | awk '{print $7}' | grep -iE '\[|%5B' | sort | uniq -c | sort -rn | head -50

Wynik to lista adresów z liczbą żądań. Jeśli ta sama kombinacja filtrów występuje w obu formach, Googlebot pobierał oba adresy. Sprawdź jeszcze kody odpowiedzi i daty żądań, bo polecenie liczy też przekierowania i błędy 404. Gdy oba adresy zwracają tę samą stronę, jedna forma zapisu może ograniczyć pobieranie duplikatów. Nazwę „Googlebot” w logach może podać każdy program, więc przed wnioskami sprawdź adresy IP według instrukcji Google o weryfikacji Googlebota.

W Google Search Console sprawdź trzy miejsca:

1. Sprawdzanie adresu URL: wklej obie formy tego samego adresu z filtrem. Narzędzie do sprawdzania adresów URL pokaże, czy Google zna każdą z nich i który adres wybrał jako kanoniczny.
2. Indeksowanie, Strony: przejrzyj przykłady przy statusach „Duplikat, użytkownik nie oznaczył strony kanonicznej” i „Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik”. Pary adresów różniące się tylko zapisem nawiasów to Twój przypadek. Co oznaczają statusy duplikatów i który wymaga działania, opisujemy osobno.
3. Ustawienia, Statystyki indeksowania: w przykładach pobranych adresów mogą pojawić się adresy z filtrami w obu formach. Lista jest tylko próbką, więc brak pary niczego nie dowodzi.

Przy wyszukiwaniu w eksportach z Search Console szukaj obu zapisów, z [ i z %5B. Nie znaleźliśmy w pomocy Google informacji, w której postaci raport pokazuje takie adresy.

Na koniec przejdź sklep programem do crawlowania, na przykład Screaming Frog, i sprawdź, czy ten sam filtr nie występuje w linkach w dwóch zapisach. To też dobry sposób, żeby sprawdzić radę Muellera o innych robotach: zobaczysz, jak dany program sam traktuje nawiasy.

Czego jeszcze nie wiadomo

Stan na 29 października 2026:

• Mueller nie powiedział, które roboty poza Google mogą mieć z tym problem. Nie wiadomo też, czy dotyczy to robotów wyszukiwarek AI.
• Google opisuje ogólne sygnały wyboru adresu kanonicznego, ale nie podał osobnej reguły dla konfliktu między surowymi a zakodowanymi nawiasami. Spójny zapis we wszystkich miejscach zwiększa szansę, że wybierze tę, którą wskazujesz.
• Angielska wersja dokumentacji Google o strukturze adresów ma datę aktualizacji 21 października 2026, dwa dni po wypowiedzi Muellera. Obecna wersja nadal każe kodować znaki zarezerwowane i podaje przykład z nawiasami, więc nic nie wskazuje, że zmiana dotyczyła nawiasów.

Jeśli Twój sklep ma tysiące adresów z filtrami i nie wiesz, które z nich Google pobiera, to zadanie na audyt SEO sklepu internetowego, z analizą logów.