Jak scrapować ceny Google Shopping w 2026 roku — przewodnik implementacji

Jak scrapować ceny Google Shopping 2026: od API do parsowania HTML

Jeśli chcesz scrape Google Shopping w 2026 roku, pierwszą decyzją jest wybór między oficjalnym API a parsowaniem HTML. Google Content API for Shopping służy wyłącznie do zarządzania własnym katalogiem produktów merchantów — nie zwraca danych konkurencji. Oznacza to, że do pozyskiwania cen konkurentów, porównań ofert czy analizy rynkowej musisz parsować strony wyników Google Shopping (tbm=shop) lub strony szczegółów produktów (/shopping/product/).

W tym przewodniku pokazujemy, jak zbudować Google Shopping price scraper krok po kroku: od wzorców URL, przez selektory CSS, po rotację IP z ProxyHat i wykrywanie blokad. Skierowany jest do analityków cen i inżynierów competitive intelligence, którzy potrzebują Google Shopping product data w skali.

Content API vs parsowanie HTML — szybkie porównanie

Więcej o Content API for Shopping znajdziesz w oficjalnej dokumentacji Google.

Stack anty-bot Google: reCAPTCHA, sorry/index i limity per-IP

Google stosuje wielowarstwowy system ochrony przed automatyzacją. Scrapowanie Google Shopping w 2026 roku wymaga zrozumienia trzech głównych mechanizmów:

• reCAPTCHA Enterprise — po przekroczeniu limitu zapytań Google wyświetla wyzwanie CAPTCHA. W przypadku SERP często jest to reCAPTCHA v2 lub niewidoczne v3, które ocenia ryzyko na podstawie zachowania, IP i sygnałów przeglądarki.
• Przekierowanie sorry/index — Google przekieruje podejrzane zapytania na https://www.google.com/sorry/index, gdzie wyświetla komunikat o nietypowym ruchu. To pierwszy sygnał soft-blocka przed twardym CAPTCHA.
• Limity per-IP — Google nie publikuje oficjalnych limitów, ale testy pokazują, że ten sam adres IP wysyłający ponad 50 zapytań/min do SERP jest flagowany niemal natychmiast. Datacenter IP są blokowane szybciej niż residential.

Kluczowa strategia: rotacja IP residential z losowymi opóźnieniami utrzymuje success rate powyżej 95% przy odpowiednio niskiej częstotliwości zapytań na IP.

Wzorce URL i selektory CSS dla Google Shopping

Wzorzec URL dla wyników zakupowych

Podstawowy URL dla wyników Google Shopping to:

https://www.google.com/search?tbm=shop&q=iphone+15+pro

Parametry lokalizacyjne są krytyczne dla poprawnych cen:

• gl — kod kraju (np. us, de, pl)
• hl — język interfejsu (np. en, de, pl)
• tbm=shop — wymusza zakładkę Shopping

Pełny przykład z geo-targetingiem:

https://www.google.com/search?tbm=shop&q=iphone+15+pro&gl=de&hl=de

Strona szczegółów produktu

Kliknięcie w produkt prowadzi do:

https://www.google.com/shopping/product/12345678901234567890

Na tej stronie znajduje się panel ofert sprzedawców (.sh-pr__product-results), który zawiera porównanie cen od różnych merchantów.

Kluczowe selektory CSS

Selektory CSS Google zmieniają się regularnie. Traktuj powyższą listę jako punkt startowy i weryfikuj ją przed każdym uruchomieniem scrapera. Utrzymuj mechanizm fallback z XPath.

Przykładowy skrócony blok odpowiedzi HTML

<div class="sh-dgr__content">
  <div class="mQi3kd">
    <h3 class="tA8xrb">Apple iPhone 15 Pro 128GB</h3>
  </div>
  <div class="sh-dgr__grid-result">
    <span class="a8Pemb">999,00 $</span>
    <span class="tA8xrb">Amazon.com</span>
  </div>
  <span aria-label="Ocena 4.5 z 5"></span>
</div>

Dlaczego zlokalizowane ceny wymagają proxy residential z geo na poziomie miasta

Kupujący w USA i kupujący w Niemczech widzą różnych sprzedawców i różne waluty na Google Shopping. Wynika to z lokalizacji IP, parametrów gl/hl oraz dostępności ofert w danym regionie.

Datacenter proxy z lokalizacją w USA nie wystarczy, jeśli potrzebujesz cen z Berlina — Google może rozpoznać IP jako datacenter i wyświetlać przekierowanie sorry lub zniekształcone wyniki. Residential proxy z geo-targetingiem na poziomie miasta rozwiązuje ten problem, ponieważ zapytanie wygląda jak ruch realnego użytkownika w danym mieście.

Przykłady konfiguracji ProxyHat dla różnych rynków:

# USA — ogólnokrajowo
http://user-country-US:pass@gate.proxyhat.com:8080

# Niemcy — Berlin
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080

# Polska — Warszawa
http://user-country-PL-city-warsaw:pass@gate.proxyhat.com:8080

# Sesja sticky (ten sam IP dla wielu zapytań)
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

Dostępne lokalizacje sprawdzisz na stronie lokalizacji ProxyHat. Połączenie parametrów URL (gl=de&hl=de) z proxy residential w Niemczech daje najbardziej wiarygodne wyniki cen.

Praktyczny przykład: Python requests przez ProxyHat

Poniżej kompletny przykład scrapowania jednego bloku wyniku z Google Shopping — tytuł, cena, sprzedawca, ocena:

import requests
from bs4 import BeautifulSoup
import random
import time

# Konfiguracja proxy ProxyHat — residential, Niemcy, Berlin
proxy_url = "http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}

# URL Google Shopping z parametrami lokalizacyjnymi
url = "https://www.google.com/search"
params = {
    "tbm": "shop",
    "q": "iphone 15 pro",
    "gl": "de",
    "hl": "de",
}
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-Language": "de-DE,de;q=0.9,en;q=0.8",
}

response = requests.get(url, params=params, proxies=proxies, headers=headers, timeout=30)

# Sprawdzenie soft-blocka
if "/sorry/" in response.url:
    print("SOFT BLOCK: przekierowanie na sorry/index")
    exit(1)

soup = BeautifulSoup(response.text, "html.parser")

# Parsowanie kontenerów produktów
products = soup.select(".sh-dgr__content")
for product in products[:3]:  # skrócone do 3 wyników
    title_el = product.select_one(".tA8xrb")
    price_el = product.select_one(".a8Pemb")
    rating_el = product.select("[aria-label*=\"Ocena\"]") or product.select("[aria-label*=\"Rated\"]")

    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[0].get("aria-label", "N/A") if rating_el else "N/A"

    print(f"Tytuł: {title}")
    print(f"Cena: {price}")
    print(f"Ocena: {rating}")
    print("---")

Przykładowy (skrócony) wynik:

Tytuł: Apple iPhone 15 Pro 128GB
Cena: 1.149,00 €
Ocena: Rated 4.5 out of 5
---
Tytuł: Apple iPhone 15 Pro 256GB
Cena: 1.299,00 €
Ocena: Rated 4.6 out of 5
---

Używaj session-abc123 w username, gdy potrzebujesz spójnego IP dla paginacji lub wielokrotnych zapytań do tego samego rynku. Sticky sessions utrzymują ten sam IP przez okres sesji.

Paginacja, batching zapytań i wykrywanie soft-blocks

Paginacja

Google Shopping używa parametru start do paginacji, w przyrostach co 20 wyników:

# Strona 1: start=0 (domyślnie)
https://www.google.com/search?tbm=shop&q=iphone+15+pro&gl=de&hl=de

# Strona 2
https://www.google.com/search?tbm=shop&q=iphone+15+pro&gl=de&hl=de&start=20

# Strona 3
https://www.google.com/search?tbm=shop&q=iphone+15+pro&gl=de&hl=de&start=40

Powyżej 3–4 stron wyników jakość danych spada, a ryzyko blokady rośnie. Dla większości zapytań pierwsze 40–60 wyników pokrywa top sprzedawców.

Batching zapytań z losowymi opóźnieniami

import random
import time

queries = ["iphone 15 pro", "samsung galaxy s24", "pixel 8 pro"]

for query in queries:
    # Losowe opóźnienie 3–7 sekund między zapytaniami
    delay = random.uniform(3, 7)
    time.sleep(delay)

    # Rotacja sesji — nowe zapytanie, nowy IP
    session_id = f"sess-{random.randint(10000, 99999)}"
    proxy = f"http://user-country-DE-session-{session_id}:pass@gate.proxyhat.com:8080"

    response = requests.get(url, params={**params, "q": query},
                            proxies={"http": proxy, "https": proxy},
                            headers=headers, timeout=30)

    if "/sorry/" in response.url or response.status_code == 429:
        print(f"Soft-block na zapytaniu: {query}")
        # Pauza 60–120 s przed ponowną próbą
        time.sleep(random.uniform(60, 120))
        continue

    # Parsowanie...</pre></pre><h3>Wykrywanie soft-blocks przed twardym CAPTCHA</h3><p>Kluczowe sygnały ostrzegawcze:</p><ul><li><strong>Przekierowanie na <code>/sorry/index</code></strong> — natychmiastowa pauza, zmiana IP.</li><li><strong>HTTP 429</strong> — rate limit, zmniejsz częstotliwość.</li><li><strong>Puste wyniki</strong> przy poprawnym zapytaniu — Google może zwracać pustą stronę zamiast CAPTCHA.</li><li><strong>Skrócone wyniki</strong> — mniej niż 5 produktów przy zapytaniu, które normalnie zwraca 20+, to sygnał throttling.</li><li><strong>Obecność <code>id="captcha-form"</code></strong> w HTML — twardy block, wymaga wymiany IP i pauzy.</li></ul><p>Strategia: utrzymuj <strong>3–5 s</strong> opóźnienia między zapytaniami na ten sam IP i rotuj sesję co 20–30 zapytań. Przy 100 konkurentach i 5 rynkach to ~500 zapytań — przy rotacji IP trwa to około 40–50 minut.</p><h2>Etyka, TOS i aspekty prawne</h2><p>Scrapowanie publicznych danych cenowych z Google Shopping znajduje się w szarej strefie prawnej. Kluczowe kwestie:</p><ul><li><strong>Computer Fraud and Abuse Act (CFAA)</strong> — w USA scrapowanie publicznie dostępnych danych bez autoryzacji było historycznie sporne, ale wyrok <em>Van Buren v. United States (2021)</em> zawęził interpretację „nieautoryzowanego dostępu". Mimo to, omijanie mechanizmów ochrony (CAPTCHA, rate limits) może stanowić naruszenie. Więcej w analizie <a href="https://www.law.cornell.edu/supreme_court.text/593_U.S._374" rel="noopener noreferrer">Cornell Law School</a>.</li><li><strong>RODO/GDPR</strong> — dane cenowe produktów nie są danymi osobowymi, ale jeśli scrapujesz opinie użytkowników lub identyfikatory kont, wchodzi to w zakres GDPR. Komisja Europejska opisuje zasady w <a href="https://commission.europa.eu/law/law-topic/data-protection_en" rel="noopener noreferrer">dokumentacji ochrony danych</a>.</li><li><strong>Terms of Service Google</strong> — automatyzowane pobieranie wyników wyszukiwania narusza TOS Google. Konsekwencje to blokada IP, a w skrajnych przypadkach działania prawne.</li><li><strong>robots.txt</strong> — Google blokuje crawling SERP w robots.txt. Scrapowanie mimo tego jest świadomym naruszeniem.</li></ul><p><strong>Kiedy rozważyć oficjalne partnerstwo:</strong> Jeśli twój przypadek użycia wymaga dużej skali i zgodności z regulaminem, oficjalni partnerzy Google Shopping API lub SERP API (np. poprzez programy partnerskie Google) są compliant route. Kosztuje więcej, ale eliminuje ryzyko prawne i infrastrukturalne.</p><h2>Konfiguracja ProxyHat i optymalizacja</h2><h3>Wybór typu proxy</h3><table><thead><tr><th>Typ proxy</th><th>Zalecane dla Google Shopping?</th><th>Uzasadnienie</th></tr></thead><tbody><tr><td>Residential</td><td>Tak — zalecane</td><td>Najbardziej wiarygodne, najniższe ryzyko blokady</td></tr><tr><td>Mobile</td><td>Tak — alternatywa</td><td>Wysoka wiarygodność, wyższy koszt</td></tr><tr><td>Datacenter</td><td>Nie</td><td>Szybkie blokady przez Google</td></tr></tbody></table><h3>Konfiguracja SOCKS5 dla niższej latencji</h3><p>Dla zapytań wymagających niższej latencji, ProxyHat oferuje SOCKS5 na porcie <code>1080</code>:</p><pre><code>socks5://user-country-DE-city-berlin:pass@gate.proxyhat.com:1080

Więcej o konfiguracji proxy znajdziesz w dokumentacji ProxyHat. Cennik i plany dostępne są na stronie cennika ProxyHat.

Integracja z przypadkami użycia

Scrapowanie Google Shopping jest częścią szerszych workflowów:

• Web scraping — ogólne podejście do scrapowania z proxy.
• SERP tracking — monitorowanie pozycji i wyników wyszukiwania.

Najczęstsze błędy i przypadki brzegowe

• Ignorowanie parametrów gl/hl — bez nich Google zwraca wyniki na podstawie IP, co może być niespójne z proxy.
• Zbyt szybka rotacja IP — każde zapytanie z nowego IP wygląda podejrzanie. Używaj sticky sessions dla 20–30 zapytań.
• Brak fallback selektorów — Google zmienia klasy CSS. Utrzymuj listę alternatywnych selektorów XPath.
• Ignorowanie soft-blocks — kontynuowanie scrapowania po przekierowaniu /sorry/ prowadzi do trwałej blokady IP.
• Brak walidacji ceny — parsowanie tekstu ceny ("1.149,00 €") wymaga uwzględnienia formatu lokalnego. Użyj regex z walutą i separatorem tysięcy.
• Scrapowanie opinii użytkowników — to dane osobowe podlegające GDPR. Ogranicz się do cen i specyfikacji produktów.

Kluczowe wnioski

• Content API for Shopping nie wystarcza do competitive intelligence — parsowanie HTML tbm=shop jest jedyną drogą do publicznych cen konkurentów.
• Residential proxy z geo na poziomie miasta jest niezbędne dla poprawnych zlokalizowanych cen — datacenter IP są blokowane niemal natychmiast.
• Selektory CSS (.sh-dgr__content, .a8Pemb, .sh-pr__product-results) zmieniają się — utrzymuj mechanizm fallback i testuj przed każdym uruchomieniem.
• Wykrywanie soft-blocks (przekierowanie /sorry/, HTTP 429, puste wyniki) zapobiega twardym blokadom i utracie IP.
• Losowe opóźnienia 3–7 s i rotacja sesji co 20–30 zapytań utrzymują success rate powyżej 95%.
• Aspekty prawne — scrapowanie publicznych danych cenowych jest technicznie wykonalne, ale narusza TOS Google. Dla skali produkcyjnej rozważ oficjalne partnerstwa API.