Wyzwanie
Twój zespół wdraża produkt z ogłoszeniami. Działa przez trzy tygodnie. Potem Zillow zmienia strukturę DOM, Rightmove zaostrza weryfikację botów, a Twój scraper przestaje działać na czterech z sześciu źródeł w ciągu jednego weekendu.
Agregacja ofert nieruchomości ma specyficzny problem, którego nie mają monitoring cen czy śledzenie SERP. Nie pobierasz ustrukturyzowanych danych z jednego czytelnego API. Łączysz ogłoszenia z portali, z których każdy korzysta z innych systemów wykrywania botów, innych układów stron, innych lokalizacji i innych częstotliwości aktualizacji. Zillow w USA, Redfin dla danych z MLS, Rightmove w Wielkiej Brytanii, realestate.com.au w Australii, Immobilienscout24 w Niemczech. Każdy portal to osobny projekt inżynieryjny.
Według badań Scrapfly z 2026 roku czołowe portale nieruchomości analizują sygnaturę na poziomie połączenia i odrzucają klientów, których handshake nie odpowiada przeglądarce. Ich przewodnik po Rightmove opisuje kod JSON osadzony w zmiennych JavaScript, którego struktura zmienia się co kilka miesięcy. Redfin rozprasza dane nieruchomości po dziesiątkach węzłów DOM, więc drobna modyfikacja układu może wyczyścić połowę Twoich pól naraz. Z kolei regionalne portale serwują inną treść zależnie od kraju użytkownika, przez co scraper z USA nie zobaczy nic użytecznego na realestate.com.au.
Rezultat: świeżość Twoich ogłoszeń po cichu spada. Jedna trzecia nieruchomości staje się nieaktualna w ciągu 48 godzin. Użytkownicy widzą ceny sprzed tygodnia. Dział sprzedaży spotyka się ze sprzeciwem klientów, a liczba zgłoszeń do supportu rośnie w poniedziałki, bo układy portali zmieniają się zwykle w weekendy.
Podejście
Agregacja ogłoszeń na dużą skalę to nie jest problem ze scrapingiem. To problem z niezawodnością, który tylko tak wygląda. Dlaczego Twój scraper ciągle się psuje opisuje przypadek ogólny. Nieruchomości potęgują każdy jego aspekt.
Każda platforma, która dobrze sobie z tym radzi, wymaga czterech współpracujących elementów. Po pierwsze, sygnatury żądania zgodnej z prawdziwymi przeglądarkami (nie tylko ciągu User-Agent w stylu przeglądarki, ale rzeczywistych parametrów na poziomie sieci, których Zillow i Rightmove używają do odróżniania botów od ludzi). Po drugie, precyzyjnych geograficznie adresów IP residential na każdym rynku docelowym, ponieważ niemiecki agregator nie może wysyłać ruchu z amerykańskiego datacenter do Immobilienscout24 i oczekiwać użytecznych odpowiedzi. Po trzecie, routingu proxy per-host, ponieważ strategia skuteczna na Zillow zawiedzie na realestate.com.au. Po czwarte, renderowania w przeglądarce jako metody zapasowej dla portali, które renderują wszystko po stronie klienta.
Przykładowe żądanie do Rightmove przez usługę Proxy od FourA wygląda następująco:
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"]}
}
}
}'
Flaga unblocker wstrzykuje pelny zestaw naglowkow przegladarki wraz z pasujaca sygnatura na poziomie sieciowym. maxTries: 5 instruuje menedzera proxy, aby rotowal do pieciu adresow IP, dopoki jeden nie zadziala. Reguly walidacji wylapuja ciche blokady: odpowiedzi 200, ktore zamiast danych o ofertach zwracaja strone z odmowa dostepu. Dzieki temu Twoj wskaznik sukcesu odzwierciedla to, co faktycznie zadzialalo, a nie to, co deklarowal status HTTP.
Portale, ktore serwuja wszystko przez JavaScript (Redfin jest tego koronnym przykladem), wymagaja renderowania w prawdziwej przegladarce. Nasz produkt Browser obsluguje je za pomoca pelnej instancji przegladarki, a nie lekkiego emulatora, ktory jest wykrywany juz przy pierwszym polaczeniu. Wykrywanie botow stalo sie behawioralne w 2026 roku, a wszystko ponizej poziomu prawdziwej przegladarki jest coraz latwiejsze do zidentyfikowania.
Wyniki
Co sie dzieje, gdy agregator nieruchomosci przechodzi z wlasnego stacku do scrapingu na podejscie API-first? Wzorce, ktore obserwujemy w rzeczywistych wdrozeniach (scenariusz pogladowy oparty na benchmarkach branzowych):
- Swiezosc ofert poprawia sie z "aktualizowane w ciagu 48 godzin" do "aktualizowane w ciagu 2 godzin" dla aktywnych rynkow
- Czas pracy inzynierow nad utrzymaniem scraperow spada o 70%. Jeden inzynier na dyzurze zamiast dedykowanego zespolu
- Zasieg portali rosnie z 6 witryn do ponad 20 bez proporcjonalnego rozbudowywania infrastruktury
- Wskaznik cichych blokad spada ponizej 3% na chronionych portalach, gdy reguly walidacji wylapia ciche odmowy
Wspolny wniosek od zespolow korzystajacych z naszej platformy: gdy warstwa niezawodnosci jest wspoldzielona, dodanie nowego rynku staje sie zmiana konfiguracji, a nie calym sprintem. Ciekawe pytania przenosza sie z "dlaczego to znowu przestalo dzialac" na "jaki portal powinnismy dodac nastepnie".
Uczciwe ograniczenie: portale nieruchomosci wymagajace zalogowanych sesji (niektore systemy MLS, wybrane widoki wylacznie dla agentow) wymagaja zarzadzania kontami poza sama infrastruktura requestow. To osobny problem, ktorego nie rozwiazujemy, i nie nalezy ufac nikomu, kto twierdzi inaczej, nie wyjasniajac dokladnie, jak to robi.
Najwazniejsze wnioski
Nieruchomosci to jedna z niewielu branz, gdzie nieaktualne dane to nie tylko niedogodnosc. To porazka produktu. Tygodniowa cena w sklepie odziezowym to drobne zazenowanie. Tygodniowa oferta na goracym rynku oznacza, ze Twoj uzytkownik wlasnie zapytal o dom, ktory zostal sprzedany we wtorek.
Jednak zespoly, ktore wygrywaja w tej branzy, to nie te z najwieksza liczba zrodel. To te, ktore przestaly budowac od zera te sama hydraulike proxy i requestow dla kazdego nowego portalu. Gdy ta warstwa staje sie wspoldzielona, zaczyna sie wlasciwa praca: jakosc danych, SLA swiezosci, deduplikacja miedzy portalami, analiza trendow cenowych. To wlasnie jest produkt. Wszystko pod spodem powinno po prostu dzialac.