How to track new property listings automatically

The simplest way to track new property listings is to save a search on a property portal and enable its alerts. That is often enough for one person using one site. When you need to monitor several searches or websites, preserve history, apply custom rules or route listings into business systems, use recurring structured collection followed by a downstream comparison.

The important distinction is that a completed scrape is not a new-listing alert. A reliable workflow must collect the intended market, validate the run, compare stable listing identities with trusted prior state and notify people only after a genuinely new record has been accepted.

Choose the simplest tracking method that fits

Method	Best for	Main limitation
Native saved-search alert	One person monitoring one portal with its existing filters	Portal-specific, with limited control over fields, history and downstream workflows
Supported feed, MLS interface or API	Teams with authorised structured access and suitable coverage	Availability, licensing, fields and coverage vary by source
Recurring structured collection and comparison	Custom searches, multiple accessible websites, historical analysis and integrations	Requires extraction maintenance, validation, stored state and comparison logic

If a portal alert already delivers the right listings at an acceptable frequency, building a separate system adds little value. Prefer an appropriate supported feed or API when one is available. Scraping becomes useful when the business needs consistent fields and its own rules across multiple accessible websites.

Define what counts as a new property listing

“New property” can describe three different events:

• A new source listing is a listing identity not previously seen on that website within the monitored scope.
• A new marketing event is a known property returning after its advert was withdrawn, sold, let or allowed to expire.
• A new physical property is a property that has never appeared in any source or historical dataset.

The first definition is the safest default because it can be established from the source's own identifiers. A practical rule is:

A new listing is a source listing whose stable source-specific key was not present in the accepted baseline or any later accepted run for that monitored scope.

This does not prove that the physical property is new to the market. A relisted home may receive a new listing ID. The same home may be advertised by two agencies or syndicated across several portals. Several flats can share one building address while remaining separate properties.

Choose the event before configuring alerts. An acquisition team may want every previously unseen source listing. A market analyst may want to label or exclude probable relistings and cross-posted properties.

Collect fields that support identity and review

The extraction schema needs enough context to identify the source record and investigate uncertain matches.

Purpose	Useful fields
Monitoring scope	source, search_scope_id, location, sale or rent, property type and applied filters
Source identity	listing_id, a separate property_id when supplied, source_url, conservatively normalised canonical_url
Property context	address_raw, address_normalised, unit, property type, bedrooms, floor area, coordinates and agency
Change context	price, currency, listing_status, source publication date when supplied
Observation and audit	observed_at, run_id, extractor_version

Use the most stable source-provided identifier available. A practical priority order is:

1. Native listing ID: Prefer a durable ID exposed in the page, URL, HTML or structured data.
2. Canonical listing URL: Use a carefully cleaned URL when no durable ID is available.
3. Address and unit composite: Use this only when neither the ID nor URL is reliable.

Include the source in the key because the same numeric ID may appear on unrelated websites:

source_listing_key = source + ":" + listing_id

Do not use row position, result rank or title as an identifier. These can change without a new advert being created.

URL normalisation must be conservative. Deleting every query parameter could merge distinct units or listing variants. Address matching is even less certain, so retain both raw and normalised values for audits.

Keep source_published_at separate from observed_at. The first is supplied by the website when available. The second records when your system detected the listing. Your own first_seen_at is therefore not proof of the original publication time.

Revisit discovery pages, not only known listings

New listings can only be found by revisiting search results, location pages, category pages or map results. Checking known detail-page URLs cannot reveal records created today.

Test the parts of a property search that commonly reduce coverage:

• numbered pagination, load-more controls or infinite scrolling;
• search-result caps and result sets that expose only the first matches;
• map boundaries or location state that changes the query;
• promoted records mixed into ordinary results;
• alternative card and detail-page layouts; and
• client-side rendering or interactions required to reveal data.

Do not assume every portal needs a rendered browser. In Web Scraper Cloud, the Fast driver can process returned HTML when the required content is already present. Use Fast or FullJS according to the tested sitemap. FullJS is required when collection depends on client-side rendering, scrolling or supported page interactions.

Create a trusted baseline and compare accepted runs

The first validated run normally establishes what already exists. Treating every baseline row as new can generate hundreds of useless notifications.

A simple workflow is:

1. Define the monitored scope, including source, geography, sale or rent, property type and filters.
2. Build and test extraction across representative results, pagination and detail-page variants.
3. Validate the first complete run and accept it as the baseline without sending listing alerts, unless an initial inventory alert is explicitly required.
4. Derive a stable, source-specific key for every record in each later accepted run.
5. Insert previously unseen keys with first_seen_at, and update last_seen_at for known keys.
6. Publish only accepted new-listing events that have not already been delivered.

Compare against all accepted history, not only the previous snapshot:

new_since_previous_run = current_keys - previous_snapshot_keys
never_seen_before = current_keys - all_historical_keys
missing_this_run = previous_snapshot_keys - current_keys

A listing that disappeared yesterday and returned today is new since the previous run, but it has been seen before. Calling it brand new would be misleading.

Keep source-listing identity separate from search membership. One listing can match several searches or clients. A key such as search_scope_id + source_listing_key lets you notify once globally, per search or per recipient.

Make event delivery idempotent. Store a unique event key based on the scope, source-listing key and first accepted run. Retrying an import or webhook can then resume processing without sending the same alert twice.

For the underlying state, history and comparison design, see incremental web scraping and change detection.

Example: separate new, changed and missing listings

Suppose Monday's accepted baseline contains two flats. Tuesday's accepted run contains one of them at a lower price and one unseen listing.

Listing key	Monday	Tuesday	Result
portal-a:8472	£325,000	£315,000	Price changed
portal-a:5520	£280,000	Not observed	Missing once, not removed
portal-a:9104	Not observed	£340,000	New source listing

Only portal-a:9104 produces a new-listing event. The first record produces a price-change event. The second begins a missing-observation policy but is not yet classified as sold, withdrawn or removed.

This prevents three common errors: alerting on the baseline, presenting a price reduction as new and treating one absence as a confirmed removal.

Handle relistings, syndication and reused URLs

A source-specific key answers whether an advert is new to that source. It does not resolve the underlying physical property.

Observed case	Safe default	Optional classification
Known listing ID with a changed URL or price	Existing source listing	Price, status or URL update
Unseen listing ID for a previously seen address	New source listing	Possible relisting
Similar property on another portal	New listing on that source	Possible syndicated or cross-posted property
Same building address with a different unit	Separate listing	Match only with unit-level evidence
Known listing absent from one run	No removal conclusion	Investigate after repeated accepted observations

Address matching can merge separate flats, while fuzzy matching can group merely similar homes. Relisting or cross-source decisions may require source-specific rules and human review. Label uncertain events as “possible”.

Reused URLs create the opposite risk. If a familiar URL suddenly refers to a materially different address, unit or location, do not overwrite the earlier record silently. Quarantine it for review or create a new versioned identity.

Reject incomplete runs before generating alerts

False alerts often start with a bad collection. A challenge page, broken pagination selector, changed filter state or layout update can return only part of the expected inventory. If that snapshot replaces trusted state, the next healthy run may make many old listings look new again.

Apply a run-level acceptance gate before changing state. Check:

• minimum expected record count for the scope;
• failed-page and empty-page rates;
• population of required fields such as listing_id or source_url;
• expected pagination or result-segment coverage;
• the intended location and filter state; and
• unusual inventory changes that warrant investigation.

Web Scraper data-quality controls can check record counts, page outcomes and required-field population. A quality failure is a signal to quarantine the dataset, not evidence that the market changed.

A successful response may still contain a challenge, fallback or incomplete page. The guide to diagnosing a 200 OK response with no usable data explains why status alone is not an acceptance test.

If validation fails, preserve the previous trusted state, suppress listing alerts and send an operational warning instead. Never advance removal or missing counters after an invalid run.

Separate detection from business qualification

“New” describes the listing's relationship to stored history. It does not mean the property meets an investor's, agent's or client's criteria.

Apply qualification rules after the new-listing event has been identified:

notify only when:
    event = new_source_listing
    sale_or_rent = sale
    price <= 350000
    bedrooms >= 2
    floor_area >= 70
    target_area = true
    likely_relisting = false

Keeping these layers separate preserves honest history. A known listing that later falls below the target price should produce a price-change or newly-qualified event, not be rewritten as a new listing.

Set a schedule based on acceptable delay and runtime

There is no universal schedule. Balance acceptable delay, source changes, job duration, access constraints and processing cost.

Total alert latency is approximately:

schedule interval + scraping duration + validation and processing time

A five-minute interval cannot provide five-minute detection when the scrape takes longer. With Web Scraper Cloud, scheduled jobs wait if the previous scheduled run for that sitemap is still running. Measure production runtime before choosing the interval.

Polling also cannot guarantee that every short-lived listing will be observed. A property may appear and disappear between runs, while search-result caps can hide active records. If strict completeness or lower latency is essential, investigate an authorised feed or interface designed for that requirement.

Connect Web Scraper to the comparison and alert workflow

1. Use the Web Scraper browser extension to build and test a sitemap for the relevant search and detail pages.
2. Run the tested sitemap in Cloud with the required driver and schedule.
3. Apply quality controls so only acceptable runs can advance.
4. Deliver the complete dataset to storage or trigger downstream processing when the job reaches a final status.
5. Retrieve, validate and compare the records before publishing listing-level alerts.

Automatic data exports can send each job's complete dataset to supported spreadsheet or storage destinations. They do not contain only the new listings.

For a database or application pipeline, a completion webhook can notify a downstream service when a job finishes, stops or fails. The webhook contains job metadata, not the scraped property records. The handler should check the status, retrieve the completed data through the Cloud API, run the acceptance checks and only then compare it with trusted state. Because completion events can be delivered more than once, the handler must be idempotent.

The responsibility boundary is straightforward:

Layer	Responsibility
Web Scraper extension	Build and test the extraction sitemap
Web Scraper Cloud	Run it repeatedly, apply collection-quality controls and deliver completed datasets
Downstream process	Maintain state, compare runs, classify relistings and send listing-level alerts

Web Scraper does not natively compare listings across runs or send new-property alerts. Keeping this logic downstream lets each team define “new”, “relisted”, “removed” and “qualified” for its own market.

Review access, terms and privacy

Technical access does not by itself establish permission to collect or reuse property data. Review each source's terms, licences, supported access options, robots instructions and applicable law. Prefer an authorised API, feed or MLS interface when it meets the requirement.

Public listing pages can also contain personal data, including identifiable agent, owner, occupant or contact information. Collect only fields required for the workflow, define access and retention rules, and obtain specialist advice when collection, reuse, profiling or sharing creates uncertainty.

A reliable system can explain why every alert was generated and distinguish a genuine market event from a collection error. Start with one representative search, prove stable identity and pagination, establish the baseline, and then connect the tested sitemap to Web Scraper's real estate data extraction workflow.