Qué importa primero: WordPress intentó establacer o leer su prueba cookie y no recibió el valor esperado. Participan todos los encabezados de detección y respuesta del navegador, dominio, ruta, HTTPS.
Qué indica realmente este síntoma
Si el error afecta a cada navegador, la configuración del servidor es más probable que una configuración de privacidad local. Capturar Set-Cookie y la siguiente solicitud muestra si el cookie fue emitido, almacenado y devuelto.
Recopila pruebas antes de cambiar nada
- Inspecciona Set-Cookie en wp-login.php y el encabezado Cookie en la siguiente solicitud.
- Compara el dominio cookie y la ruta con la dirección en el navegador.
- Comprueba la dirección de WordPress, la dirección del sitio y la detección HTTPS detrás de proxies.
- Busque advertencias de encabezados-ya-enviados y respuestas de acceso en caché.
Causas más habituales
- Desajuste de dominios: El cookie pertenece a otro servidor, variante www o antiguo dominio de migración.
- Desajuste de cookies seguras: WordPress cree que la solicitud es HTTP mientras que el navegador utiliza HTTPS, o viceversa.
- Página de acceso en cachéado: Un CDN o caché de página sirve cookies o nonces obsoleto.
- Producto inicial: La salida de PHP evita que se envíe la cabecera Set-Cookie.
Secuencia segura de diagnóstico y reparación
- Excluir wp-login.php y wp-admin de cada página completa caché.
- Corregir el manejo canónico URLs y reenviar HTTPS.
- Eliminar COOKIE_DOMAIN intencionado anula a menos que la arquitectura los requiera.
- Borrar solo el navegador relevante cookies y repetir durante la inspección de cabeceras.
Cómo distinguir entre las causas probables
No trates Desajuste de dominios y Desajuste de cookies seguras como causas equivalentes. El cookie pertenece a otro servidor, variante www o antiguo dominio de migración. En cambio, wordPress cree que la solicitud es HTTP mientras que el navegador utiliza HTTPS, o viceversa. Para distinguirlas, usa estas dos comprobaciones: Inspecciona Set-Cookie en wp-login.php y el encabezado Cookie en la siguiente solicitud; y compara el dominio cookie y la ruta con la dirección en el navegador. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Excluir wp-login.php y wp-admin de cada página completa caché— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No desactives los indicadores de seguridad o HttpOnly cookie para hacer funcionar el acceso. Fije el esquema y la detección de dominio que causó el desajuste.
Cómo verificar la reparación
- El acceso persiste a través de una actualización de la página de administración.
- La autenticación correcta cookies está configurada y devuelta para el servidor canónico.
- Otros navegadores y un sesión limpio se comportan consistentemente.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.