Estrategia de indexación: noindex, duplicados y paginación

Rastreo e indexación: dos controles distintos

La confusión más cara del SEO técnico es creer que robots.txt y noindex hacen lo mismo. No. El robots.txt gobierna el rastreo: le dice al buscador qué URLs puede visitar. La etiqueta noindex gobierna la indexación: le dice qué páginas, una vez visitadas, no debe guardar en su índice. Son fases distintas de un mismo proceso, y confundirlas produce el error clásico. Si bloqueas una página con Disallow en robots.txt y le pones noindex, el buscador nunca la visita, así que nunca ve la etiqueta noindex, así que —si ya la conocía por enlaces externos— puede mantenerla en el índice sin poder leer tu orden de sacarla.

La regla que resuelve el enredo: para sacar del índice una página, déjala rastreable y ponle noindex; el buscador ha de poder entrar para leer la orden. Usa Disallow solo para lo que no quieres que se rastree en absoluto —ahorrar presupuesto de rastreo en zonas infinitas o irrelevantes—, sabiendo que eso no garantiza que no se indexe. Rastreo e indexación son dos puertas con dos llaves; usar la llave equivocada deja la puerta que querías cerrar abierta de par en par.

Un matiz para SSR y recursos que no son HTML: la orden de no indexar también viaja por la cabecera HTTP X-Robots-Tag, no sólo por la etiqueta <meta>. Es la única vía para un PDF o una imagen, que no tienen <head> donde colgar la etiqueta, y resulta cómoda en endpoints donde ya controlas la respuesta con sus cabeceras.

// noindex por cabecera, util para PDFs y respuestas de endpointexport const GET: APIRoute = () => {  return new Response(cuerpo, {    headers: { 'X-Robots-Tag': 'noindex' },  });};

noindex: sacar del índice sin esconder del rastreo

La orden de no indexar viaja en una <meta name="robots"> con el valor noindex, a menudo acompañada de nofollow cuando tampoco quieres que se sigan los enlaces de esa página. En nuestro componente <SEO /> ya reservamos una prop noindex para esto, de modo que marcar una página es pasar un booleano, no recordar una sintaxis.

---// dentro de src/components/SEO.astroconst { noindex = false } = Astro.props;---{noindex && <meta name="robots" content="noindex, nofollow" />}

---// una página que no debe indexarseimport Base from '../layouts/Base.astro';---<Base title="Gracias" description="Formulario recibido" noindex={true}>  <h1>Gracias por tu mensaje</h1></Base>

Los candidatos naturales al noindex son las páginas sin valor de búsqueda propio: resultados de búsqueda interna, páginas de agradecimiento, versiones de impresión, listados filtrados que sólo reordenan contenido que ya vive en otra URL. Sacarlas del índice no te resta; concentra la atención del buscador en las páginas que de verdad quieres que compitan, y evita que tu sitio parezca un almacén de contenido delgado y repetido.

El caso más traicionero es la navegación por facetas: una tienda con filtros de color, talla, marca y precio genera, al combinarlos, un número casi infinito de URLs, casi todas variantes triviales del mismo listado. Dejarlas entrar al índice lo inunda de contenido delgado; dejarlas rastrear sin freno agota el presupuesto de rastreo en un laberinto sin fondo. La respuesta combina las tres palancas de este nivel: noindex en las combinaciones sin valor de búsqueda, canónica hacia el listado limpio para consolidar señales, y Disallow en los parámetros que ni siquiera merece la pena visitar. Ninguna basta sola; el criterio está en repartir bien el trabajo entre ellas según lo que cada URL merezca.

Duplicados y la canónica como consolidador

El contenido duplicado rara vez es malicioso; casi siempre es un efecto colateral de cómo se generan las URLs. La misma ficha se alcanza con ?utm_source= de una campaña, con ?orden=precio de un filtro, con y sin barra final, por www y sin www. Para el buscador son direcciones distintas con el mismo contenido, y sin una señal clara reparte la autoridad entre todas y elige él cuál mostrar. La <link rel="canonical"> consolida ese reparto: todas las variantes apuntan a una misma URL limpia, y el buscador transfiere a ella las señales dispersas.

---// la canónica ignora el querystring y apunta a la ruta limpiaconst canonical = new URL(Astro.url.pathname, Astro.site);---<link rel="canonical" href={canonical.href} />

Deriva la canónica de Astro.url.pathname, que no incluye la cadena de consulta, y una URL con ?orden=precio declarará como canónica su versión sin parámetros. Aquí conviene un matiz que separa a quien entiende el mecanismo de quien lo aplica de memoria: la canónica es una pista fuerte, no una orden. El buscador la respeta casi siempre, pero puede ignorarla si detecta que las páginas no son realmente equivalentes. Por eso la canónica no sustituye al noindex: una consolida señales entre duplicados, la otra excluye del índice sin ambigüedad. Elige según la intención, no según cuál recuerdes primero.

Hay una forma de duplicado que la canónica no debe resolver: el mismo contenido en varios idiomas. Ahí las páginas no son copias que consolidar, sino equivalentes que el buscador debe servir según el usuario, y la señal correcta es hreflang, no la canónica. Cada versión declara con rel="alternate" sus hermanas por idioma, más una x-default para quien no encaje en ninguna, y todas se referencian entre sí de forma recíproca.

---// una etiqueta alternate por idioma, derivada de la config i18nconst alternativas = [  { lang: 'es', url: '/sobre-mi/' },  { lang: 'en', url: '/en/about/' },];---{alternativas.map((a) => (  <link rel="alternate" hreflang={a.lang} href={new URL(a.url, Astro.site).href} />))}

Como todo en este nivel, esas etiquetas se derivan de una sola fuente —tu configuración de idiomas— en lugar de copiarse página a página, de modo que añadir una traducción actualiza los enlaces recíprocos de todas sus hermanas sin tocarlas una a una.

Paginación: cada página se sostiene sola

Un listado largo se trocea con paginate, como viste en el nivel de rutas, y cada página recibe su prop page. La duda recurrente es qué canónica darle a la página 2, 3, 4. La tentación es apuntarlas todas a la página 1 para “concentrar” la autoridad, y es un error: colapsar las páginas contra la primera esconde del índice el contenido que sólo aparece a partir de la segunda. El consenso moderno es que cada página paginada sea autorreferente e indexable: la página 2 es canónica de sí misma, no de la 1.

---export async function getStaticPaths({ paginate }) {  const posts = await getCollection('blog');  return paginate(posts, { pageSize: 10 });}const { page } = Astro.props;const canonical = new URL(Astro.url.pathname, Astro.site);---<SEO  title={`Blog · página ${page.currentPage} de ${page.lastPage}`}  description="Artículos de la guía"  canonical={canonical}/>

Dar a cada página un título que incluya su número la hace única y evita que el buscador las vea como duplicados. Los antiguos <link rel="next"> y <link rel="prev"> ya no son señales de indexación para el buscador principal —se retiraron hace años—, así que la discoverabilidad recae en los enlaces de navegación reales entre páginas: mientras la página 3 sea alcanzable con un enlace rastreable desde la 2, el buscador llegará a ella. La paginación deja de ser un problema de SEO en cuanto la tratas como lo que es: un conjunto de páginas hermanas, cada una legítima, enlazadas entre sí.

Dos patrones de listado exigen cuidado extra. El scroll infinito carga las páginas siguientes con JavaScript al llegar al fondo, y si ese contenido no existe en el HTML ni tiene URLs rastreables detrás, el buscador nunca lo ve: la mejora de experiencia se paga en invisibilidad. La cura es respaldar el scroll infinito con paginación real —enlaces a URLs que sí existen— para que humanos y rastreadores lleguen al mismo contenido por caminos distintos. Y si el listado no es gigantesco, una página ver todo bien enlazada a veces indexa mejor que la serie troceada, porque concentra el contenido en una sola URL fuerte en lugar de repartirlo entre muchas débiles.