Ir al contenido 
Códigos de estado HTTP controlar cómo los rastreadores realizan consultas, cargan contenidos y si las páginas aparecen en la búsqueda. Muestro cómo respuestas como 200, 301, 404 o 503 hacen que el rastreo, el presupuesto de rastreo y el alojamiento interactúen y dónde se encuentran los frenos típicos.
Puntos centrales
- Presupuesto depende directamente de respuestas de estado limpias.
- 2xx/3xx Permitir indexación, bloquear 4xx/5xx.
- Reenvío Utilizar solo sin cadenas ni bucles.
- tiempos de servidor y el tiempo de actividad generan confianza en los rastreadores.
- Monitoreo operar con registros, GSC y rastreadores.
Por qué los códigos de estado controlan el rastreo
Los rastreadores comprueban primero el Código de estado, solo después se procede al renderizado y la evaluación del contenido. Por lo tanto, doy prioridad a la corrección de la respuesta antes que a las etiquetas de título o los enlaces internos. Un 200 OK carga el contenido inmediatamente, mientras que los 4xx y 5xx cuestan tiempo, presupuesto y confianza. Si los errores se acumulan, el bot reduce las consultas y retrasa la inclusión de nuevos contenidos. Esto da lugar a pérdidas silenciosas de SEO, que pueden evitarse con reglas claras para Respuestas del servidor evitar.
2xx: El camino directo al índice
El 200 OK es para los rastreadores un Luz verde. Solo entrego 200 a páginas reales con contenido completo y evito los Soft-404, que envían 200, pero no ofrecen ningún valor añadido. El contenido escaso, la falta de H1 o los textos casi idénticos son señales de advertencia de este tipo de configuraciones erróneas. Quien limpie aquí ahorra presupuesto de rastreo y refuerza la relevancia temática. Además, optimizo fragmentos y referencias internas para que los rastreadores y los usuarios con un llamada alcanzar los objetivos correctos.
3xx: Redireccionamientos sin pérdida
301 traslada contenidos de forma permanente y transfiere señales a la nueva URL, mientras que 302 representa una solución temporal. Utilizo 301 cuando el contenido se ha trasladado realmente y elimino cadenas y bucles, ya que cada salto adicional consume tiempo y presupuesto. Comprueba los enlaces internos, ya que una cadena interna 301 es un atasco creado por uno mismo. Para los traslados, planifico reglas coherentes para que todo apunte a la URL de destino en una línea clara. En Cadenas de redireccionamiento, que afectan de forma cuantificable al tiempo de carga y al rastreo.
4xx: Señales claras para contenidos eliminados
Un 404 lo comunica claramente: este Recursos No existe. Dejo el 404 para páginas realmente eliminadas y evito los Soft-404, ya que nunca envío 200 en las páginas de error. El 410 indica aún más claramente que una página ha sido eliminada de forma permanente; lo utilizo específicamente para las URL antiguas que no tienen alternativas adecuadas. Los enlaces internos a 404 desperdician presupuesto, por lo que los corrijo rápidamente o redirijo específicamente a la mejor alternativa temática. De esta manera, mantengo los rastreadores en las páginas que son realmente Valor entregar.
5xx: los errores del servidor ralentizan los bots y los usuarios
5xx significa: El servidor no pudo procesar la solicitud. servir. Si se acumulan, los rastreadores clasifican el sitio como poco fiable y lo visitan con menos frecuencia. Para el mantenimiento, utilizo 503 con „Retry-After“ para que los bots sepan cuándo es conveniente volver a realizar una consulta. Si un 503 persiste, evalúo los registros y soluciono los cuellos de botella en la CPU, la RAM, la base de datos o los límites de velocidad. Para WordPress, recopilo consejos prácticos en esta guía sobre Errores 503, para que las ventanas de mantenimiento sean controladas y breves.
Almacenamiento en caché, 304 y ETags: ahorre presupuesto sin riesgos
304 Not Modified ahorra Ancho de banda, porque el cliente puede seguir utilizando su copia. Configuré ETag o Last-Modified correctamente para que los rastreadores puedan utilizar If-Modified-Since de forma adecuada. De este modo, se reducen las recuperaciones de CSS, JavaScript e imágenes sin modificar. Si la lógica no es correcta, el bot carga muchos archivos innecesariamente o se pierde actualizaciones. Por eso pruebo variantes, compruebo los encabezados de respuesta y mantengo las respuestas 304 consistentes en todos los Activos.
Presupuesto de rastreo: cómo mantenerlo alto
El presupuesto de rastreo depende de tres factores: calidad del código, Actuación y estructura interna. Reduzco las pérdidas de tiempo, como las cadenas de reenvío, el contenido duplicado y el TTFB lento. Dirijo los enlaces internos a unas pocas rutas claras para que los bots reconozcan las prioridades más rápidamente. Corrijo rápidamente las páginas defectuosas o huérfanas antes de que consuman presupuesto. Esto incluye códigos de estado para paginaciones, canonicals y hreflang, que sin Señales de error tener que correr.
Factores de alojamiento que influyen en los códigos de estado
Buen hardware, configuración limpia del servidor y capacidad adecuada. Almacenamiento en caché Evita picos 5xx. Me aseguro de que haya suficientes trabajadores PHP, parámetros de base de datos, Keep-Alive y HTTP/2 o HTTP/3. También se deben establecer límites de velocidad para los bots de manera sensata, para que no se bloqueen los usuarios reales. En caso de picos de carga elevados, son útiles las cachés perimetrales y las reglas para activos estáticos. Aquí muestro por qué los códigos de estado y el rendimiento del alojamiento están relacionados: Estado HTTP y potencia del servidor.
Monitorización: uso correcto de registros, GSC y rastreadores
Empiezo con los registros del servidor porque son auténticos. Consultas y anotar cada respuesta. A continuación, compruebo la Search Console en busca de errores de cobertura, mapas del sitio y estado de renderización. Un rastreo de escritorio y móvil con un rastreador SEO detecta redireccionamientos, 4xx y 5xx en una sola pasada. Para análisis profundos, correlaciono los errores con las fechas de los lanzamientos o los picos de tráfico. Esto muestra si un lanzamiento, un plugin o un conjunto de reglas CDN son los responsables. Respuestas ha cambiado.
Resumen rápido: códigos de estado y medidas
La siguiente tabla clasifica las respuestas típicas según los pasos adecuados y destaca los puntos de alojamiento. La utilizo como guía para tomar decisiones rápidas en el día a día.
| Código de estado | Reacción del rastreador | Acción | Aviso sobre el alojamiento |
|---|---|---|---|
| 200 De acuerdo. | El contenido se recupera y evalúa. | Proporcionar contenido auténtico, evitar los errores 404 suaves | Mantener bajo el TTFB, caché caliente |
| 301 Movido permanentemente | Señales a la URL de destino | Eliminar cadenas, actualizar enlaces internos | Mantener claras las reglas de reescritura |
| 302 Encontrado | Temporal, la fuente conserva las señales | Usar solo a corto plazo | Comprobar periódicamente |
| 304 No modificado | Usar caché, sin descarga | Configurar correctamente ETag/Last-Modified | Entrega de activos a través de CDN |
| 404 No encontrado | La URL se eliminará del índice. | Corregir enlaces internos, evitar errores 404 suaves | Mantener la página de error ligera |
| 410 Se ha ido | Eliminación más rápida | Utilizar para contenidos eliminados de forma permanente | Reenvío solo en caso de alternativa real |
| 500 Error interno | El bot reduce las visitas | Comprobar registros, solucionar la causa | Aumentar los recursos y los límites |
| 503 Servicio no disponible | Modo de mantenimiento aceptado | „Establecer “Retry-After», mantener una duración breve | Planificar ventanas de mantenimiento |
Tratamiento de errores: lo primero que compruebo
Empiezo con el Ámbito: ¿El error afecta a todos los usuarios, solo a los bots o solo a los dispositivos móviles? A continuación, compruebo si el último cambio se ha producido en el servidor, en la aplicación o en la CDN. Si el error solo se produce bajo carga, aumento los recursos a corto plazo y busco cuellos de botella en los registros. En caso de 5xx recurrentes, configuro alertas en patrones de registro y puntos finales de estado. De este modo, resuelvo rápidamente los problemas urgentes y evito que afecten al Presupuesto seguir reduciendo.
Comprobaciones técnicas antes de los lanzamientos
Antes de cada lanzamiento, pruebo las rutas críticas con un Puesta en escena-Rastreo y comparo los códigos de estado con la versión en vivo. Tengo preparada una lista de URL importantes: página de inicio, categoría, producto, filtro, búsqueda, mapa del sitio, API. A continuación, compruebo encabezados como Cache-Control, Vary, reglas de redireccionamiento y canónicos. Para los indicadores de características, establezco condiciones claras para que no generen 302 o 404 de forma involuntaria. Solo cuando los códigos de estado, los tiempos de carga y los resultados de renderización parecen estables, doy el visto bueno. Publique gratis.
robots.txt, mapas del sitio y URL secundarias
Primero compruebo si robots.txt Estable con 200 respuestas. 5xx o 403 en robots.txt desestabilizan a los rastreadores y ralentizan el rastreo. Un 404 en robots.txt se considera „sin restricciones“, pero es una mala señal en sitios con problemas de rastreo. Para Sitemaps Solo acepto 200 y mantengo los archivos pequeños, limpios, comprimidos con gzip y con campos lastmod correctos. Los 3xx al mapa del sitio están técnicamente permitidos, pero los evito en favor de una respuesta 200 directa. Para Fuentes, AMP- o API-Recursos: me aseguro de que no devuelvan 404 o 5xx cuando la página HTML devuelve 200; de lo contrario, el renderizado o la evaluación de datos estructurados se interrumpen de forma inconsistente.
Canonical, hreflang y paginación solo en 200
Señales como rel=canonical, hreflang o la paginación solo surten efecto si las URL de destino y de referencia se cargan con 200 final. Evito las URL canónicas en 3xx, 404 o noindex, porque confunden al rastreador. Para hreflang, compruebo el referencia inversa y que cada variante termine finalmente en 200. Las listas paginadas (página=2,3,...) deben proporcionar un 200 estable; evito que las páginas vacías provoquen un error 404 suave ofreciendo contenidos claros y enlaces internos cuando faltan resultados, pero enviando el estado correcto.
429 y utilizar correctamente los límites de velocidad
429 Demasiadas solicitudes es mi herramienta para la restricción granular cuando algunos bots son demasiado agresivos. Yo utilizo Reintentar después de con una indicación de tiempo razonable, para que los rastreadores escalonen sus solicitudes. 429 no sustituye al 503 de mantenimiento y nunca debería afectar a los usuarios legítimos. En el WAF o CDN, diferencio según el agente de usuario, la IP y las rutas, para que los activos multimedia sigan entregando 200/304, mientras que el HTML se ralentiza brevemente. Importante: el 429 no debe ser permanente, de lo contrario, el bot considerará que el sitio es de difícil acceso y reducirá el presupuesto.
401/403/451: bloqueado intencionadamente, pero de forma coherente
401 Lo utilizo para áreas protegidas con contraseña., 403 para accesos prohibidos. Me aseguro de que estas respuestas no se apliquen accidentalmente a Googlebot, por ejemplo, mediante filtros de bots estrictos. En caso de bloqueos geográficos o requisitos legales, utilizo 451 y documento los motivos internamente. Renuncio a las respuestas 200 con intersticiales („Acceso denegado“): estas páginas actúan como Soft-404. Cuando existen alternativas, enlazo claramente a contenidos accesibles y dejo que la URL bloqueada envíe el estado 4xx correcto.
Paridad de respuestas: móvil, escritorio y reproducción dinámica
Me aseguro de que los bots móviles y de escritorio tengan los mismos Códigos de estado Ver. Las reproducciones dinámicas (pruebas A/B, indicadores de funciones, contenido geográfico) no deben activar 302/403 para agentes de usuario individuales. Yo utilizo VariarUtiliza los encabezados con moderación y de forma consciente (por ejemplo, Accept-Language) para evitar divisiones innecesarias de la caché y asegúrate de que todas las rutas terminen de forma coherente en 200/304 para todas las variantes. Las rupturas de paridad provocan problemas de indexación cuando el bot ve un 404, mientras que los usuarios reciben un 200. Yo elimino estos casos con reglas claras y pruebas por variante.
HEAD, OPTIONS y puntos finales API
Muchos rastreadores envían HEAD-Solicitudes para comprobar la disponibilidad y el tamaño. Mi servidor responde con la misma lógica que con GET, solo que sin cuerpo. Evito 405 en HEAD si GET devuelve 200. OPCIONES y CORS Preflights para que los activos de fuentes externas se puedan cargar correctamente. Para Puntos finales de la API, Cuando las API proporcionan datos durante el renderizado, presto atención a los códigos 200/304 estables y a los códigos 4xx claros en caso de errores reales. Si las API proporcionan esporádicamente códigos 5xx, lo marco por separado en los registros, ya que puede explicar errores de renderizado internos, aunque la página HTML envíe un código 200.
Reglas CDN, estrategias Stale y protección 5xx
En la CDN almaceno en caché 200, 301 y 404 estáticos de forma controlada, pero evito que 503 o las páginas de administración terminan en la caché. Con stale-if-error puedo puentear 5xx temporales sin que los bots vean errores. Establezco Control sustituto para señales Edge y mantengo los TTL para HTML más cortos que para los activos. Configuro los ETags seguro para clústeres (ya sea igual en todas partes o desactivado) para que 304 funcione de forma fiable y no caduque debido a hash divergentes. Importante: los redireccionamientos (301/302) no deben almacenarse en caché indefinidamente en la CDN, ya que de lo contrario las rutas antiguas permanecerán como cadenas.
Casos de comercio electrónico: agotado, variantes, filtros
Si los productos no están disponibles temporalmente, la página del producto permanecerá en 200 con una identificación clara y enlaces internos útiles (categoría, alternativas). En el caso de productos retirados de forma permanente, decido entre 301 a la mejor URL sustitutiva (solo en caso de correspondencia real) y 410, si no hay una alternativa adecuada. Evito las redirecciones masivas a la página de inicio, ya que funcionan como Soft-404. Para URL de filtros y parámetros Utilizo reglas claras: solo combinaciones relevantes para el índice en 200, todo lo demás a través de 301 a la URL canónica o con noindex, pero nunca 200 para páginas vacías o casi idénticas que activan el detector Soft-404.
Separar claramente noindex, robots y códigos de estado
noindex Es una señal de contenido, el código de estado es una señal de transporte. Evito las formas mixtas que confunden a los rastreadores: nada de 301 en una página noindex, nada de 200 con un marcador de posición „acceso restringido“ si el recurso no existe. O bien una página es indexable (200 + index) o bien se ha eliminado (404/410) o bien no está disponible temporalmente (503 con Retry-After). robots.txt solo bloquea el rastreo, no la indexación de URL ya conocidas. Por eso, para contenidos realmente eliminados, utilizo 404/410 en lugar de bloqueos de robots.
Indicadores y valores umbral que observo
- Tasa 5xx: permanentemente muy por debajo de 0,11 TP3T. Investigar inmediatamente los picos.
- Tasa 4xx: dependiendo del tipo de sitio, entre 1 y 2%. Los 4xx internos deben ir a 0%.
- Porcentaje 3xx: lo más bajo posible; Cadenas de redireccionamiento a 0.
- Porcentaje de 304 En el caso de los activos: alto es bueno, indicador de que el almacenamiento en caché funciona correctamente.
- TTFB Para HTML: estable y bajo; correlaciono los valores atípicos con 5xx/429.
- Mapa del sitio-Salud: 200, último modelo válido, sin enlaces rotos.
- Paridad Móvil frente a ordenador: mismos códigos de estado y URL finales.
Relaciono estas métricas con implementaciones, picos de tráfico y eventos de infraestructura. De esta manera, reconozco patrones que Presupuesto influyen mucho antes de que reaccionen los rankings.
Casos extremos: 1xx, 405, 410 frente a 404
1xxLas respuestas son prácticamente irrelevantes para el SEO; solo me aseguro de que el servidor y la CDN se actualicen correctamente (por ejemplo, HTTP/2/3). 405 Método no permitido aparece cuando HEAD/POST están bloqueados, aunque GET devuelve 200; esto es inofensivo, pero debe configurarse de forma coherente. Al elegir 404 frente a 410 Utilizo 410 para contenidos eliminados deliberadamente con carácter permanente, 404 para rutas desconocidas o enlazadas accidentalmente. Es importante la Coherencia, para que los rastreadores puedan aprender de patrones recurrentes.
Estrategias de reversión y fiabilidad
Planifico los lanzamientos de manera que pueda volver rápidamente en caso de códigos de estado erróneos: Azul/Verde-Implementaciones, indicadores de características de grano fino y reglas de reescritura reversibles. Para el mantenimiento utilizo Páginas de mantenimiento, que devuelven 503 mientras se ejecutan tareas en segundo plano. A nivel de infraestructura, mantengo controles de estado, reinicios automáticos y límites de velocidad que interceptan los ataques sin paralizar el rastreo legítimo. Cada medida tiene como objetivo, 200/304 y mantener los errores 4xx/5xx controlados, breves y comprensibles en caso de fallo.
Resumen: señales claras, rastreo más rápido
Me encargo de que todo el mundo Código de estado transmite un mensaje claro: 2xx para contenidos, 3xx sin cadenas, 4xx para páginas eliminadas y 5xx solo en casos realmente excepcionales. El almacenamiento en caché con 304 alivia la carga del servidor, mientras que las respuestas 200 consistentes dan confianza al bot. Para que esto funcione, combino análisis de registros, datos de GSC y rastreos recurrentes. En el lado del host, mantengo bajos los tiempos de respuesta, establezco límites razonables y planifico el mantenimiento de forma clara. De este modo, aumentan la calidad, la indexabilidad y la visibilidad, y eso Presupuesto fluye hacia donde más rendimiento tiene.
