Firma z wieloma lokalizacjami w AI: strony oddziałów bez duplikatów

Sieć z dziesięcioma oddziałami prawie zawsze ma w serwisie dziesięć bliźniaczych podstron. Ten sam nagłówek, ten sam opis usługi, ta sama lista korzyści, podmieniona tylko nazwa miasta w tytule i w jednym akapicie. Taki zestaw wygląda sensownie w arkuszu kalkulacyjnym, ale w wyszukiwarce i w modelach językowych działa przeciwko firmie: zamiast dziesięciu silnych punktów powstaje jeden rozmyty komunikat, którego żaden system nie potrafi przypisać do konkretnego adresu.

Poniżej rozkładamy na części problem duplikatów przy wielu lokalizacjach i pokazujemy, co realnie różnicuje strony lokalizacji w SEO oraz w odpowiedziach generowanych przez AI. Jeśli dopiero zaczynasz pracę nad obecnością firmy w asystentach, warto najpierw przejrzeć nasz materiał o tym, jak firmy lokalne wpadają do odpowiedzi ChatGPT, bo mechanika cytowania jest tam opisana od podstaw.

Dlaczego kopie stron szkodzą

Pierwszy koszt jest klasycznie wyszukiwarkowy. Gdy kilkanaście adresów URL ma niemal identyczną treść, Google wybiera jeden z nich jako wersję kanoniczną i resztę traktuje jako zbędną. W raporcie indeksowania widać wtedy status „Strona jest duplikatem, Google wybrał inny adres jako kanoniczny”. Nie jest to kara, tylko decyzja o oszczędzaniu zasobów, ale efekt dla firmy jest ten sam: oddział w Katowicach nie ma własnej karty w indeksie, więc nie może rankować na zapytanie z nazwą tego miasta.

Drugi koszt jest nowy i dotyczy modeli językowych. Asystent, który buduje odpowiedź na pytanie „gdzie w Lublinie zrobić przegląd instalacji fotowoltaicznej”, potrzebuje fragmentu tekstu, w którym Lublin występuje razem z usługą, adresem, godzinami i jakimś konkretem. Jeśli wszystkie nasze podstrony mówią to samo, model nie ma z czego zbudować zdania o Lublinie i albo pominie firmę, albo wygeneruje odpowiedź ogólną, bez wskazania konkretnego punktu. Przy dziesięciu klonach ryzykujemy też odwrotną pomyłkę: model przypisze firmie adres, którego ona nie obsługuje.

Co musi być unikalne na stronie oddziału

Nie trzeba przepisywać całej oferty dla każdego miasta. Wystarczy, że unikalne będą te elementy, które faktycznie opisują punkt, a nie firmę jako całość. Minimalna lista różnicująca wygląda tak:

Reguła praktyczna: jeśli dany akapit można przenieść na podstronę innego miasta bez zmiany ani jednego słowa, to nie jest treść lokalna i nie buduje widoczności tego punktu. Taki akapit może zostać, ale nie może stanowić większości strony. Zdrowa proporcja to około 40 procent treści unikalnej na oddział, liczonej w akapitach.

Czego nie robić

• Nie generuj wariantów przez podmianę miasta w szablonie, nawet jeśli narzędzie obiecuje „unikalność” na poziomie 90 procent.
• Nie twórz podstron dla miast, w których nie masz adresu ani realnej obsługi. To najszybsza droga do uznania serwisu za niskiej jakości.
• Nie wrzucaj na wszystkie oddziały tej samej galerii zdjęć z centrali.
• Nie ukrywaj różnic w rozwijanych zakładkach, których nie ma w kodzie strony przed kliknięciem.

Dane lokalne, zespół i zdjęcia

Najtrudniejsza część nie jest techniczna, tylko operacyjna: trzeba zebrać materiał z oddziałów. Najszybciej działa krótki formularz dla kierownika każdego punktu, w którym pyta się o pięć rzeczy: trzy najczęstsze pytania klientów, dwie ostatnie realizacje, skład zespołu, specyfikę lokalnego rynku i opis dojazdu. Z takiego zestawu da się zbudować 400–600 słów treści, której nie ma nikt inny.

Zdjęcia mają tu podwójne znaczenie. Po pierwsze, własne fotografie wnętrza i zespołu to sygnał wiarygodności, którego nie zapewni bank zdjęć. Po drugie, nazwy plików i atrybuty alt powiązują materiał z miejscem, o ile są normalnym opisem: „zespół serwisu w Gdańsku przy ul. Grunwaldzkiej” jest lepszy od „serwis Gdańsk serwis tani”.

Warto też zadbać o spójność danych kontaktowych w całym serwisie. Jeden telefon na jedną lokalizację, ten sam format adresu w stopce, na podstronie i w wizytówce. Rozjazd między tymi źródłami jest jednym z częstszych powodów, dla których asystent podaje nieaktualny numer.

Schema LocalBusiness dla każdego punktu

Dane strukturalne są tym miejscem, w którym najłatwiej pomóc modelowi i najłatwiej narobić bałaganu. Zasada jest prosta: jeden obiekt LocalBusiness na jedną stronę oddziału, z własnym @id, własnym address, geo, telephone i openingHoursSpecification. Oddział powinien wskazywać na centralę przez właściwość parentOrganization, a strona z listą lokalizacji może agregować je w ItemList.

Typowe błędy, które widzimy w audytach sieci:

1. Ten sam @id skopiowany na wszystkie oddziały, co sprowadza dziesięć punktów do jednego podmiotu.
2. Adres centrali w schema na każdej podstronie, mimo poprawnego adresu w treści. Wtedy wygrywa schema.
3. Godziny otwarcia jako zwykły tekst w atrybucie description, bez openingHoursSpecification.
4. Oceny zbiorcze z całej firmy podane jako aggregateRating pojedynczego punktu.
5. Typ ogólny Organization tam, gdzie istnieje dokładniejszy podtyp, na przykład Dentist albo AutoRepair.

Pełną listę dopuszczalnych pól i podtypów opisuje dokumentacja Google dla danych strukturalnych firm lokalnych. Po wdrożeniu warto przepuścić kilka podstron przez test wyników z elementami rozszerzonymi, bo błąd w jednym szablonie powtarza się na wszystkich oddziałach.

Linkowanie między oddziałami i centralą

Strony lokalizacji bardzo często są sierotami: prowadzi do nich tylko wpis w stopce i pozycja na mapie w JavaScript, której crawler nie czyta. Taki układ sprawia, że najważniejsze komercyjnie podstrony mają najmniejszą moc w serwisie.

Sprawdza się prosta struktura trzypoziomowa. Centralna strona usługi opisuje ofertę i linkuje tekstowo do wszystkich oddziałów. Strona z listą lokalizacji jest zwykłym spisem z opisami, nie samą mapą. Każdy oddział linkuje z powrotem do strony usługi i do dwóch, trzech najbliższych geograficznie punktów, bo to realnie pomaga użytkownikowi, który trafił na zły adres. Jeśli planujesz to w szerszej strategii, nasz model sześciomiesięcznego planu dla B2B pokazuje, jak wpleść takie podstrony w harmonogram, zamiast wypuszczać je wszystkie w jednym tygodniu.

Anchory powinny się różnić: „serwis pomp ciepła w Rzeszowie” niesie więcej informacji niż dziesięć linków „sprawdź nasz oddział”.

Profil Firmy Google dla każdej lokalizacji

Bez osobnej wizytówki dla każdego punktu cała praca na stronie ma ograniczony zasięg, bo znaczna część danych lokalnych, z których korzystają także asystenci, pochodzi właśnie z profili. Każda wizytówka powinna mieć własny adres, własny numer, własne godziny, własne zdjęcia i link nie do strony głównej, lecz do podstrony tego oddziału. Ten ostatni punkt jest pomijany najczęściej i kosztuje najwięcej.

Szczegóły konfiguracji, w tym konto nadrzędne, grupy lokalizacji i import masowy, opisaliśmy w tekście o tym, jak przygotować Profil Firmy Google pod AI, włącznie z kategoriami i atrybutami, które najczęściej trafiają do odpowiedzi.

Jak sprawdzić efekt w odpowiedziach AI

Pomiar jest mniej wygodny niż w klasycznym SEO, bo nie ma raportu pozycji. Da się jednak zbudować powtarzalny test. Przygotuj listę pytań w formie, w jakiej zadaje je człowiek, po dwa, trzy na lokalizację: „kto robi X w mieście Y”, „ile kosztuje X w Y”, „czy jest X otwarte w sobotę w Y”. Zadawaj je raz w miesiącu w tych samych asystentach i zapisuj trzy rzeczy: czy firma została wymieniona, czy podany adres jest poprawny i czy link prowadzi do właściwej podstrony oddziału.

Równolegle warto patrzeć na dane, które są mierzalne: liczbę zaindeksowanych stron lokalizacji, wyświetlenia w Search Console filtrowane po zapytaniach z nazwą miasta oraz działania na wizytówkach. Jeśli po trzech miesiącach rośnie indeksacja i widoczność na frazy z miastami, a model nadal pomija firmę, problemem jest najczęściej spójność danych, a nie treść.

Na koniec rzecz, o której łatwo zapomnieć: oddziały się zmieniają. Zamknięty punkt, który nadal ma aktywną podstronę i wizytówkę, przez miesiące będzie pojawiał się w odpowiedziach asystentów. Przegląd listy raz na kwartał kosztuje godzinę, a oszczędza reklamacji.

FAQ