Tippe „zillow scraper github“ in die Suche und du landest erst mal bei 409 Repositories – eine ordentliche Auswahl, könnte man meinen. Der Haken kommt zwei Klicks später: 264 davon haben seit mehr als einem Jahr keinen Commit mehr gesehen.
Genau diese Repos habe ich mir der Reihe nach vorgenommen: gegen echte Zillow-Seiten laufen lassen, die GitHub-Issues durchgeklickt und die Reddit-Threads gelesen, in denen Entwickler ihrem Ärger Luft machen, was diese Woche schon wieder nicht mehr funktioniert. Dabei wiederholt sich immer dieselbe Geschichte: Ein Repo bekommt mit dem ersten lauffähigen Release einen Schwung Stars, und kaum ändert Zillow sein DOM, zieht den Anti-Bot-Schutz an oder kappt einen internen API-Endpunkt, verstummt das Projekt – ohne Ankündigung, ohne Hinweis. Ein genervter Entwickler hat es auf Reddit auf den Punkt gebracht: „scraping projects need to be on constant maintenance due to changes on the page or api.“ Dieser Artikel ist die Bestandsaufnahme, die ich gern vor meinem ersten Zillow-Scraper-Repo gehabt hätte – ehrlich, auf dem Stand von 2026, mit dem, was läuft, was kaputt ist und warum, und wann du dir das ganze GitHub-Gebastel einfach sparen und gleich zu einem Tool wie Thunderbit greifen solltest.
Was ist ein Zillow Scraper GitHub-Projekt – und wer braucht so etwas?
Unter einem „Zillow-Scraper“ versteht man jedes Script oder Tool, das Immobiliendaten automatisch von Zillow einsammelt: Preis, Adresse, Zimmer, Bäder, Wohnfläche, Zestimate, Angebotsstatus, Tage am Markt – und teils tiefere Details aus Unterseiten wie Preisverlauf oder Steuerunterlagen. Auf GitHub landen die meisten, weil sie sich etwas Kostenloses, Offenes und Anpassbares wünschen: Repo forken, ein paar Felder umstellen, die Ausgabe in die eigene Pipeline kippen. Klingt nach dem Besten aus beiden Welten – jedenfalls auf dem Papier.
Wer das tatsächlich macht, lässt sich recht sauber in Gruppen sortieren:
- Immobilieninvestoren behalten Deals über mehrere Postleitzahlen im Blick – sie wollen Preisrückgänge, Zestimate-Abweichungen und Tage am Markt, um Chancen zu erkennen
- Makler bauen Prospecting-Listen – sie brauchen Angebots-URLs, Maklerkontakte und Statuswechsel bei Listings
- Marktforscher und Analysten ziehen strukturierte Vergleichsdaten – Adresse, Preis pro Quadratfuß, Verkaufspreis gegen Angebotspreis, Bestandszahlen
- Ops-Teams beobachten Preise oder Bestände in festen Abständen über mehrere Märkte hinweg
Eines verbindet alle: Sie wollen strukturierte, wiederholbare Daten statt eines einmaligen Copy-Paste-Jobs. Das ist der Grund, warum Scraping so reizvoll wirkt – und gleichzeitig der Grund, warum es so wehtut, wenn ein Repo plötzlich aussteigt.
Der Zillow-Scraper-GitHub-Audit 2026: Was wirklich noch läuft
Ich habe GitHub nach den meistgestarteten und meistgeforkten Repos durchforstet, die letzten Commit-Daten kontrolliert, offene Issues gelesen und alles gegen echte Zillow-Seiten getestet. Der Maßstab ist bewusst schlicht: Liefert ein Repo Stand April 2026 korrekte Listing-Daten aus Suchergebnissen oder Detailseiten, gilt es als „working“. Läuft es zwar, gibt aber unvollständige Daten zurück oder wird nach ein paar Seiten geblockt, ist es „partially working“. Scheitert es komplett oder hat der Maintainer selbst den Stecker gezogen, ist es „broken“.
Die unbequeme Bilanz: Das meiste, was vor 12 bis 18 Monaten noch vielversprechend aussah, ist heute leise gestorben.
Kuratierte Vergleichstabelle: Top-Zillow-Scraper-GitHub-Repos
| Repo | Sprache | Stars | Letzter Push | Ansatz | Status 2026 | Wichtigste Einschränkung |
|---|---|---|---|---|---|---|
| johnbalvin/pyzill | Python | 96 | 2025-08-28 | Extraktion aus Zillow-Suche/Detailseiten + Proxy-Support | Teilweise funktionsfähig | Die README sagt „Use rotating residential proxies.“ Probleme sind Cloudflare-Blockaden, 403s über proxyrack und CAPTCHA trotz Proxys. |
| johnbalvin/gozillow | Go | 10 | 2025-02-23 | Go-Library für Property-URL/ID und Suchmethoden | Teilweise funktionsfähig | Gleicher Maintainer wie pyzill, aber geringe Verbreitung und wenig Issue-Aktivität. Das Vertrauen ist niedriger. |
| cermak-petr/actor-zillow-api-scraper | JavaScript | 59 | 2022-05-04 | Gehosteter Actor mit rekursiver interner Zillow-API | Teilweise funktionsfähig (riskant) | Cleveres Design – Map-Grenzen werden rekursiv aufgeteilt, um Ergebnislimits zu umgehen. Aber das GitHub-Repo wurde seit 2022 nicht mehr gepusht. Ein Issue-Titel lautet: „is this still working?“ |
| ChrisMuir/Zillow | Python | 170 | 2019-06-09 | Selenium | Kaputt | Die README sagt ausdrücklich: „As of 2019, this code no longer works for most users.“ Zillow erkennt Webdriver und liefert endlose CAPTCHAs. |
| scrapehero/zillow_real_estate | Python | 152 | 2018-02-26 | requests + lxml | Kaputt | Probleme sind unter anderem „returns empty dataset“, „No output in .csv file“ und „Is this repo still updated?“ |
| faithfulalabi/Zillow_Scraper | Python/Notebook | 30 | 2021-07-02 | Hardcodiertes Selenium | Kaputt | Ein Lernprojekt, fest auf Mietobjekte in Arlington, TX codiert. Kein allgemeiner Scraper. |
| eswan18/zillow_scraper | Python | 10 | 2021-04-10 | Scraper- und Verarbeitungs-Pipeline | Kaputt | Das Repo ist archiviert. |
| Thunderbit | No-Code (Chrome-Erweiterung) | N/A | Kontinuierlich aktualisiert | KI liest die Seitenstruktur + vorgefertigte Zillow-Vorlage | Funktioniert | Kein GitHub-Repo zu warten. Die KI passt sich an, wenn Zillow das Layout ändert. Kostenloser Tarif verfügbar. |
Das Bild ist eindeutig: Lebendigen Code gibt es im GitHub-Ökosystem durchaus noch, aber das Gros der sichtbaren Repos sind Tutorials, historische Überbleibsel oder dünne Wrapper um einen proxy-abhängigen Workflow.
Was „working“, „broken“ und „partially working“ bedeutet
Diese drei Labels halte ich bewusst scharf getrennt, denn sie sagen mehr aus als jede Star-Zahl:
- Working: Liefert zum Testzeitpunkt korrekte Listing-Daten aus Zillow-Suchergebnissen und/oder Detailseiten, ohne dass der Maintainer das Projekt für tot erklärt hat
- Partially working: Läuft, gibt aber unvollständige Daten zurück, wird nach ein paar Seiten blockiert oder funktioniert nur auf bestimmten Seitentypen – meist nur mit Proxy-Infrastruktur und dauerndem Nachjustieren
- Broken: Liefert keine Daten, wirft Fehler oder wurde vom Maintainer beziehungsweise der Community ausdrücklich als nicht lauffähig markiert
Ein Repo mit 170 Stars im Status „broken“ ist nichts wert gegen ein Repo mit 10 Stars, das tatsächlich Daten ausspuckt. Beliebtheit erzählt dir die Geschichte des Projekts, nicht seine aktuelle Qualität.
Warum Zillow-Scraper-GitHub-Projekte kaputtgehen: die 5 häufigsten Fehlerursachen
Wer begreift, warum Zillow-Scraper aussteigen, spart sich mehr Zeit als mit jeder README. Mit dem Wissen über die Ursachen baust du entweder einen widerstandsfähigeren Scraper – oder entscheidest gleich, dass sich der Pflegeaufwand nicht rechnet.
1. DOM-Umbauten (Zillows React-Frontend)
Zillows Oberfläche läuft auf React und wird laufend umgebaut. Klassennamen, Komponentenstruktur, Datenattribute – alles verschiebt sich ohne Vorwarnung. Ein Scraper, der heute brav div.list-card-price anspricht, steht morgen vor dem Nichts, weil genau diese Klasse verschwunden ist. Eine Antwort auf Stack Overflow bringt es auf den Punkt: Auf Zillow „the class names vary from page to page“.
Das Tückische daran: Dein Script läuft weiter, liefert aber leere Felder zurück – und du merkst es erst, nachdem du eine Woche lang nur Nullen eingesammelt hast.
2. Änderungen an internen API- und GraphQL-Endpunkten
Die schlaueren Repos lassen HTML komplett links liegen und sprechen direkt Zillows interne GraphQL- oder REST-APIs an. Das Repo actor-zillow-api-scraper etwa nutzt ausdrücklich die interne API und zerlegt Kartenbegrenzungen rekursiv, um Ergebnislimits auszuhebeln. Schlau gemacht. Nur strukturiert Zillow diese Endpunkte regelmäßig um. Dann bekommt dein Scraper 404s oder leeres JSON zurück, völlig ohne Fehlermeldung.
Das ist die heimtückischere Variante des Scheiterns: Der Code stimmt. Bloß das Ziel hat sich verschoben.
3. Anti-Bot- und CAPTCHA-Eskalation
Zillow hat die Bot-Erkennung in den vergangenen Jahren spürbar hochgefahren. In meinen eigenen Tests im April 2026 quittierten schon einfache requests.get()-Aufrufe an zillow.com ebenso wie an zillow.com/homes/Chicago,-IL_rb/ jeweils mit 403-Antworten von CloudFront – sogar mit Chrome-ähnlichem User-Agent und Accept-Language-Header. Die Community berichtet Ähnliches: Ein Nutzer schrieb, sein reverse-engineerter API-Flow habe nach rund 100 Requests ein 403 kassiert.
Scraper, die bei kleinen Mengen tadellos laufen, brechen oft genau dann weg, wenn du hochskalierst. Eine wirklich unangenehme Überraschung, wenn du eigentlich 200 Listings über drei Postleitzahlen im Auge behalten wolltest.
4. Login-Schranken bei Premium-Daten
Manche Datenpunkte – Zestimate-Details, Steuerunterlagen, Teile des Preisverlaufs – stecken hinter einer Anmeldung. Open-Source-Scraper beherrschen Login-Flows nur in den seltensten Fällen, also bleiben diese Felder schlicht leer. Hängt dein Use Case am Preisverlauf oder an steuerlich veranlagten Werten, läufst du hier schnell gegen eine Wand.
5. Abhängigkeiten veralten und Repos werden nicht gepflegt
Die Issues im scrapehero-Repo drehen sich um Installationsprobleme wie No module named 'unicodecsv'. Das eswan18-Repo dokumentiert den manuellen Ärger mit Treiber- und GIS-Abhängigkeiten. Updates von Python-Bibliotheken sprengen die Kompatibilität. Repos, die länger als sechs Monate keinen Commit gesehen haben, scheitern oft schon bei der frischen Installation – lange bevor Zillows Anti-Bot-Stack überhaupt eine Rolle spielt.
Zillows Anti-Bot-Schutz 2026: Womit du es wirklich zu tun hast
„Nimm halt Proxys und rotiere die Header“ – 2022 war das noch ein brauchbarer Rat. 2026 trägt er nicht mehr.
Mehr als IP-Blocking: TLS-Fingerprinting und JS-Challenges
Zillow blockiert längst nicht mehr nur IP-Adressen. Community-Berichte beschreiben, dass Zillow hinter Cloudflare sitzt und auf Fingerprinting und Bot-Erkennung setzt, die weit über simples Rate-Limiting hinausgehen. TLS-Fingerprinting enttarnt Nicht-Browser-Clients an ihrem „digitalen Handschlag“ – also daran, wie sie die Verschlüsselung aushandeln. Selbst mit frischem Proxy kann dein Scraper auffliegen, wenn seine TLS-Signatur nicht zu einem echten Chrome passt.
Dazu kommen JavaScript-Challenges als zweite Hürde. Headless-Browser, die JS nicht vollständig ausführen oder ihre Automatisierungsmarker offenlegen (etwa navigator.webdriver = true), fallen auf.
Suchseiten vs. Detailseiten von Objekten: unterschiedliche Schutzstufen
Nicht jede Zillow-Seite ist gleich gut bewacht. Das Apify-Real-Estate-Schema unterscheidet explizit zwischen einem „Fast Mode“, der Detailseiten überspringt, und einem langsameren „Full Mode“ mit reicheren Daten. Auch Thunderbits Zillow-Guide trennt das erste Listing-Scraping von „Scrape Subpages“ für die Anreicherung über Detailseiten.
In der Praxis heißt das: Dein Scraper kann auf Suchergebnissen anstandslos arbeiten und auf einzelnen Objektseiten reihenweise scheitern – dort fährt Zillow schärferen Schutz auf, weil die Daten wertvoller sind und häufiger abgegriffen werden.
Die HTTP-only-Fraktion: Warum manche Entwickler Browser-Automatisierung meiden
Es gibt eine ausgeprägte Fraktion von Entwicklern, die bewusst rein auf HTTP setzt – kein Selenium, kein Playwright, kein Puppeteer. Die Gründe sind handfest: Browser-Automatisierung ist langsam, frisst Ressourcen und lässt sich im großen Maßstab nur mühsam betreiben.
Die ehrliche Einordnung dazu: 2026 wird ein reiner HTTP-Ansatz gegen Zillow ohne ausgefeiltes Header- und Fingerprint-Management immer steiniger. Was die Community berichtet, deutet klar in eine Richtung – Browser-Rendering ist bei Zielen wie Zillow zum Normalfall geworden, nicht zur Ausnahme.
Konkrete Best Practices gegen Blockaden bei Zillow
Gehst du den DIY-Weg, hilft Folgendes wirklich – und Folgendes nicht:
- Randomisierte Request-Taktung, die menschliches Browsen imitiert – keine starren Pausen, sondern variable Intervalle mit sitzungsähnlichem Verhalten
- Realistische Header-Konfigurationen mit
Accept-Language, derSec-CH-UA-Header-Familie und sauberen Referer-Ketten – aber Hand aufs Herz: realistische Header sind notwendig, längst nicht hinreichend - Session-Rotation – dieselbe Proxy-/Cookie-Kombination niemals für Hunderte Requests recyceln
- Den richtigen Moment zum Wechsel auf Browser-Rendering erkennen – wenn dein HTTP-only-Ansatz nach 50 Requests 403s zurückgibt, kämpfst du gegen Windmühlen
Trau keinem Artikel, der dir verspricht, ein magischer Header-Block knacke Zillow im Jahr 2026.
Thunderbits Cloud Scraping nimmt dir das alles automatisch ab – mit rotierender Infrastruktur über USA, Europa und Asien, mit Rendering und Anti-Bot-Handling –, sodass du dir die ganze Proxy-Konfiguration sparst. Die Frage ist letztlich, wo der operative Aufwand landet.
Zillow-Scraping mit KI ausprobieren
Best Practices, um dein Zillow-Scraper-GitHub-Setup zukunftssicher zu machen
Für alle, die sich trotzdem für den GitHub-/DIY-Weg entscheiden, hier die Praktiken, die Scraper, die monatelang durchhalten, von solchen trennen, die schon nach Tagen auseinanderfallen.
Selektoren von fragilen Klassennamen entkoppeln
Hängt ein Repo an Zillows automatisch generierten CSS-Klassennamen, ist das ein Alarmsignal. Diese Namen wechseln ständig – mitunter im Wochentakt. Besser:
- Elemente über
aria-label,data-*-Attribute oder nahe Überschriftstexte ansteuern - Wo es geht, auf Selektoren setzen, die sich am Textinhalt orientieren
- JSON-first-Extraktion dem HTML-Parsing vorziehen, wenn Zillow strukturierte Daten direkt im Seitenquelltext mitliefert
Automatisierte Health Checks einbauen
Behandle Zillow-Scraping wie Produktionsmonitoring, nicht wie ein Wegwerf-Script. Setz einen Cronjob oder eine GitHub Action auf, die:
- Deinen Scraper täglich gegen ein bekanntes Listing laufen lässt
- Das Ausgabeschema prüft (sind alle erwarteten Felder da und nicht leer?)
- Alarm schlägt, sobald die Ausgabe fehlerhaft oder leer ist
So bemerkst du einen Bruch binnen 24 Stunden statt erst nach Wochen.
Abhängigkeitsversionen fest pinnen und virtuelle Umgebungen nutzen
Pinne deine Python- oder Node-Abhängigkeiten konsequent auf konkrete Versionen. Arbeite mit virtuellen Umgebungen oder Docker-Containern. Die älteren Repos in diesem Audit führen vor, wie schnell Installationsprobleme entstehen – kaputte Abhängigkeiten sind häufig das Erste, was scheitert, noch ehe Zillows Anti-Bot-Stack ins Spiel kommt.
Scrape-Volumen konservativ halten
Diese Schwelle von rund 100 Requests ist kein Naturgesetz, aber eine glaubwürdige Erinnerung daran, dass Volumen das Verhalten eines Scrapers verändert, der im Test noch tadellos aussah. Verteile deine Requests auf mehrere Sessions. Setz auf randomisierte Pausen. Und versuch bloß nicht, 10.000 Listings in einem einzigen Durchlauf abzugreifen.
Wissen, wann DIY den Aufwand nicht mehr wert ist
Wenn du mehr Zeit in die Wartung deines Scrapers steckst als in die Auswertung der Daten, hat sich die Rechnung gedreht. Das ist kein Versagen – es ist das Signal, über eine gemanagte Lösung nachzudenken.
Zillow Scraper GitHub (DIY) vs. No-Code-Tools: eine ehrliche Entscheidungs-Matrix
Die Zielgruppe für „zillow scraper github“ zerfällt sauber in zwei Lager: Entwickler, die den Code besitzen wollen, und Immobilienprofis, die die Daten schlicht in einer Tabelle brauchen. Beides ist völlig legitim. So sehen die Abwägungen in der Praxis aus.
Vergleichstabelle nebeneinander
| Kriterium | GitHub-Scraper (Python) | No-Code-Tool (z. B. Thunderbit) |
|---|---|---|
| Einrichtungszeit | 30–120 Min. (Umgebung, Abhängigkeiten, Proxys) | ca. 2 Min. (Erweiterung installieren, auf Scrape klicken) |
| Wartung | Laufend – bricht, wenn Zillow etwas ändert | Keine – KI passt sich automatisch an das Seitenlayout an |
| Anti-Bot-Handling | Manuell (Proxys, Header, Verzögerungen) | Integriert (Cloud Scraping, rotierende Infrastruktur) |
| Datenfelder | Individuell – was immer du codierst | KI-vorgeschlagen oder vorlagenbasiert |
| Exportoptionen | CSV/JSON per Code | Excel, Google Sheets, Airtable, Notion – kostenlos |
| Kosten | Kostenloser Code + Proxy-Kosten ($3.50–$8/GB für Residential Proxies) | Kostenloser Tarif verfügbar; darüber kreditbasiert |
| Anpassungspotenzial | Unbegrenzt (du besitzt den Code) | Hoch (Field-AI-Prompts, Subpage-Scraping), aber begrenzt |
Der Realitätscheck bei Proxy-Kosten
Das Argument „das Repo ist kostenlos“ verliert deutlich an Überzeugungskraft, sobald die Proxy-Kosten in die Rechnung wandern. Die aktuellen öffentlichen Preise für Residential Proxies:
| Anbieter | Preisgestaltung (Stand: April 2026) |
|---|---|
| Webshare | $3.50/GB für 1 GB, günstiger bei größeren Paketen |
| Decodo | ca. $3.50/GB nach Verbrauch |
| Bright Data | $8/GB nominal, $4/GB mit aktuellem Promo-Angebot |
| Oxylabs | Ab $8/GB |
Das Repo selbst mag gratis sein – ein proxy-gestützter Zillow-Workflow ist es in aller Regel nicht.
Wann man ein GitHub-Repo wählen sollte
- Du schreibst und wartest Code mit Freude
- Du brauchst sehr spezielle Anpassungen (eigene Datenumwandlungen, Andocken an eine proprietäre Pipeline)
- Du hast die Zeit und das technische Können, Brüche selbst zu reparieren
- Du bist bereit, dich um Proxy-Infrastruktur zu kümmern
Wann Thunderbit die bessere Wahl ist
- Du brauchst heute verlässliche Daten, ohne Setup und ohne Wartung
- Du bist Makler, Investor oder Teil eines Ops-Teams – und kein Entwickler
- Du willst direkt nach Google Sheets, Airtable oder Notion exportieren, ohne Exportcode zu schreiben
- Du willst Subpage-Scraping (Anreicherung von Listings mit Detaildaten) ohne zusätzliche Konfiguration
- Du willst geplantes Scraping in ganz normaler Sprache beschreiben
Thunderbit für Zillow-Scraping installieren
Schritt für Schritt: Zillow mit Thunderbit scrapen (ohne GitHub)
Der No-Code-Weg fühlt sich völlig anders an als der GitHub-Setup-Marathon.
Schritt 1: Thunderbit Chrome-Erweiterung installieren
Geh in den Chrome Web Store, installiere Thunderbit und registriere dich. Einen kostenlosen Tarif gibt es.
Schritt 2: Zu Zillow navigieren und Thunderbit öffnen
Ruf eine beliebige Zillow-Suchergebnisseite auf – etwa Häuser zum Verkauf in einer bestimmten Postleitzahl. Klick in der Browser-Symbolleiste auf das Thunderbit-Symbol.
Schritt 3: Die Zillow-Instant-Scraper-Vorlage verwenden oder KI-Felder vorschlagen lassen
Thunderbit bringt eine vorgefertigte Zillow-Vorlage mit – keine Konfiguration, ein Klick genügt. Sie deckt die Standardfelder ab: Adresse, Preis, Zimmer, Bäder, Quadratfuß, Maklername, Maklertelefon und Angebots-URL.
Alternativ klickst du auf „KI-Felder vorschlagen“, dann liest die KI die Seite aus und schlägt dir die Spalten vor. Bei mir erkennt sie typischerweise 20+ Felder, Zestimate inklusive.
Schritt 4: Auf „Scrape“ klicken und Ergebnisse prüfen
Klick auf „Scrape“. Thunderbit erledigt Pagination, Anti-Bot-Handling und Datenstrukturierung von selbst. Heraus kommt eine strukturierte Ergebnistabelle – keine 403-Fehler, keine leeren Felder, keine Proxy-Konfiguration.
Schritt 5: Mit Unterseitendaten anreichern (optional)
Klick auf „Scrape Subpages“, damit Thunderbit jede Detailseite des Listings ansteuert und zusätzliche Felder zieht: Preisverlauf, Steuerunterlagen, Grundstücksgröße, Schulbewertungen. In einem GitHub-Setup wäre das ein komplexer zweiter Durchlauf mit eigener Selektorlogik und eigenem Anti-Bot-Handling. Hier reicht ein Klick.
Schritt 6: Deine Daten kostenlos exportieren
Exportiere nach Excel, Google Sheets, Airtable oder Notion – alles gratis. Oder lade als CSV beziehungsweise JSON herunter, falls dir das lieber ist. Exportcode brauchst du keinen.
Das hebt sich deutlich von der GitHub-User-Journey ab, die meist mit dem Aufsetzen der Umgebung beginnt und im Troubleshooting von 403s endet.
Von CSV zu Insight: Was du mit deinen Zillow-Daten wirklich machen solltest
Die meisten Guides hören bei „hier ist deine CSV“ auf. Dabei fängt die eigentliche Arbeit genau dort erst an.
Scraping ist Schritt eins. Der Rest kommt jetzt.
Schritt 1: Scrape — Listing-Daten sammeln
Die Kernfelder aus den Suchergebnissen: Preis, Zimmer, Bäder, Quadratfuß, Adresse, Zestimate, Angebotsstatus, Tage am Markt, Angebots-URL.
Schritt 2: Anreichern — Detaildaten über Unterseiten-Scraping ziehen
Zusätzliche Felder aus den Objekt-Detailseiten: Preisverlauf, Steuerunterlagen, Grundstücksgröße, HOA-Gebühren, Schulbewertungen, Maklerkontakte. Thunderbits Unterseiten-Scraping erledigt das per Klick. In einem GitHub-Setup bräuchtest du einen separaten Durchlauf mit eigenen Selektoren und eigener Anti-Bot-Logik.
Schritt 3: Exportieren — in deine bevorzugte Plattform senden
- Google Sheets für schnelle Analyse und Freigabe
- Airtable für ein Mini-CRM oder Deal-Tracking
- Notion für ein Team-Dashboard
- CSV/JSON für eigene Pipelines
Schritt 4: Überwachen — wiederkehrende Scrapes planen
Genau das markieren mehrere Forum-Threads als ungelöstes Problem. Du willst eben nicht nur die Daten von heute – du willst Preisrückgänge, Statuswechsel (aktiv → pending → verkauft) und neue Listings erfassen, sobald sie auftauchen.
Thunderbits geplanter Scraper lässt dich Intervalle in normaler Sprache beschreiben (zum Beispiel „jeden Dienstag und Freitag um 8 Uhr“). Bei einem GitHub-Setup müsstest du den Cronjob selbst bauen, die Authentifizierung persistent halten und die Fehlerbehandlung managen.
Schritt 5: Handeln — nach Deals filtern und Outreach-Workflows speisen
Hier werden aus Daten Entscheidungen:
- Für Investoren: nach Preisrückgängen >5 % in 30 Tagen, Tagen am Markt >90, Preis unter Zestimate filtern
- Für Makler: neue Listings markieren, die zu Käuferkriterien passen, plus abgelaufene/zurückgezogene Listings fürs Prospecting
- Für Forscher: Trends bei Preis pro Quadratfuß, Verhältnis von Verkaufs- zu Angebotspreis und Bestandsdynamik berechnen
Praxisbeispiel: Ein Investor verfolgt 200 Listings in 3 Postleitzahlen
So sehen die Datenfelder je Anwendungsfall aus:
| Datenfeld | Investing | Agent Leads | Marktforschung |
|---|---|---|---|
| Preis | ✅ Kern | ✅ | ✅ |
| Zestimate | ✅ Kern (Gap-Analyse) | ✅ | |
| Preisverlauf | ✅ Kern (Trend-Erkennung) | ✅ | |
| Tage am Markt | ✅ Kern (Motivationssignal) | ✅ | ✅ |
| Steuerlich veranlagter Wert | ✅ (Valuation-Abgleich) | ✅ | |
| Angebotsstatus | ✅ | ✅ Kern | ✅ |
| Angebotsdatum | ✅ | ✅ | |
| Name/Telefon des Maklers | ✅ Kern | ||
| Preis pro Quadratfuß | ✅ | ✅ Kern | |
| Verkaufspreis vs. Angebotspreis | ✅ Kern |
Der Investor richtet einen wöchentlichen Scrape über drei Postleitzahlen ein, exportiert nach Google Sheets und hebt Preisrückgänge sowie DOM-Ausreißer per bedingter Formatierung hervor. Der Makler exportiert nach Airtable und baut sich daraus eine Prospecting-Pipeline. Der Forscher kippt alles in eine Tabelle für die Trendanalyse. Derselbe Scraping-Schritt, drei völlig verschiedene Workflows.
Rechtliche und ethische Aspekte beim Scraping von Zillow
Kurz, aber unverzichtbar.
Zillows Nutzungsbedingungen untersagen automatisierte Abfragen ausdrücklich – Screen Scraping, Crawler, Spider und das Umgehen CAPTCHA-ähnlicher Schutzmaßnahmen inklusive. Zillows robots.txt sperrt breite Pfade, darunter /api/, /homes/ und URLs mit Query-State.
Gleichzeitig lässt sich das US-Recht zum Web Scraping nicht auf „Scraping ist immer illegal“ verkürzen. Die Linie der hiQ-vs.-LinkedIn-Fälle ist für öffentlich zugängliche Daten unter dem CFAA einschlägig. Eine frische Zusammenfassung vom April 2026 von Haynes Boone hält fest, dass der Ninth Circuit LinkedINs Versuch, das Scraping öffentlicher Mitgliederprofile zu blockieren, erneut abgewiesen hat. Das räumt aber weder separate Vertrags-, Datenschutz- noch Anti-Umgehungs-Argumente aus dem Weg und macht Zillows ToS nicht hinfällig.
Was heißt das für dich?
- Das Scraping öffentlicher Seiten kann unter dem CFAA auf festerem Boden stehen, als manche Website-Betreiber behaupten
- Zillow untersagt es vertraglich trotzdem
- Wer technische Schutzmaßnahmen umgeht, erhöht das rechtliche Risiko
- Bei kommerziellen oder hochvolumigen Anwendungsfällen: juristischen Rat einholen
- Und unabhängig von der Rechtslage gilt immer: verantwortungsvoll scrapen – Rate Limits respektieren, Server nicht überlasten, keine personenbezogenen Daten für Spam missbrauchen
Das richtige Tool für deinen Zillow-Workflow wählen
Die Zillow-Scraper-GitHub-Landschaft 2026 ist dünner, als sie auf den ersten Blick wirkt. Die meisten sichtbaren Repos sind veraltet, fragil oder kaputt. Eine kleine Handvoll neuerer Repos – allen voran pyzill – läuft noch, aber nur mit laufender Proxy- und Anti-Bot-Wartung.
Die eigentliche Entscheidung ist nicht Open Source gegen Closed Source. Es geht um Kontrolle gegen operativen Aufwand.
- Willst du volle Kontrolle und wartest gern Scraper, sind GitHub-Repos mächtig – kalkuliere aber Zeit für Proxy-Management, Selektor-Updates und Health Monitoring ein.
- Willst du heute verlässliche Daten ohne Pflegeaufwand, bringt dich Thunderbits Zillow-Vorlage in Minuten von der Suche zur fertigen Tabelle. Die KI liest die Seitenstruktur jedes Mal frisch ein und verlässt sich nie auf hart codierte Selektoren, die irgendwann brechen.
Beide Wege sind legitim.
Das Schlimmste ist, Stunden in den Aufbau eines GitHub-Scrapers zu stecken – nur um dann festzustellen, dass er schon letzten Monat ausgestiegen ist und niemand die README aktualisiert hat.
Willst du den No-Code-Weg in Aktion erleben, teste Thunderbits kostenlosen Tarif – scrape Zillow-Listings in etwa zwei Klicks und exportiere in die Plattform, die dein Team ohnehin schon nutzt. Lieber erst den Ablauf ansehen? Der Thunderbit-YouTube-Kanal hat Schritt-für-Schritt-Videos.
Thunderbit für Zillow-Scraping ausprobieren Get Started Free
FAQs
Gibt es 2026 einen funktionierenden Zillow-Scraper auf GitHub?
Ein paar Repos sind teilweise funktionsfähig – am ehesten johnbalvin/pyzill, das weiterhin Daten zurückgibt, dafür aber rotierende Residential Proxies und ständiges Nachjustieren verlangt. Die Mehrheit der Repos mit vielen Stars (darunter ChrisMuir/Zillow mit 170 Stars und scrapehero/zillow_real_estate mit 152 Stars) ist wegen Zillows Anti-Bot-Änderungen und DOM-Updates kaputt. Den aktuellen Status findest du in der Audit-Tabelle weiter oben.
Kann Zillow GitHub-Scraper erkennen und blockieren?
Ja. Zillow setzt IP-Blocking, TLS-Fingerprinting, JavaScript-Challenges, CAPTCHAs und Rate-Limiting ein. In Tests lieferten selbst einfache HTTP-Requests mit Chrome-ähnlichen Headern ein 403 von CloudFront. GitHub-Scraper ohne passende Anti-Detection-Maßnahmen – Residential Proxies, realistische Header, Browser-Rendering – fliegen schnell auf, oft schon innerhalb von 100 Requests.
Welche Daten kann man von Zillow scrapen?
Typische Felder sind Preis, Adresse, Zimmer, Bäder, Quadratfuß, Zestimate, Angebotsstatus, Tage am Markt, Angebots-URL und Maklerkontakte. Mit Detailseiten-Scraping kommen Preisverlauf, Steuerunterlagen, Grundstücksgröße, HOA-Gebühren und Schulbewertungen dazu. Welche Felder genau drin sind, hängt von den Fähigkeiten deines Scrapers ab – und davon, ob du Suchergebnisse oder einzelne Objektseiten abgreifst.
Ist das Scraping von Zillow legal?
Das ist eine differenzierte Frage. Das Scraping öffentlich zugänglicher Daten steht nach der hiQ-vs.-LinkedIn-Rechtsprechung auf stärkerem Fundament, aber Zillows Nutzungsbedingungen verbieten automatisierten Zugriff ausdrücklich. Das Umgehen technischer Barrieren (CAPTCHAs, Rate Limits) treibt das rechtliche Risiko zusätzlich nach oben. Für private Recherche ist das Risiko meist gering. Für kommerzielle oder hochvolumige Anwendungsfälle solltest du juristischen Rat einholen. Und scrape grundsätzlich verantwortungsvoll.
Wie scrapt Thunderbit Zillow, ohne kaputtzugehen?
Thunderbit nutzt KI, um die Seitenstruktur bei jedem Lauf frisch auszulesen – statt sich auf hart codierte CSS-Selektoren oder XPaths zu verlassen, die beim nächsten Frontend-Update von Zillow brechen. Dazu gibt es eine vorgefertigte Zillow-Instant-Scraper-Vorlage für die Extraktion mit einem Klick. Das Cloud Scraping übernimmt das Anti-Bot-Handling automatisch mit rotierender Infrastruktur, sodass du keine Proxys konfigurieren und kein Browser-Rendering managen musst. Ändert Zillow das Layout, passt sich die KI an – ein Repo-Update ist nicht nötig.
Mehr erfahren
