Real estate scraping: why PropertyGuru and 99.co give you partial data

Your PropertyGuru scraper returns 200 listings a day. Half are missing the agent contact. Most are missing the full photo gallery. The HTML loads fine. The API quietly returns reduced payloads after a few pages. You’re not getting blocked. You’re getting partial data, which is worse, because nothing in your logs tells you it happened.

Real estate portals look easy from the outside: a search page, a listing page, an image gallery, done. In production, the hard part isn’t HTML extraction. It’s getting the same listing payloads, photos, and neighborhood detail cards that real users see, without tripping the browser and CDN defenses that now sit in front of most property platforms. The common failure mode in real estate scraping in 2026 isn’t a captcha. It’s partial data.

This article covers three things: the defenses that break naive real estate scrapers, the four-pass collection model that survives them, and a working PropertyGuru enrichment probe built on sticky mobile sessions.

Why portals punish generic scrapers

PropertyGuru, 99.co, Zillow, Rightmove, and Realtor.com have all moved toward heavier client-side rendering, event-driven search interfaces, and layered asset delivery. The obvious reason is user experience. The less obvious reason is abuse control. Listing fraud, lead harvesting, duplicate syndication, and aggressive broker scraping are routine on these platforms, so many of them now treat unusual browser traffic as suspect long before they ever show you a hard block page.

That’s why the common failure mode isn’t a dramatic captcha. It’s partial data. Search results load, but the detailed listing JSON is missing fields. Photos resolve fine in a browser but fail when fetched in batch. The single-page app shell renders normally while the underlying API silently returns reduced payloads after the first few pages.

This is especially relevant in Singapore. PropertyGuru and 99.co aren’t fully closed off to traffic from outside Singapore, but some supporting assets, experiments, and latency-sensitive calls behave differently once a session clearly looks local.

The three defenses

First is the browser-rendered SPA itself. Search filters, map movement, and lazy-loaded listing cards are often driven by GraphQL or JSON endpoints that only fire once the page sees a believable browser environment. Headless defaults still get noticed. A proper mobile browser fingerprint paired with a mobile IP closes that gap.

Second is photo CDN gating. Many portals put listing images behind signed URLs, short-lived tokens, referer checks, or behavior-based rate controls. You can scrape the listing metadata successfully and still fail to pull the gallery at scale. Mobile sessions lower the odds that the image host treats you like bulk theft on first contact.

Third is geo and market segmentation. Zillow and Realtor.com shape data around US assumptions. Rightmove shapes around UK behavior. PropertyGuru and 99.co shape around local Southeast Asian demand patterns. If you hit all of them from one generic infrastructure stack, you train their systems to recognize you as a syndicator. Break collection into market-specific mobile cohorts instead, and your success rate improves.

The four-pass collection model

Most property data teams should split collection into four passes instead of running one crawler against everything.

Discovery pass: crawl search result pages, map tiles, and pagination to identify candidate listings and detect deltas.

Enrichment pass: revisit changed listings with sticky mobile sessions to collect the full JSON, agent details, amenities, and image metadata.

Media pass: fetch photos more slowly, with coherent headers, valid referers, and strict retry limits.

QA pass: sample rendered pages against stored output to catch silent field loss before it reaches your database.

That’s heavier than a single crawler, but it maps to how these portals actually defend themselves. Discovery traffic can tolerate more rotation, since it’s just walking search results. Enrichment traffic benefits from a steadier session, because it’s the part that pulls the detail you actually care about. Media fetching needs rate discipline more than brute force, since image hosts watch for burst behavior specifically. Teams that lump all three passes together get inconsistent coverage and end up blaming the parser for what’s really an infrastructure problem.

A portal by portal playbook

PropertyGuru: the issue is SPA search combined with image gating. The best session pattern is a sticky mobile session per browser context. SG-local traffic helps with consistency.

99.co: the issue is reactive map search and request correlation. The best pattern is rotating between map batches while staying sticky inside each batch. Watch for silent field drops here in particular.

Zillow: the issue is heavy anti-bot protection on the detail flows. The best pattern is conservative browser automation with replayable steps, avoiding burst pagination.

Rightmove: the issue is an event-rich search UX. The best pattern is a warm browser context with a slow enrichment pass. Media requests need discipline.

Realtor.com: the issue is dynamic APIs with feed variance. The best pattern is separating search discovery from detail fetch, then QA-checking rendered pages against stored output.

A working PropertyGuru probe

Use a sticky session for the detail page pull, especially when the site chains several internal API calls after the initial page load. Keeping a session token in the proxy username holds the same outbound IP across that whole bucket walk, so every follow-up call in the chain comes from the same address instead of hopping IPs mid-sequence, which is exactly the pattern that gets flagged. For Singapore portals, matching the mobile user agent and language to the session makes the whole request look coherent rather than assembled.

That doesn’t replace browser automation when a page is heavily client-rendered. But it gives your enrichment jobs a much better starting point than a fresh IP and a generic header set on every request.

What mobile proxies don’t solve

Mobile proxies help with geo fit, trust posture, and consistency on mobile-shaped traffic paths. They’re especially useful when a site personalizes content delivery based on consumer network cues, or degrades assets for traffic that looks scraped.

They don’t fix broken browser fingerprints, bad concurrency, or a collector that ignores referers, cookies, and client-side sequence. And they don’t grant permission. If a portal’s terms or local law restrict how you can collect or reuse listing data, the proxy isn’t the legal layer, and no infrastructure choice changes that.

One more honest point: not every property workflow needs mobile proxies. If you’re ingesting licensed feeds, or scraping a small number of unprotected pages for internal research, a well-run residential stack may be enough. Mobile becomes necessary when you care about the exact consumer-rendered experience, image availability, local segmentation, and long-run scraper survival.

For Singapore-heavy property work, Singapore Mobile Proxy gives you SG-only mobile sessions through real Android devices on Vivifi 4G and 5G SIMs, so PropertyGuru and 99.co see local, consumer-shaped traffic instead of a bulk scraper. Try a 24-hour free trial with no card required, and use code YT30 for 30% off your first paid month. Probe one PropertyGuru listing through a sticky session and compare the result to whatever your current stack returns. Start with Singapore Mobile Proxy

Get new guides and videos first — join the Telegram channel.