Rollback WordPress con Git: guía de despliegues automáticos

📅 Publicado el 19 de octubre, 2026 · Por Equipo RedServicio

Si gestionas una web en producción, sabrás lo que es ese nudo en el estómago: actualizas un plugin un viernes por la tarde y, de repente, todo se viene abajo. Ahí es donde un rollback WordPress con Git marca la diferencia entre recuperar el sitio en minutos o pasarte horas intentando averiguar qué se rompió. En este artículo veremos cómo montar despliegues automáticos con control de versiones para poder volver atrás cuando haga falta, sin perder datos por el camino.

¿Qué es un rollback y por qué tu WordPress lo necesita?

Un rollback, dicho sin rodeos, es dar marcha atrás: revertir tu web a un estado anterior, ya sea una versión del código, una actualización de plugin o un cambio de configuración. La escena es de sobra conocida. Actualizas WooCommerce un viernes a última hora y la pasarela de pago deja de funcionar. Cada minuto sin cobrar es dinero que se escapa.

¿Y qué opciones tienes sin control de versiones? Prácticamente dos, y ninguna buena. Restaurar un backup completo (y perder pedidos y comentarios recientes) o ponerse a depurar a mano, a ciegas. Con Git el rollback es otra cosa. Quirúrgico, casi. Vuelves exactamente al código que funcionaba y la base de datos ni se entera.

¿Cuándo te salva la vida un rollback? Los casos se repiten una y otra vez:

• Actualizaciones fallidas de plugins o temas que rompen la compatibilidad con tu versión de PHP.
• Errores en código propio, introducidos por un desarrollador o por ti mismo al tocar el functions.php (a todos nos ha pasado).
• Despliegues a producción que nadie probó bien en staging.
• Compromisos de seguridad donde necesitas volver rápido a una versión estable mientras investigas qué ha pasado.

Esta red de seguridad no es ningún lujo. Es mantenimiento web básico, punto.

Cómo funciona el rollback WordPress con Git: conceptos básicos

Git guarda el historial completo de cambios de tu proyecto en forma de commits. Cada commit es una fotografía del código en un momento dado, identificada por un hash único (por ejemplo, a1b2c3d). Hacer rollback, en el fondo, es tan simple como mover tu web de vuelta a uno de esos puntos del historial.

El flujo de trabajo con despliegues automáticos sería este:

1. Haces cambios en tu entorno local y los confirmas con git commit.
2. Subes todo al repositorio remoto con git push.
3. Un servicio de despliegue (o un hook en tu servidor) detecta el push y actualiza producción automáticamente.
4. Si algo falla, ejecutas git revert o git checkout a un commit anterior, y el despliegue automático revierte la web en segundos.

Eso sí, hay un matiz que conviene tener claro desde el principio: Git versiona código, no base de datos. Tus entradas, usuarios y pedidos viven en MySQL, así que para un rollback completo tendrás que combinar Git con backups de la base de datos. Muchos paneles de hosting, como el que ofrece RedServicio con soporte 24/7, permiten programar copias automáticas que encajan muy bien con un flujo Git.

Preparando tu proyecto: repositorio Git y estructura recomendada

Antes de crear el repositorio, hay una decisión que tomar: ¿qué versionas exactamente? Versionar todo WordPress (núcleo incluido) es una opción válida, sí. Pero muchos equipos preferimos versionar solo wp-content, que es donde vive de verdad tu código personalizado.

Estructura recomendada

Algo ligero, fácil de mantener. Por ejemplo:

• /wp-content/themes/tu-tema — tu tema (hijo, preferiblemente) versionado siempre.
• /wp-content/plugins — versiona solo los plugins premium o personalizados; el resto se reinstalan sin drama.
• .gitignore — excluye wp-content/uploads, los .log y cualquier archivo con credenciales.
• /sql — opcional, para volcados de base de datos de referencia.

Un .gitignore básico podría quedar así:

Fíjate en que excluimos wp-config.php: si el repositorio se filtra algún día, no quieres que las contraseñas viajen con él. Usa mejor un archivo de ejemplo (wp-config-sample.php) con variables de entorno. Con la estructura definida, toca inicializar el repositorio con git init, añadir un remoto en GitHub, GitLab o Bitbucket, y hacer el primer commit con el estado actual y funcional de la web. Ese será tu punto de partida.

Despliegues automáticos: hooks y herramientas para conectar Git con tu hosting

Todo esto cobra sentido de verdad cuando el despliegue a producción se hace solo. Y la vía más directa, si tu hosting te da acceso SSH, es un post-receive hook: un script que corre en el servidor cada vez que haces git push. El flujo clásico no tiene misterio. Creas un repositorio «bare» fuera del directorio público y un hook que hace checkout hacia la carpeta de tu web. Nada más.

Un hook básico en hooks/post-receive tendría este aspecto:

1. WORK_DIR=’/home/usuario/public_html’ define el destino del despliegue.
2. GIT_DIR=’/home/usuario/repos/web.git’ apunta al repositorio bare.
3. El comando git –work-tree=$WORK_DIR –git-dir=$GIT_DIR checkout -f master actualiza los archivos con lo último que has enviado.
4. Opcionalmente, añade wp core update-db o una limpieza de cachés con WP-CLI tras cada despliegue.

Eso sí: dale permisos de ejecución al hook con chmod +x post-receive y prueba antes en staging. ¿Que los scripts no van contigo? Herramientas como DeployBot, Envoyer o las integraciones de GitHub Actions hacen lo mismo con interfaz gráfica. En cualquier caso, un hosting con SSH y WP-CLI disponibles —como el que ofrecemos en RedServicio— facilita mucho esta automatización, y nuestro soporte 24/7 puede echarte una mano si el hook se te resiste.

Rollback paso a paso: volver a una versión estable en minutos

Aquí es donde Git demuestra para qué sirve. Piensa en la escena: acabas de desplegar y la web saca un error crítico. Con el historial de commits, revertir lleva segundos:

1. Identifica el último commit estable con git log –oneline. Verás una lista breve con hashes y mensajes.
2. Deshaz los cambios sin perder historia usando git revert HEAD, que crea un commit inverso nuevo. Si trabajas en equipo, esta es la opción.
3. Alternativa rápida: git reset –hard abc1234 devuelve el repositorio a ese commit exacto (usa –force al hacer push si el commit problemático ya llegó al remoto).
4. Despliega la corrección con tu flujo habitual: el mismo push disparará el hook y la web volverá a su estado anterior.

Un matiz que conviene tener claro: Git no cubre la base de datos. Si el problema viene de un cambio en tablas o contenido, necesitarás restaurar un backup de la base junto al rollback del código. Por eso combinamos en RedServicio Git con copias automáticas diarias, otro servicio incluido en nuestros planes.

Conclusiones: seguridad y tranquilidad para tu WordPress

Montar un rollback WordPress con Git cambia la manera de gestionar tu web. Cada cambio queda registrado, cada despliegue es reproducible y volver atrás deja de ser una emergencia para ser un trámite de dos minutos. La puesta en marcha inicial exige algo de trabajo, es cierto —estructura del repositorio, hooks, excludes—, pero el retorno en tranquilidad es inmediato, sobre todo cuando actualizas plugins o temas en producción.

Mi consejo: empieza sencillo. Control de versiones del tema y plugins propios, un remoto en la nube, un hook básico de despliegue. Con el tiempo podrás sumar staging, integración continua y etiquetado de versiones. Y si tu hosting actual no te ofrece SSH, WP-CLI ni backups fiables, en RedServicio tienes la infraestructura y el acompañamiento técnico para llevar tu WordPress al siguiente nivel sin complicaciones.