Kiedy klient pyta ChatGPT albo Perplexity o twoje ceny i dostaje liczbę sprzed dwóch cenników wstecz, łatwo obwinić model. W praktyce wina najczęściej leży po stronie źródła. Modele nie zmyślają w próżni: rekonstruują odpowiedź z tego, co udało im się odczytać na twojej stronie. Jeśli cena jest zapisana w grafice, limity opisane w rozwlekłym akapicie, a lista integracji ładuje się dopiero po kliknięciu, model dostaje strzępy i skleja je z tym, co pamięta z treningu.
Dokumentacja produktu jest tu najważniejszym aktywem. To ona, a nie blog i nie landing page, odpowiada na pytania o ceny, limity i kompatybilność. Poniżej konkretne zasady, dzięki którym asystent AI będzie miał z czego zbudować poprawną odpowiedź.
Skąd model bierze fakty o twoim produkcie
Warto rozdzielić dwa zupełnie różne kanały. Pierwszy to dane treningowe, czyli zamrożona migawka sieci sprzed wielu miesięcy. Drugi to pobranie strony na żywo w momencie zadania pytania, kiedy asystent sięga po aktualny HTML. Te ścieżki mają inne opóźnienia i inne ograniczenia techniczne, co szczegółowo rozkładamy w tekście o tym, czym różni się crawler treningowy od bota pobierającego stronę na żywo.
Konsekwencja jest prosta. Na dane treningowe nie masz wpływu, bo one już zostały utrwalone. Masz za to pełną kontrolę nad tym, co bot zobaczy dzisiaj. Jeżeli dzisiejsza wersja strony jest jednoznaczna, model ma mocną podstawę, żeby nadpisać przestarzałe wspomnienie. Jeżeli jest mętna, wraca do pamięci i podaje starą cenę z pełnym przekonaniem.
Druga rzecz to zasięg. Model czyta zwykle jedną, może dwie podstrony, a nie całą witrynę. Fakt rozproszony po pięciu miejscach jest dla niego faktem nieistniejącym. Wszystkie kluczowe liczby muszą dać się odczytać z jednego adresu URL, bez logowania i bez kliknięć.
Strona cennika jako źródło kanoniczne
Ustal jeden adres, który jest jedynym prawdziwym cennikiem, i konsekwentnie na niego linkuj z dokumentacji, FAQ i stopki. Wszystkie inne wzmianki o cenie powinny być linkiem do tej strony, a nie skopiowaną liczbą. Kopie zawsze rozjeżdżają się w czasie, a model, który znajdzie dwie sprzeczne wartości, wybierze losowo albo poda obie.
Na samej stronie cennika trzymaj się kilku reguł:
- cena jako zwykły tekst w HTML, nigdy jako obraz ani element renderowany wyłącznie przez JavaScript,
- pełna kwota widoczna bez interakcji, także dla planu rocznego (przełącznik miesiąc/rok ukrywa połowę faktów przed botem),
- jawna informacja o VAT oraz o tym, czy cena jest za użytkownika, czy za konto,
- nazwa planu identyczna wszędzie, bez wariantów typu Pro, PRO i Professional na trzech podstronach,
- osobny akapit z warunkami darmowego planu i długością okresu próbnego.
Warto dołożyć dane strukturalne. Schema.org udostępnia typy Product i Offer z polami price, priceCurrency i priceValidUntil, a wymagania po stronie wyszukiwarki opisuje dokumentacja Google Search Central. Schema nie jest magiczna, ale usuwa dwuznaczność: liczba w znaczniku ma jednoznaczne pole i jednoznaczną walutę, więc nie ma czego interpretować.
Limity i quoty: tabela zamiast opisu w akapicie
Najgorszy format limitów to zdanie w stylu: w wyższych planach limity są odpowiednio większe, a przy dużym wolumenie zapraszamy do kontaktu. Człowiek to zniesie, model wyprodukuje z tego liczbę wziętą z sufitu.
Limity opisuj tabelą, w której wiersz to zasób, a kolumna to plan. Każda komórka zawiera liczbę i jednostkę, nigdy samo słowo bez wartości.
| Zasób | Start | Team | Business |
|---|---|---|---|
| Zapytania API | 10 000 / miesiąc | 100 000 / miesiąc | 1 000 000 / miesiąc |
| Limit szybkości | 5 zapytań / sekundę | 20 zapytań / sekundę | 100 zapytań / sekundę |
| Użytkownicy w koncie | 3 | 25 | bez limitu |
| Retencja danych | 30 dni | 12 miesięcy | 36 miesięcy |
Pod tabelą dopisz jednym zdaniem, co dzieje się po przekroczeniu limitu: twarda blokada, kolejkowanie czy naliczanie nadwyżki. To pytanie pada w rozmowach z asystentami bardzo często, a odpowiedź prawie nigdy nie jest nigdzie zapisana.
Ta sama logika dotyczy kart produktowych w sklepach, gdzie parametry muszą być odczytywalne wprost z HTML. Zasady formatowania takich danych rozpisaliśmy w poradniku o tym, jakie dane muszą być w HTML karty produktu.
Lista integracji, którą da się odczytać maszynowo
Katalogi integracji to zwykle siatka logotypów z filtrowaniem po stronie klienta. Dla bota jest to pusta strona. Model widzi nagłówek, widzi wyszukiwarkę i nie widzi ani jednej nazwy narzędzia, więc na pytanie o integrację z konkretnym systemem odpowiada wymijająco albo potwierdza coś, czego nie ma.
Minimalna poprawka polega na dołożeniu tekstowej listy wszystkich integracji renderowanej po stronie serwera, poniżej siatki logotypów. Przy każdej pozycji podaj nazwę dostawcy, typ połączenia (natywne, przez webhooki, przez platformę pośredniczącą) oraz plan, od którego integracja jest dostępna. Jeśli coś działa tylko jednokierunkowo, napisz to wprost, bo model nie domyśli się tego z ikony strzałki.
Każda integracja zasługuje też na własną podstronę pod stabilnym adresem. Dzięki temu asystent może zacytować dokładnie ten jeden URL zamiast opisywać z pamięci całą kategorię. Przy okazji rosną szanse, że produkt trafi do zestawień generowanych przez modele, co opisujemy w materiale o tym, jak budować rankingi i porównania cytowane przez AI.
Jednostki, waluty i okresy rozliczeniowe bez dwuznaczności
Większość halucynacji cenowych to nie zmyślona liczba, tylko poprawna liczba w złym kontekście. Model bierze 49 z planu rocznego i podaje jako cenę miesięczną, albo miesza złotówki z euro, bo na stronie stoi samo 49 bez symbolu waluty.
Praktyczne zasady:
- Waluta zawsze przy kwocie, w tym samym węźle tekstowym. Nie w nagłówku sekcji dwa akapity wyżej.
- Okres rozliczeniowy zapisany słowem: 49 zł miesięcznie przy płatności rocznej, a nie 49 zł z gwiazdką i przypisem na dole.
- Jednostki rozwinięte przy pierwszym użyciu. Skrót GB czy TPS jest oczywisty dla ciebie, nie dla modelu tłumaczącego to na inny język.
- Zakresy zapisane z pełnymi wartościami po obu stronach: od 10 000 do 50 000 zapytań, zamiast 10 000+.
- Brak liczb wyłącznie w grafikach porównawczych. Jeśli infografika zawiera dane, powtórz je w tekście pod nią.
Osobna pułapka to ceny promocyjne. Przekreślona stara cena i nowa obok siebie w jednym bloku to dla modelu dwie równorzędne liczby. Oznacz promocję jawnie i podaj datę jej zakończenia, najlepiej także w polu priceValidUntil.
Wersjonowanie i daty aktualizacji
Model musi umieć ocenić, czy patrzy na aktualny dokument. Data ostatniej aktualizacji widoczna w treści, nie tylko w metadanych, jest tu najtańszym sygnałem. Dopisz ją nad pierwszym nagłówkiem i aktualizuj przy każdej realnej zmianie, a nie przy każdym deployu, bo data zmieniająca się codziennie przestaje cokolwiek znaczyć.
Przy dokumentacji API dołóż jawny numer wersji i osobną stronę z historią zmian. Stare wersje zostaw dostępne pod własnymi adresami, ale oznacz je jako wycofane i podlinkuj do aktualnej. Bez tego model trafia na archiwalny endpoint i podaje go jako obowiązujący.
Jeżeli chcesz wskazać botom, które dokumenty są kanoniczne, pomaga plik z mapą najważniejszych zasobów. Wdrożenie krok po kroku opisaliśmy w poradniku o tym, jak wdrożyć llms.txt na stronie. To nie jest gwarancja niczego, ale kosztuje kilkanaście minut i porządkuje hierarchię źródeł.
Jak przetestować, co model mówi o tobie
Zgadywanie nie ma sensu, testowanie zajmuje pół godziny. Przygotuj listę 15–20 pytań, które realnie zadaje klient przed zakupem: ile kosztuje plan dla pięciu osób, czy jest integracja z konkretnym systemem, jaki jest limit zapytań, czy da się wyeksportować dane po rezygnacji.
Zadaj każde pytanie w co najmniej trzech asystentach i zapisz odpowiedź razem ze źródłami, które podał. Interesują cię trzy rzeczy: czy liczba jest poprawna, czy podane źródło to twoja domena, oraz czy model w ogóle podjął próbę pobrania strony. Odpowiedź bez cytowania oznacza zwykle, że model korzystał z pamięci, więc problem leży w dostępności treści, nie w jej treści.
Każdy błąd przypisz do konkretnej przyczyny: dane w grafice, dane za JavaScriptem, sprzeczne kopie, brak jednostki, brak daty. Napraw źródło i powtórz test po dwóch tygodniach. Ważne, żeby porównywać te same pytania w tej samej kolejności, bo inaczej nie odróżnisz poprawy od losowej zmienności modelu.
Do rutyny warto dołożyć podgląd logów serwera pod kątem tego, czy boty AI faktycznie odwiedzają dokumentację i z jakim kodem odpowiedzi. Jeśli twoja strona cennika zwraca im 403, żadne porządkowanie treści nie pomoże.
FAQ
Czy dane strukturalne wystarczą, żeby model podawał poprawną cenę?
Nie, ale bardzo pomagają. Schema.org usuwa dwuznaczność co do waluty, okresu i wartości, natomiast model i tak czyta widoczny tekst strony. Najlepiej działa połączenie obu warstw: czytelna cena w HTML plus zgodny z nią znacznik.
Jak często aktualizować dokumentację, żeby model nadążał?
Przy każdej zmianie faktu, czyli ceny, limitu, listy integracji lub warunków planu. Nie ma sensu podbijać daty aktualizacji bez zmiany treści. Ponowne pobranie strony przez boty zajmuje zwykle od kilku dni do kilku tygodni, zależnie od tego, jak często witryna jest odwiedzana.
Czy blokowanie botów AI ochroni mnie przed halucynacjami?
Efekt jest odwrotny. Zablokowany bot nie zobaczy aktualnych danych i oprze się wyłącznie na pamięci z treningu, czyli na wersji sprzed miesięcy. Blokada ma sens jako decyzja licencyjna, nie jako sposób na poprawność informacji.
Co zrobić, gdy model uparcie podaje starą cenę mimo poprawek?
Sprawdź w tej kolejności: czy cena jest w HTML, czy strona nie zwraca botowi błędu lub przekierowania, czy nie istnieje druga podstrona ze starą kwotą, oraz czy w treści jest widoczna data aktualizacji. W praktyce najczęstszą przyczyną jest zapomniana kopia cennika na starym landingu.
Czy dokumentację warto dublować w formacie Markdown?
Tak, jeśli koszt utrzymania jest niski. Wersja tekstowa pod stabilnym adresem jest łatwiejsza do sparsowania niż strona z pełnym interfejsem. Kluczowe jest jednak to, żeby obie wersje pochodziły z jednego źródła danych i nie mogły się rozjechać.