Query string: parametry w adresie URL i przekierowania

Query string to część adresu URL od znaku ? do znaku # albo do końca adresu. Niesie dane dla strony — frazę z wyszukiwarki sklepu, kolejność sortowania, numer strony listy — i dla analityki: parametry UTM, identyfikator kliknięcia reklamy. W adresie https://sklep.example.pl/szukaj?q=kurtka&sort=cena query string to q=kurtka&sort=cena, czyli dwa parametry w adresie URL. Ogólną budowę adresu opisujemy w tekście o adresie URL. Tu idziemy głębiej: jak query string się koduje, co robią z nim różne języki programowania, co z niego zostaje po przekierowaniu i jak zachowuje się w krótkim linku. Wszystkie przypadki, które pokazujemy na figurach, zmierzyliśmy sami 21.10.2026 — na prawdziwym kodzie naszego skracacza, w dwóch przeglądarkach i na dziewięciu publicznych serwisach.

Query string — z czego się składa

Query string zaczyna pierwszy znak zapytania w adresie, a kończy krzyżyk albo koniec adresu. Tak definiuje to specyfikacja URI: „The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI” (RFC 3986, §3.4). Ta sama sekcja dopuszcza w środku ukośnik i kolejny znak zapytania jako zwykłe dane — więc ?powrot=/koszyk?krok=2 jest poprawnym adresem.

Format par klucz=wartość połączonych znakiem & nie jest wymogiem tej specyfikacji. RFC wspomina go tylko jako zwyczaj: query często niesie informacje „in the form of "key=value" pairs”. Format par opisuje dopiero WHATWG URL Standard, jako application/x-www-form-urlencoded — sposób zapisu „a list of tuples, each consisting of a name and a value” (WHATWG URL Standard). To format formularzy HTML, który z czasem stał się domyślnym sposobem pisania parametrów w każdym adresie. Google w wytycznych dla stron zaleca to samo: znak = między kluczem a wartością, & między parami, a kilka wartości jednego klucza — np. po przecinku (Google Search Central, struktura adresów).

W praktyce query string składa się z czterech rodzajów elementów:

• pary klucz=wartość — sort=cena;
• klucze powtórzone — tag=a&tag=b, czyli dwie wartości tego samego parametru;
• klucze bez wartości — flag albo flag=; dla wielu serwerów to dwie różne rzeczy;
• zakodowane znaki — %20, %2B, + — o nich w następnej sekcji.

Skąd nazwa „parametr GET”? Z formularzy. Formularz HTML wysłany metodą GET nie ma treści żądania — przeglądarka zamienia jego pola na pary nazwa–wartość i wstawia je w adres jako query string. Specyfikacja HTML opisuje ten krok jako „Mutate action URL”: pary trafiają do serializera application/x-www-form-urlencoded, a wynik ustawia jako query adresu formularza (HTML Living Standard, wysyłanie formularza). Słowo „ustawia” jest tu dosłowne: query string zapisany wcześniej w atrybucie action formularza GET zostaje zastąpiony polami formularza, a nie uzupełniony. Kto chce przenieść stały parametr przez wyszukiwarkę na stronie, dodaje go jako ukryte pole, nie w action.

Fragment po # nie jest częścią query stringu i nie trafia na serwer. Serwer dostaje ścieżkę i query string, a fragment zostaje w przeglądarce, która używa go do przewinięcia strony albo przekazuje skryptom. Dlatego parametr dopisany za krzyżykiem — …/kurtki#opinie?utm_source=mail — nigdy nie dotrze do serwera ani do analityki.

Kodowanie parametrów URL: spacja, plus i polskie znaki

W query stringu nie każdy znak może stać dosłownie. Znaki, które mają w adresie specjalne znaczenie (&, =, #, ?), oraz wszystko spoza podstawowego ASCII zapisuje się jako % i dwie cyfry szesnastkowe. Polska litera staje się kilkoma takimi grupami, bo przed zakodowaniem zamienia się ją na bajty UTF-8 — więc ą to %C4%85. Pełny opis kodowania procentowego i Punycode dla domen jest w tekście o adresie URL; tu zostańmy przy jednej pułapce, która psuje najwięcej parametrów: spacji i plusie.

Spację da się zapisać na dwa sposoby: %20 albo +. Plus jako spacja pochodzi z formatu formularzy. Parser opisany w WHATWG URL Standard robi to wprost: „Replace any 0x2B (+) in name and value with 0x20 (SP)” (WHATWG URL Standard, parsowanie). W drugą stronę jest tak samo — obiekt URLSearchParams w przeglądarce „will encode U+0020 SPACE as U+002B (+)” (WHATWG, URLSearchParams). Specyfikacja nie kryje, co o tym myśli: format application/x-www-form-urlencoded jest „in many ways an aberrant monstrosity”, wynikiem lat przypadków i kompromisów, a nie dobrych praktyk.

Skutek: jeśli w wartości ma być dosłowny plus, musisz go zakodować jako %2B. Inaczej parser zamieni go na spację. MDN ostrzega przed tym na przykładzie ciągów base64, które często zawierają +: „The URLSearchParams constructor interprets plus signs ( + ) as spaces, which might cause problems” (MDN, URLSearchParams). Podpis sig=ab+cd dotrze do skryptu jako ab cd i weryfikacja się nie powiedzie. Numer telefonu tel=+48600… straci plus. W naszym pomiarze n=1%2B1 każdy parser odczytał poprawnie jako 1+1 — bo plus był zakodowany.

Praktyczna reguła: query string składaj funkcją, która koduje za Ciebie — URLSearchParams w JavaScripcie, http_build_query w PHP, urlencode w Pythonie — a nie sklejaniem tekstu. Funkcja nie zapomni o & w nazwie produktu ani o plusie w numerze telefonu.

Powtórzone klucze i tablice

Ten sam query string różne serwery czytają różnie — i to nie jest teoria. Przepuściliśmy przez trzy parsery — Pythona w dwóch ustawieniach — jeden ciąg: q=a+b&q=c%20d&tag[]=x&tag[]=y&flag&n=1%2B1. Wynik pokazuje figura niżej.

Przy powtórzonym kluczu q obiekt URLSearchParams zwraca metodą get pierwszą wartość, a b — zgodnie ze specyfikacją, która każe zwrócić „the value of the first tuple whose name is name” (WHATWG, get). Wszystkie wartości daje dopiero getAll. PHP w parse_str (i w $_GET) zostawia ostatnią, c d. Python w parse_qs zwraca listę obu. Ten sam adres daje więc w trzech językach trzy różne odpowiedzi na pytanie „jaka jest wartość q”.

Nawiasy w nazwie to konwencja PHP: z tag[]=x&tag[]=y PHP robi tablicę o nazwie tag. Dla JavaScriptu i Pythona to po prostu klucz tag[] z nawiasami w nazwie. Klucz bez wartości, flag, URLSearchParams i PHP odczytują jako pusty tekst, a Python w parse_qs domyślnie go pomija — widać go dopiero z opcją keep_blank_values=True.

Jeśli projektujesz parametry własnej strony, unikniesz tych rozbieżności prostą regułą: jeden klucz występuje w adresie raz, a kilka wartości zapisujesz po przecinku — kolor=czarny,granatowy zamiast kolor=czarny&kolor=granatowy. Google podaje przecinek jako przykład znaku, który nie koliduje ze składnią adresu. Każdy parser odczyta wtedy jedną wartość, a podział na listę robisz sam, w jednym miejscu. Klucze bez wartości zastąp jawnym =1 albo =tak — flaga=1 każdy język czyta tak samo.

Dolna część figury pokazuje drugi problem: ponowny zapis. Każda biblioteka, która odczyta query string i zapisze go z powrotem, zrobi to po swojemu. URLSearchParams zamieni %20 na +, nawiasy na %5B%5D, a flag na flag=. PHP zgubi pierwszą wartość q i ponumeruje tablicę. Dla większości stron to bez znaczenia, ale adres podpisany kryptograficznie (np. link do pliku w chmurze z podpisem w parametrze) po takiej przeróbce przestaje działać. Jeśli Twój kod tylko dopisuje parametr, nie przebudowuj przy tym całego query stringu.

W JavaScripcie odczyt i budowa wyglądają tak:

Query string a przekierowanie: co przechodzi, a co ginie

Przy przekierowaniu przeglądarka sama przenosi fragment, ale nie query string. Parametry przeżyją tylko wtedy, gdy serwer, który przekierowuje, dopisze je do nagłówka Location. To najczęstsza przyczyna znikających UTM i identyfikatorów kliknięć: strona przenosi z http:// na https:// albo z adresu bez www na adres z www i po drodze gubi wszystko po znaku zapytania.

Reguła dla fragmentu jest zapisana w specyfikacji HTTP. Jeśli Location nie ma własnego fragmentu, przeglądarka „MUST process the redirection as if the value inherits the fragment component” — przekierowanie dziedziczy fragment pierwotnego adresu (RFC 9110, §10.2.2). O query stringu ta sekcja nie mówi nic takiego. Sprawdziliśmy to w Chromium 145 i Firefoksie 146: lokalny serwer odpowiadał 301 z /stara na /nowa, a przeglądarka otwierała /stara?utm_source=test#opinie.

Obie przeglądarki zachowały się tak samo: fragment przeszedł, parametry przepadły, chyba że serwer sam dopisał je do Location. Gdy Location ma własny fragment, wygrywa on.

Jak to wygląda na prawdziwych stronach? Otworzyliśmy dziewięć publicznych serwisów jako http://domena/?utm_source=dvn-test&gclid=test i szliśmy krok po kroku po przekierowaniach. W sześciu parametry dotarły do strony końcowej, w trzech zginęły — na onet.pl już przy pierwszym skoku na https://www., na wikipedia.org dopiero przy trzecim, a na europa.eu przy przekierowaniu na stronę wyboru języka. To pomiar z jednego dnia i jednego miejsca: serwisy zmieniają reguły, a część odpowiada inaczej przeglądarce niż programowi.

Sprawdzisz to sam bez narzędzi: wpisz adres swojej strony z dopisanym ?utm_source=test i zobacz, co stoi w pasku adresu, gdy strona się załaduje. Jeśli parametr zniknął, któryś skok go zgubił — ale pasek adresu nie powie który. Dokładniej pokaże to curl, który wypisze kod i nagłówek Location każdego skoku osobno:

Każda linia location: to jeden skok. Szukasz pierwszej, w której nie ma już utm_source=test — to reguła, którą trzeba poprawić. Najczęściej siedzi w konfiguracji serwera albo CDN (przekierowanie na https:// lub na www) i przepisuje adres na sztywno, bez części po znaku zapytania. Sprawdź też podstrony, nie tylko stronę główną: reklamy i kody QR rzadko prowadzą na stronę główną, a reguły dla ścieżek bywają inne niż dla domeny. Jeśli Twoja strona przekierowuje dopiero w JavaScripcie, curl tego nie zobaczy — wtedy zostaje pasek adresu przeglądarki.

Jak skonfigurować przekierowanie domeny tak, żeby przenosiło parametry, i czym różnią się kody 301, 302, 307 i 308, opisujemy w tekście o przekierowaniu 301. Co zgubiony parametr oznacza dla reklam Google, wyjaśnia tekst o gclid.

Parametry w krótkim linku — pomiar dziesięciu przypadków

Krótki link DVN Links domyślnie przekazuje query string kliknięcia na stronę docelową. Jeśli ktoś otworzy qrln.pl/promocja?utm_source=instagram, skracacz przekieruje go kodem 302 na adres celu z dopisanym utm_source=instagram. Działa to w każdym planie. W ustawieniach konta wybierasz, czy nowe linki mają przekazywać parametry, a w każdym linku możesz to zmienić — opcja nazywa się „Przekazuj parametry z linku (UTM, gclid) na stronę docelową”. Linki utworzone przed wprowadzeniem tej opcji też przekazują. Jak skracacz w ogóle działa i dlaczego używa 302, opisujemy w tekście o skracaniu linków.

Mechanikę zmierzyliśmy na funkcji, która w naszym kodzie wylicza adres przekierowania. Dziesięć przypadków, wynik na figurze:

Co z tego wynika:

• Przy tym samym kluczu wygrywa kliknięcie. Cel /promo?utm_source=druk otwarty z ?utm_source=ig daje utm_source=ig. Wartość z kliknięcia jest świeższa — mówi, skąd ten konkretny odwiedzający przyszedł.
• Pola UTM linku przegrywają z kliknięciem, ale zostają, gdy kliknięcie ich nie podaje. Link z polami utm_source=ulotka i utm_medium=print otwarty z ?utm_source=ig daje utm_source=ig&utm_medium=print. Pola UTM w szczegółach linku są w planach od Startera.
• Zapytanie celu zostaje bajt w bajt. ids=1,2&q=a%20b&flag wychodzi dokładnie tak samo, z gclid dopisanym na końcu — przecinek, %20 i klucz bez = nie są przepisywane. To ważne dla podpisanych adresów i serwerów, które odróżniają flag od flag=.
• Powtórzone klucze przechodzą w komplecie, a parametry trafiają przed #fragment celu.
• Parametry z kliknięcia są kodowane na nowo. ?q=kurtka+zimowa dociera jako q=kurtka%20zimowa — każdy serwer odczyta to jako spację. Jeśli w doklejanym parametrze ma być dosłowny plus, zakoduj go jako %2B.
• Trzy wyjątki, w których parametry kliknięcia nie przechodzą: wyłączone przekazywanie, link do pliku wgranego do DVN Links (plik i tak ich nie czyta) i wynik dłuższy niż 8 192 znaki. W tym ostatnim przypadku parametry odpadają po cichu, a przekierowanie działa — działający link jest ważniejszy niż komplet danych.

Przekazywanie obejmuje też smart linki: cele reguł (np. osobny adres dla iPhone'a) i warianty testu A/B dostają te same parametry. Gdy odwiedzający przechodzi przez naszą stronę pośrednią — przy linku chronionym hasłem albo przy linku konta Darmowego, które mocno przekroczyło miesięczny limit — parametry jadą razem z nim i trafiają na stronę docelową po potwierdzeniu.

Statystyki skracacza zapisują z kliknięcia tylko trzy parametry: utm_source, utm_medium i utm_campaign. utm_term, utm_content, gclid i inne przechodzą na stronę docelową, ale w panelu DVN Links ich nie zobaczysz — zobaczy je Twoja analityka. Przy wyłączonym przekazywaniu jest odwrotnie: UTM z kliknięcia trafią do statystyk skracacza, a do GA4 nie, więc oba widoki mogą się różnić. Wszystkie funkcje linków porównasz na stronie funkcji.

Parametry URL a Google i GA4

Same parametry nie szkodzą stronie w Google. Szkodzi ich nadmiar, bo każda kombinacja to osobny adres tej samej treści. Google pisze: „Overly complex URLs, especially those containing multiple parameters, can cause problems for crawlers by creating unnecessarily high numbers of URLs that point to identical or similar content on your site” (Google Search Central, struktura adresów). Typowe źródła to sortowanie i filtry w kategoriach — Google wymienia je wśród przyczyn duplikatów, dodając, że „Some duplicate content on a site is normal and it's not a violation of Google's spam policies” (Google Search Central, kanonizacja). Identyfikatory sesji radzi trzymać w ciasteczkach, nie w adresie. Odpowiedzią na duplikaty jest adres kanoniczny i mniej parametrów: „shorten URLs by trimming unnecessary parameters (meaning, parameters that don't change the content)”.

Jeśli trafisz na poradę „ustaw parametry w Search Console”, jest nieaktualna. Google wycofał narzędzie URL Parameters w 2022 roku i podał powód: „only about 1% of the parameter configurations currently specified in the URL Parameters tool are useful for crawling” (Google Search Central Blog, 28.03.2022). Od tego czasu robot uczy się parametrów sam: „you don't need to do anything to specify the function of URL parameters on your site”.

GA4 czyta z query stringu parametry kampanii. Lista z pomocy Google obejmuje utm_id, utm_source, utm_medium, utm_campaign, utm_source_platform, utm_term, utm_content, utm_creative_format i utm_marketing_tactic — dwóch ostatnich GA4 na razie nie pokazuje w raportach; kolejność w adresie jest dowolna, a wartości rozróżniają wielkość liter — utm_source=google to co innego niż utm_source=Google (pomoc GA4). Co znaczy każdy z nich i jak nazywać kampanie, opisujemy w tekście o parametrach UTM; spójne wartości złożysz w kreatorze UTM, który buduje query string parserem, a nie sklejaniem tekstu.

Mniej znany limit: adres strony, który tag GA4 wysyła jako page_location, może mieć najwyżej 1 000 znaków — „the page_location parameters must be 1,000 characters or fewer” (pomoc GA4, limity zbierania danych). Limit dotyczy zbierania danych tagiem i SDK; żądania serwer–serwer mają inne zasady. Długi query string z kilkoma identyfikatorami kliknięć, UTM i filtrami może ten limit przekroczyć. Jeśli w raportach widzisz obcięte adresy, sprawdź najpierw długość parametrów.

Czego nie wkładać do query stringu

Query string widzi więcej osób i programów, niż się wydaje — dlatego nie wkładaj do niego haseł, tokenów, numerów dokumentów ani adresów e-mail. OWASP opisuje to jako osobną klasę podatności: dane w parametrach adresu trafiają „in browser history, server logs, and third-party monitoring tools”, a „Simply using HTTPS does not resolve this” (OWASP, Information exposure through query strings). HTTPS szyfruje adres w drodze, ale nie w historii przeglądarki ani w logach serwera, który go odbiera. Z tego samego powodu klucz API wysyła się w nagłówku, a nie w adresie — piszemy o tym w tekście o kluczu API.

Jedna rzecz działa na Twoją korzyść: nagłówek Referer. Domyślna polityka przeglądarek, strict-origin-when-cross-origin, przy przejściu na inną domenę wysyła tylko domenę strony, bez ścieżki i query stringu (MDN, Referrer-Policy). Strona może tę politykę zmienić nagłówkiem albo znacznikiem <meta>, więc to zabezpieczenie domyślne, nie gwarantowane.

Przy krótkim linku jest jeszcze jedna rzecz do przemyślenia. Przekazywanie parametrów przenosi każdy parametr, który ktoś dopisze do Twojego krótkiego adresu — także taki, którego się nie spodziewasz. Jeśli link prowadzi do aplikacji albo panelu, który na podstawie parametrów coś robi (np. ustawia adres powrotu po logowaniu), wyłącz przekazywanie w tym jednym linku. Do kampanii marketingowych zostaw je włączone. Więcej o ocenie linków przed kliknięciem przeczytasz w tekście o tym, jak sprawdzić, czy link jest bezpieczny.

Najczęstsze pytania o query string

Dopisujesz UTM do krótkich linków w bio, w SMS-ie albo w kodzie QR? Załóż konto i sprawdź na własnym linku z dopisanym ?utm_source=test, co dociera na stronę docelową. Sam query string z parametrami UTM złożysz bez konta w kreatorze UTM.