Schema dla firmy z wieloma lokalizacjami – jak oznaczyć oddziały bez mieszania danych?

Najbezpieczniejszy sposób oznaczenia firmy z wieloma lokalizacjami to utworzenie osobnej, rzeczywistej strony dla każdego oddziału i umieszczenie na niej danych strukturalnych opisujących właśnie tę lokalizację. Każdy oddział powinien mieć własny adres, telefon, godziny otwarcia oraz identyfikator @id. Dane wspólnej organizacji można opisać osobno, a relację między firmą nadrzędną i oddziałami zaznaczyć za pomocą właściwości branchOf lub subOrganization, zgodnie z modelem Schema.org.

Samo dodanie jednego schematu LocalBusiness z listą wszystkich adresów zwykle miesza kontekst strony. Robot i użytkownik mogą wtedy nie wiedzieć, której lokalizacji dotyczą telefon, godziny czy oferta. Schema multiple locations powinno odzwierciedlać rzeczywistą strukturę serwisu, a nie zastępować brakujące strony lokalizacyjne.

Najpierw zaplanuj strukturę stron lokalizacji

Wdrożenie zacznij od sprawdzenia, czy każdy oddział ma własny, dostępny adres URL. Przykładowo firma może mieć stronę główną, stronę „Oddziały” oraz osobne podstrony dla lokalizacji w Krakowie, Katowicach i Gliwicach. Nie chodzi o samo powielenie szablonu z podmienioną nazwą miasta. Każda strona powinna przedstawiać konkretną placówkę i pomagać użytkownikowi podjąć decyzję o kontakcie lub wizycie.

Na stronie lokalizacji powinny znaleźć się informacje zgodne ze stanem faktycznym: adres, numer telefonu, godziny otwarcia, zakres obsługi oraz sposób dotarcia, jeśli firma rzeczywiście udostępnia takie informacje. Warto również jasno wskazać, czy dana placówka obsługuje klientów na miejscu, czy jest jedynie zapleczem firmy.

To ważne także poza danymi strukturalnymi. Strona oddziału jest punktem odniesienia dla użytkownika, Profilu Firmy w Google i innych wizytówek. Więcej o budowie takich podstron opisujemy w materiale Strona firmy pod Local SEO.

Jak rozpoznać, że lokalizacja zasługuje na osobną stronę?

Osobna strona ma sens wtedy, gdy oddział jest realnym elementem działalności firmy i można przypisać do niego konkretne dane. Dotyczy to między innymi salonu, punktu obsługi, biura przyjmującego klientów czy sklepu z własnymi godzinami pracy.

Nie twórz stron dla fikcyjnych adresów, wirtualnych lokalizacji ani obszarów, w których firma nie ma rzeczywistej placówki. Nie warto też oznaczać oddziału wyłącznie dlatego, że firma chce pojawiać się na kolejną nazwę miasta. Dane strukturalne mają opisywać istniejące obiekty, a nie projektowaną widoczność.

Przejdź do powiązanego poradnika i rozwiń ten element Local SEO.

Oddziel organizację od konkretnych oddziałów

W modelu wielolokalizacyjnym występują zwykle dwa poziomy informacji. Pierwszy to organizacja nadrzędna, czyli marka lub firma. Drugi to poszczególne obiekty lokalne, opisane jako odpowiedni typ LocalBusiness albo bardziej szczegółowy typ branżowy, jeżeli pasuje do działalności.

Organizacja może zawierać informacje wspólne, takie jak nazwa marki, główna strona internetowa czy logo. Oddział powinien natomiast przedstawiać dane przypisane do swojej lokalizacji. Nie należy kopiować telefonu oddziału A do strony oddziału B tylko dlatego, że firma korzysta z jednego numeru centralnego. Jeśli wszystkie lokalizacje faktycznie używają tego samego numeru, można go powtórzyć, ale musi to odpowiadać rzeczywistości.

W Schema.org relację oddziału z organizacją można wyrazić na przykład tak:

{
  "@type": "LocalBusiness",
  "@id": "https://example.com/lokalizacje/krakow/#localbusiness",
  "name": "Przykładowa Firma – oddział Kraków",
  "url": "https://example.com/lokalizacje/krakow/",
  "branchOf": {
    "@id": "https://example.com/#organization"
  }
}

To tylko fragment pokazujący powiązanie encji. Nie należy kopiować go bez zmiany adresów, nazwy i pozostałych danych. Właściwość branchOf wskazuje organizację, której częścią jest oddział. Odwrotną relację można modelować przez subOrganization, gdy struktura danych jest budowana od strony organizacji nadrzędnej.

Najważniejsza jest spójność identyfikatorów. Jeśli organizacja ma własne @id, ten sam identyfikator powinien być używany wszędzie tam, gdzie strona odnosi się do tej samej encji. Analogicznie każdy oddział powinien otrzymać własny, stabilny identyfikator.

Co powinien zawierać schema dla pojedynczej lokalizacji?

Podstawą jest właściwy typ obiektu oraz dane odpowiadające stronie, na której kod został umieszczony. Dla większości lokalnych placówek punktem wyjścia będzie LocalBusiness, a w niektórych przypadkach jego bardziej szczegółowy wariant. Wybieraj typ opisujący faktyczną działalność, a nie taki, który brzmi korzystniej marketingowo.

Przykładowa struktura dla strony oddziału może wyglądać następująco:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/lokalizacje/katowice/#localbusiness",
  "name": "Przykładowa Firma – oddział Katowice",
  "url": "https://example.com/lokalizacje/katowice/",
  "telephone": "+48 000 000 000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 1",
    "addressLocality": "Katowice",
    "postalCode": "00-000",
    "addressCountry": "PL"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "17:00"
    }
  ],
  "branchOf": {
    "@id": "https://example.com/#organization"
  }
}

Adres, telefon i godziny w tym przykładzie są wyłącznie demonstracyjne. W publikowanym kodzie muszą zostać zastąpione danymi konkretnego oddziału. Jeżeli placówka ma inne godziny w wybrane dni, należy odwzorować ten stan zamiast wpisywać jeden uproszczony harmonogram.

Nie dodawaj właściwości tylko po to, aby kod wyglądał obszerniej. Puste pola, dane nieaktualne albo informacje niewidoczne dla użytkownika utrudniają utrzymanie wdrożenia. Szczególną ostrożność zachowaj przy telefonie, adresie i godzinach świątecznych lub tymczasowych.

Jak połączyć dane strukturalne ze stroną firmy?

Każda strona oddziału powinna wskazywać samą siebie jako adres obiektu przez właściwość url. Dzięki temu dane strukturalne są powiązane z konkretną treścią, a nie z ogólną stroną główną firmy. Strona główna może opisywać organizację, natomiast strona lokalizacji powinna opisywać oddział.

W praktyce oznacza to rozdzielenie odpowiedzialności:

• strona główna przedstawia markę i informacje wspólne dla organizacji;
• strona lokalizacji przedstawia konkretny adres, telefon, godziny i zakres działania oddziału;
• strona z listą oddziałów pełni funkcję nawigacyjną i kieruje do właściwych podstron.

Nie oznacza to, że każda strona musi mieć zupełnie inny szablon. Powtarzalny układ jest naturalny. Unikalność powinna wynikać z realnych danych i użytecznych informacji o danym miejscu, a nie z mechanicznego dopisywania kolejnych akapitów.

Sprawdź również canonical każdej podstrony. Strona oddziału powinna być kanoniczna dla własnego adresu, chyba że istnieje konkretny powód techniczny do innego ustawienia. Nie kieruj wszystkich stron lokalizacji canonicalem na stronę główną tylko dlatego, że należą do tej samej firmy. Taki zabieg może osłabić rozdzielenie treści i adresów.

Sprawdź materiał poświęcony temu obszarowi widoczności lokalnej.

Najczęstszy błąd: jeden schemat dla wielu adresów

Problem pojawia się wtedy, gdy firma umieszcza na każdej stronie ten sam kod, a w nim miesza dane wszystkich oddziałów. Na stronie lokalizacji w Poznaniu pojawia się wtedy adres z Wrocławia, kilka telefonów i pełna lista godzin całej sieci. Użytkownik widzi jeden oddział, ale dane strukturalne opisują coś znacznie szerszego.

Lepszym rozwiązaniem jest jeden główny obiekt lokalny dla strony danego oddziału. Lista pozostałych lokalizacji może być widoczna w nawigacji lub w sekcji „Pozostałe oddziały”, ale nie powinna zastępować właściwego opisu bieżącej placówki.

Podobnie nie należy tworzyć oddziałów wyłącznie na podstawie obsługi danego regionu. Firma świadcząca usługi z dojazdem może mieć stronę opisującą obszar działania, ale nie jest to automatycznie oddział z adresem. Model danych musi odpowiadać realnemu modelowi biznesowemu.

Walidacja i interpretacja wyniku

Walidator nie potwierdza, że dane są prawdziwe ani że strona otrzyma określony wygląd w wynikach wyszukiwania. Pokazuje przede wszystkim, czy struktura może zostać odczytana. Google może też nie wyświetlić rozszerzonego wyniku, nawet gdy kod nie zawiera błędów. Dane strukturalne pomagają opisać stronę, ale nie są obietnicą pozycji ani widoczności.

Po publikacji obserwuj problemy dotyczące danych strukturalnych w Search Console i reaguj na zmiany w rzeczywistości. Zamknięcie oddziału, zmiana telefonu lub przeprowadzka powinny prowadzić do aktualizacji strony, kodu i pozostałych wizytówek. Spójność nie jest jednorazowym wdrożeniem, lecz elementem utrzymania serwisu.

Jeżeli struktura wielu lokalizacji jest rozbudowana, warto połączyć dane strukturalne z audytem indeksacji, canonicali i stron lokalizacyjnych. Materiały o takich zależnościach znajdziesz w sekcji Techniczne Local SEO.