How to Scrape Google Shopping Prices in 2026 (Python + API)

By Serpent API Team · · 11 min read

If you sell anything online, the price next to your product on Google Shopping is one of the most important numbers in your business. It decides whether a shopper clicks you or a cheaper rival.

So a natural question follows: how do you pull those prices into a spreadsheet or a script, automatically, every day?

Most people start by Googling "Google Shopping API" and end up confused. The official API does not do what they think. And the DIY scraping route breaks fast.

This guide clears it up. We compare the three honest approaches, show working Python, and explain why Google Shopping data now also matters for AI shopping assistants like ChatGPT.

TL;DR: Google's Content API for Shopping is only for merchants uploading their own feed — it cannot read competitor prices. DIY scraping fails because Shopping loads products through hidden async calls and aggressive bot blocks. The reliable path is a SERP API that returns the Google Shopping block as structured JSON. Below is a working Python example using Serpent's Google SERP API to build a lowest-price table.

Why Google Shopping prices are worth tracking in 2026

Tracking Google Shopping prices is no longer just about beating rivals by a dollar — it now also drives whether AI shopping assistants surface your products at all.

Here is the fresh hook. A 2026 study covered by Search Engine Land, using data from Peec AI, analyzed more than 43,000 products in ChatGPT shopping carousels across 10 verticals. It found that about 83% of those carousel products matched organic results from Google Shopping's top positions.

In plain English: when a shopper asks ChatGPT "what is the best budget espresso machine," the answer is heavily shaped by who shows up in Google Shopping.

That changes the stakes. Monitoring your Google Shopping presence is now a useful proxy for your AI shopping visibility too — not only your standard SERP rank. If you are blind on Google Shopping, you are likely invisible in AI shopping answers.

And the classic reasons still apply: price monitoring, competitor catalog tracking, and automated repricing all start with one feed of clean, current prices.

There is one more reason this is hard to ignore in 2026. Shoppers increasingly start their research inside an AI assistant rather than a search box, and those assistants lean on Google Shopping for grounding. So the Shopping block is quietly becoming a shared data layer behind both classic search and the new wave of AI shopping. Tracking it gives you a single signal that maps to both worlds at once — which is rare and worth building around.

Approach 1: The Google Content API for Shopping (and why it won't help)

The Google Content API for Shopping cannot scrape competitor prices — it is built for merchants to upload and manage their own product feed, full stop.

This trips up almost everyone. The name sounds like a "read Google Shopping" API. It is the opposite. It is a write/manage API for your Merchant Center catalog.

With it you can push your titles, prices, availability, and images into Google so your products appear in Shopping. You cannot query it for "all sellers of product X" or "the cheapest price for this SKU." It simply does not return that.

It is also changing. Google is retiring the legacy Content API for Shopping and replacing it with the new Merchant API, with the old Content API scheduled to shut down on August 18, 2026, per Search Engine Land. Either way, the use case stays the same: your feed, not the marketplace.

So if your goal is competitive price intelligence, the official API is a dead end. Cross it off the list.

Approach 2: DIY scraping with Python (fragile)

Writing your own Google Shopping scraper is possible, but it is fragile and high-maintenance — the page is engineered to resist exactly this.

The first wall you hit is dynamic loading. When you send a plain requests.get() to a Google Shopping URL, you get back a mostly empty HTML skeleton. The actual product cards load afterward through asynchronous calls that fire only once a real browser renders the page.

So your parser finds nothing. To see products you need a headless browser like Playwright or Selenium, which is slower and far heavier to run at scale.

The second wall is hidden parameters. The backend requests use session tokens, pagination tokens, and encoded identifiers that never appear in the address bar. Reverse-engineering them is a moving target — Google changes them often.

The third wall is anti-bot defense. As scraping guides like Scrape.do document, custom scrapers often clear 75–85% success on a first run, then fall below 50% without rotating proxies, with CAPTCHA rates climbing on US queries and high-volume jobs getting rate-limited fast.

The fourth wall is markup drift. Google rewrites its class names and DOM structure regularly. The selectors you write today silently break next month, usually at the worst time — we wrote a whole post on why your scraper breaks at 3am.

None of this is impossible. But for a price-monitoring system you want to run unattended, it is the wrong place to spend your engineering time. For a deeper look at the build-versus-buy math, see web scraping vs a SERP API.

Approach 3: A SERP API that returns the Shopping block

The reliable approach is a SERP API: you send a query, it returns the Google results — including the Shopping block — as clean structured JSON.

With Serpent's Google SERP API you make one HTTPS call and get parsed results back. The Shopping products that appear on the page surface in a shopping array inside the response. There is no proxy pool or headless browser to manage — the API handles access for you, including blocks and CAPTCHAs, so you don't.

Be clear about what this is, though. It is the Google SERP Shopping block — the product listings that show up on the search results page for your query — not a full, exhaustive product-catalog database of every seller for every SKU ever listed.

Each Shopping item carries the fields visible on that block, which can include the product title, price, and the merchant or source, plus a rating where Google shows one. Exact field names can evolve, so when you build a parser, always confirm the current response shape against the live docs rather than hard-coding assumptions.

That honesty matters: a SERP API is fantastic for "what does Google show for this query, right now, in this country," which is precisely what price-comparison and AI-visibility monitoring need.

Quick context: Serpent returns up to 100 organic results in a single call, alongside ads, People Also Ask, related searches, AI Overviews, the local pack, and the Shopping block — all from the Google web SERP. New to the category? Start with what is a SERP API.

Honest comparison of all three approaches

For competitive price intelligence, a SERP API wins on reliability and maintenance; the Content API simply cannot do the job; DIY only makes sense if scraping is your product.

Factor Content API for Shopping DIY scraping (Python) SERP API (Serpent)
Reads competitor prices? No — your own feed only Yes, if it works Yes (SERP Shopping block)
Setup effort Merchant Center + OAuth High (browser, proxies, parsers) One API call
Handles blocks / CAPTCHAs N/A You build it Handled for you
Breaks when Google changes HTML? N/A Yes, often No — API absorbs it
Structured JSON out of the box Yes (your data) No (you parse it) Yes
Good for unattended daily runs No (wrong data) Risky Yes

If price intelligence is a feature in your product, not the product itself, the choice is easy. Buy the data, build your logic on top.

One more practical note on cost, because it surprises people. Most scraping APIs charge more for "shopping" or for deeper result pages, so a wide catalog sweep gets expensive fast. With Serpent the Shopping block comes inside the standard Google SERP response, and page depth does not multiply the price — so a query that returns a fat Shopping block costs the same as a thin one. That makes large daily catalog sweeps genuinely affordable. The full breakdown lives on the pricing page.

Working Python: build a lowest-price table

Here is a complete, runnable example that queries a product, pulls the Shopping block, and prints a sorted lowest-price table.

Replace sk_live_your_key with your key from the dashboard (you get 10 free Google searches on signup). Authentication uses the X-API-Key header.

import requests

API_KEY = "sk_live_your_key"
BASE_URL = "https://api.apiserpent.com/api/search"

def get_shopping(query, country="us"):
    """Fetch the Google SERP and return the shopping block."""
    resp = requests.get(
        BASE_URL,
        headers={"X-API-Key": API_KEY},
        params={
            "q": query,
            "engine": "google",
            "country": country,
            "language": "en",
        },
        timeout=60,
    )
    resp.raise_for_status()
    data = resp.json()
    # The shopping block lives under results.shopping
    return data.get("results", {}).get("shopping", [])

def to_float(price):
    """Turn '$129.99' into 129.99; skip items without a clean price."""
    if not price:
        return None
    digits = "".join(c for c in str(price) if c.isdigit() or c == ".")
    try:
        return float(digits)
    except ValueError:
        return None

def lowest_price_table(query):
    items = get_shopping(query)
    rows = []
    for it in items:
        price_num = to_float(it.get("price"))
        if price_num is None:
            continue
        rows.append({
            "title": (it.get("title") or "")[:45],
            "price": price_num,
            "merchant": it.get("source") or it.get("merchant") or "-",
        })

    rows.sort(key=lambda r: r["price"])
    print(f"\nLowest prices for: {query}\n" + "-" * 60)
    for r in rows[:10]:
        print(f"${r['price']:>8.2f}  {r['merchant']:<18}  {r['title']}")
    if rows:
        print(f"\nCheapest: ${rows[0]['price']:.2f} at {rows[0]['merchant']}")

if __name__ == "__main__":
    lowest_price_table("breville barista express espresso machine")

The shape of the call is the load-bearing part: a GET to /api/search with the X-API-Key header and engine=google. Field names like price, title, and source follow the Shopping block — confirm the exact current keys in the docs before you go to production, and guard against missing fields like the code above does.

Want to scale this to your whole catalog? Loop over a list of SKUs, run the calls on a schedule, and store each day's snapshot. Because page depth does not change the price, deep and quick searches cost the same. To learn how to wrap this in a robust pipeline, see price monitoring with a SERP API.

Real use cases: repricing, monitoring, AI visibility

The same Shopping feed powers four high-value workflows, from simple alerts to automated repricing.

1. Price monitoring. Snapshot competitor prices daily and chart how they move. This is the foundation of any pricing strategy — our deeper guide on ecommerce price intelligence walks through the analytics layer.

2. Repricing alerts. Trigger a Slack or email alert when a rival undercuts you on a key product, so a human (or an automated rule) can respond within minutes instead of days.

3. Competitor catalog tracking. Watch which sellers appear for your priority queries, when new entrants show up, and how often a competitor wins the Shopping block.

4. AI shopping visibility. Given the 83% overlap study, your Google Shopping presence is a leading indicator for whether AI assistants will recommend you. Track it the same way you track classic rank. If you also care about AI answer placement broadly, pair this with the AI Rank API, which queries ChatGPT, Claude, Gemini and Perplexity and returns brand citation and visibility data.

The pattern is consistent across all four: get clean, current prices from the SERP Shopping block, then build your own logic on top. The data layer is the hard part, and that is the part you can stop maintaining.

Pull Google Shopping prices without the scraping headache

Serpent returns the Google Shopping block as clean JSON in one API call — no proxy pool, no headless browser, no broken selectors. Start with 10 free Google searches, then pay from $0.03 per 10,000 calls. No subscription, $10 minimum deposit.

Get Your Free API Key

Explore: Google SERP API · Live Playground · Pricing

FAQ

Can I use the Google Content API for Shopping to scrape competitor prices?

No. The Content API for Shopping (now the Merchant API) only lets a merchant upload and manage their own product feed in Merchant Center. It returns no competitor data and no public Shopping search results, so it cannot be used to monitor rival prices.

Is it legal to scrape Google Shopping prices?

Scraping publicly visible prices is widely practiced for price monitoring, but it can conflict with Google's Terms of Service and varies by country. Using a SERP API keeps you off Google's infrastructure directly. Consult a lawyer for your specific use case.

Why does my Python scraper return an empty page for Google Shopping?

Google Shopping loads product data through asynchronous requests after the page renders, so a plain requests.get only sees an empty skeleton. You need a real browser or an API that returns the parsed Shopping block as JSON.

Does Serpent return Google Shopping data?

Yes. The shopping array in Serpent's Google SERP response carries the Shopping block products surfaced on the results page, including title, price and merchant source where available. It is the SERP Shopping block, not a full product-catalog database.

Why does Google Shopping matter for AI shopping visibility?

A 2026 study found about 83% of products ChatGPT recommends in shopping carousels came from Google Shopping data. Monitoring your Google Shopping presence is therefore a useful proxy for whether AI shopping assistants will surface your products.

How much does it cost to scrape Google Shopping with Serpent?

Google searches start at $0.60 per 10,000 calls pay-as-you-go and drop to $0.03 per 10,000 at the Scale tier. Page depth does not multiply the price, and you get 10 free searches on signup with no subscription.