Google Shopping Preise scrapen 2026: API vs. HTML und warum beides existiert
Wer 2026 Google Shopping Preise scrapen will, steht vor einer grundlegenden Entscheidung: API oder HTML? Die Content API for Shopping von Google liefert ausschließlich die Produkte des eigenen Merchant-Kontos. Wer Google Shopping Produktdaten von Wettbewerbern benötigt, kommt an der SERP-HTML nicht vorbei. Das bedeutet: Sie parsen die tbm=shop-Ergebnisseite oder die /shopping/product/-Detailseiten und extrahieren Titel, Preis, Verkäufer und Bewertung.
Dieser Leitfaden richtet sich an Pricing-Analysten und Competitive-Intelligence-Engineers. Wir behandeln Googles Anti-Bot-Stack, konkrete CSS-Selektoren, Geo-Targeting für lokalisierte Preise, ein funktionierendes Python-Beispiel über ProxyHat Residential Proxys sowie Ethik und Compliance.
Warum dieses Problem existiert: Googles Anti-Bot-Stack
Google betreibt eines der aggressivsten Anti-Scraping-Systeme weltweit. Drei Mechanismen sind besonders relevant:
- reCAPTCHA Enterprise — wird ausgelöst, wenn Verhaltenssignale (Mausbewegung, Scroll-Tiefe, Request-Frequenz) vom Durchschnitt abweichen. Bei Shopping-SERPs kommt Googlebot nicht zum Einsatz; die Seite ist für menschliche Nutzer optimiert.
- Sorry/Index-Redirect — bei verdächtigen IPs leitet Google auf
google.com/sorry/indexweiter. Das ist ein Soft-Block: noch keine CAPTCHA, aber die eigentliche SERP wird nicht mehr ausgeliefert. - Per-IP-Rate-Limits — erfahrungsbasiert liegt die Schwelle für Shopping-SERPs bei etwa 80–120 Requests pro IP und Stunde aus einem Datacenter-IP-Range. Danach folgt der Sorry-Redirect.
Datacenter-IPs werden schneller geblockt, weil Google ganze ASN-Ranges von Cloud-Providern (AWS, GCP, Azure) als nicht-menschlich einstuft. Residential Proxys mit realen ISP-IPs sind daher kein Luxus, sondern eine technische Notwendigkeit.
URL-Patterns und Selektoren für Google Shopping
Die SERP-URL
Die Basis-URL für Shopping-SERPs lautet:
https://www.google.com/search?tbm=shop&q=QUERY&gl=US&hl=enDer Parameter tbm=shop aktiviert den Shopping-Tab. gl steuert das Land, hl die Sprache. Für Deutschland:
https://www.google.com/search?tbm=shop&q=QUERY&gl=DE&hl=deProdukt-Container und Preis-Nodes
Google ändert seine CSS-Klassen regelmäßig, aber folgende Selektoren waren 2024–2026 stabil:
| Element | CSS-Selektor | XPath-Alternative |
|---|---|---|
| Produkt-Grid-Container | .sh-pr__product-results | //div[contains(@class,'sh-pr__product-results')] |
| Einzelnes Produkt-Item | .sh-dgr__content | //div[contains(@class,'sh-dgr__content')] |
| Preis | .a8Pemb | //span[contains(@class,'a8Pemb')] |
| Titel | .sh-dgr__grid-title oder h3 | .//h3 |
| Verkäufer | .a8Pemb-OEVnAc (variiert) | .//div[contains(@class,'a8Pemb')]/following-sibling::div |
| Bewertung | .Rsc7Yb oder [aria-label*='von 5'] | .//span[contains(@aria-label,'von 5')] |
Detailseiten und Seller-Offer-Panels
Jedes Produkt hat eine Detailseite unter /shopping/product/PRODUCT_ID. Dort finden Sie das Seller-Offer-Panel mit allen Händlerangeboten:
https://www.google.com/shopping/product/12345678901234567890?gl=DE&hl=deDie Offer-Liste nutzt typischerweise .sh-np__offer-grid für die Container und .O2U5Ue für den einzelnen Preis je Händler.
Lokalisierte Preise: Warum City-Level-Geo entscheidend ist
Ein US-Shopper und ein deutscher Shopper sehen unterschiedliche Verkäufer, Währungen und Preise für dasselbe Produkt. Das liegt an:
gl- undhl-Parametern in der URL (Länder- und Sprachcode).- Der Geo-Position der anfragenden IP (Google nutzt IP-Geolocation als Fallback).
- Händler-Verfügbarkeit pro Region.
Wenn Sie Google Shopping Produktdaten für den deutschen Markt scrapen, reicht es nicht, gl=DE zu setzen und einen US-Datacenter-Proxy zu verwenden. Google erkennt den Konflikt und liefert entweder US-Preise oder einen Soft-Block. Sie benötigen Residential Proxys mit Stadt-Level-Geo-Targeting:
# US-Shopper (Dallas, TX)http://user-country-US:pass@gate.proxyhat.com:8080# Deutscher Shopper (Berlin)http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080Mit ProxyHat Geo-Targeting steuern Sie Land und Stadt pro Request. Das bedeutet: Sie können denselben Query einmal über eine Berliner IP und einmal über eine Münchner IP senden und regionale Preisunterschiede erfassen.
Python-Beispiel: Google Shopping SERP über ProxyHat scrapen
Hier ist ein funktionierendes Beispiel mit requests und BeautifulSoup, das einen Query über einen deutschen Residential Proxy sendet und ein Ergebnisblock parst.
import requestsfrom bs4 import BeautifulSoupimport timeimport random# ProxyHat Residential Proxy — Deutschland, BerlinPROXY = "http://user-country-DE-city-berlin: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/131.0.0.0 Safari/537.36", "Accept-Language": "de-DE,de;q=0.9,en;q=0.8",}def scrape_google_shopping(query, gl="DE", hl="de"): url = f"https://www.google.com/search?tbm=shop&q={query}&gl={gl}&hl={hl}" try: resp = requests.get(url, headers=HEADERS, proxies=PROXIES, timeout=15) except requests.exceptions.RequestException as e: print(f"Request failed: {e}") return [] if "/sorry/index" in resp.url: print("SOFT BLOCK detected — rotating IP recommended") return [] soup = BeautifulSoup(resp.text, "html.parser") results = [] items = soup.select(".sh-dgr__content") for item in items[:5]: # truncate for demo title_el = item.select_one("h3") price_el = item.select_one(".a8Pemb") rating_el = item.select_one("[aria-label*='von 5']") title = title_el.get_text(strip=True) if title_el else "N/A" price = price_el.get_text(strip=True) if price_el else "N/A" rating = rating_el.get("aria-label", "N/A") if rating_el else "N/A" results.append({"title": title, "price": price, "rating": rating}) return resultsif __name__ == "__main__": data = scrape_google_shopping("sony wh-1000xm5") for d in data: print(f"{d['title']} | {d['price']} | {d['rating']}") time.sleep(random.uniform(3, 7))Beispielausgabe (gekürzt):
{ "title": "Sony WH-1000XM5 Wireless Noise Canceling Headphones", "price": "299,00 €", "rating": "4,6 von 5"}Beachten Sie: Die Preiswährung (€ statt $) ergibt sich aus der Kombination von gl=DE und der Berliner Residential IP. Mit einem US-Proxy und gl=US würden Sie $348.00 sehen.
Pagination, Query-Batching und Soft-Block-Erkennung
Pagination
Google Shopping SERPs paginieren über den start-Parameter:
https://www.google.com/search?tbm=shop&q=QUERY&gl=DE&hl=de&start=20https://www.google.com/search?tbm=shop&q=QUERY&gl=DE&hl=de&start=40Pro Seite erscheinen etwa 20–40 Produkte. Tiefer als Seite 5–6 (start=100) ist selten sinnvoll — dort dominieren weniger relevante Ergebnisse.
Query-Batching
Wenn Sie 1000+ Produkt-Queries verarbeiten, bündeln Sie diese in Batches von 50 und rotieren die IP pro Batch:
import itertoolsqueries = ["iphone 15", "galaxy s24", "pixel 8", ...] # 1000+ queriesbatch_size = 50for batch in itertools.batched(queries, batch_size): for q in batch: results = scrape_google_shopping(q) # ... save results time.sleep(random.uniform(4, 9)) # rotate to a new IP after each batch # ProxyHat rotates automatically per request unless sticky sessionRandomisierte Delays
Konstante Intervalle sind ein Verhaltenssignal. Verwenden Sie random.uniform(3, 8) zwischen Requests und random.uniform(10, 20) zwischen Batches. Bei 1000 Queries mit 5 Sekunden Durchschnittsverzögerung benötigen Sie etwa 83 Minuten — realistisch und unauffällig.
Soft-Block-Erkennung
Erkennen Sie Soft-Blocks bevor eine harte CAPTCHA kommt:
- Prüfen Sie
resp.urlauf/sorry/index. - Prüfen Sie auf das Vorhandensein von
recaptchaim HTML. - Überwachen Sie die Response-Größe: ein Sorry-Redirect liefert ~2 KB, eine echte SERP 200–500 KB.
- Zählen Sie extrahierte Produkte: 0 Produkte trotz gültigem Query = möglicher Soft-Block.
Bei einem Soft-Block: Pause von 10–15 Minuten, IP-Rotation, dann Retry. Nie sofort erneut anfragen — das eskaliert zum Hard-Block.
SOCKS5-Alternative für höhere Zuverlässigkeit
Wenn HTTP-Proxys instabil wirken, bietet SOCKS5 eine robustere Verbindung:
SOCKS5_PROXY = "socks5://user-country-DE-city-berlin:pass@gate.proxyhat.com:1080"SOCKS5 tunneln den gesamten TCP-Verkehr und sind weniger anfällig für Header-Injection. In Python benötigen Sie pip install requests[socks].
Ethik, TOS und rechtliche Rahmenbedingungen
Das Scrapen öffentlicher Preisdaten ist rechtlich nicht unproblematisch. Wichtige Punkte:
- Googles Nutzungsbedingungen verbieten automatisiertes Scraping ausdrücklich. Ein Verstoß kann zum IP-Ban oder rechtlichen Schritten führen.
- CFAA (USA) — das Computer Fraud and Abuse Act kann bei Umgehung technischer Zugriffssperren (z. B. CAPTCHAs) relevant sein. Der Fall hiQ Labs v. LinkedIn hat Präzedenz geschaffen, aber die Rechtslage bleibt unsicher.
- GDPR (EU) — Produktdaten enthalten in der Regel keine personenbezogenen Daten, aber Verkäuferprofile können Namen enthalten. Vermeiden Sie die Speicherung personenbezogener Daten.
- robots.txt — Google erlaubt
/searchnicht für Crawler. Dies ist ein starkes Signal, dass automatisiertes Scraping nicht gewünscht ist.
Für produktive Competitive-Intelligence-Systeme ist oft der offizielle Weg über Googles Shopping API oder lizenzierte SERP-Partner (z. B. SerpApi, Bright Data SERP API) die compliant Alternative. Diese Anbieter haben vertragliche Vereinbarungen mit Google.
Praktische Empfehlung: Nutzen Sie Residential Proxys für Ad-hoc-Analysen und kleine Datensätze. Für kontinuierliche, hochvolumige Preisüberwachung ziehen Sie offizielle APIs oder lizenzierte SERP-Dienste in Betracht.
ProxyHat-spezifisches Setup
Für SERP-Tracking und Shopping-Scraping empfiehlt sich folgende Konfiguration:
| Parameter | Empfehlung |
|---|---|
| Proxy-Typ | Residential (rotating) |
| Gateway | gate.proxyhat.com:8080 (HTTP) oder :1080 (SOCKS5) |
| Geo-Targeting | user-country-DE-city-berlin für deutsche Preise |
| Session-Modus | Rotierend pro Request (Default) |
| Sticky Session | user-session-abc123 für Pagination (gleiche IP für 10–30 Min.) |
| Concurrency | Max. 10–20 parallele Requests |
Preise und Pakete finden Sie auf der ProxyHat Pricing-Seite. Die ProxyHat-Dokumentation enthält weitere Code-Beispiele für Node.js, curl und Scrapy.
Key Takeaways
- Die Content API for Shopping liefert nur eigene Produkte — für Wettbewerbsdaten bleibt nur HTML-Scraping der
tbm=shop-SERP. - Googles Anti-Bot-Stack (reCAPTCHA, Sorry-Redirect, Per-IP-Rate-Limits) erfordert Residential Proxys mit City-Level-Geo-Targeting.
- Stabile Selektoren:
.sh-dgr__contentfür Items,.a8Pembfür Preise,/shopping/product/IDfür Detailseiten. - Lokalisierte Preise brauchen
gl/hl-Parameter plus eine IP im Zielmarkt —user-country-DE-city-berlinübergate.proxyhat.com:8080. - Soft-Blocks früh erkennen (URL-Check, Response-Größe), randomisierte Delays (3–8 Sek.) und IP-Rotation pro Batch.
- Für Compliance: offizielle APIs oder lizenzierte SERP-Partner für hochvolumige Produktionssysteme nutzen.
FAQ
Was bedeutet Google Shopping Preise scrapen 2026?
Es bezeichnet das automatisierte Extrahieren von Preis-, Verkäufer- und Produktdaten aus den Google Shopping SERPs (tbm=shop) oder den /shopping/product/ Detailseiten. Da die Content API for Shopping nur eigene Merchant-Produkte liefert, ist HTML-Scraping der einzige Weg an Wettbewerbsdaten. 2026 ist dies technisch anspruchsvoller geworden wegen verbesserter reCAPTCHA-Erkennung und strengeren Per-IP-Rate-Limits.
Warum ist das für Proxy-Nutzer relevant?
Google blockt Datacenter-IPs nach 80–120 Requests pro Stunde. Ohne Residential Proxys mit echten ISP-IPs ist kontinuierliches Scraping unmöglich. Proxy-Nutzer profitieren von Geo-Targeting (Land/Stadt), IP-Rotation und Sticky Sessions für Pagination — alles Funktionen, die ein Google Shopping Preis Scraper benötigt, um lokalisierte Preise zuverlässig zu erfassen.
Welcher Proxy-Typ eignet sich am besten?
Residential Proxys sind die beste Wahl für Google Shopping. Sie nutzen echte ISP-IPs und werden daher seltener geblockt als Datacenter-IPs. Mobile Proxys funktionieren ebenfalls, sind aber teurer und langsamer. Datacenter-Proxys sind für Google-SERPs praktisch unbrauchbar. Für Pagination verwenden Sie Sticky Sessions (10–30 Minuten gleiche IP), für breite Queries rotierende IPs pro Request.
Wie vermeidet man Blocks beim Scraping?
Zunächst: randomisierte Delays von 3–8 Sekunden zwischen Requests. Zweitens: IP-Rotation pro Batch (50 Queries). Drittens: Soft-Block-Erkennung durch URL-Check auf /sorry/index und Response-Größen-Monitoring (~2 KB = Block, ~200 KB = echte SERP). Viertens: realistische Browser-Header und Accept-Language passend zum Geo-Target. Bei einem Soft-Block 10–15 Minuten Pause einlegen, nie sofort retryen.
