Dane uporządkowane opisują to, co istnieje
Dane strukturalne pomagają maszynowo opisać zawartość strony i jej powiązania. Google przedstawia je jako sposób dostarczania informacji o treści oraz możliwą podstawę określonych rozszerzonych prezentacji wyników. Nie są jednak osobną warstwą, w której można dopisać korzystniejsze fakty niż te widoczne dla odbiorcy. Opis firmy, usługi czy artykułu powinien wynikać z rzeczywistej zawartości witryny.
Zanim dodasz kod, przygotuj mapę informacji: marka, adres witryny, dane kontaktowe, zakres usługi, autorzy i rodzaje podstron. Ustal, które dane są znane, a które wymagają potwierdzenia. Brak pełnego adresu przedsiębiorcy nie powinien być uzupełniany wymyślonym numerem budynku. Lepsza jest świadoma lista braków do uzupełnienia niż kompletny wizualnie, ale nieprawdziwy zapis.
Dobierz typ do rzeczywistej podstrony
Strona organizacji, opis usługi i artykuł poradnikowy mają inne przeznaczenie. Nie trzeba dodawać wszystkich dostępnych typów tylko dlatego, że znajdują się na liście funkcji CMS. W przypadku materiałów redakcyjnych Google udostępnia dokumentację danych Article i ich właściwości. Dla zwykłej witryny usługowej oznaczanie przepisów, hoteli czy wydarzeń bez odpowiedniej treści nie daje sensownego opisu.
W projekcie DR-BOOST ważne jest rozdzielenie informacji o marce, witrynie, poszczególnych usługach oraz poradnikach. Archiwum wpisów jest listą materiałów, nie pojedynczym artykułem. Taki podział ułatwia utrzymanie spójności podczas dodawania kolejnych publikacji. Reguły powinny być związane z szablonem i danymi, a nie ręcznie kopiowane do każdej strony bez kontroli.
Zachowaj zgodność z widoczną treścią
Google wymaga, aby dane strukturalne reprezentowały zawartość strony i nie wprowadzały w błąd. Jeżeli wpis pokazuje określony tytuł, autora i datę, kod nie powinien przedstawiać innego materiału. Podobnie cena usługi lub dane kontaktowe muszą odpowiadać temu, co użytkownik może sprawdzić. Rozbieżności często powstają po zmianie treści, gdy metadane pozostają ręczną kopią starszego stanu.
Najlepiej korzystać z jednego źródła danych dla prezentacji i kodu JSON-LD. W CMS aktualizacja nazwy firmy lub artykułu powinna automatycznie trafiać do obu warstw. Po wdrożeniu sprawdź jednak rezultat, nie tylko założenie projektowe. Ręczny wyjątek w jednym szablonie może sprawić, że stopka pokazuje nowy numer, a dane uporządkowane nadal stary.
Nie dodawaj opinii ani wyników bez podstawy
Oceny, recenzje i liczniki muszą mieć rzeczywiste źródło. Nie wpisuj najwyższej oceny ani dużej liczby opinii po to, aby wypełnić pole w konfiguracji. Zasady Google dotyczące danych uporządkowanych obejmują także zakaz treści wprowadzających w błąd. Jeżeli firma nie ma zweryfikowanego materiału do publikacji, odpowiednie właściwości powinny zostać pominięte zamiast uzupełnione przykładowymi danymi.
Podobna ostrożność dotyczy referencji i studiów przypadków. Wykres poglądowy nie powinien stawać się w kodzie potwierdzonym wynikiem klienta. Przy cytowanej opinii zachowaj źródło i zakres zgody na wykorzystanie. Informacje szczególnie wrażliwe dla wiarygodności marki warto zatwierdzać osobno, aby późniejsza automatyzacja publikacji nie rozpowszechniała fikcyjnych elementów jako faktów.
Kontroluj autorów, daty i obrazy artykułów
Przy każdym poradniku ustal, kto odpowiada za treść i kiedy została opublikowana lub istotnie zmieniona. Dokumentacja Article opisuje między innymi dane autora, nagłówka, obrazów i dat. Nie zmieniaj daty publikacji automatycznie przy każdym otwarciu strony. Aktualizacja technicznego szablonu nie oznacza również, że wszystkie artykuły przeszły merytoryczną redakcję tego samego dnia.
Sprawdź, czy obraz wskazany w metadanych jest dostępny i odpowiada tematowi. Gdy każda strona ma własny podgląd udostępnienia, łatwiej rozróżniać materiały, ale sam plik musi faktycznie istnieć. Zapis prowadzący do nieobecnej grafiki nie staje się poprawny tylko dlatego, że JSON jest składniowo prawidłowy. Odbiór powinien objąć także adresy zasobów i ich publiczną dostępność.
Waliduj składnię i znaczenie osobno
Test składni sprawdza, czy zapis da się odczytać. Kontrola znaczenia ocenia, czy opis pasuje do realnej treści, użyte typy mają sens i nie pojawiają się sprzeczności. Narzędzie walidacyjne może pomóc znaleźć brakujące elementy, ale nie zna całej sytuacji firmy. Dlatego pozytywny wynik automatycznego testu nie zastępuje redakcyjnego sprawdzenia nazw, dat, cen i charakteru usługi.
Przygotuj kilka reprezentatywnych stron do odbioru: główną, usługę, kontakt, archiwum i pojedynczy wpis. Po zmianie szablonu sprawdź je ponownie. Warto zapisać przykład wygenerowanego JSON-LD w raporcie testowym, aby później łatwiej porównać strukturę. Jeżeli integracja dodaje drugi opis tej samej organizacji, ustal, czy dane są spójne, zamiast dopisywać kolejne kopie bez kontroli.
Nie obiecuj rozszerzonego wyniku na żądanie
Poprawne dane nie gwarantują, że wyszukiwarka pokaże określone rozszerzenie; dokumentacja Google wskazuje takie ograniczenie. W ofercie wdrożenia należy więc rozdzielić wykonanie poprawnego opisu od decyzji zewnętrznego systemu o prezentacji. Uczciwy odbiór może potwierdzać zgodność danych, dostępność zasobów i wynik testu, ale nie stały wygląd rezultatu wyszukiwania u każdego użytkownika.
Schema.org warto traktować jako element porządku informacyjnego serwisu, obok czytelnych treści, właściwych adresów i spójnych danych firmy. Nie zastępuje ono tych podstaw. Dla DR-BOOST istotne jest, aby system rozumiał, że strona dotyczy usług związanych z profilem domeny i zawiera materiały edukacyjne. Najlepszym punktem wyjścia pozostają prawdziwe, jasno opisane informacje, które można utrzymywać wraz z rozwojem witryny.