Mentenanță WordPress: ce înseamnă concret, pe ce ritm și ce te costă dacă o sari

Un site de firmă pe care nu s-a atins nimeni de paisprezece luni. Intri în admin și te întâmpină: 23 de plugin-uri cu actualizări în așteptare, două teme pe care nu le folosește nimeni, un plugin de backup care afișează „ultima copie: acum 11 luni” pentru că a expirat autorizarea către Google Drive și nimeni n-a citit emailul, și un banner care spune că versiunea de PHP a serverului nu mai primește actualizări de securitate.

Site-ul funcționează. Se deschide, formularul trimite mesaje, nimeni nu s-a plâns. Exact ăsta e motivul pentru care nu s-a atins nimeni de el paisprezece luni.

Articolul ăsta răspunde la „ce presupune, de fapt, mentenanța unui site WordPress?” — nu ca listă de vânzare, ci ca listă de treabă: ce se face, cât de des și care dintre lucruri chiar are nevoie de cineva tehnic.

Răspuns scurt

Mentenanța WordPress nu e o activitate, e un ritm:

• Automat, permanent: actualizări automate pentru WordPress Core, backup programat off-site, monitorizare uptime.
• Săptămânal, 10 minute: verifici că backup-ul a rulat, aplici actualizările marcate ca fiind de securitate, citești alertele.
• Lunar, 30–45 de minute: aplici restul actualizărilor (după backup), verifici lista de administratori, erorile 404 și viteza.
• Trimestrial, 1–2 ore: testezi efectiv o restaurare din backup, cureți baza de date, ștergi plugin-urile și temele neutilizate, scanezi linkurile rupte.
• Anual: versiunea de PHP, reînnoirea domeniului, certificatul SSL, un audit real de plugin-uri.

Dacă reții un singur lucru: auto-update-urile de securitate rămân pornite, iar backup-ul se testează, nu doar se face. Astea două fac diferența dintre o problemă de o oră și una de trei săptămâni.

De ce cadență și nu „reparăm când se strică”

Un site WordPress e software conectat permanent la internet: Core, o temă și de obicei 10–30 de plugin-uri, fiecare scris de altcineva. Fiecare primește ocazional o corecție de securitate, iar momentul în care corecția devine publică e și momentul în care problema devine publică — advisory-ul descrie ce anume era stricat. De acolo până la scanare automatizată se măsoară în ore.

Exemplul cel mai apropiat e din luna trecută. Pe 17 iulie 2026, WordPress a lansat 6.9.5 și 7.0.2 și le-a împins forțat prin sistemul de actualizări automate — ceva ce se întâmplă rar. Motivul: un lanț de două vulnerabilități din WordPress Core (CVE-2026-63030 și CVE-2026-60137), care afecta versiunile 6.9.0–6.9.4 și 7.0.0–7.0.1. Am scris pe larg despre incident în articolul despre vulnerabilitatea wp2shell și ce trebuie verificat pe site, așa că nu îl reiau.

Reiau doar cele două concluzii care privesc direct subiectul de față:

1. Site-urile cu actualizări automate pornite au primit corecția în aceeași zi, fără ca proprietarul să facă ceva. Cele cu auto-update dezactivat — de obicei pentru că „o dată s-a stricat ceva după un update” — au rămas expuse exact atât cât a durat până s-a uitat cineva la ele.
2. Actualizarea închide ușa, dar nu scoate din casă pe cine intrase deja. Dacă cineva apucase să creeze un cont de admin înainte de patch, contul rămâne, pe un WordPress perfect actualizat.

Asta e toată logica cadenței. Nu se strică ceva în fiecare săptămână. Dar când se întâmplă, distanța dintre „s-a publicat corecția” și „ai aplicat-o” e singura variabilă pe care o controlezi tu. Verificat săptămânal, intervalul e de ordinul zilelor. Verificat când își amintește cineva, e de ordinul lunilor.

Actualizări: de ce „actualizează tot, imediat” nu e chiar corect

Sfatul standard e „ține tot la zi”. Aplicat literal, produce paguba pe care încearcă să o prevină. Sunt trei categorii diferite, care merită politici diferite.

Core, actualizări minore și de securitate (6.9.4 → 6.9.5): automate, mereu. Sunt corecții punctuale, testate pe milioane de instalări, cu risc de regresie foarte mic. E setarea implicită și nu ai motive bune să o oprești. Verifici în Tablou de bord → Actualizări, unde scrie explicit dacă site-ul primește automat actualizările de întreținere și securitate.

Core, actualizări majore (6.9 → 7.0): merită o pauză de câteva zile și un backup înainte. Schimbă editorul, uneori API-uri, uneori felul în care temele randează conținutul — genul de lucru care poate strica un layout construit cu un page builder mai vechi. Regula practică: aștepți prima versiune de corecție (7.0.1, nu 7.0).

Plugin-uri și teme: aici e nuanța. Un plugin actualizat automat, în mijlocul zilei, fără backup proaspăt, e cea mai frecventă cauză de „mi-a picat site-ul și nu știu de ce”. Un plugin de formular care își schimbă structura, un plugin de cache care intră în conflict cu tema, o extensie WooCommerce care schimbă checkout-ul — toate se întâmplă, și se întâmplă la actualizare.

Politica sănătoasă:

• Actualizările marcate ca fiind de securitate se aplică în aceeași zi, indiferent de program. În descriere scrie de obicei „security fix” sau „security release”.
• Restul se grupează și se aplică o dată pe lună, la o oră cu trafic mic, cu backup făcut cu cinci minute înainte.
• În tranșe mici, nu toate deodată. Cinci plugin-uri, verifici site-ul, încă cinci. Dacă apeși „Update All” pe 23 și site-ul cade, ai 23 de suspecți.
• Verifici după, nu doar homepage-ul: o pagină de serviciu, formularul de contact (trimite-ți un mesaj real) și, dacă vinzi online, o comandă de test dusă până la capăt.
• Ai un plan de revenire. Minim: backup înainte. Curat: aplici întâi pe un mediu de staging, pe care majoritatea hosturilor decente îl oferă cu un click.

Pentru un site de prezentare, actualizarea directă cu backup proaspăt e rezonabilă. Pentru un magazin care ia comenzi zilnic, staging-ul nu e lux — o oră de checkout stricat costă mai mult decât tot efortul.

Backup: un backup netestat nu este un backup

Cea mai frecventă descoperire neplăcută din munca de recuperare nu e că oamenii n-au backup. E că au avut și nu funcționa.

Motivele sunt mereu banale: pluginul s-a oprit acum opt luni pentru că a expirat autorizarea către Dropbox și emailul de eroare a ajuns la spam. Sau salvează doar fișierele, nu și baza de date — adică tot conținutul. Sau salvează complet, dar pe același server cu site-ul, ceea ce ajută la ștergere accidentală și nu ajută deloc când serverul e compromis sau contul de hosting e suspendat.

Un backup pe care te poți baza are patru proprietăți:

1. Complet — fișiere (wp-content în special) plus baza de date. Una fără cealaltă nu reconstruiește nimic.
2. Automat, pe un program fix. Frecvența se alege după cât conținut nou produci: zilnic pentru magazine și bloguri active, săptămânal pentru un site de prezentare care se schimbă de două ori pe an.
3. Off-site, pe alt sistem decât serverul site-ului. Multe hosturi oferă backup la nivel de cont (JetBackup în cPanel, de exemplu) — util, dar e plasă de siguranță secundară, nu singura copie. Contul de hosting și site-ul cad împreună.
4. Testat.

Punctul 4 e cel pe care îl sare toată lumea și singurul care demonstrează ceva. O dată pe trimestru e suficient. Concret, fără risc: creezi un mediu de staging la host (sau instalezi WordPress local), restaurezi ultimul backup acolo, te loghezi, deschizi trei-patru pagini și verifici că imaginile apar și conținutul e la zi. Douăzeci de minute care înlocuiesc o presupunere cu o certitudine.

Plugin-urile clasice sunt UpdraftPlus și All-in-One WP Migration, ambele cu versiuni gratuite care acoperă cazul unui site de firmă; ce plătești, de fapt, e spațiul de stocare și retenția.

Monitorizare uptime: să afli tu, nu clientul

Un site căzut la 2 noaptea, descoperit la 11 dimineața pentru că a sunat un client, înseamnă nouă ore în care Google a primit erori și oricine a căutat firma a găsit o pagină albă.

Un serviciu extern verifică site-ul la câteva minute și îți trimite email sau SMS când nu răspunde. UptimeRobot, BetterStack și HetrixTools au planuri gratuite suficiente pentru câteva site-uri, iar configurarea durează cinci minute și nu cere cunoștințe tehnice.

Două detalii care se ratează: monitorizează și o pagină internă, nu doar homepage-ul (homepage-ul se poate servi din cache și arăta perfect în timp ce restul site-ului dă eroare de bază de date), iar pentru magazine adaugă coșul sau checkout-ul. Și activează verificarea certificatului SSL — majoritatea serviciilor o oferă și te anunță cu săptămâni înainte de expirare.

Versiunea de PHP

WordPress rulează pe PHP, iar versiunile de PHP primesc corecții de securitate câțiva ani, apoi nu mai primesc nimic. Un site pe o versiune ieșită din suport stă pe un fundament care nu se mai repară, oricât de actualizat ar fi WordPress-ul deasupra.

Nu trebuie să ții minte calendarul: Instrumente → Sănătatea site-ului îți spune singur dacă versiunea nu mai e suportată, iar versiunea curentă apare la Informații → Server.

Schimbarea se face din panoul de hosting (în cPanel: „MultiPHP Manager” sau „Select PHP Version”) și e literalmente un dropdown. Partea delicată e că un plugin sau o temă foarte veche poate să nu fie compatibilă, iar rezultatul e o pagină albă. Ordinea corectă: backup, apoi schimbi pe staging, verifici, apoi pe site-ul real. Dacă nu ai staging și site-ul contează, ăsta e un punct unde merită să ceri ajutor. Pe un site vechi, saltul de versiune e de obicei și cel mai ieftin câștig de viteză disponibil.

Curățarea bazei de date

Baza de date a unui WordPress vechi acumulează straturi de care nu are nevoie nimeni: revizii ale fiecărei pagini (o pagină editată de 40 de ori păstrează 40 de copii), transient-uri expirate, comentarii spam, ciorne automate și — cel mai persistent — tabele rămase de la plugin-uri dezinstalate acum trei ani, pentru că foarte puține fac curat după ele. Rezultatul: interogări mai lente și backup-uri mai grele.

O dată pe trimestru:

• Ștergi reviziile vechi și ciornele automate — WP-Optimize sau Advanced Database Cleaner fac asta cu un click.
• Golești comentariile spam și optimizezi tabelele (același plugin o oferă).
• Limitezi reviziile pe viitor, o linie în wp-config.php: define('WP_POST_REVISIONS', 5);

Tabelele orfane sunt cazul unde recomand prudență. Un plugin le identifică, dar identificarea nu e infailibilă, iar o ștergere greșită de tabel nu se repară din interfață. Fă-o doar cu backup imediat înainte, sau las-o pe seama cuiva tehnic. Câștigul e real, dar nu e urgent.

Linkuri rupte și erori 404

Un link intern rupt nu doboară site-ul, dar consumă încrederea vizitatorului exact când era interesat de ceva. Se acumulează invizibil: redenumești o pagină, ștergi un articol, un furnizor extern își mută site-ul.

Două surse, ambele gratuite. Google Search Console → Indexare → Pagini → „Nu a fost găsită (404)” îți arată URL-urile pe care Google a încercat să le acceseze și n-a găsit nimic; contează cele către care duc linkuri, nu o pagină ștearsă intenționat. Și un crawler, care parcurge site-ul ca un robot și raportează fiecare link mort, intern și extern — Screaming Frog SEO Spider are o versiune gratuită limitată ca număr de URL-uri, suficientă pentru un site de firmă.

Ce faci cu ce găsești: dacă pagina veche are un echivalent nou, redirect 301 către el; dacă nu, lași 404-ul și repari linkurile care duceau acolo. Nu redirecta totul spre homepage — arată bine în raport și e inutil pentru vizitator.

Evită plugin-urile care scanează permanent linkurile din interiorul WordPress-ului, pentru că scanarea consumă resurse pe serverul tău. Dacă folosești unul, instalează-l, rulează-l, exportă rezultatul și dezinstalează-l.

Certificatul SSL

În 2026 certificatele sunt aproape întotdeauna Let’s Encrypt, se reînnoiesc automat, iar în cPanel funcția se numește AutoSSL. În mod normal n-ai ce face aici — și tocmai de asta, când se strică, se strică tăcut și complet: browserul afișează un avertisment pe tot ecranul și traficul se oprește.

Cauzele unei reînnoiri eșuate sunt banale: ai mutat DNS-ul și validarea nu mai trece, sau ai adăugat un subdomeniu care nu e inclus în certificat. De aceea verificarea SSL din monitorizarea uptime te anunță înainte, nu după. Manual: click pe lacătul din bara de adrese → detalii certificat → data expirării. Dacă mai sunt sub 20 de zile și nu s-a reînnoit, deschide un tichet la host.

Conturile de administrator

Cel mai bun raport între timp investit și risc eliminat, în cinci minute: Utilizatori → Toți utilizatorii, filtrezi după rolul Administrator. Regula e că trebuie să recunoști fiecare cont, cu nume și adresă de email. Concret, cauți:

• Conturi ale unor oameni care nu mai lucrează cu tine — fostul dezvoltator, agenția de acum trei ani, colegul plecat. Nu le lăsa active „că poate mai avem nevoie”.
• Roluri prea generoase. Cine scrie articole are nevoie de rol de Autor, nu de Administrator.
• Parolele aplicație (Utilizatori → Profil → Parole aplicație), folosite de integrări externe — verifică dacă mai sunt de actualitate.
• Conturi pe care nu le recunoști deloc. Aici discuția se schimbă: un cont de admin necunoscut e, până la proba contrarie, semnul unei compromiteri, iar ștergerea lui nu rezolvă nimic singură. Pașii sunt în ghidul despre ce faci când site-ul WordPress e hackuit.

În aceeași sesiune, activează autentificarea în doi pași pe conturile de administrator. Efectul asupra celui mai comun tip de atac — încercarea repetată de parole pe wp-login.php — e imediat.

Recapitulare pe cadență

Interval	Ce se face	Cine poate
Automat	Auto-update Core, backup programat, monitorizare uptime	Se configurează o dată
Săptămânal	Verifici că backup-ul a rulat; actualizări de securitate; alerte	Proprietarul
Lunar	Grup de actualizări cu backup înainte și verificare după; audit admini; 404-uri; test de viteză	Proprietarul
Trimestrial	Test de restaurare; curățare bază de date; linkuri rupte; ștergere plugin-uri neutilizate	Parțial tehnic
Anual	Versiune PHP; reînnoire domeniu; audit de plugin-uri; revizuire GDPR și cookies	Tehnic pentru PHP

Ce poți face singur și ce nu

Lista de mai sus arată mai intimidant decât e.

Singur, fără cunoștințe tehnice: verifici că auto-update-urile Core sunt pornite, configurezi monitorizarea uptime, verifici lunar lista de administratori, ștergi plugin-urile și temele neutilizate, verifici 404-urile în Search Console, activezi 2FA, verifici că backup-ul rulează. Cumulat, cam 20 de minute pe lună — și acoperă majoritatea riscului real.

Singur, cu puțină atenție: actualizările lunare în tranșe mici cu backup înainte, curățarea reviziilor cu un plugin dedicat, testul de restaurare pe staging (dacă hostul tău îl oferă cu un click, și multe îl oferă).

Merită cineva tehnic: schimbarea versiunii de PHP pe un site vechi cu plugin-uri incerte, ștergerea tabelelor orfane, orice actualizare pe un magazin care ia comenzi zilnic, configurarea unui staging dacă hostul nu îl are — și, evident, orice situație în care ai găsit ceva ce nu recunoști. Curățarea unui site compromis nu e o sarcină de mentenanță și nu se face cu un plugin: curățarea de malware e o intervenție separată, iar pentru urgențe avem o pagină dedicată pentru site WordPress hackuit.

Dacă ai citit lista și concluzia ta e „pot face asta”, chiar poți și n-ai nevoie să cumperi nimic. Pune-ți trei recurențe în calendar — una săptămânală de zece minute, una lunară de o jumătate de oră, una trimestrială de două ore — și ești peste media pieței. Dacă concluzia e „n-o s-o fac niciodată”, asta e o informație la fel de utilă: un abonament de mentenanță website firmă există exact pentru cazul ăsta, iar decizia corectă e cea sinceră, nu cea ambițioasă.

Contează și pe ce fel de hosting stă site-ul: unul care oferă staging, backup la nivel de cont și versiuni PHP recente îți face jumătate din muncă.

Concluzie

Întreținerea unui site WordPress nu e complicată. E doar recurentă, iar recurența e exact lucrul la care oamenii ocupați sunt cei mai slabi.

Nimic din lista asta nu garantează că un site nu va fi niciodată compromis — nimeni nu poate promite asta onest. Ce face mentenanța pe cadență e mai modest și mai util: scurtează fereastra în care ești expus și îți garantează că, dacă totuși se întâmplă ceva, ai o copie funcțională a site-ului de acum două zile și știi sigur că funcționează, pentru că ai testat-o luna trecută.

Diferența dintre un incident de o oră și unul de trei săptămâni se decide, aproape întotdeauna, cu munca făcută înainte. Iar dacă pornești acum de la zero, jumătate din munca de mai târziu se elimină la construcție — am descris abordarea în pagina despre website de firmă pe WordPress: puține plugin-uri, o temă care nu se strică la fiecare actualizare.