Cómo gestionar muchos sitios WordPress: actualizaciones, copias, seguridad

Gestionar tres sitios WordPress es fácil: entras en cada escritorio, pulsas «Actualizar todo» y sigues con lo tuyo. En algún punto entre diez y cincuenta sitios, esa rutina se desmorona. Las actualizaciones se acumulan, el sitio de un cliente se rompe tras la publicación de un plugin y te enteras por sus propios clientes, y una instalación olvidada con un plugin de slider de hace dos años se convierte sin hacer ruido en un relé de spam. La solución no es trabajar más; es una rutina repetible que trate tus sitios como una flota y no como cincuenta tareas sueltas. Esta es la rutina que funciona en la práctica.

Por qué una flota de WordPress se descontrola

• Las actualizaciones son frecuentes y desiguales. El núcleo publica versiones menores de seguridad varias veces al año, y un sitio medio lleva entre 15 y 30 plugins, cada uno con su propio calendario. Multiplícalo por tu número de sitios y hay algo que actualizar casi a diario.
• La mayoría de los compromisos vienen de los plugins, no del núcleo. Año tras año, la inmensa mayoría de las vulnerabilidades de WordPress publicadas están en plugins y temas. El sitio que hackean suele ser el que nadie ha mirado en meses.
• Los escritorios no escalan. Entrar en cincuenta paneles de administración es lento, es fácil saltarse uno y no tienes una vista única de qué está desactualizado y dónde.

Usa wp-cli, no el escritorio

wp-cli es la herramienta oficial de línea de comandos de WordPress y el mayor ahorro de tiempo para cualquiera que gestione más de un puñado de sitios. Cada tarea rutinaria se convierte en un comando que puedes automatizar:

# ¿Qué versión del núcleo hay y existe una actualización?
wp core version
wp core check-update

# ¿Qué plugins y temas están desactualizados?
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available

# Actualizar un plugin, o todo
wp plugin update woocommerce
wp plugin update --all
wp theme update --all
wp core update
wp core update-db

Dos reglas hacen que wp-cli sea seguro en un servidor con muchos sitios:

• Ejecútalo como el usuario del sitio, nunca como root. Si cada sitio tiene su propio usuario Linux (y debería), ejecuta sudo -u siteuser wp --path=/var/www/siteuser/public_html .... Como root, los archivos escritos por una actualización acaban siendo de root, lo que rompe la siguiente actualización y las subidas del propio sitio. wp-cli incluso se niega a ejecutarse como root sin --allow-root, y esa advertencia tiene una buena razón.
• Pasa siempre --path. En un bucle sobre muchos sitios, una ruta explícita garantiza que cada comando toque el sitio que querías.

Con eso en marcha, el inventario de toda tu flota es un bucle corto:

for dir in /var/www/*/public_html; do
  user=$(stat -c %U "$dir")
  [ -f "$dir/wp-config.php" ] || continue
  echo "== $dir"
  sudo -u "$user" wp --path="$dir" plugin list --update=available --format=csv
done

Ejecútalo cada semana y sabrás exactamente dónde está el riesgo antes de tocar nada.

El orden seguro de actualización

Actualizarlo todo en todos los sitios a la vez es la forma en que una versión defectuosa tumba a veinte clientes en una tarde. Un orden más tranquilo:

1. Primero, la copia de seguridad. Archivos y base de datos, siempre (más abajo hay detalles).
2. Actualiza los plugins antes que el núcleo cuando sale una versión mayor, para que los plugins que añaden compatibilidad con el nuevo núcleo ya estén instalados. En las versiones menores habituales el orden importa menos, pero sé constante.
3. Actualiza los temas al final, y nunca edites un tema que también actualizas; pon tus personalizaciones en un tema hijo.
4. Ejecuta wp core update-db tras actualizar el núcleo para que las migraciones de base de datos no esperen al próximo inicio de sesión de un administrador.
5. Comprueba el sitio. Como mínimo, descarga la portada y una página interior y mira el código HTTP y el registro de errores de PHP. Una pantalla en blanco que nadie nota durante un día es peor que una que detectas en treinta segundos.

Escalona según el riesgo. Actualiza primero tus propios sitios de poco tráfico, espera un día y luego despliega en los sitios de clientes. En tiendas con mucho tráfico, prueba en una copia antes de producción.

Haz copia antes de cada actualización y guárdala en otro sitio

Una actualización sin copia es una apuesta. Haz que la copia forme parte del comando de actualización, no un hábito aparte:

wp db export /var/backups/siteuser/before-update-$(date +%F).sql
tar -czf /var/backups/siteuser/files-$(date +%F).tar.gz -C /var/www/siteuser public_html

Después aplica las reglas básicas de las copias que de verdad te salvan:

• Fuera del servidor. Una copia en el mismo disco muere con el disco o con el atacante. Envía una copia a un almacenamiento compatible con S3 o a otra máquina. (Lo explicamos en detalle en copias de seguridad cifradas de sitios web en S3.)
• Retención, no una sola copia. Conserva varias generaciones. Un malware que pasó desapercibido una semana también está en la copia de anoche.
• Prueba una restauración de vez en cuando. Una copia que nunca has restaurado es una esperanza, no una copia.

Higiene de plugins: la seguridad más barata que existe

• Borra lo que no uses. Los plugins desactivados siguen en el disco y pueden explotarse si sus archivos son accesibles directamente. wp plugin list --status=inactive y luego wp plugin delete.
• Mejor pocos plugins y mantenidos. Un plugin sin actualizaciones en dos años, o retirado del directorio de wordpress.org, es un riesgo. Sustitúyelo.
• No instales nunca plugins o temas «nulled». Las copias «gratuitas» de plugins premium son una de las vías más habituales para meter puertas traseras en sitios WordPress.
• Bloquea la edición de archivos. Añade define('DISALLOW_FILE_EDIT', true); a wp-config.php para que un acceso de administrador robado no se convierta en ejecución de código PHP a través del editor de temas.
• Aísla los sitios entre sí. Un usuario Linux y un pool PHP-FPM por sitio, para que un compromiso en un sitio no pueda leer los archivos ni las credenciales de base de datos del siguiente. (Consulta alojar varios sitios de clientes en un solo VPS.)
• Escanea con regularidad. Pasa un escáner de malware como ClamAV por los archivos de cada sitio de forma programada, no solo cuando algo parece raro.

Trampas habituales

• Actualizarlo todo automáticamente a ciegas. Las actualizaciones automáticas de WordPress para versiones menores del núcleo son sensatas. Actualizar automáticamente cada plugin de cada tienda de cliente sin copia ni comprobación no lo es.
• Olvidar update-db. Tras algunas actualizaciones del núcleo y de WooCommerce el sitio funciona, pero la actualización de la base de datos queda pendiente y el próximo administrador que entra la lanza en un momento aleatorio.
• Usuarios compartidos entre sitios. Si todos los sitios se ejecutan como www-data, un solo plugin vulnerable expone todos los sitios del servidor.
• Copias en el mismo servidor. Al ransomware y a los fallos de disco no les importa que tuvieras una carpeta de copias.
• Sin inventario. No puedes parchear lo que no sabes que existe. Mantén una lista de cada instalación, su responsable y sus plugins.

Cómo ShadowPanel te quita el trabajo repetitivo

ShadowPanel es un panel de control de hosting autoalojado y, en los planes Pro y Agency, cubre la rutina anterior sin renunciar a las reglas de aislamiento:

• WordPress Toolkit. Cada sitio WordPress tiene una vista que detecta la instalación y lista la versión del núcleo, la actualización disponible y cada plugin y tema con su versión instalada y disponible. Puedes actualizar el núcleo, un plugin o tema concreto, o todos los plugins o todos los temas de una vez, y el panel te muestra la salida de wp-cli.
• Se ejecuta como el usuario del sitio. Por debajo usa wp-cli como el usuario Linux propio del sitio, nunca como root, y la ruta de destino se comprueba contra el directorio personal de ese usuario. Los archivos actualizados conservan el propietario correcto.
• Copias antes de los cambios. Las copias bajo demanda de archivos y bases de datos están disponibles en todos los planes; Pro y Agency añaden copias automáticas programadas (diarias, semanales o mensuales) que se suben a un almacenamiento compatible con S3 o a un servidor SFTP, con el número de copias a conservar que elijas y un correo si una ejecución falla. Los archivos pueden cifrarse con GPG en AES-256.
• Escaneos de malware. Pro y Agency pueden lanzar desde el panel un escaneo completo del sitio con ClamAV, moviendo opcionalmente los archivos infectados a cuarentena, con el historial de escaneos guardado por sitio y una notificación al terminar.
• Aislamiento por defecto. Cada sitio tiene su propio usuario Linux y su propio pool PHP-FPM con open_basedir, así que un plugin desactualizado sigue siendo problema de un solo sitio.

En resumen

Cincuenta sitios WordPress se mantienen sanos cuando el trabajo es rutina: inventario con wp-cli, copia fuera del servidor antes de cada cambio, actualizaciones en un orden constante, comprobación del resultado y eliminación de los plugins que no necesitas. Nada de esto es difícil; solo tiene que ocurrir cada semana, en cada sitio. ShadowPanel reúne el inventario, las actualizaciones, las copias programadas y los escaneos de malware en un solo lugar, manteniendo cada sitio aislado de los demás.

curl -fsSL https://shadowpanel.de/install.sh | bash

Ver precios y descargar →