Dane strukturalne schema.org: które typy wdrożyć na stronie firmy

Czym są dane strukturalne i po co je wdrażać

Dane strukturalne to zapisany w kodzie strony opis jej treści w słowniku, który rozumie wyszukiwarka: że dany fragment to cena produktu, data wydarzenia albo adres firmy, a nie przypadkowy ciąg znaków. Google używa tego opisu, żeby zrozumieć zawartość strony i pokazać ją jako wynik rozszerzony, czyli bogatszy wpis na liście wyników, z gwiazdkami, zdjęciem albo okruszkami nawigacyjnymi.

Słownik pochodzi ze wspólnego projektu schema.org, prowadzonego przez Google, Microsoft, Yandex i Yahoo. Schema.org opisuje to jako zbiór wspólnych słowników, których webmasterzy mogą używać do znakowania stron w sposób zrozumiały dla głównych wyszukiwarek. Zapis w tym słowniku wkleja się na stronę w jednym z trzech formatów: JSON-LD, Microdata albo RDFa.

Zakres tego artykułu to strona firmowa: usługi, lokalizacje, artykuły blogowe, opinie klientów. Osobno opisujemy pozycjonowanie w odpowiedziach asystentów AI, bo dane strukturalne to tylko jeden z elementów tamtego tematu, a nie jego istota. Wdrożeniem zajmuje się nasza usługa SEO techniczne, która sprawdza znaczniki razem z resztą kodu strony.

Które typy schema.org obsługuje Google

Pełna lista funkcji danych strukturalnych, które Google faktycznie zamienia na wynik rozszerzony, jest opublikowana w galerii wyszukiwania Google. To jedyne źródło, które warto sprawdzać: schema.org opisuje setki typów, ale Google obsługuje tylko wybrany podzbiór i tylko dla niego pokazuje wynik rozszerzony.

Do typu LocalBusiness Google zaleca wybór możliwie najbardziej szczegółowego podtypu. W dokumentacji lokalnej firmy czytamy: „Use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on”, czyli zamiast ogólnego LocalBusiness lepiej użyć konkretnego podtypu, jeśli istnieje. Dla agencji, kancelarii albo gabinetu, które nie mają wąskiego odpowiednika w słowniku, zostaje ogólny typ LocalBusiness albo ProfessionalService.

Dla LocalBusiness Google wymaga dwóch właściwości: adresu i nazwy. Dokumentacja podaje wprost: „Required properties address PostalAddress The physical location of the business. (...) name Text The name of the business”. To jeden z niewielu typów, gdzie Google w ogóle wskazuje pola obowiązkowe.

Organization: dane, które warto uzupełnić

Typ Organization nie ma pól wymaganych, ale im więcej właściwości pasujących do firmy, tym łatwiej Google powiązać wpis z prawidłowym podmiotem w panelu wiedzy. Przykład zapisu z dokumentacji Google pokazuje typowy zestaw pól: nazwę, adres URL, logo, opis, dane kontaktowe, adres i numer VAT.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Nazwa firmy",
  "url": "https://example.pl",
  "logo": "https://example.pl/logo.png",
  "telephone": "+48 000 000 000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykladowa 1",
    "addressLocality": "Krakow",
    "postalCode": "30-000",
    "addressCountry": "PL"
  }
}

BreadcrumbList: jedyny typ z wymaganą strukturą

BreadcrumbList to typ, dla którego Google jasno wymaga minimalnej struktury. Dokumentacja okruszków nawigacyjnych podaje: „To specify breadcrumbs, define a BreadcrumbList that contains at least two ListItems”, czyli lista musi zawierać co najmniej dwa elementy. Wymaganą właściwością samej listy jest itemListElement, tablica obiektów ListItem w kolejności od najwyższego poziomu strony w dół.

Nie trzeba dodawać okruszka dla strony głównej domeny ani dla samej strony, na której umieszczono znacznik. Google zaznacza też, że stary format data-vocabulary.org nie kwalifikuje się już do wyników rozszerzonych, więc strony, które zostały ze starszego wdrożenia, należy zaktualizować do schema.org.

Weźmy kancelarię z Krakowa, która ma na stronie sekcje usług podzielone na kategorie: prawo spadkowe, prawo rodzinne, obsługa firm. Każda podstrona usługi dostaje BreadcrumbList z pozycjami odpowiadającymi rzeczywistej ścieżce klikania, a nie strukturze folderów na serwerze. Dla podstrony konkretnej usługi w kategorii prawa spadkowego ścieżka wygląda tak, jak w schemacie wyżej, tylko z nazwami kategorii kancelarii zamiast nazw usług SEO.

Co zniknęło: FAQ i HowTo

Dwa typy, które jeszcze kilka lat temu dawały widoczne wyniki rozszerzone na liście wyników Google, dziś ich nie dają. Z tych znaczników nie należy już oczekiwać nowych gwiazdek, więc szkoda czasu na ich rozbudowę.

1. wrzesień 2023HowTo znika z wyników

   Google usunął dokumentację danych strukturalnych HowTo i opisał funkcję jako niewyświetlaną już w wynikach na komputerach ani na urządzeniach mobilnych.

2. 7 maja 2026FAQ przestaje się pojawiać

   Funkcja wyników rozszerzonych FAQ przestała pojawiać się w wyszukiwarce Google, zgodnie z zapowiedzią opublikowaną wcześniej na liście zmian.

Historię HowTo potwierdza wpis na liście aktualizacji dokumentacji Google z września 2023 roku: „Removed the How-to structured data documentation, as this rich result is no longer shown in search results, on both desktop and mobile devices”, czyli dokumentacja została usunięta, bo funkcja przestała pojawiać się w wynikach zarówno na komputerach, jak i na telefonach.

FAQ zniknęło później i stopniowo. Najpierw Google ograniczył je do wybranych witryn, a docelowo wycofał całkowicie. Na liście zmian z maja 2026 roku Google napisał wprost: „Deprecating the FAQ rich result feature (...) This feature will no longer appear in Google Search starting May 7, 2026”, czyli funkcja przestała się pojawiać od 7 maja 2026 roku.

Ten sam mechanizm, czyli że dokumentacja i wsparcie funkcji Google zmieniają się z miesiąca na miesiąc, dotyczy też wyszukiwania generatywnego. W przewodniku po pozycjonowaniu w AI opisujemy, które przekonania o AI Overview i asystentach są dziś nieaktualne.

Opinie o własnej firmie: zasady self-serving reviews

Najczęstszy błąd we wdrożeniach danych strukturalnych to gwiazdki przy własnej nazwie firmy w wynikach wyszukiwania, generowane z opinii, które firma sama kontroluje. Google ma na to jasną zasadę zapisaną w dokumentacji fragmentu opinii: „If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature. (...) Ratings must be sourced directly from users”.

Oznacza to, że strona usługi z sekcją „opinie klientów” wpisanymi ręcznie do CMS-a i oznakowanymi typem LocalBusiness albo Organization z polem aggregateRating nie kwalifikuje się do gwiazdek w wynikach, nawet jeśli opinie są prawdziwe. Ocena musi pochodzić bezpośrednio od użytkowników, najczęściej przez niezależny serwis opinii, który sam agreguje oceny i sam decyduje o ich publikacji.

Google zakazuje też agregowania opinii z innych serwisów na własnej stronie w tym samym znaczniku: „Don't aggregate reviews or ratings from other websites”. Kopiowanie ocen z Profilu Firmy w Google albo z innego portalu i wklejanie ich w znacznik LocalBusiness na własnej stronie łamie tę zasadę, nawet jeśli źródło zostanie podane w tekście.

Liczbę i charakter opinii, jakie realnie zbiera firma, oraz sposób ich pozyskiwania zgodny z zasadami opisujemy w tekście o zbieraniu opinii w Google, gdzie znaczniki to tylko jeden z elementów, obok samego procesu proszenia klientów o ocenę.

JSON-LD, Microdata, RDFa: który format wybrać

Google obsługuje trzy formaty zapisu danych strukturalnych i traktuje je równorzędnie pod względem technicznym, ale rekomenduje jeden z nich. W ogólnym wprowadzeniu do danych strukturalnych czytamy: „In general, we recommend using a format that's easiest for you to implement and maintain (in most cases, that's JSON-LD); all 3 formats are equally fine for Google, as long as the markup is valid and properly implemented”.

JSON-LD ma jedną praktyczną przewagę dla stron firmowych zarządzanych przez WordPressa, Shopify albo podobny CMS: znacznik nie miesza się z tekstem widocznym dla czytelnika, więc wtyczka SEO może go wygenerować i wstrzyknąć bez ingerencji w szablon strony. Microdata i RDFa wymagają dopisania atrybutów wprost do elementów HTML, co jest trudniejsze do utrzymania przy każdej zmianie szablonu.

Treść znacznika musi zgadzać się z treścią strony

Zasady jakości danych strukturalnych, opisane w wytycznych Google, zabraniają oznaczania treści, której nie widać na stronie: „Don't mark up content that is not visible to readers of the page. For example, if the JSON-LD markup describes a performer, the HTML body must describe that same performer”. Zabronione jest też oznaczanie treści nieaktualnych, wprowadzających w błąd albo niepowiązanych z tematem strony, w tym fałszywych opinii.

Jak przetestować dane strukturalne

Zanim znacznik trafi na produkcyjną stronę, warto sprawdzić go dwoma narzędziami: jednym od Google, drugim od schema.org. Sprawdzają one różne rzeczy i żadne z nich nie gwarantuje, że wynik rozszerzony faktycznie się pojawi.

1. Rich Results Test

   Narzędzie Google sprawdza, czy dany typ danych strukturalnych kwalifikuje się w ogóle do wyniku rozszerzonego w wyszukiwarce, i pokazuje podgląd. Dokumentacja galerii wyszukiwania zaznacza, że można nim „preview most features”, czyli podejrzeć większość, ale nie wszystkie funkcje.

2. Walidator znaczników schema.org

   Niezależny od Google walidator dostępny pod adresem validator.schema.org sprawdza zgodność znacznika ze słownikiem schema.org, niezależnie od tego, czy dany typ jest w ogóle obsługiwany przez wyszukiwarki jako wynik rozszerzony.

3. Narzędzie do sprawdzania adresów URL w Search Console

   Pokazuje, jakie dane strukturalne Google faktycznie odczytał z już zaindeksowanej strony, co bywa inne niż to, co widać w kodzie źródłowym przy pierwszym wdrożeniu.

Te dwa narzędzia robią co innego: Rich Results Test odpowiada na pytanie, czy Google pokaże z tego wynik rozszerzony, a walidator schema.org odpowiada na pytanie, czy sam zapis jest poprawny według słownika. Znacznik może być poprawny dla schema.org i jednocześnie bezużyteczny dla Google, jeśli opisuje typ, którego wyszukiwarka nie zamienia na wynik rozszerzony, jak wspomniane wcześniej FAQ i HowTo.

Po wdrożeniu warto sprawdzić stronę oboma narzędziami raz na kilka miesięcy, bo Google regularnie zmienia listę obsługiwanych typów i wymagań, tak jak zrobił to z FAQ i HowTo. Aktualną listę zmian publikuje na blogu Search Central.

Typowe błędy przy wdrożeniu na stronie firmowej

Większość problemów z danymi strukturalnymi nie wynika z błędnej składni JSON, tylko z niedopasowania znacznika do treści albo z nieaktualnej wiedzy o tym, co Google jeszcze obsługuje.

• Znacznik LocalBusiness ma wypełnione pola address i name, zgodnie z wymaganiami Google
• Opinie w znaczniku nie pochodzą z treści kontrolowanej przez samą firmę
• Strona nie blokuje dostępu do danych strukturalnych przez robots.txt ani noindex
• Treść znacznika JSON-LD odpowiada treści widocznej na stronie dla czytelnika
• BreadcrumbList zawiera co najmniej dwa elementy w poprawnej kolejności
• Znaczniki FAQPage i HowTo nie są jedynym elementem planu na wyniki rozszerzone
• Wdrożenie sprawdzone w Rich Results Test i w walidatorze schema.org

Osobny błąd to blokowanie dostępu do stron z danymi strukturalnymi. Wytyczne techniczne Google wprost zabraniają tego dla stron z wynikami rozszerzonymi: „Don't block your structured data pages to Googlebot using robots.txt, noindex, or any other access control methods”. Trzeba to sprawdzić zwłaszcza po migracji albo zmianie CMS-a, kiedy reguły blokowania bywają kopiowane bez przeglądu. Reguły dla robotów, w tym dla robotów AI, opisujemy osobno w tekście o robotach AI i pliku robots.txt.

Weźmy przykład sklepu internetowego z Poznania, który sprzedaje sprzęt ogrodniczy. Karty produktów mają znacznik Product z ceną i dostępnością, strona główna ma Organization, a każda podstrona kategorii ma BreadcrumbList. Brakuje tylko oznaczenia opinii klientów, bo sklep zbiera je przez zewnętrzny serwis opinii, a nie przez własny formularz, więc oznaczenie ich znacznikiem AggregateRating na stronie sklepu byłoby niezgodne z zasadami.