Conflictos de indexabilidad: Cuando tu propio sitio le dice a Google que se vaya

Cada auditoría que realizamos plantea una pregunta directa sobre las páginas que un sitio declara importantes — la página de inicio más las URLs que su propio sitemap lista: ¿pueden los motores de búsqueda indexarlas como declaradas? Entre mayo 5 y August 15, 2026, 21 de 49 sitios auditados fallaron esa pregunta. Eso es 42.9% de la muestra que indica a los rastreadores que omitan páginas a las que alguien se tomó la molestia de publicar, enlazar y listar. Los fallos comparten una firma: cada uno de estos sitios funciona perfectamente para humanos. Las páginas se renderizan, los enlaces se resuelven, nada en el navegador indica que una directiva debajo esté enviando a los motores de búsqueda lejos. Los conflictos de indexabilidad son la categoría más autoinducida en nuestros datos — ningún competidor los causó, ninguna actualización de algoritmo los disparó, y nadie del equipo puede verlos sin obtener el sitio de la manera en que lo hace un bot.

El conjunto de datos

Metodología: instantánea de auditoría completada más reciente por dominio de nuestro conjunto de comprobaciones actual, mayo 5 – August 15, 2026 — 49 sitios auditados, anonimizado. Los denominadores por comprobación varían de 46 a 49 porque una comprobación solo se ejecuta cuando sus entradas existen — un sitio sin sitemap accesible no produce veredictos de página de sitemap. La muestra es auto-seleccionada — propietarios que realizaron una auditoría — y sesga a tamaño pequeño-mediano, por lo que trate las tasas como direccionales para ese segmento.

Redirecciones y canonicals provocan más fallos que noindex

La brecha entre las primeras filas 2 es el hallazgo. La comprobación de indexabilidad falla una página por cualquiera de 4 razones: bloqueada por robots.txt, con una directiva noindex, redirigiendo a un URL diferente, o declarando un canonical que apunta a otro lugar. La comprobación específica de noindex falló en 7 sitios — lo que significa que en la mayoría de los 21 sitios fallidos, las páginas no indexables no tienen ningún noindex. Se redirigen lejos del URL que el sitemap prometió, o le dicen a Google que su canonical vive en una dirección diferente. Esa distribución importa porque los equipos buscan al culpable equivocado. La palabra que todos conocen es noindex, así que eso es lo que se busca — y vuelve limpio. El conflicto real suele ser estructural: un sitemap generado desde la base de datos CMS mientras las URLs en vivo migran a un nuevo esquema de ruta, o una etiqueta canonical templada a una variante URL que ninguna página realmente sirve. La comprobación es cuidadosa con lo que cuenta. Excusa la redirección que es infraestructura correcta — un dominio desnudo saltando a su variante www — y omite rutas utilitarias como /login y /signup que deberían llevar noindex. Los fallos 21 son lo que queda después de eliminar los casos benignos.

Los patrones de conflicto 4 en los datos

El noindex de staging que se lanzó. Los sitios 7 listan páginas en su sitemap que llevan una directiva noindex — en la etiqueta meta robots o en el encabezado de respuesta X-Robots-Tag. Esto es el clásico residuo de lanzamiento: la directiva que oculta correctamente el entorno de staging viaja a producción dentro de una plantilla, una configuración de plugin, o un conmutador de plataforma. La casilla de WordPress "Discourage search engines from indexing this site" es el ejemplo canónico — 1 configuración, noindex a nivel de sitio, nada visible diferente. robots.txt gritando sobre todo. Los sitios 3 sirven un robots.txt con Disallow: / para todos los bots — el signo de "vete" a nivel de sitio — y 5 fallan la comprobación de consistencia más amplia, donde robots.txt bloquea o un noindex en la página principal contradice la intención evidente de posicionarse. La trampa sutil en este patrón: robots.txt y noindex hacen trabajos opuestos, y combinarlos cancela el más fuerte. Una página bloqueada por robots.txt no puede ser rastreada, así que un noindex colocado en ella nunca se lee — lo que hace que las URLs terminen en el estado "Indexado, aunque bloqueado por robots.txt", presente en los resultados como un enlace en blanco Google fue prohibido de obtener. Contradicciones canonicals. Una etiqueta canonical apuntando a un objetivo que a su vez lleva noindex entrega a Google 2 instrucciones que no pueden ser cumplidas ambas: consolidar señales en esta página, y mantener esta página fuera del índice. Nuestro motor resuelve cada objetivo canónico y falla la auditoría cuando el objetivo está noindexado, redirige o se niega a declararse canónico. La misma contradicción aparece en forma de 1-página cuando una página lleva tanto noindex como un canónico a otro lugar — pidiendo a Google que transfiera autoridad a través de una página que se le dijo que olvidara. El sitemap promoviendo lo que las directivas prohíben. Un sitemap es una reclamación legible por máquina de que cada URL en él merece ser indexado. Listar un URL que robots.txt bloquea o una directiva que aplica noindex hace que el sitio discuta consigo mismo, y la discusión cuesta presupuesto de rastreo en cada ciclo. Medimos este patrón por sí solo en nuestro informe de higiene del sitemap [/articles/xml-sitemap-hygiene-audit-data].

Resuelve los conflictos en este orden: intención, luego mecanismo 1, luego prueba

Los conflictos de indexabilidad persisten porque las correcciones se aplican señal por señal — alguien parchea un noindex aquí, edita robots.txt allí — sin que nadie decida para qué sirve realmente cada clase de página. La corrección duradera se ejecuta en dirección 1.

Contenido clasificable, variantes duplicadas, páginas de utilidad privadas y espacios de parámetros infinitos obtienen cada uno la intención 1 — antes de que alguien toque un archivo de configuración. 1. Decidir la intención por clase de página. 2. Expresar cada intención a través de exactamente el mecanismo 1.

• Clasificar: listado en el sitemap, canónico apuntando a sí mismo, sin directivas robots en absoluto.
• Consolidar duplicados: <link rel="canonical" href="https://example.com/primary/" /> en la variante, que permanece rastreable y sale del sitemap. Los canónicos son una pista — la propia documentación de Google dice que puede elegir un canónico diferente cuando otras señales están en desacuerdo, lo que es exactamente por qué el objetivo debe estar limpio: indexable, 200, auto-canónico.
• Mantener fuera de los resultados: una etiqueta meta robots noindex en la página, o el encabezado de respuesta X-Robots-Tag: noindex para PDFs y otras respuestas no HTML. La página debe permanecer rastreable — una directiva detrás de un bloque robots.txt es una directiva que no existe.
• Guardar presupuesto de rastreo: Disallow: /search/ bajo User-agent: * en robots.txt, reservado para espacios con URLs ilimitadas. robots.txt controla el rastreo, nunca el indexado — no elimina nada que ya esté indexado.

Por plataforma, la intención noindex es 1 línea: robots: { index: false } en la exportación de metadata de una ruta Next.js, el interruptor "Visibilidad en motores de búsqueda" en WordPress — revisado deliberadamente por entorno, nunca heredado de staging — o add_header X-Robots-Tag "noindex" always; limitado a un bloque de ubicación en nginx. El navegador no prueba nada aquí; obtén la forma en que lo hacen los rastreadores: 3. Verificar como un bot, por clase de página.

curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"
curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"

1 representante URL por clase de página es suficiente, verificado contra la intención que decidiste en el paso 1. La Inspección URL de Search Console da la segunda opinión autorizada, incluyendo qué canonico Google realmente eligió. Nuestra auditoría ejecuta el bucle completo en cada informe — robots.txt contra membresía del sitemap, directivas contra canonicos, objetivos canonicos resueltos y verificados — y el free report lista cada par conflictivo con la página donde lo encontró. La tasa de fallos 42.9% coloca los conflictos de indexabilidad entre los hallazgos graves más comunes en nuestros datos, en la misma categoría que las brechas de encabezado de la clasificación de nuestras comprobaciones más fallidas — con una consecuencia más severa, ya que una página bloqueada no gana nada sin importar cuán buena sea. Los sitios que pasan son los donde la intención de indexado se decidió una vez, escrita en el mecanismo 1 por clase de página, y verificada de la manera que lo haría un rastreador. Todo sobre esta categoría de fallos está bajo el control del propietario del sitio — lo que la convierte en la más corregible 42.9% en el conjunto de datos.