Come fare scraping dei prezzi di Google Shopping nel 2026

Se cerchi come fare scraping dei prezzi di Google Shopping nel 2026, la prima cosa da chiarire è il trade-off tra API e HTML. Il Content API for Shopping di Google serve solo i prodotti del merchant autenticato: non ti dà accesso ai prezzi dei concorrenti. Per monitoraggio competitivo, intelligence di prezzo e confronti multi-vendor devi quindi analizzare l'HTML della SERP tbm=shop o le pagine prodotto /shopping/product/. Questa guida mostra come farlo in modo affidabile, con selettori concreti, parametri di localizzazione e proxy residenziali.

Come fare scraping dei prezzi di Google Shopping nel 2026: il quadro tecnico

Google Shopping non è un endpoint REST aperto. È un livello di presentazione costruito sopra il database merchant di Google, con rendering dinamico, localizzazione aggressiva e un anti-bot stack che si è indurito notevolmente tra il 2023 e il 2025. Per un Google Shopping price scraper funzionante devi gestire tre variabili contemporaneamente: il pattern URL corretto, i selettori che sopravvivono ai frequenti A/B test di Google e un pool di IP che non venga classificato come bot.

Il problema esiste perché Google monetizza Shopping tramite annunci sponsorizzati e partnership merchant, quindi ha ogni incentivo a rendere difficile l'estrazione massiva. I segnali di blocco tipici sono: redirect a google.com/sorry/index, sfide reCAPTCHA Enterprise, HTTP 429 ripetuti e SERP che tornano vuote o con layout degradato. Prima di scrivere codice, vale la pena leggere la robots.txt di Google: /search è esplicitamente escluso per crawler generici, il che significa che qualsiasi scraper opera in zona grigia rispetto al ToS.

API ufficiale vs parsing HTML: perché non c'è scelta

Il Content API for Shopping copre inventario, prezzo, disponibilità e feed di un singolo account merchant. È ottima se sei il venditore, inutile se vuoi sapere quanto un competitor fa pagare un ASIN o un GTIN. Non esiste un'API pubblica per i prezzi Shopping cross-merchant. L'unica alternativa legittima sono i partner ufficiali del programma Shopping/SERP, che però costano tipicamente migliaia di euro al mese e impongono clausole d'uso.

Per la maggior parte dei pricing analyst il percorso realistico è quindi: richieste HTTP localizzate verso www.google.com/search?tbm=shop&q=..., parsing del HTML, normalizzazione prezzi in valuta unica, storage in un data warehouse. La sfida non è il parsing in sé — è mantenere un tasso di successo accettabile (idealmente >95%) sotto rate limit aggressivi.

Approccio	Copertura	Costo indicativo	Resistenza ai blocchi
Content API for Shopping	Solo propri prodotti	Gratuito entro quote	N/A (autenticato)
Parsing HTML SERP tbm=shop	Tutti i merchant visibili	Proxy + infrastruttura	Media-bassa senza proxy
Partner SERP/Shopping ufficiali	Secondo contratto	Elevato (migliaia €/mese)	Alta

Stack anti-bot di Google: cosa incontrerai

Google impiega un sistema a più livelli che combina fingerprinting del browser, analisi comportamentale e limiti per IP. I componenti che impattano direttamente uno scraper di Shopping sono:

• reCAPTCHA Enterprise: sfida invisibile che assegna un risk score; score alto → redirect a sorry/index o sfida visibile.
• Sorry redirect: HTTP 200 con body che reindirizza a google.com/sorry/index?continue=.... È un soft-block: troppi richiesti dallo stesso IP in finestre brevi.
• Rate limit per IP: non documentati ufficialmente, ma empiricamente 80–150 richieste per IP in 24h su /search tendono a innescare throttling. Su tbm=shop la soglia può essere ancora più bassa.
• Layout degradato: a volte Google non blocca, ma serve una SERP senza risultati organici o con solo annunci, segnalando che il tuo IP è stato marcato.

Il punto chiave: il blocco raramente è istantaneo. C'è quasi sempre una fase di soft-block in cui i risultati si degradano. Un scraper robusto rileva questa fase e ruota IP prima del hard-block.

Pattern URL e selettori CSS che funzionano nel 2026

La URL base per Shopping è:

https://www.google.com/search?tbm=shop&q={QUERY}&gl={COUNTRY}&hl={LANG}&num=100

Parametri chiave:

• tbm=shop: attiva il vertical Shopping.
• gl: geolocalizzazione paese (es. us, de, it). Influenza seller mostrati e valuta.
• hl: lingua interfaccia (es. en, de).
• num: risultati per pagina (max 100, ma Google spesso ne serve di meno).

Selettori osservati nelle SERP Shopping (soggetti a variazione — testali sempre):

• Container risultato prodotto: .sh-dgr__content, .sh-pr__product-results
• Titolo prodotto: .sh-dgr__content h3 o [role="heading"] dentro il container
• Prezzo: .a8Pemb (storico, ancora comune), talvolta .eYmn5d in varianti A/B
• Merchant/seller: .sh-dgr__merchant, .b5yc4e
• Rating: .sh-dgr__content [aria-label*="star"] o span[role="img"]

Per le pagine dettaglio prodotto, la URL è https://www.google.com/shopping/product/{PRODUCT_ID}. Qui trovi il pannello offerte seller (.sh-os__offer-sellers in molte varianti) con prezzo, spedizione e disponibilità per ogni merchant.

Esempio di blocco risultato (HTML semplificato)

<div class="sh-dgr__content">
  <h3>Sony WH-1000XM5 Wireless Headphones</h3>
  <span class="a8Pemb">$328.00</span>
  <span class="sh-dgr__merchant">Best Buy</span>
  <span role="img" aria-label="Rated 4.6 out of 5">4.6</span>
</div>

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

Il prezzo mostrato su Google Shopping dipende fortemente da paese, lingua e talvolta regione. Un shopper statunitense vede prezzi in USD con seller come Amazon US, Best Buy, Walmart; un shopper tedesco vede EUR e seller come MediaMarkt, Otto, Amazon DE. Un datacenter IP negli Stati Uniti che richiede gl=de viene spesso comunque servito con risultati US o con un layout degradato, perché Google incrocia IP geolocation e parametro gl.

Per un Google Shopping product data pipeline seria servono IP residenziali nel paese target, idealmente con geo a livello città per cogliere differenze regionali (tasse, disponibilità locale, spedizione). Con ProxyHat questo si fa nel username:

# US shopper
http://user-country-US:pass@gate.proxyhat.com:8080

# German shopper, Berlino
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080

# Italiano, Milano
http://user-country-IT-city-milan:pass@gate.proxyhat.com:8080

Combinando geo IP e parametri gl/hl coerenti ottieni la stessa vista di un utente reale in quel mercato. Questo è il cuore del successo: IP + parametri URL devono raccontare la stessa storia geografica.

Esempio Python completo: Google Shopping price scraper con ProxyHat

Ecco un esempio funzionante con requests che usa il gateway ProxyHat, localizza negli Stati Uniti e parsa un blocco risultato troncato. Adattalo al tuo stack (Scrapy, Playwright, httpx).

import requests
from bs4 import BeautifulSoup
import random
import time

PROXY = "http://user-country-US:pass@gate.proxyhat.com:8080"
PROXIES = {"http": PROXY, "https": PROXY}

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/126.0.0.0 Safari/537.36",
    "Accept-Language": "en-US,en;q=0.9",
}

def scrape_shopping(query, country="us", lang="en"):
    url = (
        "https://www.google.com/search"
        f"?tbm=shop&q={requests.utils.quote(query)}"
        f"&gl={country}&hl={lang}&num=60"
    )
    r = requests.get(url, proxies=PROXIES, headers=HEADERS, timeout=20)

    # Rileva soft-block
    if "sorry/index" in r.url or r.status_code == 429:
        raise RuntimeError(f"Soft-block rilevato: {r.url}")

    soup = BeautifulSoup(r.text, "html.parser")
    results = []
    for card in soup.select(".sh-dgr__content"):
        title_el = card.select_one("h3")
        price_el = card.select_one(".a8Pemb")
        seller_el = card.select_one(".sh-dgr__merchant")
        rating_el = card.select_one("[role='img']")
        results.append({
            "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": rating_el.get("aria-label") if rating_el else None,
        })
    return results

if __name__ == "__main__":
    data = scrape_shopping("Sony WH-1000XM5", country="us", lang="en")
    for d in data[:5]:
        print(d)
    time.sleep(random.uniform(3, 7))

Output atteso (troncato):

{'title': 'Sony WH-1000XM5 Wireless Headphones', 'price': '$328.00', 'seller': 'Best Buy', 'rating': 'Rated 4.6 out of 5'}
{'title': 'Sony WH-1000XM5', 'price': '$329.99', 'seller': 'Amazon', 'rating': 'Rated 4.5 out of 5'}

Nota l'uso di random.uniform(3, 7) tra le richieste: jitter umanizza il pattern e riduce la probabilità di soft-block. Per volumi seri, ruota sessioni ProxyHat con user-session-{id} per distribuire il carico su più IP residenziali.

Paginazione, batching e rilevamento soft-block

La paginazione su Shopping non è standard. Non esiste un semplice start=10 come nella SERP web classica: spesso devi cliccare "Show more" o seguire link /shopping/product/ per offerte aggiuntive. Strategie pratiche:

• Batch di query: raggruppa 50–200 keyword per run, ruota sessione ogni 20–30 richieste.
• Delay randomizzato: 3–8 secondi tra richieste, 30–90 secondi tra batch.
• Concorrenza bassa: 5–10 thread per pool IP residenziale. ProxyHat supporta sessioni sticky per mantenere coerenza.
• Rilevamento soft-block: controlla "sorry/index" in r.url, HTTP 429, body con zero .sh-dgr__content, o presenza di id="captcha-form".
• Backoff esponenziale: al primo soft-block, pausa 60–300 secondi e cambia sessione.

Esempio di rotazione sessione:

import uuid

def get_proxy(country="US", city=None):
    session_id = uuid.uuid4().hex[:12]
    user = f"user-country-{country}"
    if city:
        user += f"-city-{city}"
    user += f"-session-{session_id}"
    return f"http://{user}:pass@gate.proxyhat.com:8080"

Etica, ToS e conformità

Lo scraping di prezzi pubblici è una zona grigia. Considerazioni concrete:

• Dati pubblici: prezzi visibili a qualsiasi utente senza login. Non accedere a contenuti dietro autenticazione o paywall.
• robots.txt: /search è disallowed per bot generici. Tecnicamente possibile, ma in tensione con il ToS di Google.
• CFAA: negli Stati Uniti, il Computer Fraud and Abuse Act è stato interpretato in modi che potrebbero riguardare accessi non autorizzati a larga scala, sebbene casi come hiQ Labs v. LinkedIn abbiano parzialmente limitato l'applicabilità.
• GDPR: i prezzi prodotti non sono dati personali, ma se colleghi merchant a persone o raccogli recensioni con dati utente, entra in gioco il Regolamento UE 2016/679.
• Quando usare partner ufficiali: per pipeline enterprise, audit o casi d'uso mission-critical, i partner SERP/Shopping ufficiali rimuovono rischio legale e operativo. Costano di più ma sono la scelta conforme.

Per approfondire setup e best practice, consulta la documentazione ProxyHat. Per i nostri casi d'uso di web scraping e SERP tracking troverai pattern simili applicabili a Shopping.

Key Takeaways

• Il Content API for Shopping copre solo i tuoi prodotti; per prezzi competitor devi parsare HTML tbm=shop.
• Combina IP residenziali con geo città + parametri gl/hl coerenti per ottenere prezzi localizzati reali.
• Rileva soft-block (sorry/index, 429, SERP vuote) prima che diventino CAPTCHA hard.
• Selettori chiave: .sh-dgr__content, .a8Pemb, .sh-dgr__merchant. Testali sempre prima di deploy.
• Per volumi enterprise o conformità rigorosa, valuta partner Shopping ufficiali.

Pronto a costruire il tuo Google Shopping price scraper? Esplora le location ProxyHat e i piani tariffari per scegliere il pool residenziale adatto al tuo mercato target.