WordPress-päivitys rikkoi sivun: mitä teet nyt ja miten vältät saman

Mitä teen heti, kun huomaan sivun menneen rikki?

01Selvitä, mikä muuttui

Katso WordPressin Päivitykset-sivulta ja Lisäosat-sivulta, mitä on päivitetty. Jos automaattiset päivitykset ovat päällä, WordPress lähettää niistä viestin ylläpitäjän sähköpostiin ja viestissä on lista päivitetyistä lisäosista. Kysy myös webhotellilta, onko palvelimen PHP-versiota vaihdettu. Sekin näyttää omistajan silmin päivitykseltä, joka rikkoi sivun.

02Tyhjennä välimuistit

Jos sivu toimii, mutta näyttää oudolta (asettelu hajonnut, fontit väärin, valikko auki), tyhjennä välimuistilisäosan välimuisti, mahdollinen CDN-välimuisti ja selaimen välimuisti. Päivitetty lisäosa tai teema voi käyttää uusia tyylitiedostoja, kun välimuisti tarjoaa yhä vanhoja.

03Kytke epäilty lisäosa pois päältä

Jos pääset hallintaan, poista käytöstä viimeksi päivitetty lisäosa ja katso, korjaantuuko sivu. Jos et pääse hallintaan, katso ensin ylläpitäjän sähköposti: WordPress lähettää kriittisestä virheestä viestin, jonka linkillä pääsee palautustilaan. Jos viestiä ei tule, lisäosan voi kytkeä pois nimeämällä sen kansion uudelleen kohdassa wp-content/plugins. Tarkemmat ohjeet ovat artikkelissa WordPress-kirjautuminen ei onnistu.

04Älä paina ”päivitä kaikki” uudestaan

Moni yrittää korjata rikkoutunutta sivua päivittämällä loputkin. Se vaikeuttaa syyn löytämistä ja voi viedä tietokantaan muutoksia, joita ei saa enää helposti peruttua. Tee yksi muutos kerrallaan ja tarkista sivu jokaisen jälkeen.

Miten palaan edelliseen toimivaan versioon?

Tapoja on kolme. Valitse se, joka koskee pienintä osaa sivustosta.

Yksittäisen lisäosan vanha versio

WordPress.orgin lisäosasivun lisätiedoista (Advanced View) voi ladata lisäosan aiemman version zip-tiedostona. Sen voi asentaa kohdasta Lisäosat → Lisää uusi → Lataa lisäosa, jolloin WordPress tarjoaa nykyisen version korvaamista ladatulla. Ilmaisille lisäosille on myös WP Rollback -lisäosa, joka tekee saman suoraan hallintapaneelista. Maksullisten lisäosien vanhat versiot ladataan yleensä myyjän sivuilta omalla tilillä.

Varo kuitenkin yhtä asiaa. Osa lisäosista muuttaa päivityksessä myös tietokantaa, esimerkiksi lomake-, verkkokauppa- ja kurssilisäosat. Pelkkä vanha koodi ei silloin välttämättä toimi uuden tietokannan kanssa. Isoissa lisäosissa koko varmuuskopion palautus on usein varmempi tapa.

Koko sivuston varmuuskopio

Webhotellien omat varmuuskopiot palautetaan hallintapaneelista, esimerkiksi cPanelin varmuuskopiotyökalulla. Jos sivulla on varmuuskopiolisäosa, palautus tehdään siitä. Muista, että tietokannan palautus vie sivuston siihen hetkeen, jolloin varmuuskopio otettiin. Kaikki sen jälkeen tulleet lomakeviestit, tilaukset ja muokkaukset katoavat, joten vie ne talteen ennen palautusta.

WordPressin oma automaattinen palautus

WordPress 6.6:sta alkaen automaattisesti päivittynyt lisäosa palautetaan edelliseen versioon, jos se aiheuttaa sivulla kriittisen virheen. Ylläpitäjä saa tästä sähköpostin. Suoja kattaa kuitenkin vain kaatumiset. Se ei huomaa rikki mennyttä ulkoasua, lomaketta, joka ei enää lähetä viestejä, tai verkkokaupan kassaa, joka lakkasi toimimasta. WordPressin ytimen päivityksiä ei kannata perua itse, koska vika on harvoin ytimessä.

Miksi päivitys rikkoo WordPress-sivun?

Patchstackin mukaan 91 prosenttia vuonna 2025 löydetyistä WordPressin tietoturva-aukoista oli lisäosissa ja WordPressin ytimestä löytyi vain kuusi vähäistä aukkoa. Samasta syystä myös päivitysongelmat tulevat yleensä lisäosista. Tavallisimmat syyt ovat nämä:

• Kaksi lisäosaa riitelee keskenään. Kumpikin toimii yksin, mutta uusi versio toisesta ei enää sovi yhteen toisen kanssa.
• Vanha teema tai sivurakentaja, jota ei ole päivitetty samaan tahtiin muun sivuston kanssa.
• Muokattu teema, jonka functions.php-tiedostoon on lisätty koodia. Teeman päivitys voi pyyhkiä muutokset pois, jos niitä ei ole tehty lapsiteemaan.
• Maksullinen lisäosa, jonka lisenssi on päättynyt. Se ei päivity, vaikka muu sivusto päivittyy sen ympärillä.
• Liian iso hyppy kerralla. Jos päivityksiä ei ole tehty vuoteen, kymmenien lisäosien yhtäaikainen päivitys tekee syyllisen etsimisestä hidasta.
• PHP-versio vaihtui samaan aikaan ja vanha koodi ei toimi uudella versiolla. Katso PHP 8.2:n tuki päättyy.

Miten vältän saman ensi kerralla?

1. Varmuuskopio ennen jokaista päivitystä ja se tallennetaan muualle kuin samalle palvelimelle.
2. Päivitä kerran kuussa, älä kerran vuodessa. Pieni muutos on helppo perua, iso ei.
3. Isot lisäosat yksi kerrallaan. Päivitä sivurakentaja, lomakelisäosa ja verkkokauppa erikseen ja katso sivu jokaisen jälkeen.
4. Lue muutosloki, kun versionumeron ensimmäinen numero vaihtuu, esimerkiksi 3.9 → 4.0. Silloin muutoksia on yleensä eniten.
5. Käytä testikopiota, jos webhotellissa on sellainen (staging). Päivitä ensin kopio ja vasta sitten oikea sivu.
6. Automaattiset päivitykset sopivat pienille ja hyvin ylläpidetyille lisäosille. Sivurakentajalle, verkkokaupalle ja muille isoille lisäosille ne kannattaa jättää pois päältä.
7. Testaa päivityksen jälkeen etusivu, tärkeimmät alasivut, mobiilinäkymä ja lähetä testiviesti jokaisesta lomakkeesta.
8. Karsi turhat lisäosat. Poistettu lisäosa ei voi rikkoa mitään.

Jos et halua tehdä tätä itse, WordPress-huolto 79 €/kk + alv sisältää kuukausittaiset päivitykset varmuuskopion jälkeen, tärkeimpien sivujen ja lomakkeen tarkistuksen sekä palautuksen toimivaan versioon, jos päivitys rikkoo jotain (enintään 30 minuuttia). Huolto aloitetaan ajan tasalla olevasta sivustosta. Jos sivusto ei ole ajan tasalla, päivitän sen ensin tuntityönä 75 €/h + alv ja kerron arvion ennen kuin aloitan. Huolto on vapaaehtoinen, eikä siinä ole määräaikaa. Kaikki huoltovaihtoehdot ovat sivulla ylläpito.

Lähteet

1. WordPress Core: Merge Proposal: Rollback Auto-Update. https://make.wordpress.org/core/2024/04/19/merge-proposal-rollback-auto-update/
2. WordPress: Plugins & Themes Auto-Updates. https://wordpress.org/documentation/article/plugins-themes-auto-updates/
3. WordPress: WordPress Backups. https://wordpress.org/documentation/article/wordpress-backups/
4. WordPress Advanced Administration: Upgrading WordPress. https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
5. WP Rollback, WordPress.org. https://wordpress.org/plugins/wp-rollback/
6. Patchstack: State of WordPress Security in 2026. https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
7. PHP: Supported Versions. https://www.php.net/supported-versions.php