WordPress Multisite vagy külön telepítések: melyiket válaszd több oldalhoz

Scheo · 2026-09-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha több weboldalt üzemeltetsz, mert a cégednek több márkája, több telephelye vagy több nyelvi változata van, előbb-utóbb felmerül a kérdés: egy WordPress Multisite hálózatba szervezd az oldalakat, vagy mindegyik kapjon saját, független telepítést? Elsőre technikai részletnek tűnik, valójában évekre meghatározza, mennyi munkával jár a frissítés, mi történik egy hibás bővítmény után, és mekkora munka lesz egy márka későbbi eladása vagy leválasztása.

A cikkben három jelölést használok: Hivatalosan igazolt (a WordPress vagy a Google hivatalos dokumentációjából), Saját tapasztalat (üzemeltetési gyakorlatból származó, általános megfigyelés) és Szakmai feltételezés (logikus következtetés, amit érdemes a saját helyzetedre ellenőrizni).

Mi a különbség a WordPress Multisite és a külön telepítések között?

A Multisite egyetlen WordPress-kódbázisból és egyetlen adatbázisból futtat több oldalt, közös bővítmény-, sablon- és felhasználókezeléssel. Külön telepítésnél minden oldalnak saját fájljai, saját adatbázisa és saját adminfelülete van.

Hivatalosan igazolt: a Multisite a WordPress 3.0-s verziója óta a rendszer beépített része, a korábbi WordPress MU beolvasztásával jött létre. A bekapcsolásához a wp-config.php fájlba a define( 'WP_ALLOW_MULTISITE', true ); sor kerül, majd az Eszközök menüben megjelenő Hálózat beállítása lépés után további konstansokat (például MULTISITE és SUBDOMAIN_INSTALL) és módosított átírási szabályokat kell elhelyezni.

A hálózatban ezek közösek:

• Kódbázis: egy WordPress-mag, egy wp-content/plugins és egy wp-content/themes mappa.
• Felhasználók: a wp_users és a wp_usermeta tábla az egész hálózaté, a szerepkör viszont aloldalanként adható.
• Adatbázis: egy adatbázis, amelyben minden aloldal saját, sorszámozott előtagú táblakészletet kap (wp_2_posts, wp_2_options és így tovább).
• Szuperadminisztrátor: bővítményt és sablont csak ő telepíthet, az egyes oldalak adminisztrátorai csak azt kapcsolhatják be, amit a hálózat engedélyez.

A feltöltött médiafájlok aloldalanként külön mappába kerülnek (wp-content/uploads/sites/2/), a WordPress 4.5 óta pedig külön bővítmény nélkül is rendelhető saját domain egy aloldalhoz.

Mikor jó választás a Multisite?

Akkor, ha az oldalak felépítése, bővítménykészlete és szerkesztői köre nagyrészt azonos, és reálisan így is marad.

Tipikus helyzet egy franchise-hálózat vagy egy több városban működő szolgáltató, ahol minden telephelynek ugyanaz a sablonja és ugyanazok az aloldalai (szolgáltatások, csapat, kapcsolat, nyitvatartás), csak a tartalom és a helyi adatok térnek el. Ilyenkor a Multisite valódi előnyt ad:

• egy frissítés egyszerre érvényesül minden oldalon;
• egy új telephely oldala gyorsan létrehozható a meglévő minta alapján;
• a központi marketingcsapat egy belépéssel éri el az összes oldalt;
• a sablonon végzett javítás (például egy akadálymentességi hiba) mindenhol egyszerre javul.

Saját tapasztalat: a Multisite ott működik gördülékenyen, ahol van egy felelős, aki eldönti, mi kerülhet a hálózatra, és ahol az aloldalak gazdái elfogadják, hogy nem telepíthetnek maguknak bármit. Ha ez a fegyelem hiányzik, a hálózat hamar kompromisszumok halmazává válik.

Mikor jobb a külön telepítés?

Ha az oldalak felépítése eltér, más bővítményeket igényelnek, más csapat szerkeszti őket, vagy reális, hogy valamelyik márka később önállóvá válik.

Gondolj egy cégre, amelynek van egy bemutatkozó oldala, egy WooCommerce-webshopja és egy foglalási rendszerrel működő szolgáltatási oldala. Ezeknek alig van közös pontjuk: a webshop erőforrásigényes, a foglalási oldal naptár- és fizetési bővítményeket használ, a bemutatkozó oldalhoz pedig néhány alapbővítmény is elég. Hálózatban minden bővítmény kódja ott van mindenhol, a webshop terhelése pedig a másik két oldal sebességére is hathat, hiszen ugyanazon a szerveren és ugyanazon az adatbázison osztoznak.

Szakmai feltételezés: minél több a kivétel (ezen az oldalon kell ez a bővítmény, azon nem; ennek a márkának más a kosara), annál kevesebb marad a Multisite fő előnyéből, a közös kezelésből, miközben a közös kockázat változatlanul megmarad.

A külön telepítés mellett szól az is, ha egy márkát külső ügynökség vagy partner kezel. Multisite-on nehéz neki úgy technikai hozzáférést adni (tárhely, adatbázis, FTP), hogy közben a többi oldalhoz ne férjen hozzá.

Hogyan hasonlít össze a két megoldás a döntési szempontok szerint?

A Multisite az üzemeltetési terhet csökkenti, a külön telepítés a közös kockázatot és a későbbi kötöttséget. Az alábbi döntési táblázat szempontonként mutatja a két oldalt.

• Üzemeltetési teher. Multisite: egy frissítési kör, egy mentési feladat, egy biztonsági felület. Külön telepítés: minden oldalt külön kell frissíteni, bár központi eszközzel (WP-CLI-szkript, távoli kezelőpanel) ez sokat egyszerűsödik.
• Hibák tovagyűrűzése. Multisite: egy hálózati szinten aktivált, hibás bővítményfrissítés vagy egy végzetes PHP-hiba jó eséllyel minden oldalt leállít, egy sérülékeny bővítmény pedig a teljes adatbázist veszélyezteti. Külön telepítés: a hiba jellemzően az adott oldalon marad, ha a tárhelyfiókok is el vannak választva.
• Mentés és visszaállítás egyetlen aloldalra. Multisite: sok mentőmegoldás a teljes hálózatot menti, egyetlen aloldal visszaállítása táblaszintű kézi munka (a wp_N_ táblák és a sites/N mappa), a közös felhasználói táblák miatt óvatosan. Külön telepítés: egy oldal mentése és visszaállítása önálló, egyszerű művelet.
• SEO-szempontok. Multisite: a látogató és a kereső a kiszolgált oldalakat látja, nem a telepítés módját; a kötöttség inkább abban van, hogy a SEO-bővítmény hálózati beállításai és verziója közösek. Külön telepítés: minden oldal teljesen egyedi beállítást, bővítményt és gyorsítótárazást kaphat.
• Tárhelyigény. Multisite: egy mag és egy adatbázis, kevesebb fájl; a terhelés viszont összeadódik, és egy erőforrásigényes oldal lassíthatja a többit. Külön telepítés: minden oldal saját maggal fut, több a fájl, de az erőforrások oldalanként oszthatók.
• Közös felhasználók. Multisite: egy fiók több oldalhoz, egy helyen tiltható a kilépő munkatárs. Külön telepítés: oldalanként külön fiók, a hozzáférések kezelése több lépés.
• Későbbi kiválás. Multisite: táblaexport, előtag-átnevezés, felhasználók szétválogatása, médiaáthelyezés, URL-csere, teljes tesztelés. Külön telepítés: a telepítés egyben átadható másik tárhelyre vagy új tulajdonosnak.

Hivatalosan igazolt: a WordPress dokumentációja külön felhívja a figyelmet, hogy nem minden bővítmény működik megfelelően Multisite-on, és nem minden tárhely támogatja a hálózatot (különösen az aldomaines változathoz szükséges wildcard aldomaint).

Mire figyelj SEO-szempontból több márkánál, telephelynél és nyelvnél?

A keresők a megjelenő oldalakat, az URL-eket és a jelöléseket értékelik; a döntő kérdés az URL-szerkezet, a nyelvi jelölés és az, hogy az oldalak ne versenyezzenek egymással ugyanarra a keresésre. A telepítés módja önmagában nem garantál sem jobb, sem rosszabb helyezést.

Aldomain vagy alkönyvtár

Hivatalosan igazolt: hálózat létrehozásakor választani kell az aldomaines (budapest.pelda.hu) és az alkönyvtáras (pelda.hu/budapest/) szerkezet között. Alkönyvtáras hálózatban a fő oldal bejegyzés-URL-jei elé a rendszer egy /blog/ előtagot tesz, hogy ne ütközzenek az aloldalak útvonalaival, és a dokumentáció szerint egy hónapnál régebbi telepítésnél az alkönyvtáras forma a meglévő permalinkek miatt nem is választható. Egy régóta futó oldal hálózattá alakítása tehát URL-változással járhat, amihez átirányítási terv kell.

Több nyelv

Hivatalosan igazolt: a Google Search Central a nyelvi és regionális változatokhoz a hreflang jelölést ajánlja, amelyet minden változatnak kölcsönösen tartalmaznia kell. Ez megoldható egy telepítésen belül fordítóbővítménnyel és Multisite-on is, ahol minden nyelv külön aloldal.

Saját tapasztalat: külön telepítéseknél a hreflang-párok karbantartása kézi munka, és könnyű elrontani, amikor az egyik oldalon megváltozik egy URL. Ha a nyelvi változatok felépítése megegyezik, a közös rendszer (akár egy telepítés, akár hálózat) itt kényelmesebb.

Telephelyek

Szakmai feltételezés: ha a telephelyi oldalak csak a címben és a telefonszámban térnek el, bármelyik megoldással vékony, egymáshoz nagyon hasonló tartalmak keletkeznek, ami nem segíti a láthatóságot. Itt a telepítési döntésnél fontosabb, hogy minden telephely kapjon valódi helyi tartalmat (helyi csapat, megközelítés, helyi szolgáltatási kör). Gyakran egy telepítésen belüli telephelyi aloldalak egyszerűbbek, mint bármelyik hálózati forma.

Hivatalosan igazolt: a Search Console-ban minden domaint vagy aldomaint külön tulajdonként kell hitelesíteni, és külön érdemes beküldeni a webhelytérképét is, függetlenül attól, hogy Multisite vagy külön telepítés van mögötte.

Mennyi munka később leválasztani egy oldalt a hálózatról?

Lényegesen több, mint amennyi beállítást az induláskor megspóroltál, mert a leválasztás táblaszintű adatbázis-műveletet, felhasználó-szétválogatást és teljes körű tesztelést kíván.

Ha egy márkát eladsz, vagy egy partner önállósodik, az oldalát ki kell emelni a hálózatból. A lépések nagy vonalakban:

1. Az aloldal azonosítójának kiderítése, például a wp site list WP-CLI-paranccsal.
2. Az aloldal tábláinak exportja (wp_5_posts, wp_5_postmeta, wp_5_options stb.), és a bővítmények saját, azonos előtagú tábláinak felkutatása.
3. Az előtag átnevezése önálló telepítéshez, beleértve az options táblában a wp_5_user_roles kulcsot, a usermeta táblában pedig a wp_5_capabilities és wp_5_user_level kulcsokat.
4. Csak az érintett felhasználók átvitele a közös felhasználói táblából, az azonosítók megtartásával, különben elcsúszik a bejegyzések szerzői hozzárendelése.
5. A wp-content/uploads/sites/5/ mappa áthelyezése és a hivatkozások cseréje a wp search-replace paranccsal, amely a szerializált adatokat is helyesen kezeli.
6. A hálózati szinten tárolt beállítások (wp_sitemeta) pótlása, mert ezek nem jönnek át az aloldal tábláival.
7. Átirányítások, Search Console, analitika, űrlapok és e-mail-küldés tesztelése.

Saját tapasztalat: leválasztáskor gyakran derül ki, hogy egy bővítmény hálózati licenccel vagy hálózati beállítással működött, és önálló telepítésen újra kell konfigurálni. Emiatt a Multisite akkor jó, ha az oldalak tényleg egyformák. Ha nem azok, a leválasztás később jó eséllyel drágább lesz, mint amennyit az induló kényelem megspórolt.

Mit nézz meg a döntés előtt?

Az oldalak számát, a felépítésük hasonlóságát, a szerkesztői kört, a bővítménylistát és a kiválás valószínűségét. Ezt az ellenőrzőlistát érdemes végigvenni:

• Hány oldal van most, és hány lesz két-három év múlva? Két-három oldalnál a közös kezelés előnye kicsi, sok, szinte azonos telephelyi oldalnál nagyobb.
• Mennyire eltérő a felépítésük? Ugyanaz a sablon, menü és oldaltípus? Ha az egyik webshop, a többi nem, az erős jel a külön telepítés felé.
• Ki fogja szerkeszteni? Egy központi csapat, márkánként más ember, vagy külső ügynökség is?
• Milyen bővítmények kellenek? Listázd oldalanként, és a fejlesztő dokumentációjában nézd meg, támogatják-e a Multisite-ot, és hogyan licencelik hálózati használatra.
• Mennyire valószínű a kiválás? Eladás, partner önállósodása, külön cégbe szervezés.
• Mit tud a tárhelyed? Támogatja-e a hálózatot, a wildcard aldomaint, és hogyan ment?
• Vissza tudsz állítani egyetlen oldalt? Próbáld ki tesztkörnyezetben, mielőtt éles hálózatot építesz.
• Van felelős szuperadminisztrátor? Valaki, aki a hálózati szabályokat betartatja.
• Rendben van az adatkezelés? Szakmai feltételezés: ha a márkák külön cégekhez tartoznak, a közös felhasználói tábla adatkezelési kérdést vethet fel, ezt adatvédelmi szakemberrel érdemes egyeztetni.

Van köztes megoldás a két véglet között?

Igen: külön telepítések, közös eszközökkel kezelve. Így megmarad a függetlenség, és az üzemeltetési teher egy része is csökken.

• WP-CLI-szkript a frissítésekhez, például: for d in /var/www/marka1 /var/www/marka2; do wp --path=$d plugin update --all; done
• Távoli WordPress-kezelő panel (például MainWP vagy ManageWP), amelyből több független oldal frissítése és mentése egy helyről indítható.
• Közös gyereksablon verziókezelésben, amelyet minden oldalra ugyanabból a tárolóból telepítesz.
• Tesztkörnyezet, ahol a frissítés előbb egy oldalon fut le.

Saját tapasztalat: eltérő oldalaknál ez a felállás adja a legjobb egyensúlyt, mert a hibák elszigeteltek maradnak, a rutinfeladatok mégis egy helyről mennek.

Hogyan döntsd el, ha még mindig bizonytalan vagy?

Ha az oldalaid tényleg egyformák, egy felelős kezeli őket, és nem várható kiválás, a Multisite jó eséllyel időt takarít meg. Minden más esetben a külön telepítés a biztonságosabb alap.

Szakmai feltételezés: bizonytalan helyzetben érdemes külön telepítésekkel és közös eszközökkel indulni. Ha az oldalak később valóban egyformává válnak, hálózatba szervezni őket is munka, de kisebb kockázattal jár, mint egy eltérő oldalakból álló hálózatot szétszedni, mert az átállás alatt a meglévő oldalak változatlanul futhatnak tovább.

Források és további olvasnivalók

• WordPress Advanced Administration Handbook: Create a Network
• WordPress Advanced Administration Handbook: Before You Create a Network
• WordPress Developer Resources: Multisite
• WP-CLI Commands dokumentáció (wp site, wp db, wp search-replace)
• Google Search Central: Localized Versions of your Pages (hreflang)
• Google Search Central: Managing Multi-Regional and Multilingual Sites
• Google Search Console Súgó: Webhelytulajdon hozzáadása