Dane strukturalne: 7 wzorów JSON-LD schema.org dla firmy

Dane strukturalne to opis strony zapisany w ustalonym formacie, który maszyna odczyta bez zgadywania. Zamiast liczyć, że wyszukiwarka sama znajdzie w stopce adres firmy, podajesz go wprost: to jest nazwa, to ulica, to kod pocztowy, a to telefon. Nazwy typów i właściwości pochodzą ze słownika schema.org, wspólnego projektu wyszukiwarek. Google opisuje dane strukturalne jako wyraźne wskazówki o znaczeniu strony.

Co z tego masz? Po pierwsze, strona może kwalifikować się do wyników rozszerzonych: ceny i dostępności produktu, okruszków nad tytułem czy logo w panelu wiedzy. Po drugie, Google łatwiej łączy stronę z firmą, autorem albo produktem, o których mowa. W dokumentacji Google przytacza firmy, które to zmierzyły. Rotten Tomatoes oznaczył 100 000 stron i zanotował o 25% wyższy CTR na stronach z danymi strukturalnymi niż na stronach bez nich.

Dwie rzeczy warto wiedzieć od początku. Poprawny kod nie gwarantuje wyniku rozszerzonego: Google sam decyduje, co pokazać, zależnie od zapytania, urządzenia i lokalizacji użytkownika. Dane muszą też opisywać to, co widzi czytelnik. Oznaczanie treści niewidocznych na stronie albo nieprawdziwych opinii może skończyć się ręcznym działaniem. Takie działanie odbiera stronie kwalifikację do wyników rozszerzonych, ale według Google nie zmienia jej pozycji w zwykłych wynikach.

JSON-LD, mikrodane czy RDFa?

Google obsługuje trzy formaty i każdy jest dla niego równie dobry, jeśli kod jest poprawny. Zaleca jednak JSON-LD, bo najłatwiej go wdrożyć i utrzymać. JSON-LD to osobny blok <script type="application/ld+json"> w kodzie strony, niezależny od tekstu. Mikrodane i RDFa to atrybuty dopisane do znaczników HTML, więc zmiana wyglądu strony łatwo je psuje. Wszystkie wzory na tej stronie są w JSON-LD.

Google odczyta też JSON-LD wstawiony przez JavaScript, np. przez Google Tag Manager albo widżet w CMS. Przy produktach ostrzega jednak, że dane generowane dynamicznie mogą sprawić, że roboty zakupowe będą odwiedzać stronę rzadziej i mniej niezawodnie. Dlatego cenę i dostępność najlepiej mieć w HTML wysłanym przez serwer.

Nie musisz oznaczać wszystkiego. Dla strony firmowej, sklepu albo bloga zwykle wystarczy siedem typów ze słownika schema.org. Każdy ma swoje miejsce: dane firmy na stronie głównej, okruszki na podstronach, artykuł na wpisie blogowym. Tabela pokazuje, gdzie wstawić dany typ, co może dać w Google i bez których właściwości kod w ogóle nie kwalifikuje się do funkcji w wynikach.

Czego brakuje w tabeli? FAQPage i HowTo. Oba typy nadal są w słowniku schema.org, ale Google nie pokazuje już wyników rozszerzonych z ich danych (szczegóły niżej, w sekcji o FAQ i AI). Typ Service, który często widać na stronach usług, nie daje osobnego wyniku rozszerzonego. Google może jednak ogólnie korzystać z danych schema.org i właściwości sameAs, więc nie musisz go usuwać, jeśli opisuje to, co widać na stronie.

Tak to wygląda u nas: na ai-seo-company.pl każda strona ma blok firmy (LocalBusiness) i WebSite, strony usług dodatkowo Service i BreadcrumbList, a strona O nas blok Person założyciela. Tak w praktyce wyglądają dane strukturalne Google na stronie firmy usługowej: kilka typów, każdy z danymi widocznymi na stronie.

Schema Organization mówi Google, kim jest firma: jak się nazywa, gdzie ma siedzibę, jak się z nią skontaktować i które profile w sieci do niej należą. Google nie wymaga tu żadnej właściwości. Zaleca dodać wszystkie, które pasują do firmy, a zwłaszcza przydatne klientom: nazwę, adres albo telefon jako dowód działalności w realnym świecie oraz adres strony i logo jako obecność w sieci.

Blok wstaw na stronie głównej albo na jednej stronie o firmie, np. „O nas”. Nie musisz powtarzać go na każdej podstronie. Jeśli firma przyjmuje klientów w lokalu albo działa na określonym obszarze, użyj zamiast niego podtypu LocalBusiness z następnej sekcji. To też Organization, tylko dokładniejszy.

Wzór JSON-LD: Organization

{ "@context": "https://schema.org", "@type": "Organization", "@id": "https://www.twojadomena.pl/#organizacja", "name": "Nazwa Firmy", "legalName": "Nazwa Firmy Sp. z o.o.", "url": "https://www.twojadomena.pl/", "logo": "https://www.twojadomena.pl/logo.png", "description": "Jedno zdanie o tym, czym zajmuje się firma.", "email": "kontakt@twojadomena.pl", "telephone": "+48 22 000 00 00", "address": { "@type": "PostalAddress", "streetAddress": "ul. Przykładowa 1", "addressLocality": "Warszawa", "postalCode": "00-001", "addressCountry": "PL" }, "taxID": "0000000000", "vatID": "PL0000000000", "sameAs": [ "https://www.linkedin.com/company/nazwa-firmy", "https://www.facebook.com/nazwafirmy" ] }

Co oznaczają pola

• @id – stały identyfikator firmy w Twoich danych, np. adres strony z dopiskiem #organizacja. Inne bloki mogą wskazać tę samą firmę przez {"@id": "…"}, bez kopiowania całego opisu.
• name i legalName – nazwa, której używasz na stronie i w wizytówce, oraz pełna nazwa z rejestru, jeśli jest inna. Google prosi, żeby name było takie samo jak nazwa witryny w WebSite.
• logo – adres pliku z logo, co najmniej 112 × 112 pikseli, dostępny dla Googlebota (niezablokowany w robots.txt).
• sameAs – adresy profili firmy w innych serwisach: LinkedIn, Facebook, YouTube, katalog branżowy. Tylko profile, które naprawdę należą do firmy.
• taxID i vatID – NIP w taxID. Jeśli firma ma numer VAT UE, możesz podać go w vatID z prefiksem PL. Google nazywa numer VAT ważnym sygnałem zaufania, bo użytkownik sprawdzi go w publicznym rejestrze.

Wzór JSON-LD: WebSite (nazwa witryny)

WebSite podpowiada Google, jaką nazwę witryny pokazać nad wynikiem wyszukiwania. Wymagane są dwie właściwości, name i url, a blok wstawiasz tylko na stronie głównej. Krótszą wersję nazwy albo skrót podaj w alternateName. Google bierze pod uwagę także tytuł i nagłówki strony głównej, więc używaj tej samej nazwy wszędzie.

{ "@context": "https://schema.org", "@type": "WebSite", "name": "Nazwa Firmy", "alternateName": "NF", "url": "https://www.twojadomena.pl/" }

Pole wyszukiwania pod wynikiem (sitelinks search box) zniknęło z Google, a jego dokumentację usunięto w listopadzie 2024 roku. Fragment potentialAction z SearchAction w bloku WebSite nic dziś w Google nie daje.

LocalBusiness to dane strukturalne dla firmy z lokalem albo obszarem działania: gabinetu, warsztatu, restauracji, kancelarii, hydraulika. W poradnikach znajdziesz go też jako „schema local business”. Google wymaga dwóch właściwości: nazwy (name) i adresu (address). Zaleca m.in. telefon, adres strony, godziny otwarcia, współrzędne i przedział cen. LocalBusiness jest podtypem Organization, więc możesz w nim użyć też pól z poprzedniej sekcji, np. logo, sameAs i NIP.

Użyj najdokładniejszego typu, jaki pasuje do firmy. schema.org ma dziesiątki podtypów, np. Dentist, Plumber, Electrician, AutoRepair, HairSalon, AccountingService, Restaurant. Firma, która świadczy kilka rodzajów usług, może podać kilka typów w tablicy, np. "@type": ["Electrician", "Plumber"]. Właściwości additionalType Google tu nie obsługuje. Gdy żaden podtyp nie pasuje, zostaje ogólny LocalBusiness.

Wzór JSON-LD: LocalBusiness (hydraulik w Warszawie)

{ "@context": "https://schema.org", "@type": "Plumber", "@id": "https://www.twojadomena.pl/#firma", "name": "Nazwa Firmy", "url": "https://www.twojadomena.pl/", "image": "https://www.twojadomena.pl/zdjecia/siedziba.jpg", "logo": "https://www.twojadomena.pl/logo.png", "telephone": "+48 22 000 00 00", "email": "kontakt@twojadomena.pl", "address": { "@type": "PostalAddress", "streetAddress": "ul. Przykładowa 1", "addressLocality": "Warszawa", "postalCode": "00-001", "addressCountry": "PL" }, "geo": { "@type": "GeoCoordinates", "latitude": 52.231812, "longitude": 21.006012 }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" ], "opens": "08:00", "closes": "18:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "09:00", "closes": "14:00" } ], "priceRange": "150-400 zł", "sameAs": [ "https://www.facebook.com/nazwafirmy" ] }

Zasady, o których najczęściej się zapomina

• NAP jak w wizytówce. Nazwa, adres i telefon w kodzie powinny być identyczne z tymi na stronie i w Profilu Firmy w Google. Tak pracujemy przy SEO lokalnym: jeden zapis NAP jest źródłem dla strony, wizytówki, katalogów i danych strukturalnych.
• Telefon z kodem kraju, np. +48 22 000 00 00. Google prosi o kod kraju i numer kierunkowy.
• Współrzędne z dokładnością co najmniej 5 miejsc po przecinku w geo.latitude i geo.longitude. Skopiujesz je z Map Google: kliknij prawym przyciskiem miejsce firmy na mapie.
• Godziny w formacie 24-godzinnym (opens, closes) i dni tygodnia po angielsku: Monday… Sunday. Sezonowe zamknięcie opisz datami validFrom i validThrough.
• priceRange krótszy niż 100 znaków, np. „$$” albo „150-400 zł”. Dłuższego Google nie pokaże.
• Bez własnych ocen w gwiazdkach. aggregateRating i review w LocalBusiness są tylko dla serwisów, które zbierają opinie o innych firmach. Jeśli firma sama kontroluje opinie o sobie, jej strony z LocalBusiness albo Organization nie kwalifikują się do gwiazdek. Opinie klientów zbieraj w Profilu Firmy w Google.
• Jedna placówka, jeden blok. Google prosi, żeby każdą lokalizację opisać osobnym LocalBusiness, najlepiej na jej własnej stronie z adresem i godzinami.

Dane strukturalne nie zastąpią wizytówki. W lokalnych wynikach Google bierze pod uwagę trafność, odległość i rozpoznawalność firmy, a do tej ostatniej liczy m.in. linki i opinie. Jak nad tym pracujemy, opisujemy na stronach pozycjonowanie wizytówki Google i SEO lokalne w Warszawie.

Article oznacza wpis na blogu, poradnik albo aktualność. Google nie wymaga w nim żadnej właściwości, ale zaleca tytuł (headline), obraz, datę publikacji i aktualizacji oraz autora. Daty i autor w kodzie mają zgadzać się z tym, co widać na stronie, a obraz ma dotyczyć treści artykułu.

Najwięcej błędów jest w polu author. Google zaleca: każdego autora jako osobny obiekt, typ Person dla ludzi i Organization dla firm, a w name samo imię i nazwisko, bez stanowiska, tytułu naukowego i słów „autor:”. Stanowisko wpisz w jobTitle. Do tego url albo sameAs, czyli link do strony autora.

Wzór JSON-LD: Article z autorem

{ "@context": "https://schema.org", "@type": "Article", "headline": "Tytuł artykułu taki jak w nagłówku H1", "image": [ "https://www.twojadomena.pl/blog/okladka-16x9.jpg", "https://www.twojadomena.pl/blog/okladka-1x1.jpg" ], "datePublished": "2026-11-11T08:00:00+01:00", "dateModified": "2026-11-11T08:00:00+01:00", "author": [ { "@type": "Person", "name": "Jan Kowalski", "jobTitle": "Specjalista SEO", "url": "https://www.twojadomena.pl/autorzy/jan-kowalski" } ], "publisher": { "@type": "Organization", "name": "Nazwa Firmy", "url": "https://www.twojadomena.pl/" } }

Wzór JSON-LD: strona autora (ProfilePage i Person)

Strona autora to miejsce, do którego prowadzi author.url. ProfilePage mówi Google, że strona dotyczy jednej osoby, a zagnieżdżony Person opisuje, kim ona jest. Wymagane są mainEntity i name. Google wymienia artykuły jako typ, który może wskazywać takie strony profilowe.

{ "@context": "https://schema.org", "@type": "ProfilePage", "dateModified": "2026-11-11T08:00:00+01:00", "mainEntity": { "@type": "Person", "name": "Jan Kowalski", "jobTitle": "Specjalista SEO", "description": "Jedno lub dwa zdania o doświadczeniu i specjalizacji autora.", "image": "https://www.twojadomena.pl/autorzy/jan-kowalski.jpg", "worksFor": { "@type": "Organization", "name": "Nazwa Firmy", "url": "https://www.twojadomena.pl/" }, "knowsAbout": [ "SEO techniczne", "dane strukturalne" ], "sameAs": [ "https://www.linkedin.com/in/twoj-profil" ] } }

Po co to firmie? Google pyta w swoich wskazówkach o treściach, czy czytelnik od razu widzi, kto jest autorem, i czy podpis prowadzi do informacji o nim. Według Google jasne autorstwo jest zgodne z koncepcją E-E-A-T, czyli doświadczenia, wiedzy, autorytetu i wiarygodności. Samo E-E-A-T nie jest jednak konkretnym czynnikiem rankingowym, a kod nie doda autorowi doświadczenia. Najpierw musi istnieć prawdziwa strona z biogramem, zdjęciem i specjalizacją. Zmyślone profile autorów Google uznaje za oszustwo.

U nas wygląda to tak: strona O nas ma blok Person założyciela z jobTitle, worksFor i knowsAbout, zgodny z tym, co jest napisane na stronie.

BreadcrumbList opisuje miejsce strony w strukturze serwisu: Strona główna › Usługi › Hydraulik awaryjny. Google wymaga listy co najmniej dwóch elementów ListItem. Każdy ma pozycję (position), nazwę (name) i adres (item). Ostatni element może nie mieć adresu, wtedy Google użyje adresu bieżącej strony. Ścieżka w kodzie powinna odpowiadać okruszkom widocznym na stronie.

Od stycznia 2025 roku Google pokazuje okruszki w wynikach tylko na komputerach, bo na małych ekranach były przycinane. Dane nadal warto mieć: działają w wynikach na komputerach i porządkują opis struktury serwisu.

Wzór JSON-LD: BreadcrumbList

{ "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Strona główna", "item": "https://www.twojadomena.pl/" }, { "@type": "ListItem", "position": 2, "name": "Usługi", "item": "https://www.twojadomena.pl/uslugi" }, { "@type": "ListItem", "position": 3, "name": "Hydraulik awaryjny" } ] }

Wzór JSON-LD: Product z ofertą

Product to dane karty produktu. Do fragmentu produktu w wynikach Google wymaga nazwy (name) i jednej z trzech właściwości: oferty (offers), opinii (review) albo oceny zbiorczej (aggregateRating). Sklep, w którym da się kupić produkt, może kwalifikować się też do kart sprzedawcy (merchant listings). Tam wymagane są name, image i offers, a waluta jest obowiązkowa. W ofercie podaj cenę jako liczbę, walutę w kodzie ISO 4217 (PLN) i dostępność, np. InStock.

{ "@context": "https://schema.org", "@type": "Product", "name": "Nazwa produktu", "image": [ "https://www.twojadomena.pl/produkty/nazwa-produktu-1x1.jpg" ], "description": "Krótki opis produktu taki jak na karcie.", "sku": "SKU-0001", "brand": { "@type": "Brand", "name": "Marka" }, "offers": { "@type": "Offer", "url": "https://www.twojadomena.pl/produkty/nazwa-produktu", "price": 149.99, "priceCurrency": "PLN", "availability": "https://schema.org/InStock" } }

Cena, dostępność i oceny w kodzie muszą zgadzać się z tym, co widzi klient na karcie produktu, i z plikiem produktowym w Merchant Center. Typowy problem: promocja zmienia cenę na stronie, a JSON-LD generowany z innego pola zostaje przy starej. Jeśli podajesz priceValidUntil, pilnuj daty: z datą z przeszłości fragment produktu może się nie wyświetlić.

Wiele poradników wciąż poleca FAQPage i HowTo jako prosty sposób na większy wynik w Google. To nieaktualne. Google od kilku lat upraszcza stronę wyników i wycofuje kolejne wyniki rozszerzone. Zanim dopiszesz kod, sprawdź jego status w tabeli.

Co z istniejącym kodem FAQPage? Przy ograniczeniu z 2023 roku Google napisał, że nieużywane dane strukturalne nie szkodzą wyszukiwarce, ale też nie dają widocznego efektu. Nie musisz więc w pośpiechu usuwać FAQPage. Nie dopisuj go jednak w nadziei na rozwinięte pytania pod wynikiem. Same pytania i odpowiedzi na stronie zostaw, jeśli pomagają czytelnikom.

Z AI jest podobnie. Google pisze wprost, że do pojawienia się w przeglądach AI i w trybie AI nie trzeba żadnych specjalnych danych strukturalnych schema.org ani nowych plików. W przewodniku po optymalizacji pod generatywne AI wymienia „przesadne skupienie na danych strukturalnych” wśród rzeczy, które można zignorować, ale radzi dalej ich używać, bo dają kwalifikację do wyników rozszerzonych. Wśród dobrych praktyk dla funkcji AI Google wymienia za to zgodność danych strukturalnych z widocznym tekstem strony.

Tak samo traktuj plik llms.txt: wyszukiwarka Google go nie używa, ale może się przydać innym usługom. Przygotujesz go w naszym generatorze llms.txt. Jak budujemy widoczność firmy w ChatGPT i przeglądach AI, opisujemy na stronie pozycjonowanie w AI.

Kod JSON-LD wstawiasz w sekcji head albo body strony. W WordPressie, Shopify czy Wix zwykle robi to wtyczka SEO albo ustawienia motywu: wpisujesz dane w formularzu, a wtyczka generuje kod. Sprawdź jednak, czy motyw i wtyczka nie dodają dwóch różnych bloków o tej samej firmie, np. z inną nazwą albo starym telefonem.

Każdą zmianę sprawdź w trzech krokach:

1. Test wyników z elementami rozszerzonymi (Rich Results Test) – pokazuje typy, które dają wyniki rozszerzone w Google. Popraw wszystkie błędy krytyczne. Ostrzeżenia nie odbierają kwalifikacji, ale warto je poprawić.
2. Walidator schema.org (validator.schema.org) – sprawdza składnię i wszystkie typy, także te, których Test wyników rozszerzonych nie pokazuje, np. Service.
3. Sprawdzenie adresu URL w Search Console po publikacji – pokazuje, jak stronę widzi Googlebot. Strona nie może być zablokowana w robots.txt, znacznikiem noindex ani logowaniem.

Potem obserwuj raporty wyników z elementami rozszerzonymi w Search Console, zwłaszcza po pierwszym wdrożeniu i po każdej zmianie szablonu. Liczba prawidłowych elementów powinna rosnąć, a nieprawidłowych nie. Google przypomina, że dane mogą zepsuć się już po wdrożeniu, np. przez błąd w szablonie albo na serwerze.

Najczęstsze błędy w danych strukturalnych

• Błąd składni JSON: przecinek po ostatnim elemencie, brak cudzysłowu, typograficzne cudzysłowy „ ” wklejone z edytora tekstu. Jeden taki błąd unieważnia cały blok.
• Wartości zostawione ze wzoru: twojadomena.pl, 00-001, +48 22 000 00 00.
• Oznaczone treści, których nie ma na stronie: godziny, cena albo opinie widoczne tylko w kodzie.
• Własne opinie o firmie w aggregateRating na stronie tej firmy.
• Kilku autorów w jednym polu name albo nazwa firmy w author.name.
• Logo mniejsze niż 112 × 112 px albo zablokowane w robots.txt.
• Dwa bloki o tej samej firmie z różnymi danymi (motyw i wtyczka).
• Typ ogólny tam, gdzie jest dokładniejszy: Organization zamiast LocalBusiness dla gabinetu, LocalBusiness zamiast Dentist.

Część tych błędów wychwyci nasz darmowy audyt SEO: sprawdza, czy strona główna ma dane Organization albo LocalBusiness i czy bloki JSON-LD dają się odczytać. Szerszą listę kontroli znajdziesz w poradniku audytu technicznego SEO i w punkcie D5 checklisty SEO. Jeśli wolisz zlecić przegląd i wdrożenie, dane strukturalne są częścią naszego audytu SEO.