Real estate catalog without sold listings hanging around

A real estate catalog on an agency website breaks the same way everywhere: sold flats hang around for months, prices lag behind reality, and on the portals the same flat costs something different than on your site. The buyer calls, hears "already sold" — and stops believing any figure on the site. Let us look at how to build a catalog that does not go stale, and why this is a question of one data source rather than design.

Why listings go stale: it is not the manager being lazy

The typical agency scheme looks like this: a listing is entered in the CRM, then by hand onto the site, then by hand onto one portal, then another, then a classifieds site. Four places, each with its own interface and fields.

When the flat sells, the manager removes it from the platform the buyer came from and forgets the rest. Not out of negligence — at that moment they are busy closing the deal. A month later a dozen sold listings sit on the site, and each one spoils the impression of the rest.

There is only one way out and it is structural: a listing is entered once, and every channel pulls data from that source automatically. Then forgetting becomes technically impossible.

One source of truth: the site or the CRM

First you have to decide where the listings database lives. There are two options, and both work.

The CRM as the source. If you already work in a real estate system, it makes sense to keep it primary: the site pulls listings, statuses, prices and photos from it on schedule or in real time. Managers work in the familiar interface and relearn nothing.

The site as the source. If there is no CRM or it is inconvenient, the database can live in the site's admin panel: listings are entered there and feeds export them to the portals. That is cheaper and simpler but requires managers to work there.

What you definitely should not do is maintain listings in two places in parallel. That will diverge within two weeks and you end up with the same problem, only harder.

Portal feeds: how a flat appears everywhere at once

A feed is a file with your listings in a specific portal's format, updated automatically. Property portals pick it up on schedule and refresh the ads on their side.

In practice that means: the manager changed the price on the site — within hours it changed on every platform. Marked a flat as sold — it disappeared everywhere. No manual edits in four different back offices.

An important detail: each portal has its own required fields and its own directory of districts and property types. So a feed is not a simple export but a conversion of your structure into theirs. It is set up once during development and then runs by itself.

Statuses the buyer sees

Not everything needs hiding. Sold listings are useful to keep visible with an honest "sold" label — it shows the agency really works and gives the buyer a price reference for the district.

A working status set: for sale, reserved, sold, withdrawn. The first two in the main catalog, "sold" in a separate section or behind a filter, withdrawn hidden.

The main rule: the status changes in one place and propagates everywhere. A reserved flat someone tries to view is not a problem but a reason to offer similar options.

The listing page: where a real estate catalog beats a portal

A real estate catalog wins not on the number of listings — portals will always have more — but on the quality of the page. What is mandatory: at least ten photos in decent quality, a floor plan with dimensions, the floor and building height, areas, price per square metre and total, building year and type, renovation condition.

Then what portals usually lack: a map with surrounding infrastructure, an honest description from the agent including the downsides, a mortgage calculation for this specific flat, the agent with a photo and a direct phone number, similar listings in the same budget.

We wrote about how the same logic works for new builds in property developer website: 7 blocks — a unit grid is added there, but the data-freshness principle is identical.

Filters that work instantly

A catalog of five hundred listings without proper filters is a catalog in which nothing can be found. The buyer should reach a selection resembling what they want within a minute.

The minimum set: district, number of rooms, price, area, floor with "not first or last", building type, condition. Filters must apply without reloading the page and be kept in the URL — then a person can send a selection to their partner and you can advertise it.

Separately: saved searches with alerts. Someone picks the parameters, leaves an email — and receives a message when a matching listing appears. It is the cheapest way to bring back a buyer who has not decided yet.

District pages: where organic traffic comes from

An agency's main SEO lives not in listing pages — those disappear quickly — but in district and type pages. "Buy a flat in Pozniaky", "rent in Podil", "two-bedroom Obolon" are queries that stay stable for years.

Such a page consists of a district description, infrastructure, indicative prices and a live selection of listings generated automatically from the catalog. Listings change, the page stays and accumulates positions.

That is the main advantage of your own site over a portal: there you are one ad among thousands, here you have a page that brings people in by itself. We covered the basic promotion steps in how to reach the top of Google.

Speed with hundreds of photos

A real estate catalog means tens of thousands of photographs. Served as they are, the site takes five seconds to open — while the buyer is browsing listings from a phone in the evening.

Technically this is closed by compression, a modern format and lazy loading — the browser only pulls what the person scrolled to. A catalog of a thousand listings should open in a second; that is a requirement, not a wish.

Analytics: which listings and districts actually sell

When listings live in one database, you get something no portal provides: you see which districts, budgets and types get viewed most, which listings generate calls and how long it takes from first visit to enquiry.

Calls from listing pages are worth tracking down to the specific flat via call tracking, and viewing requests should be passed to analytics as conversions. Then advertising learns from real enquiries rather than clicks. How to measure the site's return overall is described in how to calculate a website's return.

What building such a catalog includes is collected on the page about real estate agency and developer websites.

Rentals and resale: what differs for the catalog

Rentals move faster than sales: a listing appears and disappears within a week, and some flats are let several times a year. So for rentals what matters is not a rich listing page but the speed of unpublishing and an "available from" filter.

Practical differences worth building in from the start: rentals need utilities stated separately from the rent, appliances and furniture as a list, terms about pets and children, the deposit and minimum term. Sales instead depend on documents, ownership history and readiness for the deal.

If the agency works in both directions, that is not two websites but two sections with different field and filter sets inside one catalog. The database, the agents and the district pages stay shared.

Frequently asked questions

Can our CRM be connected to the site?

Yes, if it exposes data via an API or export — most real estate systems do. The site will pull listings, statuses, prices and photos from it while managers keep working in the familiar interface. Name the system at the briefing and we will assess the integration right away.

How much does a site with a 300-listing catalog cost?

The number of listings barely affects the price: the catalog works the same with 30 or 3,000. What matters is whether there is a CRM to import from, how many portals to connect, and whether you need district pages and saved searches. A basic agency site starts from ₴19,900 and 2–4 weeks.

How often is data updated on the portals?

It depends on the portal: most pick the feed up several times a day. So a price or status change on the site appears there within hours. For urgent cases manual editing in the portal's back office remains available, but the need for it is rare.

Should sold listings be shown?

Yes, but separately and with an honest label. It works as the agency's portfolio: the buyer sees you really close deals and gets a feel for district prices. The key is that they must not mix with current listings in the main catalog.

What if some listings are partners' rather than ours?

Such listings are entered with a separate marker and their own display rules — for example, without the exact address. The important thing is that they live in the same database: a mixed scheme with your listings in the CRM and partners' in a spreadsheet is the first to fall out of sync.

In short

A real estate catalog rests on one rule: a listing is entered once and the site and portals pull from a single source. Then sold flats disappear everywhere at the same moment, prices do not diverge, and a manager does not spend a day on four back offices. After that come instant filters, a listing page with a plan and a map, district pages for organic traffic and speed that survives thousands of photos.