Multisite zvolte pro weby se společnou technickou správou, podobným designovým systémem a centrálními pravidly. Nepoužívejte jej jen kvůli jedné administraci, pokud weby potřebují izolovaná data, různé pluginy nebo nezávislá vydání. Před rozhodnutím ověřte kompatibilitu a scénář budoucího oddělení webu.
WordPress Multisite umožňuje provozovat síť více webů v jedné instalaci se společným jádrem, šablonami, pluginy a síťovou správou. Může zjednodušit správu univerzitních pracovišť, franšízových poboček nebo jazykově a organizačně podobných webů. Zároveň však propojuje jejich dostupnost, aktualizace a část bezpečnostního rizika. Nejde automaticky o levnější náhradu za více samostatných instalací.
Rozhodnutí musí vycházet z míry společných pravidel, samostatnosti týmů, dat, domén a budoucího oddělení. Pokud každý web potřebuje jiné pluginy, harmonogram a smluvního vlastníka, síť může vytvořit více koordinace než užitku. Tento článek pomáhá posoudit architekturu před aktivací funkce, kterou je později náročnější rozdělit.
Posuďte společné a nezávislé potřeby
Sepište všechny plánované weby, vlastníky, publikum, domény, jazyky, design a funkce. Označte, co musí být jednotné a co si tým řídí sám. Multisite přináší hodnotu, když centrální správa šablon, pluginů a uživatelských pravidel odpovídá organizaci. Samotná podobná barva nebo stejný hosting nejsou dostatečným důvodem.
Zvažte životní cyklus. Pobočka může být dnes součástí značky, ale později se oddělit nebo prodat. Projekt může potřebovat vlastní harmonogram aktualizací a integrací. U každého webu popište, co se stane při výpadku sítě, bezpečnostním incidentu a exportu. Architektura má podporovat pravděpodobnou budoucnost, nejen dnešní pohodlí správce.
Pochopte sdílení kódu a oddělení obsahu
Weby v síti sdílejí jádro a nainstalovaný kód, zatímco obsahové tabulky jsou logicky oddělené ve společné databázi. Správce sítě povoluje šablony a pluginy, lokální administrátor spravuje svůj web ve stanovených hranicích. Chyba nebo nekompatibilita společného pluginu může ovlivnit více webů najednou, proto vydání vyžaduje reprezentativní test sítě.
Ne všechny údaje se automaticky sdílejí. Centrální služby, lidé nebo média potřebují vlastní zdroj a návrh synchronizace; kopírování příspěvku mezi weby vytváří nezávislé verze. Určete, zda má být údaj globální, lokální nebo zděděný s možností výjimky. Nejasné vlastnictví vede k rozdílným kontaktům a nepředvídatelnému přepisování.
- Společné jádro, šablony a pluginy
- Oddělený obsah jednotlivých webů
- Výslovný model sdílených dat
- Síťový dopad každé aktualizace
Navrhněte domény, uživatele a role
Rozhodněte o subdoménách, adresářích nebo mapovaných vlastních doménách a ověřte DNS, HTTPS, cookies a analytiku. Kanonické URL a sitemap musí každý web generovat podle své domény. Při změně mapování otestujte přihlášení, média a přesměrování. Lokální či stagingové domény nesmějí proniknout do veřejných metadat.
Uživatel může existovat v síti a mít na každém webu jinou roli. Centrální přihlášení zjednodušuje přístup, ale onboarding a offboarding musí pokrýt všechna přiřazení. Síťových super adminů ponechte minimum a chraňte je vícefaktorovým ověřením. Lokální správce nemá automaticky instalovat libovolný kód, což je třeba vysvětlit ještě před zavedením.
Ověřte pluginy, výkon a provoz
Každý kritický plugin musí výslovně podporovat multisite a požadovaný způsob aktivace. Licence může počítat weby samostatně a údaje některých doplňků se ukládají pro celou síť. Testujte formuláře, cache, SEO, překlady, e-maily a integrace na více webech. Aktualizaci nenasazujte jen na základě úspěchu jediné domovské stránky.
Záloha má umožnit obnovu celé sítě i jednotlivých webů podle jejich možností. Monitoring rozlišuje společný výpadek a lokální chybu. Databáze, objektová cache, naplánované úlohy a uploady rostou s celou sítí, proto sledujte jejich kapacitu. Plán řešení incidentů určuje, zda lze problémový web izolovat bez odstavení ostatních.
- Potvrzená kompatibilita s multisite
- Test více reprezentativních webů
- Síťová i lokální obnova
- Monitoring sdílených zdrojů
Připravte migraci dovnitř i ven
Přechod existujících webů do sítě zahrnuje URL, uživatele, média, tabulky pluginů, formuláře a externí klíče. Nejprve vytvořte pilot s nejméně rizikovým reprezentativním webem a projděte celý publikační i obnovovací proces. Konfliktní uživatelská jména a identifikátory nelze řešit pouze importem XML. Migrační mapa potřebuje technické testy i obsahovou kontrolu.
Oddělení webu ze sítě může vyžadovat export jeho tabulek, uploadů, nastavení a uživatelských vazeb do nové instalace. Už při návrhu dokumentujte prefixy, mapované domény, sdílená data a licence. Pokud realistický odchod nelze provést bez nepřiměřeného rizika, Multisite nemusí být vhodný pro organizačně nezávislé projekty.
Časté dotazy
Je WordPress Multisite rychlejší než více instalací?
Ne automaticky. Sdílí kód a může zjednodušit cache či správu, ale celá síť používá společné zdroje a databázi. Výkon závisí na šablonách, pluginech, počtu webů, návštěvnosti a infrastruktuře.
Může mít každý web v síti vlastní doménu?
Ano, při správném mapování domén, DNS a HTTPS. Je třeba otestovat přihlášení, cookies, kanonické URL, e-maily a licence. Konkrétní konfigurace závisí na hostingu a síťové architektuře.
Lze jeden web později oddělit z Multisite?
Dá, ale není to vždy jednoduchý export. Je třeba přenést obsah, média, nastavení, pluginová data a uživatele a přemapovat URL. Scénář oddělení je vhodné zdokumentovat ještě před zavedením sítě.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
