Real Estate Websites: Listings, Enquiries and Lead Quality

A property website has an unusual shape: almost all of the value arrives as data that somebody else owns. The listings come from a portal feed or a back office, the photographs come from an agency’s library, availability changes without anyone telling you, and the enquiry lands in an inbox that somebody checks when they remember. The visual design is the part everyone discusses. The failures are almost never visual.

That makes real estate one of the more awkward things to scope, because the build is comparatively easy and the data plumbing decides whether it works. Below is the set of things we think are worth settling early, from having had to unpick these systems after they went live — which at SmartEdge IT Solutions is usually how a property site enters our audit process in the first place.

A listing is a record with a lifecycle

The single most useful thing we can say to a property team is that a listing is not a page, it is a record in a state machine. It moves from pre-market to available to under offer to sold or let, and it can be withdrawn and return. Every visible behaviour of the site follows from that state, and it should be explicit rather than inferred from whether someone deleted a page.

Two examples of why that distinction matters. Sold and let prices: decide whether they display, display as “POA”, or display only on request, and make it a single setting rather than a per-branch habit. And expiry: an archived listing that returns a friendly page is far better for everyone than a 404, both because the URL is often linked from elsewhere and because the archived version is genuinely useful to an agent answering a question six months later.

Keep a price history rather than overwriting the field. Asking prices move, buyers notice, and having no record of it creates awkward conversations that the data would have settled. The same applies to status changes, since “when did it go under offer” is a question the whole office eventually asks.

The feed is a dependency with its own failure modes

Feeds are sold as a solved problem. They are not. In our experience the interesting work is entirely in the failure cases, so we ask for these in writing before scoping:

• How often does it refresh, and what is the agreed maximum acceptable age of a listing on the site?
• What happens when the feed is down? Does the site show yesterday’s listings, an empty page, or an error? Each of those is a different amount of work and a different amount of embarrassment.
• Which fields are always present and which may arrive empty? Property type, tenure and postcode are the three that break search when missing.
• How are removals signalled, and how quickly? A feed that only signals removal on the next full refresh will show sold properties for hours.
• Do we own a copy of the data, or does it exist only as the feed delivers it?

That last question decides the whole architecture. With our own copy, the site can search, rank and cache independently, and a feed outage stops mattering after the first load. Without it, the site is a rendering layer that goes blank when someone upstream has a bad afternoon. Ingestion belongs as its own small service with its own logging and its own retry behaviour, sitting between the feed and the site — that boundary is where our API and system integration work earns its keep, and where a lot of real estate projects have gone wrong by skipping it.

Search filters, and the ones we decline to build

Objective filters are straightforward: price band, bedrooms, property type, tenure, floor area, parking, garden, no onward chain, new build, period, and features that can be asserted as fact. They map to fields, they test cleanly, and they are what people actually reach for.

Then there are the subjective ones, and this is where we push back. Anything describing an area in evaluative terms — “safe”, “family-friendly”, “good schools” — is not a neutral filter and is not something we will implement as a query parameter. Nor are filters built around a postcode’s demographic profile, or phrased in ways that steer a user towards or away from a neighbourhood on the basis of who is assumed to live there. In several markets, advertising rules constrain what can be said about an area, and in all of them the specific position is a legal question rather than a design one.

Our working method: describe the permitted set in plain language, get the client’s legal or compliance side to approve the wording, then implement exactly that list. Where an area descriptor is wanted for the page copy, it is written as prose about the neighbourhood — transport links, amenities, character — rather than as a filter a user can toggle. That keeps the site useful and the exposure low, and it is also a shorter conversation than teams expect.

One technical detail worth agreeing: search URLs need a canonical policy. Otherwise a thousand orderings of the same filter combination become a thousand indexable pages with identical content. We normally make one canonical combination per filter set and noindex the rest.

Enquiry forms that ask for less and route faster

Every field on an enquiry form costs completions. Name, contact and a free-text message are enough to start a conversation, and most agents want to phone anyway. The additional questions worth asking are few and should be genuinely useful to the person receiving the enquiry — whether they need a mortgage, whether they are buying or renting, and roughly when. Anything longer, and the form becomes a filter that a serious buyer abandons.

Then the routing, which is where the value is. The enquiry should be:

1. Timestamped and visible in the internal view immediately, not only in an inbox.
2. Attached to the listing, with the referring URL and the campaign parameters captured before anything redirects anywhere.
3. Delivered with a fallback — if the primary channel fails, a second route fires and someone finds out.
4. Acknowledged to the enquirer at once, with what happens next and when to expect contact.
5. Spam-filtered without punishing real people. A hidden field and rate limiting handle most of it; a challenge on every enquiry costs more good leads than it saves.

We also like the enquiry form to survive a failed submission without losing what was typed. Losing a half-written message on a mobile connection is one of the more reliable ways to lose an otherwise good lead, and it is trivially avoidable.

What makes a site lead different from a portal lead

A portal lead is bought and partly inflated — agent spam, competitors checking availability, curiosity browsing. A lead from your own site is smaller in number and different in kind, usually someone who found a specific property and wants to know about that property. Two practical implications follow.

First, attribution is actually possible on your own site, so it is worth capturing properly at the point of submission. Second, because volume is lower, per-enquiry handling matters more than form features. The highest-return change on most property sites is not a redesign of the form; it is making sure the enquiry is visible to a human within minutes, including out of hours and at the weekend. That is a staffing and routing decision, not a software one, and no amount of automation substitutes for it — but automation is what stops a lead sitting unseen over lunch.

The metrics we ask clients to agree before launch, so that nobody argues about them later: contact rate, time to first contact, appointments booked, viewings held, and offers. Some teams add enquiry quality scoring; we are cautious about that, since it tends to create an incentive to filter out the buyer who needs a mortgage.

Duplicates and listings that should have come down

Two data problems dominate. Duplicate listings for the same property — usually an agent listing directly as well as through an agency, or two branches with different references. And stale listings that were sold or let weeks ago and are still live because the feed stopped telling anyone.

Automatic merging of duplicates is tempting and mostly wrong. Address string matching plus geographic proximity plus a similar price band gets you a candidate list; a human decides. The queue should show both versions side by side, including which branches and which media, because merging loses attribution that sales teams rely on. Do it once, well, and the queue stays short.

Stale listings are a separate problem, and published sold-price data for the market you operate in is a genuinely useful signal for finding them. Where a live listing matches a recent transaction record in the same area, flag it for review rather than unpublishing automatically. Automatic removal on a fuzzy match will one day remove the wrong house in front of the person whose job depends on it. Also worth having: an internal note explaining why a listing is live when a transaction record says otherwise, because that discrepancy usually means something specific.

Mobile speed is a listing feature

Most property traffic is mobile, most property browsing happens on a phone held one-handed, and phone galleries are enormous. A site that takes several seconds to show the first photograph has already lost the session, whatever the enquiry form says.

The work is mostly restraint:

• Serve resized images. Ask the agency for a sensible maximum, store several widths, and serve the right one with a srcset rather than uploading a camera original and letting the browser cope.
• Lazy-load below the fold. The first photograph should be eager; the other twenty can wait.
• Load the map after the listing text. Map libraries are heavy and usually the last thing on the page that anybody looks at.
• Keep the gallery simple. A carousel with a heavy script is worth replacing with something plain.

Related: floorplans and brochures are usually the largest assets on a listing page. If they are uploaded as multi-megabyte PDFs, consider whether a generated image preview serves the browsing case and leave the download as a deliberate action.

If the market has moved past listings to something buyers actually use — saved searches, valuation requests, viewing booking — that is a product conversation rather than a build one, and it belongs with the same people who own the enquiry routing. It is also worth noting how much of it is not a website any more: teams who need agents working offline tend to end up looking at mobile app development before they need anything else.

Fitting a CRM in without losing the thread

Almost every client has a CRM, and almost none of them want to change it. That is fine, but the mapping is real work and should be scoped as its own piece rather than described as “integration” in a footnote. The questions are unglamorous: does the CRM deduplicate by email or by phone, where do the campaign parameters land, can an enquiry and a viewing be linked to the same person, and what happens when the CRM is unavailable for an hour?

We prefer a small server-side service that receives the enquiry, writes it to our database first, and then pushes to the CRM with retry. The enquiry existing in our own records before it reaches anyone else’s system is what stops a third-party outage turning into a lost lead. Once that service exists, adding a second destination — a messaging channel, an internal chat notification — is a configuration change rather than a rebuild.

Where a CRM is being built or extended rather than merely fed, we have used CRM development to keep the enquiry model, the listing model and the activity timeline in one place, which removes most of the reconciliation work later.

What we measure in the first month

The first month after launch is mostly about finding out what the data is doing, and the useful numbers are not the glamorous ones:

• Searches that return nothing. A high count means either thin inventory or a filter combination the data cannot satisfy. Both are fixable and neither shows up anywhere else.
• Enquiry abandonment by field. Which question costs you the most completed enquiries.
• Time to first contact. Measured, not assumed.
• Listing age and feed lag. How stale the site was at its worst moment last week.
• Duplicates flagged and resolved per week, which should trend downwards as the merge rules settle.

We keep a short written log of these at each review, because the pattern that matters — usually a filter nobody can satisfy, or a branch that never updates a status — is obvious by week three and invisible by week twelve. If the intent is to build an agent-facing tool later, dashboard and internal tool design is where that lives, and it is worth sketching the data model for it now rather than after the first enquiry crisis.