Dane strukturalne: których naprawdę potrzebuje strona firmowa
Dane strukturalne nie są czynnikiem rankingowym. Są tłumaczeniem: mówią maszynom, co znaczy fragment tekstu, zamiast kazać im zgadywać. Właśnie to decyduje coraz częściej o tym, czy strona w ogóle pojawi się w odpowiedziach.
Najważniejsze w skrócie
- Cztery typy wystarczą niemal każdej stronie firmowej: Organization, WebPage względnie Article, BreadcrumbList i FAQPage.
- Dostarcza się je jako JSON-LD w
<head>– nie jako oznaczenia w tekście ciągłym. - Najczęstszy błąd jest cichy i kosztowny: informacje w danych strukturalnych, których na samej stronie nie ma.
- Trzy szeroko omawiane typy firma usługowa może sobie darować – działają tylko przy odpowiedniej ofercie albo prawdziwych ocenach.
Maszyna czytająca stronę widzi najpierw tylko tekst. Że „Emma Woelk” to człowiek, „TEISENDA GmbH” to firma, a „22 sierpnia 2026” to data publikacji, musi zgadnąć – albo stoi to tam wyraźnie.
Dane strukturalne są tym wyraźnym staniem. Nie poprawiają pozycji. Decydują o tym, czy strona w ogóle wchodzi w grę przy rozszerzonych sposobach prezentacji i przy generowanych odpowiedziach.
Cztery, które wystarczą
1. Organization – raz, na stronie głównej
Kim jesteście: nazwa, adres, logo, rok założenia, profile w innych sieciach. To wpis, który sprawia, że logo może pojawić się obok wyniku wyszukiwania – najczęstszym powodem jego braku jest po prostu brak tego wpisu.
Ważne: logo musi być w postaci obrazu rastrowego. SVG nie jest w tym miejscu przetwarzane.
2. WebPage albo Article – na każdej stronie
Czym jest ta strona: tytuł, opis, język, data publikacji i ostatniej aktualizacji. Przy artykułach dodatkowo Article względnie BlogPosting z autorem jako osobnym wpisem Person – z rolą, nie tylko z nazwiskiem.
Ważne: data aktualizacji musi się zgadzać. Data ustawiana na nowo przy każdym wygenerowaniu strony to sygnał, który sam siebie unieważnia.
3. BreadcrumbList – na wszystkich podstronach
Gdzie ta strona stoi w strukturze. Widoczna jako ścieżka u góry strony, czytelna maszynowo w nagłówku. Jedno i drugie należy do siebie – ścieżka w danych, której na stronie nie ma, jest błędną informacją.
4. FAQPage – tam, gdzie są prawdziwe pytania
Sekcja pytań na końcu artykułu. Dla silników odpowiedzi w ogóle najcenniejszy typ, bo dostarcza pytanie i odpowiedź już jako parę – dokładnie w formie, w jakiej się cytuje.
Ważne: tylko do faktycznie widocznych pytań na stronie. Wymyślone pytania stojące jedynie w danych to naruszenie wytycznych.
Trzy, które można sobie darować
Product i Offer. Dla usług z ofertą na zapytanie nie dają nic – bez ceny i dostępności i tak nie zostaną wyświetlone. Sensowne dopiero przy prawdziwym sklepie.
AggregateRating. Gwiazdki w wyniku wyszukiwania są kuszące i obwarowane surowymi warunkami: oceny muszą być prawdziwe, sprawdzalne i widoczne na stronie. Oceny wystawione samemu sobie to naruszenie wytycznych z realnym ryzykiem.
HowTo. Zostało w prezentacji wyraźnie ograniczone i dla większości stron firmowych nie jest już warte nakładu na utrzymanie.
Czy wiesz, że…?
Dane strukturalne nie są czynnikiem rankingowym – Google wyjaśniał to wielokrotnie. Decydują o prezentacji, nie o pozycji.
Dla silników odpowiedzi rzecz wygląda nieco inaczej. Model, który ma zbudować ze strony odpowiedź, używa najchętniej tego, co jest jednoznacznie oznaczone: par pytanie-odpowiedź, autora z rolą, daty ostatniego sprawdzenia. Nie musi wtedy zgadywać, co do siebie należy. Pożytek leży więc mniej w rankingu, a bardziej w cytowalności.
Jak się je wbudowuje
Trzy zasady, które pozwalają uniknąć większości problemów.
- JSON-LD, w
<head>. Nie jako atrybuty w tekście ciągłym. JSON-LD da się utrzymywać niezależnie od układu graficznego i nie ginie przy zmianach wyglądu. - Jeden blok na stronę, nie pięć. Kilka wpisów należy do jednego
@graphi łączy się je przez@id. Dzięki temu artykuł odsyła do tej samej organizacji, która stoi na stronie głównej, zamiast ją powtarzać. - Generować z tego samego źródła co widoczna treść. Jeśli tytuł, data i autor pochodzą z tych samych pól co sama strona, w ogóle nie mogą się rozjechać. To najskuteczniejsza profilaktyka ze wszystkich.
Najdroższy błąd jest najcichszy: dane strukturalne mówią coś, czego na stronie nie ma. Data aktualizacji z wczoraj przy tekście z 2023 roku. Autor, który nie pojawia się w widocznym obszarze. Pytania w danych, których na stronie nie ma.
Żadne narzędzie kontrolne tego nie wychwyci – dane są formalnie poprawne. Wychwytuje to kontrola ręczna, a wtedy konsekwencja dotyczy nie tylko danego oznaczenia. Dlatego zasada „generować z tego samego źródła” jest ważniejsza niż jakakolwiek kompletność.
Sprawdzanie – w tej kolejności
| Krok | Czym | Co zobaczycie |
|---|---|---|
| 1. Składnia | walidator oznaczeń Schema | czy JSON jest poprawny i czy typ się zgadza |
| 2. Możliwość prezentacji | test wyników z elementami rozszerzonymi | czy rozszerzona prezentacja byłaby możliwa |
| 3. Rzeczywistość | Search Console, sekcja ulepszeń | co faktycznie zostało rozpoznane, na wszystkich stronach |
| 4. Zgodność | przeczytać samemu | czy każda informacja stoi też widocznie na stronie |
Krok czwarty jest jedynym, którego nie przejmuje żadne narzędzie – i jedynym, przy którym wychodzą poważne błędy.
Sprawdź dane strukturalne tej strony pod kątem kompletności i zgodności z widoczną treścią. Widoczna treść strony: [wklej tekst strony] JSON-LD strony: [wklej blok] Zadania: 1. Wskaż każdą informację w JSON-LD, której nie ma w widocznej treści. To najważniejszy punkt – bądź tu dokładny. 2. Wskaż każdą widoczną informację, która powinna zostać oznaczona, a której brakuje (autor z rolą, data aktualizacji, pytania, ścieżka). 3. Sprawdź, czy cztery typy podstawowe są sensownie obsadzone: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Wskaż typy w bloku, które dla firmy usługowej bez sklepu i bez sprawdzalnych ocen nie dają żadnego pożytku. 5. Zwróć uwagę na każde naruszenie wytycznych, w szczególności oceny wystawione samemu sobie i pytania, których na stronie nie ma. Na końcu wypisz poprawiony JSON-LD w całości. Nie wymyślaj wartości – brakujące oznacz jako [do uzupełnienia].
Podsumowanie
Dane strukturalne bywają szybko przeceniane i równie szybko robione źle. Cztery typy pokrywają potrzeby strony firmowej, a ich pożytek leży mniej w pozycji, a bardziej w tym, by dać się cytować.
Jedna zasada, która niesie wszystko: nie oznaczać niczego, czego na stronie nie ma. Kto generuje dane z tego samego źródła co widoczną treść, rozwiązał ten problem strukturalnie – i może sobie w dużej mierze darować kontrole następcze.
Częste pytania
Jakich danych strukturalnych potrzebuje strona firmowa?
Wystarczą cztery typy: Organization raz na stronie głównej, WebPage względnie Article na każdej stronie, BreadcrumbList na wszystkich podstronach i FAQPage wszędzie tam, gdzie są prawdziwe, widoczne pytania. Product, AggregateRating i HowTo dla firm usługowych z reguły się nie opłacają.
Czy dane strukturalne poprawiają ranking?
Nie. Nie są czynnikiem rankingowym, lecz decydują o prezentacji – na przykład o tym, czy w wyniku wyszukiwania może pojawić się logo, ścieżka albo rozwijane pytania. Dla silników odpowiedzi zwiększają cytowalność, bo pary pytanie-odpowiedź, autor i data są jednoznacznie oznaczone, zamiast musieć być zgadywane.
Dlaczego Google nie pokazuje naszego logo?
Najczęstszym powodem jest brakujący albo niepełny wpis Organization na stronie głównej. Drugi co do częstości powód: zapisane logo istnieje tylko jako SVG – w tym miejscu potrzebny jest obraz rastrowy. Także przy poprawnym oznaczeniu nie ma roszczenia o wyświetlenie.
Jaki jest najczęstszy błąd przy danych strukturalnych?
Informacje stojące w danych, ale nie w widocznej treści: błędna data aktualizacji, niewymieniony autor, wymyślone pytania. Narzędzia kontrolne tego nie zgłaszają, bo dane są formalnie poprawne. Da się tego uniknąć, generując oznaczenia z tego samego źródła co widoczny tekst.
JSON-LD czy Microdata?
JSON-LD w <head>. To forma zalecana przez Google, daje się utrzymywać niezależnie od układu graficznego i nie ginie przy zmianach wyglądu. Microdata rozprasza oznaczenia po tekście ciągłym i psuje się przy każdej przebudowie strony.
Marketing, który konfiguruje się sam
Beta Studio Engine jest otwarta. Zarezerwuj miejsce i współtwórz od początku.
Dołącz do bety →