Markdown4Agents Pro dla PrestaShop — treść sklepu w Markdown dla agentów AI

Cechy i zalety modułu

• Markdown budowany z danych PrestaShop i obsługiwanych modułów treści, a nie przez konwersję wyrenderowanej strony — dokument nie zawiera menu, stopki, formularzy ani kodu innych modułów.
• Radykalnie mniejszy koszt tokenów po stronie agenta: nagłówki x-markdown-tokens oraz X-Markdown-Tokens-Estimate w każdej odpowiedzi podają szacunkową wielkość dokumentu, a panel pokazuje porównanie Markdown kontra HTML dla wskazanej encji.
• Dwa niezależne kanały dostarczania — negocjacja treści na adresie kanonicznym oraz osobne adresy .md — więc agent trafi na treść niezależnie od tego, czy wysyła nagłówek Accept.
• Bezpiecznik diagnostyczny przed włączeniem negocjacji: moduł nie pozwala uruchomić funkcji, zanim nie zmierzy prawdziwymi żądaniami HTTP, że pośrednik cache'ujący nie zatruje wspólnej pamięci podręcznej.
• Zasada „agent nigdy nie widzi więcej niż gość" wdrożona jako reguła, a nie pojedyncze wyjątki — ustawienia widoczności sklepu obowiązują tak samo wobec agentów, jak wobec anonimowego odwiedzającego.
• Ceny liczone w kontekście gościa, z jawnym rozstrzygnięciem waluty i kraju, więc cache nie zapisze ceny jednego klienta i nie poda jej wszystkim pozostałym.
• Pełne wsparcie multistore i wielojęzyczności: ustawienia, pliki llms, cache i licznik są prowadzone osobno dla każdego sklepu i każdego języka.
• Zero zewnętrznych zależności — bez Composera, bez bibliotek zewnętrznych, bez wywołań do usług trzecich; moduł nie wysyła danych Twojego sklepu nigdzie poza odpowiedź na żądanie.
• Statystyki bez identyfikatorów odwiedzających: zapisywane są agregaty dobowe, sklep, kanał, rodzina klienta oraz typ, identyfikator i język dokumentu z czasem ostatniego żądania, bez adresów IP, sesji i pełnego User-Agent.
• Komplet tego, czego szukają walidatory gotowości agentowej: negocjacja treści na głównym adresie sklepu, nagłówek Vary: Accept, licznik tokenów pod standardową nazwą x-markdown-tokens oraz deklaracja Content Signals w robots.txt — bez dopisywania czegokolwiek ręcznie do plików serwera.
• Kompatybilność od PrestaShop 1.7.1.0 do 9.x i od PHP 7.0 do 8.5, zweryfikowana wobec rzeczywistych drzew źródeł, a nie deklaratywnie.

Najważniejsze funkcjonalności modułu

• Negocjacja treści na kanonicznych adresach sklepu: żądanie z Accept: text/markdown otrzymuje dokument Markdown, żądanie przeglądarki otrzymuje niezmieniony HTML.
• Nagłówek Vary: Accept oraz znacznik Link: rel="alternate" na stronach HTML objętych modułem, dzięki czemu pośredniki i agenci wiedzą, że istnieje wersja alternatywna.
• Równoległe adresy markdown/{typ}/{id}.md dla produktów, kategorii, stron CMS, producentów, strony głównej sklepu i zintegrowanych artykułów blogowych, pod własnym prefiksem, żeby nie kolidowały z innymi modułami przepisującymi adresy.
• Zakładka Integracje: obsługa ph_simpleblog, pdfaqspro, pdproductsfaqpro, iqitreviews i productcomments, z osobnym wyborem zakresu publikowanych treści.
• Pulpit statystyk: filtry okresu, kanału i rodziny klienta, wykres dzienny, ranking agentów i klientów oraz 20 najczęściej pobieranych dokumentów.
• Zakładka Content Signals: deklaracja preferencji wobec systemów automatycznych, publikowana w robots.txt — szczegóły w osobnej sekcji poniżej.
• Strona główna sklepu też odpowiada Markdownem — dostaje własny dokument z nazwą i opisem sklepu, głównymi kategoriami i stronami informacyjnymi. To właśnie ten adres sprawdzają domyślnie walidatory gotowości agentowej (isitagentready.com, panel Agent Diagnostics w Cloudflare), więc bez niego sklep z idealnie działającą negocjacją na całym katalogu i tak był oznaczany jako nieprzygotowany.
• Plik llms.txt — krótki spis najważniejszych sekcji sklepu: kategorii najwyższego poziomu, stron informacyjnych, wybranych artykułów blogowych i odnośnika do pełnego indeksu.
• Plik llms-full.txt — zwarty indeks publicznych encji, również artykułów blogowych. Zawiera tytuły, odnośniki i streszczenia, a dla produktów także dostępne dane oferty oraz średnią i liczbę ocen z wybranego źródła opinii. Automatycznie dzielony na części po przekroczeniu skonfigurowanego rozmiaru.
• Generowanie llms-full.txt przez endpoint crona chroniony tokenem lub ręczną przebudowę w panelu, z budżetem czasu i wznawianiem przerwanej pracy. Pełny indeks nie jest budowany podczas zwykłego żądania odwiedzającego.
• Osobny token crona dla każdego sklepu, porównywany w stałym czasie, z gotowym poleceniem curl do skopiowania w panelu.
• Cache wygenerowanego Markdownu w bazie danych z konfigurowalnym czasem życia oraz unieważnianiem hookami przy zmianie produktu, kombinacji, ceny promocyjnej, reguły cenowej, stanu magazynowego, kategorii, strony CMS i producenta.
• Zakładka Diagnostyka: siedem sprawdzeń wykonywanych prawdziwymi żądaniami HTTP przeciwko własnemu punktowi sondującemu modułu, z osobnym rozróżnieniem awarii „HTML podany agentowi" i „Markdown podany przeglądarce".
• Informacyjne sprawdzenie prawdziwego adresu katalogowego po włączeniu negocjacji, prezentowane osobno i niebramkujące funkcji.
• Podgląd dokumentu w panelu dla wskazanego typu i identyfikatora encji, wraz z licznikiem tokenów Markdown kontra HTML i jawnym werdyktem widoczności encji.
• Zakładka Pliki: stan plików llms dla każdego języka (obecność, rozmiar, data, liczba encji, liczba części), przycisk ręcznej przebudowy z budżetem czasu i polecenie crona.
• Licznik trafień agentów: agregat doba × sklep × kanał × rodzina klienta, z podziałem na kanały negocjacja, trasa .md i llms oraz rodziny openai, anthropic, perplexity, google, bing, script, browser i other.
• Nagłówki odpowiedzi zgodne z przeznaczeniem treści: X-Robots-Tag: noindex, nofollow na dokumentach Markdown, X-Content-Type-Options: nosniff, ETag z obsługą 304 oraz zróżnicowana polityka Cache-Control dla adresu kanonicznego i adresu .md.
• Dane produktu w nagłówku dokumentu: typ, identyfikator, adres kanoniczny, adres Markdown, tytuł, opis meta, adres zdjęcia głównego, SKU, marka, cena brutto i netto, waluta, informacja o podatku, dostępność, oznaczenie zestawu, wymóg personalizacji, stan produktu, kategorie, język i data aktualizacji.
• Cena regularna oraz wysokość i procent rabatu, gdy produkt jest objęty promocją — agent nie zobaczy ceny promocyjnej jako zwykłej.
• Tabela wariantów z ceną, ilością, dostępnością i identyfikatorem kombinacji, dzięki czemu agent może wskazać konkretny wariant, a nie tylko go opisać.
• Zawartość zestawów produktowych z ilościami i odnośnikami do dokumentów Markdown poszczególnych pozycji.
• Informacja o wymaganych polach personalizacji, z pominięciem pól należących do innych modułów, których PrestaShop nie pokazuje na froncie.
• Wybór typów encji udostępnianych agentom, egzekwowany jednolicie we wszystkich kanałach: na trasach .md, w plikach llms i w znaczniku wersji alternatywnej.
• Katalog roboczy modułu zabezpieczony przed bezpośrednim odczytem z sieci, a pliki llms serwowane wyłącznie przez kontrolery modułu.
• Respektowanie trybu konserwacji sklepu i geolokalizacji — sklep zamknięty dla odwiedzających jest zamknięty także dla agentów.
• Panel w konwencji PD z nagłówkiem modułu i sześcioma zakładkami: Pulpit, Ustawienia, Integracje, Diagnostyka, Pliki i Content Signals. Pulpit jest ekranem startowym, a ustawieniom towarzyszą objaśnienia ich działania.

Blog i poradniki — integracja z ph_simpleblog

Integracja udostępnia agentom również wiedzę z bloga sklepu: poradniki zakupowe, instrukcje i artykuły informacyjne. Każdy opublikowany i dostępny dla gościa artykuł może mieć własny dokument Markdown oraz odnośnik w plikach llms.

• Dokument artykułu zawiera tytuł, wprowadzenie, treść, autora, kategorię blogową, datę publikacji i aktualizacji oraz adres strony źródłowej.
• Respektowane są aktywność wpisu i jego kategorii, data publikacji, dostęp niezalogowanego gościa, przypisanie do sklepu i dostępność tłumaczenia. Artykuły prywatne i zaplanowane na przyszłość są pomijane.
• Publiczne artykuły trafiają do llms-full.txt, a w krótkim llms.txt pojawia się sekcja bloga i poradników z tytułami, odnośnikami i dostępnymi krótkimi opisami.
• W krótkim przeglądzie można wyświetlić od 0 do 20 artykułów. Własna lista identyfikatorów ustala kolejność; przy pustej liście moduł wybiera najpierw artykuły wyróżnione, a następnie najnowsze. Ustawienie 0 ukrywa tę sekcję, zachowując artykuły w pełnym indeksie.
• Artykuły korzystają z tych samych kanałów dostępu co katalog: adresu Markdown oraz negocjacji treści na stronie źródłowej, gdy odpowiednie funkcje są włączone. Ich dokumenty można sprawdzać w podglądzie w panelu.

FAQ produktów, kategorii i stron CMS

Pytania i odpowiedzi tworzą sekcję dokumentu strony, której dotyczą. Agent otrzymuje opis oferty lub treść strony razem z odpowiedziami na powiązane pytania, na przykład o montaż, dobór produktu, użytkowanie czy warunki usługi.

• pdfaqspro dostarcza FAQ przypisane do produktów, kategorii i stron CMS. Każdy z tych zakresów można włączyć osobno w zakładce Integracje.
• Starszy pdproductsfaqpro jest obsługiwany jako źródło FAQ produktów. FAQ kategorii i CMS wymaga nowszego pdfaqspro. Jeżeli oba moduły są aktywne, pierwszeństwo ma nowszy wariant.
• Publikowane są aktywne pytania z właściwego sklepu i właściwej strony, z uwzględnieniem ustawień publikacji oraz reguł językowych modułu źródłowego. Jeżeli źródło dopuszcza język zastępczy, dokument wskazuje język dołączonej odpowiedzi.
• Jeden dokument może zawierać do 500 pytań i odpowiedzi, w kolejności ustalonej w module FAQ. Puste pytania lub odpowiedzi są pomijane.
• Pliki llms prowadzą do dokumentów produktów, kategorii i CMS z ich sekcjami FAQ. Poszczególne pytania nie tworzą dodatkowych pozycji w indeksie.

Oceny i opinie produktów — iqitreviews oraz productcomments

Dokument produktu może zawierać podsumowanie ocen klientów oraz treść najnowszych publicznych opinii. W panelu wybierasz jedno źródło: iqitreviews albo productcomments, dzięki czemu opinie z dwóch modułów nie są sumowane ze sobą.

• Średnia i liczba ocen są obliczane na podstawie wszystkich opinii publicznych według reguł wybranego modułu, z uwzględnieniem moderacji i ukrywania wpisów.
• Dostępne są dwa zakresy: sama średnia i liczba ocen albo podsumowanie wraz z 1–20 najnowszymi wypowiedziami. Limit tekstów nie ogranicza zbioru ocen używanego do obliczenia średniej.
• Wypowiedzi są wybierane od najnowszych, bez selekcji według wysokości oceny. Zachowują swój oryginalny język i są wyraźnie oznaczone jako opinie klientów.
• Zakres danych pojedynczej opinii obejmuje ocenę, datę, tytuł i treść. Moduł nie dołącza pól z nazwą klienta ani identyfikatorem jego konta.
• W llms-full.txt produkt może otrzymać zwięzłą informację o średniej, liczbie ocen i źródle. Treści wypowiedzi pozostają w dokumencie produktu.

Zakładka Integracje — zakres i aktualność treści

Panel pokazuje, które moduły źródłowe są aktywne w wybranym sklepie. Można osobno włączyć blog, FAQ produktów, FAQ kategorii i FAQ CMS oraz wybrać źródło i zakres opinii. Integracje są opcjonalne, domyślnie wyłączone przy instalacji, a ich ustawienia dotyczą konkretnego sklepu.

Zmiany i usunięcia artykułów, FAQ oraz opinii są sprawdzane przy żądaniu dokumentu Markdown docierającym do sklepu, również wtedy, gdy dokument znajduje się już w cache modułu. Pliki llms.txt i llms-full.txt odświeżają się przy przebudowie w zakładce Pliki lub przez CRON. Kopie przechowywane przez CDN i inne zewnętrzne cache podlegają ustawionemu czasowi ważności odpowiedzi.

Pulpit — statystyki agentów i najczęściej pobieranych treści

Pulpit pozwala zobaczyć, które części sklepu są pobierane w formatach udostępnianych przez moduł. Obejmuje dokumenty katalogu, artykuły blogowe oraz pliki llms.

• Wybór ostatnich 7, 14 lub 30 dni oraz filtrowanie po kanale dostępu i rodzinie agenta lub klienta.
• Podsumowanie liczby żądań, udziału rozpoznanych botów i agentów AI, liczby różnych dokumentów oraz żądań zarejestrowanych z informacją o treści.
• Wykres dzienny z tabelą wartości, ranking rodzin agentów i klientów oraz porównanie kanałów: negocjacja treści, adresy Markdown i pliki llms.
• Ranking 20 najczęściej pobieranych dokumentów z tytułem, typem, językiem, liczbą żądań, udziałem w ruchu treści i czasem ostatniego żądania. Artykuły blogowe pojawiają się z własnym tytułem i odnośnikiem.
• Statystyki dla wybranego sklepu w multistore. Szczegóły treści są zbierane od wdrożenia rozszerzonego licznika; wcześniejsze sumy żądań pozostają dostępne.

Licznik mierzy żądania obsłużone przez moduł, w tym odpowiedzi warunkowe 304, a nie unikalnych odwiedzających. Rozpoznanie rodziny klienta opiera się na deklarowanym User-Agent. Żądania obsłużone w całości przez zewnętrzny cache nie trafiają do statystyk modułu.

Content Signals — deklaracja, na co pozwalasz systemom automatycznym

Sklep, którego treść czytają agenci AI, prędzej czy później staje przed pytaniem, na co właściwie się zgadza. Czy wolno zbudować z niego indeks wyszukiwarki? Czy wolno użyć opisu produktu, żeby odpowiedzieć klientowi na pytanie? Czy wolno wytrenować na tym katalogu model? Content Signals to standard, który pozwala odpowiedzieć na te trzy pytania osobno i opublikować odpowiedź tam, gdzie automaty i tak zaglądają — w pliku robots.txt. Moduł daje na to osobną zakładkę, trzy proste wybory i podgląd tego, co dokładnie trafi do pliku. Specyfikacja: contentsignals.org.

• Indeksowanie w wyszukiwarkach (search) — budowanie indeksu i pokazywanie linków z krótkimi fragmentami. Nie obejmuje streszczeń generowanych przez AI.
• Odpowiadanie na pytania na podstawie Twoich treści (ai-input) — podanie treści modelowi w chwili, gdy ktoś zadaje pytanie, żeby odpowiedź opierała się na nich. Dokładnie tak działają asystenci zakupowi.
• Trenowanie modeli AI (ai-train) — wykorzystanie treści do trenowania lub dostrajania modeli.
• Każda z trzech kategorii ma niezależne ustawienie dozwolone albo niedozwolone, opisane w panelu jednym zdaniem po polsku — nie samą etykietą techniczną, której sprzedawca nie ma obowiązku znać.
• Deklaracja trafia do robots.txt w bloku ograniczonym znacznikami z nazwą modułu. Nic poza tymi znacznikami nie jest parsowane, przepisywane ani przestawiane — Twoje własne reguły i reguły innych modułów zostają nietknięte co do bajtu.
• PrestaShop nadpisuje robots.txt od zera przy każdym kliknięciu „Generuj plik robots.txt" w SEO i adresach URL. Moduł wpisuje wtedy swój blok z powrotem automatycznie, a zakładka i tak pokazuje, czy plik jest aktualny, i pozwala go zapisać ponownie jednym przyciskiem.
• Panel pokazuje przed zapisem, czy plik w ogóle jest zapisywalny — zamiast zgłosić sukces i zostawić Cię z deklaracją, której w pliku nie ma.
• Funkcja instaluje się wyłączona: wpisywanie czegokolwiek do pliku współdzielonego z całym sklepem jest decyzją sprzedawcy, nie modułu. Deinstalacja modułu usuwa blok z powrotem.
• W instalacji multistore panel wprost ostrzega, że PrestaShop trzyma jeden plik robots.txt dla wszystkich sklepów, więc zapisana deklaracja obejmuje każdy z nich.
• To deklaracja preferencji, nie kontrola dostępu: nikogo nie blokuje, a jej uszanowanie jest decyzją drugiej strony. Moduł mówi to wprost, zamiast sugerować ochronę, której ten mechanizm nie daje.

Zastosowanie biznesowe

• Dla sklepów PrestaShop, które chcą być poprawnie odczytywane przez asystentów zakupowych i agentów AI, zamiast liczyć na to, że model samodzielnie odszumi stronę HTML.
• Dla sprzedawców, którzy chcą kontrolować, co dokładnie trafia do agentów — zakres typów encji, widoczność cen i ilości, oraz sposób publikacji.
• Dla sklepów z rozbudowanym katalogiem, w którym różnica między pełną stroną HTML a dokumentem Markdown przekłada się na realną różnicę kosztu po stronie odpytującego.
• Dla sklepów prowadzących blog i bazę FAQ, które chcą udostępnić agentom porady, odpowiedzi na pytania i opinie klientów razem z ofertą produktową.
• Dla wdrożeń multistore, gdzie każdy sklep wymaga własnych ustawień, własnych plików llms i własnego tokenu crona.
• Dla firm, które chcą oprzeć decyzję o dalszych inwestycjach w ten kanał na danych — licznik trafień pokazuje, czy i którędy agenci faktycznie pytają.
• Dla sklepów pracujących za CDN lub reverse proxy, gdzie samodzielne włączenie negocjacji treści bez weryfikacji groziłoby podaniem niewłaściwej wersji strony zwykłym klientom.

Czego moduł nie robi

• Nie jest modułem SEO i nie poprawia pozycji sklepu w wynikach wyszukiwania Google — dokumenty Markdown są jawnie oznaczone jako nieindeksowane.
• Zachowuje wygląd i treść strony HTML widzianej przez klientów, dodając informację o alternatywnej wersji Markdown w nagłówkach HTTP i znaczniku odnośnika.
• Nie wysyła danych sklepu do żadnej usługi zewnętrznej i nie wymaga konta ani klucza API.
• Nie egzekwuje Content Signals i nie może tego robić: deklaracja w robots.txt jest wyrażeniem preferencji, a nie kontrolą dostępu — nikogo nie blokuje, a jej uszanowanie pozostaje decyzją drugiej strony. Moduł nie modyfikuje pozostałych reguł w tym pliku.
• Nie wykonuje automatycznych tłumaczeń. Nazwy pól dokumentu pozostają stałe i angielskie, treść stron i artykułów korzysta z dostępnych tłumaczeń, FAQ respektuje reguły językowe modułu źródłowego, a opinie zachowują język wypowiedzi klienta.

Kompatybilność

• PrestaShop: 1.7.1.0 - 9.x
• PHP: 7.0 - 8.5
• Bez Composera i bez zewnętrznych bibliotek
• Multistore: tak, ustawienia i pliki prowadzone osobno dla każdego sklepu
• Wielojęzyczność: tak, dokumenty i pliki llms dla każdego aktywnego języka