Aviso legal: Esta guía cubre el acceso a datos públicos únicamente. Debes respetar los Términos de Servicio de TripAdvisor, la Computer Fraud and Abuse Act (CFAA) en EE. UU. y el Reglamento General de Protección de Datos (GDPR) en la UE. No extraigas datos personales identificables de revisores ni eludas barreras de autenticación. Si TripAdvisor ofrece una API oficial para tu caso de uso, úsala primero.
Si construyes productos de inteligencia de viajes o análisis de reputación, tarde o temprano te preguntas cómo scrapear reseñas de TripAdvisor en 2026. Las páginas de reseñas de hoteles y restaurantes contienen texto público valioso: valoraciones, fechas, títulos y puntuaciones. Sin embargo, TripAdvisor combina múltiples capas de protección anti-bot que hacen que la extracción de datos TripAdvisor sea considerablemente más compleja que un scraping HTML convencional.
Esta guía explica qué datos son realmente públicos, cómo funciona el sistema anti-bot de TripAdvisor, qué endpoint GraphQL interno devuelve datos estructurados y cómo configurar un scraper de reseñas TripAdvisor con proxies residenciales rotativos que mantengan tasas de éxito altas sin disparar bloqueos.
Qué datos son públicos en TripAdvisor y cómo se cargan las reseñas
Las páginas /Hotel_Review y /Restaurant_Review muestran información visible sin inicio de sesión: nombre del establecimiento, puntuación global, número de reseñas, texto de cada reseña, fecha de publicación y ubicación. Esto es, en principio, información pública accesible al navegador de cualquier usuario.
Sin embargo, TripAdvisor lazy-load la mayoría de las reseñas. Cuando abres una página de hotel, solo se renderizan las primeras 5–10 reseñas en el HTML inicial. El resto se carga dinámicamente mediante peticiones XHR/Fetch a medida que el usuario hace scroll o pulsa «Más reseñas». Esto significa que un requests.get() simple solo obtendrá un subconjunto pequeño del contenido visible.
Hay dos enfoques principales para capturar todas las reseñas:
- Renderizado con headless browser: usar Playwright o Puppeteer para simular scroll y esperar a que carguen las reseñas. Es robusto pero lento (3–8 segundos por página) y consume muchos recursos.
- Llamada directa al endpoint GraphQL interno: interceptar la petición que hace el frontend y replicarla. Es más rápido (200–500 ms por página de resultados) pero requiere reproducir cabeceras y tokens correctamente.
Para volúmenes serios, el segundo enfoque es preferible, pero exige sortear el stack anti-bot.
El stack anti-bot de TripAdvisor: Cloudflare, DataDome y fingerprinting TLS
TripAdvisor no sirve su contenido a cualquier cliente HTTP. La plataforma combina al menos dos sistemas de protección:
- Cloudflare — gestiona el WAF, rate limiting a nivel de edge y desafíos JavaScript.
- DataDome — especializado en detección de bots, analiza fingerprints del navegador, patrones de navegación y reputación de IP.
El fingerprinting que aplican va más allá de los User-Agent strings. Incluye:
- TLS fingerprinting (JA3/JA4): el handshake TLS de
requestsoaxiosno coincide con el de Chrome real, y DataDome lo detecta. - HTTP/2 fingerprinting: orden de cabeceras, priorización de streams y configuración de frames.
- Reputación de IP: las IPs de datacenters (AWS, DigitalOcean, OVH) tienen una probabilidad de bloqueo cercana al 90% en la primera petición, independientemente de los cabeceras que envíes.
Si usas IPs de datacenter, ni siquiera el TLS impersonation perfecto te salvará. DataDome marca el rango de IP como sospechoso antes de evaluar tu handshake. Los proxies residenciales son un requisito, no una optimización.
Esto explica por qué tantos desarrolladores reportan que su scraper funciona en local pero recibe HTTP 403 o desafíos infinitos cuando lo despliegan en un VPS. La diferencia no está en el código; está en la IP.
| Tipo de IP | Probabilidad de bloqueo inicial | Uso recomendado |
|---|---|---|
| Datacenter | ~85–95% | No recomendado para TripAdvisor |
| Residencial rotativo | ~5–15% | Scraping de reseñas a escala |
| Móvil | ~2–8% | Alto volumen, mayor coste |
El endpoint GraphQL interno de TripAdvisor
El frontend de TripAdvisor obtiene datos estructurados mediante peticiones POST a un endpoint interno de GraphQL, típicamente en la ruta /data/graphql/ids. Este endpoint acepta consultas GraphQL que devuelven reseñas, información de ubicación, fotos y metadatos en formato JSON estructurado, evitando la necesidad de parsear HTML.
Para replicar estas peticiones necesitas:
- Un header
X-Requested-Bycon un token válido. Este token se genera en el cliente y está embebido en el HTML inicial de la página o se obtiene mediante una llamada previa. - Cabeceras de navegador completas y consistentes, incluyendo
Content-Type: application/jsony cookies de sesión de Cloudflare/DataDome. - Una consulta GraphQL bien formada que especifique los campos:
title,rating,text,publishedDate,locationId.
El body de la petición tiene una estructura similar a:
{
"queries": [
{
"query": "query ReviewsQuery($locationId: ID!, $offset: Int, $limit: Int) { locationReviews(locationId: $locationId, offset: $offset, limit: $limit) { reviewList { review { title rating text publishedDate } } } }",
"variables": { "locationId": "1234567", "offset": 0, "limit": 10 }
}
]
}
La respuesta es JSON estructurado, mucho más fácil de parsear que el HTML. El reto está en que la primera petición (para obtener el token X-Requested-By y las cookies) debe pasar el filtro anti-bot completo. Aquí es donde entran los proxies residenciales con geo-targeting.
Para listings localizadas —por ejemplo, restaurantes en una ciudad concreta— el geo-targeting por país y ciudad es esencial. TripAdvisor sirve contenido diferente según la geolocalización de la IP del visitante. Si necesitas reseñas de hoteles en Londres, una IP en Brasil puede recibir resultados diferentes o redirecciones. Con ProxyHat puedes especificar -country-GB-city-london en el usuario para asegurar que tu IP residencial coincide con la ubicación objetivo.
Ejemplo práctico en Python con curl_cffi y ProxyHat
La biblioteca curl_cffi permite realizar peticiones HTTP con fingerprinting TLS idéntico al de Chrome real. Combinada con proxies residenciales de ProxyHat, es la forma más eficaz de replicar el comportamiento de un navegador legítimo.
Primero, instala las dependencias:
pip install curl_cffi
Ejemplo completo de una petición GraphQL a TripAdvisor usando ProxyHat:
from curl_cffi import requests
import json
# ProxyHat residential proxy with London geo-targeting
proxy_url = "http://user-country-GB-city-london-session-sess01:PASSWORD@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
"Content-Type": "application/json",
"X-Requested-By": "EXAMPLE_TOKEN_FROM_INITIAL_PAGE",
"Referer": "https://www.tripadvisor.co.uk/Hotel_Review-g186338-d1234567-Reviews-Hotel_Name-London_England.html",
"Origin": "https://www.tripadvisor.co.uk",
}
graphql_payload = {
"queries": [
{
"query": """query ReviewsQuery($locationId: ID!, $offset: Int) {
locationReviews(locationId: $locationId, offset: $offset) {
reviewList {
review {
title
rating
text
publishedDate
}
}
}
}""",
"variables": {"locationId": "1234567", "offset": 0}
}
]
}
response = requests.post(
"https://www.tripadvisor.co.uk/data/graphql/ids",
headers=headers,
json=graphql_payload,
proxies=proxies,
impersonate="chrome131",
timeout=30,
)
data = response.json()
reviews = data[0]["data"]["locationReviews"]["reviewList"]["review"]
for r in reviews[:3]:
print(f"Titulo: {r['title']}")
print(f"Puntuacion: {r['rating']}")
print(f"Fecha: {r['publishedDate']}")
print(f"Texto: {r['text'][:120]}...")
print("---")
Notas clave sobre este código:
impersonate="chrome131"hace que curl_cffi reproduzca el handshake TLS y HTTP/2 de Chrome 131, evitando la detección por JA3/JA4 fingerprinting.- El flag
-session-sess01en el usuario mantiene la misma IP residencial entre peticiones, preservando cookies y tokens de Cloudflare. - El
X-Requested-Bydebe obtenerse de una petición GET previa a la página del listing. Necesitarás hacer esa petición inicial con el mismo proxy y sesión.
Ejemplo en Node.js con undici
import { fetch, Agent } from "undici";
const proxyUrl = "http://user-country-GB-city-london-session-sess02:PASSWORD@gate.proxyhat.com:8080";
const response = await fetch("https://www.tripadvisor.co.uk/data/graphql/ids", {
method: "POST",
headers: {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
"Content-Type": "application/json",
"X-Requested-By": "EXAMPLE_TOKEN",
"Referer": "https://www.tripadvisor.co.uk/Hotel_Review-g186338-d1234567.html",
},
body: JSON.stringify({
queries: [{
query: `query ReviewsQuery($locationId: ID!, $offset: Int) { locationReviews(locationId: $locationId, offset: $offset) { reviewList { review { title rating text publishedDate } } } }`,
variables: { locationId: "1234567", offset: 0 }
}]
}),
dispatcher: new Agent({
proxy: proxyUrl,
connect: { allowH2: true }
})
});
const data = await response.json();
console.log(data[0].data.locationReviews.reviewList.review.length);
Límites de tasa, sesiones sticky y backoff
TripAdvisor y sus sistemas anti-bot imponen límites efectivos. Basándonos en pruebas empíricas de la comunidad de scraping, los rangos realistas son:
- 50–100 listings por hora por IP antes de que DataDome empiece a devolver desafíos.
- 5–10 minutos de reset si una IP recibe un bloqueo temporal (HTTP 403 o challenge page).
- 10–20 reseñas por petición GraphQL usando el parámetro
limitooffset. - 200–500 ms de latencia por petición GraphQL exitosa con proxy residencial.
Estrategias recomendadas:
- Sesiones sticky: usa el flag
-session-abc123para mantener la misma IP durante una secuencia de peticiones relacionadas (obtener token, luego GraphQL, luego paginación). Cambia de sesión cada 30–50 peticiones. - Backoff exponencial: si recibes un 403 o 429, espera 60s, luego 120s, luego 300s antes de reintentar con una nueva sesión.
- Paginación por offset: incrementa
offseten bloques de 10. TripAdvisor puede tener miles de reseñas por hotel; no intentes cargar todas en una sola petición. - Rotación de geo: si scrapeas múltiples ciudades, rota el parámetro
-city-para que cada IP residencial corresponda a la región del listing.
import time
import random
def scrape_with_backoff(location_id, max_retries=5):
for attempt in range(max_retries):
session_id = f"sess_{location_id}_{attempt}"
proxy = f"http://user-country-GB-city-london-session-{session_id}:PASS@gate.proxyhat.com:8080"
try:
resp = make_graphql_request(location_id, proxy, offset=attempt * 10)
if resp.status_code == 200:
return resp.json()
elif resp.status_code in (403, 429):
wait = (2 ** attempt) * 60 + random.uniform(0, 30)
time.sleep(wait)
else:
time.sleep(5)
except Exception:
time.sleep(30)
return None
Para escalar a miles de listings, consulta las opciones de planes de ProxyHat y la disponibilidad de ubicaciones de proxy por país.
Extracción ética de datos y cuándo usar la API oficial
Scrapear reseñas de TripAdvisor plantea consideraciones éticas y legales serias que no debes ignorar.
Datos personales bajo GDPR: Las reseñas en TripAdvisor pueden contener nombres de usuarios, ubicaciones y fechas. Bajo el GDPR, los datos personales de revisores de la UE están protegidos, incluso si son públicos. Extraer y almacenar nombres de usuarios individuales puede constituir procesamiento de datos personales. Recomendaciones:
- Aggregate datos a nivel de listing (puntuación media, distribución de estrellas, volumen de reseñas).
- No almacenes nombres de usuarios, avatares ni identificadores personales.
- Trunca o anonimiza el texto de reseñas si contiene información personal incidental.
- Documenta tu base legal (interés legítimo) si operas en la UE.
Respeto por los Términos de Servicio: Los ToS de TripAdvisor prohíben típicamente el scraping automatizado. Aunque la legalidad de acceder a datos públicos es objeto de debate (caso hiQ Labs v. LinkedIn), violar ToS puede resultar en bloqueo de IP, cartas de cease-and-desist o acciones legales.
Cuándo usar la API oficial: TripAdvisor ofrece acceso a datos a través de programas de partners y APIs de contenido. Si tu caso de uso es comercial (dashboards de reputación, análisis competitivo de hoteles), la API oficial es la opción más sostenible. Las ventajas incluyen:
- Datos estructurados y garantizados contractualmente.
- Sin riesgo de bloqueos ni infraestructura de proxies.
- Cumplimiento automático de ToS.
Usa scraping solo cuando la API oficial no cubra tu necesidad específica (datos históricos, listings no incluidos en la API, investigación académica con datos agregados).
Para más contexto sobre patrones de scraping responsable, consulta nuestra guía de casos de uso de web scraping y de tracking SERP. La documentación técnica de ProxyHat está disponible en docs.proxyhat.com.
Conclusiones clave
- Las reseñas de TripAdvisor son públicas pero lazy-loaded; el endpoint GraphQL interno
/data/graphql/idsdevuelve datos estructurados más eficientemente que renderizar HTML.- El stack anti-bot (Cloudflare + DataDome) bloquea IPs de datacenter con ~85–95% de probabilidad; los proxies residenciales son obligatorios.
- curl_cffi con
impersonate="chrome131"replica el fingerprint TLS de Chrome, pero solo funciona con IPs residenciales limpias.- Límites realistas: 50–100 listings/hora por IP, con resets de 5–10 minutos tras bloqueos.
- Usa sesiones sticky (
-session-xxx) para mantener cookies y tokens entre peticiones relacionadas.- Aggregate datos, no extraigas información personal de revisores, y considera la API oficial de TripAdvisor para uso comercial.
Si necesitas proxies residenciales con geo-targeting por país y ciudad para tu proyecto de extracción de datos TripAdvisor, ProxyHat ofrece planes flexibles con rotación automática y sesiones sticky configurables directamente en el usuario del proxy.
