În ziua lansării un site pare gata. Dar tot ce stă sub el se schimbă mereu: versiunea de PHP pe care rulează, sistemul de administrare, pluginurile, certificatul. Luni la rând nu se întâmplă nimic vizibil. Apoi, într-o dimineață, browserul arată un avertisment roșu în locul paginii principale sau cineva observă că formularul de contact n-a mai trimis niciun mesaj de trei săptămâni.
Mentenanța e munca de rutină, fără nimic spectaculos, care previne asemenea surprize.
Ce se schimbă sub un site de care nu se ocupă nimeni
PHP iese din suport. Fiecare versiune de PHP primește remedieri de securitate doar o perioadă. Potrivit php.net, PHP 8.2 le primește până la 31 decembrie 2026, iar PHP 8.1 și versiunile mai vechi nu mai primesc niciuna. Un site care merge liniștit pe 8.1 rulează, de fapt, pe un PHP pe care nu-l mai actualizează nimeni.
Pluginurile adună găuri de securitate. Patchstack a numărat 11.334 de vulnerabilități noi în ecosistemul WordPress în 2025: 91% în pluginuri, 9% în teme și doar șase în WordPress propriu-zis, toate minore. Implicit, WordPress își actualizează singur nucleul, dar pluginurile și temele doar în cazuri speciale. Așa că exact partea cu cele mai multe găuri așteaptă ca cineva să apese „actualizează”.
Certificatele expiră tot mai repede. Din 15 martie 2026 un certificat HTTPS public poate fi valabil cel mult 200 de zile. CA/Browser Forum a hotărât ca limita să scadă la 100 de zile în martie 2027 și la 47 de zile în martie 2029. Let's Encrypt, autoritatea care dă certificatele gratuite folosite de multe site-uri mici, trece de la 90 la 45 de zile până în 2028 și nu recomandă reînnoirea manuală. Reînnoirea trebuie să meargă automat și cineva trebuie să afle când nu reușește.
OWASP, a cărui listă Top 10 e reperul obișnuit pentru riscurile aplicațiilor web, o spune direct în ediția din 2025: dacă programul nu mai are suport sau nu e actualizat, cel mai probabil e vulnerabil.
Un exemplu recent: PHP, 21 octombrie
Pe 21 octombrie 2026 echipa PHP a lansat versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Ele repară două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, prin care cineva din afară poate rula cod pe server fără cont și fără parolă. Echipa PHP a precizat că singura variantă sigură e actualizarea.
La un site de care are cineva grijă, asta a fost o actualizare obișnuită, făcută în aceeași săptămână. La un site lăsat de izbeliște, mai întâi trebuie aflat dacă știe cineva măcar ce versiune de PHP rulează. Pe 8.1 sau mai vechi nu există nimic de instalat: echipa PHP nu mai lansează remedieri pentru ele, deci rămâne doar trecerea la o versiune nouă.
Ce include mentenanța
Detaliile țin de fiecare site, dar o rutină lunară bine pusă la punct cuprinde cam asta:
- Actualizări: PHP, sistemul de administrare, pluginurile și temele, toate abia după o copie de rezervă, cu o verificare la final că site-ul funcționează.
- Copii de rezervă: zilnice, păstrate în afara serverului, cu o restaurare încercată din când în când. Cum le organizați, am explicat în articolul despre regula 3-2-1.
- Monitorizare: site-ul e accesibil, certificatul se reînnoiește la timp, formularul de contact chiar trimite mesajele.
- Verificări de securitate și de email: antetele de securitate și înregistrările DNS, inclusiv SPF, DKIM și DMARC, de care depinde dacă emailurile firmei ajung sau nu în spam (am scris despre asta în articolul de ce ajung emailurile firmei în spam).
- Reînnoiri: domeniul și hostingul, cu datele notate și un card de plată care nu a expirat.
- Modificări mici: un număr de telefon nou, programul de lucru, prețurile, fotografiile.
- Cineva care răspunde atunci când ceva nu mai merge.
Ce se întâmplă când nu se ocupă nimeni
Nimic din toate astea nu se întâmplă din prima zi. Problemele se adună și de obicei ies la iveală într-unul dintre felurile acestea:
- Expiră certificatul. Browserul arată un avertisment pe toată pagina în locul site-ului și mulți vizitatori pur și simplu pleacă.
- Formularul tace. Se schimbă o setare de email pe server, mesajele nu mai ajung și nu observă nimeni până nu sună un client să întrebe de ce n-a primit răspuns.
- Site-ul cade după o actualizare a serverului. Când firma de hosting renunță la o versiune veche de PHP, o temă sau un plugin vechi poate să nu mai funcționeze, iar vizitatorii văd o pagină de eroare.
- Site-ul e spart. Atacatorii adaugă pagini cu spam sau trimit vizitatorii pe alte site-uri. Google poate afișa atunci în rezultatele căutării mesajul „This site may be hacked” lângă site și le recomandă oamenilor să nu-l deschidă până nu dispare avertismentul. Google îl scoate abia după ce proprietarul curăță site-ul și cere o nouă verificare. Patchstack a măsurat și cât de repede vin atacurile: la vulnerabilitățile cele mai exploatate, mediana ponderată până la primul atac a fost de cinci ore.
- Nu există o copie de rezervă la care să reveniți. Sau există una, de acum un an, și nu știe nimeni parola.
Verificați-vă site-ul în zece minute
- Deschideți site-ul, apăsați pe iconița din stânga adresei și uitați-vă până când e valabil certificatul.
- Trimiteți-vă un mesaj prin formularul de contact și vedeți dacă ajunge.
- Puneți-i celui care se ocupă de site trei întrebări: ce versiune de PHP rulează, când au fost actualizate ultima dată pluginurile și unde sunt copiile de rezervă?
- Aflați când expiră domeniul și cine primește notificările de reînnoire.
Dacă nu vă poate răspunde nimeni, înseamnă că de site nu se ocupă nimeni. E mai bine să aflați asta azi decât în dimineața cu avertismentul roșu.
Actualizările, copiile de rezervă, monitorizarea și micile reparații de care e nevoie pe parcurs intră în planurile noastre de mentenanță și suport, pe care le găsiți pe pagina serviciului. Preluăm și site-uri vechi: le mutăm de pe un hosting pe care nu-l mai verifică nimeni, reparăm certificatul și actualizăm sistemul de administrare. Dacă vreți să ne uităm la site-ul Dvstră așa cum e acum, scrieți-ne.