Checklist de deploy en WordPress: 8 comprobaciones para no romper producción

La mayoría de los problemas graves que he visto en WordPress no vienen de un plugin malo ni de un hackeo. Vienen de un deploy: un push de staging a producción que parecía limpio y dejó algo roto que nadie vio durante días.

Esta checklist sale de incidencias reales en sitios en producción con Kinsta, Cloudflare y Elementor. Algunas están contadas en detalle en mis casos de éxito.

1. Antes del deploy

Saber qué cambia

Parece obvio, pero en muchos proyectos nadie puede decir qué archivos o ajustes van en un deploy. Un manifiesto sencillo (qué plugins se actualizan, qué archivos cambian, qué entradas nuevas hay) evita la mitad de los sustos. En un proyecto terminé automatizándolo con un plugin de deploy que genera ese manifiesto cada semana.

Buscar código que no está en archivos

Los plugins de «insertar código» guardan PHP en la base de datos y lo ejecutan con eval(). Ese código no aparece en el repositorio ni en un grep. En una migración a child theme, dos de esos snippets eran la causa de errores 500 en cadena. Antes de mover temas o plugins, revisa qué código vive en la base de datos.

Saber qué pasa si sale mal

Backup verificado y un plan concreto para volver atrás. «Restauramos el backup» no es un plan si nadie sabe cuánto tarda ni qué se pierde.

2. Durante el push

Qué arrastra un push completo

Un push de archivos y base de datos sobrescribe producción entera. Es seguro si producción está alineada con staging y nadie edita producción a mano. Si no, vas a borrar trabajo. Y si hay una funcionalidad en staging que no debe salir todavía, retírala antes del push y restáurala después.

URLs de staging que se cuelan

El buscar-y-reemplazar automático del hosting no siempre llega al JSON de Elementor, donde las URLs van con barras escapadas. En un caso, el dry-run dio 555 coincidencias: 554 eran logs de seguridad y de correo que no había que tocar, y solo 1 fila de contenido tenía enlaces reales a staging. Acota el reemplazo a las tablas de contenido:

wp search-replace 'staging.ejemplo.com' 'www.ejemplo.com' wp_posts wp_postmeta --precise --dry-run

3. Justo después del deploy

Regenerar las reglas de reescritura

Después de un deploy, los archivos de tres tipos de contenido personalizados empezaron a dar 404. Estaban bien registrados, pero sus reglas de reescritura habían desaparecido. wp rewrite flush lo arregló en segundos. Lo añadiría como último paso fijo de cualquier deploy con tipos de contenido personalizados.

Comprobar sin caché

Revisa las páginas clave saltándote la caché, por ejemplo con un parámetro en la URL, y mira las cabeceras. Si ves un MISS con error, el problema está en el origen aunque desde tu navegador todo parezca bien.

Recorrer lo que genera negocio

Home, páginas de servicio, formularios, checkout si hay tienda, buscador y cabecera y pie en varios idiomas. Mejor con un smoke test automático que a mano.

4. Caché: el orden importa

Este es el error que más daño hace: purgar la caché con el origen roto. La caché edge suele seguir sirviendo una copia buena anterior al deploy. Si purgas antes de arreglar, esa copia se sustituye por el error y le llega a todo el mundo, Googlebot incluido.

El orden correcto es: arreglar el origen → verificar sin caché → purgar. Lo cuento con detalle en el caso de los 404 ocultos por la caché edge.

5. La checklist completa

1. Manifiesto de cambios: qué va y qué no va en este deploy.
2. Revisar código guardado en la base de datos (plugins de snippets, opciones).
3. Backup verificado y plan de vuelta atrás.
4. Retirar de staging lo que no debe salir todavía.
5. Reemplazo acotado de URLs de staging, con dry-run.
6. wp rewrite flush si hay tipos de contenido personalizados.
7. Verificar las páginas clave sin caché y leer las cabeceras.
8. Solo entonces, purgar la caché y repasar formularios, checkout e idiomas.

Si tu equipo sufre cada vez que publica, puedo revisar el flujo y dejarlo documentado o automatizado. Es parte de mi trabajo como desarrollador WordPress en Barcelona y del mantenimiento WordPress que hago para empresas de toda España.

Preguntas frecuentes

¿Por qué mi WordPress da 404 en algunas páginas después de un deploy?

Una causa habitual es que las reglas de reescritura se regeneraron sin las de algunos tipos de contenido personalizados. Se arregla con wp rewrite flush y comprobando las URLs sin caché.

¿Tengo que purgar la caché después de cada deploy?

Sí, pero después de verificar que el origen responde bien. Si purgas con el origen roto, la caché servirá el error a todo el mundo.

¿El push de staging a producción reemplaza todas las URLs de staging?

No siempre. El JSON de page builders como Elementor guarda las URLs con barras escapadas y puede escapar al reemplazo automático. Conviene revisarlo con un dry-run.