Google Search Central Live Toronto 2026: 5 verdades incómodas (análisis completo)

El 21 de abril de 2026, Google reunió a su equipo de Search Relations en Toronto para el primer Search Central Live en Canadá. Fue un evento presencial, sin livestream ni grabación oficial. Y dejó varias declaraciones que rompen buena parte del consenso SEO actual — especialmente en banca, fintech y ecommerce.

No hubo grandes anuncios de producto. Hubo algo más incómodo: Google confirmando, una por una, que varias “best practices” que se están vendiendo caras en el mercado no sirven. Y que el problema real es otro.

Este análisis recorre las cinco verdades más incómodas que dejó el evento, con el contexto técnico y estratégico que creo que todo C-level debería tener sobre la mesa. Lo escribo porque no llegué a estar en Toronto — el evento fue por invitación — pero el recap más completo disponible lo publicó JC Chouinard al día siguiente, con slides, notas en vivo y comentarios de los presentadores. Sobre ese material construyo este análisis, cruzando cada punto con documentación oficial de Google y cobertura previa de la industria.

1. “Crawled – currently not indexed” suele ser una señal de calidad, no un bug técnico

Cualquier SEO que trabaje con Search Console se topó mil veces con el estado Crawled – currently not indexed. La pregunta típica del cliente: “¿por qué Google no me indexa esta página?”. Y la respuesta típica del consultor junior: revisar robots.txt, verificar canonicals, forzar un fetch desde GSC, esperar.

En Toronto, Google dijo que esa respuesta está invertida. El estado Crawled – currently not indexed, en la mayoría de los casos, no es un problema técnico de rendering. Es una señal de calidad: Google rastreó la página, la evaluó, y decidió que no valía la pena indexarla.

Pueden existir causas técnicas — 404s, redirects mal configurados, canonicals apuntando a otra URL, configuraciones raras de robots.txt — pero no son las causas más frecuentes. La causa más frecuente es que el contenido no justifica su lugar en el índice.

Este cambio no es retórico. Es un cambio de paradigma que Google viene empujando desde hace al menos un año y que en Toronto quedó explícito: la IA bajó la barrera para producir contenido, así que Google subió la barrera para indexarlo.

La implicancia operativa es concreta. El ratio URLs indexadas / URLs publicadas deja de ser un KPI técnico y pasa a ser un KPI de calidad. Si tu sitio publica 500 URLs por mes y Google indexa 120, eso no es un problema de sitemap. Es un problema de calidad del contenido, de arquitectura, o de duplicación. Diagnosticarlo como técnico te lleva a perder semanas optimizando canonicals mientras el verdadero cuello de botella está en otro lado.

El orden correcto de diagnóstico cuando aparece Crawled – currently not indexed en GSC es, desde mi experiencia:

1. Calidad del contenido: ¿aporta valor único? ¿es thin content, duplicación interna, copia de manufacturer data, contenido generado en masa sin edición?
2. Canonical y duplicación: ¿hay otra versión de la URL que Google eligió como canónica? ¿tenés dos URLs compitiendo por la misma intención?
3. Técnico: recién después, verificar 404s, redirects, robots.txt, cadenas de redirecciones, renderizado JavaScript.

Invertir esfuerzo en “forzar” la indexación con resubmits desde GSC o cambios técnicos cuando la causa real es de calidad es tirar horas al fuego. Mejorar la página sigue siendo la única solución sostenible.

2. El problema no es la IA. Es el escalado sin supervisión editorial

Danny Sullivan fue explícito en Toronto: Google no está en contra de la IA per se. Está en contra del escalado de contenido sin supervisión. Y la política que explica la gran mayoría de las caídas de tráfico en sitios que produjeron contenido con IA se llama Scaled Content Abuse.

No es una política nueva. Google la publicó en marzo de 2024, como parte de la actualización de spam policies que acompañó al core update de ese mes. La definición oficial está en Google Search Central, y es muy clara: Scaled Content Abuse ocurre cuando se generan muchas páginas con el propósito principal de manipular rankings, sin aporte de valor para los usuarios, sin importar cómo fueron creadas.

Esa última frase es la clave. La política es deliberadamente agnóstica respecto al método de producción. No dice “penalizamos IA”. Dice: penalizamos el escalado manipulativo, ya sea humano, automático o híbrido. Lo que importa es la intención y el resultado, no la tecnología.

En fintech y banca esto es doblemente crítico. Todo contenido YMYL (Your Money or Your Life) tiene estándares EEAT más altos que un blog de viajes o de recetas. Google exige evidencia de experiencia, expertise, autoridad y confiabilidad en cada pieza. El margen para “dejar que escriba el modelo y publicamos” es cero.

Lo que sí sigue siendo viable:

• Usar IA como asistente de producción: investigación, outline, primer draft.
• Edición humana con expertise real en el tema, que aporte perspectiva, ejemplos, datos propios.
• Cada pieza con autor identificado, credenciales visibles, y razón para existir más allá de una keyword.

Lo que viola la política de manera clara:

• Generar cientos de páginas con plantillas rellenadas por un modelo (landing programático de “curso online de X” donde la única variable es el tema).
• Spinning de contenido existente con LLMs para evadir detección de duplicación.
• Contenido traducido automáticamente sin revisión editorial, multiplicado por 15 mercados.
• Programas de producción masiva donde un editor revisa 50 piezas por día sin poder aportar valor real.

La buena noticia es que la línea no es arbitraria. La documentación oficial de Google es lo suficientemente explícita como para que cualquier equipo que haga una auditoría honesta de su pipeline de contenido pueda saber de qué lado está.

3. Bloquear Google-Extended NO saca tu sitio de AI Overviews ni de AI Mode

Este es probablemente el insight más incómodo del evento. Y el que más fricción va a generar dentro de equipos grandes — especialmente con áreas legales y de compliance que empujaron el bloqueo de Google-Extended pensando que “protege” a la marca.

No lo hace.

Google-Extended es un token de user-agent que Google lanzó en septiembre de 2023. Su función, según la documentación oficial, es controlar si el contenido del sitio se usa para entrenar los modelos de IA de Google (Gemini, Vertex AI). Bloquearlo en robots.txt dice: “no uses mi contenido para entrenar tus modelos.”

Lo que no hace Google-Extended: controlar si el contenido aparece en AI Overviews o en AI Mode. Y ahí está el problema.

En Toronto Google confirmó de manera pública lo que varios expertos ya venían repitiendo desde 2024: como el sitio ya está en el índice de Search, Google puede seguir usando esa información para los fanouts que generan las respuestas de IA en Search. Bloquear Google-Extended no detiene eso. Lo único que cambia, en el margen, es que el sitio pierde la posibilidad de ser citado con link en algunas respuestas. Pierde la cita. No pierde el uso de la información.

La única manera de limitar la presencia en AI Overviews y AI Mode son los llamados preview controls: las directivas nosnippet, max-snippet y el atributo data-nosnippet. Pero todas tienen un costo estructural: también afectan los snippets tradicionales en SERP. Si usás nosnippet, perdés el snippet descriptivo en resultados orgánicos, y eso reduce el CTR de manera medible. Un estudio interno de Google citado en su momento por la CMA del Reino Unido midió hasta un 45% menos de tráfico por reducir detalle de snippets — aunque ese estudio es previo a la era AI.

En enero de 2026, Google anunció que está “explorando” controles más granulares, específicos para AI features, en respuesta a la consulta regulatoria de la CMA británica. Pero no hay timeline, no hay especificación técnica, y las palabras exactas de Google fueron “exploring” y “working with the web ecosystem” — ninguna promesa de producto.

La implicancia estratégica para banca, fintech y empresas grandes con equipos de compliance:

• Revisar si se está bloqueando Google-Extended por default sin entender qué hace. En muchos casos, el bloqueo es una decisión que no cumple su objetivo declarado.
• Si el objetivo es “proteger” contenido sensible, Google-Extended no es la herramienta. El bloqueo a Googlebot es la única vía real, pero eso saca el sitio de Search directamente.
• Si el objetivo es opt-out de AIO y AI Mode específicamente, hoy no existe limpiamente. Hay que esperar los controles que Google prometió explorar, o asumir el costo de usar nosnippet.

Para proyectos donde trabajamos la estrategia de visibilidad en AI Search, este es uno de los primeros temas que aclaro con legales: el cuco del “bot de IA” no se resuelve con una línea en robots.txt.

4. llms.txt y convertir el sitio a Markdown: sin beneficio SEO

Durante todo 2025 circuló, especialmente en LinkedIn y en el ecosistema GEO, la idea de que crear un archivo llms.txt o convertir el sitio a formato Markdown aportaba ventajas de visibilidad en LLMs. Plugins de WordPress lo incorporaron. Agencias lo sumaron como servicio. Conferencias lo presentaron como “imperativo”.

Google lo desmintió en Toronto. Y no es la primera vez.

John Mueller lo había comparado en mitad de 2025 con el legendario meta keywords tag: un estándar propuesto sin adopción real, fácilmente manipulable, que ningún sistema de búsqueda serio usa. Gary Illyes lo confirmó en el Search Central Live de julio 2025: Google no soporta llms.txt y no tiene planes de hacerlo. En Toronto, el equipo de Search Relations volvió a decir lo mismo, esta vez con mayor contundencia para cortar el ruido:

• No hay beneficio SEO en crear un archivo llms.txt.
• No hay beneficio SEO en convertir el sitio a Markdown.
• Ningún sistema de IA major (Google, OpenAI, Anthropic, Meta) está usando llms.txt para indexar o citar contenido.

La lógica es clara una vez que se entiende: llms.txt propone servir una versión “limpia” del contenido en Markdown, sin nav, sin ads, sin CSS. Pero los crawlers de IA ya descargan el HTML completo y tienen modelos entrenados para extraer el contenido principal. Un archivo adicional en Markdown es redundante. Y, peor aún, abre la puerta a cloaking: que un sitio muestre una cosa al LLM y otra al usuario humano.

En diciembre de 2025, Google mismo tuvo un episodio bizarro: un llms.txt apareció brevemente en la documentación de su portal de desarrolladores. La comunidad SEO se volvió loca. John Mueller aclaró en Bluesky que no era un endorsement, que fue una adición accidental de su CMS interno, y el archivo se sacó el mismo día. Pero el ruido duró semanas.

El consejo práctico cuando un proveedor te cotiza este tipo de “optimización para IA”: pedí evidencia concreta de impacto medible. No testimonios, no capturas de paneles internos: datos de performance antes y después, comparados con grupo de control. Si no los tiene, es signo claro de venta de aire.

Lo que sí funciona hoy para visibilidad en respuestas de IA es más aburrido y más viejo: contenido con autoridad temática real, datos originales, citas verificables, entidades bien estructuradas, y schema markup implementado correctamente. Lo mismo que funciona para Google Search tradicional, porque los LLMs de búsqueda — incluyendo Gemini en AI Overviews — usan el índice de Search como base de grounding.

5. Gemini en la app ≠ Gemini en Search

La confusión más frecuente que escucho en reuniones con equipos de marketing y con C-level es esta: alguien testea una query en gemini.google.com, ve qué responde, y saca conclusiones sobre “cómo está viendo Google mi marca”. Error.

En Toronto, Google aclaró algo que no estaba documentado públicamente con esta claridad: Gemini en AI Overviews y AI Mode, aunque use el mismo modelo base que la app standalone de Gemini, recibe moldeado distinto por parte de Google Search. Los resultados son — según palabras del equipo — “esperablemente diferentes”.

Esto tiene tres consecuencias directas para medición y estrategia:

Primera: testear prompts en la app de Gemini no predice lo que aparece en AI Overviews ni en AI Mode. Si un CMO te muestra una captura de Gemini respondiendo sobre su marca y te pregunta “¿por qué no aparecemos?”, la pregunta está mal planteada. No es el mismo sistema.

Segunda: medir visibilidad de marca en AI Search requiere testear directamente en Google Search, en AI Mode activado, o usar sistemas de tracking especializados que scrapeen SERP real, no la app de Gemini. Esto aplica para cualquier auditoría de visibilidad seria en 2026.

Tercera: el reporting gap sigue abierto. Google Search Console no reporta clicks desde AI Overviews ni AI Mode de manera discriminada. En Toronto el equipo confirmó que “están trabajando en algo” — palabras textuales — pero no dio timeline. Esto significa que, por ahora, no hay fuente oficial para saber cuánto tráfico viene de AIO vs. de resultados orgánicos tradicionales dentro de las herramientas de Google.

Para cualquier empresa que use Search como canal crítico de adquisición — y banca, fintech y ecommerce entran en esa categoría — este gap es una urgencia operativa, no una curiosidad. Sin medición, no hay optimización. Y sin optimización, se pierde cuota de mercado en un sistema que ya está redistribuyendo el tráfico orgánico.

En proyectos de SEO para banca y YMYL es uno de los primeros puntos que abordo con el cliente: definir un sistema de tracking propio de presencia en AIO/AI Mode, independiente de lo que Google eventualmente decida reportar. Hay herramientas de terceros, hay scraping controlado, hay paneles internos. Todos son proxies — ninguno es perfecto — pero cualquiera es mejor que volar a ciegas.

La síntesis ejecutiva

Los cinco puntos anteriores no cambian los fundamentos del SEO. Calidad de contenido, arquitectura técnica, EEAT, Core Web Vitals y autoridad temática siguen siendo la base. Lo que cambia es el contexto en el que esos fundamentos operan:

1. El umbral de calidad para existir en el índice es más alto. Publicar más no equivale a indexar más. Las URLs tienen que justificar su lugar.
2. La IA sin supervisión es un riesgo algorítmico concreto. La política de Scaled Content Abuse lleva dos años activa y está explicando caídas de tráfico que muchos siguen atribuyendo a “core updates”.
3. Varias tácticas populares para AI Search no hacen lo que se cree. Bloquear Google-Extended no protege de AIO. llms.txt no aporta visibilidad. Markdown no mejora ranking.
4. El sistema de medición sigue incompleto. GSC no reporta AIO ni AI Mode de manera discriminada. Y Gemini app no representa AIO.
5. El ganador estructural es el mismo de siempre: contenido con autoridad real, datos originales, schema bien implementado, velocidad decente, y una arquitectura que Google pueda entender. Lo aburrido sigue funcionando.

En banca, fintech y ecommerce, donde cada punto de adquisición digital se traduce en millones de dólares, este no es un debate SEO. Es un debate de riesgo competitivo. La empresa que capitaliza estos insights antes que su competencia no gana posiciones en SERP — gana cuota de mercado.

Y la que sigue bloqueando Google-Extended “por las dudas”, generando contenido con IA sin supervisión editorial, y midiendo visibilidad de marca en la app de Gemini, va a llegar tarde.