Come estrarre recensioni TripAdvisor nel 2026: guida per sviluppatori

Avviso legale: questo articolo riguarda esclusivamente l'accesso a dati pubblicamente visibili su TripAdvisor. Prima di qualsiasi attività di scraping, consulta i Termini di Servizio della piattaforma. Negli Stati Uniti, il Computer Fraud and Abuse Act (CFAA) disciplina l'accesso non autorizzato a sistemi informatici; nell'UE, il General Data Protection Regulation (GDPR) protegge i dati personali, incluse le recensioni identificabili. Non raccogliere dati personali non pubblici, non aggirare paywall o login e rispetta robots.txt.

Come estrarre recensioni TripAdvisor nel 2026: il contesto tecnico

Se operi nel travel intelligence o nell'analisi delle recensioni, probabilmente hai bisogno di dati strutturati da TripAdvisor: valutazioni, testi delle recensioni, date di pubblicazione e metadati delle location. La sfida non è tanto il parsing HTML — TripAdvisor espone pagine listing ricche di dati — quanto la tecnologia anti-bot che protegge ogni endpoint. In questa guida vedremo come estrarre recensioni TripAdvisor nel 2026 usando proxy residenziali rotanti, impersonazione TLS e l'endpoint GraphQL interno, con esempi eseguibili in Python.

Per un quadro generale sull'uso dei proxy per web scraping, consulta la nostra pagina use-case sul web scraping.

Cosa è pubblico su TripAdvisor

Le pagine /Hotel_Review e /Restaurant_Review mostrano pubblicamente, senza login:

• Nome e indirizzo della struttura.
• Valutazione complessiva (da 1 a 5 bubble).
• Recensioni singole con titolo, testo, data di pubblicazione e nome utente pubblico.
• Numero di recensioni per utente e badge contributor.
• Foto caricate dagli utenti (con copyright rispettivo).

TripAdvisor lazy-loada le recensioni: la prima pagina ne mostra circa 5–10, mentre le successive vengono caricate dinamicamente via richieste GraphQL. L'HTML statico contiene solo i dati della prima pagina, quindi per il paginazione completa serve intercettare l'endpoint interno.

Lo stack anti-bot di TripAdvisor

TripAdvisor utilizza una combinazione di difese che rendono lo scraping non banale:

• Cloudflare come CDN e WAF di primo livello, con challenge JS e turnstile.
• DataDome come soluzione anti-bot specializzata, che analizza fingerprint del browser, pattern di navigazione e reputazione IP.
• Fingerprinting TLS/HTTP2: il server identifica il client confrontando l'ordine dei cipher suite, le estensioni TLS e i SETTINGS frame HTTP/2 con quelli di browser reali.
• Geolocalizzazione IP: le listing localizzate richiedono IP dal paese/città corretto.

Per questo motivo, gli IP datacenter vengono bloccati indipendentemente dagli header HTTP. DataDome mantiene un database di subnet associati a hosting provider (AWS, OVH, DigitalOcean) e li sfida o blocca a priori. Anche con header User-Agent perfetti e TLS fingerprint di Chrome, un IP datacenter viene rifiutato nel 90%+ dei casi.

Secondo la documentazione pubblica di DataDome, la piattaforma combina segnali lato client e lato server, inclusi TLS fingerprinting e IP reputation, per distinguere bot umani da automazione. La specifica RFC 7540 (HTTP/2) descrive i SETTINGS frame che i sistemi anti-bot usano come segnale fingerprint.

L'endpoint GraphQL interno /data/graphql/ids

Quando scorri le recensioni su una pagina TripAdvisor, il browser invia richieste POST a https://www.tripadvisor.com/data/graphql/ids. Questo endpoint accetta un body GraphQL e restituisce dati strutturati (JSON) con recensioni, metadati location e informazioni di paginazione.

Elementi chiave della richiesta:

• Header X-Requested-By: token che TripAdvisor genera lato client, spesso derivato da cookie di sessione. Senza questo header, il server restituisce 403.
• Body GraphQL: query con operation name, variabili per locationId, offset e limit.
• Cookie: sessione e token anti-bot impostati da DataDome.

Per listing localizzate (es. hotel a Londra con recensioni in inglese), serve un IP dal paese corretto. Con ProxyHat puoi specificare geo-targeting nel username: user-country-GB-city-london:pass instrada il traffico attraverso un IP residenziale di Londra.

Proxy residenziali rotanti: perché sono obbligatori

I proxy residenziali usano IP assegnati a ISP reali, quindi DataDome li tratta come traffico consumer legittimo. La rotazione automatica (per-request) distribuisce le richieste su subnet diverse, riducendo il rischio di rate-limit su un singolo IP.

Tipo di proxy	Success rate su TripAdvisor	Latenza tipica	Costo relativo
Datacenter	<10%	50–100 ms	Basso
Mobile	80–95%	800–2000 ms	Alto
Residenziale rotante	85–95%	200–800 ms	Medio

Per TripAdvisor, i proxy residenziali rotanti offrono il miglior compromesso tra successo, latenza e costo. I proxy mobile sono più sicuri ma significativamente più lenti e costosi. Verifica la nostra pagina prezzi per i piani residenziali.

Esempio pratico in Python con curl_cffi e ProxyHat

curl_cffi è una libreria Python che usa libcurl-impersonate per replicare il fingerprint TLS/HTTP2 di Chrome. Combinata con i proxy residenziali ProxyHat, permette di inviare richieste che DataDome classifica come traffico browser legittimo.

Installazione

pip install curl_cffi

Script completo

from curl_cffi import requests
import json

# ProxyHat residential proxy with UK geo-targeting
proxy_url = "http://user-country-GB-city-london:YOUR_PASSWORD@gate.proxyhat.com:8080"

GRAPHQL_URL = "https://www.tripadvisor.com/data/graphql/ids"

# This query is illustrative — inspect the actual query your browser sends
# via DevTools → Network → filter "graphql".
query = """
query ReviewList($locationId: Int!, $offset: Int, $limit: Int) {
  location(id: $locationId) {
    reviewList(offset: $offset, limit: $limit) {
      reviews {
        title
        rating
        text
        publishedDate
      }
    }
  }
}
"""

variables = {
    "locationId": 188739,   # Example: a London hotel
    "offset": 0,
    "limit": 10
}

headers = {
    "Content-Type": "application/json",
    "X-Requested-By": "YOUR_TOKEN_HERE",
    "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",
    "Referer": "https://www.tripadvisor.com/",
    "Origin": "https://www.tripadvisor.com",
}

response = requests.post(
    GRAPHQL_URL,
    json={"query": query, "variables": variables},
    headers=headers,
    impersonate="chrome",
    proxies={"http": proxy_url, "https": proxy_url},
    timeout=30,
)

if response.status_code == 200:
    data = response.json()
    reviews = data.get("data", {}).get("location", {}).get("reviewList", {}).get("reviews", [])
    for r in reviews[:3]:
        print(f"Titolo: {r.get('title')}")
        print(f"Valutazione: {r.get('rating')}/5")
        print(f"Data: {r.get('publishedDate')}")
        text = (r.get('text') or '')[:200]
        print(f"Testo: {text}...")
        print("---")
else:
    print(f"Errore {response.status_code}: {response.text[:500]}")

Nota: il token X-Requested-By va estratto dal traffico reale del browser. Apri DevTools, naviga una pagina recensione, filtra per graphql e copia l'header dalla richiesta legittima. Questo token ha una durata limitata (tipicamente 30–60 minuti), quindi va rinnovato periodicamente.

Esempio equivalente in Node.js

const { Curl } = require("node-libcurl");

const proxy = "http://user-country-GB-city-london:YOUR_PASSWORD@gate.proxyhat.com:8080";

const query = `
query ReviewList($locationId: Int!, $offset: Int, $limit: Int) {
  location(id: $locationId) {
    reviewList(offset: $offset, limit: $limit) {
      reviews { title rating text publishedDate }
    }
  }
}
`;

const body = JSON.stringify({
  query,
  variables: { locationId: 188739, offset: 0, limit: 10 }
});

const curl = new Curl();
curl.setOpt(Curl.option.URL, "https://www.tripadvisor.com/data/graphql/ids");
curl.setOpt(Curl.option.POSTFIELDS, body);
curl.setOpt(Curl.option.PROXY, proxy);
curl.setOpt(Curl.option.HTTPHEADER, [
  "Content-Type: application/json",
  "X-Requested-By: YOUR_TOKEN_HERE",
  "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
  "Referer: https://www.tripadvisor.com/",
]);
curl.setOpt(Curl.option.SSL_CIPHER_LIST, "DEFAULT:!aNULL");
curl.setOpt(Curl.option.HTTP_VERSION, Curl.http.VERSION_2_0);

curl.on("end", (status, data) => {
  if (status === 200) {
    const json = JSON.parse(data);
    const reviews = json.data?.location?.reviewList?.reviews || [];
    reviews.slice(0, 3).forEach(r => {
      console.log(`Titolo: ${r.title}, Rating: ${r.rating}/5, Data: ${r.publishedDate}`);
    });
  } else {
    console.error(`Errore ${status}`);
  }
  curl.close();
});
curl.perform();

Rate limit, sessioni sticky e backoff

TripAdvisor impone rate limit aggressivi per IP. Dall'esperienza sul campo:

• ~50–100 listing per ora per IP prima di soft-block (challenge DataDome).
• Reset di circa 5–10 minuti dopo un soft-block, durante i quali l'IP riceve challenge ripetute.
• Paginazione con offset: incrementa di 10 in 10, non richiedere tutte le pagine in sequenza rapida.

Strategia di rotazione consigliata

import time
import random

def scrape_location(location_id, max_pages=20):
    session_id = f"sess-{location_id}-{int(time.time())}"
    proxy = f"http://user-session-{session_id}-country-GB:PASS@gate.proxyhat.com:8080"

    for page in range(max_pages):
        offset = page * 10
        try:
            data = fetch_reviews(location_id, offset, proxy)
            process(data)
            # Randomized delay: 3–8 seconds between requests
            time.sleep(random.uniform(3, 8))
        except Exception as e:
            print(f"Blocco a offset {offset}: {e}")
            # Exponential backoff with jitter
            wait = (2 ** (page % 4)) + random.uniform(0, 5)
            print(f"Attesa {wait:.1f}s prima di riprovare")
            time.sleep(wait)
            # Rotate to a new IP on retry
            session_id = f"sess-{location_id}-retry-{int(time.time())}"
            proxy = f"http://user-session-{session_id}-country-GB:PASS@gate.proxyhat.com:8080"

La flag -session- nel username ProxyHat mantiene lo stesso IP per tutta la durata della sessione. Questo è utile quando devi mantenere cookie e token anti-bot coerenti tra richieste successive. Per paginazione su una singola location, una sessione sticky di 15–30 minuti è spesso sufficiente.

Per uso avanzato della sessione sticky e geo-targeting, consulta la documentazione ufficiale ProxyHat.

Errori comuni e edge case

1. Usare requests standard invece di curl_cffi

La libreria requests di Python usa un fingerprint TLS Python/urllib3, che DataDome riconosce immediatamente. Usa sempre curl_cffi con impersonate="chrome" o impersonate="safari".

2. Dimenticare l'header Origin

L'endpoint GraphQL valida l'header Origin. Senza https://www.tripadvisor.com, molte richieste vengono rifiutate con 403.

3. Token X-Requested-By scaduto

Se ricevi 403 su tutte le richieste, il token è probabilmente scaduto. Estrai un nuovo token dal browser e riprova.

4. Rotazione troppo aggressiva

Cambiare IP a ogni richiesta senza sessione sticky può innescare detection: DataDome vede un singolo cookie associato a IP che cambiano continuamente. Usa sessioni sticky di almeno 10–20 richieste.

5. Ignorare robots.txt

Controlla sempre https://www.tripadvisor.com/robots.txt prima di iniziare. Rispetta le direttive Disallow per i path che la piattaforma chiede di non scansionare.

Scraping etico e quando usare l'API ufficiale

L'accesso a dati pubblici per analisi aggregate (sentiment analysis, benchmark competitivo, monitoraggio recensioni) è generalmente considerato legittimo quando:

• Rispetti i Termini di Servizio della piattaforma.
• Non raccogli dati personali identificabili oltre il necessario.
• Non ripubblichi contenuti protetti da copyright senza autorizzazione.
• Mantieni un rate di richieste ragionevole che non impatta il servizio.

Note GDPR per recensori UE

Le recensioni TripAdvisor contengono username pubblici che possono essere considerati dati personali sotto il GDPR se associabili a una persona fisica. Se archivi recensioni per analisi:

• Anonimizza gli username quando possibile (es. hash irreversibile).
• Non arricchire i dati con profili social o informazioni aggiuntive sull'utente.
• Definisci un periodo di conservazione e cancella i dati dopo l'analisi.
• Documenta la base giuridica per il trattamento (es. interesse legittimo per analisi di mercato).

Per approfondimenti, consulta le linee guida del GDPR della Commissione Europea sul trattamento dei dati personali.

Quando usare l'API ufficiale di TripAdvisor

TripAdvisor offre un Content API ufficiale per partner commerciali che fornisce accesso strutturato a recensioni e dati location. È la scelta preferibile quando:

• Hai un caso d'uso commerciale legittimo (aggregatore di viaggi, piattaforma di prenotazione).
• Serve affidabilità SLA e supporto tecnico.
• Il volume di dati giustifica il costo della licenza.
• Vuoi evitare completamente il rischio di violazione dei ToS.

L'API ufficiale richiede un'applicazione e l'approvazione di TripAdvisor. Per progetti di ricerca, prototipi o analisi ad hoc, lo scraping di dati pubblici con proxy residenziali rimane un'opzione praticabile, ma valuta sempre il rapporto costo-beneficio rispetto all'API ufficiale.

Per altri use case di scraping e SERP tracking, vedi le nostre pagine su SERP tracking e proxy locations.

Punti chiave

Riepilogo pratico per estrarre recensioni TripAdvisor nel 2026:

• Usa proxy residenziali rotanti con geo-targeting paese/città — i datacenter IP sono bloccati da DataDome.
• Usa curl_cffi con impersonate="chrome" per replicare il fingerprint TLS/HTTP2.
• Intercetta l'endpoint /data/graphql/ids con header X-Requested-By e Origin corretti.
• Mantieni rate di 50–100 richieste/ora per IP con backoff esponenziale e delay randomizzati.
• Usa sessioni sticky (-session-) per coerenza cookie/token durante la paginazione.
• Anonimizza dati personali e rispetta GDPR per recensori UE.
• Valuta l'API Content ufficiale per progetti commerciali a lungo termine.

ProxyHat fornisce proxy residenziali con geo-targeting a livello di paese e città, rotazione automatica e sessioni sticky configurabili via username. Tutti gli esempi sopra usano gate.proxyhat.com:8080 per HTTP o gate.proxyhat.com:1080 per SOCKS5. Inizia oggi dalla pagina prezzi.