Jak scrapować ceny Google Shopping w 2026: Praktyczne podejście
Scrapowanie cen Google Shopping w 2026 roku to zadanie, które wymaga precyzji technicznej i odpowiedniej infrastruktury proxy. Jeśli próbujesz budować system do monitorowania cen konkurencji, wiesz już, że Google Shopping to jedno z najcenniejszych źródeł danych e-commerce — ale też jedno z najtrudniejszych do scrapowania. Google stosuje wielowarstwowy system anti-bot, a ceny są zlokalizowane geograficznie, co oznacza, że bez residential proxy z geo-targetowaniem otrzymasz niepełne lub mylące dane.
Zanim przejdziemy do implementacji, musisz zrozumieć kluczowy kompromis: API vs HTML. Content API for Shopping Google udostępnia dane produktowe, ale tylko dla własnych produktów merchanta — nie pozwala na pobieranie danych konkurencji. Jeśli Twoim celem jest competitive intelligence, musisz parsować HTML stron wyników SERP z parametrem tbm=shop lub strony produktowe pod /shopping/product/. To wymaga proxy, które omija anti-boty Google.
Dlaczego ten problem istnieje: kontekst techniczny
Google Shopping nie jest zwykłą stroną e-commerce. To agregator, który łączy dane od tysięcy sprzedawców i prezentuje je w zlokalizowanym formacie. Stąd dwa fundamentalne wyzwania:
1. Stack anti-bot Google
Google chroni swoje SERPy wieloma warstwami zabezpieczeń, o których szczegółowo pisze dokumentacja Google Search Central:
- reCAPTCHA Enterprise — wywoływana po wykryciu nietypowego wzorca żądań (zbyt szybkie, zbyt powtarzalne, z podejrzanymi nagłówkami).
- Przekierowanie
/sorry/index— Google przekierowuje podejrzane żądania na stronę CAPTCHA zamiast zwracać wyniki. To tzw. soft-block — ostatnie ostrzeżenie przed twardym banem. - Agresywne limity per-IP — Google nakłada limity na liczbę żądań z pojedynczego adresu IP, często już po 20-50 żądaniach w krótkim czasie. Wynikiem jest HTTP 429 lub przekierowanie na CAPTCHA.
- Fingerprinting przeglądarki — Google analizuje nagłówki, TLS fingerprint, zachowanie JavaScript i timing żądań, aby odróżnić boty od ludzi.
2. Lokalizacja cen
Użytkownik w USA i użytkownik w Niemczech widzą różnych sprzedawców, różne ceny i różne waluty na tej samej stronie produktu Google Shopping. To oznacza, że adres IP Twojego scrapera bezpośrednio wpływa na to, jakie dane otrzymujesz. Proxy datacenter z IP w jednej lokalizacji nie wystarczy — potrzebujesz residential proxy z geo-targetowaniem na poziomie miasta, aby wiarygodnie monitorować ceny na konkretnych rynkach.
Wzorce URL i selektory CSS dla Google Shopping
Zanim napiszesz linię kodu, musisz znać dokładne wzorce URL i selektory, które Google używa w swoich stronach Shopping. Struktura HTML Google zmienia się często, ale poniższe selektory są stabilne od 2024 roku.
Wzorzec URL SERP Shopping
https://www.google.com/search?tbm=shop&q={zapytanie}&gl={kraj}&hl={jezyk}
Parametry kluczowe:
tbm=shop— przełącza na zakładkę Shoppinggl— kod kraju (np.us,de,pl) — musi być dopasowany do lokalizacji proxyhl— język interfejsu (np.en,de,pl)num=100— zwiększa liczbę wyników na stronę (domyślnie ~20-30)
Wzorzec URL strony produktu
https://www.google.com/shopping/product/{product_id}
Strona produktu zawiera panel ofert sprzedawców (seller-offer panel), gdzie znajdziesz porównanie cen od różnych merchantów.
Kluczowe selektory CSS
| Element | Selektor CSS | Typ danych |
|---|---|---|
| Kontener wyników | .sh-dgr__content |
Blok produktu na SERP |
| Lista produktów | .sh-pr__product-results |
Siatka wyników |
| Cena | .a8Pemb |
Tekst ceny (np. "$299.00") |
| Tytuł produktu | .sh-dgr__product-title lub h3.tDsQ9 |
Nazwa produktu |
| Sprzedawca | .sh-dgr__merchant-name |
Nazwa sklepu |
| Ocena | .sh-dgr__rating lub [aria-label*="rating"] |
Gwiazdki + liczba opinii |
| Link do produktu | a.sh-dgr__content |
href do /shopping/product/ |
Wskazówka: Selektory CSS Google zmieniają się 2-4 razy w roku. Zawsze implementuj mechanizm fallback i monitoruj, czy parsowanie zwraca puste wyniki — to pierwszy sygnał, że struktura HTML się zmieniła.
Dlaczego zlokalizowane ceny wymagają residential proxy
To najważniejszy punkt tego przewodnika. Google Shopping personalizuje wyniki na podstawie adresu IP. Jeśli Twój scraper używa IP z serwera datacenter w USA, ale próbujesz monitorować ceny w Niemczech, otrzymasz:
- Ceny w USD zamiast EUR
- Amerykańskich sprzedawców zamiast niemieckich
- Brakujące oferty od lokalnych merchantów
- Czasami przekierowanie na google.com zamiast google.de
Rozwiązanie: residential proxy z geo-targetowaniem na poziomie kraju i miasta. ProxyHat pozwala określić lokalizację w nazwie użytkownika:
user-country-US— adres IP z USAuser-country-DE-city-berlin— adres IP z Berlinauser-country-PL-city-warsaw— adres IP z Warszawy
Parametry URL gl i hl muszą być spójne z lokalizacją proxy. Jeśli używasz -country-DE-city-berlin, ustaw gl=de&hl=de. Mismatch między IP a parametrami URL to jeden z najczęstszych powodów blokad.
Sprawdź dostępne lokalizacje na stronie ProxyHat Locations, aby dopasować proxy do swoich rynków docelowych.
Implementacja Python: pełny przykład z ProxyHat
Poniżej znajduje się kompletny, działający przykład scrapowania Google Shopping z użyciem biblioteki requests i residential proxy ProxyHat. Kod pobiera SERP Shopping, parsuje jeden blok wyników i wyciąga tytuł, cenę, sprzedawcę i ocenę.
import requests
from bs4 import BeautifulSoup
import random
import time
# Konfiguracja proxy ProxyHat — residential, Niemcy, Berlin
PROXY_HOST = "gate.proxyhat.com"
PROXY_PORT = 8080
PROXY_USER = "user-country-DE-city-berlin"
PROXY_PASS = "twoje_haslo"
proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
proxies = {"http": proxy_url, "https": proxy_url}
# Nagłówki imitujące realną przeglądarkę
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/121.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "de-DE,de;q=0.9,en;q=0.8",
"Accept-Encoding": "gzip, deflate, br",
"DNT": "1",
"Connection": "keep-alive",
"Upgrade-Insecure-Requests": "1",
}
def scrape_google_shopping(query, gl="de", hl="de"):
url = "https://www.google.com/search"
params = {
"tbm": "shop",
"q": query,
"gl": gl,
"hl": hl,
"num": 20,
}
try:
response = requests.get(
url, params=params, headers=headers,
proxies=proxies, timeout=30
)
# Wykrywanie soft-blocków
if "/sorry/" in response.url or response.status_code == 429:
print(f"Soft-block wykryty! URL: {response.url}")
return None
soup = BeautifulSoup(response.text, "html.parser")
# Parsowanie kontenerów produktów
products = []
containers = soup.select(".sh-dgr__content")
for container in containers[:5]: # pierwsze 5 wyników
title_el = container.select_one(".sh-dgr__product-title, h3")
price_el = container.select_one(".a8Pemb")
merchant_el = container.select_one(".sh-dgr__merchant-name")
rating_el = container.select_one("[aria-label*='rating'], .sh-dgr__rating")
product = {
"title": title_el.get_text(strip=True) if title_el else None,
"price": price_el.get_text(strip=True) if price_el else None,
"merchant": merchant_el.get_text(strip=True) if merchant_el else None,
"rating": rating_el.get("aria-label", "") if rating_el else None,
}
products.append(product)
return products
except requests.exceptions.RequestException as e:
print(f"Błąd żądania: {e}")
return None
# Przykład użycia
results = scrape_google_shopping("Sony WH-1000XM5", gl="de", hl="de")
if results:
for p in results:
print(f"Tytuł: {p['title']}")
print(f"Cena: {p['price']}")
print(f"Sprzedawca: {p['merchant']}")
print(f"Ocena: {p['rating']}")
print("---")
# Losowe opóźnienie 3-8 sekund między żądaniami
time.sleep(random.uniform(3, 8))
Przykładowy (skrócony) wynik dla zapytania Sony WH-1000XM5 z Niemiec:
Tytuł: Sony WH-1000XM5 Wireless Noise Cancelling Headphones
Cena: 298,00 €
Sprzedawca: Amazon.de
Ocena: 4.6 out of 5 stars (1.247 ratings)
---
Tytuł: Sony WH-1000XM5 Schwarz
Cena: 319,99 €
Sprzedawca: MediaMarkt
Ocena: 4.5 out of 5 stars (832 ratings)
---
Zauważ, że ceny są w EUR i sprzedawcy to niemieckie sklepy — to efekt użycia -country-DE-city-berlin w połączeniu z gl=de&hl=de.
Paginacja, batching i wykrywanie soft-blocków
Scrapowanie jednej strony to początek. Realny system monitorowania cen musi obsługiwać paginację, batchowanie zapytań i detekcję blokad, zanim escalują do twardego CAPTCHA.
Paginacja
Google Shopping używa paginacji opartej na parametrze start:
https://www.google.com/search?tbm=shop&q=laptop&gl=de&hl=de&num=20&start=20
https://www.google.com/search?tbm=shop&q=laptop&gl=de&hl=de&num=20&start=40
Iteruj przez strony, zwiększając start o wartość num. Maksymalnie Google zwraca ~10 stron wyników (ok. 200 produktów). Jeśli start przekracza dostępne wyniki, Google zwraca pustą stronę — użyj tego jako warunku zakończenia.
Batching zapytań i rotacja sesji
Dla wielu zapytań używaj sesji sticky ProxyHat, aby utrzymać ten sam IP dla paginacji jednego zapytania, ale rotuj IP między zapytaniami:
# Sesja sticky dla jednego zapytania
PROXY_USER = "user-country-DE-city-berlin-session-query001"
# Następne zapytanie — nowa sesja = nowy IP
PROXY_USER = "user-country-DE-city-berlin-session-query002"
To zapewnia spójność wyników w obrębie jednego zapytania (paginacja) i świeży IP dla każdego nowego zapytania.
Losowe opóźnienia
Nigdy nie wysyłaj żądań w stałych odstępach. Google wykrywa wzorce timingowe. Używaj losowych opóźnień:
- 3-8 sekund między żądaniami w obrębie jednego zapytania
- 10-30 sekund między różnymi zapytaniami
- 60-120 sekund po wykryciu soft-blocka (backoff)
Wykrywanie soft-blocków
Soft-block to ostrzeżenie — jeśli go zignorujesz, nastąpi twardy ban IP. Sygnały soft-blocka:
- Przekierowanie na URL zawierający
/sorry/lub/sorry/index - HTTP 429 (Too Many Requests)
- HTTP 302 na
google.com/sorry/ - Pusta strona wyników (brak kontenerów
.sh-dgr__content) mimo poprawnego zapytania - Obecność formularza CAPTCHA w HTML (
div#captcha-form)
def detect_soft_block(response, soup):
if response.status_code == 429:
return True, "HTTP 429 — rate limit"
if "/sorry/" in response.url:
return True, f"Przekierowanie na {response.url}"
if soup.select_one("#captcha-form, .g-recaptcha"):
return True, "CAPTCHA wykryta w HTML"
if not soup.select(".sh-dgr__content, .sh-pr__product-results"):
return True, "Brak kontenerów produktów — możliwy soft-block"
return False, "OK"
Po wykryciu soft-blocka: zatrzymaj scraper na 60-120 sekund, zmień sesję proxy (nowy IP) i ponów żądanie z większym opóźnieniem. Dokumentacja Google potwierdza, że Google nakłada throttling na adresy IP generujące nadmierny ruch.
Porównanie typów proxy dla Google Shopping
| Cecha | Datacenter Proxy | Residential Proxy | Mobile Proxy |
|---|---|---|---|
| Prawdopodobieństwo blokady | Wysokie (80-90%) | d>Niskie (5-15%)Bardzo niskie (2-5%) | |
| Geo-targeting kraj/miasto | Ograniczony | Tak (kraj + miasto) | Tak (kraj) |
| Latencja | 50-100ms | 200-500ms | 300-800ms |
| Koszt | Niski | Średni | Wysoki |
| Współbieżność | Wysoka | Średnia (50-100 sesji) | Niska (5-10 sesji) |
| Rekomendacja dla Google Shopping | Nie | Tak — optymalne | Tak — dla trudnych przypadków |
Residential proxy to sweet spot dla Google Shopping: niskie ryzyko blokady, precyzyjne geo-targetowanie i rozsądna latencja. Sprawdź ceny ProxyHat, aby dobrać plan odpowiedni do Twojego wolumenu zapytań.
Typowe błędy i przypadki brzegowe
1. Mismatch między IP a parametrami URL
Używanie -country-US z gl=de&hl=de to gwarancja soft-blocka. Google widzi amerykańskie IP żądające niemieckich wyników — to anomalia. Zawsze dopasowuj lokalizację proxy do parametrów gl/hl.
2. Ignorowanie robots.txt
Google robots.txt nie zabrania dostępu do /search, ale określa crawl-delay. Przestrzegaj go, nawet jeśli scrapujesz legalnie.
3. Zbyt wysoka współbieżność
Uruchamianie 50 jednoczesnych żądań z jednego IP to pewna blokada. Utrzymuj 2-5 jednoczesnych sesji na IP. ProxyHat pozwala na rotację IP per-request, więc przy 50 sesjach używaj 50 różnych IP.
4. Brak fallback dla selektorów
Selektory Google zmieniają się 2-4 razy rocznie. Implementuj mechanizmy fallback (alternatywne selektory) i alerty na puste wyniki. Jeśli .a8Pemb przestanie działać, Twój scraper powinien próbować [class*='price'] jako fallback.
5. Ignorowanie paginacji produktu
Strona SERP Shopping pokazuje tylko główną cenę. Aby uzyskać pełną listę sprzedawców i porównanie ofert, musisz przejść do /shopping/product/{id} i sparsować panel ofert sprzedawców (seller-offer panel).
Etyka, TOS i zgodność prawna
Scrapowanie Google Shopping znajduje się w szarej strefie prawnej. Kluczowe zasady:
- Publiczne dane cenowe tylko — nie pobieraj danych osobowych, recenzji użytkowników z imionami ani danych kont.
- CFAA (USA) — Computer Fraud and Abuse Act może penalizować "nieautoryzowany dostęp" do systemów komputerowych. Scrapowanie publicznych stron jest sporne, ale istnieje precedent hiQ Labs v. LinkedIn, który częściowo chroni scrapowanie publicznych danych.
- GDPR (UE) — dotyczy danych osobowych. Ceny produktów i nazwy sprzedawców nie są danymi osobowymi, ale recenzje z imionami już tak.
- robots.txt — przestrzegaj dyrektyw crawl-delay i Disallow, nawet jeśli nie są prawnie wiążące.
- ToS Google — zakazują automatycznego pobierania danych. To niekoniecznie jest przestępstwo, ale może skutkować banem IP i konta Google.
Gdy zgodność jest krytyczna (np. enterprise), rozważ oficjalne trasy: Content API for Shopping dla własnych produktów lub oficjalnych partnerów SERP Google. Więcej o zastosowaniach scrapowania znajdziesz na stronie ProxyHat Web Scraping i SERP Tracking.
Konfiguracja ProxyHat i dokumentacja
ProxyHat udostępnia residential proxy z geo-targetowaniem na poziomie kraju i miasta przez prosty format nazwy użytkownika. Pełną dokumentację znajdziesz na docs.proxyhat.com.
Formaty połączenia
# HTTP — domyślny port 8080
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
# SOCKS5 — port 1080
socks5://user-country-DE-city-berlin:pass@gate.proxyhat.com:1080
# Sticky session (ten sam IP dla paginacji)
http://user-country-DE-city-berlin-session-abc123:pass@gate.proxyhat.com:8080
# USA — Nowy Jork
http://user-country-US-city-newyork:pass@gate.proxyhat.com:8080
# Polska — Warszawa
http://user-country-PL-city-warsaw:pass@gate.proxyhat.com:8080
Przykład curl
curl -x "http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept-Language: de-DE,de;q=0.9" \
"https://www.google.com/search?tbm=shop&q=laptop&gl=de&hl=de&num=20"
Kluczowe wnioski
Kluczowe wnioski:
- API vs HTML: Content API for Shopping udostępnia tylko własne produkty — competitive intelligence wymaga parsowania HTML SERP z
tbm=shop.- Selektory:
.sh-dgr__content(kontener),.a8Pemb(cena),.sh-dgr__merchant-name(sprzedawca) — implementuj fallback, bo selektory Google zmieniają się 2-4 razy w roku.- Geo-targeting: Ceny są zlokalizowane — używaj
-country-DE-city-berlinzgl=de&hl=de. Mismatch IP/URL to najczęstszy powód blokad.- Anti-bot: Monitoruj
/sorry/, HTTP 429 i puste kontenery jako sygnały soft-blocka. Po wykryciu — backoff 60-120s + nowa sesja proxy.- Opóźnienia: 3-8s między żądaniami, 10-30s między zapytaniami, 2-5 jednoczesnych sesji. Nigdy stałe timingi.
- Etyka: Tylko publiczne dane cenowe, przestrzegaj robots.txt, rozważ oficjalne API dla zgodności enterprise.
Często zadawane pytania
Czym jest scrapowanie cen Google Shopping w 2026?
Scrapowanie cen Google Shopping to proces automatycznego pobierania danych produktowych — cen, sprzedawców, ocen i dostępności — ze stron wyników Google Shopping (tbm=shop). W 2026 roku wymaga to użycia residential proxy z geo-targetowaniem i rotacją IP, ponieważ Google stosuje agresywne anti-boty, w tym reCAPTCHA i limity per-IP, które blokują nieautoryzowane żądania.
Dlaczego scrapowanie Google Shopping jest ważne dla użytkowników proxy?
Google Shopping wyświetla zlokalizowane ceny, sprzedawców i waluty w zależności od lokalizacji użytkownika. Aby uzyskać wiarygodne dane konkurencyjne dla różnych rynków, potrzebujesz residential proxy z geo-targetowaniem na poziomie kraju i miasta. Proxy typu datacenter są często blokowane przez Google, a Content API for Shopping udostępnia tylko własne produkty merchanta, więc proxy residential są kluczowe dla danych konkurencyjnych.
Który typ proxy działa najlepiej do scrapowania Google Shopping?
Residential proxy z geo-targetowaniem na poziomie kraju i miasta działają najlepiej do scrapowania Google Shopping. Adresy IP residential pochodzą od dostawców internetowych i wyglądają jak ruch realnych użytkowników, co minimalizuje ryzyko blokad. ProxyHat oferuje flagi takie jak -country-US lub -country-DE-city-berlin, które pozwalają na precyzyjne pozycjonowanie geograficzne niezbędne do pobierania zlokalizowanych cen.
Jak uniknąć blokad podczas scrapowania Google Shopping?
Aby uniknąć blokad, używaj rotacji IP per-request z residential proxy, losowych opóźnień 3-8 sekund między żądaniami, parametrów gl i hl dopasowanych do lokalizacji proxy, realistycznych nagłówków User-Agent oraz monitorowania przekierowań na /sorry/ lub /index, które sygnalizują soft-block. Utrzymuj współbieżność na niskim poziomie (2-5 jednoczesnych sesji) i wdrażaj wycofywanie przy pierwszych oznakach ograniczania.
Czy scrapowanie Google Shopping jest legalne?
Scrapowanie publicznie dostępnych danych cenowych z Google Shopping znajduje się w szarej strefie prawnej. W USA CFAA może ograniczać dostęp nieautoryzowany, a w UE GDPR dotyczy danych osobowych. Należy scrapować tylko publiczne dane cenowe, przestrzegać robots.txt, unikać danych osobowych i rozważyć oficjalne API Google Shopping lub partnerów SERP, gdy dostępne, jako zgodną alternatywę.
Następne kroki
Jeśli planujesz zbudować system monitorowania cen Google Shopping, zacznij od planu ProxyHat z residential proxy, przetestuj selektory na jednym rynku i skaluj stopniowo. Dokumentacja API ProxyHat na docs.proxyhat.com zawiera pełne reference wszystkich parametrów geo-targetowania i sesji. Po więcej przykładów użycia proxy w scrapowaniu zajrzyj na ProxyHat Web Scraping i SERP Tracking.






