Qué significa una respuesta 401
Una respuesta 401 Unauthorized indica que el servidor no entregará el recurso solicitado hasta que quien lo pide presente credenciales de autenticación aceptables. El nombre es histórico: el estado se refiere a una autenticación ausente o fallida, y no a un juicio de que quien pide carezca de permisos. Una respuesta conforme suele incluir un desafío WWW-Authenticate que identifica el esquema de autenticación.
En un área de miembros, un endpoint de la API, un enlace de vista previa o un documento privado, el 401 puede ser el límite correcto. Se convierte en un defecto de SEO cuando una URL pensada para visitantes normales (o una solicitud de CSS, JavaScript, imagen o datos necesaria para renderizar esa URL pública) devuelve 401. Un rastreador de buscadores no puede iniciar sesión como un miembro normal, así que no puede obtener de forma fiable la respuesta protegida.
Decide qué debe ser público
Empieza por la función de la página. Un producto, un artículo, una categoría, una página de ayuda o una landing pública deben poder recuperarse sin sesión. Las páginas de cuenta, las facturas y las vistas previas privadas deben requerir autenticación y no deben aparecer en la navegación pública ni en los sitemaps. Esta clasificación evita una corrección errónea habitual: debilitar el control de acceso solo para que una herramienta de monitorización muestre un 200.
| Respuesta | Significado | Acción habitual |
|---|---|---|
| 401 | Se requieren credenciales o se rechazan | Mantenlo para recursos privados; quita el desafío de las rutas públicas previstas. |
| 403 | El servidor entiende la solicitud pero la rechaza | Revisa las reglas de autorización y de bots; no lo trates como una petición de inicio de sesión. |
| 404 | No se encuentra ningún recurso actual | Devuélvelo para URL retiradas o desconocidas, salvo que exista un reemplazo relevante. |
Una página puede ser pública mientras parte de su flujo es privado. Por ejemplo, permite que la página de producto y sus imágenes se carguen de forma anónima, y pide credenciales al usuario solo cuando abre un área de cuenta. Mantén el HTML público lo bastante autocontenido para que una primera visita no dependa de una solicitud de API con credenciales.
Revisa la ruta de la respuesta
Prueba una URL principal sin cookies del navegador y anota el estado final, la cadena de redirecciones y las cabeceras de respuesta. Después revisa las solicitudes de red de la página en busca de 401 en los recursos necesarios para el renderizado. Un muro de inicio de sesión que añade una CDN, un proxy inverso, un middleware de la aplicación o una API de backend puede afectar a rutas distintas, así que una respuesta correcta de la portada no basta como prueba.
Solicita la URL exacta en una sesión limpia y anota el estado final y la cabecera WWW-Authenticate.
Compara una ruta pública que funciona con la ruta que devuelve el desafío, incluidas las redirecciones y los recursos necesarios.
Cambia solo la ruta o la regla de middleware que clasifica mal el recurso público.
Confirma que la ruta pública es anónima y que una ruta privada a propósito sigue requiriendo autenticación.
La comprobación práctica tiene dos caras. Si una página pública pasa a requerir autenticación, corrige su regla de acceso y vuelve a probar la página renderizada. Si una página protegida se ha vuelto pública por accidente, restaura el límite y asegúrate de que no aparece en los enlaces internos, los feeds ni los sitemaps XML. Los códigos de estado describen el comportamiento; no sustituyen un inventario de rutas.
Verifica la corrección
Tras el despliegue, vuelve a rastrear una pequeña muestra de plantillas como solicitante anónimo. Revisa el HTML final y los recursos que transportan el contenido principal: estilos, scripts, imágenes y datos estructurados. En Google Search Console, la inspección de URL puede ayudar a distinguir un problema de obtención actual de un informe de indexación antiguo, pero no sustituye a revisar tú mismo la respuesta en directo.
Usa una lista explícita de rutas públicas frente a rutas autenticadas antes de dar por resuelta esta clase de incidencia. El resultado útil no es un 200 universal: es un límite coherente en el que las páginas públicas previstas se resuelven con normalidad y las privadas previstas siguen protegidas.
Incluye en la muestra de verificación los recursos protegidos y las API. Una página pública puede devolver 200 mientras su contenido principal, su hoja de estilos o una imagen reciben un 401 y dejan una experiencia renderizada incompleta. Revisa el estado final y el desafío de autenticación de cada solicitud imprescindible para el renderizado, y vuelve a probar tras cambiar la regla de acceso.
Monitoriza el estado por clase de URL y no por un total sin diferenciar. Un artículo público que devuelve 401 merece una investigación distinta de un endpoint de cuenta que rechaza correctamente cualquier solicitud anónima. Guarda la muestra, la hora, el estado del solicitante y la URL final con cada incidencia, para que un cambio posterior se verifique en la misma condición.