Hay una frase que oímos casi cada semana cuando un cliente nos llama con la web caída o llena despam: «pero si hacía meses que iba todo bien, no habíamos tocado nada». Y este es exactamente el problema. No tocar nada no es mantener. En un WordPress, no hacer nada es, precisamente, la decisión que acaba costando más cara. Porque mientras tú no tocas nada, el mundo que rodea tu web —las vulnerabilidades descubiertas, los bots que las explotan, las versiones que quedan obsoletas— no para de moverse.
WordPress hace funcionar aproximadamente el 43% de todos los sitios web del planeta. Es una cifra que suena bien cuando la usamos para decir que has elegido una plataforma sólida y probada. Pero tiene una cara B: esta popularidad lo convierte en el primer objetivo de los atacantes automáticos. No hablamos de un hacker con capucha mirando específicamente tu web. Hablamos de robots que escanean internet 24 horas al día buscando instalaciones de WordPress con una versión conocida y vulnerable, y que atacan en masa, sin mirar si eres una tienda de zapatos de Andorra o un medio de comunicación. Si la puerta está abierta, entran.
Este artículo no es el boletín de una versión concreta. Es la explicación, en lenguaje llano, de por qué mantener todo tu WordPress al día —núcleo, plugins y temas— no es una tarea opcional que se puede ir aplazando, sino una parte estructural de tener una web viva. Y, sobre todo, de cómo hacerlo sin el terror de que, al actualizar, se te rompa algo.
Qué es realmente una versión de mantenimiento y seguridad
WordPress publica versiones constantemente, pero no todas son iguales. Vale la pena entender la diferencia, porque determina la urgencia con la que debes actuar.
Las versiones grandes (las que llevan un número «redondo», como pasar de una serie a la siguiente) traen funcionalidades nuevas: cambios en el editor, nuevas herramientas, mejoras de interfaz. Son las que hacen ruido y salen en las notas de prensa oficiales.
Las versiones de mantenimiento y seguridad son las discretas, las que llevan un tercer número (por ejemplo, una 7.0.1 o una 7.0.2 respecto de la 7.0). No añaden nada nuevo y vistoso. Hacen algo mucho más importante: tapan agujeros. Corrigen errores que han aparecido y, sobre todo, cierran vulnerabilidades de seguridad que se han descubierto en el código del núcleo.
Aquí está el matiz que la mayoría de propietarios de web no conoce y que cambia toda la fotografía: cuando el equipo de seguridad de WordPress publica una de estas versiones, también hace público qué problema soluciona. Es decir, en el momento en que sale la corrección, todo el mundo —incluidos los atacantes— sabe exactamente cuál era la debilidad. A partir de ese instante, cada web que todavía no ha actualizado se convierte en un objetivo con un mapa del tesoro encima. Los bots empiezan a buscar precisamente las instalaciones que aún no han aplicado el parche.
Un ejemplo del tipo de problema que corrigen estas versiones es lo que la comunidad técnica llama una inyección SQL no autenticada. Suena intimidante, pero el concepto es sencillo: la base de datos es donde vive todo tu web (textos, usuarios, pedidos, contraseñas). Una inyección SQL es cuando alguien consigue «colar» órdenes a esa base de datos a través de un formulario o una dirección manipulada. Y «no autenticada» quiere decir lo peor de todo: que el atacante no necesita ninguna contraseña ni ninguna cuenta para hacerlo. Cualquier persona desde fuera, sin estar registrada, puede intentarlo. Cuando una de estas debilidades forma parte de una cadena más grande que podría acabar permitiendo ejecutar código en el servidor, deja de ser un tema técnico para informáticos y pasa a ser un riesgo directo para tu negocio.
Tu web no es solo el núcleo: plugins y temas también cuentan (y mucho)
Cuando hablamos de «actualizar WordPress», mucha gente piensa solo en el programa central, el núcleo. Pero un WordPress real es como una casa: el núcleo son los cimientos y las paredes maestras, y luego está todo lo que has ido añadiendo —el formulario de contacto, la tienda, el sistema de reservas, el constructor visual de páginas, el conector de SEO, la galería de fotos. Cada una de estas piezas es un plugin o uno tema, y cada una tiene su propio código, sus propios autores y sus propias vulnerabilidades.
Aquí viene un dato incómodo pero honesto: la gran mayoría de los WordPress que vemos comprometidos no han entrado por el núcleo. El núcleo de WordPress está muy vigilado y se actualiza solo para las correcciones de seguridad menores. Por donde entran, casi siempre, es por un plugin desactualizado. A menudo un plugin que el cliente instaló hace tres años para una promoción puntual, que ya no usa nadie, pero que sigue ahí, activo, con una versión antigua y un agujero conocido.
Por eso, cuando desde Daimatics hablamos de mantener una web, no hablamos de hacer clic en un botón una vez al mes. Hablamos de tener controlado todo el inventario: qué plugins hay instalados, cuáles se utilizan de verdad, cuáles tienen actualizaciones pendientes, cuáles ya no reciben soporte de sus creadores (estos son especialmente peligrosos, porque aunque haya un agujero, nadie lo tapará nunca) y cuáles se pueden eliminar directamente porque no aportan nada. Un plugin desinstalado es un plugin que no te puede atacar. Este trabajo de custodia continua es el corazón de nuestro servicio de mantenimiento web, y es lo que marca la diferencia entre una web que envejece con dignidad y una que se degrada en silencio hasta que revienta.
Actualizar de manera reactiva vs. tener mantenimiento gestionado
Hay dos maneras de convivir con las actualizaciones de WordPress, y la diferencia entre ambas es, literalmente, la diferencia entre sufrir sorpresas y no sufrirlas.
- Te enteras de que hay que actualizar cuando ves el aviso rojo en el panel... o cuando la web ya ha caído.
- Haces clic en «actualizar todo» de golpe, sin saber qué cambia cada pieza.
- No hay copia de seguridad reciente: si se rompe, no hay marcha atrás.
- Pruebas los cambios directamente en la web en producción, a la vista de todos los visitantes.
- Pasan semanas (o meses) entre que sale una corrección de seguridad y que la aplicas.
- Cuando algo falla, empieza la carrera por encontrar quién lo arregla y cuánto costará.
- Alguien vigila proactivamente las versiones y las vulnerabilidades antes de que sean un problema.
- Las actualizaciones críticas de seguridad se aplican rápido; las grandes, planificadas y probadas.
- Hay copias de seguridad automáticas y verificadas antes de tocar nada.
- Los cambios se prueban primero en un entorno de pruebas (staging), no delante de los clientes.
- La ventana de riesgo se reduce al mínimo: agujero conocido, agujero tapado.
- Si algo no encaja, se revierte en minutos y el visitante no se entera de nada.
La versión reactiva no es que sea «mala» por pereza. Normalmente es lo que pasa cuando nadie tiene asignada explícitamente esa responsabilidad. La web funciona, nadie la toca, y todos asumen que alguien más se encarga. Hasta que un día el aviso rojo se convierte en una pantalla en blanco, una redirección a una web extraña, o un correo del proveedor de alojamiento diciendo que tu cuenta enviaba spam y la han suspendido.
«Actualizar me da miedo porque una vez se me rompió todo»
Esta es, con diferencia, la objeción más honesta y más frecuente que nos encontramos. Y tiene toda la razón de ser. Sí, actualizar puede romper cosas. Un plugin nuevo puede ser incompatible con tu tema, una actualización del constructor de páginas puede descolocar una sección, una nueva versión del sistema de tienda puede afectar al proceso de compra. Pasa. No lo negaremos.
Pero aquí es donde hay que ser muy claro: el problema nunca es actualizar. El problema es actualizar sin red. Quien se ha «quemado» con una actualización es, casi siempre, alguien que hizo clic en el botón sin una copia de seguridad reciente y sin un lugar donde probarlo antes. Es como hacer una obra en casa sin haber hecho fotos de cómo estaba todo: si sale mal, no sabes ni cómo volver atrás.
La solución no es dejar de hacer obras —eso solo hace que la casa se derrumbe más despacio—. La solución es hacerlas con método. Y el método existe, es conocido y es el que aplicamos sistemáticamente. El concepto clave se llama staging: un entorno de pruebas que es una copia idéntica de tu web real, pero privada, donde nadie de fuera entra. Allí se aplican las actualizaciones primero, se comprueba que todo sigue funcionando, y solo cuando hay la certeza de que va bien se pasa a la web de verdad. Si en el staging algo revienta, tu web público ni se ha enterado.
Qué hay que comprobar SIEMPRE después de actualizar
Actualizar y marcharse es media faena. La parte que separa un mantenimiento serio de un «he hecho clic en el botón y ya está» es la comprobación posterior. Esta es la checklist mínima que pasamos después de tocar cualquier web de cliente:
- La página de inicio y las páginas principales cargan bien y se ven como corresponde (nada descolocado, nada desaparecido).
- El formulario de contacto se envía y el correo llega de verdad al buzón correcto.
- Si es una tienda WooCommerce: añadir un producto al carrito y completar una compra de prueba de principio a fin, incluyendo el pago.
- Los menús, los botones y los enlaces internos funcionan y llevan a donde deben llevar.
- La versión móvil se ve correctamente, no solo la de ordenador.
- La velocidad de carga no se ha degradado después de los cambios.
- La web sigue siendo accesible para Google (nada ha bloqueado la indexación sin querer).
- Los avisos de actualización pendiente han desaparecido y no hay ninguno nuevo a medio aplicar.
Fíjate especialmente en el punto del checkout. Si tienes una tienda, el proceso de compra es el elemento más crítico y el más frágil ante una actualización, porque implica muchas piezas trabajando juntas: el carrito, los métodos de pago, los impuestos, el envío, los correos de confirmación. Hemos visto tiendas que estuvieron días vendiendo «bien» aparentemente mientras, en realidad, ningún pedido se completaba porque una actualización había roto un paso del pago. La pérdida no se vio hasta que llegó la factura de ventas a final de mes. Por eso no basta con mirar que la web «se vea bien»: hay que hacer la compra entera uno mismo.
Los errores que vemos una y otra vez
Después de mantener decenas de WordPress de clientes durante años, los desastres se repiten con una regularidad casi cómica. Estos son los más habituales, y todos son evitables.
Por qué todo esto también afecta a tu posicionamiento en Google
Aquí hay una conexión que muchos propietarios de web no hacen, y que para nosotros es fundamental: la seguridad y el mantenimiento no son solo un tema técnico, son un tema de SEO y de negocio.
Google no quiere enviar a sus usuarios a webs comprometidas. Si tu WordPress es hackeado y empieza a servir contenido de spam, redirecciones a páginas dudosas o software malicioso, Google lo detecta y puede marcar tu web como «insegura» en los resultados de búsqueda —con el famoso aviso rojo antes de entrar— o directamente sacarla del índice. Recuperarse de esto cuesta mucho más tiempo y dinero que haberlo evitado. Años de trabajo de SEO técnico y de reputación pueden quedar tocados en cuestión de días.
Pero no hace falta ni llegar a un hackeo para que el mantenimiento afecte a tu posicionamiento. Una web con plugins desactualizados y acumulados tiende a ser más lento, y la velocidad de carga es un factor que Google mide y que afecta directamente tanto al ranking como a la conversión: cada segundo de más que tarda en cargar una página, se pierden visitantes por el camino. Mantener la web limpia, ligera y al día es, por tanto, también un trabajo deoptimización de velocidad. Todo está conectado: un WordPress bien mantenido es más seguro, más rápido, más estable y, por todo ello, se posiciona mejor y convierte más.
Cómo gestionamos la custodia de WordPress en Daimatics
Cuando un cliente nos confía el mantenimiento de su WordPress, no le vendemos una lista de tareas abstractas. Asumimos la custodia real de la web, lo que significa que deja de ser algo que él tiene que recordar vigilar y pasa a ser algo que alguien vigila por él, de manera continua y con criterio.
En la práctica, esto significa tener un inventario vivo de cada pieza de la web y su versión, seguir de cerca las publicaciones de seguridad oficiales de WordPress, aplicar las correcciones críticas con rapidez y las grandes con planificación, mantener copias de seguridad automáticas y probadas, disponer de un entorno de pruebas para validar los cambios antes de que lleguen al público, y hacer las comprobaciones posteriores que hemos descrito en este artículo. Y, cuando hace falta, tomar decisiones de fondo: sustituir un plugin que ha quedado abandonado por su autor por una alternativa mantenida, eliminar lo que sobra, o simplificar una instalación que ha acumulado capas durante años. Este trabajo de fondo es lo que encontrarás bajo nuestros servicios de WordPress.
La idea de fondo es sencilla y es la que defendemos desde hace más de veinte años: una web es algo vivo, no un folleto impreso que una vez hecho ya no cambia. Requiere atención regular, como un coche requiere revisiones. Nadie espera que el coche se averíe en la autopista para llevarlo al taller. Con tu WordPress, la lógica debería ser exactamente la misma.
Mantenimiento y seguridad de WordPress: preguntas frecuentes
¿Cada cuánto hay que actualizar un WordPress?
No hay un calendario fijo universal, porque depende de cuándo los creadores del núcleo, los plugins y los temas publican actualizaciones. La regla práctica es: las correcciones de seguridad se aplican cuanto antes mejor (días, no semanas), porque la vulnerabilidad se hace pública en el mismo momento de la corrección; el resto de actualizaciones se pueden agrupar y planificar. En una web mantenida, esto significa revisar el estado al menos una vez por semana y tener activadas las actualizaciones automáticas de seguridad menores del núcleo.
Si activo las actualizaciones automáticas, ¿ya estoy cubierto?
Parcialmente. WordPress puede aplicar por sí solo las correcciones de seguridad menores del núcleo, y eso es muy recomendable. Pero las actualizaciones automáticas no hacen copia de seguridad previa, no prueban los cambios en un entorno seguro y no comprueban que después todo funcione. Para los plugins, los temas y las versiones grandes, el automatismo sin supervisión puede llegar a romper la web sin que nadie se dé cuenta. La automatización es una herramienta útil, no un sustituto del criterio humano.
¿Qué pasa exactamente si no actualizo nunca?
A corto plazo, a menudo nada visible: la web parece funcionar igual. El problema es acumulativo y silencioso. Cada vulnerabilidad que se descubre y se hace pública queda abierta en tu web para siempre. Con el tiempo, aumenta mucho la probabilidad de que un ataque automático entre y la use para enviar spam, redirigir visitantes o robar datos. Además, la web se va volviendo más lenta y más frágil, y cuando finalmente hay que actualizar, el salto acumulado es tan grande que es mucho más probable que algo se rompa.
¿Actualizar puede romperme la web? ¿Cómo lo evito?
Sí, una actualización puede causar incompatibilidades. Pero el riesgo se controla con método, no evitándolo. Las tres claves son: una copia de seguridad completa y verificada antes de tocar nada, probar los cambios primero en un entorno de pruebas (staging) que es una copia privada de la web, y hacer una comprobación posterior de las páginas y funciones críticas. Con estas tres redes, si algo falla se revierte en minutos y los visitantes ni se enteran.
Tengo una tienda WooCommerce. ¿Hay algo especial que vigilar?
Sí, y mucho. En una tienda, el proceso de compra es el elemento más crítico y el que más piezas implica (carrito, pago, impuestos, envío, correos de confirmación). Es también el que más fácilmente se rompe en una actualización. Por eso, después de cualquier cambio, no basta con mirar que la web «se vea bien»: hay que hacer una compra de prueba completa, hasta el pago, para confirmar que todo el circuito funciona. Hemos visto tiendas perdiendo ventas durante días por un checkout roto que nadie había comprobado.
¿Los plugins que no uso pero tengo desactivados son un problema?
Sí. Un plugin instalado, aunque esté desactivado, sigue siendo código presente en el servidor y puede ser una vía de entrada si tiene una vulnerabilidad conocida. La buena práctica es eliminar del todo los plugins y temas que no se utilizan. Y hay que prestar una atención especial a aquellos cuyos autores han dejado de actualizar: si se descubre un agujero, nadie lo tapará nunca. Menos piezas significa menos superficie de ataque y una web más ligera.
¿Qué son los plugins «nulled» y por qué son peligrosos?
Son versiones pirateadas de plugins o temas de pago que circulan «gratis» por internet. El peligro es que muy a menudo llevan código malicioso oculto: lo has instalado tú mismo, con permisos totales, abriendo la puerta de par en par. Además, nunca reciben actualizaciones de seguridad legítimas. Es uno de los vectores de infección más comunes que nos encontramos. El ahorro aparente acaba costando una limpieza de malware, una posible penalización de Google y muchos quebraderos de cabeza.
¿Puedo gestionar yo mismo el mantenimiento o vale la pena delegarlo?
Depende del tiempo, los conocimientos y el riesgo que estés dispuesto a asumir. Si tienes una web sencilla, ganas de aprender y disciplina para hacer copias y comprobaciones cada vez, se puede llevar uno mismo. El momento de delegar suele llegar cuando la web genera negocio de verdad (y una caída cuesta dinero), cuando hay una tienda de por medio, o simplemente cuando prefieres dedicar tu tiempo a tu negocio y no a vigilar versiones. Delegarlo no es abdicar del control: es tener a alguien que asume la responsabilidad de hacerlo bien y con red.
¿Quieres dejar de sufrir con las actualizaciones de tu WordPress?
En Daimatics asumimos la custodia completa de tu WordPress —núcleo, plugins y temas— con inventario vivo, copias de seguridad verificadas, entorno de pruebas y comprobaciones posteriores. Actualizar deja de dar miedo cuando hay método y red.
Cuéntanos tu caso y revisamos el estado real de tu web.
Hablemos del mantenimiento de tu web →
