Lokalne SEO dla korporacji: Strategie WordPress multisite w 2026 roku

Zarządzanie widocznością organiczną jednej placówki stacjonarnej to stosunkowo proste zadanie. Kiedy jednak firma rozrasta się do 50, 100 czy 500 oddziałów, punktów obsługi lub przychodni w całej Polsce, pojawia się złożony problem zarządzania techniką: jak utrzymać centralną kontrolę nad marką i nie stracić lokalnego dopasowania, którego wymagają wyszukiwania typu “w pobliżu”?

Wiele marek z wieloma lokalizacjami sięga po WordPress Multisite jako infrastrukturę, która łączy ogólnokrajowy autorytet domeny ze specyfiką każdej fizycznej placówki. Ten przewodnik opisuje architekturę i w każdym punkcie pokazuje, co faktycznie mówi dokumentacja Google i WordPressa, bo spora część tego, co krąży o lokalnym SEO na dużą skalę, to folklor.

Zobacz moje zaawansowane usługi SEO i GEO, przygotowane z myślą o wieloregionalnych architekturach firmowych.

#1. Dlaczego WordPress Multisite dla wielu oddziałów

Częsty błąd dużych sieci polega na wyborze jednej z dwóch problematycznych skrajności: próbie zmieszczenia wszystkich sklepów na jednej statycznej stronie z listą albo stworzeniu dziesiątek całkowicie osobnych instalacji WordPressa. Pierwsza opcja nie ma wystarczającej głębi, by pozycjonować konkretne frazy geograficzne. Druga to koszmar bezpieczeństwa i utrzymania: setki baz danych i odizolowanych paneli.

WordPress Multisite rozwiązuje ten dylemat jedną platformą, która obsługuje sieć podwitryn z jednej bazy kodu:

• Centralne zarządzanie motywami i wtyczkami: aktualizacje bezpieczeństwa, motywy firmowe i narzędzia analityczne instaluje raz, na poziomie sieci, Superadministrator.
• Odizolowane tabele danych: każda podwitryna ma własny zestaw tabel (wp_X_posts, wp_X_options), dzięki czemu lokalne ustawienia i wpisy pozostają ściśle rozdzielone.
• Szczegółowa hierarchia uprawnień: lokalni kierownicy dostają ograniczony dostęp do edycji, by aktualizować godziny otwarcia w wyjątkowe dni albo publikować komunikaty dla swojej gminy, bez ryzyka uszkodzenia architektury portalu.

Dokumentacja WordPressa o Multisite streszcza model danych jednym zdaniem: treść każdej witryny ma “własne tabele w bazie danych, a wspólna dla wszystkich instancji jest tylko tabela użytkowników” (tłumaczenie własne). Ta sama strona przypomina, że do korzystania z Multisite potrzebne są włączone przepisywania adresów URL.

#2. Podkatalogi czy subdomeny dla stron lokalnych

Struktura adresów decyduje o tym, gdzie mieszka każdy oddział i ile kosztuje jego utrzymanie. Poniższa tabela opiera się na porównaniu opublikowanym przez Google w Zarządzanie witrynami wieloregionalnymi i wielojęzycznymi, zastosowanym do stron miast:

Google nie przypisuje żadnemu z tych modeli przewagi w pozycjonowaniu. Dla sieci sklepów w jednym kraju podkatalogi zwykle wygrywają operacyjnie: jeden certyfikat, jeden hosting, jedna konfiguracja cache. Subdomeny mają sens, gdy istnieją techniczne powody, by obsługiwać regiony z różnych serwerów.

Po stronie WordPressa strona Tworzenie sieci wyjaśnia, że wybór między subdomenami a podkatalogami zapada przy instalacji sieci i że później można przekonfigurować sieć na drugą opcję, choć zmiana wymaga pracy. Ta sama strona precyzuje, że wildcard DNS jest potrzebny tylko dla witryn tworzonych na żądanie w oparciu o domenę, nawet jeśli ekran instalacji sugeruje coś innego.

#3. Jak dodać schemę LocalBusiness do każdego oddziału

Dane strukturalne mówią wyszukiwarkom wprost, jaka jest nazwa, adres i godziny otwarcia każdej placówki. Według dokumentacji danych strukturalnych LocalBusiness osoby szukające firm w wyszukiwarce Google lub w Mapach mogą zobaczyć panel wiedzy z tymi szczegółami.

Każda podwitryna w sieci Multisite powinna dynamicznie generować pełny, wyspecjalizowany znacznik JSON-LD. Przykład używa fikcyjnej marki:

<!-- Przykładowy JSON-LD LocalBusiness wygenerowany dla oddziału (fikcyjna marka) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Marka Przykład Kraków",
  "url": "https://example.com/krakow/",
  "telephone": "+48 12 000 00 00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 100",
    "addressLocality": "Kraków",
    "postalCode": "00-000",
    "addressCountry": "PL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 50.06143,
    "longitude": 19.93658
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00:00",
      "closes": "18:00:00"
    }
  ]
}
</script>

Zasady Google, których trzyma się ten przykład:

• Wymagane: tylko name i address, z jak największą liczbą właściwości adresu.
• Współrzędne: w geo szerokość i długość geograficzna powinny mieć dokładność “co najmniej 5 miejsc po przecinku” (tłumaczenie własne).
• Godziny: opens i closes w formacie hh:mm:ss; openingHoursSpecification przyjmuje pojedynczy obiekt albo listę.
• Telefon: główny numer kontaktowy dla klientów, z numerem kierunkowym kraju i strefy.
• URL: pełny adres konkretnej lokalizacji, który musi być działającym linkiem. W sieci Multisite to strona oddziału, a nie strona główna marki.
• Podtyp: Google prosi o możliwie najbardziej szczegółowy podtyp LocalBusiness (w przykładzie Store).
• Działy: placówka z apteką albo warsztatem może opisać każdą część za pomocą department.

Punkt, który wiele poradników pomija: aggregateRating i review są zalecane, słowami Google, tylko dla witryn zbierających opinie o innych lokalnych firmach. Sieć, która oznacza opinie o własnych sklepach, nie mieści się w tym przypadku.

Dzięki polom niestandardowym (na przykład Advanced Custom Fields) albo REST API te dane trafiają do bazy każdego oddziału i są automatycznie wstrzykiwane do HTML, bez ręcznego programowania po stronie lokalnego zespołu.

#4. Jak synchronizować dane NAP z Profilem Firmy w Google

Rozbieżności w danych NAP (Name, Address, Phone) między witryną, danymi strukturalnymi a Profilem Firmy w Google rodzą wątpliwości, która informacja jest prawdziwa. Jeśli adres na stronie podaje inny kod pocztowy niż ten zapisany w profilu, użytkownik i wyszukiwarka dostają dwie wersje tego samego sklepu.

Żeby zachować stałą synchronizację, WordPress pełni rolę głównego repozytorium danych:

1. Scentralizowana baza danych: adresy, godziny otwarcia i kontakty wszystkich sklepów są przechowywane w WordPressie w jednym, kanonicznym formacie.
2. Konektory API: zaplanowane zadania (WP-Cron albo crontab na serwerze) wysyłają zmiany do API Profilu Firmy w Google, o ile ma się do nich dostęp.
3. Propagacja wyjątków: gdy kierownik zmienia godziny zamknięcia z okazji lokalnego święta, zmiana wychodzi z jednego miejsca i trafia na stronę, do danych strukturalnych i do profilu.

#5. Czego wytyczne Profilu Firmy w Google wymagają od sieci sklepów

Wytyczne dotyczące prezentowania firmy w Google określają, co każdy rekord w WordPressie powinien zawierać, zanim trafi do profilu:

• Jeden profil na lokalizację: Google prosi, by nie tworzyć więcej niż jednej strony na lokalizację, “na jednym koncie lub na wielu kontach” (tłumaczenie własne).
• Nazwa: powinna odzwierciedlać prawdziwą nazwę firmy, bez zbędnych informacji. W sieci “wszystkie lokalizacje muszą mieć tę samą nazwę”, chyba że rzeczywista prezentacja marki różni się między sklepami (tłumaczenie własne). Pole nazwa_publiczna dla każdego oddziału, z nazwą marki zablokowaną na poziomie sieci, chroni przed kierownikiem dopisującym słowa kluczowe.
• Adres: musi być prawdziwą fizyczną lokalizacją; skrytki pocztowe i biura wirtualne się nie kwalifikują.
• Telefon: pod bezpośrednią kontrolą firmy; Google woli numer lokalny od centralnej infolinii call center, kiedy tylko to możliwe.
• Witryna: powinna reprezentować konkretną lokalizację. W sieci Multisite to naturalnie adres URL oddziału.
• Działy: działy obsługujące klientów, które funkcjonują jako odrębne podmioty, mogą mieć własny profil, z nazwą inną niż główna firma.
• Firmy działające na określonym obszarze: jeden profil dla biura centralnego z określonym obszarem obsługi i adresem ukrytym przed klientami.

Przy weryfikacji strona weryfikacji zbiorczej dotyczy firm, które mają “co najmniej 10 lokalizacji tej samej firmy” (tłumaczenie własne). Wniosek składa się z arkuszem kalkulacyjnym wszystkich zarządzanych profili, nie jest dostępny dla firm działających na określonym obszarze i może wymagać weryfikacji wideo z upoważnionym przedstawicielem na miejscu. Eksport wygenerowany z tabel sieci Multisite to najprostszy sposób, by przygotować taki arkusz bez błędów przepisywania.

#6. Jak tworzyć strony lokalne bez powielonej treści

Tworzenie 100 stron miast przez samą podmianę nazwy miejscowości w statycznym tekście (“Najlepsze usługi informatyczne w Gdańsku”, “Najlepsze usługi informatyczne w Poznaniu”) daje strony o niskiej wartości.

Zasady Google dotyczące spamu opisują ten wzorzec bez owijania w bawełnę. Wśród przykładów nadużyć typu doorway jest “posiadanie wielu nazw domen lub stron kierowanych na konkretne regiony lub miasta, które prowadzą użytkowników do jednej strony” (tłumaczenie własne). Ta sama strona definiuje nadużycie treści na dużą skalę jako generowanie wielu stron głównie po to, by manipulować pozycjami, a nie pomagać użytkownikom. Sieć Multisite z 500 niemal identycznymi podwitrynami pasuje do obu definicji.

Każdą lokalną podwitrynę warto wzbogacić prawdziwą treścią:

• Zespół na miejscu: prezentacja ze zdjęciem, imieniem i nazwiskiem oraz specjalizacją osób pracujących w danej placówce.
• Projekty i case studies z regionu: krótkie wzmianki o pracach dla lokalnych instytucji i firm, jeśli takie istnieją i można je opublikować.
• Dojazd i komunikacja: konkretne informacje o pobliskich stacjach metra, przystankach autobusowych i tramwajowych albo parkingach.
• Inicjatywy lokalne: informacje o udziale w lokalnych targach, wykładach czy partnerstwach sportowych w gminie.

Test praktyczny: gdyby strona oddziału przestała istnieć, czy użytkownik straciłby jakąś informację, której nie znajdzie na stronie ogólnokrajowej? Jeśli nie, tej strony nie należy tworzyć.

#7. Jak tworzyć nowe oddziały za pomocą WP-CLI

Ręczne zakładanie setek oddziałów w panelu zajmuje setki godzin i mnoży błędy konfiguracji. Administracja sieci powinna sięgnąć po terminal i WP-CLI.

#Włączanie Multisite w podkatalogach w wp-config.php

Pierwszy krok to define( 'WP_ALLOW_MULTISITE', true );. Po utworzeniu sieci ekran instalacji pokazuje końcowe linie, dopasowane do danej instalacji; dla sieci w podkatalogach wyglądają tak:

/* Konfiguracja sieci Multisite w podkatalogach */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'marka.pl');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

#Klonowanie nowych oddziałów za pomocą Basha i WP-CLI

Skrypt wychodzi od witryny wzorcowej (ID 2, pod adresem marka.pl/wzor/). Po skopiowaniu tabel wzorca opcje siteurl i home nadal wskazują na wzorzec, dlatego krok 3 poprawia je poleceniem search-replace ograniczonym do nowej witryny:

#!/usr/bin/env bash
# Skrypt automatycznego zakładania nowych oddziałów w WordPressie

SLUG_MIASTA="krakow"
NAZWA_MIASTA="Kraków"
EMAIL_KIEROWNIKA="[email protected]"

# 1. Utworzenie nowej podwitryny w sieci Multisite
NOWY_BLOG_ID=$(wp site create --slug="$SLUG_MIASTA" --title="Marka $NAZWA_MIASTA" --email="$EMAIL_KIEROWNIKA" --porcelain)

# 2. Sklonowanie ustawień i bloków ze standardowego wzorca (site_id 2)
wp db export /tmp/wzor.sql --tables=$(wp db tables "wp_2_*" --format=csv)
sed -i "s/wp_2_/wp_${NOWY_BLOG_ID}_/g" /tmp/wzor.sql
wp db import /tmp/wzor.sql
rm /tmp/wzor.sql

# 3. Poprawienie adresów URL odziedziczonych po wzorcu i metadanych lokalizacji
wp search-replace "marka.pl/wzor/" "marka.pl/$SLUG_MIASTA/" --url="marka.pl/$SLUG_MIASTA/"
wp option update blogname "Marka $NAZWA_MIASTA" --url="marka.pl/$SLUG_MIASTA/"
wp post update 1 --post_title="Oddział $NAZWA_MIASTA" --url="marka.pl/$SLUG_MIASTA/"

echo "Podwitryna działa pod adresem marka.pl/$SLUG_MIASTA/ z ID $NOWY_BLOG_ID"

Skrypt trzeba przetestować na stagingu, zanim trafi na produkcję: kopiowanie tabel omija hooki WordPressa, a wtyczki trzymające dane we własnych tabelach wymagają osobnej obsługi.

#8. Kto co kontroluje w administracji sieci Multisite

Podział uprawnień opisany w dokumentacji administracji sieci sprawia, że model jest bezpieczny dla setek lokalnych kierowników:

• Superadministrator: tylko Superadministrator instaluje motywy i wtyczki. Słowami dokumentacji: “administratorzy witryn nie mogą instalować nowych motywów ani wtyczek” (tłumaczenie własne).
• Wtyczki: Superadministrator może włączyć wtyczkę w całej sieci (Włącz w sieci witryn), na przykład wtyczkę generującą JSON-LD LocalBusiness, tak żeby w żadnym oddziale jej nie zabrakło.
• Motywy: motyw musi być włączony w sieci albo dozwolony w zakładce Motywy konkretnej witryny. Motyw firmowy jest dostępny dla wszystkich; alternatywne motywy w ogóle nie pojawiają się oddziałom.
• Menu wtyczek: dostęp administratorów witryn do ekranu wtyczek to opcja w Ustawieniach sieci. W sieci sklepów warto zostawić ją wyłączoną.
• Pliki: pierwsza witryna zapisuje przesłane pliki w /wp-content/uploads/, kolejne w /wp-content/uploads/sites/, co pozwala robić kopie zapasowe i porządki osobno dla każdego oddziału.

Ponieważ tabela użytkowników jest wspólna, dyrektor regionalny może mieć rolę Redaktor w dziesięciu podwitrynach na jednym koncie, a kierownik sklepu tylko w swojej.

#9. Własne domeny dla franczyzobiorców przez mapowanie domen

Nie każda lokalizacja mieszka pod domeną główną. Franczyzobiorca z własną marką może wymagać własnej domeny. Według strony o mapowaniu domen od WordPressa 4.5 ta funkcja jest wbudowana w Multisite: w panelu sieci, w sekcji Witryny, edytuje się podwitrynę i wpisuje pełny adres URL w polu Adres witryny (URL).

Wymagania praktyczne, wszystkie z tej samej strony:

• DNS: dodatkowe domeny muszą wskazywać na domenę główną sieci przed mapowaniem.
• SSL: certyfikat na domenie głównej i SNI dla pozostałych; każda domena powinna mieć SSL, by logowanie do panelu było szyfrowane.
• Ciasteczka: jeśli logowanie na zmapowanej podwitrynie nie działa, dokumentacja zaleca dodanie define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); do wp-config.php, za kodem sieci.

Kompromis jest taki sam jak w tabeli z sekcji 2: każda osobna domena musi budować swoją obecność od zera, więc mapowanie służy tożsamości marki, a nie SEO.

#10. Hreflang, gdy sieć obejmuje kilka krajów

Sieć z oddziałami w Polsce, Niemczech i Czechach często ma tę samą stronę usługi po polsku, niemiecku i czesku. Tu wchodzi hreflang, opisany przez Google w Zlokalizowane wersje strony:

• Trzy metody: tagi link w HTML, nagłówki HTTP albo mapa witryny XML. W sieci Multisite mapa witryny generowana przez każdą podwitrynę jest najłatwiejsza w utrzymaniu.
• Wzajemność: “każda wersja językowa musi wskazywać samą siebie i wszystkie pozostałe wersje” (tłumaczenie własne). Jeśli podwitryna niemiecka wskazuje na polską, a polska nie wskazuje z powrotem, adnotacja nie działa.
• x-default: zarezerwowana wartość używana, gdy żaden język ani region nie odpowiada ustawieniom przeglądarki, na przykład dla strony wyboru kraju.
• Kody: akceptowane są tylko kody języka ISO 639-1 i regionu ISO 3166-1 Alpha 2, takie jak pl-PL, de-DE czy cs-CZ. Google mówi wprost: nie można podać samego kodu kraju.
• Wykrywanie języka: Google nie używa hreflang ani atrybutu lang w HTML do wykrywania języka strony; widoczny tekst musi faktycznie być w tym języku.

Strony miast w obrębie tego samego kraju i języka nie dostają między sobą hreflang: Kraków i Wrocław nie są swoimi wersjami językowymi.

#11. Dlaczego nie dopasowywać treści do IP albo języka przeglądarki

Częsta pokusa w dużych sieciach to automatyczne przekierowanie odwiedzającego do najbliższego oddziału. Ta sama strona Google o witrynach wieloregionalnych odradza to z dwóch powodów:

• Robot wysyła żądania HTTP bez nagłówka Accept-Language, więc treść zmieniająca się w zależności od języka przeglądarki może nigdy nie zostać znaleziona.
• “Nie używaj analizy IP do dopasowywania treści” (tłumaczenie własne), bo lokalizacja na podstawie IP jest trudna i na ogół mało wiarygodna.

Google zaleca różne adresy URL dla każdej wersji i ignoruje metatagi lokalizacji, takie jak geo.position. W praktyce: widoczny wybór sklepu z linkami, które robot może przejść, do każdej podwitryny, zamiast cichego przekierowania. Wśród sygnałów, z których Google korzysta, by zrozumieć odbiorców witryny, są lokalne adresy i telefony na stronie, czyli kolejny powód, by pokazywać dane NAP w HTML każdego oddziału.

#12. Jak przyspieszyć Multisite za pomocą edge cachingu i Redisa

Instalacja WordPressa z setkami podwitryn na produkcji wymaga szczególnej dbałości o architekturę:

• Edge caching przez CDN: statyczny cache stron można rozłożyć na punkty obecności (PoP) CDN-a, takiego jak Cloudflare czy Fastly, najbliższe użytkownikom w każdym regionie.
• Cache obiektów w Redisie: Redis Object Cache przechowuje w pamięci RAM wyniki zapytań o opcje i metadane z setek tabel sieci.
• Indeksowanie bazy danych: tabele wp_blogs i wp_site powinny być zoptymalizowane, żeby kierowanie żądań przez serwer WWW przebiegało bez zgrzytów.

Lokalizacja serwera też należy do sygnałów dotyczących odbiorców, które wymienia Google, ale samo Google zaznacza, że nie jest to sygnał rozstrzygający. CDN odpowiada za szybkość; kierowanie geograficzne wynika z danych na stronie i z hreflang.

#13. Model dojrzałości lokalnego SEO dla firm

Opierając sieć firmy na WordPress Multisite, marka łączy kontrolę typową dla portalu korporacyjnego ze stronami lokalnymi, które odpowiadają osobom szukającym konkretnego sklepu, pod warunkiem że każda z nich ma własną treść i dane zgodne z profilem w Google.