Die Herausforderung
Dein Team launcht ein Immobilien-Listing-Produkt. Es funktioniert drei Wochen lang einwandfrei. Dann ändert Zillow sein DOM, Rightmove verschärft seine Bot-Checks und dein Scraper fällt an einem einzigen Wochenende bei vier von sechs Quellen aus.
Die Aggregation von Immobiliendaten hat ein spezifisches Problem, das Preisüberwachung und SERP-Tracking nicht teilen. Du ziehst keine strukturierten Daten aus einer sauberen API. Du fügst Inserate von Portalen zusammen, die jeweils unterschiedliche Bot-Detection-Stacks, Layouts, Regionen und Update-Zyklen nutzen. Zillow in den USA, Redfin für MLS-gestützte Daten, Rightmove in Großbritannien, realestate.com.au in Australien, Immobilienscout24 in Deutschland. Jedes Portal ist ein eigenes Engineering-Projekt.
Laut Scrapflys Untersuchung aus dem Jahr 2026 prüfen die führenden Immobilienportale die Signatur auf Verbindungsebene und weisen Clients ab, die keinem echten Browser-Handshake entsprechen. Ihr Rightmove-Leitfaden beschreibt in JavaScript-Variablen eingebettetes JSON, dessen Struktur sich alle paar Monate ändert. Redfin fragmentiert Immobiliendaten über Dutzende von DOM-Nodes, sodass eine einzige Layout-Anpassung die Hälfte deiner Felder auf einmal unbrauchbar machen kann. Zudem liefern regionale Portale unterschiedliche Inhalte basierend auf dem Land des Besuchers aus. Das bedeutet, dass ein US-basierter Scraper auf realestate.com.au keine brauchbaren Daten sieht.
Das Ergebnis: Die Aktualität deiner Listings nimmt unbemerkt ab. Ein Drittel deiner Immobilien veraltet innerhalb von 48 Stunden. Deine Nutzer sehen Preise der Vorwoche. Dein Vertriebsteam gerät unter Druck und deine Support-Tickets steigen montags sprunghaft an, da Portallayouts meist an Wochenenden geändert werden.
Der Ansatz
Die Skalierung der Listing-Aggregation ist kein Scraping-Problem. Es ist ein Zuverlässigkeitsproblem im Gewand eines Scraping-Problems. Warum dein Scraper ständig ausfällt behandelt den allgemeinen Fall. Der Immobiliensektor verstärkt jeden einzelnen Aspekt davon.
Jede Plattform, die dies zuverlässig bewältigt, benötigt vier zusammenspielende Komponenten. Erstens eine Request-Signatur, die echten Browsern entspricht (nicht nur ein Browser-ähnlicher User-Agent-Header, sondern die tatsächlichen Details auf Netzwerkebene, anhand derer Zillow und Rightmove Bots von menschlichen Nutzern unterscheiden). Zweitens standortgenaue Residential-IPs in jedem Zielmarkt, da ein deutscher Aggregator keinen US-Datacenter-Traffic an Immobilienscout24 senden und brauchbare Responses erwarten kann. Drittens Host-basiertes Proxy-Routing, da die Strategie für Zillow bei realestate.com.au fehlschlägt. Viertens Browser-Rendering als Fallback für Portale, die die gesamte Darstellung clientseitig abwickeln.
Ein Beispiel-Request an Rightmove über das Proxy-Produkt von FourA sieht etwa so aus:
curl -X POST https://api.foura.ai/api/proxy/ \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"timeout_ms": 45000,
"request": {
"method": "GET",
"url": "https://www.rightmove.co.uk/properties/123456",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": {"accept": [200]},
"data": {"fail": ["blocked", "access denied"]}
}
}
}'
Das Flag unblocker injiziert ein vollstaendiges Browser-Header-Set zusammen mit der passenden Signatur auf Netzwerkebene. maxTries: 5 weist den Proxy-Manager an, bis zu fuenf IPs durchzuwechseln, bis ein Request erfolgreich ist. Die Validierungsregeln erkennen stumme Blockaden: 200-Responses, die statt der Listungsdaten eine verdeckte Ablehnungsseite liefern. So spiegelt deine Erfolgsquote wider, was tatsaechlich funktioniert hat, nicht was der HTTP-Status behauptet hat.
Portale, die alle Inhalte per JavaScript bereitstellen (Redfin ist das typische Beispiel), erfordern echtes Browser-Rendering. Unser Browser-Produkt verarbeitet diese Faelle mit einer vollstaendigen Browser-Instanz, nicht mit einem leichtgewichtigen Emulator, der direkt bei der ersten Verbindung markiert wird. Bot-Erkennung basiert seit 2026 auf Verhaltensmustern, und alles unterhalb eines echten Browsers faellt zunehmend auf.
Ergebnisse
Was passiert, wenn ein Immobilien-Aggregator von einem eigenen Scraping-Stack auf einen API-First-Ansatz umstellt? Die Muster, die wir im praktischen Betrieb sehen (illustratives Szenario basierend auf Branchen-Benchmarks):
- Aktualitaet der Eintraege verbessert sich fuer aktive Maerkte von "innerhalb von 48 Stunden aktualisiert" auf "innerhalb von 2 Stunden aktualisiert"
- Engineering-Aufwand fuer die Scraper-Wartung sinkt um 70%. Ein Entwickler in Rotation statt eines fest zugeordneten Teams
- Portalabdeckung waechst von 6 auf ueber 20 Websites, ohne dass die Infrastruktur proportional mitwachsen muss
- Rate stummer Blockaden sinkt auf geschuetzten Portalen unter 3%, sobald Validierungsregeln verdeckte Blocks abfangen
Ein wiederkehrendes Muster bei Teams auf unserer Plattform: Sobald die Zuverlaessigkeitsschicht geteilt wird, ist die Anbindung eines neuen Marktes nur noch eine Konfigurationsaenderung statt eines ganzen Sprints. Die Kernfragen verschieben sich von "Warum ist das schon wieder kaputt" zu "Welches Portal binden wir als naechstes an".
Die ehrliche Einschraenkung: Immobilienportale, die eingeloggte Sitzungen verlangen (einige MLS-Systeme, bestimmte Ansichten nur fuer Makler), erfordern Kontoverwaltung zusaetzlich zur Request-Infrastruktur. Das ist ein separates Problem, das wir nicht loesen. Traue niemandem, der das Gegenteil behauptet, ohne das Wie zu erklaeren.
Fazit
Die Immobilienbranche ist eine der wenigen Branchen, in denen veraltete Daten kein blosses Aergernis sind. Sie sind ein Produktfehler. Ein eine Woche alter Preis auf einer Fashion-Website ist leicht peinlich. Ein eine Woche altes Inserat in einem heiss umkaempften Markt bedeutet, dass dein Nutzer gerade ein Haus anfragt, das am Dienstag verkauft wurde.
Gewinnen werden hier jedoch nicht die Teams mit den meisten Quellen. Es sind jene, die aufgehoert haben, die Proxy- und Request-Infrastruktur fuer jedes neue Portal neu zu bauen. Sobald diese Schicht steht, beginnt die eigentliche Arbeit: Datenqualitaet, Aktualitaets-SLAs, Deduplizierung ueber Portale hinweg, Preistrendanalysen. Das ist das eigentliche Produkt. Alles darunter sollte einfach laufen.