Hi ha una frase que sentim gairebé cada setmana quan un client ens truca amb el web caigut o ple d'spam: «però si feia mesos que anava tot bé, no havíem tocat res». I aquest és exactament el problema. No tocar res no és mantenir. En un WordPress, no fer res és, precisament, la decisió que acaba costant més cara. Perquè mentre tu no toques res, el món que envolta el teu web —les vulnerabilitats descobertes, els bots que les exploten, les versions que queden obsoletes— no para de moure's.
WordPress fa funcionar aproximadament el 43% de tots els llocs web del planeta. És una xifra que sona bé quan la fem servir per dir que has triat una plataforma sòlida i provada. Però té una cara B: aquesta popularitat el converteix en el primer objectiu dels atacants automàtics. No parlem d'un hacker amb caputxa mirant específicament el teu web. Parlem de robots que escanegen internet 24 hores al dia buscant instal·lacions de WordPress amb una versió coneguda i vulnerable, i que ataquen en massa, sense mirar si ets una botiga de sabates d'Andorra o un mitjà de comunicació. Si la porta està oberta, entren.
Aquest article no és el butlletí d'una versió concreta. És l'explicació, en llenguatge planer, de per què mantenir tot el teu WordPress al dia —nucli, plugins i temes— no és una tasca opcional que es pot anar ajornant, sinó una part estructural de tenir un web viu. I, sobretot, de com fer-ho sense el terror que, en actualitzar, se't trenqui alguna cosa.
Què és realment una versió de manteniment i seguretat
WordPress publica versions constantment, però no totes són iguals. Val la pena entendre la diferència, perquè determina la urgència amb què has d'actuar.
Les versions grans (les que porten un número «rodó», com passar d'una sèrie a la següent) porten funcionalitats noves: canvis a l'editor, noves eines, millores d'interfície. Són les que fan soroll i surten a les notes de premsa oficials.
Les versions de manteniment i seguretat són les discretes, les que porten un tercer número (per exemple, una 7.0.1 o una 7.0.2 respecte de la 7.0). No afegeixen res de nou i vistós. Fan una cosa molt més important: tapen forats. Corregeixen errors que han aparegut i, sobretot, tanquen vulnerabilitats de seguretat que s'han descobert al codi del nucli.
Aquí hi ha el matís que la majoria de propietaris de web no coneixen i que canvia tota la fotografia: quan l'equip de seguretat de WordPress publica una d'aquestes versions, també fa públic quin problema soluciona. És a dir, en el moment en què surt la correcció, tothom —inclosos els atacants— sap exactament quina era la debilitat. A partir d'aquell instant, cada web que encara no ha actualitzat es converteix en un objectiu amb un mapa del tresor a sobre. Els bots comencen a buscar precisament les instal·lacions que encara no han aplicat el pegat.
Un exemple del tipus de problema que corregeixen aquestes versions és el que la comunitat tècnica anomena una injecció SQL no autenticada. Sona intimidant, però el concepte és senzill: la base de dades és on viu tot el teu web (textos, usuaris, comandes, contrasenyes). Una injecció SQL és quan algú aconsegueix «colar» ordres a aquesta base de dades a través d'un formulari o una adreça manipulada. I «no autenticada» vol dir el pitjor de tot: que l'atacant no necessita cap contrasenya ni cap compte per fer-ho. Qualsevol persona des de fora, sense estar registrada, ho pot intentar. Quan una d'aquestes debilitats forma part d'una cadena més gran que podria acabar permetent executar codi al servidor, deixa de ser un tema tècnic per a informàtics i passa a ser un risc directe per al teu negoci.
El teu web no és només el nucli: plugins i temes també compten (i molt)
Quan parlem d'«actualitzar WordPress», molta gent pensa només en el programa central, el nucli. Però un WordPress real és com una casa: el nucli són els fonaments i les parets mestres, i després hi ha tot el que hi has anat afegint —el formulari de contacte, la botiga, el sistema de reserves, el constructor visual de pàgines, el connector de SEO, la galeria de fotos. Cadascuna d'aquestes peces és un plugin o un tema, i cadascuna té el seu propi codi, els seus propis autors i les seves pròpies vulnerabilitats.
Aquí ve una dada incòmoda però honesta: la gran majoria dels WordPress que veiem compromesos no han entrat pel nucli. El nucli de WordPress està molt vigilat i s'actualitza sol per a les correccions de seguretat menors. Per on entren, gairebé sempre, és per un plugin desactualitzat. Sovint un plugin que el client va instal·lar fa tres anys per a una promoció puntual, que ja no fa servir ningú, però que segueix allà, actiu, amb una versió antiga i un forat conegut.
Per això, quan des de Daimatics parlem de mantenir un web, no parlem de clicar un botó una vegada al mes. Parlem de tenir controlat tot l'inventari: quins plugins hi ha instal·lats, quins s'utilitzen de veritat, quins tenen actualitzacions pendents, quins ja no reben suport dels seus creadors (aquests són especialment perillosos, perquè encara que hi hagi un forat, ningú el taparà mai) i quins es poden eliminar directament perquè no aporten res. Un plugin desinstal·lat és un plugin que no et pot atacar. Aquesta feina de custòdia contínua és el cor del nostre servei de manteniment web, i és el que marca la diferència entre un web que envelleix amb dignitat i un que es degrada en silenci fins que peta.
Actualitzar de manera reactiva vs. tenir manteniment gestionat
Hi ha dues maneres de conviure amb les actualitzacions de WordPress, i la diferència entre totes dues és, literalment, la diferència entre patir sorpreses i no patir-ne.
- T'assabentes que cal actualitzar quan veus l'avís vermell al tauler... o quan el web ja ha caigut.
- Cliques «actualitzar tot» de cop, sense saber què canvia cada peça.
- No hi ha còpia de seguretat recent: si es trenca, no hi ha marxa enrere.
- Proves els canvis directament al web en producció, a la vista de tots els visitants.
- Passen setmanes (o mesos) entre que surt una correcció de seguretat i que l'apliques.
- Quan alguna cosa falla, comença la cursa per trobar qui ho arregla i quant costarà.
- Algú vigila proactivament les versions i les vulnerabilitats abans que siguin un problema.
- Les actualitzacions crítiques de seguretat s'apliquen ràpid; les grans, planificades i provades.
- Hi ha còpies de seguretat automàtiques i verificades abans de tocar res.
- Els canvis es proven primer en un entorn de proves (staging), no davant dels clients.
- La finestra de risc es redueix al mínim: forat conegut, forat tapat.
- Si alguna cosa no encaixa, es reverteix en minuts i el visitant no s'assabenta de res.
La versió reactiva no és que sigui «dolenta» per mandra. Normalment és el que passa quan ningú té assignada explícitament aquesta responsabilitat. El web funciona, ningú el toca, i tothom assumeix que algú altre se n'ocupa. Fins que un dia l'avís vermell es converteix en una pantalla en blanc, un redireccionament a una web estranya, o un correu del proveïdor d'allotjament dient que el teu compte enviava spam i l'han suspès.
«Actualitzar em fa por perquè un cop se'm va trencar tot»
Aquesta és, de lluny, l'objecció més honesta i més freqüent que ens trobem. I té tota la raó de ser. Sí, actualitzar pot trencar coses. Un plugin nou pot ser incompatible amb el teu tema, una actualització del constructor de pàgines pot descol·locar una secció, una nova versió del sistema de botiga pot afectar el procés de compra. Passa. No ho negarem.
Però aquí és on cal ser molt clar: el problema mai no és actualitzar. El problema és actualitzar sense xarxa. Qui s'ha «cremat» amb una actualització és, gairebé sempre, algú que va clicar el botó sense una còpia de seguretat recent i sense un lloc on provar-ho abans. És com fer una obra a casa sense haver fet fotos de com estava tot: si surt malament, no saps ni com tornar-hi.
La solució no és deixar de fer obres —això només fa que la casa s'ensorri més a poc a poc—. La solució és fer-les amb mètode. I el mètode existeix, és conegut i és el que apliquem sistemàticament. El concepte clau es diu staging: un entorn de proves que és una còpia idèntica del teu web real, però privada, on ningú de fora entra. Allà s'apliquen les actualitzacions primer, es comprova que tot segueix funcionant, i només quan hi ha la certesa que va bé es passa al web de veritat. Si al staging alguna cosa peta, el teu web públic ni s'ha assabentat.
Què cal comprovar SEMPRE després d'actualitzar
Actualitzar i marxar és mig feina. La part que separa un manteniment seriós d'un «he clicat el botó i ja està» és la comprovació posterior. Aquesta és la checklist mínima que passem després de tocar qualsevol web de client:
- La pàgina d'inici i les pàgines principals carreguen bé i es veuen com toca (res descol·locat, res desaparegut).
- El formulari de contacte s'envia i el correu arriba de veritat a la bústia correcta.
- Si és una botiga WooCommerce: afegir un producte al carretó i completar una compra de prova de principi a fi, incloent-hi el pagament.
- Els menús, els botons i els enllaços interns funcionen i porten on han de portar.
- La versió mòbil es veu correctament, no només la d'ordinador.
- La velocitat de càrrega no s'ha degradat després dels canvis.
- El web segueix sent accessible per a Google (res no ha bloquejat la indexació sense voler).
- Els avisos d'actualització pendent han desaparegut i no n'hi ha cap de nova mig aplicada.
Fixa't especialment en el punt del checkout. Si tens una botiga, el procés de compra és l'element més crític i el més fràgil davant d'una actualització, perquè implica moltes peces treballant juntes: el carretó, els mètodes de pagament, els impostos, l'enviament, els correus de confirmació. Hem vist botigues que van estar dies venent «bé» aparentment mentre, en realitat, cap comanda no es completava perquè una actualització havia trencat una passa del pagament. La pèrdua no es va veure fins que va arribar la factura de vendes a final de mes. Per això no n'hi ha prou de mirar que el web «es vegi bé»: cal fer la compra sencera un mateix.
Els errors que veiem una vegada i una altra
Després de mantenir desenes de WordPress de clients durant anys, els desastres es repeteixen amb una regularitat gairebé còmica. Aquests són els més habituals, i tots són evitables.
Per què tot això també afecta el teu posicionament a Google
Aquí hi ha una connexió que molts propietaris de web no fan, i que per a nosaltres és fonamental: la seguretat i el manteniment no són només un tema tècnic, són un tema de SEO i de negoci.
Google no vol enviar els seus usuaris a webs compromesos. Si el teu WordPress és hackejat i comença a servir contingut d'spam, redireccionaments a pàgines dubtoses o programari maliciós, Google ho detecta i pot marcar el teu web com a «insegur» als resultats de cerca —amb el famós avís vermell abans d'entrar-hi— o directament treure'l de l'índex. Recuperar-se d'això costa molt més temps i diners que haver-ho evitat. Anys de feina de SEO tècnic i de reputació poden quedar tocats en qüestió de dies.
Però no cal ni arribar a un hackeig perquè el manteniment afecti el teu posicionament. Un web amb plugins desactualitzats i acumulats tendeix a ser més lent, i la velocitat de càrrega és un factor que Google mesura i que afecta directament tant el rànquing com la conversió: cada segon de més que triga a carregar una pàgina, es perden visitants pel camí. Mantenir el web net, lleuger i al dia és, per tant, també una feina d'optimització de velocitat. Tot està connectat: un WordPress ben mantingut és més segur, més ràpid, més estable i, per tot això, es posiciona millor i converteix més.
Com gestionem la custòdia de WordPress a Daimatics
Quan un client ens confia el manteniment del seu WordPress, no li venem una llista de tasques abstractes. Assumim la custòdia real del web, que vol dir que deixa de ser una cosa que ell ha de recordar de vigilar i passa a ser una cosa que algú vigila per ell, de manera contínua i amb criteri.
A la pràctica, això significa tenir un inventari viu de cada peça del web i la seva versió, seguir de prop les publicacions de seguretat oficials de WordPress, aplicar les correccions crítiques amb rapidesa i les grans amb planificació, mantenir còpies de seguretat automàtiques i provades, disposar d'un entorn de proves per validar els canvis abans que arribin al públic, i fer les comprovacions posteriors que hem descrit en aquest article. I, quan cal, prendre decisions de fons: substituir un plugin que ha quedat abandonat pel seu autor per una alternativa mantinguda, eliminar el que sobra, o simplificar una instal·lació que ha acumulat capes durant anys. Aquesta feina de fons és el que trobaràs sota els nostres serveis de WordPress.
La idea de fons és senzilla i és la que defensem des de fa més de vint anys: un web és una cosa viva, no un fullet imprès que un cop fet ja no canvia. Requereix atenció regular, com un cotxe requereix revisions. Ningú espera que el cotxe s'espatlli a l'autopista per portar-lo al taller. Amb el teu WordPress, la lògica hauria de ser exactament la mateixa.
Manteniment i seguretat de WordPress: preguntes freqüents
Cada quant s'ha d'actualitzar un WordPress?
No hi ha un calendari fix universal, perquè depèn de quan els creadors del nucli, els plugins i els temes publiquen actualitzacions. La regla pràctica és: les correccions de seguretat s'apliquen com abans millor (dies, no setmanes), perquè la vulnerabilitat es fa pública en el mateix moment de la correcció; la resta d'actualitzacions es poden agrupar i planificar. En un web mantingut, això vol dir revisar l'estat almenys un cop per setmana i tenir activades les actualitzacions automàtiques de seguretat menors del nucli.
Si activo les actualitzacions automàtiques, ja estic cobert?
Parcialment. WordPress pot aplicar sol les correccions de seguretat menors del nucli, i això és molt recomanable. Però les actualitzacions automàtiques no fan còpia de seguretat prèvia, no proven els canvis en un entorn segur i no comproven que després tot funcioni. Per als plugins, els temes i les versions grans, l'automatisme sense supervisió pot arribar a trencar el web sense que ningú se n'adoni. L'automatització és una eina útil, no un substitut del criteri humà.
Què passa exactament si no actualitzo mai?
A curt termini, sovint res visible: el web sembla funcionar igual. El problema és acumulatiu i silenciós. Cada vulnerabilitat que es descobreix i es fa pública queda oberta al teu web per sempre. Amb el temps, augmenta molt la probabilitat que un atac automàtic entri i el faci servir per enviar spam, redirigir visitants o robar dades. A més, el web es va tornant més lent i més fràgil, i quan finalment cal actualitzar, el salt acumulat és tan gran que és molt més probable que alguna cosa es trenqui.
Actualitzar em pot trencar el web? Com ho evito?
Sí, una actualització pot causar incompatibilitats. Però el risc es controla amb mètode, no evitant-lo. Les tres claus són: una còpia de seguretat completa i verificada abans de tocar res, provar els canvis primer en un entorn de proves (staging) que és una còpia privada del web, i fer una comprovació posterior de les pàgines i funcions crítiques. Amb aquestes tres xarxes, si alguna cosa falla es reverteix en minuts i els visitants ni s'assabenten.
Tinc una botiga WooCommerce. Hi ha alguna cosa especial a vigilar?
Sí, i molt. En una botiga, el procés de compra és l'element més crític i el que més peces implica (carretó, pagament, impostos, enviament, correus de confirmació). És també el que més fàcilment es trenca en una actualització. Per això, després de qualsevol canvi, no n'hi ha prou de mirar que el web «es vegi bé»: cal fer una compra de prova completa, fins al pagament, per confirmar que tot el circuit funciona. Hem vist botigues perdent vendes durant dies per un checkout trencat que ningú havia comprovat.
Els plugins que no faig servir però tinc desactivats són un problema?
Sí. Un plugin instal·lat, encara que estigui desactivat, segueix sent codi present al servidor i pot ser una via d'entrada si té una vulnerabilitat coneguda. La bona pràctica és eliminar del tot els plugins i temes que no s'utilitzen. I cal parar una atenció especial als que els seus autors han deixat d'actualitzar: si es descobreix un forat, ningú el taparà mai. Menys peces vol dir menys superfície d'atac i un web més lleuger.
Què són els plugins «nul·lats» i per què són perillosos?
Són versions piratejades de plugins o temes de pagament que circulen «gratis» per internet. El perill és que molt sovint porten codi maliciós amagat: l'has instal·lat tu mateix, amb permisos totals, obrint la porta de bat a bat. A més, mai reben actualitzacions de seguretat legítimes. És un dels vectors d'infecció més comuns que ens trobem. L'estalvi aparent acaba costant una neteja de malware, una possible penalització de Google i molts maldecaps.
Puc gestionar jo mateix el manteniment o val la pena delegar-lo?
Depèn del temps, els coneixements i el risc que estiguis disposat a assumir. Si tens un web senzill, ganes d'aprendre i disciplina per fer còpies i comprovacions cada vegada, es pot portar un mateix. El moment de delegar sol arribar quan el web genera negoci de veritat (i una caiguda costa diners), quan hi ha una botiga pel mig, o simplement quan prefereixes dedicar el teu temps al teu negoci i no a vigilar versions. Delegar-ho no és abdicar del control: és tenir algú que assumeix la responsabilitat de fer-ho bé i amb xarxa.
Vols deixar de patir amb les actualitzacions del teu WordPress?
A Daimatics assumim la custòdia completa del teu WordPress —nucli, plugins i temes— amb inventari viu, còpies de seguretat verificades, entorn de proves i comprovacions posteriors. Actualitzar deixa de fer por quan hi ha mètode i xarxa.
Explica'ns el teu cas i revisem l'estat real del teu web.
Parlem del manteniment del teu web →
