Die Herausforderung
Dein Team veröffentlicht ein Listings-Produkt. Es funktioniert drei Wochen lang. Dann ändert Zillow sein DOM, Rightmove verschärft seine Bot-Prüfungen, und dein Scraper fällt an einem einzigen Wochenende bei vier von sechs Quellen aus.
Die Aggregation von Immobilien hat ein spezifisches Problem, das Price-Monitoring und SERP-Tracking nicht haben. Du ziehst keine strukturierten Daten aus einer sauberen API. Du stückelst Listings aus Portalen zusammen, die jeweils unterschiedliche Anti-Bot-Stacks, Layouts, Regionen und Update-Zyklen nutzen. Zillow in den USA, Redfin für MLS-Daten, Rightmove in Großbritannien, realestate.com.au in Australien, Immobilienscout24 in Deutschland. Jedes Portal ist ein eigenes Engineering-Projekt.
Laut der Scrapfly-Forschung von 2026 prüfen die Top-Immobilienportale die Signatur auf Verbindungsebene und lehnen Clients ab, die keinen Browser-Grade-Handshake aufweisen. Ihr Rightmove-Guide behandelt in JavaScript-Variablen eingebettetes JSON, das alle paar Monate seine Struktur ändert. Redfin fragmentiert Immobiliendaten über Dutzende von DOM-Nodes, sodass eine einzige Layout-Anpassung die Hälfte deiner Felder auf einmal löschen kann. Regionale Portale liefern zudem unterschiedliche Inhalte basierend auf dem Land des Besuchers. Ein Scraper aus den USA sieht auf realestate.com.au also nichts Brauchbares.
Das Ergebnis: Die Aktualität deiner Listings nimmt stillschweigend ab. Ein Drittel deiner Immobilien veraltet innerhalb von 48 Stunden. Deine Nutzer sehen Preise von letzter Woche. Dein Sales-Team stößt auf Widerstand, und deine Support-Tickets steigen montags rasant an, da sich Portal-Layouts oft an Wochenenden ändern.
Der Ansatz
Listings im großen Maßstab zu aggregieren, ist kein Scraping-Problem. Es ist ein Zuverlässigkeitsproblem in Verkleidung. Warum dein Scraper ständig ausfällt behandelt den allgemeinen Fall. Die Immobilienbranche verstärkt jeden Teil davon.
Jede Plattform, die das gut meistert, benötigt vier zusammenspielende Dinge. Erstens eine Request-Signatur, die echten Browsern entspricht (nicht nur ein User-Agent-String im Browser-Format, sondern die tatsächlichen Details auf Wire-Ebene, die Zillow und Rightmove nutzen, um Bots von Menschen zu trennen). Zweitens geo-genaue Residential-IPs in jedem Zielmarkt, denn ein deutscher Aggregator kann keinen US-Datacenter-Traffic an Immobilienscout24 senden und nützliche Responses erwarten. Drittens Proxy-Routing pro Host, da die Strategie für Zillow bei realestate.com.au fehlschlägt. Viertens Browser-Rendering als Fallback für Portale, die alles clientseitig pushen.
Ein Beispiel-Request gegen Rightmove über das Proxy-Produkt von FourA sieht in 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 unblocker Flag injiziert ein vollständiges Browser-Header-Set zusammen mit der passenden Wire-Level-Signatur. maxTries: 5 weist den Proxy-Manager an, bis zu fünf IPs durchzuwechseln, bis eine erfolgreich ist. Die Validierungsregeln fangen stille Blockaden ab: die 200 Responses, die eine Soft-Block-Seite anstelle von Listing-Daten zurückgeben. Deine Erfolgsquote spiegelt also wider, was tatsächlich funktioniert hat, und nicht, was der HTTP-Status behauptet.
Portale, die alles über JavaScript ausliefern (Redfin ist das offensichtliche Beispiel), benötigen echtes Browser-Rendering. Unser Browser-Produkt verarbeitet diese mit einer vollständigen Browser-Instanz, nicht mit einem leichtgewichtigen Emulator, der bei der ersten Verbindung markiert wird. Bot-Erkennung wurde 2026 verhaltensbasiert, und alles, was weniger als ein echter Browser ist, wird zunehmend sichtbar.
Ergebnisse
Was passiert, wenn ein Immobilien-Aggregator von einem benutzerdefinierten Scraping-Stack zu einem API-First-Ansatz wechselt? Die Muster, die wir in realen Betrieben sehen (illustratives Szenario basierend auf Branchen-Benchmarks):
- Listings-Aktualität verbessert sich für aktive Märkte von "innerhalb von 48 Stunden aktualisiert" auf "innerhalb von 2 Stunden aktualisiert"
- Engineering-Zeit für die Scraper-Wartung sinkt um 70%. Ein rotierender Engineer anstelle eines dedizierten Teams
- Portal-Abdeckung wächst von 6 auf über 20 Seiten ohne proportionalen Anstieg der Infrastruktur
- Stille Blockierraten fallen bei geschützten Portalen unter 3%, sobald Validierungsregeln Soft-Blocks abfangen
Ein Muster von Teams, die unsere Plattform nutzen: Sobald der Reliability-Layer gemeinsam genutzt wird, wird das Hinzufügen eines neuen Marktes zu einer Konfigurationsänderung statt zu einem Sprint. Die interessanten Fragen verlagern sich von "Warum ist das schon wieder kaputtgegangen" zu "Welches Portal sollten wir als Nächstes hinzufügen".
Die ehrliche Einschränkung: Immobilienportale, die eingeloggte Sessions erfordern (einige MLS-Systeme, bestimmte Makler-Ansichten), benötigen Account-Management auf der Request-Infrastruktur. Das ist ein separates Problem, das wir nicht lösen. Du solltest niemandem vertrauen, der behauptet, dies zu tun, ohne zu erklären, wie.
Wichtigste Erkenntnis
Die Immobilienbranche ist eine der wenigen Branchen, in denen veraltete Daten kein Ärgernis sind. Sie sind ein Produktversagen. Ein eine Woche alter Preis auf einer Mode-Seite ist eine leichte Peinlichkeit. Ein eine Woche altes Listing in einem heißen Markt bedeutet, dass dein Nutzer gerade ein Haus angefragt hat, das am Dienstag verkauft wurde.
Aber die Teams, die hier gewinnen, sind nicht die mit den meisten Quellen. Es sind die, die aufgehört haben, für jedes neue Portal dasselbe Proxy- und Anti-Bot-Plumbing neu zu bauen. Sobald diese Schicht geteilt wird, beginnt die interessante Arbeit: Datenqualität, Aktualitäts-SLAs, portalübergreifende Deduplizierung, Preistrendanalysen. Das ist das Produkt. Alles darunter sollte einfach funktionieren.