robots.txt w PrestaShop: dlaczego znikają Twoje wpisy i co powinno w nim być

Ktoś kiedyś dopisał do tego pliku kilka reguł — zablokował testową kopię sklepu, dodał parametry filtrów, wskazał mapę strony. Po kilku miesiącach zaglądasz tam i po tych wpisach nie ma śladu. Nikt ich nie usuwał, nikt nawet nie pamięta, żeby cokolwiek zmieniał.

Odpowiedź jest prostsza, niż się wydaje: PrestaShop generuje ten plik samodzielnie i przy każdym generowaniu kasuje całą dotychczasową zawartość, pisząc ją od nowa. Dokumentacja producenta mówi to wprost — kliknięcie przycisku zastępuje istniejący plik nowym — a część z tych generowań dzieje się przy okazji zupełnie innych prac, więc nikt nie kojarzy jednego z drugim.

W skrócie: ten plik mówi automatom — wyszukiwarkom i asystentom AI — gdzie w Twoim sklepie mogą wchodzić. PrestaShop tworzy go sam przy instalacji sklepu, przy dodaniu lub zmianie języka oraz za każdym razem, gdy ktoś kliknie przycisk generowania w panelu — a każde z tych generowań zastępuje plik nowym. Domyślna zawartość jest całkiem sensowna i pokrywa cztery obszary, od których zaczyna się każdy audyt tego pliku. Własne wpisy trzeba dopisywać poniżej i trzymać ich kopię poza sklepem, bo prędzej czy później znikną. Najkosztowniejszym błędem nie jest przy tym brak reguły, tylko zablokowanie czegoś, co zablokowane być nie powinno.

W tym tekście: co dokładnie generuje PrestaShop i w jakich momentach, co zawiera wersja domyślna, czego nie wolno zablokować, co warto dopisać w sklepie oraz jak sprawdzić u siebie, na czym stoisz.

Co robi ten plik, a czego nie robi

robots.txt to zwykły plik tekstowy w głównym katalogu domeny, w którym zapisane jest, gdzie automaty mają wstęp. Zagląda do niego wyszukiwarka, zanim zacznie odwiedzać Twoje strony, i robią to również automaty dostawców AI — choć, jak się zaraz okaże, nie wszystkie i nie zawsze.

Dwie rzeczy, których ten plik nie robi, choć powszechnie mu się je przypisuje. Po pierwsze, nie ukrywa treści — reguła w nim zapisana jest prośbą skierowaną do automatu, a nie zabezpieczeniem, co zresztą odnotowuje sama dokumentacja PrestaShopa, zaznaczając, że najgorsze automaty jej nie respektują. To, co ma być naprawdę niedostępne, musi stać za logowaniem. Po drugie, nie usuwa stron z wyników wyszukiwania: Google pisze wprost, że do tego służy znacznik noindex albo hasło, a zablokowany adres potrafi utrzymać się w wynikach, jeśli prowadzą do niego odnośniki z innych witryn — tyle że bez opisu, bo robot nie mógł go przeczytać.

Warto zapamiętać to rozróżnienie, bo wraca przy każdym pytaniu o ten plik: dostęp to nie to samo co indeksowanie.

Kiedy plik powstaje od nowa

Pierwszym momentem jest instalacja sklepu: plik powstaje przy jego stawianiu, zanim ktokolwiek zajrzy do ustawień, i dlatego praktycznie każdy sklep na PrestaShopie jakiś plik ma, nawet jeśli nikt go świadomie nie tworzył. Drugim jest przycisk generowania na stronie z parametrami sklepu, w sekcji ruchu i SEO — jedyna ścieżka, na której administrator wie, co robi.

Trzeci jest najbardziej podstępny, bo nikomu nie kojarzy się z tym plikiem: dodanie albo zmiana języka sklepu. PrestaShop wprowadził to celowo i logika jest tu bez zarzutu — blokady zawierają przedrostki językowe, więc po dodaniu nowego języka plik musi powstać na nowo, żeby je uwzględnić. Skutek uboczny jest jednak taki, że ktoś uruchamia w poniedziałek nową wersję językową sklepu, a w środę okazuje się, że z pliku zniknęły wpisy dopisane pół roku wcześniej przez zupełnie inną osobę.

Na forum producenta wracają zresztą zgłoszenia w rodzaju „plik został dziś rano nadpisany, a nikt go nie ruszał” — z odpowiedzią, że ręczne zmiany wprowadzone bezpośrednio w pliku zawsze prędzej czy później zostaną nadpisane. To nie jest usterka, tylko sposób działania platformy.

Za każdym razem generator buduje zawartość od zera i w żadnym momencie nie odczytuje tego, co było wcześniej, więc nie ma mowy o scalaniu ani zachowywaniu cudzych reguł. Dokumentacja producenta mówi o tym jednym zdaniem — kliknięcie przycisku zastępuje istniejący plik nowym — i z tego wyprowadza jedyne zalecenie w sprawie własnych wpisów: dopisuj je po wygenerowaniu. Jest przy tym szczegół istotny przy większych wdrożeniach: generator może uruchomić mechanizm pozwalający modułom dopisać własne reguły, ale robi to wyłącznie przy wywołaniu z przycisku, więc moduł, który miał dokładać swoje wpisy, przy pozostałych ścieżkach w ogóle się nie odezwie, a plik i tak powstanie na nowo.

Co zawiera wersja domyślna

Dokumentacja PrestaShopa nie podaje zawartości domyślnej — opisuje przycisk i skutek jego kliknięcia, ale nie listę reguł. Poniższe wynika z kodu producenta, w wersjach PrestaShop 8 i PrestaShop 9, między którymi różnice są zresztą drobne.

Generator wypisuje około dwudziestu katalogów technicznych zablokowanych do wejścia: z kodem aplikacji, konfiguracją, pamięcią podręczną, tłumaczeniami, dziennikami, plikami tymczasowymi, bibliotekami zewnętrznymi i usługą sieciową. Dokłada do tego kilkadziesiąt adresów stron funkcyjnych — koszyk, konto klienta, dane osobowe, adresy, logowanie, rejestracja, historia zamówień, potwierdzenie zamówienia, śledzenie przesyłki, wyszukiwarka, stronicowanie, sortowanie, resetowanie hasła i faktury w wersji do druku. Co istotne, adresy te budowane są z ustawień Twojego sklepu, więc mają Twoje przyjazne nazwy, a przy sklepie wielojęzycznym każda wersja językowa dostaje własny zestaw wpisów z odpowiednim przedrostkiem.

Trzecią grupą jest kilkadziesiąt blokad adresów z parametrami: sortowanie, tagi, waluta, stronicowanie, wyszukiwanie i powrót do poprzedniej strony, w każdym wariancie zapisu. Na końcu stoi zaś grupa, która wygląda na sprzeczność, a jest najważniejsza z całego pliku — zezwolenia na pliki stylów, skryptów i obrazów leżące w katalogu modułów, mimo że sam katalog modułów jest wyżej zablokowany. Dlaczego akurat to jest ważne, wyjaśniamy w następnej sekcji.

Do tego dochodzi wiersz wskazujący mapę strony, ale z pewnym haczykiem: PrestaShop dopisuje go tylko wtedy, gdy w głównym katalogu sklepu leży plik o nazwie dokładnie sitemap.xml. Jeśli mapę generuje moduł zapisujący ją pod inną nazwą — a tak robi część popularnych rozwiązań — wiersza po prostu nie będzie i trzeba dopisać go samodzielnie.

Wszystkie reguły zapisane są w jednej grupie dla wszystkich automatów, bez podziału na roboty. Jak na wersję domyślną jest to konfiguracja całkiem dobra: pokrywa wyszukiwanie wewnętrzne, koszyk, konto klienta i adresy z parametrami, czyli cztery obszary, od których zaczyna się każdy sensowny audyt tego pliku w sklepie. Kłopot nie leży w tym, co tam jest, tylko w tym, że nikt tego właścicielowi sklepu nie opisał ani nie powiedział, co z tym zrobić dalej.

Czego nie wolno zablokować

Najkosztowniejszy błąd w tym pliku nie polega na tym, że czegoś brakuje, tylko na zablokowaniu czegoś, co zablokowane być nie powinno — i jest to błąd popełniany zwykle w dobrej wierze, przy porządkowaniu.

Google pisze o plikach odpowiadających za wygląd strony — obrazach, skryptach i arkuszach stylów — że blokować wolno wyłącznie te nieistotne, czyli takie, bez których strona nie zmienia się w sposób znaczący. Odwrotna strona tego zdania jest ostrzejsza: jeżeli brak zasobu utrudnia robotowi zrozumienie strony, blokować go nie należy. Do tego dochodzi zasada dotycząca przetwarzania skryptów, mówiąca wprost, że Google nie wykonuje skryptów pobranych z zablokowanych plików ani na zablokowanych stronach.

Dla sklepu na PrestaShopie oznacza to rzecz bardzo konkretną. Domyślna konfiguracja blokuje katalog modułów, a zaraz potem zezwala na leżące w nim style, skrypty i obrazy — i te zezwolenia są tam po coś, bo motyw i moduły trzymają w tym katalogu pliki potrzebne do wyświetlenia karty produktu. Ktoś, kto uzna je za zbędne i „posprząta” plik, odetnie robotowi widok własnego sklepu, nie zmieniając ani jednej linijki na stronie.

Praktyczna zasada brzmi więc: przy tym pliku dodawaj z rozmysłem, a usuwaj wyłącznie wtedy, gdy wiesz, po co dana reguła tam stoi.

Automaty AI: jedna decyzja, nie jedna reguła

Domyślna konfiguracja traktuje wszystkie automaty jednakowo i dla robotów wyszukiwarek jest to w porządku. Przestaje być, gdy w grę wchodzą automaty dostawców AI, bo one nie są jednym bytem i różne ich rodzaje robią zupełnie różne rzeczy.

Rzecz, którą trzeba znać, zanim ktokolwiek dopisze tu regułę: u tego samego dostawcy jeden automat zbiera treści do trenowania modeli, a zupełnie inny odpowiada za to, czy Twoja strona może w ogóle pojawić się w wynikach wyszukiwania wewnątrz jego asystenta. Dokumentacja mówi o tym drugim wprost — witryny, które się z niego wypisały, nie będą pokazywane w odpowiedziach. Zablokowanie obu naraz jest więc decyzją biznesową o wycofaniu się z widoczności, a nie techniczną higieną, i zapada zwykle jednym wpisem, w dobrej wierze, po tym jak ktoś usłyszał, że „AI kradnie treści”. Warto przy tym wiedzieć, że blokada automatów treningowych też ma swoją cenę: model przestaje wiedzieć cokolwiek o Twojej marce, gdy odpowiada bez szukania w sieci, a przy niektórych wpisach — jak token sterujący Google — oznacza wprost rezygnację z cytowań w asystencie tego dostawcy. Rozkładamy to na części w osobnym tekście: które boty AI odwiedzają sklep i co z nimi zrobić.

Warto też wiedzieć, że sami dostawcy odradzają twardsze metody — na przykład blokowanie automatów na poziomie serwera, zanim w ogóle dotrą do strony. Brzmi to skuteczniej, a w praktyce działa przeciwnie do zamierzeń: automat nie ma wtedy jak przeczytać Twoich reguł, więc nie może się do nich zastosować. Jeśli ktoś proponuje Ci takie rozwiązanie, warto zapytać, co konkretnie ma dzięki niemu zniknąć.

Tutaj wystarczy zasada: nie dopisuj blokad automatów AI, zanim nie sprawdzisz, który z nich za co odpowiada.

Jeśli nie masz pewności, co stoi dziś w Twoim pliku, prześlij nam adres sklepu — w darmowym raporcie GEO sprawdzamy między innymi to, czy asystenci mają w ogóle dostęp do Twoich stron.

Co warto dopisać w sklepie

Od tego miejsca robi się technicznie. Jeśli zmiany w tym pliku wykonuje u Ciebie ktoś inny, przejdź do listy kontrolnej — a tutaj wróć wtedy, gdy będziesz chciał sprawdzić, co dostałeś.

Wersja domyślna jest dobrym punktem wyjścia, ale nie wie nic o Twoim sklepie. Cztery rzeczy, które zwykle trzeba dołożyć, oczywiście tylko te, które w Twoim wypadku w ogóle istnieją.

Własne parametry filtrowania. Domyślna lista pokrywa parametry samej platformy. Jeśli korzystasz z nawigacji fasetowej, modułu filtrów albo dokleiłeś własne parametry do adresów kategorii, każdy z nich mnoży liczbę adresów prowadzących do tej samej treści — i to jest najczęstsza przyczyna, dla której sklep na tej platformie ma w indeksie wielokrotnie więcej adresów, niż ma produktów.

Parametry śledzenia z kampanii. Adresy z oznaczeniami kampanii prowadzą do tych samych stron, więc nie muszą być odwiedzane osobno.

Katalogi robocze spoza wydania — kopie sklepu, katalogi testowe, wypakowane paczki, stare wersje motywu. Jeśli leżą w głównym katalogu domeny, są publicznie dostępne i bywają odwiedzane.

Wskazanie mapy strony, jeśli generator go nie dopisał — czyli w każdym sklepie, w którym mapa nie nazywa się dokładnie sitemap.xml. To nie jest reguła dostępu, tylko wiersz informacyjny, ale jego miejsce jest właśnie tutaj.

Tak wygląda przykładowy blok własnych wpisów dla przykładowego sklepu z narzędziami ogrodowymi — dopisywany pod treścią wygenerowaną przez platformę, nigdy zamiast niej:

# --- wpisy własne, dopisane po wygenerowaniu przez PrestaShop ---
# ostatnie sprawdzenie: 2026-09-17

Disallow: /*?filtr_marka= Disallow: /*&filtr_marka= Disallow: /*?filtr_srednica= Disallow: /*&filtr_srednica= Disallow: /*?utm_ Disallow: /*&utm_ Disallow: /kopia-2025/ Disallow: /stary-motyw/

Sitemap: https://sklep-ogrodowy.example/sitemap.xml # --- koniec wpisów własnych ---

Komentarze z datą sprawdzenia są tu celowe: za pół roku to jedyna rzecz, która powie, czy ten blok jest aktualny, czy przeszedł przez trzy zmiany w sklepie i nikt go nie ruszył.

Jak zrobić, żeby własne wpisy przetrwały

Skoro generator kasuje całą zawartość i uruchamia się także bez Twojej wiedzy, samo dopisanie reguł nie wystarczy. W praktyce sprawdzają się trzy podejścia, przy czym pierwsze jest obowiązkowe niezależnie od reszty.

Trzymaj kopię swojego bloku poza sklepem — w dokumentacji wdrożenia, w repozytorium, gdziekolwiek poza plikiem, który może zniknąć. Odtworzenie zajmuje wtedy minutę zamiast godziny przypominania sobie, co tam było.

Sprawdzaj plik po każdej zmianie w językach, po zmianie adresu i po każdej większej aktualizacji. Wejście na adres sklepu z dopiskiem /robots.txt zajmuje dziesięć sekund i jest jedyną metodą, która wyłapuje ciche nadpisanie.

Rozważ moduł dopisujący reguły automatycznie, jeśli plik zmienia się u Ciebie często. Pamiętaj tylko o ograniczeniu opisanym wyżej: mechanizm ten działa wyłącznie przy generowaniu z przycisku, więc po instalacji i po zapisie adresu sklepu i tak trzeba sprawdzić plik ręcznie.

Pytanie, które pada w tym miejscu zawsze: czy nie prościej odebrać platformie możliwość nadpisywania. Da się — w praktyce spotyka się rozwiązanie, w którym serwer podaje zamiast wygenerowanego pliku jego własną, ręcznie utrzymywaną kopię pod inną nazwą. Odradzamy to w większości sklepów, i to nie dlatego, że nie działa, tylko dlatego, że po dwóch latach i trzech aktualizacjach nikt już nie pamięta, że taka konstrukcja istnieje. Ktoś wtedy poprawia plik w panelu, dziwi się, że nic się nie zmienia, i szuka błędu zupełnie gdzie indziej. Jeśli mimo to decydujecie się na takie rozwiązanie, niech będzie opisane w dokumentacji wdrożenia, a nie wyłącznie w głowie osoby, która je zrobiła.

Przy okazji aktualizacji warto wiedzieć jedno: pliki statyczne, których nie ma w wydaniu, nie są przez aktualizator dotykane, ponieważ lista plików do przetworzenia powstaje z zawartości nowej wersji oraz z listy plików skasowanych między wersjami. Plik spoza obu tych zbiorów do przetwarzania nie trafia. Dotyczy to ścieżki aktualizacji modułem aktualizującym — przy ręcznej podmianie katalogu odpowiadasz za to sam.

Zanim uznasz temat za zamknięty

• Otwórz adres sklepu z dopiskiem /robots.txt. Widzisz pustą stronę albo błąd? Plik trzeba wygenerować.
• Sprawdź, czy są zezwolenia na style, skrypty i obrazy w katalogu modułów. Jeśli katalog modułów jest zablokowany, a zezwoleń brak, ktoś je usunął i robot nie widzi Twoich stron w całości.
• Sprawdź, czy blokady stron funkcyjnych są w językach Twojego sklepu. Lista budowana jest z ustawień, więc powinna zawierać adresy w każdym języku, który masz włączony — przy sklepie wielojęzycznym każda wersja dostaje własne wpisy z przedrostkiem językowym. Jeśli brakuje wpisów dla któregoś języka, plik pochodzi sprzed jego dodania.
• Poszukaj własnych wpisów. Jeśli pamiętasz, że coś dopisywaliście, a tego nie ma, właśnie zobaczyłeś, jak działa nadpisywanie.
• Sprawdź, czy jest wiersz wskazujący mapę strony. Jeśli go nie ma, prawdopodobnie Twoja mapa nazywa się inaczej niż sitemap.xml — wtedy trzeba dopisać ten wiersz ręcznie.
• Policz grupy zaczynające się od User-agent. Dwie takie same grupy oznaczają, że ktoś dokleił reguły niżej, zamiast do istniejącej — część automatów przeczyta wtedy tylko pierwszą.
• Poszukaj nazw automatów AI — GPTBot, ClaudeBot, PerplexityBot i podobnych. Jeśli przy którejś widnieje Disallow, sprawdź, czy to była świadoma decyzja.
• Jeśli czegokolwiek z tego nie rozumiesz, pokaż plik osobie opiekującej się sklepem. Jest pisany dla automatów, nie dla ludzi, i nie ma w tym nic dziwnego.

Najczęstsze pytania

Gdzie znajduje się plik robots.txt w PrestaShop?
W głównym katalogu sklepu, dostępny pod adresem Twojej domeny z dopiskiem /robots.txt. Generuje się go przyciskiem w panelu, w ustawieniach dotyczących adresów i SEO.

Dlaczego moje wpisy w robots.txt znikają?
Bo PrestaShop nadpisuje ten plik w całości przy instalacji, przy zapisaniu adresu sklepu w panelu i po kliknięciu przycisku generowania. Żadna z tych operacji nie zachowuje wcześniejszej zawartości. Trzymaj kopię własnych wpisów poza sklepem.

Co powinno się znaleźć w robots.txt sklepu na PrestaShop?
Wersja domyślna pokrywa katalogi techniczne, strony funkcyjne i adresy z parametrami platformy. Dopisać warto własne parametry filtrowania, parametry kampanii, katalogi robocze spoza wydania oraz wiersz wskazujący mapę strony.

Dlaczego PrestaShop nadpisuje robots.txt po dodaniu języka?
Bo blokady w tym pliku zawierają przedrostki językowe — po dodaniu nowej wersji językowej musi więc powstać komplet wpisów dla tego języka. PrestaShop robi to celowo i sensownie, ale przy okazji kasuje wszystko, co ktoś dopisał ręcznie.

Czy PrestaShop 9 wymaga innej konfiguracji robots.txt niż PrestaShop 8?
Nie w żadnym istotnym zakresie. Różnice w wersji domyślnej są drobne — kosmetyczne uzupełnienia listy zezwoleń i parametrów — a mechanika generowania i nadpisywania jest w PrestaShop 8 i PrestaShop 9 taka sama. Wszystko, co opisujemy w tym tekście, dotyczy obu wersji.

Zablokowałem stronę, a ona nadal jest w Google. Ten plik nie usuwa stron z wyników. Adres może się utrzymać, jeśli prowadzą do niego odnośniki, tylko bez opisu. Do usunięcia z wyników służy znacznik noindex — ale żeby robot go zobaczył, strona nie może być zablokowana w tym pliku. Te dwa mechanizmy potrafią sobie nawzajem przeszkodzić.

Czy blokować w robots.txt katalog ze zdjęciami produktów?
Nie. Obrazy produktów są treścią sklepu, a nie zasobem technicznym, i bywają samodzielnym źródłem ruchu.

Mam sklep wielojęzyczny — czy plik obsłuży to sam?
Adresy stron funkcyjnych pobierane są z bazy dla każdego języka, więc generator uwzględnia wersje językowe. Sprawdź jednak, czy po dodaniu nowego języka plik został wygenerowany ponownie; jeśli nie, brakuje w nim blokad dla tej wersji.

Czy da się mieć osobne reguły dla różnych automatów?
Da się, bo to funkcja samego formatu, ale platforma nie wygeneruje ich za Ciebie — trzeba je dopisać, a wtedy wracamy do pytania o trwałość własnych wpisów.

Plik, do którego nikt nie zagląda, aż robi się problem

Największa wada tego pliku w PrestaShopie nie leży w jego domyślnej zawartości, bo ta jest rozsądna. Leży w tym, że powstaje sam, znika sam i nie zostawia po sobie żadnego śladu, a dokumentacja dla właściciela sklepu poświęca mu dwa zdania.

Wejdź więc na adres swojego sklepu z dopiskiem /robots.txt i przeczytaj, co tam stoi. To jest publiczna deklaracja, gdzie w Twoim sklepie wolno wchodzić automatom — łącznie z tymi, od których zależy, czy pojawisz się w odpowiedziach asystentów AI. Całkiem możliwe, że ostatni raz widział ją ktoś, kto stawiał ten sklep.

Gdy już to sprawdzisz, kolejnym plikiem wartym uwagi jest ten, w którym sam mówisz asystentom, co w Twoim sklepie jest najważniejsze — opisaliśmy go jak napisać plik llms.txt krok po kroku. A jeśli wolisz mieć całość sprawdzoną z zewnątrz, zamów darmowy raport GEO. Jeśli wolisz od razu zobaczyć, ile kosztuje wdrożenie i co obejmuje, mamy zakres i ceny pakietów GEO.