Los errores de SEO técnico que Google Travel se puede permitir y tu OTA no

Lo lógico sería que un producto de Google que rankea tan bien siguiera al pie de la letra lo que Google pide a las demás webs, y quise comprobar si lo hace.

Según Ahrefs, en España rankean más de 33.000 URLs de Google Travel entre google.es/travel y google.com/travel. google.es/travel, casi todo Hoteles, recibe unas 197.000 visitas orgánicas estimadas al mes, y google.com/travel, casi todo Vuelos, unas 431.000. Lo consigue con una sección de Hoteles que incumple varias recomendaciones de la propia documentación de Google.

En este artículo explico cuánto rankea, repaso esos fallos técnicos con ejemplos de cada uno, y los comparo con Vuelos, que sigue casi todas esas recomendaciones. Al final miro qué pasa con Google Travel en AI Mode y en ChatGPT, donde juega con otras reglas. Hice las pruebas con curl, Chrome, el Rich Results Test y los propios asistentes de IA, y los datos de rankings, tráfico, SERP y respuestas de IA son de Ahrefs.

En Ahrefs, el 96 % de las keywords de google.es/travel/hotels/ llegan por fichas de hotel (/travel/hotels/entity/…). Entre junio y octubre de 2026 las URLs con rankings se multiplicaron por cinco, casi todas fichas limpias y compartidas (variantes con parámetros que explico más abajo).

Las keywords de Hoteles en el top 10 suben durante varias actualizaciones del algoritmo de Google, la principal de mayo y las dos contra el spam de agosto y septiembre. La de septiembre coincide además con los cambios del 8 de septiembre en los resultados de hoteles del Espacio Económico Europeo por la DMA. El mayor salto, entre finales de enero y principios de febrero de 2026, no coincide con ninguna actualización anunciada, y la caída de marzo y abril la sufren igual las OTA de la comparación y no se puede atribuir solo a Google Travel, y en todos los casos hablo de coincidencias de fechas, no de causas.

En las dos actualizaciones contra el spam, Google Travel ganó keywords en el top 10 y las grandes agencias de viajes online (OTA) no. Lo mido en keywords en el top 10 porque el tráfico estimado de Ahrefs sube y baja con la estacionalidad de las búsquedas.

Para ver de quién salen los puestos, comparé las SERP que guarda Ahrefs de antes y de después de cada actualización en unas 70 keywords por actualización donde Google Travel entra en el top 10, elegidas en parte por tráfico y en parte al azar. Como solo incluye búsquedas donde Google Travel ganó, la muestra sirve para ver a quién desplaza, no para medir la actualización entera.

Los puestos que gana Google Travel salen sobre todo de OTA y metabuscadores, y los que más veces dejan el top 10 son centraldereservas.com, trivago.es, hoteles.com, booking.com y tripadvisor.es. Ni booking.com ni tripadvisor.es ganan keywords en el top 10 en esas fechas, así que no parece que estas actualizaciones favorezcan a todos los dominios grandes a costa de los pequeños.

Con estos datos no puedo saber si Google Travel sube porque esas actualizaciones penalizan a las OTA y ocupa su hueco, o porque Google trata mejor a sus propias páginas. Lo que sí muestran es que Google Travel posiciona con fallos técnicos que en cualquier otra web se marcarían como problemas, y que repaso a continuación.

Hoteles no comprueba si el lugar o el hotel de la URL existen. Cualquier texto después de /travel/hotels/ devuelve una página 200 con ese texto en el title. google.es/travel/hotels/asdfqwertyzx, por ejemplo, responde 200 con el title "asdfqwertyzx: búsqueda de hoteles de Google", y Googlebot la ve sin canonical, sin noindex y sin ningún hotel. Una ficha con un ID inventado (/travel/hotels/entity/xyz) también responde 200, con el title vacío.

Para una URL que no existe, la guía de errores de rastreo de Google pide responder 404 o 410, o redirigir con 301 si el contenido se ha movido, pero Hoteles sirve un soft 404. La única plantilla que detecta un lugar inexistente es la landing SEO (/travel/hotels/landingpage/), y redirige con 302 a la landing normal, que vuelve a responder 200.

Según Ahrefs, en España rankean 91 URLs de este tipo con el nombre de un lugar real, como /travel/hotels/Madrid o /travel/hotels/Córdoba.

Las URLs con utm_campaign=sharing las genera el JavaScript de Hoteles en cada visita, sin que nadie pulse Compartir. En el HTML que sirve el servidor, ninguno de los enlaces a fichas de madrid-hotels lleva esos parámetros. Después del JavaScript los llevan todos, tanto para Googlebot como para un usuario de móvil, y la propia URL de la página pasa a ser /travel/hotels/madrid-hotels?utm_campaign=sharing&…&ts=….

Para verlo en el render de Googlebot inspeccioné la landing en Search Console, a través de una redirección desde mi dominio, y saqué sus enlaces con la extensión que reconstruye el render completo, que permite filtrarlos y exportarlos.

El parámetro ts guarda el estado de la búsqueda (lugar, fechas y moneda), y como cambia en cada visita, cada ficha acumula URLs distintas. De la ficha del Exe Sevilla Macarena, Google tiene indexadas 1 URL limpia y 26 variantes compartidas.

La landing SEO (/landingpage/) también reescribe su URL con utm_campaign=sharing y un ved distinto en cada visita, aunque sin ts y con el canonical limpio. Ninguna de esas variantes aparece rankeando en Ahrefs. Las fichas acumulan además URLs con sa=X&ved=, que en google.es rankean por cientos, sin contar las compartidas.

Una URL compartida de Madrid en google.com, generada en febrero de 2022 con fechas de estancia de junio de 2021, sale 1.ª para "hoteles cerca de mí" y 2.ª para "hotel cerca de mi". El tráfico de las URLs compartidas llega sobre todo por búsquedas del nombre de un hotel.

Una ficha admite dos formas de ID, un prefijo de lugar (/travel/hotels/Catalunya/entity/…), cualquier pestaña (/prices, /reviews o cualquier texto, que también devuelve 200) y los parámetros que añade el JavaScript. Por eso en google.es rankean más URLs de fichas que alojamientos, y el Hotel Palacio de Luko llega a 17.

Las dos formas de ID no se consolidan. Una lleva el identificador del Knowledge Graph y la otra no, y cada una se declara canónica de sí misma.

El Barceló Murcia Siete Coronas, por ejemplo, responde en /travel/hotels/entity/ChkIhI2H5Njrn8_cARoML2cvMWhjMWdnMjUyEAE, con el identificador /g/1hc1gg252, y en /travel/hotels/entity/CgsIhI2H5Njrn8_cARAB, sin él. Las dos llevan el mismo identificador de Maps y las dos rankean en google.es para el nombre del hotel. Al Exe Sevilla Macarena le pasa lo mismo con ChkI6_TdiuGlz-FwGg0vZy8xMWI2eTlmejNfEAE y CgoI6_TdiuGlz-FwEAE.

Para "google hotels", la ficha del Hotel Palacio de Luko ocupa cinco de los siete primeros resultados con URLs distintas, la primera en catalán. El hub de Hoteles solo sale 1.º para "google hoteles".

Los puntos de interés también tienen ficha dentro de Hoteles y rankean para su nombre. La de la catedral de Segovia, por ejemplo, sale 3.ª para "catedral segovia".

Cada dominio de Google sirve su propia copia de cada landing. Las versiones de madrid-hotels de google.es, google.com, google.co.uk y google.com.mx se declaran canónicas de sí mismas, y ninguna tiene hreflang. Según Ahrefs, en España rankean además URLs de Travel de al menos 34 dominios de Google más, como google.com.py, google.co.ve o google.com.br, y casi todas son fichas de hotel.

Dentro de google.es también rankean fichas en un idioma que no corresponde. Las fichas con el parámetro hl=ca, en catalán, reciben el 15,7 % del tráfico estimado de Hoteles en google.es según Ahrefs, y casi todas son URLs compartidas. Su title termina en "Hotels de Google".

El canonical de esas fichas tampoco ayuda, porque apunta a una página en otro idioma. Las fichas con hl=ca, en catalán, declaran como canónica la versión limpia de google.es, que está en español. La variante del Barceló Murcia Siete Coronas en google.com.br con hl=es&gl=es, en español, declara la de google.com.br, que está en portugués. Según la documentación de versiones localizadas, las versiones de una página solo se consideran duplicadas si el contenido principal está sin traducir. Google las trata como páginas distintas, no aplica el canonical y las indexa, y de ahí salen las fichas en catalán que rankean en google.es y la variante brasileña que aparece para frases en español.

Las landings y las fichas no usan hreflang, que sirve para mostrar a cada usuario la versión de su idioma o región, aunque falle bastante. Solo el hub lo declara, en un sitemap aparte y sin x-default.

En las landings, el canonical llega vacío en el HTML del servidor y lo rellena el JavaScript. Google admite que se puede poner el canonical con JavaScript cuando no se puede poner en el HTML, aunque no lo recomienda, y pide que el JavaScript no cambie el del HTML original ni deje más de una etiqueta. Explorar sirve dos canonical distintos, uno a google.es y otro a google.com.

Si el JavaScript no reconoce el lugar, el canonical se queda vacío para Googlebot. Para un visitante apunta a la landing de la zona donde Google lo sitúa, que puede ser una comunidad autónoma, una ciudad o un código postal. Sin sesión iniciada, la zona sale de la IP, y en mis pruebas el canonical era comunidad-de-madrid-hotels desde Madrid y barcelona-hotels desde Barcelona. Con la sesión iniciada, Google puede usar la ubicación de la cuenta aunque la IP sea de otra ciudad.

Cuando el canonical sí está, Google a menudo lo ignora. Estas URLs con el nombre de un lugar declaran como canónica su landing -hotels, pero Google posiciona la URL original. Las posiciones las saco de Ahrefs.

La guía de URLs duplicadas pide no usar robots.txt para canonicalizar y avisa de que Google puede indexar las URLs bloqueadas sin su contenido. Esas URLs salen indexadas sin descripción, y según Ahrefs en España rankean 24 URLs bloqueadas, casi todas de /travel/flights/search en google.com.

Las de Vuelos (/travel/flights/search y /travel/flights/booking) llevan además la meta robots "noindex, nofollow". Como robots.txt impide rastrearlas, Google nunca llega a leer ese noindex, y la guía del noindex avisa de que, si la página está bloqueada en robots.txt, el rastreador no ve la regla y la URL puede seguir saliendo en los resultados.

Ahrefs atribuye además a Google Travel casi 11.000 URLs bloqueadas de /travel/clk/. Son el enlace que Google añade como sitelink bajo los resultados de aerolíneas y agencias, como Iberia, Vueling o Skyscanner, y que pasa por su propia redirección antes de llevar a la web. Como robots.txt bloquea /travel/clk/, Googlebot no puede seguir esa redirección y la URL de clk se indexa como una página más.

Las landings de ciudad responden 200 en móvil. Con cualquier user agent de escritorio, Googlebot desktop incluido, redirigen con 302 a /travel/search, una ruta bloqueada en robots.txt. Las fichas no redirigen nunca.

Googlebot recibe lo mismo que un usuario del mismo dispositivo, así que no hay cloaking, y con el índice mobile-first Google indexa la versión móvil. La respuesta cambia según el user agent, pero la cabecera Vary no lo declara, y la guía mobile-first describe esta configuración como una que se apoya en el user agent y en Vary. Además, la versión de escritorio es otra URL, y bloqueada, cuando la misma guía pide el mismo contenido en las dos.

Hoteles tiene 46.407 landings de ciudad (/travel/hotels/madrid-hotels) y otras tantas en versión SEO (/travel/hotels/landingpage/madrid-hotels). El hub de Hoteles, las fichas y Vuelos no enlazan a ninguna landing de ciudad, así que Google solo puede descubrirlas por sus sitemaps.

Esos sitemaps solo listan URLs de google.com. google.es sirve copias idénticas de los mismos ficheros en las mismas rutas, también con URLs de google.com. Que listen google.com encaja con la migración, porque es el dominio que Google mantiene. En cambio, en Hoteles siguen rankeando las URLs de google.es, que no están en ningún sitemap y no se han consolidado en google.com como las de Vuelos. No declarar el sitemap en robots.txt no es un problema, porque Google acepta los que se envían por Search Console.

Los sitemaps de landings tampoco están limpios. Cuando el nombre de un lugar lleva una coma, el generador lo parte en dos URLs, y "University of California, Los Angeles" aparece como /travel/hotels/university-of-california y /travel/hotels/-los-angeles-hotels, mientras que la buena, con la coma, no está. Le pasa a 739 lugares, cuyas URLs responden 200, unas repitiendo otra landing y otras sin ningún hotel, aunque según Ahrefs ninguna rankea en España. En los mismos ficheros hay entradas repetidas y landings que solo se diferencian en una tilde, como los-angeles-hotels y los-ángeles-hotels.

El enlazado va de la landing a las 24 fichas de su búsqueda y de cada ficha a otras 35. Ninguna ficha enlaza de vuelta a su ciudad y ninguna landing enlaza a otra.

Hoteles no tiene ningún dato estructurado. Google los usa para entender y clasificar el contenido de la página, y John Mueller ha dicho que le ayudan a entender las entidades de la página y para qué búsquedas es más relevante, pero también que no hacen que una web rankee mejor. Se notan sobre todo en el CTR. La galería de datos estructurados no tiene un resultado específico para hoteles, pero el fragmento de reseña admite negocios locales, y Hotel y LodgingBusiness lo son. Las fichas de Google Travel tienen esos datos de cada hotel, y como Google no es el dueño del hotel, no les afecta la norma que excluye las reseñas propias. Vuelos, además, marca las migas (BreadcrumbList), que Hoteles tampoco tiene, aunque Google ya construye la ruta del snippet a partir de la URL.

Googlebot solo descarga los primeros 2 MB del HTML, contados sin comprimir y con las cabeceras, y Google explica que lo que queda detrás no se rastrea, no se renderiza y no se indexa. El mismo artículo recomienda sacar el CSS y el JavaScript pesados a ficheros externos y poner arriba el title, el canonical y los datos estructurados.

Pedí las fichas de hotel con el user agent de Googlebot y desde una IP de EE. UU., y pesan entre 2,35 y 2,91 MB sin comprimir. Antes del title llevan unos 1,5 MB de código, casi todo CSS en línea, y la descripción propia del hotel, las reseñas, la dirección y los servicios quedan después de los 2 MB. Las landings de ciudad y el hub pesan unos 2,2 MB y pierden el bloque de datos que usa el JavaScript. Las fichas de alquileres vacacionales y de puntos de interés pesan menos de 2 MB.

Para ver si Google indexa lo que queda detrás, busqué entre comillas frases de 17 fichas, cada una con la redacción que recibe Googlebot y en una posición conocida del HTML.

El límite se cumple, y está en 2 MiB (2.097.152 bytes), no en 2.000.000. En las fichas limpias, Google no indexa la descripción del hotel ni nada de lo que va detrás.

Algunas variantes de la misma ficha, como una URL compartida de google.com.ec en la pestaña de precios, una versión en catalán de google.es o una de google.co.ve con prefijo de lugar, sí están indexadas con texto que hoy queda detrás del corte, aunque pesan lo mismo. Lo más probable es que Google las rastreara cuando Google Travel servía una versión anterior de la página, más ligera, y que esas copias sigan en el índice. No he podido comprobarlo con capturas antiguas.

La redacción de la descripción depende del país desde el que se pide la ficha. Desde España, la del Barceló Murcia Siete Coronas habla de "un restaurante sofisticado de cocina mediterránea", y desde EE. UU., que es desde donde rastrea Googlebot, de "un restaurante mediterráneo elegante".

Google usa las Core Web Vitals en su ranking y lleva desde 2020 pidiendo a las webs que las mejoren, aunque su documentación reconoce que pesan poco. El contenido más relevante gana aunque la experiencia sea mala, y una buena experiencia solo desempata cuando hay mucho contenido igual de útil. Ninguna página de Google Travel con datos de usuarios en Chrome las aprueba.

Para aprobar hace falta un LCP de 2,5 s o menos, un INP de 200 ms o menos y un CLS de 0,1 o menos en el percentil 75 (CrUX, 28 días hasta el 18-10-2026). /travel/search es donde acaban en escritorio las visitas al hub y a las páginas de ciudad.

El CLS alto viene de las fichas. Se abren desde la lista sin recargar la página, así que Chrome anota a la URL de la lista todo lo que se mueve después. Al bajar por una ficha, la barra de pestañas se queda fija y empuja el contenido, y al volver con el botón atrás del navegador la lista reaparece con un salto de toda la pantalla, que por sí solo da un CLS de 1,05. En Vuelos de escritorio pasa algo parecido al pulsar "Ver vuelos", cuando el pie de página salta mientras cargan los resultados.

En mis pruebas de laboratorio, cada página de Hoteles lleva dentro del HTML 1,4 MB de CSS, del que usa menos del 6 %, y como el HTML no se guarda en caché se descarga otra vez en cada página. En un móvil emulado, más de un segundo del hilo principal se va en animaciones de carga que no se detienen, y solo los mapas de madrid-hotels pesan más de 1,5 MB. No he querido hacer una auditoría de rendimiento completa, porque la idea es mostrar el dato y no solucionarle los marrones a Google.

Google anunció el 15 de abril de 2025 que el buscador dejaba los dominios de país, y la portada de google.es ya redirige a google.com. En Travel la consolidación solo se completó en Vuelos.

Por eso google.es/travel sigue rankeando, muchas veces en la misma SERP que google.com/travel, con más de 700 keywords en común según Ahrefs. Para "google flights", por ejemplo, google.com/travel/flights sale 1.º y google.es/travel/explore 5.º.

Casi todo el tráfico estimado de google.es/travel es de Hoteles, y el de google.com/travel, de Vuelos. Hoteles de google.com apenas recibe tráfico.

La migración explica que haya dos dominios rankeando. El resto de fallos de este artículo se repite igual en las URLs de google.com.

En Vuelos, Google Travel resuelve casi todos estos problemas.

Vuelos de google.es estaba en la raíz, en google.es/flights. Según Ahrefs, tuvo algo de tráfico entre 2021 y 2023 y en la primavera de 2025, y desde agosto de 2025 no tiene ninguno. Hoy esa ruta redirige con 301 a google.es/travel/flights, que lleva noindex y canonical a google.com. Mezclar noindex y canonical no es lo que recomienda Google. John Mueller ha dicho que son señales contradictorias, y la guía de URLs duplicadas prefiere el canonical al noindex para consolidar. Una redirección 301 directa a google.com, como la de la portada de google.es, sería más limpia.

Pese al hreflang, según Ahrefs en España rankean 1.422 URLs de Vuelos en español de Latinoamérica, como la versión argentina de la ruta Murcia-Madrid.

En Ahrefs, google.com/travel/flights ya crecía desde mediados de 2023, pero su tráfico estimado se multiplica casi por treinta entre febrero de 2024 y agosto de 2025. El 6 de marzo de 2024 Google retiró el módulo de Vuelos de los resultados del Espacio Económico Europeo para cumplir la Ley de Mercados Digitales (DMA). eDreams ya avisó de que, sin el módulo, Google Flights podía salir más arriba como resultado orgánico. La actualización principal de marzo de 2024 empezó un día antes, el 5 de marzo, y con estas fechas no se puede separar un efecto del otro ni demostrar la causa.

Hasta aquí he tratado Google Travel como una web más, con sus fallos de robots.txt, canonical y noindex. En AI Mode Google cambia de papel y pasa a ser el buscador que recomienda y enlaza sus propios servicios.

Los enlaces de AI Mode a Google Flights llevan el parámetro source=aim_search. Según Brand Radar de Ahrefs, aparece por primera vez entre el 22 de junio y el 1 de julio, y hoy lo llevan casi 3.000 URLs de Google Flights citadas en España.

Con ese parámetro Google etiqueta el tráfico que AI Mode se manda a sí mismo, pero no el que manda a los demás. En la respuesta a "vuelos barcelona sevilla", por ejemplo, el enlace a Google Flights lleva source=aim_search y los de Vueling y Ryanair van sin nada, y lo mismo pasa con Skyscanner o Booking en el resto de respuestas. Una aerolínea o una agencia no tiene forma directa de separar las visitas que le llegan de AI Mode, porque en Search Console sus clics van sumados a los de la búsqueda web y en GA4 entran como tráfico orgánico de Google.

El módulo de vuelos de la búsqueda clásica hace lo mismo y enlaza a Google Flights con source=flun. Google sabe medir de dónde viene ese tráfico, como demuestra con sus propios enlaces, y no da esa información a las webs a las que envía pocas visitas y que le dan la data.

Hay una segunda variante, source=aim_shopping, que lleva a /travel/flights/search, la ruta que robots.txt bloquea y que tiene noindex. Esos enlaces llevan la ruta y unas fechas de viaje calculadas al responder, y los construye el módulo de vuelos de AI Mode sin pasar por el rastreo. Por eso un enlace de AI Mode a una ruta bloqueada no quiere decir que Google se salte su robots.txt.

En hoteles, AI Mode apenas enlaza a Google Hoteles, pero cita a Google con otra URL, google.com/searchviewer/, una página titulada "Place Viewer" con la ficha de un negocio (valoración, dirección y precio por noche), y en la respuesta aparece como una fuente llamada "Google". El identificador de la URL (svid) lleva dentro el ID del Knowledge Graph del lugar, del mismo tipo /g/ que usan las fichas de Hoteles. Como página repite los fallos de las fichas. Todas tienen el title "Place Viewer", no llevan canonical ni meta robots y robots.txt no las bloquea.

Según Ahrefs, google.com/searchviewer/ tiene datos en España desde el 22 de abril de 2026 y su tráfico estimado pasó de unas 33.000 visitas al mes el 1 de septiembre a 1,9 millones el 29 de octubre. El salto coincide con la actualización contra el spam de septiembre, y las URLs con más tráfico son fichas de comercios como Mercadona o Carrefour.

Muestra de unas 400 respuestas por celda de Brand Radar (España, octubre de 2026), con consultas que contienen "vuelo" o "hotel". Brand Radar separa AI Mode en un índice de búsquedas por keyword y otro de prompts en forma de pregunta.

Algunas respuestas sobre hoteles no citan nada. Para "hotel four seasons madrid precio", AI Mode me dio, en tres pruebas, precios por noche según el tipo de habitación sin ninguna fuente, ni siquiera "Google". Encaja con cómo llegan los datos del Knowledge Graph a la IA de Google, que se convierten en texto y que el modelo recibe sin URL, como expliqué en este análisis sobre el Knowledge Graph y la IA de Google.

Cuando le pedí a AI Mode que enumerase los datos que había usado, me devolvió un resultado de tipo HotelPriceResult para el 8 y el 9 de diciembre con los precios de 36 webs de reserva, que coinciden con los de la ficha de Google Hoteles para esas fechas. Los rangos de la respuesta salen de los precios por habitación de la web oficial, y las ofertas más baratas, desde 737 €, se quedan fuera. En la SERP clásica, el panel del hotel enseña esos mismos precios con un enlace a cada web, de Booking a trivago. AI Mode usa los mismos datos, responde "a partir de 1.300 o 1.400 €" y no enlaza a ninguna.

Esto afecta a la Ley de Mercados Digitales, cuyo artículo 6.5 prohíbe a Google tratar "más favorablemente" a sus propios servicios y productos frente a los de terceros, "ni en la clasificación ni en las funciones relacionadas de indexado y rastreo". El 23 de julio de 2026 la Comisión Europea multó a Google con 460 millones de euros por autopreferencia en compras, hoteles, transporte y deportes, y en el mismo comunicado dice que toma nota de cómo propone Google aplicar la decisión a AI Overviews y AI Mode, un diálogo que sigue abierto. Si el artículo 6.5 se aplica a AI Mode, que es lo que la Comisión está discutiendo con Google, la pregunta es si responder sobre vuelos citando solo a Google Flights es tratar más favorablemente a su propio servicio. Con estos datos no puedo decir si AI Mode cumple, pero sí que en España hay respuestas sobre vuelos que solo citan a Google, que ese tráfico va etiquetado y que en hoteles usa los precios de terceros sin enlazarlos.

La regla general del robots.txt de Google deja pasar a los rastreadores de IA por /travel/hotels/ y /travel/flights/, pero el servidor los bloquea. Cuando pido las páginas desde una IP normal con el user agent de OAI-SearchBot, ChatGPT-User, GPTBot, PerplexityBot o Claude-SearchBot, Google Travel responde con una redirección 302 a /travel/unsupported, una página que pide actualizar el navegador ("Time for an upgrade"). Pasa en las landings, en las fichas y en Vuelos, y también con el rastreador de Vertex AI, que es de la propia Google. Googlebot y Bingbot para móvil sí reciben la página.

Cuando pedí a cada asistente que abriera la ficha del Four Seasons Madrid y me dijera su precio y su valoración, Claude llegó a la página de navegador no compatible, ChatGPT explicó que Google lo redirigía a una pantalla de consentimiento y Perplexity no pudo abrirla. Gemini, que es de Google, respondió buscando en Google Hoteles. Con la landing de Vuelos de la ruta Madrid-Bangkok pasó lo mismo. ChatGPT llegó esta vez a la página de navegador no compatible, y Gemini contestó con precios de Google Flights para unas fechas que eligió él.

Como control probé una ficha de google.com/searchviewer/, que Google sí sirve a los bots de IA. ChatGPT la abrió y dio la valoración y los precios por noche del hotel, así que en su caso el bloqueo es propio de Google Travel. Claude, Perplexity y Gemini no pudieron abrirla.

Aun así, según Brand Radar ChatGPT cita Google Travel en más de 1.700 respuestas en España, casi dos tercios con fichas de hotel. Cuando le pregunté "¿Cuánto cuesta una noche en el Four Seasons Madrid?", respondió "entre 1.200 y 1.600 €" con un solo indicador de fuentes, "Expedia +2", que incluye Expedia, la Guía MICHELIN y la ficha de Google Hoteles. El texto nombra a MICHELIN, pero nunca a Google. Entre sus 7 fuentes hay 4 URLs de esa misma ficha, con dos formas de ID, tres dominios de Google (.com, .es y .co.ve) y estados guardados de búsquedas de 2019 y 2024. No abrió ninguna y respondió con los fragmentos de su buscador, que sí tiene el contenido de la ficha.

Ese contenido no sale de Bing. En Bing, las fichas de Google Hoteles aparecen con el title "Google" y la descripción "Google", sin más texto, y algunas URLs de Vuelos tienen como descripción la página comprimida, en bytes ilegibles. El buscador de ChatGPT, en cambio, tenía de esas fichas el nombre del hotel, su descripción y hasta el precio por noche, así que OpenAI guarda su propia copia de Google Travel en su índice. No he podido saber si la consiguió antes de que Google bloqueara a sus bots o por otra vía.

Cuatro de los fallos se pueden reproducir con curl. La cookie SOCS evita el muro de consentimiento de la UE.

Con la misma página abierta en móvil, este código en la consola de DevTools devuelve 36 enlaces con parámetros de 36.

Para verlo en el render de Googlebot, inspecciona en Search Console una URL de tu dominio que redirija a la landing y saca sus enlaces con esta extensión.

Los rankings, el tráfico estimado y las SERP salen de la base de España de Ahrefs (Site Explorer, Keywords Explorer y Brand Radar), que consulté el 29 de octubre de 2026.

¿Tienes preguntas? Estamos en LinkedIn y en X.