Código de estado HTTP 200

Qué comprueba esta verificación

Envía una petición GET a la URL auditada y lee el código de estado HTTP final. La verificación sólo pasa con 200 OK. Marca:

• Redirecciones 3xx (la URL no es la canónica)
• Errores 4xx (404 página no encontrada, 410 gone, 403 prohibido)
• Errores 5xx (caída del servidor, gateway timeout)

El rastreador sigue un número pequeño de redirecciones para poder decirte también el estado final al final de la cadena.

Por qué importa

Los buscadores y los rastreadores de IA tratan las respuestas distintas de 200 como “no indexes esta URL”.

• 301/302 — la URL no posiciona; el destino de la redirección sí. Si has compartido example.com/old-post y hace un 301 a example.com/new-post, cada backlink, cada compartición social, cada selección como featured snippet apunta a una URL que Google sacará de su índice en unas semanas.
• 404 / 410 — la URL se elimina del índice. Si esto ha ocurrido por accidente (un typo en una regla de redirección, una barra final que falta, una página borrada que aún tiene backlinks), estás perdiendo tráfico en silencio.
• 500 / 502 / 503 / 504 — Google reintenta, y desindexa tras unos días de fallos. Peor aún, Googlebot reducirá el crawl budget para todo el dominio.

Una página que devuelve cualquier cosa distinta de 200 es invisible.

Cómo arreglarlo

Primero, mira exactamente qué devuelve el servidor. curl -I muestra la cadena completa:

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Añade -L y -w "%{http_code} -> %{redirect_url}\n" para mapear cada salto. Si ves varias filas 30x antes del 200 final, tienes una cadena de redirecciones — también vale la pena arreglarla.

Si la URL debería devolver 200 pero devuelve 301/302:

Sospechosos habituales:

• Discrepancia de WWW o barra final — example.com/page hace 301 a example.com/page/. Elige una forma canónica (con o sin barra) y enlaza a ella consistentemente. No enlaces a la forma que redirige internamente.
• Subida a HTTPS — http://example.com/page hace 301 a https://example.com/page. Esperable, pero asegúrate de que todos los enlaces internos y el sitemap usan HTTPS para que los rastreadores nunca toquen la redirección. Mira Redirigir HTTP a HTTPS.
• Redirección por idioma en la ruta raíz — / hace 302 a /en/ según Accept-Language. Googlebot rastrea desde EE. UU. con en-US, así que / se convierte en una redirección a /en/. O haces que / sirva el contenido en inglés directamente (con hreflang para los otros idiomas), o usas un 302 más x-default hreflang.

Si la URL devuelve 404 por accidente:

• Revisa la configuración de routing (try_files de nginx, [...slug].tsx de Next.js, getStaticPaths de Astro).
• Revisa la sensibilidad a mayúsculas — /About y /about son URLs diferentes en servidores Linux.
• Revisa la base de datos — una página del CMS marcada como “borrador” devuelve 404 en la mayoría de las plantillas.

Si la página se ha ido de verdad, devuelve 410 Gone en lugar de 404 — Google desindexa los 410 unas dos veces más rápido. Configura una página 404 personalizada para que la respuesta siga siendo útil para los humanos.

Si la URL devuelve 5xx:

Esto es un problema de servidor, no de configuración. Revisa los logs de la aplicación con la marca de tiempo en que MetricSpot ejecutó la auditoría. Causas habituales: pool de conexiones a base de datos agotado, falta de memoria en una función serverless, una API de terceros de la que depende la página devolvió timeout.

Recetas:

# nginx — explicit 200 for a route, no redirect
location = /pricing {
  try_files /pricing.html =404;
}

// Express — return 410 for permanently removed URLs
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — return 410 from a route segment
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // returns 404 by default
  // ...
}

Para sitios estáticos de Astro, un 410 lo tiene que servir tu host (return 410; en nginx o un Cloudflare Worker), ya que la salida estática de Astro sólo emite 404 para rutas inexistentes.

Preguntas frecuentes

¿Un 301 siempre es malo?

No. Un 301 es correcto cuando la URL realmente se ha movido — slug antiguo a slug nuevo, HTTP a HTTPS, www a no-www. Sólo es malo cuando MetricSpot audita la URL que pretendes que sea canónica y hace 301 hacia otra — eso significa que nos has dado (y a Google, y a cada backlink) la URL equivocada.

¿Debería devolver 200 para páginas inexistentes con un mensaje de “no encontrado”?

No. Devolver 200 con un cuerpo “página no encontrada” se llama soft 404. Google lo detecta (por patrón de contenido) y lo trata como 404 igualmente, pero confunde a la analítica e infla tu crawl budget. Devuelve siempre el código HTTP correcto.

¿Y qué pasa con el 304 Not Modified?

304 es una respuesta condicional exitosa — el navegador ya tiene la página en caché. No es un problema; MetricSpot no envía cabeceras If-Modified-Since, así que normalmente no lo verás en nuestro rastreo. Si lo ves, tu CDN está siendo demasiado agresivo cacheando respuestas a GETs no autenticados.