Auditoría de integridad de códigos de estado

Los frameworks modernos sirven 200 para casi todo, así que un producto borrado, un filtro sin resultados y una llamada fallida a un tercero parecen todos páginas sanas para un rastreador. Google tiene entonces que adivinar, mediante su detección de soft 404, que es lenta y poco fiable. El arreglo reflejo de añadir noindex es incorrecto para la mayoría de estos estados, porque mantiene la URL en la cola de rastreo indefinidamente en lugar de retirarla.

El archivo de la habilidad

---
name: status-code-integrity-audit
description: Úsala cuando páginas eliminadas, vacías o con error devuelvan 200 OK, cuando aparezcan soft 404 en Search Console, o antes de retirar un lote de URL de un sitio.
---

# Auditoría de integridad de códigos de estado

Los frameworks modernos sirven 200 para casi todo, así que un producto borrado, un filtro sin resultados y una llamada fallida a un tercero parecen todos páginas sanas para un rastreador. Google tiene entonces que adivinar, mediante su detección de soft 404, que es lenta y poco fiable. El arreglo reflejo de añadir noindex es incorrecto para la mayoría de estos estados, porque mantiene la URL en la cola de rastreo indefinidamente en lugar de retirarla.

## Qué necesitas antes

- Una exportación de rastreo con códigos de estado, más la lista de soft 404 de Search Console
- Una lista de todos los estados que la aplicación puede producir sin contenido útil, sacada del código o de los desarrolladores y no de un rastreo
- Acceso por línea de comandos para pedir URL y leer las cabeceras de respuesta en bruto
- Capacidad de cambiar los códigos de estado en la aplicación y de ver qué hace el CDN con ellos

## Método

1. Enumera los estados de fallo desde el código junto con los desarrolladores: elemento borrado, búsqueda o filtro sin resultados, anuncio caducado, agotado de forma permanente, contenido tras login, dependencia de API caída. Un rastreo solo encuentra los estados que ya están enlazados, que son la minoría.
2. Pide una URL por estado desde la línea de comandos y anota el estado de la cabecera, no lo que diga el cuerpo de la página. Una página que pone "no encontrada" mientras envía un 200 es el hallazgo más habitual de esta auditoría y es invisible en un navegador.
3. Asigna el código correcto a cada estado: 404 cuando la cosa ya no está y no tiene equivalente, 410 cuando estés seguro y quieras una retirada más rápida, 301 cuando exista un sustituto uno a uno de verdad, 200 con contenido real cuando la página siga cumpliendo una función, y 503 con Retry-After para las paradas planificadas.
4. Comprueba qué pasa bajo carga y durante los fallos de dependencias. Un servidor que responde 200 con una página de error esconde una caída a la monitorización y a Google, mientras que un 503 correcto hace que el rastreo se modere y luego se reanude sin perder indexación.
5. Concilia la lista con el informe de soft 404. Cada entrada de ahí es Google diciendo que no está de acuerdo con tu 200, y es la confirmación más barata que vas a tener de que un estado está mal clasificado.
6. Verifica a nivel de cabecera después de desplegar, porque un edge worker, una regla de caché o una página de error personalizada pueden reescribir un estado que la aplicación había puesto bien, y los logs de la aplicación mostrarán el correcto.
7. Vigila las estadísticas de rastreo durante dos semanas. Un lote grande de 404 o 410 nuevos produce una gráfica alarmante que es esperable y se corrige sola; una subida de 5xx en esa misma ventana no lo es, y hay que pararla.

## Qué produce esto

Un mapa de códigos de respuesta estado por estado con el código actual y el correcto de cada uno, y una comprobación verificada a nivel de cabecera que confirma qué envía producción realmente.

## Dónde falla esto

- Redirigir cada página retirada a la home, lo que Google trata igualmente como un soft 404 mientras destruye la señal de que la página ya no está
- Servir un 200 con noindex en un estado vacío, con lo que la URL se queda en la cola de rastreo para siempre y no se va nunca
- Probar en un navegador, donde un router en cliente o un service worker pueden pintar una página 404 que se entregó con una cabecera 200
- Responder 404 durante una ventana de mantenimiento en lugar de 503, lo que saca del índice páginas que funcionan por culpa de una hora

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/status-code-integrity-audit

Qué necesitas antes

• Una exportación de rastreo con códigos de estado, más la lista de soft 404 de Search Console
• Una lista de todos los estados que la aplicación puede producir sin contenido útil, sacada del código o de los desarrolladores y no de un rastreo
• Acceso por línea de comandos para pedir URL y leer las cabeceras de respuesta en bruto
• Capacidad de cambiar los códigos de estado en la aplicación y de ver qué hace el CDN con ellos

Método

1. 01 Enumera los estados de fallo desde el código junto con los desarrolladores: elemento borrado, búsqueda o filtro sin resultados, anuncio caducado, agotado de forma permanente, contenido tras login, dependencia de API caída. Un rastreo solo encuentra los estados que ya están enlazados, que son la minoría.
2. 02 Pide una URL por estado desde la línea de comandos y anota el estado de la cabecera, no lo que diga el cuerpo de la página. Una página que pone "no encontrada" mientras envía un 200 es el hallazgo más habitual de esta auditoría y es invisible en un navegador.
3. 03 Asigna el código correcto a cada estado: 404 cuando la cosa ya no está y no tiene equivalente, 410 cuando estés seguro y quieras una retirada más rápida, 301 cuando exista un sustituto uno a uno de verdad, 200 con contenido real cuando la página siga cumpliendo una función, y 503 con Retry-After para las paradas planificadas.
4. 04 Comprueba qué pasa bajo carga y durante los fallos de dependencias. Un servidor que responde 200 con una página de error esconde una caída a la monitorización y a Google, mientras que un 503 correcto hace que el rastreo se modere y luego se reanude sin perder indexación.
5. 05 Concilia la lista con el informe de soft 404. Cada entrada de ahí es Google diciendo que no está de acuerdo con tu 200, y es la confirmación más barata que vas a tener de que un estado está mal clasificado.
6. 06 Verifica a nivel de cabecera después de desplegar, porque un edge worker, una regla de caché o una página de error personalizada pueden reescribir un estado que la aplicación había puesto bien, y los logs de la aplicación mostrarán el correcto.
7. 07 Vigila las estadísticas de rastreo durante dos semanas. Un lote grande de 404 o 410 nuevos produce una gráfica alarmante que es esperable y se corrige sola; una subida de 5xx en esa misma ventana no lo es, y hay que pararla.

Qué produce esto

Un mapa de códigos de respuesta estado por estado con el código actual y el correcto de cada uno, y una comprobación verificada a nivel de cabecera que confirma qué envía producción realmente.

Dónde falla esto

• Redirigir cada página retirada a la home, lo que Google trata igualmente como un soft 404 mientras destruye la señal de que la página ya no está
• Servir un 200 con noindex en un estado vacío, con lo que la URL se queda en la cola de rastreo para siempre y no se va nunca
• Probar en un navegador, donde un router en cliente o un service worker pueden pintar una página 404 que se entregó con una cabecera 200
• Responder 404 durante una ventana de mantenimiento en lugar de 503, lo que saca del índice páginas que funcionan por culpa de una hora

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en SEO técnico