Filtry, wyszukiwarka i sitemapa: co Google powiedział latem 2026 o crawlowaniu sklepu

Sklep z kilkoma tysiącami produktów ma w Search Console setki tysięcy adresów. Różnica bierze się z filtrów, sortowań, paginacji i wyszukiwarki wewnętrznej, a jej objawem jest rosnący wiersz „Strona zeskanowana, ale jeszcze niezindeksowana". Przez lata traktowałem to jako problem techniczny. Dziś patrzę na to jak operator: to problem decyzyjny. Które adresy chcę pokazywać Google'owi, a które istnieją tylko dla klienta, który klika. Latem 2026 zespół Search Relations powiedział na ten temat więcej niż przez poprzednie dwa lata razem; zbieram to w decyzje, nie w przewodnik.

Ile adresów Google naprawdę chce

Zacznę od odczarowania liczby. Google pisze w dokumentacji raportu indeksowania, żeby nie oczekiwać, że każdy adres w serwisie zostanie zindeksowany. W odcinku Search Off the Record z 16 lipca Martin Splitt i John Mueller dodali, że nie ma żadnej magicznej proporcji zindeksowanych do niezindeksowanych, a dokumentacja samego Google'a ma ogromną część adresów poza indeksem z wyboru. Rada: szukać wzorców, nie liczyć inwentarza. I jeden wzorzec, na który uczulają: zabezpieczenia antybotowe, które serwują Googlebotowi ekran wyzwania z kodem 200.

Druga liczba do odczarowania to crawl budget. Przewodnik Google mówi wprost, kogo dotyczy: serwisów od miliona unikalnych stron zmienianych mniej więcej co tydzień albo od 10 tys. stron zmienianych codziennie, oraz tych, które mają dużo adresów w stanie „Strona wykryta, ale jeszcze niezindeksowana". Sklep z cenami i stanami aktualizowanymi codziennie na kilkunastu tysiącach kart mieści się w tej drugiej grupie. Ale to nie znaczy, że problemem jest budżet. Problemem jest to, na co go wydajesz.

Wyszukiwarka wewnętrzna: co Google radzi

Odcinek z 30 lipca jest w całości o stronach wyników Twojej własnej wyszukiwarki. Streszczam stanowisko Muellera w kolejności decyzji.

Dlaczego to problem: ktoś może podlinkować wynik dla dowolnego słowa, a jeśli do tego dołożysz sortowania i filtry, Google widzi nieskończoną liczbę adresów. Strony wyszukiwarki zwykle nie są cache'owane, więc każde wejście robota to zapytanie do bazy i przeliczenie rankingu. Google próbuje takie przestrzenie rozpoznawać i obniżać im priorytet, ale, jak przyznał Mueller, nie informuje o tym w Search Console, a rozpoznanie może zająć czas.

Co robić: dwie drogi. Pierwsza to robots.txt z jedną szeroką regułą, na przykład blokadą wszystkiego, co zaczyna się od ścieżki wyszukiwania z parametrem. Mueller nazwał ją najłatwiejszą i zalecił jedną regułę zamiast labiryntu wyjątków. Druga to noindex w nagłówku albo meta tagu: czystsza, bo zablokowany w robots.txt adres teoretycznie może pojawić się w wynikach, ale Google i tak wejdzie na stronę, zanim zobaczy noindex.

Czego nie robić: narzędzie usuwania w Search Console tylko ukrywa adresy w wynikach, crawlu nie zatrzymuje. Kod 404 dla stron wyszukiwania jest „nieczysty" z powodu cache'owania. A kod 500 jest zakazany: Google odczyta go jako przeciążenie serwera i zmniejszy crawl całej domeny, łącznie z kartami produktów.

Dwie rzeczy warte uwagi. Po pierwsze, Google nie traktuje zindeksowanych stron wyszukiwarki jako spamu, tylko jako nieefektywność; dawniej było to w wytycznych dla webmasterów, dziś już nie. Po drugie, jest z tym realne ryzyko: jeśli strona wyników powtarza wpisaną frazę w nagłówku i jest indeksowalna, ktoś może masowo podlinkować Twoją wyszukiwarkę z frazami o lekach albo kasynach i numerem telefonu, a Twoja domena zacznie rankować na te frazy. Google widuje to w skali tysięcy stron i bywa, że oznacza serwis jako zhakowany. Blokada w robots.txt „domyślnie, od początku" zamyka temat.

W praktyce: w PrestaShop szukaj adresów z parametrem kontrolera wyszukiwania, w WooCommerce parametru s, w Magento ścieżki catalogsearch. Sprawdź własne logi, bo wtyczki zmieniają domyślne wzorce. I ostatnia rada z odcinka, która dla sklepu jest najważniejsza: jeśli używasz wyników wyszukiwania jako zastępnika stron kategorii, zbuduj prawdziwe kategorie. Dają kontekst, hierarchię i możliwość napisania, dlaczego ten zestaw produktów jest razem.

Filtry i sortowania: lista decyzji

Opieram tę listę na dokumentacji nawigacji fasetowej, która porządkuje opcje według kosztu crawlu: robots.txt jest najoszczędniejszy; fragmenty w adresie (po znaku #) Google w ogóle nie crawluje; canonical zmniejsza crawl wersji niekanonicznych dopiero z czasem; nofollow działa tylko, gdy jest na każdym linku do filtra. A przewodnik o crawl budget dodaje, że noindex nie oszczędza crawlu: Google pobiera stronę, a potem ją odrzuca.

• Sortowania, widoki listy, liczba produktów na stronie, parametry dodania do koszyka: robots.txt.
• Kombinacje dwóch i więcej filtrów: robots.txt albo fragmenty w adresie. Wyjątek: kombinacja, na którą masz udokumentowany popyt w Search Console, dostaje własny adres jako podkategoria.
• Pojedynczy filtr z popytem i odrębnym asortymentem (marka w kategorii, pojemność, kolor): zostaje w indeksie, ale na warunkach Google'a: stały porządek parametrów, standardowy separator &, własny tytuł i opis, a przy pustym wyniku kod 404, nie strona „brak produktów" z kodem 200.
• Warianty tego samego produktu (kolor, pojemność) bez osobnych wyszukiwań: canonical na produkt główny.
• Paginacja kategorii: zostaje, z self-canonical na każdej stronie.
• Strony wyszukiwarki: robots.txt, jedna reguła.

Jedno ostrzeżenie do zmian canonical. Przewodnik o rozwiązywaniu problemów z kanonikalizacją, zaktualizowany 10 lipca, mówi, że nawet po naprawie Google może trzymać strony w klastrze duplikatów do dwóch tygodni, a szybciej rozdziela je wtedy, gdy różnica w treści jest wyraźna. Zmiany rób partiami i nie oceniaj po trzech dniach.

Sitemapa: prawdziwy lastmod zamiast sztuczek

Dokumentacja sitemap jest w tej sprawie bezlitosna. Google używa wartości lastmod tylko wtedy, gdy jest konsekwentnie i weryfikowalnie prawdziwa, na przykład przez porównanie z faktyczną datą zmiany strony. Za istotną zmianę uznaje modyfikację głównej treści, danych strukturalnych lub linków; zmiana roku w stopce nią nie jest. priority i changefreq ignoruje. Limit to 50 tys. adresów albo 50 MB na plik.

Na tym tle Search Engine Journal opisał 2 września technikę, w której do adresów doklejany jest codziennie zmieniany parametr ze znacznikiem czasu, żeby Google traktował je jak nowe. Mueller odpowiedział na Bluesky, że to zły pomysł, bo sygnalizuje, że kanoniczny adres treści ma się ciągle zmieniać, a to szkodzi i wyszukiwarce, i Twojej analityce. Dodał odsyłacz do klasycznego tekstu „Cool URIs don't change". Ta sama logika obala „lastmod równy dacie wygenerowania sitemapy": jeśli każdy adres ma dziś datę dzisiejszą, Google przestaje wierzyć wszystkim.

Decyzje dla sklepu: lastmod liczysz z pola aktualizacji produktu w bazie, ustawianego tylko przy zmianie ceny, dostępności, opisu, zdjęć lub danych strukturalnych. Cena i stan są główną treścią karty produktu, więc ich zmiana jest istotna, a codzienny przelot cron, który nic nie zmienił, nie jest. Sitemapy dzielisz na produkty, kategorie i treści, i wpisujesz do nich wyłącznie adresy kanoniczne i indeksowalne. Adres z filtra w sitemapie i jednocześnie zablokowany w robots.txt to sprzeczny sygnał, który sam sobie wysyłasz.

Soft 404, których nie widzi żaden crawler

Historia, którą opisał Jakub Sawa 14 sierpnia, dotyczy każdego sklepu na frameworku JavaScript. Serwis z dziesiątkami tysięcy adresów znikał z indeksu, choć każda strona zwracała 200 i wyglądała poprawnie w Screaming Frogu. Google pobiera HTML, a renderuje później; między jednym a drugim na serwerze wchodził nowy deploy, który usuwał poprzednie wersje plików JavaScript i CSS z hashami w nazwach. W momencie renderowania zasoby zwracały 404, strona renderowała się pusta i Google klasyfikował ją jako soft 404. Crawler sprawdza stronę w jednej chwili, więc nie miał szans tego zobaczyć; diagnoza wyszła z logów serwera zestawionych z kalendarzem wdrożeń. Widoczność spadła niemal do zera poza stroną główną i frazami brandowymi, a po naprawie wróciła.

Przewodnik o crawl budget dopowiada, dlaczego to boli podwójnie: strony soft 404 są dalej crawlowane i marnują budżet. U siebie sprawdzam to dwoma sposobami: po każdym deployu biorę kilka kart produktów do narzędzia inspekcji adresu w Search Console i patrzę na wyrenderowany HTML, nie na kod odpowiedzi, a poprzednie wersje zasobów zostawiam na serwerze przez kilkanaście dni.

Co zrobić w najbliższym tygodniu

1. Wyeksportuj z raportu indeksowania próbkę adresów ze stanów „zeskanowana, ale niezindeksowana" i „wykryta, ale niezindeksowana" i pogrupuj po wzorcach: wyszukiwarka, filtry, sortowania, warianty, paginacja.
2. Dodaj do robots.txt jedną szeroką regułę dla stron wyszukiwarki i sprawdź w testerze, czy nie blokuje kategorii.
3. Przejdź listę decyzji z tego tekstu i przy każdym wzorcu adresów wpisz: robots.txt, fragment, canonical albo zostaje.
4. Sprawdź, jak generowany jest lastmod: jeśli równa się dacie budowania sitemapy, zmień źródło na pole aktualizacji produktu.
5. Usuń z sitemap adresy niekanoniczne i zablokowane w robots.txt.
6. Po najbliższym deployu sprawdź pięć kart produktów w inspekcji adresu, patrząc na wyrenderowany HTML.
7. Przejrzyj logi serwera pod kątem kodów 500 i 429 zwracanych Googlebotowi oraz ekranów zabezpieczeń z kodem 200.

Google powtórzył latem to, co mówił od lat, tylko wyraźniej: nie chce Twoich wszystkich adresów, chce tych, które mają sens dla człowieka. Sklep, który potrafi to rozróżnić w robots.txt i sitemapie, nie potrzebuje sztuczek. Jeśli chcesz, żebyśmy przejrzeli wzorce adresów w Twoim sklepie i ułożyli tę listę razem, porozmawiajmy.