Web nefunguje po aktualizácii WordPress: čo urobiť krok za krokom
WordPress po aktualizácii nefunguje? Väčšina výpadkov má jednu zo štyroch príčin: zaseknutý maintenance mode, plugin-konflikt, nekompatibilná téma alebo nedostatok PHP pamäte. Prvý krok je vždy rovnaký - skontrolujte e-mail administrátora webu. Od verzie WordPress 5.2 systém automaticky deteguje fatálne PHP chyby a okamžite posiela e-mail s recovery odkazom. Vo väčšine prípadov sa na web dostanete späť bez prístupu cez FTP alebo bez zásahu do kódu, ak postup dodržíte v správnom poradí.
Prečo web po aktualizácii WordPress prestane fungovať?
Najčastejšia príčina je nekompatibilita pluginu alebo témy s novou verziou WordPressu alebo PHP. Každá aktualizácia mení časti jadra - a plugin napísaný pre staršie API nemusí s novým bez chyby fungovať. V praxi pri správe webov narážame opakovane na rovnaké scenáre:
- Plugin-konflikt - jeden z nainštalovaných pluginov nie je kompatibilný s novou verziou WP alebo s iným pluginom po aktualizácii.
- Nekompatibilná téma - téma používa zastarané funkcie, ktoré nová verzia WP odstránila alebo zmenila.
- Nedostatok PHP pamäte - aktualizácia navýšila pamäťové nároky a server narazí na limit.
- Prerušená aktualizácia - aktualizácia jadra sa nedokončila (výpadok internetu, timeout), web zostal v maintenance mode.
- Aktualizácia PHP na serveri - hosting zmenil verziu PHP súbežne, niektoré pluginy s novou verziou nefungujú.
Dobrá správa: každý z týchto problémov má overený postup riešenia. Pozrite si tabuľku príznakov, aby ste vedeli, kde začať.
| Príznak na webe | Najpravdepodobnejšia príčina | Prvý krok |
|---|---|---|
| „Briefly unavailable for scheduled maintenance“ - stránka sa nezobrazila | Prerušená aktualizácia, zaseknutý .maintenance súbor | Vymazať .maintenance súbor z koreňa webu |
| „There has been a critical error on this website“ | Fatálna PHP chyba - plugin alebo téma | Skontrolovať e-mail admina, použiť recovery odkaz |
| Biela prázdna stránka (WSOD) | PHP chyba bez recovery e-mailu, alebo PHP memory limit | Zapnúť WP_DEBUG v wp-config.php |
| wp-admin funguje, front-end nie | Problém s témou alebo page-builder pluginom | Prepnúť na predvolenú tému (Twenty Twenty-Five) |
| Web funguje, wp-admin nie | Bezpečnostný plugin, alebo 403 z firewallu | Premenovať plugins/ priečinok cez FTP/správcu súborov |
Prvý krok: recovery mode e-mail od WordPress
Od WordPressu 5.2 platí: ak nastane fatálna PHP chyba, systém okamžite pošle e-mail na adresu administrátora s odkazom na recovery mode. Tento mechanizmus je zabudovaný priamo do jadra - nevyžaduje žiadny plugin ani špeciálne nastavenie.
E-mail má predmet podobný: „Your Site is Experiencing a Technical Issue.“ Obsahuje:
- Popis chyby a súbor, kde nastala (napr. konkrétny plugin).
- Odkaz na recovery mode - špeciálny URL, platný spravidla jeden deň.
Po kliknutí na odkaz sa dostanete do wp-admin v recovery mode. WordPress v tomto mode zablokuje problematický plugin alebo tému len pre vás, ostatní návštevníci stránku stále vidia (prípadne s chybou, no bez toho, aby ste im ublížili ďalšími zásahmi). Deaktivujte plugin, ktorý e-mail uvádza ako zdroj chyby - web sa zvyčajne okamžite obnoví. Celý mechanizmus je popísaný v oficiálnej dokumentácii WordPress recovery mode.
Ak e-mail neprišiel alebo ste ho nenašli, pozrite spam. Ak ani tam nie je, e-mailová adresa na stránke Nastavenia → Všeobecné nemusí byť správna - a to je signál, že treba skontrolovať aj nastavenie e-mailov na webe. Viac o komplexnej správe WordPress webu nájdete v komplexnom sprievodcovi správou WordPress webu.

Web sa zasekol v maintenance mode - ako to opraviť za dve minúty
Príznak je jasný: stránka zobrazuje hlásenie „Briefly unavailable for scheduled maintenance. Check back in a minute.“ Ak toto hlásenie trvá dlhšie ako niekoľko minút, aktualizácia sa prerušila a web zostal zaseknutý.
Počas každej aktualizácie jadra, pluginu alebo témy WordPress dočasne vytvorí súbor .maintenance v koreňovom adresári webu. Po úspešnom dokončení aktualizácie ho automaticky vymaže. Ak sa aktualizácia prerušila - napríklad výpadkom spojenia, timeoutom na serveri, alebo súbežnou aktualizáciou viacerých pluginov - súbor zostane a web sa nezotaví sám.
Postup: vymazanie .maintenance súboru
- Prihláste sa do Správcu súborov (File Manager) v cPanel vášho hostingu, alebo pripojte sa cez FTP.
- Prejdite do koreňového adresára WordPressu (zvyčajne
public_html/alebo priečinok s názvom domény). - Zobrazte skryté súbory (súbory začínajúce bodkou sú predvolene skryté - v cPanel zvoľte „Show hidden files“).
- Nájdite súbor
.maintenancea vymazajte ho. - Načítajte web v prehliadači - mal by fungovať okamžite.
Ak súbor vymažete, no web ďalej zobrazuje chybu, aktualizácia sa skutočne nepodarila a príčina je inde. Pokračujte nasledujúcimi krokmi - problém môže byť v konflikte pluginu.
„Critical error“ alebo biela obrazovka: ako zapnúť debug mód
Ak web zobrazuje „There has been a critical error“ alebo prázdnu bielu stránku a recovery e-mail neprišiel, treba zistiť presnú PHP chybu. WordPress má zabudovaný debug mód, ktorý sa aktivuje pridaním konštánt do súboru wp-config.php.
Otvorte wp-config.php v správcovi súborov alebo cez FTP a tesne pred riadok /* That's all, stop editing! */ vložte:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Zoznam všetkých dostupných debug konštánt nájdete v dokumentácii WordPress ladenia.
Nastavenie WP_DEBUG_DISPLAY false zabezpečí, že chyby sa nezobrazujú priamo na stránke pre návštevníkov - zapisujú sa len do logovacieho súboru wp-content/debug.log. Otvorte tento súbor a hľadajte prvý riadok začínajúci Fatal error alebo PHP Fatal error. Ten riadok vám povie presne, ktorý plugin alebo funkcia spôsobila problém.
Po diagnostike nezabudnite debug mód vypnúť - nastavte WP_DEBUG späť na false alebo riadky vymažte. Ladenie na produkcii by malo trvať len nevyhnutný čas.
Špeciálny prípad: PHP memory limit
Ak debug.log obsahuje hlásenie Allowed memory size of ... bytes exhausted, príčina nie je plugin-konflikt ale nedostatok PHP pamäte. Riešenie je navýšiť limit priamo v wp-config.php vložením riadku define( 'WP_MEMORY_LIMIT', '256M' ); pred záverečný komentár. Ak hostingový plán neumožňuje navýšiť PHP pamäť na aspoň 256 MB, problém sa bude vracať po každej väčšej aktualizácii - to je signál, že web narástol a plán je poddimenzovaný.
Ako nájsť problematický plugin alebo tému: krok za krokom
Keď debug.log ukáže meno pluginu alebo viete, že príčina je v plugine, ale neviete ktorom, postupujte systematicky. Cieľom je izolovať vinníka bez toho, aby ste zbytočne zasahovali do databázy alebo nastavení.

Keď máte prístup do wp-admin
- Prejdite na Pluginy a deaktivujte všetky pluginy naraz (zaškrtnite všetky, Hromadná akcia → Deaktivovať).
- Skontrolujte, či web funguje. Ak áno, plugin-konflikt je potvrdený.
- Aktivujte pluginy jeden po jednom a po každej aktivácii skontrolujte web.
- Keď sa chyba vráti, práve aktivovaný plugin je vinníkom.
- Nechajte ho deaktivovaný, skontaktujte autora pluginu alebo hľadajte alternatívu.
Keď nemáte prístup do wp-admin (len FTP alebo správca súborov)
- Cez FTP alebo správca súborov prejdite do
wp-content/. - Premenujte priečinok
plugins/naplugins-off/. WordPress všetky pluginy automaticky deaktivuje. - Skontrolujte web. Ak funguje, príčina je v niektorom plugine.
- Premenujte priečinok späť na
plugins/. - Teraz v
plugins/premenujte jednotlivé podpriečinky pluginov (každý plugin má vlastný podpriečinok), kým nájdete vinníka.
Ak deaktivácia všetkých pluginov nepomôže, problém môže byť v téme. Premenujte priečinok aktívnej témy (napr. themes/nazov-temy/ na themes/nazov-temy-off/) - WordPress automaticky aktivuje predvolenú tému a web by mal fungovať. Pre väčší prehľad o bezpečnom postupe aktualizácií - vrátane toho, ako používať staging prostredie - odporúčame článok o aktualizáciách WordPress bez rizika rozbitia webu.
V praxi pri spravovaných weboch vidíme, že najčastejší vinníci sú bezpečnostné a SEO pluginy - majú tendenciu reagovať na zmeny v jadre ostrejšie ako bežné funkčné pluginy. Ak neviete, čo ste naposledy aktualizovali, pozrite si v časti Pluginy stĺpec „Posledná aktualizácia" - pluginy aktualizované v ten istý deň sú prvými kandidátmi na kontrolu.
Kedy siahnuť po zálohe a ako postupovať
Záloha je posledná záchrana - a zároveň najrýchlejší spôsob, ak viete, že záloha existuje a je aktuálna. Ak site-context webu je komplex s množstvom pluginov, vlastných úprav alebo WooCommerce objednávok a diagnostika trvá, niekedy je rýchlejšie obnoviť zálohu spred aktualizácie ako hľadať vinníka.
V praxi to znamená mať zálohu nie staršiu ako 24 hodín pred každou veľkou aktualizáciou. Podrobne sme zálohovaciu stratégiu - vrátane pravidla 3-2-1 a testovania obnovy - opísali v článku o zálohovacích WordPress stratégiách. Ak záloha neexistuje a web nefunguje, môžete sa dostať do situácie, keď bude potrebná ručná oprava databázy alebo kódu - čo je práca pre odborníka.
Prevencia: prečo sa to stáva a ako tomu predchádzať
Výpadok po aktualizácii nie je smola - je to symptóm toho, že web nemá nastavený bezpečný update-proces. V praxi pri spravovaných weboch vidíme, že weby bez testovacieho (staging) prostredia majú podstatne vyšší výskyt problémov po aktualizáciách ako weby so správne nastaveným procesom.
Tri opatrenia, ktoré problémy po aktualizáciách takmer eliminujú:
- Záloha pred každou aktualizáciou. Databáza aj súbory. Vždy pred, nie po.
- Aktualizujte postupne, nie všetko naraz. Jadro zvlášť, pluginy po jednom - tak viete presne, čo spôsobilo problém, ak nastane.
- Staging prostredie pre dôležitejšie weby. Aktualizáciu najprv otestujete na kópii webu, potom prenesiete na produkciu. Pre weby s e-shopom alebo vlastnými úpravami je to štandard. Viac o bezpečnostnom nastavení WordPress webu nájdete v 10-bodovom checklistoch bezpečnosti WordPress.
Záver: keď si s opravou neviete rady
Väčšina výpadkov po aktualizácii WordPress sa dá vyriešiť vlastnými silami - recovery e-mail, .maintenance súbor, plugin-deaktivácia. Ak sa po prejdení všetkých krokov web neobnoví, problém môže byť hlbší: nekompatibilný vlastný kód, poškodená databáza alebo konflikt na úrovni servera. V takom prípade má zmysel zveriť opravu odborníkovi.
Ak chcete mať istotu, že aktualizácie webu prebehajú bez výpadkov - aj do budúcna - v rámci mesačnej podpory a starostlivosti o web robíme zálohy pred každou aktualizáciou, testujeme na stagingu a opravujeme prípadné konflikty skôr, ako ich uvidia návštevníci. Nezáväzná konzultácia - radi povieme, či váš web potrebuje takúto starostlivosť.
Časté otázky.
Prečo WordPress zobrazuje hlásenie „There has been a critical error on this website“?
Toto hlásenie WordPress zobrazí, keď nastane fatálna PHP chyba - najčastejšie spôsobená nekompatibilným pluginom alebo témou. Od verzie 5.2 WordPress automaticky posiela e-mail administrátorovi s recovery odkazom, cez ktorý sa dostanete do wp-admin a problematický plugin deaktivujete.
Ako sa dostanem do wp-admin, keď web po aktualizácii nefunguje?
Najrýchlejšia cesta je recovery odkaz z e-mailu od WordPress. Ak e-mail neprišiel, prihláste sa cez hosting do správcu súborov a premenujte priečinok wp-content/plugins/ na plugins-off/ - WordPress deaktivuje všetky pluginy a wp-admin by mal byť dostupný.
Ako dlho trvá, kým web opustí maintenance mode po aktualizácii?
Ak sa aktualizácia podarila, trvá to niekoľko sekúnd. Ak web zostane v maintenance mode dlhšie, aktualizácia sa prerušila a .maintenance súbor v koreňovom adresári sa nevymazal automaticky - musíte ho vymazať ručne cez FTP alebo správcu súborov.
Oplatí sa aktualizovať všetky pluginy naraz?
Nie. Keď aktualizujete pluginy po jednom a po každej aktualizácii otestujete web, pri probléme okamžite viete, ktorý plugin ho spôsobil. Hromadná aktualizácia je rýchlejšia, no pri výpadku musíte hľadať vinníka medzi všetkými naraz aktualizovanými pluginmi.
Čo robiť, keď záloha neexistuje a web nefunguje?
Postupujte diagnosticky: zapnite WP_DEBUG v wp-config.php, identifikujte chybový súbor v debug.log, deaktivujte problematický plugin cez FTP. Ak sa web neobnoví ani po deaktivácii všetkých pluginov a prepnutí témy, príčina môže byť v poškodenej databáze alebo vlastnom kóde - v takom prípade odporúčame odborníka.