Audyt Schema.org: błędy, poprawki i widoczność w Google

Niepoprawne lub niespójne dane strukturalne mogą sprawić, że strona nie kwalifikuje się do wyników z elementami rozszerzonymi. Sprawdź, jak wykrywać błędy Schema.org, ustalać ich priorytet i bezpiecznie weryfikować poprawki.

Poprawny składniowo kod Schema.org może nadal opisywać nieaktualną cenę, niewłaściwy produkt albo ocenę, której użytkownik nie widzi na stronie. Dlatego audyt danych strukturalnych nie kończy się na zielonym komunikacie walidatora. Trzeba sprawdzić trzy rzeczy: czy oznaczenia mają sens dla danej podstrony, czy spełniają wymagania konkretnej funkcji wyszukiwarki i czy odpowiadają opublikowanej treści. Poniższy proces pozwala przejść od wyboru adresów do kontroli po wdrożeniu, bez poprawiania wszystkich ostrzeżeń na ślepo.

1. Jakie typy danych strukturalnych warto sprawdzić w pierwszej kolejności

Zacznij od szablonów stron, a nie od losowej listy adresów. Błąd w szablonie produktu może powielać się w całym katalogu, podczas gdy problem w pojedynczym artykule ma znacznie mniejszy zasięg. Przygotuj zestaw reprezentatywnych URL-i: po jednym dla każdego głównego szablonu oraz dodatkowe przykłady nietypowych stanów, takich jak produkt niedostępny, oferta promocyjna czy artykuł po aktualizacji.

Sklep internetowy: sprawdź przede wszystkim Product i Offer oraz powiązane oceny, jeżeli rzeczywiście występują na stronie. Porównaj cenę, walutę, dostępność i identyfikację wariantu.
Portal lub blog: skontroluj Article, BlogPosting albo NewsArticle, zależnie od rodzaju materiału. Zwróć uwagę na autora, daty, nagłówek oraz powiązanie z właściwą stroną i obrazami.
Serwis firmy: przejrzyj Organization oraz odpowiedni podtyp LocalBusiness, jeśli opisuje rzeczywistą działalność. Zweryfikuj nazwę, adres, dane kontaktowe i godziny otwarcia.
Nawigacja: sprawdź BreadcrumbList, zwłaszcza po zmianach kategorii i struktury adresów. Kolejność elementów i wskazywane strony powinny odzwierciedlać sensowną ścieżkę nawigacyjną.
Serwisy specjalistyczne: uwzględnij typy odpowiadające głównej treści, takie jak Event, JobPosting, Recipe lub VideoObject. Szczególnej kontroli wymagają informacje, które szybko tracą aktualność.

Priorytet ustal według połączenia zasięgu błędu, znaczenia podstron i ryzyka wprowadzenia użytkownika w błąd. Nieprawdziwa cena na popularnych kartach produktów jest pilniejsza niż brak dodatkowej właściwości w mało odwiedzanym wpisie. Nie dodawaj też typu wyłącznie dlatego, że pojawił się w generatorze kodu. Na przykład obecność sekcji pytań i odpowiedzi nie oznacza automatycznie, że strona kwalifikuje się do rozszerzonego wyniku FAQ w Google.

Schema.org jest słownikiem opisu danych, a nie katalogiem gwarantowanych funkcji Google. Typ może być poprawny według Schema.org, ale nieobsługiwany w rozszerzonych wynikach wyszukiwania. Przed pracą nad konkretną funkcją sprawdź jej aktualną dokumentację w Google Search Central.

2. Jak odróżnić błędy krytyczne od ostrzeżeń w narzędziach Google

Używaj narzędzi zgodnie z ich zakresem. Test wyników z elementami rozszerzonymi Google sprawdza obsługiwane przez Google rodzaje wyników i pomaga ocenić kwalifikację wykrytych elementów. Schema Markup Validator służy do kontroli struktury oznaczeń według słownika Schema.org, ale nie potwierdza spełnienia wymagań Google. Z kolei Google Search Console pokazuje problemy rozpoznane podczas przetwarzania witryny; dostępne raporty zależą od wykrytych danych i obsługiwanych funkcji.

Błąd krytyczny oznacza zwykle, że dany element nie spełnia wymagań określonej funkcji. Przyczyną może być nieczytelny JSON-LD, brak wymaganej właściwości albo nieprawidłowy typ wartości. Ostrzeżenie najczęściej wskazuje brak zalecanej informacji lub możliwość ulepszenia opisu. Nie traktuj jednak koloru komunikatu jako pełnej oceny ryzyka: poprawnie sformatowana, ale nieprawdziwa cena może nie zostać wykryta przez test, a nadal wymaga pilnej korekty.

Najpierw usuń problemy uniemożliwiające odczyt danych: błędy składni, uszkodzone zagnieżdżenia i niewłaściwe formaty wartości.
Następnie popraw brakujące lub błędne pola wymagane dla funkcji, z której dana strona ma korzystać.
Równolegle potraktuj jako pilne rozbieżności z treścią i naruszenia zasad, nawet jeśli narzędzie nie pokazuje błędu krytycznego.
Ostrzeżenia dotyczące pól zalecanych uzupełniaj tylko wtedy, gdy masz wiarygodne dane. Nie wymyślaj ocen, identyfikatorów ani informacji o autorze po to, by uzyskać komplet zielonych oznaczeń.

Oceniaj konkretny element, nie tylko całe podsumowanie adresu. Jedna podstrona może zawierać prawidłowy BreadcrumbList i nieprawidłowy Product albo kilka encji Product o różnej poprawności. Przy każdym zgłoszeniu zapisz URL, typ i identyfikator elementu, treść problemu, liczbę podobnych stron oraz źródło markupu. Taka lista pozwala odróżnić pojedynczą usterkę od błędu wspólnego komponentu.

3. Jak wykryć rozbieżności między Schema.org a treścią widoczną na stronie

Otwórz stronę tak, jak zobaczy ją niezalogowany użytkownik, i porównaj widoczne informacje z odczytanymi danymi strukturalnymi. Sprawdź zarówno HTML zwrócony przez serwer, jak i wyrenderowany dokument, jeżeli serwis korzysta z JavaScriptu. Kod źródłowy może zawierać inną wersję danych niż ta dodana po uruchomieniu skryptów. Zwróć też uwagę na wybór wariantu, języka, waluty i lokalizacji, bo mogą zmieniać prezentowaną ofertę.

Tożsamość obiektu: czy nazwa, URL, zdjęcia i identyfikatory opisują dokładnie produkt, artykuł, lokalizację lub wydarzenie widoczne pod badanym adresem?
Oferta: czy price, priceCurrency i availability odpowiadają tej samej ofercie oraz wybranemu wariantowi? Czy markup nie zachował starej ceny po zakończeniu promocji?
Opinie: czy ratingValue i reviewCount dotyczą właściwego obiektu i zgadzają się z informacją dostępną użytkownikowi? Czy do produktu nie przypisano oceny całego sklepu?
Autorstwo i daty: czy autor ma właściwą tożsamość, datePublished odzwierciedla publikację, a dateModified rzeczywistą aktualizację materiału, zamiast każdego odświeżenia strony?
Aktualność: czy zakończone wydarzenie, wygasłe ogłoszenie lub zmienione godziny otwarcia mają odpowiednio zaktualizowane dane i treść?

Przykład hipotetyczny: karta butów pokazuje po wyborze rozmiaru cenę 249 zł i brak dostępności, ale JSON-LD nadal zawiera cenę 199 zł oraz InStock, pobrane z domyślnego wariantu. Sam zapis JSON-LD może przejść walidację. Problem leży jednak w powiązaniu oznaczeń z ofertą. Trzeba ustalić, którą konfigurację reprezentuje URL, i zapewnić spójność między danymi produktu, interfejsem oraz markupem, zamiast ręcznie podmieniać cenę tylko w kodzie.

Sprawdź, czy kilku generatorów nie opisuje tej samej encji

Wyszukaj wszystkie wystąpienia JSON-LD, Microdata i RDFa. Motyw, wtyczka SEO, moduł sklepu oraz skrypt własny mogą jednocześnie publikować dane o tym samym obiekcie. Wiele encji na stronie jest normalne, ale sprzeczne opisy jednego produktu lub organizacji utrudniają interpretację. Ustal jedno źródło odpowiedzialne za każdą encję. Jeśli łączysz obiekty za pomocą @id, stosuj spójne identyfikatory i sprawdź, czy odwołania prowadzą do właściwych obiektów.

4. Jak bezpiecznie poprawić markup i sprawdzić go przed wdrożeniem

Poprawiaj przyczynę w generatorze danych, nie tylko wynikowy kod jednej strony. Jeśli cena w interfejsie i cena w Schema.org pochodzą z osobnych pól, problem będzie wracał. Najbezpieczniej, gdy oba widoki korzystają z tego samego źródła informacji i tych samych reguł biznesowych. Przed zmianą zachowaj dotychczasowy kod, przykładowe wyniki testów oraz możliwość powrotu do poprzedniej wersji.

Zdefiniuj oczekiwany wynik: jakie encje mają występować na stronie, jakie wartości powinny zawierać i które pola mogą być pominięte, gdy nie ma danych.
Wprowadź zmianę w środowisku testowym lub osobnej wersji szablonu. Ogranicz zakres do konkretnego problemu, aby łatwo ustalić przyczynę ewentualnej regresji.
Sprawdź składnię oraz strukturę w Schema Markup Validator, a obsługiwane funkcje Google w Teście wyników z elementami rozszerzonymi. Test fragmentu kodu pomaga przy prywatnym środowisku, ale nie sprawdza dostępności opublikowanego URL-a.
Porównaj wynik z wyrenderowaną treścią. Przetestuj także brak wartości opcjonalnych, znaki specjalne, produkt bez opinii, promocję i stan niedostępności.
Skontroluj wynikowy HTML: czy szablon nie dodaje drugiego opisu tej samej encji, nie usuwa potrzebnych pól i nie generuje nieprawidłowych odwołań @id.
Po publikacji przetestuj rzeczywisty URL. Wyczyść właściwe warstwy pamięci podręcznej, jeśli nadal serwują stary kod, i sprawdź, czy wdrożenie nie przeniosło blokad indeksowania ze środowiska testowego.

Poprawny test kodu nie potwierdza, że Google może pobrać stronę, wyrenderować ją i użyć danych w wynikach. Dostępność dla robota, indeksowalność, wybór adresu kanonicznego oraz zgodność z zasadami wymagają osobnej kontroli.

Przy większym wdrożeniu zacznij od ograniczonej grupy stron, jeśli architektura serwisu na to pozwala. Zachowaj zestaw kontrolny adresów dla wszystkich istotnych szablonów. Automatyczne testy mogą sprawdzać na przykład, czy waluta jest zgodna z ofertą, wymagane wartości nie są puste, a wycofane dane nie wracają z pamięci podręcznej. Takie testy nie zastąpią kontroli redakcyjnej, ale pomagają wykrywać powtarzalne usterki po aktualizacjach.

5. Jak monitorować efekty zmian i reagować na błędy wykryte po publikacji

Zapisz datę wdrożenia, zakres zmienionych szablonów i stan wyjściowy: wykryte problemy, liczbę dotkniętych elementów oraz dane o skuteczności odpowiednich stron. Po publikacji najpierw potwierdź poprawność techniczną na żywych adresach. Dopiero później oceniaj raporty Search Console, ponieważ odzwierciedlenie zmian wymaga ponownego przetworzenia stron i nie następuje natychmiast.

W odpowiednim raporcie Search Console możesz uruchomić weryfikację poprawki, jeśli taka opcja jest dostępna. Wcześniej sprawdź reprezentatywne adresy objęte problemem, zamiast naprawiać wyłącznie przykład wskazany przez narzędzie. Raport nie musi stanowić pełnego spisu wszystkich oznaczonych stron. Inspekcja URL-a pomaga porównać informacje o wersji znanej Google z testem na żywo; wyniki tych kontroli mogą się różnić, gdy ostatnie pobranie nastąpiło przed wdrożeniem.

Oddziel poprawność danych od efektów w wyszukiwarce

Monitoruj osobno stan wdrożenia i widoczność. Pierwszy obszar obejmuje błędy, spójność danych oraz dostępność stron. Drugi to wyświetlenia, kliknięcia, CTR i pozycje dla odpowiednich adresów oraz zapytań. Jeśli Search Console udostępnia filtr wyglądu w wyszukiwarce dla danej funkcji, wykorzystaj go do dokładniejszej analizy. Porównuj podobne okresy i uwzględniaj sezonowość, zmiany oferty, treści oraz inne wdrożenia SEO.

Wzrost CTR po zmianie nie jest sam w sobie dowodem, że spowodował go markup. Podobnie brak rozszerzonego wyniku nie musi oznaczać błędu wdrożenia. Dane strukturalne pomagają wyszukiwarce interpretować treść i mogą umożliwić korzystanie z określonych funkcji, ale nie gwarantują ich wyświetlenia ani poprawy pozycji. Jeśli testy są poprawne, sprawdź wymagania funkcji, dostępność strony, adres kanoniczny i zgodność z zasadami, zamiast dodawać kolejne właściwości bez uzasadnienia.

Nagły wzrost błędów po wdrożeniu: porównaj dotknięte szablony z listą zmian i rozważ wycofanie wadliwego komponentu.
Błędy tylko na części adresów: poszukaj wspólnej cechy, np. pustego pola w CMS, konkretnego wariantu, języka lub nieprawidłowo zapisanego znaku.
Stare wartości mimo poprawki: sprawdź pamięć podręczną aplikacji i CDN, źródło danych oraz datę ostatniego pobrania widoczną w narzędziu.
Powracające problemy po aktualizacji wtyczki lub motywu: ponownie skontroluj liczbę generatorów i uruchom testy zestawu kontrolnego URL-i.

Na początek wybierz po jednym adresie z najważniejszych szablonów i przygotuj krótką kartę audytu: wykryta encja, wynik testu Google, zgodność z treścią, źródło kodu i priorytet poprawki. Najpierw napraw problem o największym zasięgu lub ryzyku dezinformacji, a następnie przetestuj ten sam zestaw stron po publikacji. W ten sposób powstanie powtarzalny proces kontroli, który można uruchamiać po każdej zmianie szablonu, danych lub wtyczki.

SEO dla stron z danymi strukturalnymi: jak znaleźć błędy Schema.org i poprawić widoczność wyników