Los chats de ChatGPT están siendo indexados por Google

Hace menos de 24 horas, los SEOs avispados compartían un hallazgo ingenioso: las conversaciones públicas de ChatGPT en /share eran totalmente indexables y algunas ya aparecían en el top 20 de Google para consultas long-tail. El descubrimiento se sentía como alquimia digital: contenido instantáneo y con autoridad que no tenías que redactar. Se inundó Twitter de capturas de pantalla, surgieron posts en blogs y algunos oportunistas empezaron incluso a raspar los chats para montar páginas de afiliados exprés.

Y entonces llegó el mazazo.

A la mañana siguiente, todos los resultados de /share habían desaparecido del índice de Google. Escribe site:chatgpt.com/share hoy y verás cero resultados. OpenAI aplicó en silencio tres cambios en rápida sucesión—<meta name="robots" content="noindex">, una etiqueta canónica global a la página principal y (muy probablemente) una petición masiva a través de la Herramienta de Eliminación de URLs de Google. “ChatGPT share URLs” se convirtió en un caso en vivo de desindexación relámpago en Google.

Una encuesta relámpago a 225 fundadores capturó el cambio de ánimo:

Las consecuencias no podrían ser más claras:

• Citas perdidas: Cualquier asistente de IA o medio que citara tu /share pierde la autoridad del enlace cuando Google borra la página.

• Brecha de visibilidad en IA: Los LLM entrenados con capturas recientes de la web toman el índice de Google como señal de confianza. Sin índice, no hay cita.

• Precipicio de tráfico orgánico: Si Google puede sacarte de la SERP en un solo ciclo de rastreo, tu flujo de contenido es tan fuerte como tu disciplina de cumplimiento.

El “hack” de crecimiento de ayer se ha convertido en la advertencia de hoy—prueba de que, cuando dependes de resquicios en lugar de fundamentos SEO duraderos, la distancia entre posicionar y desaparecer es un simple refresco de Google.

Cómo /share se indexó en primer lugar

1. Robots.txt dejó la puerta de par en par
   Cuando ChatGPT lanzó la función pública “Share”, su robots.txt permitía explícitamente el rastreo de /share/ bajo User-agent: *. Para Googlebot eso es luz verde para obtener, renderizar y tratar cada conversación compartida como una página HTML normal.

2. El arsenal de Google para descubrir URLs ocultas
   Aunque ningún sitio enlazara esas páginas, Google puede descubrirlas a través de canales pasivos que la comunidad SEO denomina “side-channels de Google”.

   • Pistas de URL de Chrome — cuando millones de usuarios pegan un enlace /share en la omnibox o lo hacen clic dentro de ChatGPT, la telemetría de Chrome envía muestras de URLs anonimizadas al planificador de rastreo de Google.

   • Android Link Resolver — cualquier toque en un URL /share dentro de una app de Android lanza un intent que queda registrado por los diagnósticos de Play-services.

   • Revisiones de Gmail y Workspace — los chats compartidos enviados por correo se escanean contra phishing; las URLs consideradas benignas se añaden a la cola de rastreo.

   • Heurísticas de DNS público y QUIC — grandes volúmenes de resoluciones DNS para el mismo subdirectorio señalan que “esta ruta importa”.

   Resultado: No enlaces internos ≠ No descubrimiento. Google no necesita un grafo de enlaces cuando es el propio comportamiento de los usuarios quien apunta a nuevas URLs.

3. El contenido generado por IA luce fresco y único
   Cada /share contenía texto novedoso que no se duplicaba en ningún otro lugar, por lo que el clasificador de frescura de Google le asignó valor inmediato. La combinación de rastreo permitido y contenido único aceleró la entrada de las páginas al índice—algunas en cuestión de horas desde su primera compartición.

Limpieza exprés de Google: la solución de cuatro frentes

Por qué Google pudo reaccionar en menos de 24 horas

• Prioridad a las grandes marcas: los dominios de alta autoridad se rastrean con mayor frecuencia, por lo que los cambios de directiva se propagan más rápido.

• Empujón manual: OpenAI casi seguro activó “Obtener como Google” en Search Console para forzar la actualización de las páginas críticas tras la publicación de las nuevas etiquetas.

• Evitar penalizaciones automáticas: los sistemas anti-spam de Google penalizan el contenido escaso o generado por usuarios que escala sin control; OpenAI tenía un fuerte incentivo para neutralizar el riesgo antes de que se aplicara una descalificación tipo black-hat a todo el sitio.

Una vez se accionan las cuatro palancas, /share queda invisible para los usuarios y es inútil como cita en la SERP. Para los SEOs la lección es clara: si una ruta de alto tráfico plantea de repente riesgos de marca o de cumplimiento, noindex + canonical + eliminación de URL es el triplete más rápido para hacerla desaparecer—antes de que los algoritmos de penalización de Google tomen la decisión por ti.

La resaca de un millón de URLs en Bing

El plan de limpieza de OpenAI se detuvo en Google Search Console. Como resultado, Bing todavía muestra ~1 millón de páginas /share en sus resultados—un pueblo fantasma digital de conversaciones de ChatGPT que ahora son invisibles en Google. La disparidad pone de relieve tres diferencias estructurales entre los motores:

1. Latencia de rastreo a índice – Googlebot vuelve a rastrear dominios de alta autoridad en cuestión de horas; Bingbot suele necesitar días. Cuando OpenAI añadió noindex y canónicos, Google volvió a rastrear rápidamente y obedeció. Bing simplemente no ha procesado todavía su cola pendiente.

2. Falta de intervención en BWT – Las herramientas para eliminar URLs y acelerar el rastreo en Bing viven dentro de Bing Webmaster Tools. Todo indica que OpenAI se saltó ese panel, lo que significa que Bingbot sigue la directiva “Allowed” original hasta que su cadencia natural asimile los cambios.

3. Patrón histórico de retraso – No es algo nuevo. En 2021 Bing siguió sirviendo URLs de favicon de WordPress semanas después de que Google las purgara, y el año pasado indexó un directorio filtrado de font-CSS que Google ignoró. La flota de bots más pequeña de la plataforma y su ventana de actualización conservadora la hacen propensa a resacas de indexación cada vez que un sitio de alto perfil cambia directivas de forma repentina.

Conclusión para SEOs: Si dependes del tráfico de Bing—o de citas de ChatGPT que se apoyan en el índice de Bing—mantén dos paneles. Envía solicitudes de eliminación o de nuevo rastreo tanto en Search Console como en Bing Webmaster Tools, o prepárate para un purgatorio prolongado donde dos buscadores muestran dos realidades muy distintas.

Por qué los resultados /share no ingleses dominan en Bing

Un efecto colateral curioso del retraso de Bing es que las páginas /share supervivientes son mayoritariamente resultados no ingleses y de alfabetos no latinos: japonés, ruso, árabe, tailandés. Tres factores explican el sesgo:

1. Las porciones regionales del índice se actualizan más lento – Bing segmenta su índice por ubicación. Las porciones EN-US de alto tráfico se actualizan primero; los fragmentos de idiomas periféricos pueden esperar una semana o más antes de podar páginas con noindex.

2. Priorización de clústeres duplicados – El algoritmo de desduplicación de Bing mantiene una URL por clúster canónico. Cuando las versiones en inglés desaparecieron de Google y perdieron autoridad de enlaces, Bing dio peso a variantes no inglesas únicas que aún mantenían señales de interacción de usuario.

3. Diferencia entre servir e indexar – Bing puede marcar internamente una URL como “desindexada” pero seguir mostrándola en mercados de baja competencia hasta el siguiente ciclo de despliegue completo. Esa brecha explica por qué consultas en árabe siguen devolviendo páginas /share incluso después de que el contador de índice de Bing empiece a bajar.

Insight de optimización: Monitorizar qué idiomas desaparecen primero ofrece una lección práctica sobre el presupuesto de rastreo y el modelo de confianza de cada motor. Para sitios multilingües, desplegar directivas de forma escalonada (p. ej., primero EN, luego JP) puede crear ventanas involuntarias de contenido duplicado. La táctica más segura de optimización para buscadores es aplicar las etiquetas noindex y canónicas de forma global y verificar la eliminación en cada centro de datos específico de la región mediante comprobaciones de SERP con VPN.