Dane strukturalne niezgodne ze stroną: dlaczego Google je ignoruje

Niezgodne dane strukturalne Google: gdzie zaczyna się problem

Niezgodne dane strukturalne Google pojawiają się wtedy, gdy kod schema.org opisuje stronę inaczej niż jej widoczna treść. W sklepie internetowym najłatwiej zauważyć to przy produkcie: kod podaje jedną cenę, inną dostępność albo nazwę, która nie odpowiada nazwie wyświetlanej klientowi. Podobny problem może dotyczyć oceny, liczby opinii, marki, wariantu czy adresu strony.

Sam fakt, że JSON-LD jest poprawny składniowo, nie oznacza jeszcze, że Google powinien wykorzystać zawarte w nim informacje. Structured data guidelines wymagają między innymi, aby oznaczenie było reprezentatywne dla głównej treści strony i nie wprowadzało użytkownika w błąd. Google może więc odczytać kod bez błędu technicznego, ale pominąć dane przy tworzeniu wyniku rozszerzonego.

W praktyce oznacza to, że przy diagnozowaniu problemu trzeba porównać dwie rzeczy: dane przekazywane w kodzie oraz informacje dostępne na stronie dla zwykłego użytkownika. Dopiero wtedy można ustalić, czy problem znajduje się w schema.org, szablonie sklepu, synchronizacji danych produktowych czy sposobie generowania strony.

Jak sprawdzić zgodność schema z treścią strony

Najprościej zacząć od konkretnej strony produktu, na której Google nie pokazuje oczekiwanych informacji. Nie ma sensu analizować całego sklepu naraz. Wybierz jeden adres, otwórz go w przeglądarce i zapisz informacje widoczne dla klienta.

Przy produkcie sprawdź przede wszystkim nazwę, cenę, walutę, dostępność, zdjęcie, markę oraz informacje o ocenach i liczbie opinii. Jeżeli produkt występuje w wariantach, sprawdź także, czy cena i dostępność dotyczą tego samego wariantu, który opisuje strona.

Następnie podejrzyj kod źródłowy strony i wyszukaj application/ld+json. W typowym sklepie znajdziesz tam jeden lub więcej bloków JSON-LD. Nie zakładaj jednak, że pierwszy znaleziony blok opisuje produkt. Sklep może generować równocześnie dane dla organizacji, breadcrumbs, strony internetowej i produktu.

Przy danych produktu szukaj przede wszystkim elementu Product oraz powiązanego z nim Offer, Review lub AggregateRating. Schema.org definiuje Product jako typ opisujący konkretny produkt lub usługę, natomiast Offer służy między innymi do opisania oferty sprzedaży. Dlatego przy diagnozie trzeba patrzeć na zależności między obiektami, a nie tylko na pojedyncze wartości.

Potem wykonaj proste porównanie. Jeżeli na stronie widzisz cenę 199 zł, a w kodzie znajduje się 179,00 PLN, masz konkretną rozbieżność do wyjaśnienia. Jeżeli klient widzi „Brak w magazynie”, a schema przekazuje InStock, problem jest jeszcze bardziej oczywisty. Tak samo należy potraktować nazwę produktu, ocenę i liczbę opinii.

Do kontroli technicznej możesz użyć Rich Results Test, a następnie sprawdzić adres w Google Search Console za pomocą narzędzia Inspekcja adresu URL. Walidator odpowiada przede wszystkim na pytanie, czy oznaczenie może zostać odczytane i czy spełnia wymagania techniczne określonego typu wyniku. Nie zastępuje jednak ręcznego porównania danych z rzeczywistą zawartością strony.

Cena w schema.org nie zgadza się z ceną produktu

Cena jest jednym z najczęstszych miejsc, w których ujawniają się niezgodne dane strukturalne Google. Sklep może wyświetlać klientowi cenę promocyjną, podczas gdy JSON-LD nadal pobiera cenę podstawową z bazy danych. Czasami sytuacja jest odwrotna: schema zawiera cenę po rabacie, ale użytkownik bez spełnienia określonych warunków widzi inną kwotę.

Przy sprawdzaniu ceny nie ograniczaj się do wartości price. Zobacz również priceCurrency i ustal, czy oba pola odnoszą się do tej samej oferty. W przypadku rozbudowanych sklepów sprawdź także, czy kod nie zawiera kilku ofert i czy wybrana oferta odpowiada produktowi prezentowanemu na stronie.

Problem może pojawić się również przy produktach z wariantami. Przykładowo klient wybiera konkretny rozmiar i kolor, a cena zmienia się dynamicznie. Jeśli widoczna cena pochodzi z JavaScriptu, natomiast schema jest generowana wcześniej i nie zostaje zaktualizowana, Google może otrzymać inny obraz produktu niż użytkownik.

W takiej sytuacji nie zaczynaj od ręcznej zmiany wartości w JSON-LD. Najpierw ustal źródło danych. Jeżeli schema jest tworzona przez moduł WooCommerce, PrestaShop, Shoper lub własny szablon, sprawdź, z jakiego pola pobierana jest cena. Ręczna poprawka kodu może zostać nadpisana przy kolejnej zmianie produktu.

Dostępność produktu może być nieaktualna

Drugim częstym problemem jest dostępność. W kodzie może pojawić się InStock, podczas gdy na stronie znajduje się informacja o braku towaru. Możliwa jest również sytuacja odwrotna, gdy schema wskazuje OutOfStock, a sklep już przyjmuje zamówienia.

Przy analizie sprawdź, czy dostępność wynika bezpośrednio ze stanu magazynowego, czy z dodatkowych warunków. Niektóre sklepy pokazują produkt jako dostępny, gdy można go zamówić u dostawcy, a inne używają tego statusu tylko dla produktów znajdujących się fizycznie w magazynie. Schema powinna opisywać rzeczywistą ofertę przedstawioną użytkownikowi, a nie przypadkową wartość pobraną z innego systemu.

Szczególnie dokładnie sprawdzaj produkty synchronizowane z zewnętrznym systemem magazynowym. Jeśli stan magazynowy aktualizuje się szybciej niż kod generowany przez sklep, przez pewien czas strona i schema mogą przedstawiać różne informacje. Google zwraca uwagę także na problemy z dynamicznie generowanymi danymi, zwłaszcza gdy dotyczą szybko zmieniającej się ceny lub dostępności.

Nazwa produktu, wariant i identyfikacja obiektu

Rozbieżność nie musi dotyczyć ceny. Czasami kod wskazuje produkt o innej nazwie niż ta widoczna w nagłówku strony. Bywa też, że schema opisuje nazwę produktu bazowego, podczas gdy strona przedstawia konkretny wariant.

Przy produktach wariantowych sprawdź, czy adres URL, nazwa, oferta i dostępność wskazują ten sam obiekt. Jeśli użytkownik znajduje stronę „Buty Sport X, rozmiar 42”, a schema opisuje ogólny produkt „Buty Sport X”, trzeba ustalić, czy taki sposób oznaczenia odpowiada faktycznej konstrukcji strony.

Jeżeli problem wynika z indeksowania wielu wariantów, osobno przeanalizuj strukturę adresów i sygnały kanoniczne. W sklepie z dużą liczbą wariantów pomocna może być także analiza problemów z duplikatami stron produktów, ponieważ błędna identyfikacja produktu nie zawsze kończy się wyłącznie problemem w JSON-LD.

Oceny i opinie: schema nie może tworzyć innego obrazu produktu

Dane o ocenach wymagają szczególnej kontroli. Jeżeli strona pokazuje ocenę 4,7 na podstawie 120 opinii, schema nie powinna przekazywać wartości 5 na podstawie innej liczby ocen. Google traktuje dane AggregateRating jako informacje o zagregowanych ocenach, więc wartości powinny odpowiadać temu, co użytkownik może znaleźć na stronie.

Sprawdź ratingValue, reviewCount oraz ratingCount, jeśli są wykorzystywane. Następnie porównaj je z widocznym modułem opinii. Nie wystarczy sprawdzić, czy liczby są formalnie poprawne. Trzeba ustalić, czego dotyczą.

Inny problem pojawia się wtedy, gdy system sklepu zachowuje starą ocenę po usunięciu części opinii albo schema korzysta z danych zapisanych w pamięci podręcznej. Wtedy użytkownik może widzieć aktualną ocenę, a kod nadal podawać poprzednią wartość.

W przypadku opinii warto również sprawdzić, czy oznaczenie dotyczy właściwego produktu. Ocena przypisana do produktu A nie może zostać przypadkowo wygenerowana w kodzie produktu B tylko dlatego, że oba produkty korzystają z tego samego komponentu szablonu.

Najczęstsze rozbieżności danych strukturalnych

Poniższa tabela pozwala szybko przejść przez podstawową kontrolę strony produktu.

Element	Co widzi użytkownik	Co może zawierać schema	Typowy problem	Co sprawdzić
Nazwa	Nazwa produktu na stronie	name	Stara lub skrócona nazwa	Źródło pola name i nagłówek produktu
Cena	Aktualna cena	price	Cena bazowa zamiast promocyjnej	Źródło ceny i reguły promocji
Waluta	Waluta ceny	priceCurrency	Inna waluta niż na stronie	Waluta oferty i ustawienia sklepu
Dostępność	Dostępny, brak produktu lub przedsprzedaż	availability	Nieaktualny status	Stan magazynowy i cache
Ocena	Średnia ocena	ratingValue	Stara lub zawyżona wartość	Widoczna ocena i źródło danych
Liczba opinii	Liczba recenzji	reviewCount	Inna liczba niż na stronie	Moduł opinii i cache
Produkt	Konkretny produkt lub wariant	Product	Schema opisuje inny obiekt	URL, nazwa i wariant
Oferta	Aktualna oferta sprzedaży	Offer	Oferta nie odpowiada stronie	Cena, dostępność i produkt

Taka kontrola jest szczególnie przydatna po wdrożeniu nowego szablonu, zmianie modułu SEO albo migracji sklepu. Jeśli wiele produktów ma dokładnie ten sam rodzaj rozbieżności, prawdopodobnie problem znajduje się w mechanizmie generującym dane, a nie w pojedynczym produkcie.

Schema spam: kiedy problem przestaje być zwykłym błędem

Nie każda rozbieżność oznacza schema spam. Jest jednak różnica między przypadkowym błędem synchronizacji a świadomym oznaczaniem informacji, których użytkownik nie widzi na stronie.

Przykładem problemu może być umieszczenie w kodzie oceny, której nie ma w widocznej treści, albo podanie ceny, której klient faktycznie nie może uzyskać. Podobnie należy traktować dane ukryte przed użytkownikiem, jeśli schema przedstawia je jako główną informację strony.

Google w swoich zasadach dotyczących danych strukturalnych wskazuje, że oznaczenie powinno reprezentować główną treść strony. Naruszenia wytycznych mogą skutkować utratą kwalifikacji do wyników rozszerzonych, a w określonych przypadkach także ręcznym działaniem dotyczącym danych strukturalnych.

Dlatego nie próbuj dodawać do schema informacji tylko dlatego, że mogą wyglądać atrakcyjnie w Google rich results. Najpierw sprawdź, czy ta informacja rzeczywiście znajduje się na stronie i czy odnosi się do tego samego obiektu.

Dlaczego Google ignoruje schema, mimo że kod jest poprawny

To pytanie często pojawia się po teście, który nie wykazuje błędów. Odpowiedź jest prosta: poprawność techniczna kodu to tylko jeden etap oceny.

Google może odczytać JSON-LD, rozpoznać typ Product, zaakceptować jego składnię, a mimo to nie wykorzystać danych w wynikach wyszukiwania. Jednym z powodów może być brak zgodności z widoczną treścią. Innym może być niespełnienie wytycznych konkretnego rodzaju danych strukturalnych. Samo użycie schema nie gwarantuje pojawienia się wyniku rozszerzonego.

Dlatego przy pytaniu „dlaczego Google ignoruje schema” trzeba najpierw ustalić, co dokładnie jest ignorowane. Czy Google nie odczytuje danych? Czy odczytuje je, ale nie pokazuje rich result? Czy może pokazuje informacje inne niż te zapisane w kodzie? To trzy różne sytuacje i wymagają innej diagnostyki.

Jeżeli kod jest generowany przez JavaScript, sprawdź także sposób jego tworzenia i moment pojawienia się danych w DOM. W sklepach, w których cena i dostępność zmieniają się dynamicznie, opóźnione lub niestabilne generowanie oznaczenia może utrudniać prawidłowe odczytanie aktualnych informacji.

Jak znaleźć źródło niezgodności w sklepie

Jeżeli rozbieżność występuje na jednej stronie, zacznij od konkretnego produktu. Porównaj widoczną treść z JSON-LD, a następnie sprawdź, skąd szablon pobiera każdą problematyczną wartość.

Jeżeli ten sam błąd występuje na dziesiątkach lub setkach produktów, nie poprawiaj stron ręcznie. Poszukaj wspólnego źródła. Może nim być moduł SEO, szablon produktu, wtyczka generująca schema, integracja z systemem magazynowym albo mechanizm cache.

Przy dużym sklepie dobrze jest wybrać kilka produktów o różnym statusie: produkt dostępny, niedostępny, przeceniony, z wariantami i z opiniami. Porównanie takich stron szybko pokazuje, czy problem dotyczy określonego typu danych.

Jeśli w kodzie znajdziesz wiele bloków JSON-LD opisujących ten sam produkt, sprawdź, czy nie przekazują sprzecznych informacji. Jeden moduł może podawać aktualną cenę, a drugi wartość zapisaną wcześniej. Samo usunięcie błędu składniowego nie rozwiąże takiej sytuacji.

Warto również sprawdzić, jak Google widzi stronę, a nie tylko jak wygląda ona w przeglądarce. Inspekcja adresu URL pozwala zweryfikować dostępność strony dla Google i sprawdzić stan jej indeksowania. Przy problemach z JavaScriptem pomocna będzie także analiza tego, czy dane pojawiają się w wersji strony dostępnej po renderowaniu.

Jeżeli przy okazji diagnozy znajdziesz problemy z odpowiedziami serwera, sprawdź również źródła błędów 500 w sklepie, ponieważ niestabilne działanie strony może utrudniać prawidłowe pobieranie jej zawartości.

Schema a rzeczywista treść strony: jak wykonać kontrolę ręcznie

Najprostszy audyt można wykonać według stałej kolejności. Najpierw otwórz stronę jako użytkownik i zanotuj wartości, które mają znaczenie dla danego typu wyniku. Następnie otwórz kod źródłowy i znajdź odpowiedni obiekt schema.org. Potem zestaw obie wersje obok siebie.

W przypadku produktu porównaj nazwę, identyfikację produktu, ofertę, cenę, walutę, dostępność oraz dane o ocenach. Jeśli którakolwiek wartość się różni, nie poprawiaj jej od razu. Ustal, która wersja jest źródłem prawdy i skąd druga wersja pobiera dane.

Następnie sprawdź, czy rozbieżność występuje tylko w kodzie, czy również w bazie danych sklepu. Jeżeli baza zawiera poprawną cenę, strona pokazuje poprawną cenę, a schema podaje inną, problem znajduje się na etapie generowania oznaczenia. Jeżeli baza ma starą cenę, trzeba zacząć od synchronizacji danych produktowych.

Na końcu ponownie uruchom test danych strukturalnych i sprawdź stronę w Search Console. Po wdrożeniu poprawki Google musi ponownie pobrać i przetworzyć stronę. Brak natychmiastowej zmiany w wynikach nie oznacza automatycznie, że poprawka jest nieskuteczna.

Takie podejście pozwala odróżnić błędy danych strukturalnych od problemów z indeksowaniem, cache, JavaScriptem czy samą treścią strony. Jest to istotne, bo każda z tych przyczyn wymaga innej poprawki.

Co zrobić po wykryciu niezgodności

Najpierw popraw źródło danych, a dopiero potem samą warstwę schema. Jeśli cena pochodzi z niewłaściwego pola produktu, popraw generator danych. Jeśli dostępność jest opóźniona przez cache, sprawdź mechanizm odświeżania. Jeśli problem dotyczy wariantów, ustal, który produkt i która oferta są reprezentowane przez dany adres URL.

Nie usuwaj całego schema tylko dlatego, że jeden element jest niezgodny. Jeżeli pozostałe dane są prawidłowe, usuń lub popraw konkretny problem. Jednocześnie nie dodawaj kolejnych właściwości na zapas. Schema powinna opisywać faktycznie dostępne informacje.

Po zmianie ponownie sprawdź kilka reprezentatywnych stron. W sklepie z dużą liczbą produktów pojedyncza poprawka może zmienić sposób generowania danych na wszystkich kartach produktu. Dlatego test kilku różnych przypadków jest bezpieczniejszy niż sprawdzenie tylko jednej strony.

Jeśli niezgodności są częścią większego problemu technicznego sklepu, audyt techniczny sklepu internetowego pozwala potraktować schema razem z indeksowaniem, szablonem, wydajnością i innymi sygnałami wpływającymi na sposób odczytu strony.

Podsumowanie

Niezgodne dane strukturalne Google nie muszą oznaczać błędu składniowego. Kod może być poprawny, przechodzić walidację, a mimo to nie być wykorzystany, jeśli opisuje inną cenę, dostępność, nazwę, ocenę albo produkt niż ten przedstawiony użytkownikowi.

Dlatego kontrolę zaczynaj od porównania strony z kodem. Sprawdź konkretne wartości, ustal ich źródło i zobacz, czy problem powtarza się na innych produktach. Dopiero później analizuj moduł schema, JavaScript, cache, bazę danych i konfigurację sklepu.

Najważniejszym kryterium nie jest to, czy JSON-LD wygląda poprawnie. Liczy się to, czy opisuje rzeczywistą treść strony i właściwy obiekt. To właśnie od tego trzeba zacząć, gdy Google nie wykorzystuje danych strukturalnych tak, jak oczekujesz.