Najważniejsze wnioski w pigułce
Co się zmieniło
- Googlebot stosuje teraz tylko jedno przejście dekodowania encji HTML (HTML unescaping) przy ekstrakcji danych strukturalnych JSON-LD.
- Podwójnie zakodowane encje w rodzaju
&czy✔nie będą już automatycznie „rozwijane” do właściwych znaków. - Google porzuca dotychczasowe pobłażliwe podejście na rzecz ścisłej zgodności ze standardem JSON opisanym w RFC 8259, sekcja 7.
Co to oznacza w praktyce
- Błędnie zakodowane znaki mogą sprawić, że fragment danych strukturalnych stanie się nieczytelny dla parsera.
- Ryzyko dotyczy przede wszystkim cen produktów, ocen i recenzji, składników przepisów oraz sekcji FAQ — czyli wszystkiego, co zasila wyniki rozszerzone (Rich Results).
- Poprawne rozwiązanie to standardowe znaki ucieczki JSON albo zapis szesnastkowy Unicode, na przykład
\u0026zamiast&.
Kto powinien reagować najszybciej
- Sklepy internetowe generujące dane strukturalne dynamicznie z systemów PIM lub ERP.
- Serwisy korzystające z wtyczek i szablonów, które składają JSON-LD ze stringów HTML.
- Wydawcy treści z rozbudowanymi sekcjami FAQ, HowTo i recenzji.
Na czym polega zmiana w parserze Google
Google poinformował na LinkedInie, że dostosował swój mechanizm ekstrakcji JSON-LD do standardów JSON i stosuje już tylko jedno przejście dekodowania encji HTML. Wcześniej crawler potrafił „domyślić się” intencji i naprawić dane, w których znaki zostały zakodowane dwukrotnie — na przykład gdy ampersand trafiał do kodu jako & zamiast pojedynczego &. Ta tolerancja właśnie się skończyła.
Gary Illyes z Google dodał, że definicja poprawnego znaku ucieczki w JSON jest opisana bardzo precyzyjnie w dokumencie RFC 8259, w sekcji siódmej. To wyraźny sygnał, że Google nie zamierza dłużej kompensować błędów w implementacji po stronie właścicieli witryn. Standard jest publiczny, jednoznaczny i obowiązuje wszystkich.
Warto zauważyć, że sama zmiana nie jest aktualizacją algorytmu rankingowego ani karą. To korekta techniczna na poziomie parsera, która porządkuje sposób odczytu skryptów application/ld+json. Konsekwencje są jednak realne, bo dotykają warstwy, od której zależy widoczność w wynikach rozszerzonych.
Dlaczego to ważne dla widoczności w wyszukiwarce
Google wykorzystuje skrypty JSON-LD do zrozumienia szczegółów encji: cen produktów, gwiazdek w recenzjach, składników przepisów czy pytań i odpowiedzi w sekcjach FAQ. Na tej podstawie generuje wyniki rozszerzone, które zwiększają zajmowaną powierzchnię w SERP-ach i realnie podnoszą współczynnik klikalności. Jeśli parser nie odczyta danych poprawnie, znika nie ranking, ale atrakcyjny format prezentacji.
Największe ryzyko dotyczy nazw produktów i tytułów zawierających znaki specjalne — ampersandy w nazwach marek, symbole zaznaczenia w opisach cech czy znaki interpunkcyjne w treściach FAQ. To właśnie te miejsca najczęściej przechodzą przez podwójne kodowanie, gdy dane wędrują z bazy przez system szablonów aż do kodu HTML strony.
Dla sklepów internetowych oznacza to potencjalną utratę gwiazdek recenzji lub informacji o cenie i dostępności przy wynikach produktowych. W kategoriach o wysokiej konkurencji taka różnica w prezentacji potrafi przełożyć się na dwucyfrowy spadek liczby wejść z wyszukiwarki, mimo niezmienionej pozycji.
Skąd bierze się podwójne kodowanie
Problem rzadko wynika z celowej decyzji dewelopera. Najczęściej powstaje przy łączeniu kilku warstw systemu: dane produktowe wychodzą z bazy już zakodowane pod HTML, a następnie szablon lub wtyczka koduje je ponownie przed wstawieniem do skryptu JSON-LD. Efekt to & zamiast & — wcześniej Google to naprawiał, teraz przepuści bez korekty.
Drugim źródłem są generyczne funkcje pomocnicze typu htmlspecialchars stosowane bez rozróżnienia kontekstu. JSON i HTML to dwa różne formaty z odmiennymi regułami znaków ucieczki, a traktowanie ich wymiennie prowadzi dokładnie do opisywanego konfliktu. W JSON-LD prawidłowy zapis ampersanda to \u0026, a nie encja HTML.
Trzeci scenariusz to ręczne sklejanie stringów JSON zamiast serializacji obiektu przez wbudowaną funkcję języka. Każdy nowoczesny język programowania ma bezpieczny serializator JSON, który sam zadba o poprawne kodowanie. Rezygnacja z niego na rzecz konkatenacji tekstu to prosta droga do błędów, które teraz zaczną kosztować widoczność.
Jak przygotować witrynę na nowe reguły
Punktem wyjścia powinien być audyt wszystkich szablonów generujących dane strukturalne — osobno dla kart produktowych, kategorii, artykułów i stron z sekcjami FAQ. Warto sprawdzić, na którym etapie renderowania dane przechodzą przez funkcje kodujące i czy nie robią tego dwukrotnie. Najbezpieczniejszym rozwiązaniem jest zbudowanie struktury danych jako natywnego obiektu i wyeksportowanie go standardowym serializatorem.
Weryfikację warto przeprowadzić w narzędziu Google do testowania wyników z elementami rozszerzonymi oraz w walidatorze schema.org, koncentrując się na produktach z nietypowymi znakami w nazwach. Dobrą praktyką jest przygotowanie kontrolnej listy kilkunastu adresów URL zawierających ampersandy, cudzysłowy i symbole, i regularne sprawdzanie ich po każdym wdrożeniu. Raport wyników z elementami rozszerzonymi w Search Console pokaże z kolei, czy skala problemu rośnie.
W przypadku witryn opartych na gotowych wtyczkach kluczowa jest aktualizacja do najnowszych wersji — twórcy popularnych rozszerzeń zwykle szybko dostosowują się do zmian po stronie Google. Jeśli wtyczka nie została zaktualizowana, a błędy się utrzymują, rozsądniej jest wyłączyć jej generowanie JSON-LD i zastąpić je własną, kontrolowaną implementacją.
Podsumowanie
Google przestał naprawiać cudze błędy w kodowaniu danych strukturalnych i wymaga zgodności z RFC 8259. Dla większości witryn to zmiana neutralna, ale tam, gdzie JSON-LD powstaje przez wielowarstwowe kodowanie stringów, może oznaczać utratę wyników rozszerzonych — a więc i ruchu. Szybki audyt szablonów oraz weryfikacja kilkunastu reprezentatywnych adresów URL wystarczą, żeby wykluczyć ryzyko.
Źródło: Search Engine Roundtable — JSON-LD Extraction For Googlebot Now Does One Pass Of HTML Unescaping
