Co wybrać dla wizytówki firmy: dane strukturalne LocalBusiness czy Organization

Wybór między LocalBusiness a Organization nie powinien zależeć od tego, który typ zawiera więcej pól ani który częściej pojawia się we wtyczkach SEO. Decydujące pytanie brzmi: czy strona opisuje firmę jako podmiot, czy konkretną placówkę dostępną pod określonym adresem?

Jeżeli przedsiębiorstwo ma biuro, sklep, gabinet, restaurację, warsztat albo punkt obsługi klientów, najczęściej właściwym typem będzie LocalBusiness lub jeden z jego bardziej szczegółowych podtypów. Gdy witryna przedstawia markę, spółkę, fundację, producenta, platformę internetową albo firmę działającą bez punktu obsługi klientów, lepszym wyborem pozostaje Organization.

Nie jest to jednak wybór „albo–albo” dla całej domeny. W serwisie wielooddziałowym można opisać centralę jako Organization, a poszczególne placówki jako LocalBusiness. Najwięcej problemów powstaje wtedy, gdy jeden ogólny znacznik jest automatycznie wstawiany na każdej podstronie, niezależnie od jej treści.

LocalBusiness opisuje konkretną placówkę, a nie sam fakt prowadzenia firmy

LocalBusiness jest jednocześnie typem organizacji i miejsca. Służy do opisania konkretnego fizycznego przedsiębiorstwa albo oddziału, z którym można powiązać lokalizację, godziny otwarcia i sposób obsługi klientów.

Ten typ pasuje między innymi do:

• restauracji i kawiarni,
• sklepów stacjonarnych,
• salonów fryzjerskich i kosmetycznych,
• warsztatów samochodowych,
• kancelarii przyjmujących klientów w biurze,
• gabinetów lekarskich i stomatologicznych,
• hoteli,
• placówek bankowych,
• lokalnych punktów usługowych.

Samo posiadanie adresu rejestrowego nie wystarcza. Spółka zarejestrowana w mieszkaniu prezesa, która świadczy usługi wyłącznie zdalnie, nie staje się przez to lokalnym punktem usługowym. Podobnie sklep internetowy nie powinien być oznaczany jako Store, jeżeli wskazany magazyn nie obsługuje klientów.

Przed wdrożeniem LocalBusiness trzeba sprawdzić cztery rzeczy:

1. Czy klient rzeczywiście może skorzystać z usług w tej lokalizacji?
2. Czy adres jest publicznie podany na stronie?
3. Czy godziny otwarcia dotyczą tej konkretnej placówki?
4. Czy dane są zgodne z Profilem Firmy w Google, mapami i katalogami branżowymi?

Jeżeli odpowiedź na pierwsze pytanie brzmi „nie”, wybór LocalBusiness jest zwykle naciągany. Dane strukturalne powinny opisywać rzeczywistą treść strony, a nie tworzyć wygodniejszą wersję działalności na potrzeby SEO.

Dla pojedynczej placówki podstawowy zestaw danych zwykle obejmuje:

• @type,
• stabilne @id,
• name,
• url,
• image,
• logo,
• telephone,
• address,
• geo,
• openingHoursSpecification,
• priceRange, jeżeli taki opis ma sens,
• sameAs z oficjalnymi profilami firmy.

Najczęstszy błąd polega na użyciu zbyt ogólnego typu. Restauracja może zostać oznaczona jako Restaurant, hotel jako Hotel, gabinet dentystyczny jako Dentist, a sklep rowerowy jako BikeStore. Najbardziej szczegółowy prawidłowy typ jest zazwyczaj lepszy od samego LocalBusiness, ponieważ precyzyjniej opisuje działalność.

Nie należy jednak dobierać podtypu pod najważniejszą frazę pozycjonowaną. Kancelaria nie staje się LegalService tylko dlatego, że serwis chce zajmować wysokie pozycje na zapytania prawnicze. Typ musi odpowiadać temu, czym placówka faktycznie jest i co przedstawia dana strona.

Przy wielu oddziałach każda placówka powinna mieć osobną stronę oraz własny obiekt danych strukturalnych. Oddział w Warszawie i oddział w Poznaniu nie mogą dzielić jednego adresu, jednego @id ani wspólnych godzin otwarcia, jeżeli działają według różnych harmonogramów. W praktyce rozsądny układ wygląda tak:

• strona główna: podmiot nadrzędny opisany jako Organization,
• strona /warszawa/: warszawski LocalBusiness,
• strona /poznan/: poznański LocalBusiness,
• powiązanie oddziałów z centralą przez parentOrganization.

Umieszczanie listy wszystkich adresów w jednym obiekcie LocalBusiness zaciera znaczenie danych. Jedna placówka powinna odpowiadać jednemu identyfikowalnemu miejscu.

Organization sprawdza się przy marce, centrali i działalności bez punktu obsługi

Organization opisuje firmę lub inną organizację jako podmiot. Nie zakłada, że przedsiębiorstwo prowadzi lokal dostępny dla klientów. Dlatego jest właściwym wyborem dla spółek technologicznych, producentów, organizacji branżowych, fundacji, portali internetowych, platform SaaS i większości biznesów działających zdalnie.

Na stronie głównej Organization pomaga uporządkować informacje takie jak:

• oficjalna nazwa firmy,
• nazwa skrócona lub handlowa,
• adres strony,
• logo,
• dane kontaktowe,
• numery identyfikacyjne,
• profile społecznościowe,
• podmiot nadrzędny i jednostki zależne,
• polityka zwrotów w przypadku działalności handlowej.

Google zaleca umieszczanie danych organizacji na stronie głównej albo jednej stronie opisującej organizację, na przykład w zakładce „O nas”. Powielanie kompletnego obiektu Organization w stopce każdej podstrony nie daje dodatkowej wartości. Co gorsza, źle skonfigurowane wtyczki potrafią tworzyć kilka wersji tej samej firmy z różnymi nazwami, adresami URL i identyfikatorami.

Kluczową rolę pełni @id. Powinien być stabilnym identyfikatorem obiektu, na przykład:

https://example.pl/#organization

Ten sam identyfikator należy później wykorzystywać w innych danych strukturalnych. Artykuł może wskazywać organizację jako wydawcę, strona kontaktowa jako opisywany podmiot, a lokalny oddział jako jednostkę należącą do firmy. Bez wspólnego @id wyszukiwarka może potraktować te elementy jak osobne organizacje.

Trzeba także rozdzielić nazwę prawną od nazwy, którą posługują się klienci. Jeżeli spółka działa formalnie jako „Przykład Technologie Spółka z ograniczoną odpowiedzialnością”, ale marką widoczną na stronie jest „Przykład”, właściwość name powinna odpowiadać głównej nazwie prezentowanej użytkownikom. Pełną nazwę rejestrową można uzupełnić w odpowiednim polu identyfikującym podmiot.

Nie należy wstawiać do name fraz sprzedażowych, miasta ani katalogu usług. Nazwa:

Przykład – najlepsze strony internetowe Warszawa

jest błędna, jeżeli firma oficjalnie nazywa się „Przykład”. Dane strukturalne nie są miejscem na rozbudowę słów kluczowych.

Drugim częstym problemem jest logo. Plik powinien być dostępny dla robota Google, mieć poprawny adres URL i pozostawać spójny z identyfikacją wizualną widoczną na stronie. Nie należy podawać obrazu osadzonego wyłącznie przez skrypt wymagający zgody użytkownika ani adresu tymczasowego generowanego przez system CDN. Po migracji domeny stare adresy grafik często przestają działać, mimo że sam kod JSON-LD nadal przechodzi podstawową walidację składni.

Organization nie daje gwarancji wyświetlenia logo, danych kontaktowych ani panelu wiedzy. Oznaczenie pomaga wyszukiwarce zrozumieć podmiot, ale sposób prezentacji wyników zależy również od jakości strony, spójności informacji w innych źródłach i decyzji algorytmów Google.

Jak wybrać typ i wdrożyć go bez konfliktów

Najprostsza reguła decyzyjna jest praktyczna:

• firma bez placówki obsługującej klientów — Organization,
• jedna dostępna dla klientów placówka — odpowiedni podtyp LocalBusiness,
• centrala i kilka oddziałów — Organization dla podmiotu nadrzędnego oraz osobny LocalBusiness dla każdego oddziału,
• sklep internetowy z biurem niedostępnym dla klientów — Organization,
• firma mobilna dojeżdżająca do klientów — zwykle Organization, chyba że prowadzi także rzeczywisty punkt obsługi,
• serwis franczyzowy — osobna organizacja nadrzędna i osobne dane placówek, z uwzględnieniem ich faktycznych operatorów.

Nie trzeba dodawać jednocześnie Organization i LocalBusiness tylko po to, aby „mieć oba warianty”. LocalBusiness dziedziczy cechy organizacji, dlatego dla pojedynczego lokalnego biznesu jeden precyzyjny typ zwykle wystarcza.

Wdrożenie najlepiej przeprowadzić w formacie JSON-LD. Kod jest oddzielony od widocznej warstwy HTML, łatwiej go aktualizować i rzadziej psuje układ strony niż mikrodane wstawiane bezpośrednio do elementów treści. Nie oznacza to jednak, że można opisywać informacje, których użytkownik nie widzi. Adres, telefon, nazwa i godziny otwarcia powinny zgadzać się z treścią strony.

Minimalna procedura wdrożenia wygląda następująco:

1. Ustal, jaki podmiot jest głównym tematem strony.
2. Wybierz możliwie szczegółowy, ale zgodny z rzeczywistością typ.
3. Nadaj obiektowi trwały @id.
4. Ujednolić nazwę, adres, telefon i URL.
5. Usuń stare znaczniki generowane przez motyw lub poprzednią wtyczkę.
6. Sprawdź kod w Rich Results Test.
7. Sprawdź pełną składnię w Schema Markup Validator.
8. Po publikacji użyj inspekcji adresu URL w Google Search Console.
9. Po ponownym zindeksowaniu sprawdź, czy Google widzi właściwy kod strony.

Szczególnie ważny jest punkt piąty. W WordPressie dane strukturalne mogą być jednocześnie generowane przez motyw, WooCommerce, Yoast SEO, Rank Math i osobny moduł lokalnego SEO. Efektem bywają trzy organizacje, dwa różne logotypy i nieaktualny adres placówki. Kod może być formalnie poprawny, ale semantycznie przedstawia kilka sprzecznych wersji tej samej firmy.

Nie należy też oczekiwać natychmiastowego efektu po wdrożeniu. Google musi ponownie pobrać i przetworzyć stronę, co może zająć od kilku dni do kilku tygodni. Samo przejście testu nie gwarantuje rozszerzonego wyniku. Test potwierdza głównie możliwość odczytania danych i zgodność z wymaganiami technicznymi.

Dane strukturalne trzeba aktualizować po zmianie:

• adresu,
• numeru telefonu,
• domeny,
• godzin otwarcia,
• logo,
• nazwy marki,
• operatora placówki,
• struktury oddziałów.

Najbardziej irytująca wada tego rozwiązania jest prosta: dane szybko się rozjeżdżają. Firma aktualizuje godziny w Profilu Firmy w Google, ale zapomina o kodzie strony. Zmienia numer telefonu w stopce, lecz JSON-LD nadal zawiera poprzedni. Dlatego dane strukturalne powinny korzystać z tego samego źródła danych co widoczna wizytówka firmy, a nie być ręcznie wpisanym fragmentem kodu, o którym nikt później nie pamięta.

Więcej informacji na: biznap.pl

FAQ

Czy LocalBusiness poprawia pozycję strony w lokalnych wynikach?
Samo dodanie znacznika nie podnosi automatycznie pozycji. Pomaga wyszukiwarce zinterpretować dane placówki, ale nie zastępuje poprawnej strony lokalnej, Profilu Firmy w Google, opinii, linków ani spójnych danych kontaktowych.

Czy firma działająca w całej Polsce może użyć LocalBusiness?
Tak, ale tylko dla rzeczywistej placówki. Zasięg ogólnopolski nie wyklucza LocalBusiness, jeżeli firma ma punkt obsługi klientów. Nie należy jednak tworzyć fikcyjnych lokalizacji dla każdego miasta, w którym świadczone są usługi.

Czy na stronie można umieścić jednocześnie Organization i LocalBusiness?
Tak, gdy opisują różne elementy: na przykład centralę i oddział. Dla jednej placówki tworzenie dwóch niezależnych obiektów bez wyraźnego powiązania zwykle nie jest potrzebne i może prowadzić do duplikacji danych.

Gdzie umieścić kod danych strukturalnych?
JSON-LD można umieścić w sekcji <head> albo <body>. Ważniejsze od miejsca jest to, aby kod był dostępny dla robota, dotyczył zawartości danej strony i nie był blokowany przez mechanizm zgód lub logowanie.

Czy trzeba podawać NIP i KRS?
Nie są konieczne do podstawowego oznaczenia firmy. Można dodać prawidłowe identyfikatory organizacji, jeżeli są potrzebne do jednoznacznego rozpoznania podmiotu, ale nie należy tworzyć niestandardowych pól ani wpisywać numerów w przypadkowe właściwości.

Czy każda podstrona oddziału powinna mieć własny znacznik?
Tak. Każdy oddział powinien mieć osobny @id, adres, telefon i godziny. Dane muszą dotyczyć placówki przedstawionej na konkretnej podstronie.

Co sprawdzić jako pierwsze przed zmianą typu?
Najpierw ustal, czy strona opisuje podmiot, czy fizyczną placówkę. Następnie sprawdź kod źródłowy i usuń zdublowane obiekty generowane przez wtyczki. Dopiero potem wybierz typ: Organization dla firmy jako organizacji albo najbardziej szczegółowy podtyp LocalBusiness dla rzeczywistego punktu obsługi klientów.