Dane strukturalne i schema.org dla firmy i sklepu — co realnie działa

Dane strukturalne to opis treści strony zapisany za pomocą wspólnego słownika schema.org, najczęściej w formacie JSON-LD. Pozwalają jednoznacznie wskazać między innymi nazwę produktu, cenę, dostępność, autora artykułu, adres firmy i miejsce strony w strukturze serwisu. Google wykorzystuje obsługiwane typy do lepszego zrozumienia treści i oceny, czy strona kwalifikuje się do wyniku rozszerzonego. Sam poprawny znacznik nie gwarantuje jednak, że taki wynik zostanie wyświetlony.

W skrócie

• Typ danych trzeba dopasować do rzeczywistej zawartości strony. Dla wielu firm przydatne są Organization i BreadcrumbList, dla sklepów Product z Offer, dla wydawców Article, a dla fizycznych placówek LocalBusiness.
• Google nie gwarantuje wyników rozszerzonych. Dokumentacja mówi wprost, że poprawne oznaczenie zgodne z testem nie oznacza wyświetlenia elementu rozszerzonego.
• FAQPage nie daje już wyniku rozszerzonego w Google. Funkcja przestała się wyświetlać 7 maja 2026 roku, a dokumentację usunięto 15 czerwca 2026. Widoczna sekcja FAQ nadal może być użyteczna, ale nie ma dowodu, że sam znacznik zwiększa szansę cytowania przez AI.
• HowTo zniknęło wcześniej, w 2023 roku, i również nie wraca — planowanie treści pod ten typ nie ma dziś sensu.
• Znacznik sprzeczny z widoczną treścią szkodzi. Wytyczne Google zabraniają oznaczania treści, której nie widzi czytelnik, oraz treści nieistotnych i wprowadzających w błąd.
• Ręczne działanie za dane strukturalne odbiera kwalifikację do wyników rozszerzonych, ale — zgodnie z dokumentacją — nie wpływa na pozycję strony w klasycznych wynikach.
• Dane strukturalne nie są dodatkowym wymogiem funkcji AI Google. Google wprost podaje, że AI Overviews i AI Mode nie wymagają specjalnego znacznika schema.org. Znacznik powinien wspierać zwykłe SEO i pozostawać zgodny z widoczną treścią.
• Kolejność wdrożenia ma znaczenie: najpierw encja firmy i nawigacja, potem oferta i treść, na końcu typy niszowe. Encje na poziomie ogólnym opisuje wpis o LLM SEO.

Które typy schema.org są przydatne dla firmy i sklepu

Schema.org obejmuje setki typów, ale nie każdy ma specjalne zastosowanie w Google. Wdrożenie powinno zaczynać się od typu, który najlepiej opisuje główną treść konkretnej strony. Poniższa tabela obejmuje najczęstsze potrzeby firmy, sklepu i bloga; serwisy z przepisami, wydarzeniami, ofertami pracy lub oprogramowaniem będą potrzebowały innych typów.

Kolejność wdrożenia wynika z tej tabeli i z jednej dodatkowej przesłanki: najpierw to, co opisuje tożsamość i strukturę serwisu, bo od tego zależy interpretacja wszystkiego innego. Organization i BreadcrumbList najpierw, potem Product albo Article — zależnie od tego, czym serwis jest — a typy niszowe tylko wtedy, gdy strona faktycznie taką treść zawiera.

Organization: encja marki w jednym miejscu

Organization jest jedynym typem, który opisuje nie stronę, a firmę. Dokumentacja Google zaleca umieszczenie go na stronie głównej albo na jednej stronie opisującej organizację, na przykład „o nas" — powtarzanie go w każdym szablonie nie jest potrzebne. Nie ma tu właściwości wymaganych; Google zaleca podanie tylu, ile jest istotnych dla danej organizacji, a aktualizacja tej dokumentacji jest z 15 kwietnia 2026 roku.

Znacznik działa na dwóch poziomach. Część właściwości pracuje w tle nad rozróżnieniem organizacji — czyli nad tym, żeby dwie firmy o podobnych nazwach nie zlały się w jedną encję. Część wpływa na elementy widoczne, na przykład na to, które logo pojawia się w wynikach i w panelu wiedzy. Najwięcej znaczą trzy grupy: nazwa i adres strony, sameAs z linkami do profili marki w innych serwisach oraz identyfikatory rejestrowe — vatID, taxID, a w bardziej sformalizowanych sytuacjach leiCode, iso6523Code, globalLocationNumber czy naics.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://przyklad.pl/#organizacja",
  "name": "Nazwa Firmy sp. z o.o.",
  "alternateName": "Nazwa Firmy",
  "url": "https://przyklad.pl",
  "logo": {
    "@type": "ImageObject",
    "url": "https://przyklad.pl/img/logo.png",
    "width": 512,
    "height": 512
  },
  "description": "Sklep z obuwiem sportowym, wysyłka na terenie Unii Europejskiej.",
  "foundingDate": "2018",
  "email": "kontakt@przyklad.pl",
  "telephone": "+48221234567",
  "vatID": "PL1234567890",
  "taxID": "1234567890",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Przykładowa 10",
    "postalCode": "00-001",
    "addressLocality": "Warszawa",
    "addressCountry": "PL"
  },
  "sameAs": [
    "https://www.linkedin.com/company/nazwa-firmy/",
    "https://www.facebook.com/nazwafirmy",
    "https://www.youtube.com/@nazwafirmy"
  ]
}

Dwie uwagi praktyczne. sameAs nie jest listą wszystkich kont w internecie, a wskazaniem profili, które faktycznie należą do marki i są utrzymywane — martwy profil z inną nazwą i innym zakresem usług dokłada sprzeczność, nie potwierdzenie. Identyfikatory rejestrowe warto podać, bo są weryfikowalne w publicznych rejestrach i wprost rozstrzygają, o którym podmiocie mowa; to również sygnał zaufania dla użytkownika, który sprawdza, z kim ma do czynienia.

Product z ofertą i dostępnością

Product to typ, w którym błąd kosztuje najwięcej, bo dotyczy ceny. Dokumentacja Google rozdziela dwa doświadczenia: wynik z ofertą sprzedażową (merchant listing) dla stron, na których da się kupić produkt, i skrócony wynik produktowy (product snippet) dla stron, które produkt opisują albo recenzują. Dla oferty sprzedażowej wymagane są name, image oraz offers z ceną i walutą — price i priceCurrency w kodzie ISO 4217, przy czym cena musi być większa od zera. Zalecane są availability, shippingDetails, hasMerchantReturnPolicy, brand, sku, a także review i aggregateRating, gdy opinie są na stronie.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Buty do biegania Model X",
  "image": [
    "https://przyklad.pl/img/model-x-1x1.jpg",
    "https://przyklad.pl/img/model-x-4x3.jpg"
  ],
  "description": "Buty na asfalt, amortyzacja neutralna, waga 245 g w rozmiarze 42.",
  "sku": "MX-42-BLK",
  "gtin13": "5901234123457",
  "brand": {
    "@type": "Brand",
    "name": "Marka X"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://przyklad.pl/buty/model-x",
    "price": "399.00",
    "priceCurrency": "PLN",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "PL",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "0",
        "currency": "PLN"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "PL"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 1,
          "maxValue": 2,
          "unitCode": "DAY"
        }
      }
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": 128
  }
}

Wartości availability i itemCondition podaje się jako pełne adresy słownika, na przykład https://schema.org/InStock albo https://schema.org/OutOfStock — skrót „InStock" bywa akceptowany przez walidatory, ale pełny adres nie zostawia miejsca na interpretację. Najczęstsza awaria w tym typie nie jest jednak składniowa. To rozjazd między znacznikiem a stroną: cena w JSON-LD z ostatniego wdrożenia, a na stronie po promocji inna; InStock w znaczniku i „chwilowo niedostępny" w koszyku; ocena 4,8 w danych strukturalnych i brak jakichkolwiek opinii w widocznej treści. Taki rozjazd jest jednocześnie problemem jakości i naruszeniem wytycznych.

W sklepach warto pamiętać, że dane strukturalne i feed produktowy to dwie osobne warstwy o wspólnym źródle. Znacznik opisuje stronę produktu dla wyszukiwarki i modeli, feed produktowy zasila kampanie i powierzchnie zakupowe. Gdy oba biorą dane z tego samego miejsca w systemie sklepu, przestają się rozjeżdżać — i to jest właściwa robota techniczna, opisana szerzej we wpisie o pozycjonowaniu sklepu internetowego.

BreadcrumbList: hierarchia, którą widzi maszyna

BreadcrumbList jest najtańszym sensownym wdrożeniem w całym zestawie. Opisuje pozycję strony w strukturze serwisu, dzięki czemu w wyniku wyszukiwania zamiast adresu URL może pojawić się czytelna ścieżka, a system streszczający ma wprost podaną relację między kategorią a produktem albo między działem a artykułem.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Strona główna",
      "item": "https://przyklad.pl"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Buty do biegania",
      "item": "https://przyklad.pl/buty-do-biegania"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Model X"
    }
  ]
}

Ostatni element ścieżki opisuje stronę bieżącą, więc nie podaje się dla niego item — to detal, który walidator zwykle wybacza, a który warto zrobić poprawnie. Druga zasada: ścieżka w znaczniku ma odpowiadać ścieżce widocznej na stronie i realnej strukturze adresów. Znacznik pokazujący ścieżkę, której w serwisie nie ma, jest opisem wymyślonej nawigacji.

Article i autorstwo

Article porządkuje trzy rzeczy, których model i wyszukiwarka nie odczytają z pewnością z samego tekstu: tytuł, daty i autorstwo. W tym typie również nie ma właściwości wymaganych — Google zaleca podanie tych, które mają zastosowanie: headline, image, datePublished, dateModified oraz author jako Person albo Organization.

Wytyczne o autorstwie są konkretne i często łamane. Wszyscy autorzy widoczni na stronie powinni znaleźć się w znaczniku, każdy w osobnym polu author, a nie zlepieni w jednym ciągu znaków. Typ ma być jednoznaczny — Person dla człowieka, Organization dla redakcji. author.name zawiera wyłącznie imię i nazwisko, bez stanowiska, tytułów ani nazwy wydawcy. Warto dodać url albo sameAs prowadzące do strony autora, bo to one wiążą podpis z konkretną osobą.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Jak dobrać buty do biegania po nawierzchni",
  "image": [
    "https://przyklad.pl/blog/buty/cover.jpg"
  ],
  "datePublished": "2026-07-23T12:00:00+02:00",
  "dateModified": "2026-07-23T12:00:00+02:00",
  "author": [
    {
      "@type": "Person",
      "name": "Anna Kowalska",
      "url": "https://przyklad.pl/autorzy/anna-kowalska",
      "sameAs": [
        "https://www.linkedin.com/in/anna-kowalska/"
      ]
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Nazwa Firmy",
    "logo": {
      "@type": "ImageObject",
      "url": "https://przyklad.pl/img/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://przyklad.pl/blog/buty-do-biegania-nawierzchnia"
  }
}

Daty warto podawać w formacie ISO 8601 razem ze strefą czasową. dateModified ma odpowiadać realnej aktualizacji treści — podbijanie tej daty bez zmiany treści nie jest sygnałem świeżości, a rozbieżnością między znacznikiem a stroną. Dokumentacja Google przy tym typie powtarza ogólną zasadę: nie ma gwarancji, że funkcje korzystające z danych strukturalnych pojawią się w wynikach.

FAQPage i to, co zmieniło się w 2026 roku

Tu potrzebna jest korekta, bo większość poradników — polskich i angielskich — nadal sprzedaje FAQ jako sposób na zajęcie większej powierzchni w wynikach. Dziennik zmian dokumentacji Google odnotowuje to w dwóch krokach: w maju 2026 roku pojawiło się ostrzeżenie, że funkcja przestaje być wyświetlana w wyszukiwarce od 7 maja 2026, a 15 czerwca 2026 usunięto dokumentację elementu rozszerzonego FAQ, ponieważ nie pojawia się już w wynikach. Wcześniej, od 2023 roku, funkcja była i tak ograniczona do znanych, autorytatywnych serwisów rządowych i zdrowotnych. HowTo zniknęło w 2023 roku i podobnie nie wróciło. W bieżącej galerii typów obsługiwanych przez Google ani FAQ, ani HowTo już nie ma.

Co z tego wynika praktycznie? FAQPage pozostaje poprawnym typem schema.org, ale nie zapewnia już dodatkowej powierzchni w Google. Wartość sekcji FAQ wynika przede wszystkim z widocznej treści: krótkie, samodzielne odpowiedzi pomagają czytelnikowi szybko rozwiązać problem i są łatwe do zrozumienia bez czytania całego artykułu. Nie ma podstaw, aby obiecywać, że dodanie samego znacznika zwiększy widoczność w ChatGPT lub innych odpowiedziach AI. Typ Q&A jest przeznaczony do stron, na których użytkownicy publikują wiele odpowiedzi na pytanie, a nie do redakcyjnego FAQ firmy.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Ile trwa dostawa zamówienia?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Zamówienia złożone do godziny 14:00 wysyłamy tego samego dnia roboczego, a przesyłka kurierska dochodzi w ciągu 1-2 dni roboczych."
      }
    },
    {
      "@type": "Question",
      "name": "Jaki jest termin na zwrot?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Zwrot można zgłosić w ciągu 30 dni od odbioru przesyłki, a koszt odesłania pokrywa sklep."
      }
    }
  ]
}

Wniosek dla planowania treści: FAQ warto pisać dla czytelnika i dla cytowalności, a nie pod element rozszerzony, którego nie ma. Sztuczne pytania dopisane wyłącznie po to, żeby wypełnić znacznik, kończą się treścią, której nikt nie zadaje, i sekcją, którą trudno obronić przed audytem jakości.

LocalBusiness, gdy dotyczy

LocalBusiness i typy od niego pochodne — na przykład sklep sportowy, restauracja, gabinet — mają sens tylko wtedy, gdy firma obsługuje klientów w konkretnym miejscu albo na konkretnym terenie. Wtedy znacznik porządkuje dane, które w innym wypadku występują w serwisie w kilku niespójnych wersjach: adres, telefon, godziny otwarcia, obszar obsługi.

{
  "@context": "https://schema.org",
  "@type": "SportingGoodsStore",
  "name": "Nazwa Firmy — salon Warszawa",
  "url": "https://przyklad.pl/salony/warszawa",
  "image": "https://przyklad.pl/img/salon-warszawa.jpg",
  "telephone": "+48221234567",
  "priceRange": "200-900 PLN",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Przykładowa 10",
    "postalCode": "00-001",
    "addressLocality": "Warszawa",
    "addressCountry": "PL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.2321,
    "longitude": 21.0059
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "10:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "16:00"
    }
  ]
}

Znacznik nie zastępuje profilu firmy w Google — dane widoczne w mapach i w panelu lokalnym pochodzą z profilu, nie ze strony. Rola danych strukturalnych jest inna: mają potwierdzać to samo, co profil, żeby nie powstała trzecia wersja adresu i godzin. Przy wielu placówkach każda dostaje własną stronę i własny znacznik, a nie jedną stronę z listą wszystkich lokalizacji w jednym obiekcie.

Słowniczek

• Dane strukturalne — opis treści strony w ustalonym słowniku, czytelny dla maszyn, umieszczany w kodzie strony obok treści widocznej dla użytkownika.
• schema.org — wspólny słownik typów i właściwości (Product, Organization, Article), rozwijany przez konsorcjum wyszukiwarek.
• JSON-LD — format zapisu danych strukturalnych w bloku skryptu, rekomendowany przez Google; alternatywy to Microdata i RDFa.
• Wynik rozszerzony — wzbogacona forma wyniku wyszukiwania korzystająca z danych strukturalnych, na przykład z ceną, dostępnością i oceną.
• Encja — maszynowa tożsamość firmy, osoby lub produktu, którą system ustala przed odpowiedzią na pytanie o nie.
• sameAs — właściwość wskazująca inne adresy opisujące ten sam podmiot, używana do potwierdzenia tożsamości encji.
• Ręczne działanie za dane strukturalne — decyzja zespołu Google odbierająca stronie kwalifikację do wyników rozszerzonych; zgodnie z dokumentacją nie wpływa na pozycję w klasycznych wynikach.

Spójność: znacznik sprzeczny z treścią szkodzi

To najważniejsza zasada w całym temacie, ważniejsza od doboru typów. Wytyczne Google dotyczące danych strukturalnych zabraniają oznaczania treści, której nie widzi czytelnik strony — jeśli JSON-LD opisuje wykonawcę, ten sam wykonawca musi być opisany w treści HTML. Zabraniają też oznaczania treści nieistotnych i wprowadzających w błąd, w tym fałszywych opinii, oraz używania danych strukturalnych do wprowadzania w błąd co do własności, powiązań i charakteru działalności. Konsekwencją naruszenia jest ręczne działanie: strona traci kwalifikację do wyniku rozszerzonego, choć — jak stwierdza dokumentacja — nie wpływa to na jej pozycję w klasycznych wynikach wyszukiwania. Dokumentacja tych wytycznych była aktualizowana 10 lipca 2026 roku.

Rozbieżność jest problemem także dla użytkownika i każdego systemu przetwarzającego stronę. Jeżeli znacznik podaje cenę 399 zł, a widoczna oferta 349 zł, nie wiadomo, która wartość jest aktualna. Dlatego cena, dostępność, liczba opinii i daty powinny pochodzić z tego samego źródła co treść wyświetlana na stronie.

Dane strukturalne a AI Overviews, ChatGPT i inne systemy AI

W tym miejscu trzeba oddzielić dokumentację od przypuszczeń. Google podaje, że AI Overviews i AI Mode nie wymagają specjalnego znacznika schema.org. Zaleca jednak, aby stosowane dane strukturalne były zgodne z widoczną treścią, ponieważ nadal służą zwykłym funkcjom wyszukiwarki. Nie ma publicznej dokumentacji potwierdzającej, że FAQPage, Organization lub inny typ sam w sobie zwiększa szansę cytowania w ChatGPT, Claude czy Perplexity.

Poprawne dane strukturalne warto utrzymywać ze względu na ich potwierdzone zastosowania: opis organizacji, kwalifikację do obsługiwanych wyników rozszerzonych oraz jednoznaczne powiązanie informacji w obrębie strony. Widoczność w odpowiedziach AI wymaga szerszego fundamentu — dostępnej technicznie strony, spójnej tożsamości marki, pomocnej treści i źródeł potwierdzających najważniejsze informacje. Schema.org może być częścią porządnego wdrożenia SEO, ale nie należy przedstawiać go jako bezpośredniego mechanizmu pozyskiwania cytowań.

Warstwa encji i architektury informacji jest częścią tego, co prowadzimy jako usługę AI SEO dla marek i sklepów — obok dostępu dla robotów, treści pod cytowanie i pomiaru cytowań. Ogólny obraz tego, jak działa cytowanie marki przez modele, opisuje wpis o LLM SEO, a sposób doboru źródeł w wynikach generatywnych — wpis o AI Overviews i GEO. Osobna, cieńsza warstwa to plik kontekstowy w katalogu głównym domeny, którą opisuje wpis o llms.txt.

Walidacja i granice obietnic

Walidacja składa się z trzech narzędzi o różnym zakresie i mieszanie ich prowadzi do złych wniosków. Test wyników z elementami rozszerzonymi Google sprawdza wyłącznie te typy, które Google obsługuje, i odpowiada na pytanie o kwalifikację do konkretnej funkcji. Walidator schema.org sprawdza poprawność wobec całego słownika, także typów, których Google nie używa w wynikach. Raporty w Search Console pokazują, co Google widzi na realnych, zaindeksowanych stronach, oraz informują o ręcznych działaniach.

Kolejność pracy jest prosta: walidator schema.org na etapie budowania znacznika, test wyników rozszerzonych przed wdrożeniem, raporty Search Console po wdrożeniu. Trzy szczegóły, o których łatwo zapomnieć. Znacznik trzeba testować na wyrenderowanym kodzie strony, nie na tym, co wychodzi z systemu zarządzania treścią — zwłaszcza gdy JSON-LD wstrzykuje menedżer tagów. Strony ze znacznikiem nie mogą być zablokowane dla robota, bo wytyczne wprost zabraniają blokowania takich stron w robots.txt czy przez noindex. I stan „bez błędów" w walidatorze nie jest tym samym co „widoczne w wynikach".

Granica obietnic jest wyznaczona przez samą dokumentację: Google nie gwarantuje, że dane strukturalne pojawią się w wynikach wyszukiwania, nawet jeśli strona jest oznaczona poprawnie zgodnie z testem. Warto to mówić wprost w rozmowie o zakresie prac — poprawne oznaczenie kupuje kwalifikację, nie miejsce. Szerszy przegląd tego, co sprawdzić w warstwie technicznej, jest we wpisie o audycie SEO.

Jak podchodzimy do tego w Space Ads

Zaczynamy od ustalenia, jakie fakty strona ma opisywać i gdzie znajduje się ich źródło. Następnie dobieramy typ właściwy dla danej podstrony i łączymy obiekty przez stabilne identyfikatory @id. Ceny, dostępność, opinie i daty generujemy z tego samego systemu co widoczna treść, dzięki czemu zmiana w sklepie aktualizuje również JSON-LD. Po wdrożeniu sprawdzamy wyrenderowany kod w walidatorze schema.org, te funkcje, które Google obsługuje — w Rich Results Test, a stan zaindeksowanych stron — w Search Console. Nie obiecujemy elementu rozszerzonego ani cytowania w AI. Poprawne oznaczenie zapewnia zgodność i kwalifikację do obsługiwanej funkcji; o jej wyświetleniu decyduje wyszukiwarka.

Plan działania

1. Spisać fakty, które mają być jednoznaczne. Nazwa prawna i handlowa, adres, identyfikatory, kategoria, kontakt, autorzy treści, dane oferty. To lista wejściowa do znacznika.
2. Wdrożyć Organization na jednej stronie. Strona główna albo „o nas", z sameAs do utrzymywanych profili i identyfikatorami rejestrowymi.
3. Dodać BreadcrumbList w szablonach. Ścieżka generowana z realnej hierarchii kategorii, bez item w ostatnim elemencie.
4. Oznaczyć główną treść podstrony. Product z ofertą na stronie produktu, Article przy publikacji, LocalBusiness na stronie placówki. Kilka typów można połączyć, jeżeli każdy opisuje widoczną treść i relacje między obiektami są jasne.
5. Powiązać znacznik ze źródłem danych. Cena, dostępność, oceny i daty mają pochodzić z tego samego miejsca, z którego renderuje się treść strony.
6. Uzgodnić dane lokalne z profilem firmy. Adres, telefon i godziny w znaczniku identyczne jak w profilu; przy wielu placówkach jedna strona na placówkę.
7. Przejść walidację w trzech krokach. Walidator schema.org, test wyników rozszerzonych, potem raporty w Search Console na wyrenderowanym kodzie.
8. Wpisać rewizję w procedurę zmian. Zmiana szablonu, cennika, oferty albo autorów pociąga rewizję znacznika w tym samym zadaniu.

Częsty błąd i co zrobić zamiast tego

Najczęstsze pytania

Czym są dane strukturalne i po co je stosować?

Dane strukturalne to opis treści strony w słowniku schema.org, umieszczany w kodzie strony najczęściej jako JSON-LD. Pozwalają wyszukiwarce i modelom odczytać fakty wprost — nazwę produktu, cenę, dostępność, autora, adres firmy — zamiast wnioskować je z układu tekstu. Dają kwalifikację do wyników rozszerzonych i porządkują fakty o encji.

Który format danych strukturalnych wybrać?

Google obsługuje JSON-LD, Microdata oraz RDFa, a najczęściej rekomenduje wybór formatu najłatwiejszego do wdrożenia i utrzymania. W praktyce zwykle jest nim JSON-LD, ponieważ cały opis znajduje się w osobnym bloku i łatwiej generować go z danych szablonu bez ingerowania w znaczniki widocznej treści.

Czy schema.org gwarantuje wynik rozszerzony w Google?

Nie. Dokumentacja Google stwierdza, że nie gwarantuje pojawienia się danych strukturalnych w wynikach wyszukiwania, nawet gdy strona jest oznaczona poprawnie zgodnie z testem wyników rozszerzonych. Poprawne oznaczenie daje kwalifikację, a decyzja o wyświetleniu należy do wyszukiwarki.

Czy FAQPage nadal działa?

Znacznik FAQPage nadal jest poprawnym typem schema.org, ale nie daje już elementu rozszerzonego w Google: funkcja przestała się wyświetlać 7 maja 2026 roku, a dokumentację usunięto 15 czerwca 2026. Sekcja FAQ nadal może pomagać użytkownikom, jeśli odpowiada na realne pytania. Nie należy jednak obiecywać dodatkowej widoczności dzięki samemu znacznikowi.

Czy dane strukturalne pomagają w cytowaniu przez ChatGPT albo AI Overviews?

Nie są wymagane do AI Overviews ani AI Mode. Google wprost podaje, że te funkcje nie potrzebują specjalnego znacznika schema.org. Nie ma również publicznego potwierdzenia, że samo dodanie danych strukturalnych zwiększa szansę cytowania w ChatGPT lub Perplexity. Warto je wdrażać ze względu na potwierdzone zastosowania w wyszukiwarce i spójny opis strony.

Co się dzieje, gdy znacznik jest sprzeczny z treścią strony?

Wytyczne Google zabraniają oznaczania treści, której nie widzi czytelnik, oraz treści nieistotnych i wprowadzających w błąd. Naruszenie może skończyć się ręcznym działaniem, po którym strona traci kwalifikację do wyników rozszerzonych — zgodnie z dokumentacją bez wpływu na pozycję w klasycznych wynikach. Dla modelu sprzeczność oznacza brak pewności wobec obu wersji faktu.

Gdzie umieścić znacznik Organization?

Na stronie głównej albo na jednej stronie opisującej organizację, na przykład „o nas" — tak zaleca dokumentacja Google. Powtarzanie tego znacznika na każdej podstronie nie jest potrzebne i utrudnia utrzymanie spójności przy zmianach danych firmy.

Czym walidator schema.org różni się od testu wyników rozszerzonych?

Walidator schema.org sprawdza poprawność znacznika wobec całego słownika, także typów nieużywanych przez Google w wynikach. Test wyników z elementami rozszerzonymi sprawdza wyłącznie funkcje obsługiwane przez Google i odpowiada na pytanie o kwalifikację do konkretnego wyniku. Stan realny na zaindeksowanych stronach pokazują raporty w Search Console.

Najważniejsze

• Dla typowej strony firmowej, sklepu i bloga najczęściej przydają się Organization, Product z ofertą, BreadcrumbList, Article oraz LocalBusiness; inne rodzaje serwisów wymagają innych typów.
• FAQPage nie daje już elementu rozszerzonego w Google od maja 2026, a HowTo zniknęło w 2023 — FAQ warto pisać pod cytowalność, nie pod funkcję wyszukiwarki.
• Spójność jest ważniejsza od pokrycia: znacznik sprzeczny z widoczną treścią narusza wytyczne i odbiera wiarygodność faktom, które były poprawne.
• Znacznik należy generować z tego samego źródła danych, z którego renderuje się treść, bo najczęstszą awarią jest rozjazd ceny, dostępności i ocen.
• Dane strukturalne nie są dodatkowym wymogiem AI Overviews ani AI Mode, a ich bezpośredni wpływ na cytowania w innych systemach AI nie jest publicznie potwierdzony.
• Poprawne oznaczenie daje kwalifikację, nie wynik rozszerzony — dokumentacja Google nie gwarantuje wyświetlenia, więc taką obietnicę warto zdjąć z rozmowy o zakresie prac.

Źródła

• Google Search Central — Ogólne wytyczne dotyczące danych strukturalnych
• Google Search Central — Galeria typów danych strukturalnych obsługiwanych w wyszukiwarce
• Google Search Central — Dane strukturalne organizacji
• Google Search Central — Dane strukturalne produktu i oferty sprzedażowej
• Google Search Central — Dane strukturalne artykułu
• Google Search Central — Funkcje AI a witryna internetowa
• Google Search Central — Dziennik zmian dokumentacji
• schema.org — pełny słownik typów i właściwości
• schema.org — walidator znaczników

Opisane wymagania, funkcje wyszukiwarki i daty zmian odpowiadają dokumentacji na stan lipiec 2026 — dostawcy zmieniają zakres obsługiwanych typów i wymagania właściwości, więc przed wdrożeniem opartym na konkretnej regule warto sprawdzić aktualną dokumentację.

Czytaj dalej

• LLM SEO: jak zwiększyć szansę, że AI cytuje markę
• llms.txt: czym jest ten plik, kto go czyta i co realnie daje
• AI Overviews i GEO: cytowania marki w wyszukiwaniu AI
• Czym jest audyt SEO i jak go poprawnie wykonać
• Pozycjonowanie sklepu internetowego: SEO w e-commerce
• AI SEO · Audyt marketingowy