Parametry w URL a SEO: jak nie zduplikować treści w React, Next.js i Astro?

Jeśli chcesz, żeby ktoś po prostu znalazł te problemy w Twoim kodzie i je naprawił, to zakres mojej usługi Audyt techniczny SEO.

Czym jest parametr w URL — anatomia

Parametr URL (inaczej query string) to dodatkowe dane doklejone na końcu adresu, które mówią serwerowi lub aplikacji, co ma zrobić. Najczęściej dotyczy to zmiany wyświetlanej treści albo zmierzenia czegoś.

https://example.com/products?category=shoes&sort=price-asc
└───────────┬──────────────┘ └───────────┬───────────────┘
        base URL                      query string

Składowe powyższego adresu:

• base URL — https://example.com/products, czyli kanoniczny adres przed jakąkolwiek modyfikacją.
• znak zapytania ? — separator, który oznacza koniec ścieżki i początek query string, w tej roli może wystąpić tylko raz.
• pary klucz-wartość — category=shoes, gdzie category to klucz, a shoes wartość. Łączy je znak =.
• ampersand & — łączy kolejne pary. Twardego limitu nie ma, ale im jest krócej tym lepiej.

Osobny przypadek to fragment (#), np. #sekcja. Tradycyjnie serwer go ignoruje, a przeglądarka używa do przewinięcia do kotwicy. Część frameworków JavaScript używała kiedyś # do nawigacji (hash-based routing), co dla SEO było i jest rozwiązaniem złym. Zapamiętaj różnicę: ? wysyła dane do serwera, # działa po stronie klienta.

Parametry aktywne vs pasywne

Dawne narzędzie URL Parameters w Search Console zostało wycofane, dlatego dziś zasady trzeba wymusić we własnej architekturze, linkowaniu i odpowiedziach HTTP.

• Aktywne (zmieniające treść) — modyfikują to, co widzi użytkownik: sortowanie (?sort=price-asc), filtrowanie (?color=blue), paginacja (?page=2), wyszukiwarka wewnętrzna (?q=...), język (?lang=fr).
• Pasywne (śledzące) — nie zmieniają treści, tylko zbierają dane: UTM-y (?utm_source=newsletter), ID sesji (?sessionid=...), ID afiliacyjne (?affid=...).

Reguła kciuka:

• pasywne zwykle tworzą duplikaty — najczęściej powinny prowadzić do czystego canonicala i nie pojawiać się w linkowaniu wewnętrznym,
• aktywne wymagają decyzji: ?sort= to praktycznie duplikat (canonical do bazy), ale ?lang=fr to osobna, indeksowalna wersja strony, a ?category=running-shoes może być wartościowym landingiem, który chcesz indeksować. Potraktowanie tych ostatnich jak zwykłych duplikatów to poważny błąd.

Typy parametrów i ich obsługa

Szczególnie groźna jest nawigacja fasetowa w e-commerce, czyli kilkanaście filtrów po kilka wartości każdy potrafi wygenerować miliony kombinacji URL-i. To główne źródło problemów z budżetem indeksowania w dużych sklepach internetowych. Trzeba tego pilnować.

Parametr językowy wymaga osobnej ostrożności. Każda wersja językowa powinna mieć własny canonical w tym samym języku oraz wzajemne adnotacje hreflang; canonical wszystkich wersji do języka głównego usuwa je z rywalizacji o właściwe rynki. Parametry są technicznie możliwe, ale ścieżki takie jak /pl/ i /en/ zwykle upraszczają linkowanie, sitemap oraz debugowanie. Poprawną relację canonical–hreflang rozkładam na czynniki w osobnych przewodnikach: dla hreflang i canonical w Next.js oraz dla wielojęzyczności i hreflang w Astro.

Jak parametry URL szkodzą SEO — duplikacja treści i budżet indeksowania

Wyszukiwarka traktuje każdy unikalny URL jako osobną stronę z czego wynikają cztery zagrożenia.

Duplikacja treści. /, /?sort=price, /?color=red, /?sessionid=xyz to dla bota cztery strony z tą samą treścią, co skutkuje kanibalizacją słów kluczowych, indeksacją zaśmieconych adresów zamiast czystych i rozproszeniem sygnałów rankingowych.

Marnowanie budżetu indeksowania. Googlebot ma ograniczony budżet na crawlowanie strony, dlatego jeśli wypala go na nieskończonych kombinacjach filtrów, może nigdy nie dotrzeć do nowych produktów czy kluczowych landingów. Im większy serwis, tym bardziej jest zagrożony tym zjawiskiem.

Rozwodnienie link equity. Jeśli jedne źródła linkują do /dresses?color=red, a inne do /dresses?size=m, moc linków rozkłada się na warianty zamiast wzmacniać jedną kanoniczną stronę.

UX i CTR. Długie, „maszynowe" adresy (/products.php?cat=2&id=815) wyglądają na mniej wiarygodne (spamerskie), gorzej się je udostępnia czy klika niż czytelne i jasne np /buty/czerwone-trampki.

Widoczność w systemach AI. Oprócz Googlebota stronę mogą odwiedzać boty odpowiadające za wyszukiwanie w produktach AI, trening modeli lub pojedyncze żądania użytkowników. Przykładowo OpenAI rozróżnia OAI-SearchBot, GPTBot i ChatGPT-User, a każdy z nich ma inny cel. Nie należy więc zakładać jednego, wspólnego sposobu renderowania JavaScriptu dla wszystkich systemów. Praktyczna zasada pozostaje jednak bezpieczna: treść, którą chcesz indeksować lub cytować, powinna być dostępna w odpowiedzi HTML bez obowiązkowej interakcji użytkownika. To bezpośrednio łączy temat parametrów z audytem renderowania i indeksacji.

Parametry URL w React, Next.js i Astro a renderowanie

W aplikacjach JavaScript o losie parametrów decyduje architektura renderowania i w tej części, chce więcej opowiedzieć na ten temat.

Czysty React (SPA, CSR)

W Single Page Application zmiana filtra zwykle nie przeładowuje strony, ponieważ JavaScript przechwytuje akcję i podmienia treść przez History API. Możemy chwalić to rozwiązanie ze względu na UX, ale jest to ryzykownie dla SEO. Jeśli przefiltrowana treść powstaje wyłącznie po stronie klienta, bot, który nie wykona JS, zobaczy pustą lub niekompletną stronę. To problem architektoniczny na który sam canonical nie pomoże i najczęściej wymaga przejścia na renderowanie serwerowe.

Next.js App Router — pułapka searchParams

W Next.js (App Router) parametry zapytania trafiają do strony przez prop searchParams. Od Next.js 15 jest on asynchroniczny (Promise) i trzeba go await-ować w komponentach serwerowych:

// app/produkty/page.tsx — Next.js 15+
type Props = {
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>
}
 
export default async function ProduktyPage({ searchParams }: Props) {
  const { color, sort } = await searchParams
  // ...renderowanie zależne od parametrów
}

Najważniejsza rzecz dla SEO i wydajności to samo sięgnięcie po searchParams w komponencie strony wybija całą trasę z generowania statycznego (SSG) i wymusza renderowanie dynamiczne przy każdym żądaniu. To zachowanie celowe, kiedy query string jest zależnością request-time, więc Next.js nie może prerenderować strony na etapie builda. To samo dotyczy cookies(), headers() i draftMode().

Konsekwencja: bezmyślne czytanie searchParams na stronie głównej kategorii potrafi zamienić statyczną stronę w dynamiczną i zmienić model cache oraz koszt obsługi żądań. Nie oznacza to automatycznie złego TTFB, ale wymaga świadomej architektury. Rozwiązaniem jest separacja tras: trzymaj statyczny, indeksowalny widok bazowy osobno, a logikę zależną od filtrów wydziel (np. do osobnego segmentu, komponentu klienckiego z useSearchParams albo route handlera), tak by główny widok mógł zostać statyczny.

// Wariant kliencki — nie wybija trasy z SSG,
// ale treść zależna od filtra powstaje po stronie klienta
'use client'
import { useSearchParams } from 'next/navigation'
 
export function FilterControls() {
  const params = useSearchParams()
  const color = params.get('color')
  // sterowanie UI filtra
}

Wybór między wariantem serwerowym a klienckim to świadomy kompromis: serwerowy umieszcza treść w początkowym HTML-u bez wymagania JavaScriptu, ale jest dynamiczny; kliencki zachowuje statyczny shell, lecz treść zależna od parametru będzie niedostępna dla botów nierenderujących JS. Dla widoków, które mają rankować, prawie zawsze wygrywa wariant serwerowy. To rozwinięcie szerszej zasady, którą opisuję w tekście o tym, kiedy Next.js naprawdę daje przewagę SEO nad zwykłym Reactem.

Astro

W Astro o wszystkim decyduje tryb renderowania trasy. Domyślnie strony są prerenderowane (statyczne) i Astro.url.searchParams na etapie builda jest puste. Żeby reagować na parametry w czasie żądania, trasa musi działać w trybie serwerowym:

---
// src/pages/produkty.astro
export const prerender = false // tryb on-demand (SSR)
const color = Astro.url.searchParams.get('color')
---

Samo prerender = false nie wystarczy w projekcie bez środowiska wykonawczego. Build musi korzystać z adaptera, np. Cloudflare, Netlify, Node lub Vercel. Alternatywnie cały projekt może działać z output: 'server'; wtedy trasy są domyślnie renderowane na żądanie, a statyczne wyjątki oznaczasz przez prerender = true.

To ta sama zasada co w Next.js, gdzie treść zależna od parametru wymaga renderowania w czasie żądania, jeśli ma być widoczna dla wyszukiwarek bez wykonywania JS.

Canonical w Astro ustawiasz bezpośrednio w layoucie lub w elemencie <head> komponentu. Framework nie ma odpowiednika generateMetadata, więc konsolidacja sygnałów dla sparametryzowanych widoków wymaga ręcznego wyznaczenia czystego URL:

---
// src/pages/produkty.astro
export const prerender = false
const color = Astro.url.searchParams.get('color')
const canonicalUrl = new URL('/produkty', Astro.site).toString()
---
<head>
  <link rel="canonical" href={canonicalUrl} />
</head>

Jeśli sparametryzowany widok ma być indeksowany jako samodzielna strona (np. /produkty?category=buty), canonical powinien wskazywać na siebie. Wtedy przekaż Astro.url.href po wyczyszczeniu śledzących parametrów, a wartościowe filtry rozważ zamiast tego jako osobne trasy statyczne (src/pages/produkty/[kategoria].astro).

Canonical, robots.txt, noindex i redirect — kiedy używać którego

Po zdiagnozowaniu parametrów dobiera się narzędzie do celu. Zanim sięgniesz po tabelę właściwości, warto przejść przez ścieżkę decyzji:

Z kolei tabela poniżej zestawia te narzędzia po właściwościach — blokowaniu crawla, efekcie indeksacyjnym i konsolidacji sygnałów:

Canonical przez Metadata API (Next.js)

Dla pasywnych parametrów i sortowania ustaw canonical na czysty URL — to konsoliduje sygnały z ?utm= i ?sort=:

// app/produkty/page.tsx
import type { Metadata } from 'next'
 
export async function generateMetadata(): Promise<Metadata> {
  return {
    alternates: {
      canonical: 'https://example.com/produkty', // czysty, bez parametrów
    },
  }
}

Pamiętaj też, że canonical to silna wskazówka, ale nie jest rozkazem dla Google. Jego celem jest porządkowanie indeksu, a sam Google i tak może odwiedzić niekanoniczny URL, więc canonical nie oszczędza budżetu indeksowania.

Nie kopiuj jednak tego przykładu bezwarunkowo na każdą stronę, ponieważ paginacja powinna zachować ?page=2, a indeksowalny filtr — własny URL. W praktyce generator canonicala powinien usuwać wyłącznie parametry śledzące i sortujące, zachowując te, które definiują unikalną, indeksowalną treść.

const TRACKING_PARAMS = new Set([
  'utm_source',
  'utm_medium',
  'utm_campaign',
  'gclid',
  'fbclid',
])
 
export function getCanonicalUrl(input: URL) {
  const canonical = new URL(input)
 
  for (const key of [...canonical.searchParams.keys()]) {
    if (TRACKING_PARAMS.has(key)) canonical.searchParams.delete(key)
  }
 
  canonical.searchParams.sort()
  canonical.hash = ''
  return canonical.toString()
}

Ten helper nie decyduje, czy color=red ma być indeksowane. Taka decyzja musi wynikać z mapy typów stron i intencji wyszukiwania.

robots.txt / robots.ts (Next.js)

Najskuteczniejsze narzędzie do oszczędzania budżetu indeksowania jest robots.txt:

// app/robots.ts
import type { MetadataRoute } from 'next'
 
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/szukaj', '/*?sessionid=', '/*&sessionid='],
    },
    sitemap: 'https://example.com/sitemap.xml',
  }
}

Uważaj, by nie blokować plików .js/.css (uniemożliwisz wtedy renderowanie) i nie łącz Disallow z noindex na tej samej stronie. Jeśli zablokujesz crawl, bot nigdy nie zobaczy noindex i strona może zostać w indeksie. Wybierz jedno albo drugie.

Wzorce dla query stringów trzeba testować na prawdziwych URL-ach. Parametr może wystąpić jako pierwszy po ? albo kolejny po &, dlatego jedna reguła często nie obejmuje obu przypadków. Jeszcze lepiej najpierw znormalizować kolejność parametrów i ograniczyć ich generowanie, zamiast próbować naprawić cały graf samym plikiem robots.txt.

Statyczne URL przez redirecty (Next.js)

Dla wartościowych filtrów lepsze od parametrów są czyste, statyczne ścieżki — przyjaźniejsze użytkownikowi i SEO:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // stary URL → czysty, trwały redirect (308 w Next.js)
      {
        source: '/produkty',
        has: [{ type: 'query', key: 'category', value: 'buty' }],
        destination: '/produkty/buty',
        permanent: true,
      },
    ]
  },
}

To podejście ma sens, gdy przefiltrowany widok („męskie buty do biegania") ma na tyle unikalną treść i potencjał wyszukiwawczy, że chcesz go indeksować jako samodzielną stronę.

Nie zastępuj redirectu przez rewrite, jeśli celem jest zmiana adresu widocznego dla użytkownika i wyszukiwarki. Rewrite może serwować zawartość /produkty/buty pod adresem /produkty?category=buty, ale nie przenosi przeglądarki i sam nie konsoliduje sygnałów. Jest narzędziem routingu, nie canonicalizacji.

Normalizacja parametrów — jeden stan i jeden URL

Najpierw aplikacja musi przestać generować wiele adresów opisujących dokładnie ten sam stan, a dopiero potem myślimy o canonicalu.

/produkty?color=red&size=m
/produkty?size=m&color=red
/produkty?color=RED&size=m
/produkty?color=red&size=m&utm_source=mail
/produkty?color=red&size=m&color=red

Warstwa normalizacji powinna:

• Przyjmować tylko znane klucze i dozwolone wartości.
• Usuwać puste, domyślne i powtórzone parametry.
• Normalizować wielkość liter oraz format wartości.
• Generować parametry zawsze w tej samej kolejności.
• Oddzielać parametry treściowe od śledzących.
• Odrzucać kombinacje, których aplikacja nie obsługuje.

Jeśli wariant jest jednoznacznie tym samym zasobem, serwer może przekierować go kodem 308 do wersji znormalizowanej. Jeśli parametr jest nieznany albo prowadzi do nieistniejącego stanu, nie należy bezrefleksyjnie zwracać pustej strony z kodem 200. Zależnie od intencji lepsze będzie 404, kontrolowany widok noindex albo przekierowanie do rzeczywistego odpowiednika.

Nawigacja fasetowa w e-commerce a budżet indeksowania

Najtrudniejszy przypadek nie zaczyna się przy jednym filtrze, tylko przy ich kombinacjach. Dziesięć atrybutów po dziesięć wartości daje potencjalnie miliardy stanów, zanim doliczysz sortowanie, paginację i kolejność parametrów. Googlebot musi najpierw odwiedzić URL, żeby ocenić jego przydatność, więc niekontrolowany graf filtrów spowalnia odkrywanie właściwych stron i obciąża serwer.

Dojrzała architektura rozdziela trzy klasy widoków:

Nie ma jednej reguły Disallow, która poprawnie rozpozna wartość biznesową kombinacji. Lista indeksowalnych landingów powinna być jawna i ograniczona, a interfejs filtrów nie może generować linków do każdego matematycznie możliwego stanu. W dużym e-commerce dochodzi jeszcze kontrola głębokości, liczby aktywnych filtrów oraz parametrów zależnych — np. rozmiar nie powinien generować URL-i dla kategorii, w której nie występuje. Sama implementacja takiego interfejsu filtrów po stronie aplikacji — z searchParams, debounce i synchronizacją stanu z URL — to osobny temat, który rozwijam w artykule o wyszukiwarce z filtrami w Next.js.

Odkrywanie URL-i przez crawlera — linkowanie i sitemap

Google zwykle znajduje kolejne strony przez href elementu <a>, a nie przez kliknięcie przycisku uruchamiającego JavaScript i dlatego właśnie paginacja i indeksowalne filtry muszą mieć prawdziwe, serwerowo renderowane linki.

Zasady są spójne w całym serwisie:

• linkowanie wewnętrzne prowadzi do wersji kanonicznych i nie dokleja UTM-ów,
• sitemap zawiera tylko adresy kanoniczne, zwracające 200 i przeznaczone do indeksacji,
• parametry sortowania, sesji i kampanii nie trafiają do sitemap,
• indeksowalne landingi są osiągalne z kategorii lub innych stron tematycznych,
• przycisk „pokaż więcej” i infinite scroll mają równoległą sekwencję crawlable URL-i.

Samą generację poprawnej sitemap — tylko z adresami kanonicznymi i bez parametrów śledzących — automatyzujesz po stronie frameworka. Pokazuję to w praktyce dla sitemap i robots.txt w Next.js oraz dla dynamicznej sitemap w Astro.

Paginacja a SEO — canonical i linkowanie w 2026

Dwa fakty, które dezaktualizują wiele starszych poradników:

1. Google nie używa już rel="next"/rel="prev" do łączenia serii paginowanych (oficjalnie od 2019). Możesz je zostawić dla dostępności, ale nie licz na efekt SEO.
2. Narzędzie URL Parameters w Google Search Console zostało wycofane (2022). Dziś obsługą parametrów sterujesz wyłącznie po swojej stronie: canonical, robots.txt, noindex, struktura linków.

Dla paginacji rekomendacja jest prosta: każda strona serii powinna mieć samoreferencyjny canonical (/kategoria?page=2 → canonical do /kategoria?page=2). Częsty błąd to ustawianie canonicala wszystkich stron na stronę 1 — wtedy mówisz Google, że strony 2, 3, 4 to duplikaty, i treść z głębszych stron (oraz linkowane z nich produkty) może nigdy nie zostać odkryta.

Canonical to jednak tylko część wdrożenia. Każda strona musi mieć unikalny URL, link <a href> prowadzący co najmniej do następnej strony oraz możliwość powrotu do początku kolekcji. Infinite scroll może zostać jako warstwa UX, ale nie może być jedyną drogą do dalszych elementów, ponieważ crawler nie wykonuje gestu przewijania ani nie klika przycisku „więcej”. Stronę implementacyjną — wybór między offsetem, cursorem a stanem w URL przez searchParams — rozkładam na czynniki w artykule o paginacji w Next.js.

Trzeba też określić zachowanie brzegowe:

• ?page=1 przekieruj do czystego URL-a kategorii,
• ?page=0, wartości tekstowe i liczby ujemne normalizuj lub odrzucaj,
• strona wykraczająca poza ostatnią stronę nie powinna zwracać pustego 200,
• zmiana sortowania nie może przypadkowo zmieniać canonicala paginacji na stronę 1,
• filtry aktywne na stronie 2 muszą być zachowane w linkach kolejnych stron, jeśli tworzą jeden spójny widok.

Najczęstsze błędy w obsłudze parametrów URL

Parametry dla stron nawigacyjnych — ?page_id=2 zamiast /o-nas/. Statyczne strony powinny mieć czyste URL-e z wyraźnymi, przyjaznymi użytkownikowi słowami kluczowymi (friendly urls).

Niespójne linkowanie wewnętrzne — menu linkuje do /dresses, a baner do /dresses?sort=newest. Zawsze linkuj wewnętrznie do czystej, kanonicznej wersji.

Konflikt robots.txt + noindex — opisany wyżej; bot nie zobaczy noindex, jeśli wcześniej zablokujesz crawl.

Globalny canonical na paginacji — patrz sekcja o paginacji.

Nieskończone przestrzenie URL — np. możliwość dodania tego samego filtra wielokrotnie (?color=red&color=blue&color=red...). To pułapka na crawlery i musisz ograniczyć poprzez logikę serwerową i wzorce parametrów w robots.txt.

Ignorowanie kolejności parametrów — ?color=blue&size=m i ?size=m&color=blue to dla bota dwa różne URL-e. Musisz wymusić spójną, deterministyczną kolejność generowania parametrów.

Puste wyniki z kodem 200 — kombinacja filtrów nie zwraca produktów, ale nadal generuje indeksowalną stronę z tytułem kategorii. Przy dużej liczbie kombinacji powstają tysiące thin pages. Nieistniejący stan powinien mieć jawnie zaprojektowaną odpowiedź, zamiast dziedziczyć metadata strony bazowej.

Niespójne sygnały — canonical wskazuje czysty URL, sitemap zawiera wariant z parametrem, a linkowanie wewnętrzne prowadzi do jeszcze innej wersji - jednym słowem, jest bałagan. Google dostaje trzy konkurencyjne wskazówki i może wybrać canonical inny od deklarowanego.

Fragmentacja cache — CDN lub warstwa aplikacyjna traktuje każdą kolejność parametrów jako osobny klucz cache. Nawet gdy HTML jest identyczny, rośnie liczba missów, czas odpowiedzi i koszt infrastruktury. Normalizacja musi działać przed generowaniem klucza cache, a nie dopiero w tagu canonical.

Błędy specyficzne dla JS:

• czytanie searchParams na stronie, która powinna być statyczna → niezamierzona utrata SSG i gorszy performance,
• kluczowa treść filtrów wyłącznie po stronie klienta → zależna od możliwości wykonania JavaScriptu przez konkretnego crawlera,
• canonical/metadane zależne od parametru wstrzykiwane po stronie klienta zamiast renderowane serwerowo.

Co powinien wykazać audyt parametrów URL

Sama lista adresów z ? nie jest audytem. Wynikiem powinna być mapa reguł łącząca semantykę parametrów, zachowanie aplikacji i decyzję indeksacyjną. Do jej zbudowania potrzebne są cztery źródła danych:

• Crawler pokazuje wzorce generowane przez linkowanie i liczbę osiągalnych kombinacji.
• Google Search Console pokazuje URL-e znalezione przez Google, wybrany canonical i problemy z indeksacją.
• Logi serwera ujawniają faktyczne zachowanie Googlebota, częstotliwość wejść i kombinacje pochłaniające zasoby. Jak czytać te dane na poziomie crawlowania, pokazuję na przykładzie logów Cloudflare i budżetu indeksowania.
• Analityka i dane biznesowe odróżniają filtry używane i konwertujące od technicznego szumu.

Rezultatem nie powinien być PDF z ogólnym „dodaj canonical”. Potrzebna jest macierz: wzorzec URL → status HTTP → robots → canonical → obecność w sitemap → zasady linkowania → renderowanie → właściciel reguły w kodzie. Dopiero na tej podstawie można bezpiecznie zmienić robots.ts, Metadata API, routing i komponent filtrów. Pisałem o tym szerzej: audyt SEO to nie lista TODO, tylko pull requesty.

Kryteria odbioru wdrożenia obsługi parametrów

Zmiana jest zakończona dopiero wtedy, gdy zachowanie zgadza się w kodzie, renderowanym HTML-u i logach. Kryteria odbioru powinny obejmować:

1. Każdy wspierany wzorzec zwraca oczekiwany status HTTP.
2. Canonical jest absolutny, stabilny i zgodny z sitemap oraz linkowaniem.
3. Widoki noindex pozostają dostępne dla crawlera, który ma odczytać dyrektywę.
4. Zablokowane wzorce nie są jednocześnie promowane w linkach i sitemap.
5. Paginacja jest osiągalna przez linki bez wykonywania interakcji.
6. Normalizacja nie usuwa parametrów potrzebnych do działania produktu lub atrybucji.
7. Logi po wdrożeniu pokazują spadek wejść w bezwartościowe kombinacje bez utraty crawlowania ważnych landingów.

Te reguły warto zabezpieczyć testami regresji dla reprezentatywnych typów stron, a nie tysiącami snapshotów pojedynczych URL-i. Przykład takiej warstwy opisuję w artykule o automatycznych testach regresji SEO w CI/CD.

Strategia obsługi parametrów: e-commerce vs mała strona

Nie ma jednego idealnego ustawienia, a strategia zależy przede wszystkim od kontekstu, skali oraz celów.

• Duży sklep e-commerce — priorytet to kontrola grafu URL-i i zasobów serwera. Ograniczaj odkrywanie parametrów niskiej wartości, a wybrane wzorce blokuj w robots.txt tylko wtedy, gdy nie potrzebujesz na nich dyrektywy noindex. Wartościowe filtry zamieniaj na statyczne, indeksowalne URL-e i pilnuj deterministycznej kolejności parametrów.
• Mniejsza strona firmowa / usługowa — budżet indeksowania rzadko jest problemem, dlatego skup się na konsolidacji link equity przez canonical i na czystej strukturze URL. Najczęściej wystarczy kilka reguł.

Jednej rzeczy unikaj i mam tu na myśli globalnego Disallow: /*?*. To wyjątkowo tępawe narzędzie. Potrafi zablokować wartościowe, sparametryzowane landingi i wersje językowe, a do tego odcina Google od canonical/noindex na tych stronach. Prawie zawsze lepsze jest podejście celowane.

Jak podchodzę do tego w StriveLab

Parametry URL to dla mnie część szerszego audytu technicznego SEO, bo w aplikacjach Next.js, React i Astro ich obsługa zazębia się z renderowaniem, indeksacją i Core Web Vitals. Mój układ pracy:

• diagnoza — crawler + GSC + logi + GA4, żeby oddzielić parametry wartościowe od śmieci,
• decyzja per typ — co kanonizować, co blokować, co zamienić na statyczny URL, a co indeksować jako landingi,
• wdrożenie w kodzie — canonical przez Metadata API, robots.ts, redirects/rewrites, separacja tras pod SSG — wprost w repozytorium, nie jako lista TODO,
• pomiar przed i po — indeksacja w GSC, crawl w logach, performance po zmianach.