24 sitios WordPress, un comando por lote: cómo automatizamos el mantenimiento con IA (y lo que se rompió)

Septiembre: 24 sitios WordPress, 156 componentes actualizados, 52 retenidos a propósito y 1 regresión real entre 20 alarmas. Método y reglas.

En septiembre de 2026 hicimos el mantenimiento de los 24 sitios WordPress que tenemos con contrato mensual: actualizamos 156 componentes y dejamos 52 quietos a propósito. Diecinueve de esos sitios pasaron por un ciclo automático que escribió y opera Claude Code. Un lote de 16 sitios tardó 93 minutos, unos 5,8 minutos por sitio.

Este artículo es para agencias, freelancers y equipos de TI de pymes que sostienen sitios en WordPress y Elementor. Aquí van el método completo y las reglas que no negociamos.

¿Por qué automatizamos justo en septiembre?

Por un susto. Entre el 22 y el 23 de septiembre, Elementor 4.3.0 se instaló solo en varios de los sitios que administramos, por la actualización automática. Donde Elementor Pro seguía en la línea 3.x, la combinación producía un error fatal y el sitio respondía HTTP 500 en todas sus páginas.

Rescatamos 13 sitios caídos en dos rondas, bajando el núcleo de Elementor a la última versión 3.x compatible con su Pro. A otros 7 los intervenimos antes de que cayeran: tenían la misma combinación esperando el siguiente ciclo automático. Después blindamos todos los WordPress donde teníamos acceso para que nada se actualice sin que lo decidamos nosotros.

Ahí quedó claro algo incómodo: el mantenimiento “a mano, cuando se pueda” no estaba protegiendo a nadie. Un sitio puede responder bien y estar roto, y puede romperse un martes por la noche sin que nadie lo toque.

¿Cómo es el ciclo de diez pasos?

Cada sitio pasa por los mismos diez pasos, en el mismo orden. Para los sitios con acceso por SSH, un solo comando corre el lote completo.

Paso	Qué hace	Qué evita
1. Inventario	Lee versiones de WordPress, PHP, plugins y temas, y qué está pendiente	Actualizar a ciegas
2. Respaldo	Base de datos, plugins y temas comprimidos, guardados fuera de `public_html`	Quedarse sin vuelta atrás o dejar el respaldo descargable
3. Capturas antes	Portada y páginas clave	No tener contra qué comparar
4. Actualizar	Todo lo pendiente, excepto lo congelado a propósito	Romper con una versión que ya sabemos inestable
5. Purgar cachés	Todas: objetos, hosting, CSS de Elementor, plugins de caché, CDN	Ver roto lo que solo está en caché, o al revés
6. Verificar	HTTP, errores PHP, plugins activos antes y después	Dar por bueno un sitio que no carga
7. Capturas después	Mismas páginas a 390, 820 y 1440 px, comparadas píxel a píxel	Un sitio que responde 200 con el diseño roto
8. Escaneo de seguridad	Integridad de archivos, administradores, registros del servidor	Una infección que nadie ve
9. Informe PDF	Qué se actualizó, qué se retuvo y por qué, hallazgos	Que el cliente no sepa qué se hizo
10. Publicación	El informe queda en el portal del cliente	Correos perdidos

El portal es el Cerebro IA de btodigital, donde cada cliente ve su historial de mantenimiento.

Hay un paso cero que no está en la tabla: si la portada no responde bien antes de empezar, el script no toca nada. En el lote del 26 de septiembre eso pasó con un sitio cuyo firewall bloqueaba nuestra conexión, y el ciclo se detuvo solo en ese sitio.

¿Qué hace la IA y qué hace una persona?

Claude Code escribió los scripts del ciclo, los corre, revisa las comparaciones visuales marcadas, redacta la nota de cada sitio y publica el informe. También fue el que rescató los sitios caídos durante el incidente de Elementor.

Lo que no hace: no decide qué riesgo aceptar con un cliente ni instala nuestro plugin en los sitios sin SSH. Eso, junto con las contraseñas de aplicación, lo hace una persona desde el panel de administración. Y cuando el ciclo marca una posible regresión, se detiene y espera revisión antes de publicar.

¿Qué pasó en el ciclo de septiembre?

Indicador	Resultado
Sitios con contrato mensual	24
Por SSH, con el ciclo automático	19
Con nuestro plugin propio (sin SSH)	3
A mano desde el panel	1
Con un hosting que bloquea el acceso automatizado	1
Componentes actualizados	156
Componentes retenidos a propósito	52
Lote del 26 de septiembre	16 sitios en 93 minutos (~5,8 min por sitio)
Lote del 1 de octubre	3 sitios en paralelo en 13 minutos
Respaldo de un sitio, antes y después de comprimir	577 MB → 135 MB

Los 52 retenidos son la cifra que más me gusta del informe, porque es la que muestra criterio:

Motivo de la retención	Componentes
Regla de Elementor 4.3 (núcleo y Pro congelados)	33
Plugin de pago con licencia inactiva	16
Regresión real o sospechada en la versión nueva	3

Un plugin de pago sin licencia activa “se actualiza” sin cambiar de versión, y si subes la parte gratuita sin la de pago, el formulario se puede romper. Mejor dejarlo quieto y decirlo en el informe.

En los registros de los sitios por SSH, la lista de plugins activos antes y después de actualizar fue idéntica. Lo revisamos en cada corrida porque, como verás más abajo, una vez no lo fue.

¿Cómo sabe la máquina si algo se rompió visualmente?

Compara capturas. Si más del 2 % de los píxeles cambió, marca una posible regresión; entre 0,5 % y 2 %, un cambio menor. En el lote del 26 de septiembre se compararon 123 vistas (cada página en celular, tableta y computador). El sistema marcó 20 como posibles regresiones. Solo una era real.

La real: un plugin de optimización, en su versión nueva, agrandaba los íconos SVG de un sitio. Íconos pensados para 82 píxeles salían gigantes. Revertimos ese plugin a la versión anterior en ese sitio y lo dejamos retenido.

Las otras 19 eran ruido predecible:

Causa del falso positivo	Por qué cambia la captura
Ventanas emergentes	Salen en una captura y en la otra no
Carruseles y sliders	Cada captura toma otra diapositiva
Video de fondo	Otro fotograma
Texto animado	Otra palabra del titular
Caché fría	La primera captura sale en blanco
Firewall del hosting	La captura muestra la pantalla de verificación, no el sitio

¿Veinte alarmas para una falla real es mucho? Para mí no. Revisar 20 pares de imágenes toma minutos. No ver la falla real significaba que el cliente descubriera los íconos gigantes antes que nosotros.

¿Qué encontró el escaneo de seguridad?

Lo sumamos en octubre. En un sitio B2B de alto tráfico, los registros del servidor mostraron 20,5 millones de solicitudes en 30 días. Entre ellas, 67.241 intentos de inyección de código y 7.522 intentos de averiguar los usuarios del sitio. Ninguno logró acceso, y el firewall del hosting frena la mayoría de los ataques antes de que lleguen a esos registros.

El valor no está en el número que asusta, sino en lo que aparece al lado:

En otro sitio, un certificado SSL de pago que vencía en pocas semanas y que, a diferencia de los gratuitos, no se renueva solo. Hay que conseguir el nuevo e instalarlo a mano.
En ese mismo sitio, dos PDF de la política de datos del sitio anterior que respondían 404 y aun así recibieron 150 visitas en una semana.

Ninguna de las dos cosas aparece en una revisión de “¿el sitio está arriba?”.

¿Qué reglas no negociamos?

Actualizaciones automáticas apagadas siempre, en tres capas: un mu-plugin, una constante en wp-config.php y el interruptor del panel del hosting, que no se apaga desde la línea de comandos.
Nunca subir Elementor sin que Pro suba al mismo tramo. Y hoy, ni así: núcleo y Pro quedan congelados mientras la línea 4.3 no demuestre estabilidad. Tras un parche probamos 4 sitios y uno perdió el centrado y los contenedores de su encabezado.
Si se ve sin estilos, primero pensar en caché. Y verificar con la URL exacta. Un ?nocache= salta la caché de página del hosting y te hace creer que ya está arreglado cuando sigue roto para todo el mundo.
Un 0,00 % de diferencia en todas las vistas es sospechoso. Que todo dé exactamente cero no es buena noticia: suele significar que el comparador no está midiendo.
Una llave SSH dedicada por sitio, solo para el mantenimiento. Si una se compromete, se revoca esa y nada más.
El respaldo vive fuera de la carpeta pública. Si un navegador puede descargarlo, no es un respaldo: es una fuga.

¿Cuántas horas ahorra?

No lo sé, y prefiero decirlo. Nunca medimos cuánto tardaba el método manual por sitio, así que cualquier cifra de ahorro sería inventada.

Lo que sí tenemos es el tiempo de máquina: 93 minutos para 16 sitios en un lote, 13 minutos para 3 en paralelo. Lo que falta es el tiempo humano. En el ciclo de octubre lo vamos a medir así:

Hora de inicio y fin de cada sitio, que ya queda en el registro del lote.
Minutos de revisión humana por sitio: falsos positivos, notas y aprobación del informe.
Un sitio hecho completo a mano, de punta a punta, como referencia.

Con eso tendremos una comparación honesta. Si sale peor de lo que creo, también lo contaré.

¿Cómo aplicarlo en tu agencia o en tu empresa?

No necesitas IA para empezar. Necesitas orden. Esta es la lista en el orden en que yo la haría:

Apaga las actualizaciones automáticas en las tres capas: mu-plugin, wp-config.php y panel del hosting.
Escribe qué componentes están congelados y por qué. Si usas Elementor, revisa núcleo y Pro juntos.
Haz un respaldo comprimido antes de cada actualización, fuera de public_html, y prueba que no se pueda descargar.
Toma capturas antes y después en celular, tableta y computador.
Purga todas las cachés, no solo la del hosting.
Compara la lista de plugins activos antes y después.
Desconfía del 0,00 %.
Lee los registros del servidor una vez al mes: certificados de pago, 404 con tráfico, intentos de intrusión.
Entrega un informe con lo retenido y su motivo, no solo con lo actualizado.

Cuando el método está claro, la IA lo acelera. Antes, solo acelera el desorden. Es la misma razón por la que fracasan tantos proyectos de IA en las pymes. Y si después del mantenimiento quieres revisar la velocidad, en Core Web Vitals y SEO técnico está el orden que sigo.

Preguntas frecuentes

¿Se puede automatizar el mantenimiento de WordPress sin romper sitios? Se puede reducir mucho el riesgo, no eliminarlo. La clave no es actualizar más rápido sino verificar después: HTTP, errores PHP, plugins activos y comparación visual. En un lote de septiembre, de 123 vistas comparadas, una mostró una regresión real y la revertimos antes de que la viera el cliente.

¿Debo apagar las actualizaciones automáticas de WordPress? En sitios con Elementor y plugins de pago, sí. El 22 y 23 de septiembre una actualización automática de Elementor dejó sitios en error 500. Actualizar en una ventana controlada, con respaldo y verificación, es más seguro que dejar que el sitio se actualice solo.

¿Por qué no subir Elementor a la última versión? Porque núcleo y Pro deben ir en el mismo tramo, y aun así la línea 4.3 mostró regresiones visuales en algunos sitios. Hoy los mantenemos congelados y lo explicamos en cada informe.

¿Qué hago si mi sitio se ve sin estilos después de actualizar? Antes de tocar nada, purga todas las cachés y verifica con la URL exacta, sin parámetros como ?nocache=. En varios casos de septiembre era la caché de página del hosting. Si sigue roto después de purgar, vuelve al respaldo.

Si quieres montar algo así en tu equipo, es el tipo de trabajo que hago como consultor de IA con Claude.