Pytasz ChatGPT o własną firmę i dostajesz odpowiedź prawdziwą dwa lata temu. Stara nazwa spółki, cennik sprzed dwóch podwyżek, adres biura, z którego wyprowadziliście się w zeszłym roku. Klient dostaje to samo, tylko nie wie, że dane są nieaktualne, więc dzwoni pod nieistniejący numer albo pyta o pakiet, którego nie sprzedajecie.
To nie jest błąd, który da się zgłosić formularzem. Model nie ma przycisku „popraw dane o mojej firmie”. Ma za to kilka mechanizmów, przez które stara wersja faktów trafiła do odpowiedzi, i każdy naprawia się inaczej. Poniżej rozkładamy je na czynniki pierwsze i podajemy kolejność działań, która skraca czas korekty.
Trzy powody, dla których model zna starą wersję faktów
Zanim cokolwiek zmienisz, ustal, z którym przypadkiem masz do czynienia. Leczenie niewłaściwej przyczyny to zwykle kilka straconych tygodni.
- Pamięć treningowa. Fakt siedzi w wagach modelu, bo znalazł się w danych treningowych. Model odpowiada z pamięci, bez sięgania do sieci. Twoja strona może być aktualna od miesięcy, a odpowiedź i tak będzie stara.
- Świeże pobranie złego źródła. Model faktycznie wchodzi do sieci, ale trafia na katalog, agregator albo stary artykuł prasowy, który powiela nieaktualne dane. Twoja strona istnieje, tylko przegrała rywalizację o cytowanie.
- Niejednoznaczność w twoich własnych danych. Aktualna informacja jest na stronie, ale obok niej wciąż żyje stara: w archiwalnym wpisie, w PDF-ie do pobrania, w stopce podstrony nietkniętej od rebrandingu. Model widzi dwie wersje i wybiera tę lepiej udokumentowaną.
Prosty test: zapytaj model dwa razy, raz normalnie, raz z poleceniem sprawdzenia twojej strony teraz. Jeśli po wymuszeniu pobrania odpowiedź się poprawia, problem leży w pamięci treningowej albo w rywalizacji źródeł. Jeśli nadal jest zła, masz sprzeczne dane we własnym serwisie.
Cache treningowy kontra świeże pobranie strony
Rozróżnienie między tym, co model pamięta, a tym, co pobiera w momencie zapytania, jest kluczowe dla całej reszty tego tekstu. Opisaliśmy je przy okazji tematu crawlera treningowego i bota pobierającego stronę na żywo: to dwa różne systemy, o różnych user agentach i różnym harmonogramie.
Konsekwencja praktyczna: aktualizacja strony wpływa natychmiast tylko na tryb z wyszukiwaniem, a na odpowiedzi z pamięci nie wpływa wcale, dopóki nie pojawi się kolejna wersja modelu. Celem nie jest więc „poprawienie modelu”, tylko doprowadzenie do sytuacji, w której model woli sięgnąć po świeże dane, a kiedy sięgnie, trafia na twoje źródło, nie na cudze.
| Objaw | Prawdopodobna przyczyna | Co naprawiać |
|---|---|---|
| Zła odpowiedź bez cytowań | Pamięć treningowa | Sygnały świeżości, czekanie na kolejny trening |
| Zła odpowiedź z linkiem do cudzej strony | Przegrana rywalizacja źródeł | Prostowanie danych u źródła, wzmocnienie własnej strony |
| Zła odpowiedź z linkiem do twojej strony | Sprzeczne dane u ciebie | Audyt własnego serwisu, usunięcie starych wersji |
| Model odmawia odpowiedzi o firmie | Brak danych albo blokada crawlera | Weryfikacja robots.txt i dostępności treści |
Zewnętrzne źródła powielające nieaktualne dane
Najczęstszy scenariusz wygląda tak: firma zmienia nazwę albo adres, aktualizuje własną stronę i uznaje temat za zamknięty. Tymczasem stara wersja żyje dalej w kilkunastu niekontrolowanych miejscach: wpisy w katalogach branżowych, profile w bazach firm, artykuły sponsorowane sprzed lat, notki prasowe, wizytówki na portalach regionalnych.
Model, który waży wiarygodność, widzi jedno źródło mówiące X (twoja strona) i dziesięć mówiących Y (reszta sieci). Zgadnij, co wybierze. To ten sam mechanizm, przez który katalogi firm wciąż mają znaczenie, choć dawno straciły wartość linkową: nie budują rankingu, budują konsensus faktograficzny.
Zanim zaczniesz pisać maile z prośbą o korektę, zrób inwentaryzację. Wyszukaj w Google starą nazwę, stary adres i stary numer telefonu w cudzysłowie. Dostaniesz listę miejsc do obdzwonienia, zwykle krótszą, niż się obawiasz.
Aktualizacja własnych stron: co zmienić w pierwszej kolejności
Kolejność ma znaczenie, bo nie wszystkie miejsca ważą tyle samo. Zacznij od tych, po które model sięga najpierw.
- Strona „O nas” i kontaktowa. Kanoniczne źródło danych firmowych: pełna nazwa prawna, NIP, adres, telefon, mail, godziny pracy, wszystko w tekście HTML, nie w grafice.
- Dane strukturalne Organization i LocalBusiness. Pole
sameAsjest tu najbardziej niedoceniane: wiąże twoją stronę z profilami w innych serwisach i pomaga modelowi rozstrzygnąć, że mówimy o tym samym podmiocie. - Stopka na wszystkich podstronach. Jedno źródło prawdy, generowane z szablonu, nie wklejane ręcznie. Najczęstsze miejsce, gdzie zostaje stary adres.
- Cennik. Opatrz ceny datą obowiązywania, a archiwalne wersje usuń albo wyraźnie oznacz jako nieaktualne.
- Archiwalne wpisy na blogu. Wpisy sprzed rebrandingu potrafią rankować lepiej niż nowa strona „O nas”.
- Pliki do pobrania. PDF-y, prezentacje, cenniki. Są indeksowane, a nikt o nich nie pamięta.
Osobny przypadek to firmy z dokumentacją produktową: jeśli model odpowiada na pytania o limity, ceny czy integracje, wchodzi zwykle do docs, nie na stronę marketingową. Zasady opisu takich treści zebraliśmy w tekście o changelogu i stronie statusu jako źródle dla AI. To najbardziej niedoszacowany element układanki: publiczny changelog z datami wprost mówi modelowi, która wersja faktu jest nowsza.
Prostowanie danych w katalogach i serwisach trzecich
Po uporządkowaniu własnego podwórka bierzesz się za resztę. Priorytety ustaw według widoczności, nie według liczby wpisów.
- Profil Firmy w Google. Wciąż najsilniejsze pojedyncze źródło danych lokalnych i coraz częściej wykorzystywane przez modele. Szczegóły w naszym przewodniku po local SEO w Polsce.
- Rejestry publiczne. KRS, CEIDG, REGON. Zmiana propaguje się do dziesiątek agregatorów zaciągających z nich dane, więc jeden wniosek naprawia wiele wpisów naraz.
- Agregatory danych firmowych. Aleo, Panorama Firm i podobne. Większość ma formularz korekty, część wymaga maila z domeny firmowej.
- Wikipedia i Wikidata. Jeśli firma ma tam wpis, waży on dla modeli nieproporcjonalnie dużo. Wikidata jest szczególnie istotna, bo trafia do grafów wiedzy w postaci ustrukturyzowanej. Poprawka wymaga źródła zewnętrznego: najpierw komunikat prasowy, potem edycja.
- Media i portale branżowe. Prośba o dopisek redakcyjny działa lepiej niż prośba o usunięcie: redakcje niechętnie kasują archiwum, ale chętnie dodają notkę z datą.
Realistyczne oczekiwania: rejestry i Profil Firmy zmienisz w kilka dni, agregatory w dwa do sześciu tygodni, część nigdy. Nie blokuj całego projektu na najtrudniejszych przypadkach.
Sygnały świeżości, które przyspieszają korektę
Sama poprawna treść nie wystarczy, jeśli model nie ma powodu sądzić, że jest nowsza od tego, co już zna. Sygnały świeżości to zestaw wskazówek, które to komunikują.
- Widoczna data aktualizacji w treści strony, nie tylko w metadanych. Format jednoznaczny, najlepiej z nazwą miesiąca, żeby uniknąć pomyłki w kolejności dnia i miesiąca.
- Pola
dateModifiedidatePublishedw danych strukturalnych, spójne z tym, co widać na stronie. - Nagłówek
Last-Modifiedi obsługaIf-Modified-Sincepo stronie serwera. Tanie do wdrożenia, a wprost mówi crawlerowi, że zasób się zmienił. - Sitemap z aktualnym
lastmod, faktycznie odzwierciedlającym zmiany, a nie przestawianym przy każdym przebudowaniu cache. - Jawne zdanie w treści, na przykład „Od stycznia 2026 firma działa pod nazwą X, wcześniej Y”. Model potrzebuje tekstu, który wprost łączy starą wersję z nową, bo inaczej traktuje je jako dwa niezależne podmioty.
Ostatni punkt jest najskuteczniejszy i najczęściej pomijany. Usunięcie starej nazwy wydaje się intuicyjne, ale odbiera modelowi możliwość powiązania faktów. Lepiej zostawić zdanie porządkujące historię, niż wymazać ją całkowicie.
Ile czasu zajmuje zmiana odpowiedzi modelu
Odpowiedź zależy od trybu, w którym pracuje model. Warto zakomunikować to zarządowi zawczasu, żeby uniknąć rozczarowania po tygodniu.
| Kanał | Typowy czas korekty | Od czego zależy |
|---|---|---|
| Odpowiedź z wyszukiwaniem na żywo | od kilku dni do 3 tygodni | Ponowne pobranie strony, aktualizacja indeksu wyszukiwarki |
| Odpowiedź z pamięci modelu | miesiące, do kolejnej wersji | Harmonogram treningu dostawcy |
| Wyniki oparte o graf wiedzy | 2 do 8 tygodni | Propagacja z rejestrów i Wikidata |
| Cytowania z katalogów | 2 do 6 tygodni | Tempo reakcji operatora katalogu |
Wniosek operacyjny: pierwsze efekty zobaczysz w trybie z wyszukiwaniem i to on powinien być miarą sukcesu w pierwszym miesiącu. Odpowiedzi z pamięci wyrównają się przy kolejnej aktualizacji modelu i nie ma sensu ich forsować.
Monitoring: jak wychwycić nawrót błędu
Nieaktualne dane wracają. Ktoś zaciągnie stary feed, agregator odświeży bazę ze snapshotu sprzed roku, redakcja przedrukuje archiwalny materiał. Bez monitoringu dowiesz się o tym od klienta.
Minimalny zestaw, który da się utrzymać bez dedykowanego etatu:
- Stały zestaw pytań kontrolnych, pięć do dziesięciu, zadawanych raz w miesiącu w każdym modelu używanym przez twoich klientów. Te same sformułowania, odpowiedzi zapisywane z datą. Bez powtarzalności nie zmierzysz zmiany.
- Alert Google na starą nazwę i stary adres. Wychwytuje nowe publikacje powielające błąd.
- Kontrola logów serwera pod kątem wizyt botów AI. Jeśli zaktualizowana strona nie została pobrana od miesięcy, żadna poprawka treści nie zadziała. Konfigurację opisaliśmy w tekście o monitoringu botów AI w logach serwera.
- Kwartalny przegląd katalogów z listy zbudowanej przy inwentaryzacji.
Jedna uwaga o mierzeniu: nie traktuj pojedynczej odpowiedzi jako dowodu poprawy. Modele generują wariantywnie, więc ta sama konfiguracja da dwa różne wyniki. Miarą jest odsetek odpowiedzi z poprawnym faktem w serii kilku prób, nie zrzut ekranu.
FAQ
Czy mogę zgłosić poprawkę danych bezpośrednio do OpenAI albo Google?
Nie ma kanału gwarantującego korektę konkretnego faktu. Dostawcy przyjmują zgłoszenia treści szkodliwych i naruszeń prawa, ale nie prowadzą obsługi poprawek faktograficznych o firmach. Realną drogą jest zmiana źródeł, z których model korzysta.
Usunąłem starą nazwę ze strony, a model nadal jej używa. Dlaczego?
Prawdopodobnie z dwóch powodów naraz. Po pierwsze fakt może siedzieć w pamięci treningowej i nie zmieni się przed kolejną wersją modelu. Po drugie, usuwając starą nazwę całkowicie, odebrałeś modelowi możliwość powiązania jej z nową. Skuteczniejsze jest zdanie wprost opisujące zmianę wraz z datą.
Czy dane strukturalne wystarczą, żeby naprawić błąd?
Same nie wystarczą, ale bez nich naprawa jest wolniejsza. Schema Organization z polami name, address, telephone i sameAs daje maszynowo czytelny zapis faktów i wiąże stronę z profilami zewnętrznymi. Przyspiesza to rozstrzygnięcie sprzeczności, ale nie zastępuje korekty u źródeł trzecich.
Co jeśli błędne dane pochodzą z artykułu w dużym portalu?
Poproś redakcję o dopisek aktualizacyjny z datą zamiast o usunięcie tekstu. Redakcje rzadko kasują archiwum, ale notki sprostowujące dodają chętnie. Dla modelu artykuł z widoczną adnotacją „aktualizacja: dane zmienione w 2026” jest jednoznacznym sygnałem, która wersja obowiązuje.
Jak często sprawdzać, czy model podaje poprawne dane?
Raz w miesiącu wystarczy przy stałym zestawie pytań kontrolnych, po każdej istotnej zmianie danych firmowych warto sprawdzić dodatkowo po dwóch i po sześciu tygodniach. Kluczowa jest powtarzalność pytań, bo tylko wtedy porównanie odpowiedzi cokolwiek znaczy.
Czy blokada botów AI pomoże, skoro i tak podają złe dane?
Nie, zadziała odwrotnie. Blokada nie usuwa faktów już obecnych w pamięci modelu, a odbiera mu dostęp do twojej poprawionej wersji. Efekt jest taki, że jedynym dostępnym źródłem zostają katalogi i archiwa z nieaktualnymi danymi.