Los administradores autenticados suelen evitar la caché de página, optimizaciones de CDN y ciertas reglas de seguridad. También reciben cookies, HTML y scripts diferentes. Que funcione durante una prueba de administración puede ocultar el recorrido público roto.
Usa siempre la sesión anónima como referencia.
Reproduce en sesiones aisladas
Abre un navegador privado sin cookies de WordPress. Envía una prueba inocua y única con Consola y Red abiertas.
Compara la misma URL con sesión iniciada, pero no mezcles cachés. Conserva el HTML inicial y URLs de scripts de ambas variantes. Comprueba si la prueba pública se guarda aunque no aparezca éxito o email.
Compara caché y nonces
Inspecciona cabeceras de caché y antigüedad del token. El administrador normalmente evita la caché completa mientras el visitante puede recibir un formulario con nonce antiguo.
Purga la página afectada, excluye endpoints dinámicos y usa la compatibilidad oficial. No desactives toda la caché indefinidamente. Si la CDN varía por cookie o dispositivo, prueba exactamente la variante pública.
Comprueba cada versión de idioma por separado.
Inspecciona roles y permisos
Un handler propio puede requerir por error is_user_logged_in() o una capability. También un endpoint REST puede registrar un permission callback incorrecto.
Revisa el código o configuración en staging. Los formularios públicos necesitan antiabuso y nonces, no permisos de administrador.
No hagas público un formulario interno sensible para resolver la prueba; confirma primero su audiencia prevista.
Compara scripts y optimización
Los administradores pueden recibir JavaScript sin combinar o excluido. Los visitantes pueden obtener recursos retrasados o un CAPTCHA bloqueado por consentimiento.
Registra el primer error y la petición. Desactiva una optimización cada vez en staging e identifica la exclusión o dependencia mínima. Ocultar el error no es repararlo: confirma que el POST llega al servidor.
Revisa WAF y antispam
Cloudflare, ModSecurity, plugins, CAPTCHA o honeypots pueden confiar en cookies o IP del administrador y bloquear anónimos.
Busca el evento e ID exactos y usa datos públicos representativos. Limita la excepción a la acción legítima sin omitir todos los controles POST. Comprueba límites desde redes móviles o empresariales compartidas.
Comprueba condiciones de notificación
Si las entradas se guardan para ambos roles pero solo llega el test del admin, compara los valores usados por las condiciones. El autocompletado o datos de cuenta pueden rellenar un campo que el visitante deja vacío.
Revisa tokens To, From y Reply-To y los logs. Envía desde un dominio autenticado. La diferencia de rol y la entrega pueden ser dos errores separados.
Verifica el recorrido completo del visitante
Prueba sin sesión en escritorio y móvil, validación, consentimiento, CAPTCHA, adjuntos y un envío correcto. Demuestra una entrada, una aceptación SMTP y entrega al buzón.
Prueba también con sesión para no romper administración. Monitoriza errores públicos y conversiones después de publicar.
Realiza una comparación controlada
Ejecuta las pruebas de administrador y visitante con el mismo navegador, campos y destinatario, cambiando únicamente la sesión. Etiqueta ambas y anota estado, ID de entrada y mail log.
Así no confundirás un email autocompletado, otra elección de consentimiento o una página cacheada con permisos. Usa una ventana privada sin extensiones y prueba los dos estados válidos de consentimiento.
No desactives globalmente privacidad o seguridad. Corrige la diferencia concreta, limpia solo la capa afectada y repite después de cerrar sesión.
Cuándo solicitar reparación
Pide ayuda si difieren nonces, caché, WAF o roles. Facilita URL pública, hora, estado y error redactado, nunca entradas ni contraseñas.
El resultado debe demostrar que los visitantes anónimos envían con seguridad y que los formularios internos siguen restringidos.