Dane strukturalne kontra zwykły tekst — z którego formatu AI częściej czerpie informacje o firmie?

Jeżeli na stronie firmy widnieje telefon +48 22 123 45 67, w kodzie JSON-LD zapisano +48 22 987 65 43, a w Profilu Firmy w Google jest jeszcze trzeci numer, problemem nie jest brak kolejnego znacznika schema. Problemem są trzy konkurujące wersje tego samego faktu.

To ważne, bo systemy wyszukiwania i narzędzia wykorzystujące modele generatywne nie działają według prostej zasady: „jest schema, więc biorę schema”. Nie istnieje publiczna, uniwersalna proporcja mówiąca, że AI pobiera np. 70% informacji z JSON-LD, a 30% z tekstu. Różne systemy korzystają z różnych indeksów, crawlerów, baz wiedzy i metod ustalania wiarygodności danych.

Da się jednak wskazać praktyczną hierarchię. Treść widoczna na stronie jest podstawą, bo opisuje firmę w kontekście: czym się zajmuje, gdzie działa, komu świadczy usługi i jakie są warunki oferty. Dane strukturalne są warstwą doprecyzowującą — pozwalają oznaczyć, że konkretny ciąg cyfr jest telefonem, dany adres jest lokalizacją firmy, a dany URL prowadzi do jej oficjalnego profilu. Metadane, takie jak <title> czy meta description, pomagają opisywać stronę, ale nie powinny być traktowane jako osobna baza faktów o przedsiębiorstwie.

Najlepszy efekt daje więc nie wybór „tekst albo schema”, lecz doprowadzenie wszystkich warstw do jednej wersji prawdy o firmie.

AI potrzebuje tekstu do kontekstu, a danych strukturalnych do jednoznaczności

Zwykły tekst ma przewagę, której nie da się zastąpić samym JSON-LD. Jeśli firma napisze na stronie:

„Serwisujemy pompy ciepła na terenie Krakowa i miejscowości do około 40 km od miasta. Pogotowie serwisowe działa od poniedziałku do soboty w godzinach 7:00–20:00.”

system dostaje znacznie więcej informacji niż z samego:

"name": "ABC Serwis"
"addressLocality": "Kraków"

Z tekstu można ustalić zakres usługi, obszar działania, ograniczenia i kontekst biznesowy. To materiał potrzebny zarówno klasycznej wyszukiwarce, jak i systemowi generującemu odpowiedź na pytanie użytkownika.

Dane strukturalne rozwiązują inny problem: wskazują maszynie, czym dokładnie jest dany element informacji. W schema.org można jednoznacznie oznaczyć nazwę firmy, adres, telefon, godziny otwarcia, współrzędne, stronę WWW czy powiązane profile.

Dla Google obsługiwane są trzy podstawowe sposoby umieszczania takich danych:

• JSON-LD — rozwiązanie rekomendowane i najłatwiejsze w utrzymaniu;

• Microdata — znaczniki umieszczane bezpośrednio w elementach HTML;

• RDFa — również osadzane w HTML, dziś stosowane znacznie rzadziej w typowych stronach firmowych.

W praktycznych wdrożeniach firmowych wybieram JSON-LD, o ile nie ma konkretnego powodu, aby zrobić inaczej. Kod można trzymać w jednym logicznym bloku, łatwiej go aktualizować i znacznie trudniej przy okazji zmian layoutu przypadkowo uszkodzić oznaczenia.

Nie oznacza to jednak, że samo dodanie schema powoduje, iż AI zacznie cytować firmę. W przypadku funkcji generatywnych Google nie istnieje specjalne „AI schema”, które gwarantowałoby obecność w odpowiedziach. Dane strukturalne pomagają systemowi zrozumieć i rozróżnić encję, ale nie zastępują strony zawierającej normalną, użyteczną treść.

Podobnie wygląda sprawa metadanych.

<title> powinien precyzyjnie określać temat strony. meta description może zawierać zwięzły opis, ale nie należy wkładać tam informacji, których użytkownik później nie znajdzie w treści. Wyszukiwarki nie mają też obowiązku wyświetlać podanego meta description — mogą wygenerować fragment bezpośrednio z zawartości strony, jeśli lepiej odpowiada zapytaniu.

Praktyczna hierarchia wygląda więc tak:

1. Treść widoczna — opisuje fakty i nadaje im kontekst.

2. Schema.org — nazywa i porządkuje te fakty w formacie maszynowym.

3. Profile i zewnętrzne rekordy firmy — potwierdzają jej tożsamość poza własną domeną.

4. Metadane strony — pomagają określić temat dokumentu i sposób jego prezentacji, ale nie powinny pełnić funkcji ukrytej bazy danych.

Jeśli trzeba wybierać między stworzeniem porządnej strony „Kontakt” a wygenerowaniem 40 właściwości schema dla witryny, na której prawie nie ma treści, najpierw poprawiłbym stronę. Schema dodaje się do informacji, które rzeczywiście istnieją. Nie odwrotnie.

Konflikt między HTML, schema i profilem firmy jest gorszy niż brak części znaczników

Najbardziej problematyczne wdrożenia nie są zwykle tymi, które mają za mało schema. Najwięcej bałaganu robią strony, na których każda warstwa została przygotowana w innym momencie.

Typowy przypadek:

• stopka: „ul. Długa 18, 31-146 Kraków”;

• strona kontaktowa: „ul. Długa 18A”;

• JSON-LD: „Długa 16”;

• Profil Firmy w Google: „Długa 18”;

• Facebook: stary adres sprzed przeprowadzki.

Dla człowieka jest oczywiste, że trzeba zadzwonić i zapytać. Dla systemu próbującego ustalić fakty pojawia się konflikt encji.

W danych strukturalnych nie powinno się umieszczać „lepszej” wersji informacji tylko dlatego, że kod jest niewidoczny dla użytkownika. Jeżeli schema mówi, że lokal jest czynny w niedzielę od 10:00 do 18:00, informacja o takich godzinach powinna mieć pokrycie w treści dostępnej użytkownikowi. To samo dotyczy adresu, oferty czy innych istotnych cech firmy.

Szczególnie ryzykowne jest automatyczne generowanie schema przez kilka wtyczek jednocześnie. Na WordPressie łatwo spotkać konfigurację, w której:

• motyw dodaje Organization,

• Yoast SEO albo Rank Math generuje drugi obiekt organizacji,

• dodatkowa wtyczka lokalnego SEO tworzy LocalBusiness,

• kod napisany ręcznie dokłada czwarty zestaw danych.

Sam fakt istnienia kilku obiektów nie zawsze jest błędem. Problem zaczyna się wtedy, gdy dotyczą tej samej firmy i podają różne dane.

Nie naprawiałbym tego przez dokładanie kolejnego skryptu JSON-LD. Najpierw trzeba ustalić jedno źródło danych.

Dobra procedura kontroli wygląda następująco:

• wpisz pełną nazwę firmy oraz markę, jeśli są różne;

• ustal jeden podstawowy numer telefonu;

• sprawdź adres znak po znaku, łącznie z numerem lokalu i kodem pocztowym;

• porównaj godziny otwarcia;

• sprawdź adres e-mail;

• porównaj adres URL strony głównej i podstrony lokalizacji;

• zweryfikuj logo;

• sprawdź NIP i inne identyfikatory, jeśli są publikowane;

• dopiero wtedy porównaj HTML, JSON-LD oraz najważniejsze profile zewnętrzne.

Numer telefonu najlepiej zapisywać w danych strukturalnych razem z prefiksem kraju, np. +48 22 123 45 67, zamiast samego 22 123 45 67. Dla adresu polskiej firmy addressCountry można zapisać jako PL.

Drugi częsty problem to mylenie nazwy handlowej z nazwą prawną.

Przykładowo klient może znać lokal jako „Studio Forma”, podczas gdy pełna nazwa przedsiębiorcy brzmi „Jan Kowalski Studio Forma”. Nie trzeba wszędzie zastępować przyjaznej nazwy pełną nazwą rejestrową. Schema pozwala rozdzielić te informacje:

• name — nazwa używana przez firmę;

• legalName — pełna nazwa prawna, jeżeli jest inna;

• taxID lub vatID — właściwy identyfikator podatkowy, jeżeli ma zastosowanie.

Równie istotny jest sameAs. To pole może prowadzić do oficjalnych profili firmy w innych serwisach. Nie powinno być jednak śmietnikiem z przypadkowymi linkami. Dodaję tam wyłącznie strony rzeczywiście identyfikujące tę samą organizację.

Sama poprawność składni również nie wystarcza. Walidator może potwierdzić, że JSON-LD jest prawidłowo napisany, ale nie ustali za przedsiębiorcę, czy podał aktualny numer telefonu. Walidacja techniczna nie jest walidacją faktów.

I to jest niedogodność, która przy większych serwisach szybko zaczyna irytować: dane firmy często żyją w CMS-ie, stopce, wtyczce SEO, systemie sklepów, Profilu Firmy w Google i katalogach jednocześnie. Zmiana telefonu wykonana tylko w jednym miejscu tworzy niespójność praktycznie od ręki.

Checklista Organization i LocalBusiness: jakie dane faktycznie uporządkować

Dla firmy bez punktu obsługi klienta zacząłbym od Organization lub jego dokładniejszego podtypu. Dla restauracji, gabinetu, salonu, sklepu stacjonarnego, warsztatu czy innego przedsiębiorstwa posiadającego konkretną lokalizację właściwszy będzie zazwyczaj LocalBusiness albo bardziej szczegółowy podtyp, np. Restaurant, Dentist, Store czy Electrician, jeżeli odpowiada rzeczywistemu charakterowi działalności.

Nie należy automatycznie oznaczać każdej działalności jako LocalBusiness tylko dlatego, że przedsiębiorca ma adres rejestrowy. Wirtualne biuro w Warszawie nie zmienia ogólnopolskiego sklepu internetowego w warszawski sklep stacjonarny.

Dla Organization kontroluję w pierwszej kolejności:

• name — podstawowa nazwa organizacji;

• alternateName — inna powszechnie używana nazwa, jeśli występuje;

• legalName — pełna nazwa prawna, jeśli różni się od marki;

• url — oficjalna strona organizacji;

• logo — właściwy, indeksowalny plik logo;

• description — rzeczywisty opis organizacji, bez przesadzonych deklaracji marketingowych;

• telephone — główny numer kontaktowy z kodem kraju;

• email — główny adres e-mail;

• address — jeśli firma faktycznie publikuje swój adres;

• sameAs — oficjalne profile lub strony identyfikujące tę samą organizację;

• taxID / vatID — jeśli są zasadne i publikowane;

• foundingDate — tylko jeśli data jest ustalona i prawdziwa;

• contactPoint — gdy istnieją osobne kanały kontaktu, np. dział obsługi klienta.

Google nie określa obecnie obowiązkowego zestawu właściwości dla Organization. Sensowniejsza jest kompletność niż sztuczne „odhaczenie” każdego możliwego pola.

Przy logo jest już konkretny parametr techniczny: dla danych organizacji Google wskazuje minimum 112 × 112 px. Plik musi być dostępny dla robota i możliwy do indeksowania. Umieszczenie świetnego logo w JSON-LD nic nie da, jeśli jego URL odpowiada błędem 403 albo jest blokowany.

Dla LocalBusiness wymagania są bardziej konkretne. Jeżeli celem jest kwalifikacja danych do obsługiwanej przez Google prezentacji Local Business, podstawą są:

• name;

• address jako PostalAddress.

Adres warto rozpisać, zamiast wkładać wszystko do jednego tekstowego pola:

• streetAddress — np. Marszałkowska 58/12;

• postalCode — np. 00-545;

• addressLocality — Warszawa;

• addressCountry — PL.

Dalej uzupełniam przede wszystkim:

• telephone;

• url prowadzący do konkretnej placówki;

• openingHoursSpecification;

• geo z szerokością i długością geograficzną;

• priceRange, jeśli rzeczywiście ma zastosowanie;

• właściwości branżowe, np. servesCuisine i menu dla restauracji.

Google wymaga dla współrzędnych geo.latitude i geo.longitude precyzji co najmniej pięciu miejsc po przecinku. To drobiazg techniczny, ale pokazuje, dlaczego ręczne wpisywanie przybliżonego punktu „gdzieś na środku ulicy” nie jest dobrym rozwiązaniem.

Godziny otwarcia zapisuję przez OpeningHoursSpecification. Jeżeli placówka ma inne godziny w sobotę, trzeba je opisać osobno. Jeśli przez część roku działa sezonowo, można użyć pól dat obowiązywania zamiast zostawiać przez dziewięć miesięcy błędną informację.

Przy kilku lokalizacjach obowiązuje jeszcze jedna ważna zasada: każdy punkt powinien być opisany jako osobna lokalizacja. Sieć mająca salony przy ul. Marszałkowskiej w Warszawie i przy ul. Floriańskiej w Krakowie nie powinna tworzyć jednego LocalBusiness z dwoma przemieszanymi adresami i wspólnymi godzinami.

Na stronie każdej placówki umieściłbym więc jej:

• nazwę;

• pełny adres;

• telefon;

• godziny;

• mapę lub wskazówki dojazdu;

• opis usług dostępnych właśnie w tym punkcie;

• odpowiadający tym informacjom JSON-LD.

Potem trzeba sprawdzić źródła zewnętrzne. Dla lokalnego biznesu szczególnie istotna jest konsekwencja NAP — Name, Address, Phone. Jeżeli firma buduje kolejne potwierdzenia swojej obecności w sieci, użyteczna może być także darmowa wizytówka NAP dla firmy, pod warunkiem że wpis zawiera dokładnie tę samą nazwę, lokalizację i numer telefonu co oficjalna strona. Tworzenie kolejnego rekordu ze skróconą nazwą, starym numerem albo inną pisownią adresu nie poprawia porządku — powiększa bałagan.

Na tym etapie wykonuję jeszcze trzy testy.

Test 1: człowiek
Otwórz stronę bez zaglądania do kodu. Czy użytkownik znajdzie nazwę, adres, telefon, godziny i opis działalności?

Test 2: maszyna
Sprawdź wygenerowany kod w Rich Results Test oraz Schema Markup Validator. Następnie zobacz w narzędziu inspekcji adresu URL, jak strona jest pobierana i renderowana.

Test 3: konflikt
Skopiuj do arkusza sześć pól: nazwa, adres, telefon, URL, godziny, e-mail. Porównaj stronę główną, kontakt, JSON-LD i najważniejsze profile zewnętrzne. Każda różnica musi mieć uzasadnienie albo zostać usunięta.

To ostatnie jest ważniejsze niż dodanie kolejnych 20 właściwości schema. Sześć poprawnych, zgodnych faktów ma większą wartość operacyjną niż rozbudowany graf danych zawierający stary adres.

FAQ

Czy AI częściej korzysta ze schema.org czy ze zwykłego tekstu?
Nie ma jednej publicznej proporcji obowiązującej wszystkie systemy AI. Widoczny tekst dostarcza szerszego kontekstu i jest podstawowym źródłem treści strony, natomiast schema.org jednoznacznie opisuje konkretne fakty. Najbezpieczniej traktować dane strukturalne jako maszynowe potwierdzenie informacji widocznych dla użytkownika.

Czy dodanie JSON-LD zwiększa szansę pojawienia się firmy w odpowiedzi AI?
Może ułatwić rozpoznanie firmy i jej właściwości, ale nie gwarantuje wykorzystania strony ani wyświetlenia wyniku rozszerzonego. Nie istnieje specjalny znacznik schema gwarantujący obecność w generatywnych odpowiedziach Google.

Co jest lepsze dla firmy: Organization czy LocalBusiness?
Organization pasuje do opisu organizacji jako podmiotu. LocalBusiness i jego dokładniejsze podtypy stosuje się do działalności związanej z konkretną fizyczną lokalizacją. Dla lokalnej firmy Google zaleca uwzględnić również właściwości właściwe dla Organization.

Czy dane w JSON-LD mogą różnić się od informacji widocznych na stronie?
Nie powinny. Dane strukturalne muszą rzeczywiście opisywać treść strony. Nie należy używać JSON-LD do przekazywania robotowi innej wersji adresu, godzin, oferty czy innych faktów niż wersja prezentowana użytkownikowi.

Czy meta description jest ważniejsze od treści strony?
Nie. Meta description jest pomocniczym opisem dokumentu. Google może go wykorzystać, ale może też wygenerować fragment wyniku bezpośrednio z treści strony, jeśli uzna go za lepiej dopasowany do zapytania.

Czy trzeba wypełnić wszystkie dostępne właściwości Organization?
Nie. Google nie wskazuje obecnie obowiązkowych właściwości dla Organization. Lepiej podać 10 poprawnych pól niż 30 uzupełnionych na siłę. Priorytetem są nazwa, adres lub inny ślad rzeczywistej obecności, telefon, URL, logo i właściwe powiązania.

Co zrobić, gdy firma ma kilka oddziałów?
Każdą rzeczywistą lokalizację opisuj osobno. Oddział powinien mieć własny adres, telefon, godziny, URL lokalizacji i odpowiadający im obiekt LocalBusiness. Nie łącz dwóch różnych punktów w jeden rekord.

Od czego zacząć poprawianie danych firmy pod AI i wyszukiwarki?
Nie od schema. Najpierw wypisz nazwę, adres, telefon, URL, godziny i e-mail i sprawdź, czy jedna wersja tych danych występuje na stronie głównej, stronie kontaktowej i stronach lokalizacji. Pierwszym błędem do usunięcia jest każda sprzeczność w NAP. Dopiero gdy treść widoczna jest poprawna, dostosuj do niej JSON-LD, a na końcu zaktualizuj profile i katalogi zewnętrzne.