Haz una copia de seguridad y revisa las reglas del servidor antes del despliegue
Las reglas del servidor afectan a cada petición antes de que WordPress pueda recuperarse de un error. Un despliegue de caché necesita una copia de seguridad en buen estado conocido, un cambio acotado, una comprobación de sintaxis y un responsable explícito de la reversión.
Esta guía cubre la revisión en sí. Usa Install the supplied Apache rules safely para ver los pasos de interfaz y de ubicación.
Captura el comportamiento actual
Antes de editar:
- guarda una copia recuperable de la configuración activa;
- anota dónde empieza el bloque principal de reescritura de WordPress;
- confirma que la portada, una página interior, el acceso, la administración, los medios, la REST y un 404 funcionan actualmente;
- demuestra una página en caché mediante PHP;
- anota la ubicación de la caché y la ruta del archivo generado;
- identifica el procedimiento de omisión o invalidación de la CDN.
La copia de seguridad debe pertenecer al mismo host virtual y a la misma versión de despliegue que se va a modificar.
Orden y alcance de la revisión
El bloque de POM Cache debe evaluarse antes de que WordPress reescriba una ruta pública a index.php. No debe colocarse:
- dentro del marcador generado por otro plugin;
- después de una regla incondicional del controlador frontal de WordPress;
- en un directorio donde sus rutas relativas signifiquen algo distinto;
- en un host virtual más amplio que sirva aplicaciones no relacionadas.
Conserva los marcadores # BEGIN POM Cache y # END POM Cache para poder identificar el bloque sin adivinar.
Revisa cada entrada de la clave de caché
Usa esta lista de comprobación:
| Entrada | Decisión necesaria |
|---|---|
| Método | Solo las lecturas seguras pueden usar HTML estático |
| Host | Debe seleccionar el árbol de sitio/dominio correcto |
| Ruta | Debe ser canónica, estar normalizada y dentro del espacio de nombres de la caché |
| Consulta | El estado significativo debe pasar de largo |
| Cookies | La autenticación, las contraseñas, los comentarios, los carritos, las sesiones y la personalización propia deben omitirse |
| Representación | JSON y otros formatos no deben recibir HTML |
| Estado del archivo | El destino exacto debe existir; sin listado de directorio ni alternativa adivinada |
Revisa también el comportamiento del proxy. Una regla del origen no puede evaluar una cookie, un host o una consulta que la capa superior haya eliminado o sustituido.
Revisa las suposiciones del sistema de archivos
Confirma:
- que el árbol de caché no sea la raíz del sistema de archivos ni la raíz de WordPress;
- que Apache pueda leer archivos pero no necesite escribirlos;
- que PHP pueda escribir archivos temporales y renombrarlos;
- que la ruta de la regla coincida con Advanced → Storage → Cache Location;
- que cada nodo del origen vea el archivo generado;
- que los enlaces simbólicos y los montajes se resuelvan a la raíz de caché prevista;
- que los alias de dominio no puedan seleccionar otro árbol de cliente o de sitio.
No uses una búsqueda con comodín por todo el sistema de archivos para compensar una asignación incorrecta.
Valida antes de recargar
Usa la prueba de configuración compatible de la plataforma de alojamiento. Una prueba correcta demuestra la sintaxis, no la corrección.
Después de recargar, comprueba:
- que no haya un bucle de redirección interna;
- que no haya respuestas 403/404/500 inesperadas;
- que el acceso y la administración de WordPress sigan siendo dinámicos;
- que los archivos de medios sigan usando sus gestores normales;
- que los fallos de caché lleguen a WordPress;
- que las peticiones públicas en caché devuelvan el documento esperado;
- que las cabeceras de seguridad y de caché sigan presentes en las respuestas estáticas.
Desencadenante de reversión
Restaura la configuración anterior de inmediato si:
- el tráfico autenticado o de carrito recibe el archivo anónimo;
- los hosts o subsitios se cruzan;
- los métodos que cambian estado devuelven HTML en caché;
- las rutas de WordPress dejan de llegar a
index.php; - los recursos reciben el tipo de contenido incorrecto;
- el origen empieza a entrar en bucle o a devolver errores del servidor.
Después de la reversión, invalida cualquier copia de borde insegura antes de volver a probar.
Mantén los cambios separables
Despliega las reescrituras de caché HTML, las reescrituras de JSON progresivo, la negociación de WebP y la compresión como cambios separados. Cada uno tiene una clave de caché y un contrato de cabeceras distintos. Combinar los cuatro en un único bloque sin verificar dificulta aislar y revertir los fallos.
Termina con Verify that Apache serves cached pages y, a continuación, prueba el comportamiento de la CDN de forma independiente.