Zillow Scraper GitHub: Was 2026 funktioniert – und was kaputtgeht

Wenn du jetzt nach „zillow scraper github“ suchst, findest du . Klingt erst mal vielversprechend – bis dir auffällt, dass seit über einem Jahr nicht mehr aktualisiert wurden.

Ich habe viel Zeit damit verbracht, diese Repos zu prüfen, sie mit Live-Zillow-Seiten zu testen und die GitHub-Issues sowie Reddit-Threads zu lesen, in denen Entwickler ihrem Frust darüber Luft machen, was diesmal wieder kaputtgegangen ist. Das Muster ist immer dasselbe: Ein Repo bekommt mit dem ersten funktionierenden Release viele Stars, stirbt dann aber still und leise, sobald Zillow sein DOM ändert, den Anti-Bot-Schutz verschärft oder einen internen API-Endpunkt abschaltet. Ein frustrierter Entwickler auf Reddit brachte es perfekt auf den Punkt: „scraping projects need to be on constant maintenance due to changes on the page or api.“ Dieser Artikel ist genau die Prüfung, die ich mir vor meinem ersten Zillow-Scraper-Repo gewünscht hätte – ein ehrlicher, aktueller Blick darauf, was 2026 wirklich läuft, was kaputtgeht und warum, und wann es sinnvoller ist, den GitHub-Kaninchenbau ganz zu überspringen und stattdessen ein Tool wie zu nutzen.

Was ist ein Zillow Scraper GitHub-Projekt – und wer braucht so etwas?

Ein „Zillow-Scraper“ ist jedes Script oder Tool, das automatisch Immobiliendaten von der Zillow-Website sammelt – also Dinge wie Preis, Adresse, Zimmer, Bäder, Wohnfläche, Zestimate, Angebotsstatus, Tage am Markt und manchmal tiefere Detaildaten von Unterseiten wie Preisverlauf oder Steuerunterlagen. Viele suchen gezielt auf GitHub, weil sie etwas Kostenloses, Open-Source-freundliches und Anpassbares wollen. Repo forken, Felder anpassen, die Ausgabe in die eigene Pipeline leiten. In der Theorie das Beste aus beiden Welten.

Die Zielgruppen sind ziemlich klar voneinander getrennt:

• Immobilieninvestoren verfolgen Deals über Postleitzahlen hinweg – sie wollen Preisrückgänge, Zestimate-Abweichungen und Tage am Markt, um Chancen herauszufiltern
• Makler bauen Prospecting-Listen auf – sie brauchen Angebots-URLs, Kontaktdaten von Maklern und Statusänderungen von Listings
• Marktforscher und Analysten ziehen strukturierte Vergleichsdaten – Adresse, Preis pro Quadratfuß, Verkaufspreis vs. Angebotspreis, Bestandszahlen
• Ops-Teams überwachen Preise oder Bestände über verschiedene Märkte in regelmäßigen Abständen

Der gemeinsame Nenner: Alle wollen strukturierte, wiederholbare Daten – keinen einmaligen Copy-Paste-Job. Genau das macht Scraping attraktiv. Und genau das macht den Wartungsaufwand so schmerzhaft, wenn ein Repo nicht mehr funktioniert.

Der Zillow-Scraper-GitHub-Audit 2026: Was wirklich noch läuft

Ich habe GitHub nach den Repos mit den meisten Stars und Forks durchsucht, die letzten Commit-Daten geprüft, offene Issues gelesen und die Projekte gegen Live-Zillow-Seiten getestet. Die Methode ist simpel: Wenn ein Repo as of April 2026 korrekte Listing-Daten aus Zillow-Suchergebnissen oder Detailseiten zurückgibt, bekommt es das Label „working“. Wenn es läuft, aber unvollständige Daten liefert oder nach ein paar Seiten blockiert wird, ist es „partially working“. Wenn es komplett scheitert oder der Maintainer es selbst für tot erklärt hat, ist es „broken“.

Die harte Realität: Die meisten Repos, die vor 12–18 Monaten vielversprechend aussahen, sind inzwischen still und leise kaputt.

Kuratierte Vergleichstabelle: Top-Zillow-Scraper-GitHub-Repos

Das Muster ist eindeutig: Das GitHub-Ökosystem enthält zwar weiterhin lebenden Code, aber die meisten sichtbaren Repos sind Tutorials, historische Artefakte oder dünne Wrapper um einen proxy-abhängigen Workflow.

Was „working“, „broken“ und „partially working“ bedeutet

Ich möchte diese Labels bewusst präzise halten, weil sie wichtiger sind als die Star-Zahlen:

• Working: Liefert zum Testzeitpunkt erfolgreich korrekte Listing-Daten aus Zillow-Suchergebnissen und/oder Detailseiten, ohne dass der Maintainer das Projekt als tot markiert hat
• Partially working: Läuft, liefert aber unvollständige Daten, wird nach wenigen Seiten blockiert oder funktioniert nur auf bestimmten Seitentypen – meist mit Proxy-Infrastruktur und laufendem Feintuning
• Broken: Liefert keine Daten, wirft Fehler oder wurde vom Maintainer bzw. der Community ausdrücklich als nicht funktionsfähig markiert

Ein Repo mit 170 Stars und dem Status „broken“ ist schlechter als ein Repo mit 10 Stars, das tatsächlich Daten liefert. Popularität ist historischer Kontext, kein Qualitätsmerkmal.

Warum Zillow-Scraper-GitHub-Projekte kaputtgehen: die 5 häufigsten Fehlerursachen

Zu verstehen, warum Zillow-Scraper kaputtgehen, spart mehr Zeit als jede README. Wer die Ursachen kennt, kann entweder einen robusteren Scraper bauen oder entscheiden, dass sich der Wartungsaufwand nicht lohnt.

1. DOM-Umbauten (Zillows React-Frontend)

Zillows Frontend basiert auf React und ändert sich häufig. Klassennamen, Komponentenstruktur und Datenattribute verschieben sich ohne Vorwarnung. Ein Scraper, der heute div.list-card-price anspricht, kann morgen feststellen, dass diese Klasse verschwunden ist. Wie eine anmerkt, variieren auf Zillow „the class names vary from page to page“.

Die Folge: Dein Script läuft, gibt aber leere Felder zurück – und du merkst es erst, wenn du eine Woche lang nur Nullen gesammelt hast.

2. Änderungen an internen API- und GraphQL-Endpunkten

Die klügeren Repos umgehen HTML komplett und sprechen direkt Zillows interne GraphQL- oder REST-APIs an. Das Repo nutzt zum Beispiel ausdrücklich Zillows interne API und teilt Kartenbegrenzungen rekursiv auf, um Ergebnislimits zu umgehen. Ein cleveres Design – aber Zillow strukturiert diese Endpunkte regelmäßig um. Dann liefert dein Scraper 404s oder leeres JSON, ohne Fehlermeldung.

Das ist eine subtilere Form des Scheiterns. Der Code ist in Ordnung. Nur das Ziel hat sich bewegt.

3. Anti-Bot- und CAPTCHA-Eskalation

Zillow hat die Bot-Erkennung in den letzten Jahren deutlich verschärft. In meinen eigenen Tests im April 2026 lieferten einfache requests.get()-Aufrufe an sowohl zillow.com als auch zillow.com/homes/Chicago,-IL_rb/ – selbst mit einem Chrome-ähnlichen User-Agent und Accept-Language-Header. Auch die Community meldet Ähnliches: Ein Nutzer schrieb, sein reverse-engineerter API-Flow habe nach etwa 403 zurückgegeben.

Scraper, die bei geringem Volumen problemlos laufen, können plötzlich scheitern, sobald sie skaliert werden. Das ist eine fiese Überraschung, wenn du 200 Listings über 3 Postleitzahlen überwachen willst.

4. Login-Schranken bei Premium-Daten

Bestimmte Datenpunkte – Zestimate-Details, Steuerunterlagen, manche Preisverläufe – sind hinter einer Anmeldung versteckt. Open-Source-Scraper beherrschen Login-Flows nur selten, also bleiben diese Felder leer. Wenn dein Use Case von Preisverlauf oder steuerlich veranlagten Werten abhängt, stößt du schnell an diese Grenze.

5. Abhängigkeiten veralten und Repos werden nicht gepflegt

Die enthalten Installationsprobleme wie No module named 'unicodecsv'. Das dokumentiert manuellen Ärger mit Treiber- und GIS-Abhängigkeiten. Updates von Python-Bibliotheken brechen die Kompatibilität. Repos, die seit mehr als 6 Monaten nicht aktualisiert wurden, scheitern oft schon bei einer frischen Installation, noch bevor Zillows Anti-Bot-Stack überhaupt ins Spiel kommt.

Zillows Anti-Bot-Schutz 2026: Womit du es wirklich zu tun hast

„Einfach Proxys nutzen und Header rotieren“ war 2022 noch brauchbarer Rat. 2026 ist das nicht mehr so.

Mehr als IP-Blocking: TLS-Fingerprinting und JS-Challenges

Zillow blockiert nicht nur IPs. Community-Berichte beschreiben, dass Zillow hinter Cloudflare sitzt und einsetzt, die über simples Rate-Limiting hinausgehen. TLS-Fingerprinting identifiziert Nicht-Browser-Clients über ihren „digitalen Handshake“ – also darüber, wie sie Verschlüsselung aushandeln. Selbst mit einem frischen Proxy kann dein Scraper auffallen, wenn seine TLS-Signatur nicht zu einem echten Chrome-Browser passt.

JavaScript-Challenges kommen als zusätzliche Hürde hinzu. Headless-Browser, die JS nicht vollständig ausführen oder Automatisierungsmarker offenlegen (etwa navigator.webdriver = true), werden erkannt.

Suchseiten vs. Detailseiten von Objekten: unterschiedliche Schutzstufen

Nicht alle Zillow-Seiten sind gleich stark abgesichert. Das unterscheidet ausdrücklich zwischen einem „Fast Mode“, der Detailseiten überspringt, und einem langsameren „Full Mode“, der reichere Daten enthält. Auch Thunderbits trennt das erste Listing-Scraping von „Scrape Subpages“ für die Anreicherung über Detailseiten.

Die praktische Konsequenz: Dein Scraper kann auf Suchergebnissen problemlos funktionieren, aber auf einzelnen Objektseiten scheitern, wo Zillow stärkeren Schutz einsetzt, weil die Daten wertvoller und häufiger gescrapt werden.

Die HTTP-only-Fraktion: Warum manche Entwickler Browser-Automatisierung meiden

Es gibt eine starke Gruppe von Entwicklern, die ausdrücklich HTTP-only-Ansätze wollen – kein Selenium, kein Playwright, kein Puppeteer. Die Gründe sind praktisch: Browser-Automatisierung ist langsam, ressourcenintensiv und schwerer in großem Maßstab zu betreiben.

Die ehrliche Einschätzung: 2026 werden reine HTTP-Ansätze gegen Zillow ohne ausgefeiltes Header- und Fingerprint-Management immer schwieriger. Die Community-Evidenz deutet darauf hin, dass Browser-Rendering bei Zielen wie Zillow zum Standard wird – nicht zur Ausnahme.

Konkrete Best Practices gegen Blockaden bei Zillow

Wenn du den DIY-Weg gehst, hilft Folgendes tatsächlich – und Folgendes nicht:

• Randomisierte Request-Taktung, die menschliches Browsen nachahmt – keine festen Pausen, sondern variable Intervalle mit sitzungsähnlichem Verhalten
• Realistische Header-Konfigurationen inklusive Accept-Language, Sec-CH-UA-Header-Familie und sauberer Referer-Ketten – aber ehrlich gesagt: realistische Header sind notwendig, nicht ausreichend
• Session-Rotation – dieselbe Proxy-/Cookie-Kombination nicht für Hunderte von Requests wiederverwenden
• Wissen, wann auf Browser-Rendering umgestellt werden sollte – wenn dein HTTP-only-Ansatz nach 50 Requests 403s zurückgibt, kämpfst du einen verlorenen Kampf

Glaub keinem Artikel, der behauptet, ein magischer Header-Block löse Zillow 2026.

übernimmt all das automatisch – mit rotierender Infrastruktur über USA/Europa/Asien, Rendering und Anti-Bot-Handling – sodass Nutzer den ganzen Proxy-Konfigurations-Kaninchenbau überspringen. Entscheidend ist, wo der operative Aufwand landet.

Best Practices, um dein Zillow-Scraper-GitHub-Setup zukunftssicher zu machen

Für Leser, die sich für den GitHub-/DIY-Weg entscheiden, hier die Praktiken, die Scraper unterscheiden, die Monate durchhalten, von solchen, die in Tagen kaputtgehen.

Selektoren von fragilen Klassennamen entkoppeln

Wenn ein Repo von Zillows automatisch generierten CSS-Klassennamen abhängt, ist das ein Warnsignal. Diese Namen ändern sich häufig – manchmal wöchentlich. Stattdessen:

• Elemente über aria-label, data-*-Attribute oder nahe Überschriftstexte ansprechen
• Wo möglich, Selektoren auf Basis von Textinhalt verwenden
• JSON-first-Extraktion HTML-Parsing vorziehen, wenn Zillow strukturierte Daten im Seitenquelltext liefert

Automatisierte Health Checks einbauen

Behandle Zillow-Scraping wie Produktionsmonitoring, nicht wie ein einmaliges Script. Richte einen Cronjob oder eine GitHub Action ein, die:

1. Deinen Scraper täglich gegen ein bekanntes Listing laufen lässt
2. Das Ausgabeschema validiert (sind alle erwarteten Felder vorhanden und nicht leer?)
3. Einen Alarm auslöst, wenn die Ausgabe fehlerhaft oder leer ist

So erkennst du Brüche innerhalb von 24 Stunden statt erst nach Wochen.

Abhängigkeitsversionen fest pinnen und virtuelle Umgebungen nutzen

Pinne deine Python- oder Node-Abhängigkeiten immer auf konkrete Versionen. Nutze virtuelle Umgebungen oder Docker-Container. Die älteren Repos in unserem Audit zeigen, wie schnell Installationsprobleme entstehen – kaputte Abhängigkeiten sind oft das Erste, was scheitert, noch bevor Zillows Anti-Bot-Stack überhaupt relevant wird.

Scrape-Volumen konservativ halten

Diese ist nicht universell, aber sie erinnert glaubwürdig daran, dass Volumen das Verhalten eines Scrapers verändert, der im Test noch gut aussah. Verteile deine Requests auf mehrere Sessions. Nutze randomisierte Pausen. Versuch nicht, 10.000 Listings in einem einzigen Lauf zu scrapen.

Wissen, wann DIY den Aufwand nicht mehr wert ist

Wenn du mehr Zeit mit der Wartung deines Scrapers verbringst als mit der Analyse deiner Daten, hat sich die Wirtschaftlichkeitsrechnung gedreht. Das ist kein Scheitern – sondern ein 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“ teilt sich klar in zwei Gruppen: Entwickler, die den Code besitzen wollen, und Immobilienprofis, die die Daten einfach in einer Tabelle brauchen. Beides ist legitim. So sehen die Abwägungen in der Praxis aus.

Vergleichstabelle nebeneinander

Der Realitätscheck bei Proxy-Kosten

Das Argument „kostenloses Repo“ überzeugt deutlich weniger, sobald man die Proxy-Kosten einrechnet. Aktuelle öffentliche Preise für Residential Proxies:

Das Repo mag kostenlos sein, ein proxy-gestützter Zillow-Workflow ist es meist nicht.

Wann man ein GitHub-Repo wählen sollte

• Du schreibst und wartest gern Code
• Du brauchst sehr spezifische Anpassungen (eigene Datenumwandlungen, Integration in eine proprietäre Pipeline)
• Du hast Zeit und technische Fähigkeiten, um Brüche zu beheben
• Du bist bereit, Proxy-Infrastruktur zu verwalten

Wann Thunderbit die bessere Wahl ist

• Du brauchst heute verlässliche Daten ohne Setup oder Wartung
• Du bist Makler, Investor oder Teil eines Ops-Teams – kein Entwickler
• Du willst , ohne Exportcode zu schreiben
• Du willst Subpage-Scraping (Anreicherung von Listings mit Detaildaten) ohne zusätzliche Konfiguration
• Du willst geplantes Scraping in normaler Sprache beschreiben

Schritt für Schritt: Zillow mit Thunderbit scrapen (ohne GitHub)

Der No-Code-Weg sieht völlig anders aus als der GitHub-Setup-Prozess.

Schritt 1: Thunderbit Chrome-Erweiterung installieren

Gehe zum , installiere Thunderbit und registriere dich. Es gibt einen kostenlosen Tarif.

Schritt 2: Zu Zillow navigieren und Thunderbit öffnen

Öffne eine beliebige Zillow-Suchergebnisseite – zum Beispiel Häuser zum Verkauf in einer bestimmten Postleitzahl. Klicke in der Browser-Symbolleiste auf das Thunderbit-Erweiterungssymbol.

Schritt 3: Die Zillow-Instant-Scraper-Vorlage verwenden oder KI-Felder vorschlagen lassen

Thunderbit hat eine – keine Konfiguration nötig, einfach ein Klick. Die Vorlage deckt die Standardfelder ab: Adresse, Preis, Zimmer, Bäder, Quadratfuß, Name des Maklers, Telefon des Maklers und Angebots-URL.

Alternativ klickst du auf „KI-Felder vorschlagen“ und die KI liest die Seite aus und schlägt Spalten vor. In meiner Erfahrung erkennt sie typischerweise , einschließlich Zestimate.

Schritt 4: Auf „Scrape“ klicken und Ergebnisse prüfen

Klicke auf „Scrape“. Thunderbit übernimmt Pagination, Anti-Bot-Handling und Datenstrukturierung automatisch. Du erhältst eine strukturierte Tabelle mit Ergebnissen – keine 403-Fehler, keine leeren Felder, keine Proxy-Konfiguration.

Schritt 5: Mit Unterseitendaten anreichern (optional)

Klicke auf „Scrape Subpages“, damit Thunderbit jede Detailseite des Listings besucht und zusätzliche Felder zieht: Preisverlauf, Steuerunterlagen, Grundstücksgröße, Schulbewertungen. In einem GitHub-Setup wäre das ein komplexer zweiter Scraping-Durchlauf mit eigener Selektorlogik und Anti-Bot-Handling. Hier ist es ein Klick.

Schritt 6: Deine Daten kostenlos exportieren

Exportiere nach Excel, Google Sheets, Airtable oder Notion – alles kostenlos. Oder lade als CSV bzw. JSON herunter, wenn du das bevorzugst. Kein Exportcode nötig.

Das unterscheidet sich deutlich von der GitHub-User-Journey, die meist mit dem Einrichten der Umgebung beginnt und mit dem Troubleshooting von 403s endet.

Von CSV zu Insight: Was du mit deinen Zillow-Daten wirklich machen solltest

Die meisten Guides enden bei „hier ist deine CSV“. Das ist, als würde man jemandem eine Angel in die Hand drücken und weggehen, bevor man erklärt, wie man den Fisch zubereitet.

Scraping ist Schritt eins. Der Rest folgt hier.

Schritt 1: Scrape — Listing-Daten sammeln

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 Objekt-Detailseiten: Preisverlauf, Steuerunterlagen, Grundstücksgröße, HOA-Gebühren, Schulbewertungen, Kontaktdaten des Maklers. Thunderbits Unterseiten-Scraping erledigt das mit einem Klick. In einem GitHub-Setup bräuchtest du einen separaten Scraping-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

Das ist der Schmerzpunkt, den mehrere Forum-Threads als ungelöst markieren. Du willst nicht nur die Daten von heute – du willst Preisrückgänge, Statusänderungen (aktiv → pending → verkauft) und neue Listings erfassen, sobald sie erscheinen.

Thunderbits geplanter Scraper lässt dich Intervalle in normaler Sprache beschreiben (z. B. „jeden Dienstag und Freitag um 8 Uhr“). Für ein GitHub-Setup müsstest du selbst einen Cronjob bauen, Authentifizierung persistent halten und Fehlerbehandlung managen.

Schritt 5: Handeln — nach Deals filtern und Outreach-Workflows speisen

Hier werden Daten zu Entscheidungen:

• Für Investoren: Preisrückgänge >5 % in 30 Tagen, Tage am Markt >90, Preis unter Zestimate filtern
• Für Makler: neue Listings markieren, die Käuferkriterien entsprechen, sowie abgelaufene/zurückgezogene Listings für Prospecting
• Für Forscher: Trends bei Preis pro Quadratfuß, Verhältnis Verkaufspreis zu Angebotspreis, Bestandsdynamik berechnen

Praxisbeispiel: Ein Investor verfolgt 200 Listings in 3 Postleitzahlen

So sehen die Datenfelder je Anwendungsfall aus:

Der Investor richtet einen wöchentlichen Scrape über drei Postleitzahlen ein, exportiert nach Google Sheets und nutzt bedingte Formatierung für Preisrückgänge und DOM-Ausreißer. Der Makler exportiert nach Airtable und baut eine Prospecting-Pipeline. Der Forscher lädt alles in eine Tabelle für Trendanalysen. Gleicher Scraping-Schritt, drei verschiedene Workflows.

Rechtliche und ethische Aspekte beim Scraping von Zillow

Kurz, aber notwendig.

Zillows verbieten ausdrücklich automatisierte Abfragen, einschließlich Screen Scraping, Crawlers, Spiders und das Umgehen CAPTCHA-ähnlicher Schutzmaßnahmen. Zillows sperrt breite Pfade, darunter /api/, /homes/ und URLs mit Query-State.

Gleichzeitig lässt sich das US-Recht zum Web Scraping nicht auf „alles Scraping ist illegal“ reduzieren. Die Linie der hiQ-vs.-LinkedIn-Fälle ist für öffentlich zugängliche Daten unter dem CFAA relevant. Eine von Haynes Boone weist darauf hin, dass der Ninth Circuit erneut LinkedIns Versuch zurückgewiesen hat, das Scraping öffentlicher Mitgliederprofile zu blockieren. Das löscht aber keine separaten Vertrags-, Datenschutz- oder Anti-Umgehungs-Argumente aus und macht Zillows ToS nicht irrelevant.

Was bedeutet das für dich?

• Scraping öffentlicher Seiten kann unter dem CFAA stärkere Argumente haben, als viele Website-Betreiber behaupten
• Zillow verbietet es vertraglich dennoch
• Das Umgehen technischer Schutzmaßnahmen erhöht das rechtliche Risiko
• Bei kommerziellen oder hochvolumigen Anwendungsfällen: juristischen Rat einholen
• Unabhängig von der Rechtslage gilt: 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 aussieht. Die meisten sichtbaren Repos sind veraltet, fragil oder kaputt. Eine kleine Zahl neuerer Repos – insbesondere – funktioniert noch, aber nur mit laufender Proxy- und Anti-Bot-Wartung.

Die eigentliche Entscheidung ist nicht Open Source gegen Closed Source. Es geht um Kontrolle versus operativen Aufwand.

• Wenn du volle Kontrolle willst und gern Scraper wartest, sind GitHub-Repos mächtig – plane aber Zeit für Proxy-Management, Selektor-Updates und Health Monitoring ein.
• Wenn du heute verlässliche Daten ohne Pflege willst, bringt dich in Minuten von der Suche zur Tabelle. Die KI liest die Seitenstruktur jedes Mal frisch ein und verlässt sich nie auf hart codierte Selektoren, die kaputtgehen.

Beide Wege sind legitim.

Das Schlimmste ist, Stunden damit zu verbringen, einen GitHub-Scraper aufzusetzen, nur um dann festzustellen, dass er schon letzten Monat kaputtging und niemand die README aktualisiert hat.

Wenn du den No-Code-Weg in Aktion sehen willst, aus – scrape Zillow-Listings in etwa 2 Klicks und exportiere in die Plattform, die dein Team bereits nutzt. Willst du den Ablauf zuerst ansehen? Der hat Schritt-für-Schritt-Videos.

FAQs

Gibt es 2026 einen funktionierenden Zillow-Scraper auf GitHub?

Einige Repos sind teilweise funktionsfähig – am bemerkenswertesten johnbalvin/pyzill, das weiterhin Daten zurückgibt, aber rotierende Residential Proxies und laufendes Feintuning braucht. 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 oben.

Kann Zillow GitHub-Scraper erkennen und blockieren?

Ja. Zillow nutzt IP-Blocking, TLS-Fingerprinting, JavaScript-Challenges, CAPTCHAs und Rate-Limiting. In Tests lieferten selbst einfache HTTP-Requests mit Chrome-ähnlichen Headern 403 von CloudFront. GitHub-Scraper ohne geeignete Anti-Detection-Maßnahmen – Residential Proxies, realistische Header, Browser-Rendering – werden schnell blockiert, oft 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 Kontaktdaten des Maklers. Mit Detailseiten-Scraping erhältst du zusätzlich Preisverlauf, Steuerunterlagen, Grundstücksgröße, HOA-Gebühren und Schulbewertungen. Die genauen Felder hängen von den Fähigkeiten deines Scrapers und davon ab, ob du Suchergebnisse oder einzelne Objektseiten abgreifst.

Ist das Scraping von Zillow legal?

Das ist differenziert zu betrachten. Das Scraping öffentlich zugänglicher Daten hat nach der hiQ-vs.-LinkedIn-Rechtsprechung eine stärkere rechtliche Grundlage, aber Zillows Nutzungsbedingungen verbieten automatisierten Zugriff ausdrücklich. Das Umgehen technischer Barrieren (CAPTCHAs, Rate Limits) erhöht das rechtliche Risiko zusätzlich. Für private Recherche ist das Risiko meist niedrig. Für kommerzielle oder hochvolumige Anwendungsfälle solltest du juristischen Rat einholen. Scrape grundsätzlich verantwortungsvoll.

Wie scrapt Thunderbit Zillow, ohne kaputtzugehen?

Thunderbit nutzt KI, um die Seitenstruktur bei jedem Lauf frisch auszulesen – es verlässt sich nicht auf hart codierte CSS-Selektoren oder XPaths, die beim Frontend-Update von Zillow brechen. Außerdem gibt es eine vorgefertigte für die Extraktion mit einem Klick. Cloud Scraping übernimmt das Anti-Bot-Handling automatisch mit rotierender Infrastruktur, sodass Nutzer Proxys nicht selbst konfigurieren oder Browser-Rendering managen müssen. Wenn Zillow das Layout ändert, passt sich die KI an – kein Repo-Update nötig.

Mehr erfahren