Dane strukturalne schema.org dla małej firmy: co dodać, jak sprawdzić i czego unikać

Krótka odpowiedź: dane strukturalne (schema.org, najczęściej w formacie JSON-LD) to opis Twojej strony zrozumiały dla maszyn: że to jest firma, że ma taką nazwę i dane kontaktowe, że ten tekst to artykuł napisany przez konkretną osobę. Dla małej firmy sensowny minimalny zestaw to opis organizacji, witryny i autora oraz okruszki nawigacyjne i oznaczenie artykułów. Nie gwarantują one rich results ani rekomendacji AI, a muszą zgadzać się z tym, co widać na stronie.

Ten tekst jest uzupełnieniem artykułów o widoczności w odpowiedziach AI: GEO - jak pozycjonować firmę w ChatGPT, Gemini i Perplexity oraz SEO pod sztuczną inteligencję. Tam dane strukturalne są jednym z kilku elementów. Tutaj rozkładam je na części pierwsze.

Spis treści

• Czym są dane strukturalne i po co się je dodaje
• Zasady, których trzeba przestrzegać
• Jakie typy ma sens dodać na stronie małej firmy
• Jak wygląda przykład w JSON-LD
• Powiązania między encjami: po co @id
• FAQPage - czy jeszcze warto
• Jak testować i monitorować
• Najczęstsze błędy
• Checklista

Czym są dane strukturalne i po co się je dodaje

Strona dla człowieka jest zbiorem tekstu, obrazów i układu. Dla robota to w dużej mierze ciąg znaków, z którego trzeba wywnioskować, co jest czym. Dane strukturalne zdejmują część tego zgadywania: mówisz wprost, że dany blok opisuje firmę, artykuł, usługę czy ścieżkę nawigacji.

Według dokumentacji Google dane strukturalne pomagają zrozumieć stronę i mogą umożliwić wyświetlanie bardziej rozbudowanych wyników (rich results) (Google: wprowadzenie do danych strukturalnych). Zwróć uwagę na słowo "mogą": to nie jest obietnica. Dokumentacja zaznacza, że niepoprawne lub niekompletne dane mogą uniemożliwić wyświetlenie efektu.

Słownik typów i właściwości prowadzi organizacja schema.org. To wspólny język, z którego korzystają wyszukiwarki i inne systemy.

Zasady, których trzeba przestrzegać

Google opisuje kilka zasad, które warto traktować jako żelazne:

• Dane muszą opisywać treść widoczną na stronie. Nie opisujesz niczego, czego użytkownik nie zobaczy.
• Nie twórz pustych stron wyłącznie po to, by umieścić na nich znaczniki.
• Nie dodawaj informacji ukrytych przed użytkownikiem, nawet jeśli są prawdziwe.
• Podaj wszystkie wymagane właściwości danego typu. Lepiej mniej właściwości, ale kompletnych i prawdziwych, niż wiele niepełnych lub błędnych.
• Stosuj się do wytycznych szczegółowych dla konkretnego typu danych.

W praktyce oznacza to jedno: nie dodawaj ocen gwiazdkowych, recenzji, cen ani adresów, których nie ma na stronie lub które nie są prawdziwe. To najkrótsza droga do utraty wiarygodności.

Jakie typy ma sens dodać na stronie małej firmy

Nie ma potrzeby oznaczać wszystkiego. Dla większości małych firm sensowny zestaw to:

Który typ firmy wybrać

Wybierz najbardziej odpowiedni typ, który rzeczywiście opisuje działalność. Dla agencji lub wykonawcy usług sprawdza się ProfessionalService, dla firmy z adresem przyjmującej klientów - LocalBusiness lub jego bardziej szczegółowy podtyp. Jeśli nie jesteś pewien, użyj ogólnego Organization i uzupełnij je danymi, które na pewno są prawdziwe.

Czego nie dodawać "na zapas"

• ocen i recenzji, których nie ma na stronie,
• cen i ofert, które nie są jasno przedstawione użytkownikowi,
• adresu, którego nie podajesz publicznie,
• certyfikatów i nagród, których nie możesz udokumentować.

Jak wygląda przykład w JSON-LD

Poniżej uproszczony przykład opisu firmy i jej właściciela. To schemat, a nie gotowy kod do wklejenia: wszystkie dane trzeba zastąpić własnymi i prawdziwymi.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "ProfessionalService",
      "@id": "https://example.pl/#organization",
      "name": "Nazwa firmy",
      "url": "https://example.pl",
      "description": "Krótki, prawdziwy opis działalności.",
      "telephone": "+48000000000",
      "email": "kontakt@example.pl",
      "areaServed": { "@type": "Country", "name": "Polska" },
      "founder": { "@id": "https://example.pl/#owner" }
    },
    {
      "@type": "Person",
      "@id": "https://example.pl/#owner",
      "name": "Imię i nazwisko",
      "jobTitle": "Stanowisko",
      "worksFor": { "@id": "https://example.pl/#organization" }
    }
  ]
}

Blok umieszcza się w kodzie strony jako skrypt typu application/ld+json. Google zaleca JSON-LD jako najwygodniejszy format, choć akceptuje także Microdata i RDFa.

Powiązania między encjami: po co @id

Najczęstszy błąd, jaki widzę, to dane opisujące tę samą firmę kilka razy, za każdym razem inaczej i bez połączenia. Rozwiązaniem jest nadanie encjom stałych identyfikatorów (@id) i odwoływanie się do nich z innych bloków.

Przykład: artykuł nie opisuje autora od nowa, tylko wskazuje "author": { "@id": "https://example.pl/#owner" }. Dzięki temu maszyna widzi, że autor artykułu to ta sama osoba, która jest właścicielem firmy opisanej w innym miejscu witryny. Ten sam mechanizm łączy wydawcę, witrynę i podstrony.

Warto pilnować, żeby adresy w identyfikatorach były spójne z faktycznym adresem strony. Jeśli strona działa pod adresem z www, używaj go konsekwentnie wszędzie: w danych strukturalnych, adresach kanonicznych i mapie strony.

FAQPage - czy jeszcze warto

Przez pewien czas znacznik FAQPage dawał rozwijane pytania bezpośrednio w wynikach wyszukiwania. Według aktualnej dokumentacji Google ten rodzaj wyniku został wycofany i nie jest już wyświetlany (Google: FAQPage).

Co z tego wynika:

• Sekcję FAQ nadal warto pisać, bo odpowiada na realne pytania klientów i dobrze porządkuje treść.
• Nie dodawaj FAQ wyłącznie po to, by zyskać wyróżnienie w Google. Ten efekt już nie działa.
• Znacznik jest poprawny, jeśli odzwierciedla widoczne pytania i odpowiedzi. Jeśli już go masz, nie musisz go usuwać, ale też nie powinien być powodem do dopisywania sztucznych pytań.

Jak testować i monitorować

1. Rich Results Test - podczas pracy nad stroną sprawdź, czy znaczniki są poprawne i które typy narzędzie rozpoznaje.
2. Narzędzie sprawdzania adresu URL w Google Search Console - zobaczysz, czy Google wykrył dane na konkretnej stronie.
3. Raporty statusu rich results w Search Console - po wdrożeniu pokazują błędy i ostrzeżenia w skali całej witryny.
4. Ręczna kontrola. Otwórz kod źródłowy strony i sprawdź, czy dane zgadzają się z tym, co widzi użytkownik: nazwa, telefon, adres, daty.
5. Powtórz po zmianach szablonu. Aktualizacja motywu lub wtyczki potrafi po cichu usunąć lub zdublować znaczniki.

Najczęstsze błędy

• Dane niezgodne z treścią strony, na przykład inny numer telefonu w znacznikach i w stopce.
• Dodawanie ocen i recenzji "dla ozdoby", których nie ma na stronie.
• Wtyczki generujące ten sam typ danych w kilku miejscach, co powoduje duplikaty i sprzeczności.
• Brak powiązań między firmą, autorem i artykułami.
• Błędne lub niespójne adresy URL (raz z www, raz bez, raz z końcowym ukośnikiem).
• Przestarzałe dane po zmianie oferty, danych kontaktowych lub nazwy firmy.
• Oczekiwanie cudów. Dane strukturalne porządkują informacje, ale nie zastąpią dobrej treści i wiarygodności.

Checklista

• Firma jest opisana raz, typem, który naprawdę do niej pasuje.
• Dane kontaktowe w znacznikach są identyczne z widocznymi na stronie.
• Właściciel lub autor ma własny opis i jest powiązany z firmą.
• Artykuły mają datę publikacji, autora i tytuł zgodne z treścią strony.
• Podstrony mają okruszki nawigacyjne zgodne z rzeczywistą strukturą serwisu.
• Podstrony usług mają opis usługi i obszar działania.
• Nie ma ocen, cen ani adresów, których nie widać na stronie.
• Znaczniki przeszły test w Rich Results Test i nie mają błędów w Search Console.
• Adresy URL w znacznikach są spójne z adresem kanonicznym strony.

Jeśli interesuje Cię szerszy obraz widoczności firmy w wyszukiwarkach i odpowiedziach AI, zobacz GEO - jak pozycjonować firmę w ChatGPT, Gemini i Perplexity, a podstawy SEO dla małej firmy opisuję w artykule SEO dla małej firmy: od czego zacząć. Lokalną widoczność wspiera profil w Google, którego dotyczy tekst Google Moja Firma - najważniejszy bezpłatny krok w lokalnym SEO.