robots.txt w WooCommerce: gdzie on w ogóle jest i kto nim rządzi

Chcesz zajrzeć do pliku z regułami dostępu w swoim sklepie, więc wchodzisz na serwer, otwierasz główny katalog i… nie ma go tam. Tymczasem pod adresem Twojego sklepu z dopiskiem /robots.txt plik wyświetla się bez problemu, z regułami, których nikt świadomie nie wpisywał.

To nie jest usterka. W sklepie na WooCommerce ten plik zwykle nie istnieje jako plik — WordPress tworzy jego treść dopiero w momencie, gdy ktoś o nią poprosi. I właśnie dlatego pierwsze pytanie nie brzmi „co w nim zmienić”, tylko „kto go w tej chwili pisze”. Zanim na nie odpowiesz, każda zmiana jest strzałem w ciemno.

W skrócie: jeśli w głównym katalogu witryny leży prawdziwy plik, serwer podaje właśnie jego i nic innego nie ma znaczenia. Jeśli go nie ma, treść buduje WordPress — bardzo skromną, bo to dosłownie dwie reguły — a potem przepuszcza ją przez mechanizm, w którym kolejno dopisują swoje WooCommerce i wszystkie wtyczki. Kto w tym łańcuchu odezwie się ostatni i zamiast dopisać podmieni całość, ten wygrywa. Najczęstszym źródłem kłopotów jest utworzenie prawdziwego pliku jednym kliknięciem we wtyczce SEO, bo od tej chwili wszystko, co dokładały rdzeń i WooCommerce, przestaje obowiązywać.

W tym tekście: skąd bierze się treść tego pliku, co dokłada samo WooCommerce, dlaczego koszyka nie blokuje się tutaj, jak sprawdzić, co masz u siebie, i jak poukładać to na stałe.

Serwer i WordPress, czyli dwa poziomy

Żeby cokolwiek zrozumieć, trzeba rozdzielić dwie warstwy, w których ten plik może powstać. Na poziomie serwera sprawa jest prosta: jeżeli w głównym katalogu witryny leży prawdziwy plik, serwer podaje go bezpośrednio, a kod WordPressa w ogóle się nie wykonuje — reguły zapisywane do konfiguracji serwera kierują żądanie do aplikacji wyłącznie wtedy, gdy żądany adres nie odpowiada istniejącemu plikowi ani katalogowi. Plik fizyczny wygrywa więc ze wszystkim, co opisuję niżej, i to jest pierwsza rzecz do ustalenia.

Jeżeli natomiast pliku nie ma, treść buduje sam WordPress: funkcja rdzenia wypisuje bardzo oszczędny zestaw reguł, a następnie przekazuje go dalej, do mechanizmu, w którym po kolei dopisują się WooCommerce i wszystkie wtyczki mające na ten temat zdanie. Dlatego pytanie, od którego trzeba zacząć, brzmi: czy plik w Twoim sklepie jest prawdziwy, czy powstaje w locie — odpowiedź rozstrzyga, gdzie w ogóle szukać przyczyny, gdy coś się nie zgadza.

Przy okazji: jeśli WordPress stoi w podkatalogu, a nie w głównym katalogu domeny, pod adresem domeny z dopiskiem /robots.txt nie pojawi się nic, bo żądanie w ogóle do niego nie trafia. Wtedy potrzebny jest prawdziwy plik w głównym katalogu domeny — i to on obsługuje całą domenę, nie tylko sklep.

Co zawiera wersja tworzona przez WordPressa

Zaskakująco mało, bo sam rdzeń WordPressa wypisuje jedną grupę reguł obowiązującą wszystkie automaty, a w niej dokładnie dwie dyrektywy: blokadę katalogu administracyjnego i zezwolenie na jeden plik obsługujący żądania wykonywane w tle — ten sam, którego panel i część wtyczek używają do działania, więc jego zablokowanie psułoby stronę. Do tego dochodzi wiersz wskazujący mapę strony, dopisywany wtedy, gdy witryna jest oznaczona jako publiczna w ustawieniach czytania. Wszystko pozostałe, co widzisz w swoim pliku, dołożył już ktoś inny: WooCommerce albo któraś z wtyczek.

Jedno sprostowanie, które nie dotyczy WooCommerce

Przy okazji warto wyprostować informację krążącą po poradnikach, bo bywa myląca — dotyczy wyłącznie ustawienia „zniechęcaj wyszukiwarki do indeksowania tej witryny”, które znajdziesz w ustawieniach czytania, i nie ma nic wspólnego z regułami dokładanymi przez WooCommerce.

Dawniej zaznaczenie tej opcji sprawiało, że WordPress dopisywał do pliku z regułami blokadę całej witryny. Dziś już tego nie robi — realizuje to ustawienie znacznikiem umieszczanym w kodzie strony, bo blokada w pliku z regułami nie usuwa stron z wyników wyszukiwania, a jedynie uniemożliwia ich przeczytanie. Praktyczny wniosek jest taki, że brak takiej blokady w pliku nie oznacza, że ustawienie jest wyłączone — trzeba sprawdzić je w panelu, a nie w pliku.

Co dokłada samo WooCommerce

I tu dochodzimy do części, o której nie mówi żadna dokumentacja pisana dla właściciela sklepu, bo takiej dokumentacji po prostu nie ma. WooCommerce dopisuje do tego pliku własne reguły — robi to dziś, w aktualnych wydaniach, podłączając się do tego samego mechanizmu, z którego korzystają wtyczki. Dlatego w typowym sklepie plik zawiera znacznie więcej niż dwie dyrektywy rdzenia.

Blokuje trzy katalogi leżące wewnątrz katalogu przesłanych plików — dzienniki zdarzeń, pliki tymczasowe oraz katalog, w którym lądują pliki sprzedawane do pobrania — a także adresy powstające przy dodawaniu produktu do koszyka, które potrafią mnożyć się w tysiącach wariantów przy każdym przejściu automatu przez katalog. Komentarz w kodzie opisuje cel wprost: chodzi o niedopuszczenie do indeksowania katalogów tworzonych przez samo WooCommerce.

Dwa szczegóły mają tu praktyczne znaczenie. Po pierwsze, reguły wstawiane są bezpośrednio po wierszu z identyfikatorem automatu, a nie dopisywane na końcu — kod szuka tego wiersza i dzieli treść dokładnie w tym miejscu, a uzasadnienie podane w komentarzu brzmi: część automatów czyta wyłącznie pierwszą grupę reguł dla danego identyfikatora. To samo uzasadnienie warto wziąć do siebie przy dopisywaniu własnych wpisów. Po drugie, ścieżka katalogu przesłanych plików odczytywana jest z ustawień witryny, więc jeśli ktoś ją u Ciebie zmieniał, reguły wskażą właściwe miejsce, a nie standardowe.

Zestaw tych reguł zmienia się przy tym między wydaniami WooCommerce — blokada adresów koszyka jest w nim dopiero od pewnej wersji. Dwa sklepy na dwóch różnych wydaniach mają więc różne pliki, mimo że nikt niczego nie zmieniał.

Czego WooCommerce tym plikiem nie załatwia i nie próbuje

Strony koszyka, zamówienia i konta klienta nie są blokowane w pliku z regułami dostępu. Zamiast tego dostają znacznik zabraniający indeksowania, umieszczony w kodzie strony, a końcówki transakcyjne i żądania pobrania pliku dodatkowo odpowiedni nagłówek odpowiedzi.

To jest rozdział mechanizmów, który tłumaczy pozorną niekonsekwencję i warto go zrozumieć raz a dobrze. Plik z regułami decyduje o wejściu. Znacznik w kodzie strony decyduje o obecności w wynikach wyszukiwania. Strona zablokowana w pliku z regułami nie zostanie przeczytana, więc robot nie zobaczy na niej znacznika zakazującego indeksowania — i adres może utrzymać się w wynikach, bez opisu, jeśli prowadzą do niego odnośniki. Dlatego koszyka nie blokuje się tutaj, tylko oznacza w treści strony. WooCommerce robi to dobrze i nie należy tego „poprawiać”, dopisując blokady, które sprawią, że znacznik przestanie być widoczny.

Kto wygrywa, gdy wtyczek jest kilka

Pytanie pada zawsze, a odpowiedź nie brzmi tak, jak większość zakłada. Nie wygrywa ważniejsza wtyczka ani ta skonfigurowana później. Wygrywa ta, która odezwała się jako ostatnia i zamiast dopisać coś do otrzymanej treści, podmieniła ją w całości.

Mechanizm przekazuje kolejnym rozszerzeniom to, co zbudowały poprzednie. Rozszerzenie, które dopisuje do otrzymanej treści, zachowuje wkład wcześniejszych; rozszerzenie, które zwraca własną wersję, kasuje wszystko, co było przed nim — łącznie z regułami WooCommerce i wierszem wskazującym mapę strony.

Do tego dochodzi trzeci gracz, w praktyce najgroźniejszy. Wtyczki SEO potrafią utworzyć prawdziwy plik jednym kliknięciem w panelu, a wstawiana przy tym treść bywa minimalna: jedna grupa dla wszystkich automatów, pusta dyrektywa zakazu, czyli brak jakiejkolwiek blokady, plus wiersz z mapą strony. Od momentu powstania takiego pliku cały mechanizm opisany wyżej przestaje mieć znaczenie, bo serwer podaje plik, nie pytając WordPressa o zdanie.

Przeczytaj to jeszcze raz, bo konsekwencja jest poważna: jedno kliknięcie w panelu wtyczki potrafi zamienić plik blokujący katalog z plikami sprzedawanymi do pobrania w plik, który nie blokuje niczego. Nie dlatego, że wtyczka działa źle — dlatego, że nikt nie powiedział osobie klikającej, co dokładnie się wtedy dzieje.

Automaty AI: jedna decyzja, nie jedna reguła

Zanim ktokolwiek zacznie dopisywać do tego pliku blokady dostawców AI, warto wiedzieć jedno: ich automaty nie są jednym bytem. U tego samego dostawcy jeden zbiera treści do trenowania modeli, a zupełnie inny odpowiada za to, czy Twój sklep może w ogóle pojawić się w wynikach wyszukiwania wewnątrz asystenta — i o tym drugim dokumentacja mówi wprost, że 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ą. Zapada zwykle jednym wpisem, w dobrej wierze, po tym jak ktoś usłyszał, że „AI kradnie treści” — a skutków nie widać od razu, bo nic się nie dzieje i nic nikogo nie powiadamia.

Pełną listę automatów z podziałem na funkcje i trzy gotowe warianty konfiguracji zebraliśmy w tekście które boty AI odwiedzają sklep i co z nimi zrobić. 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.

Jak sprawdzić, co masz u siebie

Wejdź na adres swojego sklepu z dopiskiem /robots.txt i przeczytaj, co się wyświetli. Czterech rzeczy warto przy tym poszukać, a każda od razu mówi, z jaką sytuacją masz do czynienia.

Najszybciej rozstrzygają komentarze z nazwą wtyczki, czyli linie zaczynające się od znaku kratki, w których pada nazwa jakiegoś rozszerzenia — jeśli je widzisz, masz prawdziwy plik utworzony przez tę wtyczkę i to ona rządzi całością. Podobnie działa brak reguł dotyczących katalogu przesłanych plików: skoro nie dopisało ich WooCommerce, treść najwyraźniej nie przeszła przez mechanizm rozszerzeń, czyli znowu mamy do czynienia z prawdziwym plikiem. Trzecim sygnałem jest brak wiersza wskazującego mapę strony przy publicznej witrynie, co zwykle oznacza, że coś podmieniło treść, zamiast do niej dopisać.

Czwarta rzecz jest subtelniejsza: policz grupy zaczynające się od identyfikatora automatu. Dwie takie same oznaczają, że ktoś dokleił swoje reguły na końcu, zamiast wstawić je do istniejącej grupy — część automatów przeczyta wtedy wyłącznie pierwszą i Twoje blokady po prostu nie zadziałają.

Zajrzyj też w ustawienia czytania i sprawdź, czy witryna nie jest przypadkiem oznaczona jako niepubliczna. To ustawienie potrafi przetrwać od czasów budowy sklepu, a w pliku z regułami dziś go nie zobaczysz — z powodu opisanego wyżej.

Jeśli którykolwiek z tych punktów nic Ci nie mówi, to normalne: ten plik jest pisany dla automatów, nie dla ludzi. Pokaż go osobie opiekującej się sklepem albo prześlij nam adres.

Jak poukładać to na stałe

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

Zasada jest jedna i wszystko inne z niej wynika: wybierz jedno miejsce, w którym rządzisz tym plikiem.

Wariant pierwszy: prawdziwy plik. Prosty, przewidywalny, odporny na to, że wtyczka zmieni zdanie przy aktualizacji. Kosztuje jedną rzecz — musisz sam dopisać wszystko, co dokładały rdzeń i WooCommerce, bo od tej chwili nikt nie zrobi tego za Ciebie. Przepisz te reguły z wersji budowanej w locie, zanim utworzysz plik, inaczej po prostu znikną.

Wariant drugi: zostawiasz wersję budowaną w locie i dokładasz własne reguły jednym, świadomie napisanym fragmentem kodu, który dopisuje do otrzymanej treści, a nie podmienia jej w całości. Wtedy rdzeń i WooCommerce nadal robią swoje, a Twoje reguły dochodzą na końcu. Wymaga to kogoś, kto ruszy kod, i upewnienia się, że żadna inna wtyczka nie podmienia treści całkowicie.

Czego nie robić w żadnym wariancie: trzymać części reguł w panelu wtyczki, części w prawdziwym pliku, a jeszcze innej w kodzie motywu. Po pół roku nikt nie będzie wiedział, skąd bierze się która linia — a wyjaśnianie tego zajmuje więcej czasu niż wszystkie te zmiany razem wzięte.

Niezależnie od wariantu: sprawdź plik po każdej większej aktualizacji. Zestaw reguł dokładanych przez WooCommerce zmieniał się między wydaniami, więc treść potrafi się zmienić bez żadnego Twojego udziału.

Czego nie wolno zablokować

Ta część jest wspólna dla wszystkich sklepów, niezależnie od platformy, i jest najkosztowniejszym błędem w tym pliku.

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śli brak zasobu utrudnia robotowi zrozumienie strony, blokować go nie należy. Do tego dochodzi zasada mówiąca wprost, że Google nie wykonuje skryptów pobranych z zablokowanych plików ani na zablokowanych stronach.

W tym środowisku ryzyko jest bardzo konkretne. Motyw, WooCommerce i wtyczki trzymają style oraz skrypty w katalogach wewnątrz katalogu z zawartością witryny, więc zablokowanie całego tego katalogu — kuszące, bo jednym wpisem — odcina robotowi widok karty produktu. Blokuje się zatem konkretne podkatalogi, dokładnie tak, jak robi to samo WooCommerce ze swoimi dziennikami i plikami do pobrania.

Drugim kandydatem na ten sam błąd jest katalog przesłanych plików. Leżą w nim zdjęcia produktów, czyli treść sklepu, a nie zasób techniczny — WooCommerce blokuje w nim trzy podkatalogi i tylko trzy, i to jest właściwa skala.

Zanim uznasz temat za zamknięty

• Otwórz adres sklepu z dopiskiem /robots.txt i sprawdź, czy cokolwiek się wyświetla.
• Poszukaj komentarzy z nazwą wtyczki — ich obecność oznacza prawdziwy plik, który przykrywa wszystko inne.
• Sprawdź, czy są reguły dotyczące katalogu przesłanych plików. Ich brak to drugi sygnał, że masz prawdziwy plik.
• Sprawdź, czy jest wiersz wskazujący mapę strony.
• Policz grupy zaczynające się od identyfikatora automatu. Powinna być jedna.
• Poszukaj nazw automatów AI i sprawdź, czy przy którejś widnieje zakaz — jeśli tak, ustal, czy to była świadoma decyzja.
• Sprawdź, czy nie blokujesz katalogów ze stylami i skryptami ani katalogu ze zdjęciami produktów.
• Zajrzyj w ustawieniach czytania, czy witryna jest publiczna.
• Jeśli masz dwie wtyczki SEO, zostaw jedną. Dwie naraz dają wynik, którego nikt nie przewidzi.

Najczęstsze pytania

Gdzie jest plik robots.txt w WooCommerce?
Najczęściej nigdzie — nie istnieje jako plik, tylko jako treść tworzona przez WordPressa w momencie, gdy ktoś o nią poprosi. Zobaczysz ją, wchodząc na adres sklepu z dopiskiem /robots.txt. Jeśli ktoś utworzył prawdziwy plik, leży on w głównym katalogu witryny i przykrywa wersję tworzoną w locie.

Jak edytować robots.txt w WordPressie?
Masz dwie drogi: utworzyć prawdziwy plik w głównym katalogu albo dopisać reguły kodem, który dokłada je do treści tworzonej w locie. Pierwsza jest prostsza, ale wyłącza wszystko, co dokładały rdzeń i WooCommerce, więc trzeba to wcześniej przepisać.

Czy WooCommerce dodaje coś do robots.txt?
Tak. Blokuje trzy katalogi wewnątrz katalogu przesłanych plików — dzienniki zdarzeń, pliki tymczasowe i pliki sprzedawane do pobrania — oraz adresy powstające przy dodawaniu produktu do koszyka. Zestaw tych reguł zmieniał się między wydaniami.

Czy blokować w robots.txt koszyk i stronę zamówienia?
Nie ma takiej potrzeby, bo WooCommerce oznacza te strony znacznikiem zakazującym indeksowania w kodzie strony. Dopisanie blokady w pliku z regułami jest wręcz szkodliwe: robot nie przeczyta wtedy strony, więc nie zobaczy tego znacznika.

Dlaczego moje zmiany w robots.txt nie działają?
Najczęściej dlatego, że w głównym katalogu leży prawdziwy plik utworzony kiedyś przez wtyczkę, a Ty zmieniasz coś w innym miejscu. Serwer podaje prawdziwy plik i nie pyta WordPressa o zdanie.

Mam dwie wtyczki SEO. Która rządzi plikiem?
Prawdopodobnie żadna w przewidywalny sposób, i to jest odpowiedź sama w sobie. Zostaw jedną.

Czy robots.txt chroni pliki, które sprzedaję do pobrania?
Nie. Blokada wejścia nie jest zabezpieczeniem — WooCommerce blokuje ten katalog po to, żeby nie trafił do wyników wyszukiwania, a nie żeby uniemożliwić pobranie. Ochrona plików płatnych to osobny mechanizm w ustawieniach sklepu i warto sprawdzić, czy jest włączony.

Plik, którego nie ma, a jednak rządzi

Największa różnica wobec innych platform polega na tym, że tutaj nie wystarczy przeczytać zawartość pliku — trzeba jeszcze wiedzieć, skąd ona pochodzi. Ta sama treść może być wynikiem pracy rdzenia, WooCommerce i dwóch wtyczek albo jednym plikiem, który ktoś utworzył kliknięciem trzy lata temu i zdążył o tym zapomnieć.

Otwórz więc adres swojego sklepu z dopiskiem /robots.txt i poszukaj w nim reguł dotyczących katalogu przesłanych plików. Ich obecność albo brak odpowie Ci na pytanie, kto w Twoim sklepie pisze ten plik — a to jest jedyna rzecz, którą trzeba wiedzieć, zanim cokolwiek się w nim zmieni.

Ten sam plik w PrestaShopie zachowuje się zupełnie inaczej — opisujemy to w tekście jak działa plik robots.txt w PrestaShop. 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.