Qué rompe de verdad un sitio WordPress
Ayuda saber contra qué te estás defendiendo, porque las causas reales son más aburridas que las que la gente teme. Más o menos en orden de cuántas veces causan daño:
- Un plugin que su autor dejó de mantener, que sigue instalado porque todavía funcionaba.
- Una actualización aplicada directo al sitio en vivo que entró en conflicto con el tema.
- Un formulario de contacto o de cotización que dejó de entregar en silencio, casi siempre después de un cambio de hosting o de correo.
- Un certificado vencido, que convierte cada visita en una advertencia del navegador.
- Una versión de PHP que llega a su fin de vida, el hosting la actualiza y algo viejo deja de correr.
- Un respaldo que existía pero nunca se había restaurado, descubierto el día que se necesitaba.
Fíjate en que cuatro de esos son invisibles. Nada da error, nada se ve mal, y el único síntoma es que los clientes dejan de llegar. Ese es el argumento para monitorear en lugar de revisar de vez en cuando.
Actualizaciones: en copia de pruebas, probadas y después publicadas
Las actualizaciones automáticas en el sitio en vivo son una opción razonable para un blog personal y mala para un sitio de negocio, porque la forma de fallar es una pantalla en blanco en horario de oficina. La alternativa no es más lenta, solo está ordenada distinto:
- Aplica las actualizaciones primero en una copia de pruebas del sitio, no en el que está en vivo.
- Después de actualizar, carga las páginas que importan: la de inicio, una de servicio, el checkout si existe, y todo lo que tenga un bloque propio o un formulario.
- Envía los formularios. No des por bueno que funcionan porque la página se ve bien.
- Publica en vivo cuando eso pase, con un respaldo tomado justo antes.
- Deja constancia escrita de lo que cambió, para que un problema reportado tres días después tenga por dónde empezar.
Las versiones de seguridad son la excepción y deben salir rápido. Las de funciones pueden esperar una semana; dejar que otros encuentren primero las regresiones es una estrategia legítima.
Respaldos que de verdad has restaurado
Un respaldo sin probar es una creencia, no un respaldo. Las preguntas que vale la pena contestar antes de necesitar la respuesta son qué tan vieja es la copia más reciente, dónde vive y cuánto tarda una restauración completa.
Los detalles que importan más que el calendario:
- Fuera del servidor. Un respaldo guardado en el mismo hosting se va con el hosting.
- Fuera de la región. Una tormenta que deje sin luz a todo Lee County no debería llevarse también los respaldos.
- Las dos mitades. La base de datos y la carpeta de archivos subidos son cosas distintas, y el respaldo de una no es el respaldo del sitio.
- Restaurado al menos una vez, a propósito, en un sitio de pruebas, para que el procedimiento se conozca en lugar de improvisarse.
- Conservado el tiempo suficiente para alcanzar un problema que no notaste de inmediato. Siete días de respaldos no sirven para un daño hecho hace tres semanas.
Monitoreo: disponibilidad y los formularios
Monitorear la disponibilidad es lo mínimo y toma diez minutos configurarlo. Basta con una comprobación cada pocos minutos desde fuera de tu red y una alerta a un teléfono; el punto es enterarte de una caída antes de que te lo diga un cliente.
El monitoreo de formularios es la parte que casi nadie hace, y es la que más cuesta. Para un contratista o un consultorio el formulario de cotización es el negocio, y un formulario roto no genera error ni queja. Manda un envío de prueba real de forma programada y alerta si no llega, y vuelve a comprobar la entrega después de cada actualización y de cada cambio en el correo o en el DNS.
Vale la pena vigilar junto a eso la fecha de vencimiento del certificado, las advertencias de contenido mixto y si el sitio sigue indexándose o quedó bloqueado en silencio.
La auditoría de plugins que nadie quiere hacer
Un sitio que lleva cinco años corriendo suele cargar treinta plugins, y normalmente alrededor de un tercio no está haciendo nada. Cada uno es código corriendo en tu servidor y una puerta que alguien puede probar. La auditoría los separa en tres montones:
- Quitar: instalados para algo que ya no haces, o que duplican lo que el tema u otro plugin ya ofrece.
- Reemplazar: abandonados por su autor, actualizados por última vez hace años, o con vulnerabilidades conocidas.
- Conservar: los que sostienen el sitio. Hay que identificarlos de forma explícita, porque la parte riesgosa de limpiar es borrar algo que resulta ser estructural.
Hazlo en copia de pruebas, de uno en uno, revisando las páginas después de cada eliminación. Es lento y es lo más valioso que se le puede hacer a un sitio heredado. Normalmente además lo deja más rápido, por las razones de por qué mi sitio web es lento.
PHP, hosting y lo que está debajo del sitio
WordPress corre sobre PHP, y las versiones de PHP llegan a su fin de vida en un calendario público. Los hostings terminan forzando la actualización, y un plugin viejo o un tema a medida escrito para una versión anterior es donde eso sale mal. Saber tu versión de PHP y probar la siguiente en copia de pruebas convierte una caída forzada en una tarde agendada.
Lo mismo aplica al hosting en sí: si los respaldos vienen incluidos o solo anunciados, si hay un entorno de pruebas, y si el soporte contesta en horas o en días. El hosting barato suele ser un falso ahorro en un sitio que genera clientes, pero el cambio es una decisión que se toma con calma y no durante un incidente.
Las revisiones de contenido que atrapan el deterioro silencioso
El mantenimiento de software mantiene el sitio funcionando. Estas lo mantienen correcto, y vale la pena una pasada cada trimestre:
- Enlaces internos y externos rotos, incluidos los que están dentro de publicaciones viejas.
- Horarios, teléfonos, direcciones y zonas de servicio, sobre todo después de una mudanza o una sucursal nueva.
- Precios y todo lo que lleve una fecha, incluidas las páginas de temporada que quedaron publicadas fuera de temporada.
- Nombres y fotos del equipo en una página que nadie ha abierto en dos años.
- Imágenes subidas en la resolución completa de la cámara desde la última limpieza, que es como un sitio rápido deja de serlo poco a poco.
Agendarlo según el año de Florida
Aquí el mantenimiento tiene un calendario, lo planees o no. De eso se desprenden dos cosas.
Primero, la temporada de huracanes cambia para qué sirven los respaldos. Fuera del servidor y fuera de la región deja de ser una buena práctica y se vuelve el punto entero, y tu equipo necesita una manera de publicar un aviso de cierre o de reapertura desde el teléfono, quizá desde algún lugar sin luz.
Segundo, el trabajo pesado pertenece a los meses lentos. Las auditorías de plugins, las actualizaciones de PHP y cualquier cosa con posibilidad real de romper algo deben caer a finales del verano, no en las semanas previas a la temporada de invierno cuando el sitio carga con el tráfico del año. En diciembre no debería publicarse nada riesgoso.
Qué debe incluir un plan de mantenimiento
Si le pagas a alguien por mantenimiento, estas son las líneas que conviene tener por escrito. La ausencia de cualquiera de ellas es justo lo que hay que preguntar:
- Actualizaciones aplicadas y probadas en copia de pruebas antes de salir en vivo, no empujadas directo a producción.
- Respaldos fuera del servidor, con un periodo de retención declarado y una restauración ya ensayada.
- Monitoreo de disponibilidad y de entrega de formularios, con alertas que llegan a una persona.
- Un tiempo de respuesta declarado para cuando algo está roto, y a quién contactar fuera de horario.
- Un resumen mensual en lenguaje claro de lo que cambió y de lo que se encontró.
- Una bolsa para cambios pequeños de contenido, para que una lista de precios nueva no necesite factura aparte.
- Propiedad clara: el dominio, la cuenta de hosting y el código son tuyos, y puedes irte con ellos.
Eso es más o menos lo que cubre mi servicio de mantenimiento web. De los sitios que he mantenido durante años en lugar de construir y entregar, los casos de Nielsen y Athlean-X son los de recorrido largo.
Hacerlo tú mismo
Todo esto se puede hacer en casa, y para un sitio sencillo con un dueño técnico es una decisión razonable. La prueba honesta no es si puedes hacer las tareas, es si seguirán ocurriendo en el séptimo mes, en plena temporada alta, cuando nada parece estar mal.
Si la respuesta es no, la versión más económica de la ayuda externa no es un plan completo: es monitoreo más una pasada trimestral, para que las fallas invisibles se atrapen y el resto espere una tarde agendada. Normalmente eso alcanza para evitar las caídas que de verdad cuestan dinero.