Qué no indexar

Si el artículo sobre qué indexar establece los criterios generales, este artículo desciende al detalle: cada tipo de página que habitualmente no debe indexarse, por qué, y cómo implementar esa decisión correctamente.

Archivos de etiqueta

Por qué no indexar: Los archivos de etiqueta son listas de artículos agrupados por un término descriptivo. En la mayoría de casos, esas listas no tienen contenido editorial propio: son una selección automática de extractos. Un usuario que llega desde un buscador a la página de la etiqueta “canonicalización” no encuentra nada que no pudiera encontrar mejor buscando directamente los artículos sobre ese tema.

Además, los archivos de etiqueta tienen una tendencia natural al contenido fino: muchas etiquetas se crean con uno o dos artículos asociados, lo que produce páginas de archivo con muy poco contenido.

Excepción: Una etiqueta con decenas de artículos asociados, con una descripción editorial propia extensa y con interés de búsqueda real como término puede indexarse. Pero es la excepción, no la regla.

Implementación en WordPress: En el plugin de SEO, configurar la taxonomía post_tag como noindex globalmente. Las excepciones se configuran individualmente por término.

<meta name="robots" content="noindex, follow" />

Páginas de paginación de archivos

Por qué no indexar: La página 2, 3, 4… de un archivo (de categoría, de blog, de autor) es un subconjunto del archivo completo. No tiene contenido propio: es una selección de extractos de artículos que también aparecen en el archivo principal y en sus propias páginas individuales.

Indexar páginas de paginación genera:

  • Múltiples URLs con contenido solapado (los artículos del número 11 al 20 aparecen en /blog/pagina/2/ pero también en sus propias URLs individuales).
  • Páginas de bajo valor que diluyen la calidad del índice del sitio.
  • Posibles señales de contenido duplicado para artículos que aparecen en múltiples páginas de paginación a la vez.

Implementación: noindex en todas las páginas de paginación. En WordPress, los plugins de SEO gestionan esto con una opción de configuración global para las páginas paginadas.

Resultados de búsqueda interna

Por qué no indexar: Las páginas de resultados de búsqueda interna (/busqueda/?q=taxonomia, /?s=hreflang en WordPress) son páginas generadas dinámicamente cuyo contenido varía según la consulta. No tienen valor permanente: el mismo resultado de búsqueda puede devolver contenidos completamente distintos en el tiempo según se añadan o eliminen artículos.

Además, el número potencial de URLs de búsqueda es prácticamente infinito (tantas como consultas posibles). Si los buscadores rastrean estas URLs, pueden desperdiciar todo su presupuesto de rastreo en páginas sin valor.

Implementación: Dos capas de protección:

  1. Bloquear el rastreo en robots.txt:
Disallow: /?s=
Disallow: /busqueda/
  1. Añadir noindex en las páginas de resultados de búsqueda. En WordPress, esto se configura en el plugin de SEO activando la opción de noindex para resultados de búsqueda.

Páginas de archivo de autor con poco contenido

Por qué no indexar (en ciertos casos): Los archivos de autor (/autor/nombre/) listan todos los artículos publicados por una persona. Si el autor tiene muchos artículos publicados y el archivo tiene una descripción biográfica del autor, puede indexarse y tiene valor: es una forma de descubrir el trabajo de ese autor.

Pero si el autor tiene uno o dos artículos, el archivo de autor es una página de bajo valor que no justifica su indexación.

Regla práctica: Indexar el archivo de autor si el autor tiene más de diez artículos publicados. Por debajo de ese umbral, noindex.

Caso especial — múltiples autores en WordPress: En instalaciones WordPress con muchos usuarios registrados que nunca han publicado nada, los archivos de autor generan páginas vacías que definitivamente no deben indexarse. Configurar noindex global para archivos de autor con cero o pocos artículos.

Páginas de archivo cronológico

Por qué no indexar: Los archivos por año (/blog/2022/), por mes (/blog/2022/03/) o por día son agrupaciones cronológicas del contenido sin valor temático propio. No hay ningún usuario que busque “artículos publicados en marzo de 2022”: la fecha de publicación no es un criterio de búsqueda relevante.

Implementación en WordPress: WordPress genera estos archivos por defecto. Los plugins de SEO permiten desactivar su indexación globalmente.

Páginas facetadas de bajo valor

Por qué no indexar: Como se explica en el artículo sobre facetas, cada combinación de filtros puede generar una URL única. La mayoría de estas URLs producen subconjuntos de contenido sin valor diferencial suficiente para justificar su indexación independiente.

La excepción son las combinaciones de facetas de alta demanda con contenido suficiente y diferenciado. Por ejemplo, en una tienda de libros, la página /libros/?idioma=español&formato=ebook puede tener suficiente interés de búsqueda y suficiente contenido para indexarse si hay cientos de resultados.

Implementación: La gestión de la indexación de páginas facetadas es uno de los retos técnicos más complejos del SEO. Las opciones principales:

  • noindex global en todas las URLs con parámetros de faceta.
  • Canonical a la URL sin filtros para todas las páginas facetadas.
  • Configuración de parámetros de URL en Google Search Console para indicar que esos parámetros no generan contenido distinto.
  • Implementación de filtros mediante JavaScript sin modificar la URL (no recomendado: impide compartir URLs filtradas).

Páginas de confirmación y agradecimiento

Por qué no indexar: Las páginas de confirmación de formulario (/gracias/, /pedido-confirmado/, /suscripcion-confirmada/) son el destino de una acción del usuario. No tienen valor para un usuario que llega desde un buscador: si alguien llega a /pedido-confirmado/ sin haber hecho un pedido, la página no tiene sentido para esa persona.

Además, indexar estas páginas puede producir problemas: un buscador que indexa /gracias/ puede mostrarla en resultados de búsqueda y generar visitas sin contexto.

Implementación: noindex y también nofollow para evitar que los buscadores sigan los enlaces de esas páginas (habitualmente enlazan a secciones del sitio que ya están bien enlazadas desde otros lugares).

Páginas de perfil de usuario en plataformas

Por qué no indexar (en ciertos casos): En plataformas con registro de usuarios, los perfiles de usuario (/usuarios/nombre-de-usuario/) pueden generar miles de páginas. Si los perfiles tienen contenido real y propio (publicaciones, contribuciones, portfolio), pueden indexarse. Si son páginas vacías o con información mínima, no deben indexarse.

Implementación: Configurar noindex por defecto para todos los perfiles y activar la indexación solo para perfiles que cumplan ciertos criterios (número mínimo de contribuciones, perfil completo).

Páginas de parámetros de seguimiento

Por qué no indexar: Las URLs con parámetros UTM (?utm_source=, ?utm_medium=, ?utm_campaign=) son variantes de URLs existentes generadas por herramientas de analítica. No son páginas distintas: son la misma página con información de seguimiento añadida. Los buscadores no deberían indexar estas variantes.

Implementación: El canonical self-referencial (apuntando a la URL limpia sin parámetros UTM) es la solución estándar. Los buscadores respetan el canonical y no indexan las variantes con parámetros.

También puede configurarse en Google Search Console que esos parámetros no generan contenido distinto, lo que evita que se rastreen innecesariamente.

Páginas de impresión y versiones alternativas

Por qué no indexar: Algunas implementaciones generan versiones alternativas de páginas para impresión (?print=1, /imprimir/nombre-del-articulo/) o versiones AMP (/amp/nombre-del-articulo/). Estas variantes no deben indexarse de forma independiente: son representaciones alternativas del mismo contenido.

Implementación: Canonical de la versión de impresión a la versión estándar. Para AMP, la implementación correcta usa la relación amphtml/canonical entre las dos versiones.

Páginas de la API REST de WordPress

Por qué no indexar ni rastrear: WordPress expone por defecto una API REST en /wp-json/. Estas URLs devuelven datos en formato JSON, no contenido HTML para usuarios. No deben rastrearse ni indexarse.

Implementación: Bloquear en robots.txt:

Disallow: /wp-json/

Y si se quiere ser más restrictivo, bloquear también con autenticación para evitar el acceso público a ciertos endpoints que puedan exponer información sensible.

Para profundizar