Dane strukturalne dla firmy: trzy typy schema krok po kroku

Model AI, który odpowiada na pytanie klienta, w ułamku sekundy decyduje, kogo wymienić. Zanim to zrobi, musi zrozumieć, kim jesteś. Może to wywnioskować z treści strony albo dostać podane wprost. Dane strukturalne to ta druga droga.

Format tego zapisu, czyli spór mikrodane kontra JSON-LD, opisuję w osobnym artykule. Tu zostawiam format z boku i biorę się za rzecz ważniejszą w praktyce: które typy schema.org wypełnić najpierw i co dokładnie wpisać w ich pola.

Dlaczego firma potrzebuje danych strukturalnych w erze AI?

Bo maszyna, która Cię nie rozumie, nie może Cię polecić.

Silnik AI czyta stronę inaczej niż człowiek. Człowiek widzi logo w rogu i od razu wie, że to firma. Model widzi ciąg tekstu i musi wywnioskować, co jest nazwą, co adresem, a co ceną. Im więcej zgaduje, tym łatwiej o pomyłkę.

Dane strukturalne zdejmują z niego to zgadywanie. Podają nazwę, opis, adres i usługę w formie, którą maszyna czyta bez wysiłku. Ma to znaczenie zwłaszcza w modelu RAG, gdzie silnik dokleja do odpowiedzi fragmenty wyszukane na żywo i musi szybko ocenić, czym jest dana strona. Jak działa RAG i skąd AI bierze źródła, rozkładam na czynniki w osobnym artykule.

Uczciwa granica: dane strukturalne nie sprawią, że AI zacznie Cię polecać. Zwiększają szansę, że dobrze zrozumie, kim jesteś, i przypisze Cię do właściwej kategorii. Reszta zależy od treści i od tego, jak wypadasz na tle konkurencji.

Organization: podstawowa tożsamość firmy

Typ Organization to wizytówka firmy dla maszyny: kto to jest i gdzie go znaleźć. Od niego zacznij, bo dotyczy każdej firmy, niezależnie od branży. Wypełnij w nim kilka pól, po kolei:

• Nazwa (name). Dokładnie tak, jak nazywa się firma, w jednej spójnej formie na całej stronie.
• Logo. Link do pliku z logotypem, żeby model i wyszukiwarka wiedziały, jak wygląda znak marki.
• Opis (description). Jedno-dwa zdania o tym, czym firma się zajmuje, językiem klienta, nie sloganem.
• sameAs. Linki do Twoich profili poza stroną: LinkedIn, Facebook, wpis w Wikipedii, jeśli istnieje. To one łączą stronę z resztą śladów firmy w sieci.
• Kontakt (contactPoint). Telefon, adres e-mail oraz język obsługi.
• Adres i strona (url). Adres siedziby oraz adres strony głównej.

LocalBusiness: firma z adresem, godzinami i obszarem

Jeśli firma ma fizyczny adres, do którego przychodzą klienci, zamiast Organization użyj typu LocalBusiness. Zawiera on wszystko, co Organization, i dokłada pola przypięte do miejsca:

• Adres (address). Ulica, numer, kod pocztowy i miasto, rozbite na osobne pola, nie w jednej linijce tekstu.
• Godziny otwarcia (openingHours). Dni i godziny pracy. To jedna z rzeczy, o które klient pyta AI najczęściej.
• Obszar działania (areaServed). Miasto, region albo lista miejscowości, które obsługujesz.
• Współrzędne (geo). Szerokość i długość geograficzna punktu na mapie.
• Telefon i widełki cenowe (priceRange). Numer kontaktowy oraz orientacyjny poziom cen.

Service i Product: co dokładnie oferujesz

Organization i LocalBusiness mówią, kim jesteś. Service i Product mówią, co konkretnie sprzedajesz. Typ Service opisuje usługę:

• Nazwa usługi (name). Językiem klienta, nie wewnętrzną nazwą z oferty.
• Opis (description). Co usługa obejmuje i dla kogo jest.
• Kto ją świadczy (provider). Odnośnik do Twojego typu Organization, żeby usługa była przypięta do firmy.
• Obszar (areaServed). Gdzie usługę wykonujesz.
• Cena lub widełki (offers). Tylko jeśli cena jest jawna na stronie.

Jak dodać dane strukturalne bez programisty?

Nie musisz pisać kodu. Są trzy drogi, od najprostszej:

• Wtyczka do systemu, na którym stoi strona. WordPress, Shopify i większość popularnych systemów mają wtyczki, które generują dane strukturalne z formularza. Wypełniasz pola, wtyczka wstawia kod.
• Generator JSON-LD. Darmowe generatory w sieci proszą o dane w formularzu i zwracają gotowy fragment do wklejenia w kod strony. Dobre na start, gdy nie masz odpowiedniej wtyczki.
• Walidator na koniec. Zanim uznasz, że gotowe, sprawdź zapis w narzędziu Schema Markup Validator na validator.schema.org oraz w teście Google Rich Results Test. Pierwsze mówi, czy kod jest zgodny ze standardem schema.org, drugie, czy Google rozpoznaje go pod bogatsze wyniki.

Najczęstszy błąd: schema niezgodna z treścią na stronie

Najczęstszy błąd to opisać w danych strukturalnych coś, czego na stronie nie ma.

Model porównuje zapis z treścią widoczną dla człowieka. Gdy w schema wpiszesz godziny, adres albo cenę inne niż te na stronie, łapie rozjazd i traci zaufanie do całości. Zamiast pomóc, dane strukturalne stają się sygnałem, że coś tu nie gra.

Druga wersja tego błędu to oznaczanie rzeczy nieobecnych: sekcji FAQ, której na stronie nie widać, opinii, których nie ma, usługi, o której nie piszesz. To łamie wytyczne Google i potrafi ściągnąć karę. Osobnym, prostym typem jest zresztą FAQPage, czyli dane strukturalne dla sekcji pytań i odpowiedzi. Kiedy i jak jej używać, opisuję w osobnym artykule o sekcjach FAQ; tu wystarczy zasada, że oznaczasz nią wyłącznie pytania widoczne na stronie.

Reguła jest prosta: dane strukturalne opisują to, co i tak jest na stronie. Nie dodają nowych informacji, tylko układają istniejące w formę czytelną dla maszyny. Najpierw treść dla człowieka, potem jej opis dla modelu. Jak zbudować samą stronę usługi wokół tych danych, pokazuję w osobnym artykule o szablonie strony usługi.

Jak sprawdzić, czy dane strukturalne pomagają?

Sprawdzenie ma dwa poziomy: czy kod jest poprawny i czy realnie zmienia widoczność w AI.

Pierwszy poziom to walidacja. Wróć do Schema Markup Validator i testu Rich Results Test po każdej większej zmianie. W Google Search Console, w sekcji z ulepszeniami, zobaczysz z kolei, czy Google widzi Twoje dane strukturalne na wszystkich stronach i czy nie zgłasza błędów.

Drugi poziom to pomiar widoczności w AI, bo poprawny kod to jeszcze nie cytowanie. Zadaj silnikom pytania, które zadałby Twój klient, i sprawdź, czy pada Twoja nazwa oraz czy Twoja domena jest wśród źródeł. Powtórz to w ChatGPT, Gemini, Perplexity, AI Overviews i AI Mode, bo każdy czyta sieć inaczej.

Pamiętaj o granicy. Pojedynczy pomiar to obraz jednej chwili, bo odpowiedzi AI zmieniają się z dnia na dzień, a wniosek daje dopiero kilka powtórzeń przy większej liczbie promptów. Tę pracę na pięciu silnikach przejmuje monitoring widoczności marki w AI.

Zanim jednak zaczniesz dokładać dane strukturalne, sprawdź rzecz wcześniejszą: czy roboty AI w ogóle dobrze czytają Twoją stronę. Od tej strony technicznej zaczniesz w darmowym audycie AI.

Z własnego doświadczenia

Zrobiłem tak z własnym produktem. Dołożyłem dane strukturalne, sprawdziłem je w walidatorze, aż przeszły bez błędu, i dopiero potem zajrzałem do pomiaru, czy coś drgnęło w odpowiedziach AI. Poprawny kod dostałem od ręki, ale widoczność ruszyła nierówno, silnik po silniku inaczej. To był dla mnie jasny dowód, że schema porządkuje zrozumienie, a nie gwarantuje cytowania.

Piotr Czerwiński · Założyciel CiteLyzer

Sedno

Dane strukturalne to najkrótsza droga, żeby maszyna zrozumiała Twoją firmę bez zgadywania. Zacznij od typu Organization, dołóż LocalBusiness, jeśli masz fizyczny adres, i Service albo Product dla tego, co sprzedajesz. Wypełnij pola danymi, które i tak są na stronie.

Dodasz je wtyczką albo generatorem, sprawdzisz w walidatorze i teście Google, a potem zmierzysz, czy zmieniają widoczność w AI. To nie przełącznik, który włącza polecenia. To porządek, dzięki któremu model dobrze rozumie, kim jesteś, a reszta zależy od treści i konkurencji.