Un nonce ayuda a confirmar que una petición procede de una página y ventana temporal esperadas; no es permanente. Servir HTML antiguo o mezclar versiones de assets puede hacer que un visitante envíe un token que el servidor ya no acepta.
Demuestra la discrepancia antes de excluir toda la web de la caché.
Captura la respuesta fallida
Envía datos sintéticos sin sesión e inspecciona el código y respuesta redactada. Anota si WordPress indica nonce inválido o caducado, fallo de seguridad o 403 genérico.
Relaciona la hora con PHP y seguridad. Un 403 de Cloudflare o ModSecurity puede parecer igual y pertenecer a otra capa.
No compartas el nonce; trátalo como dato de seguridad temporal.
Compara visitantes con y sin caché
Prueba ventana privada, vista bypass disponible para administradores y URL pública normal. Examina cabeceras de estado y edad.
Si falla la página pública y funciona la copia no cacheada con el mismo formulario, la edad o variación es evidencia sólida. Un único test con login no sirve porque suele excluirse.
Registra variantes móvil, escritorio, geográfica o CDN.
Compara también cookies y cabeceras que forman la clave de caché. Una variante anónima puede servirse erróneamente a usuarios con consentimiento o sesión distinta si el CDN ignora una cookie necesaria.
Revisa la vida de la página
Compara la validez esperada del nonce con TTL de página y CDN. La página no debe servir un token después de que WordPress deje de aceptarlo.
Usa la compatibilidad documentada por plugin o caché. Algunos formularios refrescan mediante AJAX; confirma que esa petición no se cachea ni bloquea.
Verifica que el token renovado se escribe en la misma instancia que se enviará y que la respuesta no procede de otra caché. Registra horas de generación y envío sin copiar el nonce.
Excluye solo páginas o fragmentos con estado dinámico. Verifica también el reloj del servidor.
Evita cachear endpoints
Las respuestas POST, AJAX y REST no deben almacenarse como éxitos o errores reutilizables. Revisa reglas CDN y servidor para el endpoint exacto.
Una respuesta de éxito cacheada puede afirmar que se envió un lead cuando WordPress nunca lo procesó. Purga el endpoint tras corregir la regla.
Revisa también métodos y códigos: una regla CDN no debe compartir la clave de POST con GET ni almacenar respuestas 403 o 422 para otros visitantes.
No desactives toda la seguridad REST como solución.
Revisa la optimización JavaScript
Minificar cambia formato, pero combinar, retrasar y reordenar dependencias puede impedir refrescar el token o iniciar con datos antiguos.
Inspecciona consola y versiones. Excluye del delay/combine el handle mínimo demostrado y regenera assets.
No incrustes un nonce en un archivo JavaScript estático; genéralo u obtenlo mediante el mecanismo compatible.
Busca varias copias del formulario
Un maquetador puede generar formularios móvil y escritorio con ID duplicados y tokens distintos. El script quizá actualice solo el primero mientras se envía el segundo.
Inspecciona DOM y peticiones. Prefiere una instancia responsive o asigna identificadores únicos.
Limpia CSS/JS del maquetador solo después de corregir la duplicación.
Mantén intacta la seguridad
No desactives validación, extiendas tokens indefinidamente ni aceptes cualquier petición anónima. La reparación debe servir estado fresco y conservar la comprobación legítima.
Combina el nonce correcto con validación en servidor, antispam y rate limits.
Ofrece una alternativa monitorizada si el formulario crítico sigue inestable.
Verifica todos los estados de caché
Tras reparar, purga la página u objeto CDN afectado y envía desde una sesión pública nueva. Repite cuando la caché se haya calentado y cerca del TTL cuando sea viable.
Confirma una petición, entrada, notificación y llegada. Prueba variantes móviles y estados de consentimiento.
Solicita reparación urgente si varias capas discrepan o el endpoint devuelve éxitos cacheados. Comparte URL, cabeceras y estados redactados, nunca nonces, cookies o contenido.