Come scrapearre i prezzi di Google Shopping nel 2026

Se devi raccogliere dati competitivi sui prezzi dei prodotti, scrapearre i prezzi di Google Shopping nel 2026 richiede più di una semplice richiesta HTTP. Google ha rafforzato il suo stack anti-bot, i selettori CSS cambiano frequentemente e i prezzi variano in base alla geolocalizzazione dell'IP. In questa guida affrontiamo ogni aspetto pratico: dai pattern URL ai selettori, dalla scelta dei proxy al codice Python pronto da eseguire.

API vs HTML: perché il Content API non basta per lo scraping di Google Shopping

Il primo dilemma è sempre lo stesso: usare un'API ufficiale o parsare l'HTML? Per Google Shopping la risposta è netta. Il Content API for Shopping di Google serve solo ai merchant per gestire i propri prodotti — non espone i prezzi dei concorrenti. Se sei un pricing analyst o un ingegnere di competitive intelligence, l'API non ti dà accesso ai dati che ti servono.

L'unica via per ottenere dati competitivi è parsare la SERP HTML di Google Shopping (tbm=shop) e le pagine di dettaglio prodotto (/shopping/product/). Questo significa gestire anti-bot, rotazione IP e selettori che cambiano. È un lavoro engineering reale, ma è l'unico modo per ottenere prezzi cross-vendor a scala.

Lo stack anti-bot di Google: cosa ti bloccherà

Google protegge le sue SERP con un sistema multi-strato che include:

• reCAPTCHA Enterprise — integrato nelle SERP, analizza comportamento, fingerprint del browser e pattern di traffico. Secondo la documentazione ufficiale, il punteggio di rischio va da 0.0 a 1.0 e viene combinato con segnali lato server.
• Redirect sorry/index — quando Google rileva traffico sospetto da un IP, redirige la richiesta a https://www.google.com/sorry/index?continue=... invece di servire la SERP. Questo è il primo segnale di soft-block.
• Rate limits per-IP aggressivi — non esiste una documentazione pubblica, ma test empirici mostrano che un singolo IP datacenter viene bloccato dopo circa 20-50 richieste in rapida successione. Gli IP residenziali tollerano leggermente di più, ma non molto.
• Browser fingerprinting — Google analizza header HTTP, TLS fingerprint (JA3), e comportamento JavaScript. Le richieste con librerie come requests o curl hanno fingerprint distinti rispetto ai browser reali.

La conseguenza pratica: senza rotazione IP e proxy residenziali, il tuo scraper si ferma entro pochi minuti. Anche con proxy, devi gestire delay, header realistici e rilevamento dei soft-block.

Pattern URL e selettori CSS per Google Shopping

URL della SERP di Shopping

L'endpoint base per i risultati di shopping è:

https://www.google.com/search?tbm=shop&q=QUERY&gl=US&hl=en

I parametri chiave:

• tbm=shop — attiva la vertical search di Shopping.
• q= — la query di ricerca (URL-encoded).
• gl= — geolocalizzazione del paese (es. US, DE, JP).
• hl= — lingua dell'interfaccia (es. en, de, ja).
• num= — numero di risultati per pagina (max ~60, default 10).
• start= — offset per paginazione (0, 10, 20, ...).

Selettori CSS principali (verificati a gennaio 2026)

I selettori di Google Shopping cambiano frequentemente. Quelli sotto sono stati verificati di recente, ma è buona pratica verificarli con un test rapido prima di andare in produzione:

Pagina di dettaglio prodotto

La pagina di dettaglio segue il pattern:

https://www.google.com/shopping/product/PRODUCT_ID?gl=US&hl=en

Qui trovi il pannello delle offerte dei venditori (seller-offer panels), che mostra tutti i merchant che vendono lo stesso prodotto con i rispettivi prezzi, spese di spedizione e disponibilità. I selettori tipici:

• .deIvCe — riga singola offerta venditore.
• .trsj2d — prezzo del venditore.
• .dULFsb — nome venditore.
• .bVfO8d — spese di spedizione.

Nota importante: i selettori CSS di Google sono instabili. Usa matchers fuzzy (es. regex sul testo del prezzo) come fallback e monitora il tasso di parsing fallito. Se supera il 10%, è ora di aggiornare i selettori.

Perché i prezzi localizzati richiedono proxy residenziali con geo a livello di città

Questo è il punto più critico e spesso frainteso. Un acquirente negli Stati Uniti e uno in Germania che cercano lo stesso prodotto su Google Shopping vedono venditori diversi, prezzi diversi e valute diverse. Il parametro gl=DE aiuta, ma Google cross-referenzia anche l'IP geolocalizzato per determinare cosa mostrare.

Se il tuo IP è un datacenter in Francia ma richiedi gl=DE, Google può comunque servire risultati filtrati o mostrare un avviso di localizzazione incongruente. Con proxy residenziali tedeschi, l'IP corrisponde a un ISP reale in Germania, e i risultati sono coerenti con quelli che vede un vero acquirente locale.

Ecco perché il geo-targeting a livello di città di ProxyHat è essenziale:

• -country-US — IP residenziale negli Stati Uniti, prezzi in USD.
• -country-DE-city-berlin — IP residenziale a Berlino, prezzi in EUR, venditori DACH.
• -country-JP-city-tokyo — IP residenziale a Tokyo, prezzi in JPY, venditori giapponesi.

Per monitoring competitivo su più mercati, devi rotare tra questi geo-target con sessioni sticky per mantenere coerenza nei risultati di una singola sessione di scraping.

Esempio Python: scrapearre Google Shopping con ProxyHat

Ecco un esempio completo che usa requests con BeautifulSoup per parsare un blocco di risultati dalla SERP di Google Shopping, passando attraverso il gateway ProxyHat con geo-targeting USA.

import requests
from bs4 import BeautifulSoup
import random
import time
import re

# ProxyHat gateway con geo-targeting USA e sessione sticky
PROXY_URL = "http://user-country-US-session-shop01:pass@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/120.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "DNT": "1",
}

def scrape_google_shopping(query, gl="US", hl="en", num=20, start=0):
    url = "https://www.google.com/search"
    params = {
        "tbm": "shop",
        "q": query,
        "gl": gl,
        "hl": hl,
        "num": num,
        "start": start,
    }

    try:
        resp = requests.get(
            url, params=params, headers=HEADERS,
            proxies=PROXIES, timeout=30
        )
    except requests.exceptions.RequestException as e:
        print(f"Errore richiesta: {e}")
        return []

    # Rilevamento soft-block
    if "sorry/index" in resp.url:
        print(f"Soft-block rilevato! URL: {resp.url}")
        return []

    if resp.status_code == 429:
        print("Rate limit (429). Pausa necessaria.")
        return []

    soup = BeautifulSoup(resp.text, "html.parser")
    results = []

    # Selettore principale container risultati
    product_cards = soup.select(".sh-dgr__content")

    for card in product_cards[:5]:  # Tronca a 5 per esempio
        title_el = card.select_one("h3.sh-dgr__grid-title") or card.select_one(".tAxDx")
        price_el = card.select_one(".a8Pemb")
        seller_el = card.select_one(".aULzUe") or card.select_one(".IuHbeo")
        rating_el = card.select_one(".SHzH4e")

        title = title_el.get_text(strip=True) if title_el else None
        price = price_el.get_text(strip=True) if price_el else None
        seller = seller_el.get_text(strip=True) if seller_el else None
        rating = None
        if rating_el:
            aria = rating_el.get("aria-label", "")
            match = re.search(r"([\d.]+)", aria)
            rating = float(match.group(1)) if match else None

        results.append({
            "title": title,
            "price": price,
            "seller": seller,
            "rating": rating,
        })

    return results

# Esecuzione
if __name__ == "__main__":
    data = scrape_google_shopping("wireless headphones", gl="US", hl="en")
    for item in data:
        print(item)
    # Delay randomizzato prima della prossima query
    time.sleep(random.uniform(3, 8))

Output di esempio (troncato):

{
  'title': 'Sony WH-1000XM5 Wireless Noise Canceling Headphones',
  'price': '$328.00',
  'seller': 'Amazon.com',
  'rating': 4.6
}
{
  'title': 'Bose QuietComfort Ultra Headphones',
  'price': '$379.00',
  'seller': 'Best Buy',
  'rating': 4.5
}

Versione curl per test rapido

curl -x http://user-country-US-session-test01:pass@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
  -H "Accept-Language: en-US,en;q=0.9" \
  "https://www.google.com/search?tbm=shop&q=wireless+headphones&gl=US&hl=en&num=20"

Versione Node.js con axios

const axios = require('axios');
const cheerio = require('cheerio');

const PROXY_URL = 'http://user-country-DE-city-berlin-session-de01:pass@gate.proxyhat.com:8080';

async function scrapeShopping(query, gl = 'DE', hl = 'de') {
  const url = `https://www.google.com/search?tbm=shop&q=${encodeURIComponent(query)}&gl=${gl}&hl=${hl}`;
  try {
    const resp = await axios.get(url, {
      proxy: { host: 'gate.proxyhat.com', port: 8080,
               auth: { username: 'user-country-DE-city-berlin-session-de01', password: 'pass' } },
      headers: {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
        'Accept-Language': 'de-DE,de;q=0.9',
      },
      timeout: 30000,
    });

    if (resp.data.includes('sorry/index')) {
      console.log('Soft-block rilevato');
      return [];
    }

    const $ = cheerio.load(resp.data);
    const results = [];
    $('.sh-dgr__content').slice(0, 5).each((_, el) => {
      results.push({
        title: $(el).find('h3.sh-dgr__grid-title').text().trim(),
        price: $(el).find('.a8Pemb').text().trim(),
        seller: $(el).find('.aULzUe').text().trim(),
      });
    });
    return results;
  } catch (e) {
    console.error('Errore:', e.message);
    return [];
  }
}

scrapeShopping('kabellose kopfhörer').then(console.log);

Paginazione, batch di query e rilevamento soft-block

Paginazione

Google Shopping supporta paginazione via parametro start. Incremente di 10 o 20 sono standard. Tuttavia, oltre la pagina 5-6 (start=50-60), i risultati diventano meno rilevanti e Google può servire risultati ripetuti o vuoti. Per la maggior parte dei casi di price monitoring, le prime 2-3 pagine coprono i prodotti principali.

def scrape_all_pages(query, max_pages=3, gl="US", hl="en"):
    all_results = []
    for page in range(max_pages):
        start = page * 20
        results = scrape_google_shopping(query, gl=gl, hl=hl, num=20, start=start)
        if not results:
            print(f"Nessun risultato a pagina {page+1}. Stop.")
            break
        all_results.extend(results)
        time.sleep(random.uniform(4, 9))  # Delay randomizzato tra pagine
    return all_results

Batch di query

Per monitorare centinaia di prodotti, organizza le query in batch e distribuile su più sessioni proxy. Ogni sessione sticky dovrebbe gestire al massimo 15-20 richieste prima di ruotare. Esempio di strategia:

• Batch di 50 query → dividi in 3-4 sessioni proxy diverse.
• Delay randomizzato tra 3-8 secondi tra richieste nella stessa sessione.
• Pausa di 60-120 secondi tra batch.
• Rotazione User-Agent ad ogni sessione (non ad ogni richiesta, sarebbe sospetto).

Rilevamento soft-block prima del CAPTCHA hard

Il soft-block si manifesta in tre modi principali. Rilevarli precocemente evita di sprecare richieste e di aggravare il blocco:

1. Redirect a /sorry/index — il segnale più chiaro. Controlla resp.url dopo ogni richiesta.
2. Risultati vuoti o ridotti — se una query che normalmente restituisce 20 risultati ne restituisce 0-2, è probabile un soft-block silenzioso.
3. Status code 429 — rate limit esplicito. Pausa immediata di 60+ secondi.

def detect_soft_block(resp, expected_min_results=5):
    """Rileva soft-block prima che diventi CAPTCHA hard."""
    if "sorry/index" in resp.url:
        return "sorry_redirect"
    if resp.status_code == 429:
        return "rate_limited"
    # Conta risultati: se troppo pochi, possibile soft-block
    soup = BeautifulSoup(resp.text, "html.parser")
    cards = soup.select(".sh-dgr__content")
    if len(cards) < expected_min_results:
        return "empty_results"
    return None

Quando rilevi un soft-block, la strategia migliore è non insistere con lo stesso IP. Ruota sessione proxy, aumenta il delay e riprova. Se il soft-block persiste, pausa quel geo-target per 30-60 minuti.

Configurazione ProxyHat e setup completo

Per configurare il tuo scraper con ProxyHat, usa il gateway gate.proxyhat.com sulla porta 8080 (HTTP) o 1080 (SOCKS5). Le opzioni di geo-targeting e sessione vanno nel username:

Per il SOCKS5, cambia la porta a 1080:

socks5://user-country-US-session-shop01:pass@gate.proxyhat.com:1080

Puoi consultare la documentazione ProxyHat per dettagli su parametri avanzati. Per i prezzi e i piani disponibili, visita la pagina prezzi di ProxyHat. Per verificare le location disponibili per il geo-targeting, consulta la pagina delle locazioni proxy.

Se sei interessato ad altri casi d'uso oltre a Google Shopping, dai un'occhiata alle guide su web scraping e SERP tracking.

Considerazioni etiche e legali

Lo scraping di dati pubblici di prezzo è un'area grigia legale. Alcuni punti chiave:

• Dati pubblici solo — raccogli solo informazioni visibili pubblicamente senza autenticazione. Non tentare di accedere a dati dietro login o paywall.
• robots.txt — rispetta le direttive di robots.txt di Google. Tecnicamente, tbm=shop non è escluso, ma è buona pratica verificare periodicamente.
• CFAA — negli Stati Uniti, il Computer Fraud and Abuse Act è stato interpretato (post-hiQ vs LinkedIn) in modo più favorevole allo scraping di dati pubblici, ma le interpretazioni variano per giurisdizione.
• GDPR — i dati di prezzo non sono dati personali, ma se raccogli recensioni che includono nomi utenti, entra in gioco il GDPR. Evita di memorizzare dati personali.
• Termini di servizio di Google — i ToS di Google proibiscono l'accesso automatizzato alle SERP. Questo è un rischio legale reale, specialmente per uso commerciale su larga scala.
• Route compliance — per uso enterprise su larga scala, i partner ufficiali Google Shopping/SERP offrono API conformi. Sono costose ma eliminano il rischio legale.

La nostra raccomandazione: usa lo scraping per ricerca e analisi interna, rispetta i rate limit, non ripubblicare i dati come servizio pubblico e consulta un legale se operi su scala commerciale.

Errori comuni e edge cases

1. Selettori non aggiornati

Google cambia i class CSS ogni poche settimane. Implementa un sistema di alerting che ti notifica quando il tasso di parsing fallito supera il 10%. Usa selettori multipli di fallback e regex sul testo come safety net.

2. Geo-targeting incongruente

Se usi gl=DE ma il tuo IP è USA, Google può mostrare risultati ibridi. Allinea sempre il parametro gl con il geo-targeting del proxy: gl=DE con -country-DE, gl=US con -country-US.

3. Delay troppo brevi

Delay inferiori a 2 secondi tra richieste sono un segnale chiaro di bot. Usa random.uniform(3, 8) come minimo. Per query ripetute sullo stesso prodotto, aumenta a 10-15 secondi.

4. Concorrenza troppo alta per IP

Anche con proxy residenziali, più di 5-10 richieste concorrenti dalla stessa sessione sono sospette. Limita la concorrenza a 3-5 per sessione e usa sessioni multiple per parallelismo.

5. Ignorare i prezzi con spedizione

Il prezzo mostrato in .a8Pemb può non includere le spese di spedizione. Per un confronto reale, visita la pagina /shopping/product/ e estrai prezzo + spedizione dal pannello offerte.

Key Takeaways

• Il Content API for Shopping di Google mostra solo i prodotti del merchant: per dati competitivi devi parsare l'HTML di tbm=shop e /shopping/product/.
• I selettori principali sono .sh-dgr__content per i container, .a8Pemb per i prezzi, .aULzUe per i venditori — ma cambiano frequentemente.
• I prezzi localizzati richiedono proxy residenziali con geo a livello di città (-country-DE-city-berlin) allineati ai parametri gl e hl.
• Il gateway ProxyHat (gate.proxyhat.com:8080) supporta geo-targeting e sessioni sticky direttamente nel username.
• Rileva i soft-block (redirect /sorry/, risultati vuoti, 429) prima che diventino CAPTCHA hard.
• Delay randomizzati di 3-8 secondi, max 15-20 richieste per sessione, rotazione User-Agent per sessione.
• Rispetta robots.txt, ToS di Google e consulta un legale per uso commerciale su larga scala.

FAQ

Cos'è lo scraping dei prezzi di Google Shopping nel 2026?

È l'estrazione automatizzata di dati di prezzo, venditore, recensioni e disponibilità dai risultati di Google Shopping (tbm=shop) e dalle pagine prodotto /shopping/product/. A differenza del Content API for Shopping, che mostra solo i prodotti del merchant stesso, lo scraping HTML permette di raccogliere dati competitivi pubblici da più venditori e mercati geografici.

Perché lo scraping di Google Shopping è importante per gli utenti proxy?

Google applica limiti di rate per-IP aggressivi, redirect sorry/index e reCAPTCHA. Per raccogliere dati da più mercati (USA, Germania, Giappone) con prezzi e valute localizzate, servono proxy residenziali con geo-targeting a livello di città e rotazione IP. Senza proxy, un singolo IP viene bloccato dopo poche decine di richieste.

Quale tipo di proxy funziona meglio per lo scraping di Google Shopping?

I proxy residenziali sono la scelta migliore perché usano IP ISP reali, difficili da distinguere dal traffico organico. Il geo-targeting a livello di paese e città è essenziale per ottenere prezzi localizzati. I proxy datacenter sono più economici ma vengono rilevati e bloccati rapidamente dai sistemi anti-bot di Google.

Come si evitano i blocchi nello scraping di Google Shopping?

Usa proxy residenziali rotanti con sessioni sticky, imposta parametri gl/hl per localizzare le richieste, randomizza i delay tra 3-8 secondi, ruota gli User-Agent, monitora i redirect a /sorry/ come segnale di soft-block e riduci la concorrenza per IP a 3-5 richieste. Se appare un CAPTCHA, pausa l'IP per 30-60 minuti prima di riprovare con una nuova sessione.