Regex w SEO - praktyczne zastosowania wyrażeń regularnych

Regex, czyli wyrażenie regularne (ang. regular expression), to wzorzec opisujący zbiór ciągów znaków. Zamiast szukać jednej frazy, opisujesz regułę – a narzędzie samo wyłapuje wszystko, co do niej pasuje. W SEO oznacza to jedno: zamiast ręcznie przeklikiwać tysiące zapytań czy adresów URL, jednym wzorcem segmentujesz całe raporty w kilka sekund.

Największy zysk pojawia się przy dużych zbiorach danych. Sklep z 8 000 adresów URL, blog z 600 wpisami, konto z 40 000 zapytań miesięcznie w Search Console – tutaj ręczna analiza jest po prostu niewykonalna. Regex pozwala wyciągnąć dokładnie te wiersze, które Cię interesują: frazy pytające, adresy bez ukośnika na końcu, URL-e z polskimi znakami, zapytania sprzedażowe.

Wyrażenia regularne działają niemal wszędzie tam, gdzie pracujesz z tekstem: Google Search Console, GA4, Looker Studio, Screaming Frog, Google Sheets, pliki .htaccess i konfiguracje serwera nginx. Składnia jest w 90% wspólna, więc raz nauczone podstawy przenoszą się między narzędziami. To dlatego regex jest jedną z niewielu umiejętności technicznych, która zwraca się praktycznie od pierwszego użycia.

Do 90% zadań SEO wystarczy garstka znaków. Nie musisz znać całej składni PCRE ani lookbehindów – większe znaczenie ma zrozumienie, jak łączyć kilka prostych klocków w precyzyjny wzorzec.

Poniższa tabela zbiera symbole, które realnie wykorzystasz w codziennej pracy z danymi:

Reszta to już tylko składanie tych elementów. Wzorzec `^(jak|co|dlaczego)\s` znaczy dosłownie: zacznij od słowa pytającego, po którym występuje spacja. Im więcej takich zdań przeczytasz na głos, tym szybciej regex przestanie wyglądać jak szum.

Google Search Console to miejsce, w którym regex daje największy zwrot dla SEO. Filtr włączysz tak: raport Skuteczność, klikasz Nowy, wybierasz Zapytanie lub Strona, a w liście typu dopasowania zaznaczasz Niestandardowe (wyrażenie regularne). Możesz wybrać tryb Filtruj (pokaż pasujące) lub Wyklucz (ukryj pasujące).

Ważna informacja techniczna: GSC korzysta z silnika RE2 firmy Google. RE2 jest szybki i bezpieczny, ale celowo nie obsługuje lookbehindu ani backreferencji. Większość realnych wzorców SEO i tak ich nie potrzebuje, ale jeśli skopiujesz gotowca z internetu i nie zadziała – najczęściej właśnie o to chodzi.

Poniższa tabela to gotowy zestaw filtrów, który możesz wklejać wprost do GSC:

Największy efekt daje łączenie filtrów. Najpierw zawęź strony do `^/blog/`, a potem na tym samym widoku dołożysz filtr zapytań `(cena|cennik)` – w ten sposób sprawdzasz, czy artykuły blogowe nie łapią przypadkiem ruchu transakcyjnego, który powinien trafiać na strony ofertowe. To jeden z najszybszych sposobów na wykrycie kanibalizacji.

W GA4 wyrażenia regularne pojawiają się tam, gdzie definiujesz warunki: w Eksploracjach (sekcja Filtry), w budowaniu odbiorców (audiences), w definicjach zdarzeń kluczowych oraz w filtrach danych. Najczęściej używasz ich do segmentacji ruchu po ścieżce strony (parametr `page_path`) albo po źródle kampanii.

Kilka praktycznych warunków, które sprawdzają się w raportach:

• `^/(kategoria|produkt)/` – cały ruch w obrębie ścieżek kategorii lub produktów
• `[?&]utm_source=` – sesje z oznaczeniem UTM (przydatne do weryfikacji tagowania)
• `^/(koszyk|zamowienie|dziekujemy)` – etapy lejka zakupowego w jednym segmencie

W Looker Studio (dawny Data Studio) regex działa dwojako. Po pierwsze, jako warunek w filtrach – te same wzorce co w GA4. Po drugie, jako funkcje obliczeniowe w polach niestandardowych: REGEXP_MATCH zwraca prawdę lub fałsz, REGEXP_EXTRACT wyciąga fragment tekstu, a REGEXP_REPLACE podmienia ciąg. Dzięki temu z surowego page_path zbudujesz czytelny wymiar Typ strony (blog, kategoria, produkt) i pogrupujesz po nim cały raport.

Jedna uwaga o wydajności: regex jest wolniejszy niż dopasowania typu zaczyna się od czy zawiera. Dla prostych przypadków używaj wbudowanych filtrów, a po regex sięgaj wtedy, gdy faktycznie potrzebujesz logiki wzorca. Niezależnie od narzędzia każdy wzorzec sprawdź najpierw na regex101.com – wybierz odpowiedni wariant składni (Go/RE2 dla GSC, PCRE dla większości narzędzi).

Screaming Frog to crawler, w którym regex zamienia surowe skanowanie w celowaną analizę. Pierwsze zastosowanie to sterowanie zakresem crawla: w Configuration > Include podajesz wzorce adresów do skanowania, a w Configuration > Exclude – te do pominięcia. Na dużym sklepie pozwala to wyciąć z crawla niekończące się warianty filtrów (`.*\?color=.*`) i skupić budżet na realnych podstronach.

Drugie, mocniejsze zastosowanie to Custom Extraction (Configuration > Custom > Extraction). Tutaj regexem wyciągasz dowolny fragment kodu strony podczas skanowania – cenę, status dostępności, obecność konkretnego skryptu czy danych strukturalnych. Przykład ekstrakcji ceny ze znacznika span z klasą price wygląda tak: `class=.price.>([0-9,.]+)\s*zl` – grupa w nawiasie zwraca samą liczbę.

W audytach technicznych regex najczęściej służy do wykrywania wzorców błędów, które giną w surowych danych. Oto zestaw, który wykorzystujemy w praktyce:

Trailing slash to klasyczny przykład informacyjnego niuansu. Filtr `[^/]$` znajdzie adresy bez ukośnika na końcu – jeśli część URL ma slash, a część nie, generujesz duplikaty i niepotrzebne przekierowania 301, które rozpraszają sygnały i marnują budżet indeksowania. To jeden z tych błędów, które łatwo przeoczyć przy 5 000 adresów, a regex wyciąga go w sekundę.

Tutaj ważne rozróżnienie, które rzadko pada wprost w poradnikach. Robots.txt NIE obsługuje pełnego regexa – Google wspiera w nim wyłącznie dwa znaki wieloznaczne: gwiazdkę (dowolny ciąg znaków) oraz znak dolara (koniec adresu URL). Nie zadziała tam ani `[0-9]`, ani alternatywa, ani grupowanie. Próbowanie pełnego regexa w robots.txt to częsty błąd, który cicho nie działa.

Poprawne reguły w robots.txt wyglądają tak: `Disallow: /*?sort=` blokuje każdy adres zawierający parametr sort, a `Disallow: /*.pdf$` blokuje wszystkie pliki PDF.

Przekierowania to zupełnie inna historia. W pliku .htaccess (serwer Apache) działają pełne wyrażenia regularne z grupami przechwytującymi. Klasyczny wzorzec migracji adresów to `RewriteRule ^stara-sciezka/(.*)$ /nowa-sciezka/$1 [R=301,L]`. Grupa `(.*)` przechwytuje końcówkę adresu, a `$1` wstawia ją w docelowym URL – dzięki temu jedna reguła obsługuje setki podstron naraz, zachowując ich nazwy. Na serwerze nginx logika jest ta sama, zmienia się tylko składnia dyrektywy (`rewrite ^/stara-sciezka/(.*)$ /nowa-sciezka/$1 permanent;`).

Przy przekierowaniach masowych regex jest niezastąpiony, ale też najgroźniejszy: zbyt szeroki wzorzec potrafi przekierować pół serwisu w pętlę. Dlatego każdą regułę testuj na próbce adresów, zanim wdrożysz ją na produkcji – najlepiej z mapą starych i nowych URL pod ręką.

Większość problemów z regexem nie wynika ze skomplikowanej składni, tylko z kilku powtarzalnych pułapek. Znajomość ich z góry oszczędza godziny zgadywania, dlaczego wzorzec łapie za dużo albo za mało.

• Zbyt szeroki wzorzec. `.*cena.*` dopasuje również ocena, pocena, scenariusz. Jeśli zależy Ci na samym słowie, dodaj granice albo uszczegółów kontekst. Zaczynaj wąsko, rozszerzaj po testach.
• Niezaeskejpowana kropka. Znak `.` to dowolny znak, więc `plik.pdf` dopasuje też plikXpdf. Aby szukać dosłownej kropki, pisz `\.` – stąd `\.pdf$`, a nie `.pdf$`.
• Mylenie gwiazdki z plusem. Gwiazdka dopuszcza zero powtórzeń, więc `a*` pasuje nawet do pustego miejsca. Gdy element ma wystąpić co najmniej raz, użyj `+`.
• Ignorowanie wielkości liter. Domyślnie regex rozróżnia wielkość znaków, więc blog nie złapie Blog. W GSC obejdziesz to klasą `[Bb]log`, bo RE2 w panelu nie przyjmuje flagi ignorowania wielkości w każdym kontekście.
• Lookbehind w GSC. RE2 go nie obsługuje – wzorce z `(?<=...)` po prostu nie zadziałają, mimo że są poprawne w innych narzędziach.

Reguła nadrzędna brzmi: testuj przed wdrożeniem. Wklej wzorzec i próbkę danych do regex101.com, sprawdź, co dokładnie zostaje podświetlone, dopiero potem przenieś go do GSC, GA4 czy .htaccess. Minuta testu ratuje przed błędną analizą opartą na wzorcu, który cicho łapał nie to, co trzeba.

W naszych audytach SEO regex najczęściej ratuje nas w dwóch sytuacjach. Pierwsza to porządkowanie zapytań w Search Console na dużych kontach – filtr `.+\s.+\s.+` na frazy minimum trzywyrazowe niemal zawsze odsłania pulę long-taili z realnymi wyświetleniami, które klient miał na pozycjach 8-15 i o których nie wiedział. To gotowy backlog tematów, bez zgadywania.

Druga sytuacja to higiena techniczna przy migracjach i audytach struktury. Filtr `[^/]$` na listę adresów regularnie wyciąga grupy URL bez trailing slash, które generują niepotrzebne przekierowania, a wzorzec na polskie znaki w slugach wyłapuje adresy, które w wynikach wyświetlają się jako brzydkie kody procentowe. To detale, ale przy kilku tysiącach podstron składają się na zauważalny chaos sygnałów.

Nasza rada dla osób, które dopiero zaczynają: nie ucz się regexa z teorii. Weź własne konto GSC, wklej trzy wzorce z tabel powyżej i zobacz, co pokażą na Twoich danych. Po godzinie takiej zabawy składnia przestaje być abstrakcją, a zaczyna być narzędziem pracy. A jeśli wolisz, by analiza i wdrożenie wniosków spoczęły na specjalistach, sprawdź naszą ofertę pozycjonowanie SEO lub napisz po bezpłatną konsultację.