Rastreo e indexación: robots.txt, sitemap y códigos de estado HTTP

Google solo muestra una página después de tres etapas: Googlebot descarga la URL (rastreo), Google procesa el contenido y decide si lo guarda en el índice (indexación) y, en cada búsqueda, elige qué páginas del índice mostrar. Cuando una página no entra en el índice, los motivos que dependen del sitio son pocos y todos se pueden comprobar: el robots.txt impide el rastreo, la página tiene noindex, la URL canónica apunta a otra página, el servidor no responde 200, el contenido parece una página de error (soft 404), el contenido solo aparece después del JavaScript, o Google la rastreó y prefirió no indexarla. El informe Indexación de páginas de Search Console dice cuál de estos motivos se aplica a cada URL.

Alcance: esta guía trata de la Búsqueda de Google y se basa en la documentación de Google Search Central y en la ayuda de Search Console, consultadas en octubre de 2026. Bing y otros buscadores siguen estándares parecidos (el robots.txt, por ejemplo, está estandarizado en la RFC 9309), pero los comportamientos descritos aquí son los de Google.

Rastreo, indexación y publicación de resultados

Googlebot es el programa de Google que descarga las páginas. Descubre URLs siguiendo enlaces de páginas que ya conoce y leyendo sitemaps. Durante el rastreo, Google renderiza la página y ejecuta el JavaScript con una versión reciente de Chrome (Google Search Central, cómo funciona la Búsqueda).

En la indexación, Google analiza textos, imágenes y vídeos y guarda el resultado en el índice. Las páginas con contenido igual o parecido forman un grupo, y Google elige una de ellas como canónica: la versión que puede aparecer en los resultados.

En la publicación de resultados, Google elige entre las páginas indexadas las que considera más relevantes para la búsqueda. La misma documentación dice que Google no garantiza que vaya a rastrear, indexar o mostrar una página y que no acepta pagos para rastrear con más frecuencia ni para posicionar mejor.

Esta separación ayuda en el diagnóstico. Un problema de rastreo impide que Google lea la página; un problema de indexación ocurre después de que la ha leído. Los controles también son distintos: el robots.txt actúa en el rastreo, mientras que noindex y la canónica actúan en la indexación. Los datos estructurados actúan en la publicación de resultados, porque hacen que la página pueda optar a resultados enriquecidos como la ruta de navegación y el precio, y solo valen para páginas que Google puede rastrear e indexar. Las directrices de datos estructurados piden que esas páginas no estén bloqueadas por robots.txt, noindex u otro control de acceso. El artículo sobre datos estructurados trata esa parte.

robots.txt controla el rastreo, no la indexación

El robots.txt es un archivo de texto en la raíz del sitio (https://www.ejemplo.com/robots.txt) que indica qué rutas puede rastrear cada robot. Las reglas solo valen para el protocolo, el host y el puerto en que está publicado el archivo (Google, cómo interpreta Google el robots.txt).

User-agent: *
Disallow: /carrito/
Disallow: /buscar

Sitemap: https://www.ejemplo.com/sitemap.xml

Google describe el archivo como una forma de controlar el tráfico de robots, para no sobrecargar el servidor y para evitar el rastreo de páginas poco importantes o duplicadas. La misma página advierte que no sirve para mantener una página fuera de Google: una URL bloqueada todavía puede indexarse si otras páginas enlazan a ella, aunque aparece sin descripción (Google, introducción al robots.txt). En Search Console, este caso aparece como "Se ha indexado aunque un archivo robots.txt la tenía bloqueada".

Para sacar una página del índice, Google indica tres caminos: noindex, contraseña en el servidor o eliminar la página. Google no admite la regla noindex escrita dentro del robots.txt (Google, bloquear la indexación con noindex).

Un error en el propio robots.txt puede detener el rastreo de todo el sitio. Si el archivo responde con un error 5xx, Google deja de rastrear el sitio durante 12 horas mientras intenta descargarlo de nuevo. Después, durante un máximo de 30 días, usa la última versión buena que tenga en caché. El archivo también tiene un límite de 500 KiB; lo que pase de ahí se ignora. Google suele mantener el robots.txt en caché hasta 24 horas, así que una corrección puede tardar un día en aplicarse.

Permitir o bloquear robots de IA, como GPTBot y ClaudeBot, también se hace en el robots.txt. El artículo sobre robots de IA en el robots.txt trata los nombres de cada robot y la diferencia entre robots de búsqueda, de acceso del usuario y de entrenamiento.

noindex: meta robots y X-Robots-Tag

noindex es la regla que pide a Google que no muestre la página en los resultados. Puede ir en una metaetiqueta del HTML o en la cabecera HTTP X-Robots-Tag, con el mismo efecto (Google, bloquear la indexación con noindex).

<meta name="robots" content="noindex">

X-Robots-Tag: noindex

La cabecera es la forma de aplicar la regla a lo que no es HTML, como PDF, imágenes y vídeos. En la metaetiqueta, name="robots" vale para todos los buscadores que aceptan la regla y name="googlebot" vale solo para Google.

La trampa está en la combinación con el robots.txt. Para que el noindex funcione, Google tiene que rastrear la página y leer la regla. Si el robots.txt bloquea la URL, Googlebot nunca ve el noindex, y la página puede seguir indexada a partir de enlaces de otros sitios (Google, especificaciones de la metaetiqueta robots y de X-Robots-Tag). Si quieres sacar una página del índice, tienes que dejar el rastreo permitido hasta que Google lea el noindex.

Además de noindex, Google acepta nofollow (no seguir los enlaces de la página), none (equivale a noindex y nofollow juntos), nosnippet, max-snippet, max-image-preview, max-video-preview, unavailable_after, indexifembedded, notranslate y noimageindex. Cuando dos reglas entran en conflicto, se aplica la más restrictiva. noarchive y nocache se ignoran.

En sitios con JavaScript, el noindex exige un cuidado adicional. Si el HTML original tiene noindex, Google puede saltarse la renderización, y un script que quite la regla después puede no tener efecto. Si quieres la página indexada, el noindex no puede estar en el código original (Google, conceptos básicos de JavaScript para SEO).

Cualquier cambio en estas reglas solo surte efecto después de que Googlebot vuelva a rastrear la página. En páginas menos importantes, la documentación dice que eso puede tardar meses; la Inspección de URLs permite solicitar un nuevo rastreo.

Canónica: qué URL de un grupo de duplicados aparece

Los duplicados son URLs distintas con el mismo contenido, o casi el mismo. Ocurre con http y https, con y sin www, con y sin barra al final, con parámetros de campaña (?utm_source=) y con los filtros de una tienda online. Google agrupa esas URLs y elige una como canónica. Tú indicas tu preferencia; la elección final es de Google.

<link rel="canonical" href="https://www.ejemplo.com/producto/zapatillas-azules">

Las señales se suman: la etiqueta canónica y el sitemap apuntando a la misma URL refuerzan la elección. El problema es la señal contradictoria, como un sitemap que incluye una URL y una etiqueta canónica que apunta a otra. Google también desaconseja usar robots.txt o noindex para elegir la canónica: el primero deja que la URL se indexe sin contenido y el segundo saca la página de la búsqueda por completo (Google, cómo especificar una URL canónica).

En la Inspección de URLs de Search Console aparecen la canónica que declaraste y la que Google seleccionó. Cuando no coinciden, el informe Indexación de páginas muestra el motivo "Duplicada: Google ha elegido una versión canónica diferente a la del usuario" (ayuda de Search Console, Inspección de URLs).

Cuando el duplicado debe desaparecer, como en un cambio de http a https, la señal correcta es la redirección. El artículo sobre redirecciones, cadenas y bucles trata los tipos de redirección y cómo probarlas.

Sitemap: la lista de las URLs que quieres indexadas

El sitemap es un archivo, normalmente XML, que enumera las URLs del sitio. Google trata el envío como una sugerencia: puede que ni siquiera descargue el archivo y no promete rastrear todo lo que contiene (Google, crear y enviar un sitemap). Las reglas de la documentación:

• Cada archivo admite hasta 50.000 URLs o 50 MB sin comprimir. Por encima de eso, divídelo en varios sitemaps y enuméralos todos en un archivo de índice de sitemaps.

• La codificación debe ser UTF-8.

• Las URLs deben ser completas (https://www.ejemplo.com/pagina), porque Google rastrea exactamente lo que está escrito.

• Solo entran las versiones canónicas, las que quieres en los resultados.

• Google usa el lastmod solo cuando es coherente y se puede comprobar que es correcto. La fecha debe reflejar el último cambio significativo de la página. Un sitemap que marca todas las URLs con la fecha del día cada vez que se genera no cumple ese criterio.

• Google ignora priority y changefreq.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.ejemplo.com/producto/zapatillas-azules</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
</urlset>

Hay tres formas de enviarlo: el informe Sitemaps de Search Console, la API de Search Console o una línea Sitemap: en el robots.txt.

El sitemap no tiene relación con el llms.txt, un archivo propuesto para los modelos de lenguaje. En junio de 2026 Google añadió a su documentación que los archivos llms.txt no son necesarios para la Búsqueda de Google y no afectan a la visibilidad ni a la posición (Google Search Central, registro de actualizaciones). El artículo sobre llms.txt explica para qué sirve fuera de Google.

Estado HTTP: qué hace Googlebot con cada respuesta

El código de estado es el número de tres dígitos que el servidor devuelve junto con la página. El significado de cada código está en la RFC 9110; el tratamiento que les da Google está en la documentación de rastreo de Google.

Un soft 404 es una página que responde 200 pero muestra un mensaje de error o llega vacía, como un "producto no encontrado" servido con estado de éxito. Para el servidor todo está bien; para Google, es una página de error. La corrección es responder 404 o 410 cuando el contenido no existe, o poner contenido real si la página debería existir. En sitios grandes, la guía del presupuesto de rastreo recuerda que las páginas soft 404 se siguen rastreando y gastan ese presupuesto.

JavaScript: cuando el contenido depende de la renderización

En sitios que montan la página en el navegador, el HTML que entrega el servidor puede llegar casi vacío. Google procesa estas páginas en tres fases: rastreo, renderización e indexación. Toda página con estado 200 entra en una cola de renderización, salvo que tenga noindex. Puede esperar unos segundos o más hasta que un Chromium sin interfaz ejecute el JavaScript. Las páginas con un estado distinto de 200 pueden no renderizarse (Google, conceptos básicos de JavaScript para SEO).

Puntos que destaca la documentación:

• Google solo descubre enlaces que son elementos <a> con atributo href. Una navegación hecha solo con eventos de clic no sirve como enlace.

• Las rutas con fragmento (#/productos) no se resuelven de forma fiable. Usa la History API con rutas reales.

• En las aplicaciones de una sola página, una ruta inexistente suele responder 200. Google sugiere redirigir con JavaScript a una URL que responda 404 o insertar noindex en las pantallas de error.

• Un noindex en el HTML original puede hacer que Google se salte la renderización.

Google sigue recomendando la renderización en el servidor o la prerrenderización, porque no todos los robots ejecutan JavaScript.

Los motivos del informe Indexación de páginas

En Search Console, el informe Indexación de páginas enumera las URLs que Google conoce y, para las no indexadas, el motivo. Los nombres de abajo son los de la interfaz en español (ayuda de Search Console, informe de indexación de páginas).

Entre las páginas indexadas, el informe puede mostrar dos advertencias: "Se ha indexado aunque un archivo robots.txt la tenía bloqueada" y "La página se ha indexado sin contenido", cuando Google no pudo leer el contenido.

Checklist: la página no se ha indexado

1. Abre la URL en la Inspección de URLs de Search Console. Muestra el estado, el último rastreo y la canónica elegida por Google. El resultado por defecto es la versión indexada; la prueba en directo descarga la página en ese momento.

2. Comprueba el estado HTTP. La URL tiene que responder 200 por sí misma, sin redirección:

   curl -sI https://www.ejemplo.com/pagina

3. Comprueba que el robots.txt permite la ruta a Googlebot.

4. Busca noindex en el HTML original y en la cabecera X-Robots-Tag. El comando del paso 2 muestra las cabeceras.

5. Comprueba la canónica. La etiqueta debe apuntar a la propia URL, o a la versión que quieres indexada, y el sitemap debe incluir esa misma URL.

6. Mira el HTML que recibió Google (la Inspección de URLs muestra el HTML y las cabeceras). El contenido principal tiene que estar ahí, y no aparecer solo después de clics en el navegador.

7. Descarta el soft 404: la página tiene contenido propio y no parece un mensaje de error.

8. Asegúrate de que la página se puede encontrar: está en el sitemap y recibe enlaces <a href> de otras páginas del sitio.

9. Lee el motivo en el informe Indexación de páginas y sigue la fila correspondiente de la tabla de arriba.

10. Si el motivo es "Rastreada: actualmente sin indexar", no hay ningún bloqueo técnico que quitar. La recomendación aquí es revisar el contenido, no la configuración: las páginas muy parecidas a otras del sitio o con poco texto propio son las primeras candidatas. Google no publica los criterios exactos de esta decisión.

11. Si el motivo es "Descubierta: actualmente sin indexar", mira el servidor: las respuestas 5xx y 429 hacen que Google reduzca el ritmo de rastreo. La guía del presupuesto de rastreo está escrita para sitios grandes (alrededor de 1 millón de páginas, o 10.000 con cambios diarios, cifras que el propio Google llama aproximadas) y para sitios con muchas URLs en este estado.

12. Después de corregir, solicita la indexación en la Inspección de URLs. Hay un límite diario de solicitudes y la solicitud no garantiza la indexación; para muchas URLs, el camino es el sitemap.

Cómo revisar tu sitio

Parte de estas comprobaciones se puede hacer con las herramientas gratuitas de WebVyze. El validador de robots.txt revisa la sintaxis, el sitemap declarado y qué robots (Google, Bing y robots de IA, separando búsqueda y entrenamiento) pueden rastrear una ruta. También están el validador de sitemap, el verificador de redirecciones y el validador de datos estructurados. Estas herramientas leen las páginas públicas del sitio; el motivo exacto por el que una URL no está indexada solo aparece en Search Console.