Aviso legal: Este artigo aborda apenas o acesso a dados públicos em páginas de listagem do TripAdvisor. Antes de qualquer coleta, verifique os Termos de Serviço da plataforma, a Computer Fraud and Abuse Act (CFAA) nos EUA e o Regulamento Geral de Proteção de Dados (GDPR) na UE. Raspar dados pessoais de revisores sem base legal pode violar o GDPR. Use as APIs oficiais quando disponíveis.
Se você trabalha com inteligência de viagens, análise de reputação ou monitoramento competitivo, saber como raspar avaliações do TripAdvisor em 2026 é uma habilidade essencial — mas a infraestrutura anti-bot da plataforma tornou o processo consideravelmente mais complexo do que era há poucos anos. Neste guia, vamos cobrir o que é público, como o TripAdvisor bloqueia raspadores, qual endpoint GraphQL usar e como configurar proxies residenciais rotativos para manter uma coleta estável.
O que é público no TripAdvisor: listagens, avaliações e carregamento preguiçoso
As páginas /Hotel_Review e /Restaurant_Review do TripAdvisor exibem publicamente informações como nome do estabelecimento, endereço, classificação agregada (estrelas), número de avaliações e o texto das próprias avaliações — incluindo título, nota, data de publicação e texto. Esses dados são visíveis sem login e, portanto, são considerados públicos. No entanto, o TripAdvisor não renderiza todas as avaliações no HTML inicial.
A plataforma usa carregamento preguiçoso (lazy-loading): a página carrega as primeiras 5–10 avaliações no HTML server-side e as demais via chamadas AJAX subsequentes. Quando você rola a página, o navegador dispara requisições para o endpoint interno /data/graphql/ids, que retorna dados estruturados em JSON. Isso significa que um simples requests.get() só captura o primeiro lote — e mesmo esse pode ser bloqueado antes de chegar.
Dados acessíveis sem login vs. dados protegidos
- Sem login: nome do estabelecimento, endereço, classificação, texto da avaliação, data de publicação, fotos públicas.
- Com login: detalhes do perfil do revisor, mensagens privadas, avaliações marcadas como úteis. Não recomendamos coletar dados de perfis pessoais — isso entra em conflito direto com o GDPR para usuários europeus.
A stack anti-bot do TripAdvisor: Cloudflare, DataDome e fingerprinting TLS
O TripAdvisor emprega uma combinação de camadas de proteção que vai muito além de simples rate limiting. Em 2026, a infraestrutura inclui:
- Cloudflare Bot Management: inspeção de fingerprints de navegador, desafios JavaScript e análise de padrões de tráfego. O Cloudflare Bot Management classifica requisições em tempo real com base em dezenas de sinais.
- DataDome: solução anti-bot especializada que complementa o Cloudflare, focando em detecção de automação via análise comportamental e fingerprints de dispositivo.
- Fingerprinting TLS/HTTP2: o servidor examina a extensão JA3/JA4 do handshake TLS e os parâmetros HTTP/2 (SETTINGS, prioridade de frames, ordem de headers). Bibliotecas HTTP padrão como
requestsouhttpxproduzem fingerprints que não correspondem a nenhum navegador real. - Bloqueio de IPs datacenter: intervalos de IPs de provedores como AWS, Google Cloud e DigitalOcean são bloqueados ou desafiados independentemente dos headers enviados. Não importa se você simula um User-Agent perfeito — o IP já delata você.
É por isso que proxies datacenter falham consistentemente no TripAdvisor. Mesmo com headers impecáveis e JavaScript resolvido, o IP de origem pertence a um AS (Autonomous System) conhecido por hospedar bots. A única solução confiável é usar proxies residenciais — IPs que pertencem a provedores de internet domésticos reais.
O endpoint GraphQL interno e por que geo-targeting importa
Em vez de fazer parsing do HTML complexo e instável, a abordagem mais robusta é chamar diretamente o endpoint GraphQL que o próprio frontend do TripAdvisor usa. O camão é /data/graphql/ids, aceita requisições POST e requer um token X-Requested-By que pode ser extraído do HTML da página inicial da listagem.
Uma requisição típica se parece com isto:
POST /data/graphql/ids
Content-Type: application/json
X-Requested-By: <token extraído do HTML>
{
"query": "query ReviewList($locationId: Int!, $offset: Int!, $limit: Int!) { ... }",
"variables": {"locationId": 123456, "offset": 0, "limit": 10}
}A resposta retorna nós de avaliação estruturados com campos como title, rating, text, publishedDate e userId (que você deve ignorar para conformidade com GDPR).
Por que geo-targeting residencial é necessário
O TripAdvisor serve conteúdo diferente dependendo do país e cidade do visitante. Uma listagem de hotel em Londres pode mostrar avaliações em inglês para visitantes do Reino Unido e avaliações traduzidas para visitantes do Brasil. Se você precisa de avaliações no idioma original, deve rotear suas requisições através de proxies residenciais no país de origem do estabelecimento.
Com o ProxyHat, você pode especificar país e cidade diretamente no nome de usuário:
http://user-country-GB-city-london:pass@gate.proxyhat.com:8080Isso garante que o TripAdvisor veja uma requisição vinda de um IP residencial britânico, retornando o conteúdo localizado correto.
Exemplo prático em Python com curl_cffi e ProxyHat
A biblioteca curl_cffi permite impersonar o fingerprint TLS/HTTP2 do Chrome, contornando a detecção JA3/JA4. Combinada com proxies residenciais do ProxyHat, ela oferece a melhor chance de acesso estável.
from curl_cffi import requests as curl_requests
import json
# ProxyHat residential proxy with UK geo-targeting
proxy_url = "http://user-country-GB-city-london: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",
"Accept": "application/json",
"Content-Type": "application/json",
"Referer": "https://www.tripadvisor.co.uk/",
}
# Step 1: Fetch the listing page to extract X-Requested-By token
listing_url = "https://www.tripadvisor.co.uk/Hotel_Review-g186338-d123456-Reviews-Hotel_Name-London_England.html"
response = curl_requests.get(
listing_url,
headers=headers,
proxies=proxies,
impersonate="chrome131"
)
# Extract token from HTML (simplified — adjust selector as needed)
import re
token_match = re.search(r'X-Requested-By["\s:]+([a-f0-9]+)', response.text)
token = token_match.group(1) if token_match else ""
headers["X-Requested-By"] = token
# Step 2: POST GraphQL query for reviews
graphql_url = "https://www.tripadvisor.co.uk/data/graphql/ids"
payload = {
"query": """
query ReviewList($locationId: Int!, $offset: Int!, $limit: Int!) {
location(id: $locationId) {
reviewList(offset: $offset, limit: $limit) {
reviews {
title
rating
text
publishedDate
}
}
}
}
""",
"variables": {"locationId": 123456, "offset": 0, "limit": 10}
}
resp = curl_requests.post(
graphql_url,
headers=headers,
json=payload,
proxies=proxies,
impersonate="chrome131"
)
data = resp.json()
reviews = data["data"]["location"]["reviewList"]["reviews"]
for review in reviews:
print(json.dumps({
"title": review.get("title", ""),
"rating": review.get("rating", 0),
"text": review.get("text", "")[:200], # truncate
"publishedDate": review.get("publishedDate", "")
}, ensure_ascii=False, indent=2))
Observe que truncamos o texto da avaliação para 200 caracteres no exemplo. Em produção, você pode armazenar o texto completo, mas evite coletar userId ou qualquer dado pessoal do revisor.
Exemplo em Node.js com undici e ProxyHat
import { fetch, ProxyAgent } from "undici";
const proxyUrl = "http://user-country-GB-city-london:PASSWORD@gate.proxyhat.com:8080";
const dispatcher = new ProxyAgent(proxyUrl);
const 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",
"Accept": "application/json",
"Content-Type": "application/json",
"Referer": "https://www.tripadvisor.co.uk/",
};
// Fetch listing page for token
const listingRes = await fetch("https://www.tripadvisor.co.uk/Hotel_Review-g186338-d123456-Reviews-Hotel-London.html", {
headers,
dispatcher,
});
const html = await listingRes.text();
const tokenMatch = html.match(/X-Requested-By["\s:]+([a-f0-9]+)/);
const token = tokenMatch ? tokenMatch[1] : "";
headers["X-Requested-By"] = token;
// POST GraphQL
const gqlRes = await fetch("https://www.tripadvisor.co.uk/data/graphql/ids", {
method: "POST",
headers,
dispatcher,
body: JSON.stringify({
query: `query ReviewList($locationId: Int!, $offset: Int!, $limit: Int!) {
location(id: $locationId) {
reviewList(offset: $offset, limit: $limit) {
reviews { title rating text publishedDate }
}
}
}`,
variables: { locationId: 123456, offset: 0, limit: 10 }
})
});
const data = await gqlRes.json();
console.log(data.data.location.reviewList.reviews);
Rate limits realistas, sessões sticky e backoff
Com base na experiência prática de desenvolvedores de raspagem de viagens, aqui estão os parâmetros realistas para coleta no TripAdvisor em 2026:
| Parâmetro | Valor recomendado | Observação |
|---|---|---|
| Requisições por IP por hora | 50–100 listagens | Ultrapassar isso dispara desafios DataDome |
| Reset após bloqueio | 5–10 minutos | Use backoff exponencial, não retente imediatamente |
| Concorrência por IP | 1–2 conexões | Múltiplas conexões simultâneas do mesmo IP são suspeitas |
| Latência típica com proxy residencial | 200–800ms | Varia conforme localização do proxy e do servidor |
| Taxa de sucesso esperada | 90–95% | Com proxies residenciais rotativos e impersonação TLS adequada |
Usando sessões sticky para paginação
Quando você pagina avaliações (offset 0, 10, 20...), é importante manter o mesmo IP durante toda a sequência de requisições para um estabelecimento. Se o IP mudar no meio, o TripAdvisor pode interpretar como comportamento anômalo. Use a flag -session- no nome de usuário do ProxyHat:
http://user-session-hotel-123456:PASSWORD@gate.proxyhat.com:8080Cada session-abc123 mantém o mesmo IP de saída por padrão até 30 minutos. Quando terminar de raspar um estabelecimento, troque o identificador de sessão para obter um novo IP.
Estratégia de backoff
import time
import random
def fetch_with_backoff(url, max_retries=5):
for attempt in range(max_retries):
try:
resp = curl_requests.get(url, proxies=proxies, impersonate="chrome131")
if resp.status_code == 200:
return resp.json()
elif resp.status_code == 403:
# Blocked — backoff
wait = (2 ** attempt) + random.uniform(1, 5)
print(f"Blocked, waiting {wait:.1f}s...")
time.sleep(wait)
else:
print(f"Status {resp.status_code}, retrying...")
time.sleep(2)
except Exception as e:
print(f"Error: {e}, retrying...")
time.sleep(5)
return None
Comparação: tipos de proxy para raspagem do TripAdvisor
| Tipo de proxy | Taxa de sucesso | Velocidade | Custo | Recomendado para TripAdvisor? |
|---|---|---|---|---|
| Datacenter | 10–20% | Rápido (50ms) | Baixo | Não — bloqueado quase sempre |
| Residencial rotativo | 90–95% | Médio (200–800ms) | Médio | Sim — melhor opção geral |
| Mobile | 95–99% | Variável (300–1500ms) | Alto | Sim — para volumes altos ou alvos sensíveis |
Para a maioria dos casos de uso de inteligência de viagens, proxies residenciais rotativos como os da ProxyHat oferecem o melhor equilíbrio entre custo e confiabilidade. Confira as localizações disponíveis para garantir cobertura no país-alvo.
Erros comuns e casos de borda
1. Não extrair o token X-Requested-By
O endpoint GraphQL rejeita requisições sem o token válido. O token muda a cada sessão e deve ser extraído do HTML da página de listagem. Se você reutilizar um token antigo, recebe um 403.
2. Usar fingerprint TLS errado
requests usa urllib3, cujo fingerprint JA3 não corresponde a nenhum navegador. O DataDome detecta isso em milissegundos. Use sempre curl_cffi com impersonate="chrome131" ou equivalente.
3. Ignorar o schema GraphQL mutável
O TripAdvisor atualiza seu schema GraphQL periodicamente. Campos podem ser renomeados ou removidos. Monitore suas respostas e tenha tratamento de erros robusto para campos ausentes.
4. Não respeitar robots.txt
Verifique sempre https://www.tripadvisor.com/robots.txt antes de iniciar a coleta. Embora o robots.txt não seja legalmente vinculante, ignorá-lo pode ser usado como evidência de má fé em disputas legais.
Extração de dados TripAdvisor: considerações éticas
Raspar avaliações públicas para análise agregada (sentimento médio, distribuição de notas, volume temporal) é geralmente aceitável. No entanto, há limites importantes:
- Não colete dados pessoais: nomes de usuários, IDs de perfil, fotos de avatar e localização declarada do revisor são dados pessoais sob o GDPR. Se você precisa de referência ao autor, use um hash irreversível e não armazene o original.
- Agregue, não identifique: o valor analítico está em padrões agregados, não em avaliações individuais. Considere armazenar apenas estatísticas sumarizadas por estabelecimento.
- Respeite a frequência: 50–100 requisições por hora por IP é um limite razoável. Não tente maximizar throughput à custa da infraestrutura do alvo.
- Considere a API oficial: o TripAdvisor oferece um Content API para parceiros. Se você precisa de dados de forma confiável e sustentável, esta é a rota recomendada. A API oficial garante conformidade com os Termos de Serviço e elimina riscos legais.
Para casos de uso de web scraping e rastreamento SERP, a ProxyHat oferece infraestrutura de proxy residencial compatível. Consulte a documentação oficial para detalhes de integração.
Principais conclusões
- Dados públicos apenas: listagens, classificações e textos de avaliações em
/Hotel_Reviewe/Restaurant_Reviewsão públicos; dados de perfis não são.- Use o endpoint GraphQL:
/data/graphql/idscom tokenX-Requested-Byretorna dados estruturados, evitando parsing de HTML frágil.- Proxies residenciais são obrigatórios: IPs datacenter são bloqueados pelo Cloudflare e DataDome independentemente de headers.
- Geo-targeting importa: use
-country-GB-city-londonpara conteúdo localizado correto.- Rate limit realista: 50–100 listagens/hora por IP, com backoff exponencial em caso de 403.
- Use sessões sticky:
-session-abc123mantém o mesmo IP durante paginação de um estabelecimento.- Seja ético: agregue dados, não colete informações pessoais e considere a API oficial do TripAdvisor quando disponível.
Perguntas frequentes
O que é raspar avaliações do TripAdvisor em 2026?
É o processo de extrair dados públicos de avaliações de hotéis e restaurantes do TripAdvisor usando técnicas de web scraping modernas. Em 2026, isso envolve contornar proteções anti-bot como Cloudflare e DataDome, usar proxies residenciais rotativos com geo-targeting e acessar o endpoint GraphQL interno para obter dados estruturados, em vez de fazer parsing do HTML renderizado.
Por que raspar TripAdvisor importa para usuários de proxy?
O TripAdvisor bloqueia IPs datacenter de forma agressiva, tornando proxies residenciais essenciais. Usuários de proxy precisam entender geo-targeting (país/cidade), rotação de IPs e sessões sticky para manter coleta estável. A escolha correta de proxy determina se a taxa de sucesso será 10% ou 95%.
Qual tipo de proxy funciona melhor para raspar TripAdvisor?
Proxies residenciais rotativos são a melhor opção geral, com taxa de sucesso de 90–95%. Proxies mobile oferecem a maior taxa de sucesso (95–99%) a um custo mais alto. Proxies datacenter são praticamente inúteis no TripAdvisor, com taxa de sucesso de apenas 10–20%, pois são detectados pelo AS logo no handshake TLS.
Como evitar bloqueios ao raspar TripAdvisor?
Use curl_cffi para impersonação do fingerprint TLS do Chrome, rotacione proxies residenciais a cada 50–100 requisições, mantenha sessões sticky durante paginação, implemente backoff exponencial em resposta a 403, extraia o token X-Requested-By a cada sessão e respeite limites de concorrência de 1–2 conexões por IP.
Raspar TripAdvisor é legal?
O acesso a dados públicos sem login é geralmente aceitável, mas deve respeitar os Termos de Serviço da plataforma, a CFAA nos EUA e o GDPR na UE. Coletar dados pessoais de revisores sem base legal pode violar o GDPR. Para uso comercial sustentável, a API oficial do TripAdvisor é a rota mais segura. Consulte sempre um advogado para sua situação específica.
