Dlaczego robots.txt i llms.txt nie pokazują zmian z panelu?

SEO/GEO Files Generator to wtyczka do WordPressa, która z jednego panelu generuje i serwuje pliki robots.txt, llms.txt i llms-full.txt. Przygotował ją BeeClear, twórca wtyczek do WordPressa i aplikacji na smartfony. Czasem zapisujesz nowe reguły, a pod adresem /robots.txt wciąż widać starą treść. Najczęściej winny jest fizyczny plik na serwerze, który przejmuje rolę ustawień z panelu. Poniżej zebraliśmy objawy, ich przyczyny i sposoby, w jakie wtyczka pomaga je wykryć.

Dlaczego robots.txt pokazuje starą treść mimo zapisanych ustawień?

Robots.txt pokazuje starą treść mimo zapisanych ustawień zwykle wtedy, gdy w katalogu głównym WordPressa leży fizyczny plik o tej nazwie. Serwer WWW oddaje go zamiast odpowiedzi generowanej przez WordPressa. Nowe reguły trafiają więc do bazy, ale robot ich nie zobaczy. SEO/GEO Files Generator buduje robots.txt dynamicznie po zaznaczeniu opcji „Serve generated robots.txt through WordPress”. Plik na dysku i tak ma pierwszeństwo przed wynikiem z WordPressa.

Taki plik mógł wgrać ręcznie administrator serwera. Równie dobrze mógł go zapisać wcześniej sam generator przyciskiem „Save & write robots.txt file”. W obu przypadkach objaw wygląda identycznie: podgląd w panelu pokazuje nowe reguły, a adres na żywo – stare. Różnica między tymi scenariuszami ma jednak znaczenie przy sprzątaniu.

Jak wtyczka wykrywa fizyczny robots.txt w katalogu WordPressa?

Wtyczka wykrywa fizyczny robots.txt w katalogu WordPressa przy każdym otwarciu ekranu robots.txt. Gdy plik istnieje, pod formularzem pojawia się ostrzeżenie o serwowaniu go zamiast ustawień. Komunikat mówi też, czy treść pliku różni się od podglądu. Przy porównaniu generator pomija różnice w znakach końca linii i spacje na końcu wierszy. Alarm nie wyskakuje więc z powodu samego formatowania.

Różna treść oznacza błąd z plakietką „Blocked”. Zgodna treść daje tylko ostrzeżenie z plakietką „Check”. Boty czytają wtedy właściwe reguły, lecz każda kolejna zmiana wymaga ponownego zapisu pliku. Obok podglądu masz też link „Open live robots.txt” do wersji dostępnej pod adresem witryny.

Kiedy fizyczny robots.txt można usunąć z panelu?

Fizyczny robots.txt usuniesz z panelu tylko wtedy, gdy zapisała go sama wtyczka. Taki plik zaczyna się od nagłówka „# robots.txt generated by BeeClear SEO/GEO Files Generator”. Dla niego pojawia się przycisk „Delete physical robots.txt” z prośbą o potwierdzenie. Plik bez tego nagłówka generator uznaje za przygotowany ręcznie i go nie rusza. Komunikat podpowiada wtedy usunięcie go bezpośrednio z hostingu. Oto, jak wtyczka traktuje plik zależnie od jego pochodzenia:

Sytuacja na serwerze	Co pokazuje panel	Co dzieje się przy aktualizacji wtyczki
plik zapisany przez wtyczkę, treść zgodna z ustawieniami	ostrzeżenie i przycisk usuwania	plik zostaje na miejscu
plik zapisany przez wtyczkę, treść nieaktualna	błąd i przycisk usuwania	plik znika, a WordPress serwuje bieżące ustawienia
plik przygotowany ręcznie	ostrzeżenie lub błąd, bez przycisku	plik zostaje na miejscu
brak pliku	brak ostrzeżenia	WordPress nadal serwuje zapisane ustawienia

Automatyczne sprzątanie działa od wersji 2.5.1 i rozwiązuje najczęstszy przypadek. Nieaktualna kopia zapisana przez generator nie zasłania już nowych reguł. O ręcznym pliku decydujesz sam, bo wtyczka nie zna jego pochodzenia.

Dlaczego llms.txt prowadzi do innej domeny niż Twoja?

Llms.txt z linkami do innej domeny to typowy objaw pliku zapisanego raz na dysku. Fizyczny plik ma treść z chwili generowania i nie rozpoznaje adresu, pod którym go otwierasz. Od wersji 2.4.0 SEO/GEO Files Generator domyślnie serwuje llms.txt i llms-full.txt dynamicznie. Linki wskazują wtedy domenę, pod którą otwarto witrynę: produkcję, kopię testową, tunel albo lokalny port. Tryb wybierasz w ustawieniach globalnych, w polu „llms delivery”.

Tryb dynamiczny przechowuje wynik w pamięci podręcznej osobno dla każdej domeny. Każde ponowne generowanie tę pamięć odświeża. Zapis na dysk nadal istnieje jako opcja „Physical files written to the WordPress root”. Wybierz go świadomie – plik na dysku ma jeden zestaw linków niezależnie od domeny.

Co zrobić, gdy stary plik llms.txt zasłania wersję dynamiczną?

Stary plik llms.txt zasłania wersję dynamiczną tak samo, jak fizyczny robots.txt zasłania ustawienia. Serwer oddaje zawartość dysku, a WordPress nie dostaje szansy na odpowiedź. Wtyczka sygnalizuje to w linii statusu na ekranach llms.txt i llms-full.txt. Komunikat mówi wprost, że plik z dysku jest serwowany zamiast wyniku dynamicznego.

Przy każdym generowaniu w trybie dynamicznym generator próbuje taki plik usunąć. Własne pliki rozpoznaje po znaczniku BOM UTF-8 na samym początku. Plik bez tego znacznika uznaje za ręczny i zostawia na miejscu. Zobaczysz wtedy informację o odświeżeniu llms.txt z dopiskiem, że serwer nadal oddaje plik z dysku. Usuń go z serwera, a wersja dynamiczna zacznie działać.

Dlaczego poprawka na stronie nie trafia od razu do llms.txt?

Poprawka na stronie nie trafia do llms.txt od razu, bo wtyczka odświeża plik w tle. Zapis strony wybranej do llms.txt planuje zadanie WP-Cron około 30 sekund później. Kilka zapisów w krótkim czasie łączy się w jedno odświeżenie. Edytor kończy więc zapis natychmiast, bez czekania na budowę pliku. Tak samo działa llms-full.txt, który ma własne zadanie w tle.

Zmianę od ręki wymusisz przyciskiem „Generate now” na ekranie modułu. Generator zbuduje wtedy treść od nowa i odświeży pamięć podręczną dla wszystkich domen. Wynik każdej operacji trafia do dziennika „Last 100 logs” z datą i statusem. Tam sprawdzisz, czy ostatnie generowanie zakończyło się wpisem OK, czy ERROR.

Co zrobić, gdy WordPress nie może zapisać pliku na serwerze?

Gdy WordPress nie może zapisać pliku na serwerze, karta „Filesystem access” w ustawieniach globalnych powie Ci o tym zawczasu. Karta sprawdza robots.txt, llms.txt i llms-full.txt bez próbnego zapisu. Dla każdego z nich pokazuje, czy da się go utworzyć albo nadpisać w katalogu WordPressa. Ten sam status widać w linii pod formularzem każdego modułu. Komunikaty rozróżniają kilka sytuacji:

• WordPress nie zapisuje plików bezpośrednio i wymagałby danych FTP lub SSH,
• katalog główny blokuje zapis, więc nowego pliku nie da się utworzyć,
• plik istnieje bez prawa zapisu, więc nie da się go nadpisać,
• zapis robots.txt przechodzi, ale odczyt kontrolny nie zgadza się z treścią.

W każdej z tych sytuacji pomaga przycisk „Download”. Pobiera dokładnie tę treść, którą wtyczka zapisałaby na dysku. Plik wgrywasz potem ręcznie do katalogu głównego. Pamiętaj tylko o jednym: taki plik zasłoni późniejsze zmiany z panelu aż do podmiany.

Dlaczego przycisk zapisu robots.txt zniknął z ekranu?

Przycisk zapisu robots.txt znika z ekranu, gdy jedno drzewo plików obsługuje kilka witryn z osobnymi bazami danych. Jeden plik w katalogu głównym trafiałby wtedy do wszystkich tych witryn naraz. Wtyczka ukrywa więc przycisk „Save & write robots.txt file” i odmawia zapisu na dysk. Linia statusu wyjaśnia, że WordPress serwuje robots.txt dynamicznie. W takim układzie llms.txt i llms-full.txt także działają wyłącznie dynamicznie.

Jak krok po kroku sprawdzić, który plik widzą roboty?

Który plik widzą roboty, sprawdzisz w kilku krokach bez sięgania do plików na hostingu. Zacznij od porównania podglądu z wersją na żywo. Każda różnica między nimi oznacza, że odpowiada coś innego niż ustawienia. Oto kolejność, która szybko zawęża przyczynę:

1. otwórz ekran robots.txt i porównaj podgląd z linkiem „Open live robots.txt”,
2. sprawdź, czy pod formularzem nie widnieje ostrzeżenie o fizycznym pliku,
3. upewnij się, że opcja „Serve generated robots.txt through WordPress” jest zaznaczona,
4. w ustawieniach globalnych przejrzyj tryb „llms delivery” i kartę „Filesystem access”,
5. na ekranie llms.txt kliknij „Generate now” i zajrzyj do dziennika.

Pełny opis modułów i zrzuty ekranu znajdziesz na stronie SEO/GEO Files Generator. Jeśli wolisz wsparcie przy wdrożeniu, zespół BeeClear pomoże ustawić pliki pod Twój serwis. Dzięki kilku kontrolom szybko ustalisz, czy boty czytają Twoje reguły, czy zapomnianą kopię.