Comportamiento del almacenamiento en caché para errores y páginas 404

Una página de error puede parecer un documento HTML completo. Almacenarla bajo una ruta válida convertiría un fallo temporal en una respuesta duradera, así que POM Cache aplica controles de errores y de estado durante la generación.

Una sola página 404 compartida por sitio

Con el almacenamiento en caché HTML habilitado, POM Cache mantiene automáticamente un documento HTML estático para la página 404 pública del sitio. Todas las URL que no existen comparten ese documento; las rutas inexistentes nunca crean archivos de caché de página individuales.

WordPress sigue cargándose, resuelve la URL solicitada y ejecuta el manejo normal de redirecciones. Solo después de que WordPress identifica un 404 es cuando POM Cache reutiliza el documento en lugar de renderizar el tema de nuevo. La respuesta sigue siendo HTTP 404, con cabeceras no-cache. Una URL que se publique más adelante puede cargarse con normalidad sin tener que eliminar el documento compartido.

En el primer GET válido, POM Cache realiza una solicitud anónima a una URL inexistente fija del mismo sitio. Esto genera el 404 del tema sin copiar la ruta, los parámetros de consulta, las cookies ni las credenciales del visitante original. La solicitud debe completarse como un 404 HTML público. Si la generación falla, continúa el renderizado dinámico normal. Las solicitudes simultáneas no lanzan solicitudes de generación duplicadas, y una generación fallida se reintenta como máximo una vez por minuto. Las solicitudes HEAD pueden reutilizar un documento existente, pero no generan uno.

El documento compartido no tiene caducidad por antigüedad. Sobrevive a Delete Cache de la barra de administración, a las limpiezas normales de HTML/JSON y a la invalidación automática de contenido.

Actualizar el diseño del 404

Después de editar tu plantilla 404, cabecera, pie de página, navegación u otro contenido que se muestre en esta página:

1. Abre Settings → POM Cache → General → Cache tools en el sitio correspondiente.
2. Busca Shared 404 page y selecciona Delete 404 Cache.
3. Confirma el mensaje de eliminación.
4. Visita una URL inexistente como visitante anónimo.
5. Confirma el 404 HTTP, el diseño actualizado y el X-POM-Cache-404: HIT cuando la generación tenga éxito.

En multisitio, utiliza el contexto de configuración autorizado del sitio actual. Cada sitio posee su propio documento. La acción dedicada deja intactos el HTML normal y el JSON progresivo.

Solo contenido público y reutilizable

Utiliza un diseño 404 genérico. Las descripciones específicas de cada solicitud, el contenido específico de cada visitante y los formularios con tokens que caducan deben permanecer dinámicos. El documento se genera contra una URL inexistente fija, por lo que las plantillas que muestran la ruta solicitada mostrarán esa ruta fija en la copia compartida.

Los visitantes que han iniciado sesión, las cookies de omisión de sesión/carrito, las cabeceras de autorización, POST y otros métodos distintos de GET/HEAD, los parámetros de consulta, las solicitudes REST/feed y el DONOTCACHEPAGE omiten esta función. Las respuestas que establecen cookies, redirigen, fallan o contienen HTML incompleto no pueden alimentarla. La única excepción de cookies es la preferencia pública de idioma base de POM Translate, que no personaliza el documento compartido. El interruptor de almacenamiento en caché HTML y las comprobaciones de seguridad del caché compartido existente siguen aplicándose.

Se conserva un único documento en lugar de copias separadas para cada idioma, dispositivo o URL. Se sirve solo en el nombre de host y esquema configurados del sitio, con el mismo contexto de idioma que su copia generada. Los idiomas adicionales de POM Translate se renderizan dinámicamente. Las integraciones con otras salidas que dependen de la solicitud pueden desactivar el uso compartido a través del 404 filter.

Si no aparece ningún documento, comprueba Shared 404 page para ver el último resultado de generación. Un intento de generación puede informar de una conexión fallida, un estado HTTP inesperado, una salida que no es HTML, una cookie que impide el uso compartido, una respuesta no verificada o un fallo de escritura de archivo. Corrige la condición indicada, espera al menos un minuto y visita de nuevo una URL inexistente de forma anónima. Delete 404 Cache también borra el intento anterior para que la siguiente solicitud válida pueda reintentar de inmediato.

El sitio debe poder realizar una solicitud HTTPS anónima a sí mismo. Los errores de certificado, un desafío de cortafuegos, las redirecciones forzadas o las respuestas 404 personalizadas pueden impedir la generación. Una CDN o un proxy deben preservar la solicitud de generación y la respuesta HTML completa. Filtrar una cabecera de solicitud personalizada por sí solo no impide la generación cuando los parámetros de consulta llegan a WordPress. WordPress continúa sirviendo su 404 habitual siempre que la generación no pueda completarse de forma segura.

Esta función ahorra el renderizado del tema. No elimina el arranque de WordPress, las consultas de enrutamiento ni el trabajo de los plugins realizado antes del renderizado de la plantilla, incluido un monitor de 404 habilitado de forma independiente.

Redirecciones

POM Cache realiza un seguimiento de los estados de redirección habituales de WordPress 301, 302, 303 y 307 y excluye esas respuestas de la generación de HTML. Una redirección debe seguir siendo un estado más la cabecera Location, no convertirse en una página HTML reutilizable en la URL de origen.

Para otros flujos personalizados que no sean 200, la integración debe definir DONOTCACHEPAGE explícitamente y verificar el resultado. No asumas que una plantilla de error visualmente completa es una protección suficiente.

wp_die() y errores intersticiales

WordPress utiliza wp_die() para fallos de permisos, pantallas de confirmación y otras respuestas de error/intersticiales. POM Cache marca estas solicitudes con DONOTCACHEPAGE de forma predeterminada.

Eso protege el contenido cuyo marcado puede incluir mensajes específicos de cada solicitud, nonces o contexto administrativo.

Salida fatal e incompleta

Antes de escribir, POM Cache comprueba los tipos de errores fatales de PHP. También requiere una salida no vacía con un marcador de cierre reconocido.

Ejemplos que no deberían convertirse en un archivo de página:

• PHP se detiene antes de </html>;
• el búfer de salida está vacío;
• un error fatal interrumpe el renderizado de la plantilla;
• un componente define deliberadamente DONOTCACHEPAGE.

El visitante actual puede seguir recibiendo un error o una respuesta parcial. La protección del caché impide que ese búfer sea promovido a index.html.

Páginas previamente almacenadas en caché durante un fallo

La generación y la entrega son independientes:

• si se sirve un archivo estático válido antes de WordPress, el código dinámico que falla puede no ejecutarse nunca;
• si la solicitud omite o no acierta, WordPress puede fallar, pero el búfer rechazado no se publica intencionadamente;
• una CDN puede seguir sirviendo su propio objeto más antiguo independientemente del estado actual del origen.

Decide operativamente si es preferible contenido antiguo pero válido o un fallo dinámico inmediato. Los archivos HTML de POM Cache no caducan por antigüedad, por lo que purgarlos durante una interrupción elimina esa protección.

Probar sin afectar a las rutas de error reales

Utiliza un sitio de staging:

1. elimina el documento compartido con Delete 404 Cache;
2. solicita una URL conocida que no existe y confirma el estado 404;
3. solicita una segunda URL inexistente y confirma que reutiliza el mismo documento con HTTP 404, sin crear el index.html de ninguna de las dos URL;
4. prueba una redirección normal y confirma que su ruta de origen no se almacena;
5. genera una página válida;
6. simula una condición de salida incompleta aprobada;
7. confirma que el archivo válido existente no fue reemplazado por uno truncado;
8. restaura el comportamiento normal y vuelve a comprobar la página.

No introduzcas errores fatales en producción solo para probar el almacenamiento en caché.

Cuando ya existe un archivo de error

Si los visitantes reciben repetidamente un error antiguo:

1. determina si proviene de la CDN, de Apache/POM Cache, de otro producto de caché de páginas o de la aplicación;
2. inspecciona el archivo almacenado y su marca de tiempo de generación;
3. corrige primero la ruta o la respuesta subyacente;
4. elimina el caché de origen afectado;
5. invalida el objeto de CDN correspondiente;
6. solicita la URL canónica y confirma el estado, las cabeceras y el cuerpo correctos.

Los controles para desarrolladores están documentados en Error and 404 filters.