llms.txt w PrestaShop: moduł czy plik ręczny i co wybrać

Wejdź na adres swojego sklepu i dopisz na końcu /llms.txt. Z dużym prawdopodobieństwem zobaczysz stronę błędu — i nie jest to usterka, tylko stan domyślny. PrestaShop nie tworzy tego pliku z pudełka: ani przy instalacji sklepu, ani przy generowaniu pliku z regułami dostępu, ani przy żadnej innej operacji w panelu. Dopóki ktoś świadomie czegoś nie zrobi, pod tym adresem nie ma nic.

Pytanie brzmi więc nie „co już mam”, tylko „czym to zrobić i czy warto za to płacić” — bo w tej platformie obie odpowiedzi są sensowne, a wybór zależy głównie od tego, jak często zmienia się Twój asortyment.

W skrócie: masz dwie drogi. Moduł z katalogu, który generuje plik automatycznie z Twojego asortymentu i odświeża go po zmianach, albo zwykły plik tekstowy napisany ręcznie i wgrany do głównego katalogu sklepu. Pierwsza jest wygodna przy katalogu, który często się zmienia; druga przewidywalna i darmowa, a przy tym — co w PrestaShopie istotne — nie należy do wydania platformy, więc nie jest ruszana przez mechanizm aktualizacji. Przy obu wariantach największa praca leży poza narzędziem: w napisaniu zdania o tym, czym jest Twój sklep.

W tym tekście: obie drogi z ich wadami, na co patrzeć przy wyborze modułu, pułapka wariantu z pełną treścią, co zrobić przy wielu sklepach i językach oraz jak sprawdzić, czy to, co powstało, cokolwiek znaczy.

Czym jest ten plik i czego od niego oczekiwać

Dla porządku, bo trafiają tu też osoby, które słyszały o nim pierwszy raz. llms.txt to jedna strona tekstu w głównym katalogu domeny, w której własnymi słowami mówisz asystentom AI, czym jest Twój sklep i gdzie szukać rzeczy istotnych. Niczego nie blokuje i nie zastępuje pliku z regułami dostępu ani mapy strony — różnice między tą trójką wyjaśniamy w tekście czym różnią się robots.txt, mapa strony i llms.txt, a sposób pisania takiego pliku rozkładamy na czynniki w tekście jak napisać plik llms.txt krok po kroku.

Czego od niego nie oczekiwać: wpływu na pozycje w wynikach wyszukiwania Google. Sam Google pisze, że utrzymywanie takich plików na potrzeby innych usług jego wyszukiwarce ani nie zaszkodzi, ani nie pomoże. Wartość leży w tym, że asystent trafiający na Twój sklep dostaje wskazówkę, zamiast zgadywać z przypadkowych podstron — a przy sklepie z kilkoma tysiącami produktów różnica między wskazówką a zgadywaniem bywa duża.

Moduł z katalogu rozszerzeń

W oficjalnym katalogu rozszerzeń PrestaShopa dostępne są między innymi LLMs Generator, obecny również w polskiej wersji katalogu, oraz Automatic LLMs.txt Generator Pro z odświeżaniem harmonogramem. Poza katalogiem sprzedawane są kolejne: LLMs TXT Generator w wersjach od Knowbanda i Webkula, a na polskim rynku Generator llms i llms-full od Prestasoftu.

Deklarowany zakres bywa szeroki: generowanie pliku z produktów, kategorii, marek i stron treściowych, obsługa wielu sklepów i języków, własny wstęp pisany ręcznie, odświeżanie harmonogramem, a w droższych wariantach także rejestr odwiedzin automatów i punktacja gotowości sklepu.

Zaletą jest to, że plik powstaje sam i nadąża za katalogiem — przy sklepie, w którym asortyment zmienia się co tydzień, ręczne utrzymywanie takiej listy nie ma sensu. Część modułów oznacza przy tym plik jako nieaktualny po każdej zmianie w produktach albo kategoriach, co jest rozwiązaniem sensownym, bo zdejmuje z Ciebie pamiętanie o odświeżeniu.

Wada jest ta sama co przy każdym generatorze: moduł zna strukturę sklepu, ale nie wie, co w nim rozstrzyga o zakupie. Dostaniesz listę zbudowaną z kategorii i produktów, czyli odbicie menu, a nie odpowiedź na pytanie, czym ten sklep się różni i gdzie klient przestaje się wahać. Tę część i tak trzeba napisać samemu — dlatego przy wyborze modułu najważniejsze jest pytanie, czy w ogóle pozwala wpisać własny wstęp i ograniczyć zakres.

Plik napisany ręcznie

Wgrywasz zwykły plik tekstowy do głównego katalogu sklepu, tam gdzie leży plik z regułami dostępu, i sprawdzasz, czy odpowiada pod adresem z dopiskiem /llms.txt. Nic poza tym nie trzeba robić — nie ma tu mechanizmu, który musiałby cokolwiek zarejestrować, bo serwer podaje istniejące pliki bezpośrednio.

Zaletą jest pełna kontrola nad treścią i brak zależności od czegokolwiek, co może zostać wyłączone przy aktualizacji. W PrestaShopie dochodzi do tego argument dodatkowy, którego nie ma na innych platformach: plik statyczny nie należy do wydania platformy, a mechanizm aktualizacji przetwarza wyłącznie pliki należące do wydań — lista rzeczy do podmiany powstaje z zawartości nowej wersji oraz z listy plików skasowanych między wersjami, a plik spoza obu tych zbiorów do przetwarzania nie trafia. Przy aktualizacji wykonywanej modułem aktualizującym nic mu się więc nie stanie. Przy ręcznej podmianie katalogu odpowiadasz za to sam i tam warto trzymać kopię poza sklepem.

Koszt jest oczywisty: aktualizujesz go własnoręcznie. Dla sklepu o stabilnej ofercie jest to droga najrozsądniejsza, z przypomnieniem w kalendarzu raz na kwartał. Przy katalogu zmieniającym się co tydzień przestaje być praktyczna.

Na co patrzeć przy wyborze modułu

Nie wskazujemy konkretnego i nie odradzamy żadnego — rynek jest młody i zmienia się szybciej niż cokolwiek innego w tej dziedzinie. Poniższe pytania są jednak ważniejsze od nazwy i warto zadać je przed zakupem, bo zmiana modułu po wdrożeniu oznacza zwykle zaczynanie od zera.

Najważniejsze są dwa pierwsze wiersze. Moduł, który nie pozwala napisać własnego wstępu ani ograniczyć liczby pozycji, daje plik poprawny formalnie i bezużyteczny w praktyce.

Pułapka wariantu z pełną treścią

Większość modułów na tym rynku generuje dwa pliki: skrócony i rozszerzony, zawierający nie odnośniki, lecz pełne opisy produktów i kategorii. Bywa to przedstawiane jako przewaga, a przy sklepie internetowym warto podejść do tego ostrożnie z dwóch powodów.

Po pierwsze, wariant z pełną treścią nie jest elementem pierwotnej propozycji formatu. Jest praktyką narzędzi, która się przyjęła, ale nie standardem — więc argument „bo tak mówi standard” jest w tym przypadku nieprawdziwy.

Po drugie, przy kilku tysiącach produktów powstaje z tego dokument, którego nikt nie przeczyta w całości, a który w dodatku natychmiast się dezaktualizuje, bo zawiera ceny i opisy zmieniające się co tydzień. Dokumentacja techniczna, dla której ten wariant wymyślono, zmienia się rzadko i ma kilkadziesiąt stron; katalog sklepu ma tysiące pozycji i zmienia się codziennie.

Nie twierdzimy, że szkodzi. Twierdzimy coś węższego: jeśli ktoś sprzedaje Ci oba pliki, warto zapytać, skąd wiadomo, że ten drugi jest potrzebny — i czy ktokolwiek sprawdził, co się w nim znalazło.

Wiele sklepów i wiele języków

To jest obszar, w którym najłatwiej o błąd, bo tryb wielosklepowy jest w PrestaShopie czymś zwyczajnym, a sklepy wielojęzyczne są regułą, nie wyjątkiem.

Zasada jest prosta: jeden plik opisuje jedną wersję językową. Plik próbujący opisać trzy języki naraz nie opisuje dobrze żadnego — połowa opisów jest w języku, którego czytający nie potrzebuje, a streszczenie sklepu robi się ogólnikowe, bo musi pasować do wszystkich. Co z tego wynika praktycznie, zależy jednak od tego, jak Twój sklep jest zbudowany, a przypadki są trzy.

Kilka sklepów, każdy na własnej domenie. Najprostszy przypadek: każda domena potrzebuje własnego pliku pod własnym adresem, w języku tej domeny. To jest pytanie do zadania modułowi przed zakupem, bo nie wszystkie obsługują tryb wielosklepowy.

Jedna domena, kilka wersji językowych w podkatalogach — czyli najczęstszy układ w polskich sklepach sprzedających za granicę, z adresami zaczynającymi się od /pl/, /en/ i tak dalej. Tutaj propozycja formatu daje gotowe rozwiązanie, bo dopuszcza pliki na podścieżkach: główny plik leży pod adresem /llms.txt, a wersje językowe pod /en/llms.txt i /de/llms.txt. Przy nakładaniu się zakresów pierwszeństwo ma plik bardziej szczegółowy, więc asystent wchodzący w angielską część sklepu dostanie opis po angielsku. W pliku głównym warto przy tym zostawić sekcję z odnośnikami do pozostałych wersji, żeby dało się je w ogóle znaleźć.

Jedna domena, kilka języków bez podkatalogów. Jeśli wersje językowe rozróżnia parametr w adresie albo ustawienie w sesji, podziału nie da się odwzorować i trzeba wybrać: albo plik w języku, w którym prowadzisz większość sprzedaży, albo krótki plik w języku głównym z sekcją wskazującą, gdzie szukać oferty w pozostałych. Pierwsze jest prostsze i zwykle wystarcza.

Niezależnie od przypadku warto zapytać moduł o jedną rzecz przed zakupem: czy generuje osobne pliki dla języków, czy jeden z języka domyślnego. Część robi tylko to drugie, a zmiana narzędzia po wdrożeniu oznacza zaczynanie od zera.

Jeśli chcesz, żeby ktoś przeszedł przez te decyzje z Tobą i pokazał przy okazji, co asystenci dziś z Twojego sklepu wyczytują — zamów u nas darmowy raport GEO.

Co sprawdzić po wdrożeniu

Niezależnie od wybranej drogi, dwadzieścia minut z przeglądarką. Wejdź na adres swojego sklepu z dopiskiem /llms.txt i przejdź przez poniższe pytania.

Czy plik otwiera się jako zwykły tekst? Jeśli przeglądarka proponuje pobranie zamiast wyświetlenia, konfiguracja serwera wymaga drobnej poprawki — to jest zadanie na pięć minut dla osoby utrzymującej sklep.

Czy pierwszy akapit mówi, co sprzedajesz, komu i na jakich warunkach? Jeśli zamiast tego stoi tam nazwa sklepu i hasło reklamowe, masz szkielet, a nie plik. To zdanie trzeba napisać samemu i jest to praca na kwadrans, która decyduje o wartości całej reszty.

Ile jest pozycji? Kilkanaście do dwudziestu przy typowym sklepie. Kilkaset oznacza, że generator wypisał katalog i powstała druga mapa strony.

Czy adresy są pełne, z nazwą domeny? Plik bywa czytany w oderwaniu od strony i wtedy skrócony adres nie prowadzi donikąd.

Czy plik jest świeży? Zmień coś drobnego w ofercie, odśwież plik i sprawdź, czy zmiana się pojawiła. Moduły z własną pamięcią podręczną potrafią podawać starą zawartość długo po tym, jak panel zgłosił powodzenie.

Zanim uznasz temat za zamknięty

• Sprawdź, czy pliku jeszcze nie ma — wejdź na adres sklepu z dopiskiem /llms.txt.
• Wybierz jedną drogę: moduł przy katalogu, który często się zmienia, plik ręczny przy stabilnej ofercie.
• Przy module zadaj siedem pytań z tabeli wyżej przed zakupem, nie po.
• Napisz własny wstęp, nawet jeśli moduł wygenerował swój.
• Ogranicz liczbę pozycji do kilkunastu najważniejszych.
• Sprawdź plik w przeglądarce — czy się otwiera, czy adresy są pełne, czy odnośniki prowadzą tam, gdzie zapowiadają.
• Przy wielu sklepach i językach sprawdź, czy każdy ma własny plik.
• Trzymaj kopię treści poza sklepem, jeśli piszesz plik ręcznie.
• Wpisz w kalendarz przegląd za kwartał.

Najczęstsze pytania

Czy PrestaShop generuje plik llms.txt?
Nie. Platforma nie tworzy go ani przy instalacji, ani przy żadnej późniejszej operacji. Trzeba zainstalować moduł albo wgrać plik ręcznie do głównego katalogu sklepu.

Jak dodać llms.txt w PrestaShop?
Dwiema drogami: modułem z katalogu rozszerzeń, który generuje plik z Twojego asortymentu i odświeża go po zmianach, albo wgrywając zwykły plik tekstowy do głównego katalogu sklepu, tam gdzie leży plik z regułami dostępu.

Czy aktualizacja PrestaShop skasuje mój plik llms.txt?
Przy aktualizacji wykonywanej modułem aktualizującym nie, ponieważ plik nie należy do wydania platformy, a mechanizm aktualizacji przetwarza wyłącznie pliki z wydań. Przy ręcznej podmianie katalogu odpowiadasz za to sam, więc warto trzymać kopię treści poza sklepem.

Który moduł do llms.txt wybrać?
Nie wskazujemy konkretnego, bo rynek zmienia się zbyt szybko. Przed zakupem warto sprawdzić, czy moduł pozwala wpisać własny wstęp, ograniczyć liczbę pozycji, wykluczać treści oraz czy obsługuje Twoje języki i sklepy — to są pytania, które rozstrzygają o użyteczności.

Czy potrzebuję też pliku llms-full.txt?
To wariant z pełną treścią stron zamiast odnośników. Nie jest elementem pierwotnej propozycji formatu, a przy sklepie z dużym katalogiem daje dokument, którego nikt nie przeczyta w całości i który dezaktualizuje się natychmiast. Jeśli moduł oferuje oba, warto zapytać, co konkretnie ma z tego drugiego wyniknąć.

Czy llms.txt poprawi moje pozycje w Google?
Nie. Google pisze wprost, że utrzymywanie takich plików na potrzeby innych usług jego wyszukiwarce ani nie zaszkodzi, ani nie pomoże. Ten plik jest skierowany do asystentów AI.

Mam sklep wielojęzyczny pod jedną domeną. Ile plików potrzebuję?
Po jednym na wersję językową. Jeśli języki rozróżniają podkatalogi w adresie, główny plik leży pod /llms.txt, a wersje językowe pod /en/llms.txt i podobnymi — propozycja formatu dopuszcza pliki na podścieżkach i daje pierwszeństwo bardziej szczegółowemu. Jeśli podkatalogów nie ma, zostaje jeden plik w języku, w którym prowadzisz większość sprzedaży.

Mam kilka tysięcy produktów. Czy wypisywać je wszystkie?
Nie. Ten plik jest skróconą ścieżką wejścia, a nie katalogiem — od kompletnego spisu adresów jest mapa strony. Zamiast produktów warto opisać drogi dojścia do nich: wyszukiwarkę według parametru, tabele doboru, kategorie ułożone tak, jak myśli klient.

Narzędzie wybierzesz w kwadrans, treść napiszesz sam

W PrestaShopie techniczna część tego zadania sprowadza się do jednej decyzji: moduł albo plik ręczny. Obie drogi działają, obie zajmują mniej niż godzinę i obie zostawiają Cię w tym samym miejscu — przed pustym polem, w którym trzeba napisać, czym właściwie jest Twój sklep.

To jest ta część, której nie zrobi za Ciebie żaden generator, bo wymaga wiedzy o tym, czego klienci nie znajdują sami i co rozstrzyga o ich decyzji. Zajmuje kwadrans, a decyduje o tym, czy plik cokolwiek znaczy.

Zacznij więc od sprawdzenia, na czym stoisz: wejdź na adres swojego sklepu z dopiskiem /llms.txt i zobacz, czy cokolwiek się wyświetli. Jeśli nie — wiesz już, że to pole jest puste i nikt go za Ciebie nie wypełni.

A jeśli wolisz zobaczyć całość z zewnątrz, razem z tym, co asystenci wyczytują dziś z Twoich kart produktów — 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.