Googlebot przestał sprzątać po webmasterach. Wyszukiwarka zmieniła sposób wyciągania danych strukturalnych JSON-LD i stosuje już tylko jedno przejście odkodowywania encji HTML zamiast dwóch. Efekt jest cichy i nieprzyjemny: bloki schema, które działały latami, mogą od teraz zwracać krzaki albo w ogóle przestać się parsować.
O zmianie poinformował Gary Illyes z Google w publicznym wpisie na LinkedIn, a szerzej opisał ją serwis Search Engine Roundtable w materiale z 21 sierpnia 2026 roku. Nie towarzyszy jej ani wpis na blogu Search Central, ani komunikat w Search Console. To klasyczna zmiana infrastrukturalna: nie widać jej w rankingu, widać ją dopiero w raporcie „Ulepszenia” albo w teście wyników z elementami rozszerzonymi, kiedy jest już za późno.
Co dokładnie się zmieniło
Do tej pory parser Google zachowywał się liberalnie. Kiedy natrafiał na string w JSON-LD, który po pierwszym odkodowaniu encji HTML nadal zawierał encje HTML, wykonywał drugie przejście i rozwijał je do końca. Dzięki temu podwójnie zakodowane ciągi, w rodzaju zapisu encji ampersanda czy encji numerycznej znaczka „check”, ostatecznie trafiały do indeksu jako czytelne znaki.
Teraz Googlebot robi dokładnie jedno przejście. Wszystko, co po tym jednym przejściu nadal wygląda jak encja HTML, zostaje w stringu jako dosłowny tekst. Nazwa produktu, która w zamyśle miała brzmieć „Kawa & Herbata”, może wylądować w danych strukturalnych jako ciąg znaków z widoczną encją. Google nie zgłosi tego jako błędu składni, bo z punktu widzenia JSON to poprawny string. Po prostu wartość będzie zła.
Illyes uzasadnił zmianę wprost: escapowanie w JSON jest, jak to ujął, bardzo dobrze zdefiniowane w RFC 8259, konkretnie w sekcji 7. Google przestaje więc kompensować błędy implementacji po stronie stron i zaczyna trzymać się standardu. Rekomendacja jest równie prosta: używać standardowych escape’ów JSON albo escape’ów unicode w zapisie szesnastkowym, na przykład sekwencji rozpoczynającej się od backslasha i litery „u” dla ampersanda.
Kluczowe fakty
| Element | Stan przed zmianą | Stan po zmianie |
|---|---|---|
| Liczba przejść odkodowania encji HTML | Dwa (parser rozwijał podwójne kodowanie) | Jedno |
| Podwójnie zakodowane encje | Rozwijane do czystego znaku | Zostają w wartości jako tekst |
| Zalecany zapis znaków specjalnych | Brak twardej rekomendacji | Escape JSON lub unicode hex |
| Podstawa normatywna | Zachowanie tolerancyjne | RFC 8259, sekcja 7 |
| Kanał komunikacji | Brak | Wpis Gary’ego Illyesa na LinkedIn |
| Sygnalizacja błędu | Nie dotyczy | Brak twardego błędu składni, wartość po prostu błędna |
| Zasięg | Nie dotyczy | Wyłącznie JSON-LD, bez Microdata i RDFa |
Warto podkreślić, czego zmiana nie obejmuje. Google nadal rekomenduje JSON-LD jako preferowany format danych strukturalnych i nadal czyta go zarówno z sekcji head, jak i z body dokumentu. Nie jest to też aktualizacja algorytmu rankingowego i nie pojawiła się na Search Status Dashboard, gdzie w sierpniu 2026 odnotowano tylko jeden incydent: spam update, który zakończył się 21 sierpnia po dwóch dniach i szesnastu godzinach.
Skąd w ogóle bierze się podwójne kodowanie
Mechanizm jest prostszy, niż się wydaje, i właśnie dlatego tak łatwo go przeoczyć. Blok JSON-LD żyje wewnątrz dokumentu HTML, ale sam nie jest HTML-em. To osobny język o własnych regułach escapowania. Problem pojawia się, gdy narzędzie budujące stronę traktuje zawartość tego bloku tak samo jak każdy inny fragment szablonu.
Typowa ścieżka wygląda tak. Wartość pobierana z bazy danych zawiera znak specjalny. Warstwa szablonu, w trosce o bezpieczeństwo, uruchamia na niej funkcję escapującą HTML. Wartość jest już zakodowana raz. Następnie ta sama wartość trafia do bloku JSON-LD, gdzie sposób jej zapisu zależy od tego, czy kod używa prawdziwej serializacji JSON, czy po prostu skleja tekst. W drugim wypadku encja zostaje w środku, a jeżeli po drodze zadziała jeszcze jedna warstwa escapowania, sam ampersand encji zostaje zakodowany po raz kolejny. Powstaje wartość zakodowana dwukrotnie.
Przez lata nic złego się nie działo, bo parser Google to naprawiał. Zachowanie tolerancyjne było jednak niewidzialną protezą, która maskowała błąd w kodzie. Zdjęcie tej protezy ujawnia problem, który istniał od początku, tylko nikt nie miał powodu, żeby go zauważyć.
Kogo to realnie dotknie
Nie każdego. Poprawnie zbudowany JSON-LD, w którym string jest generowany przez bibliotekę serializującą JSON, nie ma z tym najmniejszego problemu. Kłopot zaczyna się tam, gdzie dane strukturalne powstają przez sklejanie szablonu tekstowego.
- Szablony PHP i motywy WordPress budujące schema przez konkatenację stringów. Jeśli w kodzie leci funkcja escapująca HTML na wartości, która potem trafia do bloku JSON-LD, encja zostaje zakodowana dwa razy: raz przez funkcję, raz przez sam kontekst dokumentu.
- Generatory statyczne i frameworki, które domyślnie escapują zmienne w interpolacji. To najczęstszy źródłowy błąd: framework robi to, do czego został zaprojektowany, czyli chroni przed XSS w HTML, ale JSON-LD nie jest HTML-em.
- Wtyczki i integracje e-commerce, gdzie nazwy produktów, warianty i opisy są pobierane z bazy już w formie zakodowanej. Ampersand w nazwie marki to najczęstszy realny przypadek.
- Feedy i eksporty od zewnętrznych dostawców, przekazywane dalej bez normalizacji, oraz treści migrowane ze starszych systemów CMS, gdzie encje siedzą wprost w bazie.
- Ręcznie wklejane bloki schema w edytorach WYSIWYG, które przy zapisie potrafią zakodować zawartość pola tekstowego.
W praktyce najbardziej narażone są pola tekstowe, które człowiek widzi w wyniku wyszukiwania: nazwa produktu, nagłówek artykułu, nazwa organizacji, treść pytania w FAQ, autor, opis w polu description. Tam podwójne kodowanie od razu psuje prezentację. Pola techniczne, jak identyfikator czy data, cierpią rzadziej, bo zwykle nie zawierają znaków wymagających escapowania. Wyjątkiem są adresy URL z parametrami zapytania, gdzie ampersand jest normalnym elementem składni i właśnie tam podwójne kodowanie potrafi rozbić cały link, a więc także powiązanie encji, do którego ten link prowadzi.
Co to znaczy dla SEO
Bezpośrednia konsekwencja to utrata kwalifikacji do wyników z elementami rozszerzonymi. Jeśli wymagane pole zawiera śmieciową wartość, Google może uznać markup za niezgodny z wytycznymi jakościowymi i przestać wyświetlać gwiazdki, ceny, breadcrumbs czy rozwijane FAQ. To nie jest kara, tylko utrata funkcji, ale w raportach wygląda identycznie: nagły spadek CTR bez zmiany pozycji. Diagnoza idzie wtedy zwykle w złą stronę, w rewrite tytułów i opisów, podczas gdy przyczyna siedzi w warstwie technicznej.
Drugi, poważniejszy skutek jest wolniejszy i trudniejszy do zauważenia. Dane strukturalne nie służą już wyłącznie do rysowania snippetów. Są jednym z czystszych źródeł faktów o encji, z których korzysta warstwa grounding w systemach generatywnych. Jeśli nazwa Twojej firmy jest w schema zapisana z widoczną encją HTML, to model, który pobiera tę wartość, dostaje błędny ciąg znaków jako nazwę encji. Nie zgadnie, że chodziło o ampersand.
W konsekwencji rośnie ryzyko rozjazdu między tym, co widzi użytkownik na stronie, a tym, co maszyna zapisuje w swojej reprezentacji marki. Ten sam mechanizm opisywaliśmy przy porównaniu formatów w tekście o tym, która forma danych strukturalnych lepiej sprawdza się pod LLM. Sedno jest niezmienne: model ufa polu, które znalazł w markupie, bardziej niż swojemu odczytowi tekstu ze strony, więc błędna wartość w schema jest gorsza niż brak schema.
Trzeci skutek jest organizacyjny. Ponieważ Google nie sygnalizuje tego jako błędu, standardowy monitoring nie zadziała. Raport „Ulepszenia” w Search Console pokaże problem tylko wtedy, gdy zepsute pole jest polem wymaganym danego typu. Przy polach opcjonalnych zmiana przejdzie bez żadnego alertu i zobaczysz ją dopiero w wynikach, na własne oczy, w SERP. Dla dużych serwisów oznacza to, że kontrola wzrokowa nie skaluje się w ogóle i jedynym sensownym rozwiązaniem jest automatyczny test na etapie wdrożenia.
Jak sprawdzić to u siebie w kilkanaście minut
Kolejność działań ma znaczenie, bo pierwszy krok odsiewa większość przypadków bez żadnej pracy programistycznej.
- Pobierz surowe źródło, nie renderowany DOM. Wykonaj zapytanie HTTP do kilkunastu reprezentatywnych szablonów (strona główna, artykuł, kategoria, karta produktu) i wyciągnij zawartość bloków ze skryptem typu application/ld+json. Podgląd w narzędziach deweloperskich przeglądarki potrafi wprowadzić w błąd, bo przeglądarka pokaże wartość już po swoim własnym odkodowaniu.
- Szukaj wzorca podwójnego kodowania. Interesuje Cię każdy string, w którym po nazwie encji nadal siedzi zakodowany ampersand. Jeśli w wartości widzisz sekwencję wyglądającą jak encja, która sama zaczyna się od zakodowanego ampersanda, masz trafienie.
- Zwaliduj JSON osobno. Wycięty blok wrzuć do zwykłego parsera JSON, nie do walidatora schema. Parser powie Ci, czy plik jest w ogóle poprawny składniowo. Walidator schema odpowiada na inne pytanie i przepuści poprawny składniowo string ze śmieciową treścią.
- Porównaj wartość z tekstem na stronie. Najprostszy test akceptacyjny: nazwa w schema musi być znak w znak taka sama jak nazwa widoczna dla użytkownika.
- Sprawdź osobno adresy URL w polach typu url, sameAs i @id. Tam ampersand jest częścią składni zapytania, więc podwójne kodowanie rozbija link bez żadnego wizualnego sygnału.
- Napraw u źródła, nie na wyjściu. Właściwe rozwiązanie to serializacja całego obiektu przez bibliotekę JSON i wyłączenie escapowania HTML na wartościach, które i tak trafiają do kontekstu JSON. Ręcznie doklejane łatki znowu się rozjadą przy następnej zmianie szablonu.
- Wepnij test do procesu wdrożeniowego. Prosty skrypt, który po każdym deployu pobiera kilka adresów, parsuje bloki JSON-LD i sprawdza obecność wzorca podwójnego kodowania, kosztuje godzinę pracy i chroni na stałe.
Dla stron, które opisują narzędzia i oprogramowanie, sprawa jest o tyle ważniejsza, że pola nazwy i opisu są tam nośnikiem całej propozycji wartości. Szczegółowy szablon tego typu markupu opisaliśmy w materiale o schemacie SoftwareApplication pod AI, i każde z wymienionych tam pól warto teraz przejrzeć pod kątem kodowania znaków.
Reakcje branży
Odbiór jest wyraźnie dwubiegunowy. Część technicznych SEO przyjęła zmianę z ulgą i argumentem, że tolerancyjny parser był przez lata źródłem nieprzewidywalności. Skoro Google akceptował wejście niezgodne ze standardem, to zespoły deweloperskie nie miały żadnego bodźca, żeby poprawić generowanie danych. Twarde trzymanie się RFC oznacza, że zachowanie parsera staje się wreszcie testowalne, a wynik da się odtworzyć lokalnie bez zgadywania.
Druga część zwraca uwagę na sposób komunikacji. Zmiana o skutkach produkcyjnych została ogłoszona wpisem w mediach społecznościowych jednego pracownika, bez notatki na blogu Search Central, bez wpisu w historii zmian dokumentacji i bez okresu przejściowego. Dokumentacja ogólnych wytycznych dla danych strukturalnych w momencie publikacji tego tekstu nadal nie zawierała wzmianki o liczbie przejść odkodowywania ani odwołania do RFC 8259.
Pojawia się też pytanie o skalę. Nikt nie opublikował dotąd twardego oszacowania, jaki odsetek stron generuje podwójnie zakodowany JSON-LD. Anegdotyczne zgłoszenia z forów wskazują na dwa skupiska: starsze sklepy na silnikach z ręcznie pisanymi szablonami oraz witryny, gdzie schema dokleja wtyczka trzecia, nieaktualizowana od dawna. To sugeruje problem wąski, ale skoncentrowany, czyli taki, który nie ruszy średniej rynkowej, a pojedynczym serwisom potrafi zabrać cały zestaw rozszerzeń w SERP.
Co dalej
Trzy rzeczy warto obserwować w najbliższych tygodniach.
Po pierwsze, aktualizacja dokumentacji. Jeśli Google traktuje to jako trwałe zachowanie parsera, wzmianka powinna trafić do wytycznych ogólnych dla danych strukturalnych. Brak takiego wpisu przez dłuższy czas będzie sygnałem, że zmiana ma charakter cichej korekty implementacji, a nie zapowiedzi polityki.
Po drugie, zachowanie narzędzia do testowania wyników z elementami rozszerzonymi. Kluczowe pytanie brzmi, czy narzędzie zaczęło już odzwierciedlać nowe zachowanie, czy nadal pokazuje wartość rozwiniętą po dwóch przejściach. Rozjazd między narzędziem a produkcyjnym crawlerem byłby najgorszym możliwym scenariuszem, bo test przechodziłby na zielono przy realnie zepsutych danych.
Po trzecie, tempo łatania po stronie wtyczek. W ekosystemie WordPressa to wtyczki SEO odpowiadają za większość generowanego JSON-LD, więc ich najbliższe wydania są naturalnym miejscem, gdzie zmiana zostanie zaadresowana. Do czasu ich publikacji odpowiedzialność leży po stronie właściciela witryny, a nie dostawcy oprogramowania.
Praktyczny wniosek jest niewdzięczny, ale jednoznaczny. Dane strukturalne przestały być elementem kosmetycznym, który się raz wdraża i zapomina. Są interfejsem danych między Twoją stroną a maszynami, które ją czytają: crawlerem, warstwą rich results i modelem generatywnym. Interfejsy danych wymagają walidacji w procesie wdrożeniowym, a nie kontroli wzrokowej raz na kwartał. Ta zmiana jest tanim przypomnieniem o tej zasadzie. Następna może być droższa.
FAQ
Czy ta zmiana wpływa na pozycje w rankingu?
Nie bezpośrednio. To zmiana w parsowaniu danych strukturalnych, a nie aktualizacja algorytmu rankingowego, i nie pojawiła się na Search Status Dashboard. Pośrednio może jednak obniżyć CTR, jeśli strona traci kwalifikację do wyników z elementami rozszerzonymi, a spadek kliknięć przy niezmienionej pozycji bywa mylnie diagnozowany jako spadek widoczności.
Jak szybko sprawdzę, czy mam problem?
Pobierz surowe źródło HTML kilku szablonów i wyciągnij zawartość bloków application/ld+json, a następnie poszukaj w wartościach sekwencji wyglądających jak encja HTML, która sama zaczyna się od zakodowanego ampersanda. Nie polegaj na podglądzie w narzędziach deweloperskich przeglądarki, bo przeglądarka odkoduje wartość po swojemu i ukryje błąd.
Czy powinienem przejść na Microdata, żeby uniknąć problemu?
Nie. Google nadal rekomenduje JSON-LD jako preferowany format, a Microdata ma własny zestaw ograniczeń, zwłaszcza przy szablonach dynamicznych i przy odczycie przez modele językowe. Właściwym rozwiązaniem jest poprawna serializacja JSON, a nie zmiana formatu.
Co z polami, których Google nie oznacza jako wymagane?
To właśnie najtrudniejszy przypadek, bo raport „Ulepszenia” w Search Console nie zaalarmuje o błędzie w polu opcjonalnym. Zepsuta wartość przejdzie do indeksu bez żadnego sygnału, dlatego walidację warto wpiąć do procesu wdrożeniowego i porównywać wartość w schema z tekstem widocznym na stronie.
Czy to dotyczy tylko Googlebota?
Komunikat dotyczy parsera Google, ale konsekwencje są szersze. Inne crawlery i systemy grounding czytają te same bloki JSON-LD, więc podwójnie zakodowana nazwa marki czy produktu psuje reprezentację encji również poza Google. Poprawienie kodowania jest więc działaniem uniwersalnym, a nie optymalizacją pod jedną wyszukiwarkę.