How to keep property prices and availability current

Start with an accountable source

A correct import can become outdated the same day: a broker reserves an apartment, a developer changes the price, or an old offer remains on the website. Catalog quality therefore depends on more than the first scan. Decide who reports changes and which source is authoritative for each important field.

If the CRM, spreadsheet and website disagree, do not automatically choose the most recently delivered file. Establish which source is authorised to change the price and when the change takes effect. Apply the same rule to reservations. Someone on the team should be able to explain why a particular property is currently considered available.

Use meaningful states backed by evidence

Distinguish available, reserved, sold, rented, withdrawn and unknown. Unknown is neither confirmed availability nor evidence of a completed sale. When a record disappears, first check whether every results page was collected, whether a filter changed and whether the request failed.

An HTTP 404 describes a missing web resource, not a completed property transaction. Change business status using an explicit source fact or a confirmed team action. Schema.org defines an availability property, but the technical vocabulary you choose still needs to match your business rules. A colour or CSS class alone is a weak explanation for a significant status change.

Keep the price and its context together

Amount and currency form a meaningful pair. Receiving a currency label alone should not relabel an old amount. Distinguish the purchase price from monthly rent, price per square metre and deposit. In a data file, use a numeric amount and an explicit currency code such as EUR rather than embedding explanations in the number.

Record when a change was detected and, where known, when it happened at the source. A reservation discovered this morning may have been made yesterday. FindEstate’s observation history records detection; it should not be presented as the actual contract or sale date. If the source supplies no event date, that date remains unknown.

Manage manual corrections deliberately

Manual editing helps correct a city, an incorrectly recognised area or a description mistake. Over time, however, it can conceal a source problem. In your team’s process, record why an important correction was made and who should review the original record. Fixing the source is often the lasting solution because it prevents the same error reaching other systems.

FindEstate preserves manual property corrections during later scans. A newly completed job therefore does not prove that every manually edited field matches the source. Review those fields separately. Apply shared catalog fields only after reviewing their scope; do not make different properties’ prices or areas identical simply to remove empty cells.

Create a short, repeatable check

Set review frequency according to actual change rates and team availability. A fast-moving development may need more frequent checks than a small collection of long-term offers. This is your operating policy, not a promise about the platform’s automatic refresh schedule. Treat successful updates, partial results and failed attempts as different outcomes.

After an update, inspect one changed property, one unchanged property and one removed from the active offer. Compare the source, workspace and public channel. External search systems refresh their own copies separately; correcting your live response does not guarantee an immediate change everywhere else. If a conflict remains, stop distributing the misleading entry until it is resolved.

• Who confirmed the new price or status?
• Was the existing property ID updated?
• Is the acquisition coverage known?
• Does the public response still contain a misleading old fact?