WordPress Multisite: Problémy, které vás čekají – a jak je řešit

WordPress Multisite je mocný nástroj. Jedna instalace, desítky nebo stovky webů pod jednou střechou, sdílená databáze, centralizovaná správa. Na papíře ideální řešení pro agentury, vydavatele nebo velké organizace s více subweby.

V praxi? Každý, kdo s Multisite pracuje delší dobu, ví, že se pod tímto slibným povrchem skrývají pasti, na které nenarazíte při správě klasické single-site instalace. Konfigurace serveru, která funguje na Apache, přestane fungovat na Nginx. Klonování webu skončí rozbitými interními odkazy. SEO plugin najednou generuje sitemapu, která neexistuje.

V tomto článku shrnujeme reálné problémy, na které jsme narazili při správě WordPress Multisite pro klientské weby – a hlavně jak jsme je vyřešili.

---

1. Nginx a WordPress Multisite: přátelství plné kompromisů

Apache a WordPress mají dlouhou historii. .htaccess soubory zajistí veškeré přesměrování automaticky – stačí aktivovat modul mod_rewrite a WordPress si zbytek zařídí sám. Jenže Nginx .htaccess nepodporuje. A u WordPress Multisite to začne být docela bolestivé.

Co konkrétně přestane fungovat

Typické problémy na Nginx s Multisite zahrnují:

• Přesměrování podsložek – Multisite v režimu subdirectory (např. example.com/blog/) potřebuje specifická rewrite pravidla. Bez nich Nginx vrací 404 nebo přesměrovává špatně.
• Přihlašovací stránka – wp-login.php a wp-admin napříč weby v síti vyžadují správně nakonfigurované location bloky.
• Sitemap a robots.txt – SEO pluginy jako Yoast nebo RankMath generují sitemapu dynamicky přes PHP (/sitemap_index.xml → rewrite na index.php). Pokud chybí odpovídající location blok v Nginx konfiguraci, server vrátí 404, i když plugin sitemapu technicky generuje správně.

Jak to řešit

Veškerá rewrite pravidla, která by na Apache obsluhoval .htaccess, musí být explicitně definována v konfiguračním souboru Nginx – typicky v server bloku daného webu nebo v sdílené include šabloně pro Multisite.

Příklad konfigurace pro sitemapu: nginx

location ~ ^/sitemap(_index)?\.xml {
    rewrite ^/sitemap(_index)?\.xml$ /index.php?sitemap=$1 last;
}

U každého nového SEO pluginu nebo změny URL struktury je nutné ověřit, zda Nginx konfiguraci odpovídá aktuálnímu stavu – a podle potřeby ji upravit. Automatické řešení neexistuje.

---

2. Klonování webů v Multisite: zdánlivě jednoduchý úkol, ve skutečnosti noční můra

WordPress Multisite nemá nativní funkci pro klonování webů. Žádné tlačítko „zkopírovat web“. Existují pluginy (Duplicator, NS Cloner a další), ale ani ty nepokryjí vše – a na výsledek se nedá slepě spoléhat.

Kde to bolí

Databázové záznamy a ID webu

Každý web v síti má své unikátní ID. Při klonování se ID změní, a to rozbije interní odkazy, nastavení pluginů i přímé reference v databázi, které staré ID obsahují. Řešení? Ruční nebo skriptovaná úprava databázových záznamů po dokončení klonování.

Uživatelé, menu a widgety

Pluginy pro klonování typicky zkopírují obsah – příspěvky, stránky, nastavení šablony. Ale menu, widgety, přiřazení uživatelských rolí a custom databázové tabulky (které si přidávají některé pluginy) se přenáší nekonzistentně nebo vůbec. Každou tuto oblast je potřeba po klonování ověřit a opravit ručně nebo na úrovni databáze.

Mediální soubory

Jsou dvě strategie, obě mají háček:

• Fyzické kopírování souborů – spolehlivé, ale každý klonovaný web zdvojuje spotřebu diskového prostoru.
• Symlinkování – šetří místo, ale při mazání původního webu nebo souborů hrozí rozbití závislostí.

SEO a duplicitní obsah

Po klonování může nový web zdědit metadata (title, description, canonical URL) z původního. To je přímá cesta k duplicitnímu obsahu a penalizaci ve vyhledávačích. Před spuštěním klonovaného webu je nutné:

• Přenastavit title a meta description.
• Aktualizovat canonical URL.
• Ověřit sitemapu.
• Projít obsah a nahradit staré URL za nové.

Bez důkladného testování zůstávají nepřepsané staré URL v obsahu i v nastavení pluginů – a to se projeví až v provozu, nikoliv při přebírání webu.

---

3. SEO pluginy v Multisite: každý web, jiná konfigurace

Yoast SEO a RankMath patří ke standardní výbavě WordPress webů. V Multisite prostředí ale narážejí na specifická omezení, která u single-site instalace neexistují.

Co funguje jinak

Síťová nastavení jsou omezená. Některé funkce SEO pluginů jsou dostupné pouze na úrovni celé sítě, ale jejich konfigurace přes síťový admin panel je omezená nebo neúplná. Každý web v síti potřebuje vlastní SEO konfiguraci – title šablony, meta popisy, schema markup – nastavenou individuálně, případně řízenou přímo v databázi.

Přesměrování a canonical URL. Multisite nemá centrální správu přesměrování. Každý web řeší přesměrování zvlášť, přes vlastní instanci pluginu. To je v pořádku, pokud weby v síti fungují jako oddělené entity – ale při migraci nebo restrukturalizaci sítě to znamená práci na každém webu samostatně.

Sitemap pro celou síť neexistuje. SEO pluginy generují sitemapu pouze pro daný web, nikoliv pro celou síť. Pokud potřebujete centrální sitemap zahrnující všechny weby v síti, máte dvě možnosti:

• Napsat vlastní plugin, který sitemapy agreguje.
• Řešit to na úrovni serveru, skriptem nebo konfigurací, která sitemapy jednotlivých webů propojí do jednoho výstupu.

Výkon u větších sítí. Pokud síť obsahuje desítky nebo stovky webů, dynamické generování sitemapních souborů při každém requestu může zatížit server. Řešení spočívá v optimalizaci na úrovni kódu – cachování, generování sitemapních souborů staticky, nebo omezení frekvence jejich obnovy.

A pak je tu Nginx – jak bylo zmíněno výše: pokud sitemap plugin správně negeneruje rewrite pravidla do .htaccess (protože ta na Nginx nefunguje), musí správce serveru zasáhnout ručně.

---

4. Oprávnění uživatelů: sdílená databáze, rozdílné role

Správa uživatelů v Multisite funguje jinak než v klasickém WordPressu. Databáze uživatelů je sdílená pro celou síť – každý uživatel existuje v systému jednou. Role a přístupy se ale nastavují na úrovni každého webu zvlášť.

Jak to funguje v praxi

Role	Přístup
Super admin	Celá síť, všechny weby, globální nastavení
Admin webu	Jen vlastní web – bez možnosti instalovat pluginy a šablony
Editor, autor…	Standardní WordPress role, omezené na daný web

Klíčový rozdíl oproti single-site: admin webu v Multisite nemůže instalovat pluginy ani šablony. Vše spravuje centrálně super admin. To může být žádoucí z hlediska bezpečnosti, ale v praxi to znamená, že každý požadavek na nový plugin jde přes jednoho správce.

Kde nastávají problémy

Rozbité role po klonování nebo migraci. Role uživatelů jsou uloženy v databázi jako metadata vázaná na ID webu. Po klonování (kdy se ID webu změní) se tyto záznamy přestanou shodovat a uživatelé ztrácejí přiřazené role. Oprava probíhá ručně – buď přes administraci, nebo přímo v databázi.

Matoucí uživatelská zkušenost. Uživatel, který je adminem na webu A a jen editorem na webu B, to nemusí chápat. Neexistuje žádné centrální UI, kde by viděl přehled svých rolí napříč sítí. To generuje zbytečné dotazy na podporu.

Pluginy, které Multisite role neznají. Některé pluginy počítají se standardním WordPress role systémem a v Multisite se chovají nepředvídatelně – ignorují roli super admina, přiřazují oprávnění špatně nebo odmítají fungovat pod admin účtem webu.

---

Závěr: Multisite je mocný nástroj – ale připravte se na práci navíc

WordPress Multisite dokáže výrazně zjednodušit správu velkého množství webů. Sdílená databáze, centralizovaná aktualizace pluginů, jedna instalace místo desítek – to jsou reálné výhody.

Ale jak ukázaly výše popsané zkušenosti z klientských projektů, Multisite přináší specifické výzvy, na které běžná dokumentace ani pluginy nepokryjí:

• Nginx vyžaduje ruční konfiguraci tam, kde Apache funguje automaticky.
• Klonování webů nikdy není „one click“ – vždy vyžaduje manuální ověření a opravy v databázi.
• SEO musí být konfigurováno individuálně pro každý web, centrální správa je omezená.
• Uživatelské role jsou svázány s ID webů a po migraci se mohou rozbít.

Pokud Multisite spravujete nebo plánujete nasadit, počítejte s tím, že technická péče o takovou síť je náročnější než správa ekvivalentního počtu samostatných instalací – a vyžaduje hlubší znalost jak WordPressu, tak serverového prostředí.

---

Máte zkušenosti s WordPress Multisite? Narazili jste na jiné problémy, které tu nejsou zmíněné? Napište nám – rádi článek rozšíříme o další reálné případy.