Websites

Real estate website: catalogue, filters, viewings

The property page, filters and map, exchange with the agency database and listing portals, withdrawn listings and viewing requests — what a working site is made of.

A real estate agency website differs from an ordinary catalogue in two ways. First, every property is unique and exists as a single item. Second, it quickly stops being available, and a withdrawn property still on the site damages reputation more than its absence would. That's where the main work lies: the property page, search, data exchange and keeping everything current.

The property page

The property page is what the person came for. It should answer the questions people usually call to clarify.

What it needs:

  • Parameters in structured form. Type, total and living area, floor and number of floors, rooms, condition, year built, building type. Each parameter is a separate field, not a line in the description: you can't filter by a description.
  • Price and terms. The price, what it includes, whether a mortgage or instalments are possible, whether there are encumbrances. For rentals — term, deposit, utilities, rules on pets and children.
  • Location. An address at the right level of precision, the district, a map pin, what's nearby: transport, schools, shops. If the address isn't disclosed before contact, say so directly rather than showing a pin in the middle of the district with no explanation.
  • Photos. Plenty of them, in decent quality, in a sensible order: overview, rooms, kitchen, bathroom, view from the window, entrance and yard. The floor plan as a separate image.
  • A description written by a person. A short text explaining what the parameters don't show: why it's being sold, what has been done to the flat, what its quirks are.
  • The responsible agent's contact. The name and photo of the agent handling the property — conversion to an enquiry is higher here than with a general phone number.
  • Reference data. The internal property number and the date of the last update. Both remove questions during a call.

A note on video and virtual tours. They really do reduce the number of pointless viewings, but they require a shoot for every property. Decide upfront: either it's the agency's standard, or there won't be any — a handful of properties with tours looks like selective advertising.

Filters and map

Property search is mostly filters. People almost always search by parameters, not by name.

The basic set is clear: transaction (buy or rent), property type, price, area, rooms, floor, district. Then come the nuances that affect usability:

  1. Ranges, not exact values. Price and area are set as intervals. "From" and "to" fields should allow filling in only one side.
  2. A live result counter. The user should see how many properties remain before applying a filter. Otherwise they hit an empty list and leave.
  3. Clear behaviour at zero results. Not an empty page, but an explanation and a suggestion to loosen one of the filters.
  4. Filters in the page URL. A selection should be shareable by link — with a colleague, a spouse, an agent. This also makes it possible to build pages for common queries like a district or number of rooms.
  5. Saved searches and alerts. Looking for property takes weeks. Being able to save a filter and get notified about new matching properties brings people back to the site.

For real estate, a map isn't decoration but a second way to search: some people pick the district first and the property second. A working map clusters properties when zoomed out, stays in sync with filters and lets users search within a drawn area. Plan for it from the start — adding a full map mode to a finished catalogue costs noticeably more.

Data exchange: the agency database and external portals

Properties are almost always already managed somewhere else — in the agency's CRM or a specialised database. In this setup, the website is usually not the data source but the storefront.

What needs to be defined:

  • Where the source of truth is. If a property can be entered both in the CRM and on the site, the data will diverge. Better: entered in the CRM, exported to the site.
  • What exactly is transferred. Parameters, price, status, photos, the responsible agent. Which fields are publicly visible is a separate decision: internal comments and owner details must not reach the site.
  • How often. For real estate, regular scheduled sync is enough, but unpublishing a property should happen as quickly as possible.
  • How properties are matched. By the CRM's internal ID, not by address or title.

The other side of the exchange is export to external portals. Listings are published in common feed formats, and discipline matters here: if a property is withdrawn on the site but stays in the feed, calls about it will keep coming. Export and withdrawal must be controlled by a single status.

A separate question is which properties to export at all. Some agencies deliberately keep part of their base on their own site only. It's a sensible strategy, but it should be built into the system as a property flag rather than tracked by hand.

Being current: the main reputational problem

A withdrawn property still hanging on the site is the most common source of frustration. A person chose, called, heard "that one's gone" and stopped trusting the whole catalogue. It's worse when outdated listings are kept on purpose to generate calls: that destroys trust faster than it brings enquiries.

What helps:

  1. An explicit property status. Not just "active" and "deleted", but intermediate ones: reserved, deposit paid, deal in progress. A property under deposit can be shown with an honest label — more useful than it disappearing.
  2. Automatic removal by CRM status. As soon as a deal closes, the property leaves the site and the feeds without human involvement.
  3. Staleness checks. A property that hasn't been confirmed for a long time is flagged for review. The confirmation routine is an operational matter, but the system should send reminders.
  4. The update date on the page. A visible date keeps the agency disciplined and informs the visitor.
  5. Correct handling of withdrawn pages. The URL of a sold property shouldn't return an error: better to show a page marked as sold with a selection of similar properties. This keeps the person on the site and preserves the value of accumulated links.

The last point matters for search too: real estate sites constantly gain and lose pages, and careful handling of withdrawn URLs directly affects the site's overall quality in the eyes of search engines.

The viewing request

The site's goal isn't selling online but moving to a conversation. The viewing request is the target action.

The form should be short: name, phone, convenient time. The agent will clarify everything else. The property must be attached to the request — the agent should see what it's about without extra questions.

What to provide for:

  • Choosing a time. At least as a convenient time slot, not free text. It cuts down on back-and-forth.
  • A fallback contact method. A messenger or a call straight from the page — some people won't fill in forms on principle.
  • A clear confirmation. On screen and by email, naming the property and what happens next.
  • Response speed. The request should go directly to the responsible agent, not a shared inbox. In real estate, a slow reply costs the deal.
  • Favourites and comparison. People look at several properties. Being able to save and compare a shortlist isn't decoration but part of the decision process.

What to check before development

A short list of decisions best made before work starts on a real estate website:

  1. The full list of property types and the parameter set for each.
  2. Which parameters are used in filters, and in what form — range, list, flag.
  3. Whether a map mode with area search is needed, and whether from day one.
  4. Where the source of truth for properties is and which fields are exported to the site.
  5. Which external portals are needed and how one status controls publication everywhere.
  6. The set of property statuses and the automatic removal rule.
  7. What's shown at the URL of a withdrawn property.
  8. Where viewing requests go and who is responsible for response time.

The first two points define the catalogue's structure; the rest define whether it's still viable six months on. If any of them are unclear, it makes sense to settle them at the task-definition stage — let's discuss before the start.