Chrome Web Store scrapen 2026 (API & Python)

Am schnellsten scrapst du den Chrome Web Store 2026, indem du eine strukturierte API aufrufst, die normalisiertes JSON zurückgibt — Suchergebnisse, Listing-Detail, Nutzer-Reviews, deklarierte Permissions und Privacy-Disclosures — statt die client-seitig gerenderten Seiten des Stores selbst zu parsen. Für diese Daten gibt es keine öffentliche Developer-API, und Googles allgemeine Nutzungsbedingungen schränken automatisierten Zugriff ein. Dieser Guide zeigt dir alle drei Ansätze: was jeder liefert, wo DIY scheitert und die rechtlichen Grundlagen.

Warum den Chrome Web Store scrapen?

Listing- und Permission-Daten aus dem Chrome Web Store treiben an:

• Extension-Marktintelligenz — Kategorie-Leader, schnell wachsende Extensions und Install-Count-Trends über die Zeit im Blick behalten.
• Wettbewerbs- und ASO-Recherche — Listings, Keywords, Ratings und Review-Geschwindigkeit für eine Kategorie vergleichen.
• Security-Inventar — überwachen, welche Extensions breiten Host-Zugriff (<all_urls>) anfordern, die Migration von MV2 zu MV3 nachverfolgen und Permission-Änderungen zwischen Versionen erkennen.
• Trust- & Privacy-Recherche — die eigene deklarierte Datenerfassungs-Disclosure einer Extension lesen, bevor du sie empfiehlst oder allowlistest.
• Publisher- und Portfolio-Recherche — alles sehen, was ein Developer-Account veröffentlicht hat.

Ist es legal, den Chrome Web Store zu scrapen?

Option 1: DIY in Python (und warum das scheitert)

Die Item-Seiten des Stores rendern client-seitig, deshalb muss ein DIY-Scraper an die Daten, die in die Seite eingebettet sind, oder an die internen Endpoints des Stores herankommen:

import requests

resp = requests.get(
    "https://chromewebstore.google.com/detail/cjpalhdlnbpafiamejdnhcphjbkeiagm",
    headers={"User-Agent": "Mozilla/5.0 (compatible; research-bot/1.0)"},
)
# Rating, install count, and permissions live in an embedded JSON blob,
# not selectable markup — and /reviews and /privacy are separate,
# robots.txt-disallowed sub-pages you'd have to fetch individually

Es funktioniert in der Demo und geht dann kaputt:

• robots.txt schneidet genau die interessanten Teile heraus. Die Sitemap deckt die Basis-Item-Seiten ab, aber /search sowie die /reviews- und /privacy-Unterseiten eines Items sind verboten — genau die Endpoints, die ein Marktintelligenz- oder Security-Research-Use-Case am meisten braucht.
• Kein stabiles Markup. Ratings, Install-Counts und Permissions liegen in einem eingebetteten JSON-Blob, dessen Form sich mit Store-Redesigns ändert.
• Full-Catalog-Scale ist real. Die eigene Sitemap des Stores erstreckt sich über 30+ Shards mit rund 250K+ Extensions — ein vollständiger Sweep sind zig Gigabyte an Responses, bevor du überhaupt etwas parst, ein naiver Per-Page-Loop skaliert also nicht auf einen vollständigen Zensus.
• Permissions- und Privacy-Daten brauchen separate Requests. Detail, Reviews, Permissions und Privacy-Disclosures sind vier verschiedene Fetches pro Extension, jeder mit eigener Form.

Option 2: No-Code-Tools

Marktplatz-Scraper-Actors existieren für einzelne Extension-Lookups und eignen sich für einmalige Abzüge, aber ein Full-Catalog- oder Security-Monitoring-Use-Case braucht denselben Per-Item-Fan-out über vier Endpoints, egal welches Tool du nutzt.

Option 3: Eine strukturierte Chrome-Web-Store-API

Für einen wiederholbaren Workflow liefert eine Chrome Web Store scraping API normalisiertes JSON, ganz ohne Page-Parsing. Suche nach Extensions:

curl "https://api.crawlora.net/api/v1/chromewebstore/search?term=vpn" \
  -H "x-api-key: $CRAWLORA_API_KEY"

Hol dir Detail, Permissions und Privacy-Disclosure für ein Ergebnis in Python:

import requests

h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/chromewebstore"

hits = requests.get(f"{base}/search", headers=h, params={"term": "ad blocker"}).json()["data"]["results"]
ext_id = hits[0]["id"]

item = requests.get(f"{base}/item", headers=h, params={"id": ext_id}).json()["data"]
permissions = requests.get(f"{base}/permissions", headers=h, params={"id": ext_id}).json()["data"]
privacy = requests.get(f"{base}/privacy", headers=h, params={"id": ext_id}).json()["data"]
reviews = requests.get(f"{base}/reviews", headers=h, params={"id": ext_id, "num": 20}).json()["data"]

Eine Search-Response ist normalisiertes JSON (echte Felder — sieh dir die docs an):

{
  "code": 200,
  "msg": "OK",
  "data": {
    "query": "vpn",
    "count": 1,
    "results": [
      { "id": "majdfhpaihoncoakbjgbdhglocklcgno", "name": "Free VPN for Chrome - VPN Proxy VeePN", "rating": 4.5, "rating_count": 50285, "publisher": "veepn.com", "url": "https://chromewebstore.google.com/detail/majdfhpaihoncoakbjgbdhglocklcgno" }
    ]
  }
}

Permissions liefern den deklarierten Zugriff der Extension, inklusive jeder breiten Host-Permission:

{
  "data": {
    "id": "cjpalhdlnbpafiamejdnhcphjbkeiagm",
    "manifest_version": 2,
    "permissions": ["alarms", "contextMenus", "storage", "tabs", "webNavigation", "webRequest", "webRequestBlocking", "<all_urls>"]
  }
}

Und der Privacy-Endpoint liefert die eigene Disclosure des Entwicklers — welche Datenkategorien er als erfasst deklariert hat und seine erklärten Nutzungszusagen:

{
  "data": {
    "id": "kbfnbcaeplbcioakkpcpgfkobkghlhen",
    "collects_data": true,
    "data_collected": ["Personally identifiable information", "Personal communications", "Location", "User activity", "Website content"],
    "declarations": ["Not being sold to third parties, outside of the approved use cases"]
  }
}

Speichere eine Zeile pro Extension pro Abzug und lauf das Ganze nach Zeitplan erneut, um Rating-, Install-Count-, Permission- und Versions-Drift über die Zeit zu verfolgen.

Was du sammeln kannst

Öffentliche Extension-Daten: Suchergebnisse (id, Name, Rating, Rating-Count, Publisher); Listing-Detail (Beschreibung, Kategorie, Entwickler, Größe, Version, Update-Datum, Install-Count, Screenshots, Support-/Privacy-Links); Nutzer-Reviews (Autor, Rating, Text, Version, Datum); deklarierte Permissions und Host-Permissions, inklusive optionaler; Privacy-Disclosures (erfasste Datenkategorien, Entwickler-Deklarationen); dazu Kategorien, kuratierte Collections, Top-Charts, Publisher-Profile und Related-Item-Vorschläge. Nur öffentliche Listing- und Review-Daten.

Grenzen und typische Herausforderungen

• robots.txt verbietet Search sowie die Reviews-/Privacy-Unterseiten. Plane eine strukturierte API ein, statt diese Pfade direkt zu crawlen.
• Vier separate Calls pro Extension. Detail, Reviews, Permissions und Privacy brauchen jeweils einen eigenen Fetch — plane den Fan-out ein, wenn du eine Kategorie oder einen vollständigen Zensus abdeckst.
• Full-Catalog-Scale. Die öffentliche Sitemap erstreckt sich über 30+ Shards und rund eine Viertelmillion Extensions — behandle einen vollständigen Sweep als dauerhaften, fortsetzbaren Crawl, nicht als einzelnen Skript-Lauf.
• Permission-Heuristiken sind kein Security-Score. <all_urls> oder ein breites Permission-Set ist ein Signal, kein Beweis für böswillige Absicht — labele eine abgeleitete Heuristik nicht als "Malware", ohne eine echte Methodik dahinter zu haben.
• Nur öffentliche Daten. Das liefert Listing-Metadaten, nicht das tatsächliche Code-Paket der Extension (die .crx-Datei) — das herunterzuladen und zu analysieren ist ein eigenes, viel schwereres Unterfangen mit eigenem Review.

Wo das eingesetzt wird

• Extension-Marktintelligenz — Kategorie-Leader, schnell wachsende Extensions und verwaiste High-Install-Extensions.
• Security-Inventar — Tracking der MV2-zu-MV3-Migration, Permission- und Host-Access-Drift, Änderungen an Privacy-Disclosures.
• Wettbewerbs- und ASO-Recherche — Keyword- und Rating-Vergleiche innerhalb einer Kategorie.

Sources

Leg los mit dem Sammeln

Probier es zuerst kostenlos aus: jage eine beliebige öffentliche URL durch den Free Web Scraper oder prüfe mit dem Anti-Bot Checker, ob eine Seite Bots blockiert — ohne Anmeldung.

Teste die Search-, Item- und Permissions-Endpoints im Playground, sieh dir das Schema in den API docs an und wirf einen Blick aufs pricing. Extensions sind eine Distributions-Fläche für ein Produkt; how to scrape Google Play und how to scrape App Store reviews decken die Mobile-App-Seite mit derselben Search-dann-Detail-dann-Reviews-Form ab. Siehe auch how to choose a web scraping API und is web scraping legal.