Multisite vs osobne instalacje — kiedy co

WordPress Multisite vs osobne instalacje to decyzja, która zaważy na 3–5 latach operacji zespołu marketingowego. Zła decyzja – blokuje rozwój, psuje SEO i kosztuje dwucyfrowe tysiące PLN w refaktoryzacji. Dobra – daje skalę, spójność i kontrolę, których nie uzyskacie inaczej. Ten artykuł pokazuje, kiedy konkretnie wybrać multisite, kiedy osobne instalacje, a kiedy hybrydę – na bazie 40+ migracji wykonanych w polskich agencjach i markach w latach 2022–2026.

Tekst jest praktyczny, nie akademicki. Każda rekomendacja ma warunek użycia, pułapkę i szacunek kosztu w PLN. Jeśli prowadzicie sieć blogów korporacyjnych, portale w wielu językach, franczyzę, albo firmę z 5+ brandami – to jest lektura obowiązkowa. Jeśli macie jedną stronę i planujecie drugą – też, bo wtedy decyzja jest prostsza, ale nie trywialna.

Opisujemy też ekonomię utrzymania: hosting, licencje, aktualizacje, bezpieczeństwo. W 2026 WordPress Multisite nie jest ani zabawką, ani przeżytkiem – to narzędzie enterprise, które przy odpowiednim zastosowaniu oszczędza 30–60% kosztów operacyjnych. Przy niewłaściwym – generuje 2× więcej kosztów niż osobne instalacje.

Definicje — co dokładnie porównujemy

Zanim wybierzecie, warto uporządkować pojęcia. WordPress Multisite to natywna funkcja rdzenia (od 3.0 z 2010 roku) – pozwala uruchomić wiele stron z jednej instalacji plików i jednej bazy danych. Każda strona ma swoje własne tabele w tej samej bazie (prefix wp_2_, wp_3_…), wspólny kod rdzenia i współdzielone wtyczki/motywy aktywowane per site. Powiązane zagadnienia opisujemy w porównanie Ahrefs vs Semrush vs Sistrix 2026.

Multisite — trzy warianty

• Subdomeny (np. marka.com, blog.marka.com, pl.marka.com) – izolacja cookies, lepsza percepcja brandingu w Google, ale trudniejsze SSL.
• Subfolders (np. marka.com/pl/, marka.com/sklep/) – lepszy dla SEO (autorytet domeny się kumuluje), wymaga permalinks bez base category.
• Domain mapping (różne domeny na jednej instalacji, np. marka.pl, brand.de, brandstore.com) – najelastyczniejsze, standard enterprise 2026, wymaga dodatkowej konfiguracji DNS i SSL.

Osobne instalacje — warianty

• Osobne konta hostingowe – pełna izolacja, ale drogie w skali.
• Jeden hosting, osobne VHOSTs – tani kompromis, współdzielone zasoby serwera.
• Kubernetes / kontenery – standard enterprise dla 10+ stron, drogi w setup, tani w utrzymaniu.
• Managed WordPress platform (WP Engine, Kinsta, Rocket.net) – osobne plany per strona, wygodne ale drogie.

Kryteria decyzyjne — kiedy co wybrać

Nie ma odpowiedzi „multisite lepsze niż osobne”. Są cztery pytania, na które jeśli odpowiecie szczerze, wybór zrobi się sam. Każde z nich wskazuje stronę.

Cztery pytania decyzyjne

1. Czy strony dzielą wtyczki, motyw i globalną logikę? Tak – multisite. Nie – osobne.
2. Czy zespół techniczny jest jeden czy wielu? Jeden – multisite bez problemu. Wielu niezależnych – osobne.
3. Czy regulacje wymagają izolacji danych? Tak (medical, finance, niektóre GDPR edge cases) – osobne. Nie – dowolne.
4. Czy strony mogą iść w dół razem? Jeśli update rdzenia zepsuje jedną – zepsuje wszystkie. Multisite akceptuje to ryzyko. Osobne instalacje – nie.

Tabela decyzyjna

Scenariusz	Rekomendacja	Powód
Strona PL + EN + DE tej samej marki	Multisite subfolders	Jeden design, ten sam zespół, hreflang łatwiejszy
Blog korporacyjny + portal rekrutacyjny + landing produktu	Osobne	Różne cele, różne zespoły, różne stacki wtyczek
Franczyza 30 restauracji, wspólny brand	Multisite domain mapping	Spójny design, lokalny content, centralne aktualizacje
E-commerce + blog edukacyjny + forum	Osobne	WooCommerce + forum + blog = bardzo różne stacki
10 mikro-stron kampanijnych na 3 miesiące	Multisite	Szybki setup, wspólny template, centralny deploy
SaaS B2B + dokumentacja + marketing site	Osobne, w tym część nie-WP	Dokumentacja lepiej w docs.* (Mintlify, GitBook), marketing w WP
Portal medialny z 5 redakcjami	Multisite subfolders	Spójne SSO, wspólne role, jedna biblioteka mediów

SEO w multisite — czy naprawdę gorsze?

Przez lata multisite miał reputację „słabszego SEO”. To mit wynikający z trzech realnych problemów, które w 2026 są rozwiązane: brak natywnego hreflang (dziś ogarnia to RankMath Multisite i Yoast Premium), współdzielona konfiguracja SEO (naprawione) i trudniejsza integracja z Search Console (dziś każdy site można zarejestrować osobno). Szczegóły technicznej konfiguracji znajdziecie w WordPress dla SEO 2026.

Autorytet domeny — kluczowy argument

Subfolders multisite (marka.com/de/) dziedziczą autorytet domeny głównej. Subdomeny (de.marka.com) – częściowo (Google traktuje je jako „tą samą organizację”, ale osobne właściwości). Osobne domeny (marka.de) – startują od zera, budują autorytet osobno. Dla 90% scenariuszy międzynarodowych subfolders w multisite są najlepsze – to ta sama logika, co dla wielojęzycznych sklepów e-commerce.

Hreflang i canonical

W 2026 hreflang w multisite działa wtedy, gdy używacie wtyczek klasy Multilingual Press, WPML z multisite, lub RankMath Pro z modułem multisite. Nie próbujcie ręcznie – konfiguracja hreflang dla 3+ języków to gigabity pułapek (self-referencing, x-default, kody regionalne). Plugin za 99–399 USD/rok zwraca się w miesiąc tańszej pracy devopsa.

Indeksacja i Search Console

Każda strona w multisite to osobna property w Search Console. Przy 20 stronach to 20 verifikacji, 20 sitemap, 20 dashboardów. Narzut – 4–6 godzin początkowo, 1–2 godziny miesięcznie na audyt. Alternatywnie – Looker Studio dashboard agregujący dane ze wszystkich GSC API w jeden widok. Więcej o integracjach API – w artykule Headless WordPress: czy warto w 2026, który pokazuje, jak te same dane trafiają do innego frontendu.

Ekonomia — realne koszty w PLN

Teoria teorią, ale wybór zapada na podstawie rachunków. Pokażemy trzy scenariusze – 3 strony, 10 stron, 50 stron – z kosztem multisite i osobnych instalacji w skali 36-miesięcznej.

Scenariusz 1 — 3 strony brandingowe

3 strony, każda 50k UU/mc, łącznie 150k UU/mc. Multisite: 1 hosting enterprise (SiteGround GoGeek / Cloudways 4GB) – 300–600 PLN/mc, licencje pro (RankMath Pro, WPML) – 200 PLN/mc, wsparcie dev – 800 PLN/mc. Suma: 1 300–1 600 PLN/mc = 46 800–57 600 PLN / 36 mc.

Osobne: 3× hosting średni (100–200 PLN/mc każdy) = 300–600 PLN/mc, licencje × 3 = 450 PLN/mc (zakładając pakiet na 3 strony), wsparcie 3× strony = 1 800 PLN/mc. Suma: 2 550–2 850 PLN/mc = 91 800–102 600 PLN / 36 mc.

Różnica: 45 000 PLN na korzyść multisite w 3 lata. Przy 3 stronach multisite jest już opłacalny – ale marginalnie. Break-even przy 2 stronach multisite ma sens, gdy strony naprawdę dzielą stack.

Scenariusz 2 — 10 stron franczyzy

10 stron franczyzy, każda 10–30k UU/mc. Multisite: hosting enterprise Cloudways 16GB – 800–1 200 PLN/mc, licencje – 400 PLN/mc, dev – 2 500 PLN/mc. Suma: 3 700–4 100 PLN/mc = 133 000–147 000 PLN / 36 mc. Plus onboarding 12 000 PLN jednorazowo.

Osobne: 10× managed WP (SiteGround StartUp 40 PLN/mc) = 400 PLN/mc, licencje × 10 = 1 000 PLN/mc, dev równoległy – 5 000 PLN/mc (dziesięciokrotnie więcej aktualizacji, backupów, monitoringu). Suma: 6 400 PLN/mc = 230 000 PLN / 36 mc.

Różnica: 95 000 PLN na korzyść multisite. Przy 10 stronach multisite jest bezkonkurencyjny – o ile franczyza faktycznie dzieli design i wtyczki.

Scenariusz 3 — 50 mikrostron kampanijnych

Tu multisite wygrywa tak samo, jak LAN wygrywa z dial-upem. 50× osobne instalacje – niewykonalne operacyjnie, nie chodzi nawet o koszt hostingu. Multisite z szablonem master pozwala uruchamiać kolejną stronę w 15 minut; osobne instalacje – godziny konfigu per strona. Tutaj decyzja nie jest ekonomiczna, jest operacyjna.

Pułapki multisite, których nie znajdziecie w dokumentacji

Dokumentacja WordPress pokazuje happy path. Produkcja pokazuje 20 pułapek, które realnie kosztują czas i pieniądze.

Pułapka 1 — aktualizacja zepsuje wszystko naraz

Wtyczka w multisite jest aktywowana per site, ale kod jest jeden. Aktualizacja zepsuta w wersji 3.4 psuje 20 stron jednocześnie. Rozwiązanie – staging environment z produkcyjnym kopią bazy, obowiązkowe testy regresyjne przed push. Zespół z multisite musi mieć proces CI/CD, bo „szybki hotfix na produkcji” tu nie istnieje.

Pułapka 2 — user management i role

Admin sieci widzi wszystko. Admin strony – tylko swoją stronę. Role między stronami nie są domyślnie spójne – user może mieć różne role na różnych stronach. Plugin typu WP Multisite User Sync rozwiązuje to, ale wymaga konfiguracji. Bez tego – 30 redaktorów z chaotycznymi uprawnieniami.

Pułapka 3 — media i CDN

Każdy site ma osobną bibliotekę mediów. Jeśli chcecie współdzielić logo firmy między 20 stronami, nie – musicie wgrać 20 razy albo użyć wtyczki typu Network Media Library. CDN konfiguracja – globalna dla całej sieci, więc albo wszyscy na tym samym CDN, albo żaden.

Pułapka 4 — backup i restore pojedynczej strony

Klasyczny backup robi dump całej bazy danych. Restore jednej strony wymaga selektywnego przywracania tabel wp_N_*. Standardowe pluginy backup (UpdraftPlus, BackupBuddy) radzą sobie z tym różnie – przetestujcie restore przed awarią, nie po.

Pułapka 5 — performance bottleneck

Jedna baza danych dla 50 stron to jedna baza danych pod obciążeniem. Slow query na jednej stronie wpływa na wszystkie. Object cache (Redis/Memcached) i dobre indeksy to nie „nice to have” – to warunek koniecznego działania powyżej 10–15 stron.

Migracja — jak przejść z osobnych na multisite (i odwrotnie)

Migracja to 2–8 tygodni pracy, w zależności od skali. Pokażemy framework, który zadziała w 90% przypadków. Pełny protokół migracji domen znajdziecie w dedykowanym artykule migracyjnym.

Z osobnych na multisite — 6 kroków

1. Audyt stacku – listujcie wszystkie wtyczki, motywy, custom code na każdej stronie. Jeśli są konflikty (2 strony wymagają innej wersji WooCommerce) – multisite niemożliwy bez harmonizacji.
2. Standaryzacja – ujednolicacie wtyczki, motywy, wersje PHP. Im więcej wspólnego – tym łatwiej.
3. Staging multisite – postawcie pustą instalację multisite na stagingu, przetestujcie core functionality.
4. Import per site – użyjcie pluginu typu All-in-One WP Migration z wariantem Multisite. Każda strona wchodzi jako nowy site w sieci.
5. Rewrite rules i redirects – stare URLs muszą kierować 301 na nowe (jeśli zmieniacie strukturę). Bez redirects – utrata ruchu 40–70%.
6. Gradual cutover – nie przełączajcie 10 stron jednej nocy. Jedna strona per tydzień, obserwacja analytics, rollback plan.

Z multisite na osobne — kiedy warto

Odwrotna migracja ma sens tylko wtedy, gdy jeden lub dwa site’y w sieci rosną znacznie szybciej niż reszta i wymagają własnej optymalizacji. Przykład: multisite z 20 blogami korporacyjnymi, z czego jeden zrobił 500k UU/mc i potrzebuje dedykowanego hostingu + CDN. Wyciągnięcie tego jednego jako osobnej instalacji to 1–3 tygodnie pracy, ale zwraca się w lepszym performance dla flagowej strony.

Zarządzanie uprawnieniami i bezpieczeństwem

W multisite bezpieczeństwo jest jednocześnie prostsze i trudniejsze. Prostsze – bo jedna instalacja to jeden punkt aktualizacji, jedna konfiguracja firewalla, jeden WAF. Trudniejsze – bo kompromitacja jednego site’u może być wektorem do całej sieci, jeśli atak wykorzysta lukę na poziomie kodu współdzielonego.

Model ról w multisite

WordPress multisite wprowadza dodatkowe role ponad standardowe: Super Admin (pełna kontrola sieci, w tym dodawanie/usuwanie stron), Administrator (pełna kontrola jednej strony, ale nie sieci), i dalej Editor / Author / Contributor / Subscriber per strona. Kluczowa zasada – Super Admin powinien być 1–2 osób, nie 10. Dla multi-brand organizacji rekomendacja to jeden Super Admin techniczny (CTO/Head of Eng) i jeden awaryjny, a redaktorzy poszczególnych marek to Administrators na swoich stronach.

Izolacja danych między site’ami

Dane każdej strony są w osobnych tabelach bazy, ale admin jednej strony nie widzi danych innej – chyba że jest Super Administrator. Dla GDPR i DPIA ważne – dane osobowe użytkowników są współdzielone w tabeli wp_users (wszystkie site’y widzą wszystkich userów, jeśli są do nich przypisani). Jeśli mamy 10 marek z osobnymi bazami klientów, to multisite wymaga dodatkowej konfiguracji – osobne systemy auth (np. WooCommerce per site + osobne accounty) lub migracja do osobnych instalacji.

WAF i firewall — jeden czy per site

WAF (Cloudflare, Sucuri, Wordfence) w multisite jest konfigurowany globalnie dla całej instalacji. To oznacza, że reguły blokowania IP, rate limiting, reguły na geolokalizację są wspólne. Dla większości firm to korzyść – jedna polityka, jeden monitoring. Dla firm wielobrandowych z bardzo różnym profilem ruchu (B2B software + B2C lifestyle) – może być ograniczeniem. Tuning WAF dla uśrednionego profilu ruchu pogarsza jakość detekcji.

Performance w multisite — co trzeba wiedzieć

Performance jednej instalacji obsługującej 20 stron jest mierzalny na poziomie Core Web Vitals każdego site’u osobno – ale wąskie gardła są współdzielone. Baza danych, PHP workers, object cache – wszystko to zasoby dzielone między stronami.

Object cache — warunek skalowania

Redis lub Memcached z object cache dla WordPress jest niezbędny powyżej 5 stron w multisite. Standardowo każde zapytanie do bazy danych wymaga otwarcia połączenia, serializacji/deserializacji, zapytania SQL, przetworzenia wyniku. Object cache przechowuje wynik w RAM – kolejne zapytanie o tę samą daną to microsecond zamiast 5–50 ms. Dla strony z 30 zapytań bazowych na request to różnica 150–1500 ms na TTFB.

MariaDB/MySQL tuning

Konfiguracja domyślna MariaDB/MySQL jest zaprojektowana na małe bazy danych. Dla multisite z 20+ stronami potrzebne są inne parametry: innodb_buffer_pool_size na 60–70% dostępnego RAM, query_cache_type = 0 (query cache był odpięty w nowszych MariaDB jako kontrproduktywny), innodb_flush_log_at_trx_commit = 2 dla lepszego write throughput (z akceptowalną utratą 1s danych przy crash). Agencja hostingowa klasy enterprise konfiguruje to domyślnie; shared hosting – nie.

CDN i cache na poziomie Nginx/Varnish

Powyżej 10 stron w multisite warto dodać drugą warstwę cache’u – Nginx FastCGI Cache lub Varnish przed PHP. To zmniejsza obciążenie PHP workers o 70–90% dla ruchu anonimowego (bez zalogowania). Kluczowe – cache invalidation musi być świadoma multisite, bo publikacja posta na stronie #5 nie może wyczyścić cache dla stron #1–20. Pluginy klasy LiteSpeed Cache radzą sobie z tym natywnie w multisite.

Multisite a headless — hybryda 2026

W 2026 coraz częściej widać stack hybrydowy: WordPress multisite jako backend (CMS + API + auth), Next.js / Astro / Nuxt frontend per strona. To daje maksimum elastyczności – centralne zarządzanie treścią, osobny performance frontend per strona. Porównanie tego podejścia z klasycznym WordPressem w artykule Headless WordPress: czy warto w 2026.

Koszt takiego stacku – wyższy niż czysty multisite o 40–60%, ale niższy niż 20 osobnych Next.js aplikacji o 70%. Sweet spot dla zespołów marketingowych z kompetencjami frontendowymi.

Najczęstsze błędy — czego unikać

• Multisite dla 2 stron – narzut konfiguracyjny większy niż oszczędność. Chyba że jedna jest PL, druga EN, i dzielą 100% wtyczek.
• Multisite z WooCommerce per site i różnymi pluginami – WooCommerce w multisite działa, ale 10 sklepów z różnymi bramkami płatności i regulaminami to pułapka.
• Brak CDN i cache – multisite bez cache to strona, która leży przy 100 concurrent users.
• Auto-update włączony – w multisite auto-update wtyczek to gwarancja outage’u co 2 miesiące. Wyłączcie i testujcie manualnie.
• Różne wersje PHP per site – niemożliwe w multisite. Wszystkie strony na tej samej wersji PHP.
• Strona krytyczna dla biznesu + strony eksperymentalne w jednym multisite – eksperymenty psują core. Oddzielcie.
• Brak monitoringu per strona – awaria jednej strony w multisite może być niewidoczna dla admin sieci, jeśli nie macie monitoring per site.

FAQ — najczęstsze pytania

Czy multisite naprawdę ma gorsze SEO niż osobne instalacje?

W 2026 – nie. Subfolders multisite dziedziczą autorytet domeny (plus dla SEO), hreflang konfigurujecie przez dedykowane wtyczki (RankMath Pro, WPML), Search Console rejestruje każdą stronę osobno. Mit o słabszym SEO wynikał z czasów, kiedy wtyczki SEO nie wspierały multisite dobrze – dziś wspierają.

Ile kosztuje postawienie multisite dla 10 stron od zera?

Setup techniczny – 8 000–20 000 PLN jednorazowo (konfiguracja hostingu, multisite, wtyczek, szablonów). Miesięczne koszty – 3 500–5 000 PLN (hosting enterprise, licencje, utrzymanie). Po 36 miesiącach – suma 150 000–200 000 PLN. Osobne instalacje dla porównania – 230 000–280 000 PLN w tym samym okresie.

Czy można migrować z WordPress.com multisite na self-hosted?

Tak, ale z ograniczeniami. WordPress.com (VIP, Business plan) eksportuje XML per strona. Import do self-hosted multisite wymaga przejścia przez stagingową instalację i przemapowania URL. Cały proces dla 10 stron – 40–80 godzin pracy. Budżet 15 000–30 000 PLN jednorazowo, zakładając średni poziom komplikacji.

Jak multisite radzi sobie z GDPR i danymi osobowymi?

Każda strona ma osobne tabele, więc dane osobowe są technicznie odizolowane – ale w tej samej bazie danych. Dla większości firm to akceptowalne. Dla sektorów regulowanych (finanse, zdrowie) często wymagana pełna izolacja infrastruktury – wtedy osobne instalacje. Konsultujcie z prawnikiem, nie z deweloperem.

Czy Cloudflare działa poprawnie z multisite?

Tak, ale konfiguracja jest globalna dla całej sieci. Jeden Cloudflare account, wszystkie domeny multisite dodane jako osobne zony. Cache rules – per zona. WAF – per zona. Dla multisite na subdomenach lub domain mapping to prostsze niż na subfolders, bo subfolder’y dzielą zonę z root domain.

Jak wygląda aktualizacja PHP w multisite?

Krytyczna operacja. Wszystkie strony w multisite działają na tej samej wersji PHP – nie można wyjątków. Przed aktualizacją PHP (np. z 8.1 na 8.3): pełny staging, testy wszystkich kluczowych wtyczek, testy regresyjne na 3 najważniejszych stronach. Plan cutover 2–4 tygodnie. Bez procesu – awaria na dziesiątkach stron jednocześnie.

Ile stron może obsłużyć jedna instalacja multisite?

Technicznie – tysiące (WordPress.com działa na multisite z milionami stron). Praktycznie dla własnej firmy – do 50–100 stron na jednej instalacji bez problemów performance, przy dobrej konfiguracji hostingu (Redis, PHP OPcache, MariaDB z optymalizowanymi indeksami). Powyżej – warto rozważyć segregację na kilka multisite’ów per region/brand.

Czy WooCommerce działa dobrze w multisite?

Tak, ale z zastrzeżeniami. 2–3 sklepy w multisite – bez problemu, pod warunkiem, że dzielą stack płatności i dostawców. 10+ sklepów – zaczyna być trudne, bo każdy ma swoje podatki, waluty, regulaminy, płatności. Dla ecommerce enterprise często lepsze rozwiązanie – osobne instalacje lub platforma headless (Shopify Plus + WP jako CMS bloga).

Co dalej

Warto kontynuować lekturę od Stack marketingowy 2026: narzędzia, API i automatyzacje, a następnie przejść do WordPress dla SEO 2026: konfiguracja, która przyspiesza — razem dają pełny obraz tematu.