A real estate website CMS should represent real property relationships, publishing ownership and lead context instead of forcing every listing into a generic card.

Model the entities the business actually manages, then connect them only where the relationship is useful. Properties, developments, locations, agents and resources often need different fields, owners and update frequencies.

The content model outlives the design

Visual design is replaced every few years; the content model usually is not. A poorly modelled property structure is invisible on the first development and painful on the second, when the same information has to be retyped and every price change means editing several places. This is the highest-leverage decision in a property website.

  • Symptom of a weak model: the same fact stored in several places.
  • Symptom of a weak model: adding a property needs developer help.
  • A good model survives a redesign; a weak one forces a rebuild.

Define the source of truth

Decide whether inventory is entered in the website CMS, synchronized from another system or curated manually. This choice controls freshness, editing and integration requirements. Where the same property exists in a CRM, a spreadsheet and the website, the three will diverge and nobody will know which is correct.

  • One system where property data is created and corrected.
  • A defined direction of synchronisation if more than one system holds it.
  • A named person accountable for accuracy.

Create semantic property fields

Use fields for status, type, location, specifications, price treatment, contact, media and documents according to the real business. Avoid a single rich-text field that hides structured information. Anything a visitor may want to filter or sort by must be its own field; buried inside a paragraph it is invisible to the system.

  • Make required fields protect page quality.
  • Document units and formatting.
  • Plan unavailable and archived states.
  • Store price as a number, not as text inside a description.

Connect locations and agents carefully

References can reduce duplication and support useful navigation, but excessive relationships create editor complexity. Keep only connections that serve visitors or operations. A relationship earns its place when it removes repeated typing or powers real navigation, and not otherwise.

  • Property references its development rather than repeating the name.
  • Development references a location described once.
  • Agent profiles maintained once and linked to their listings.
  • Resist relationships that exist only because they are possible.

Design the states nobody demonstrates

Content models are usually designed around the ideal property: complete specification, professional photography, confirmed price. Real inventory is messier, and it is the awkward records that decide whether the site still looks credible a year after launch.

  • A property with no photography yet.
  • A price that is withheld or given on application.
  • A very long development name that breaks a card layout.
  • A development where every unit is now sold.

Protect search and enquiry context

Use stable slugs, metadata fields and crawlable links. Pass the property or development context into forms and CRM destinations so teams know what generated the enquiry. Without that link the most valuable business question, which properties actually generate enquiries, cannot be answered.

  • Slugs that stay stable even when a title is edited.
  • Property reference carried into every submission.
  • Enquiries attributable to a specific listing or development.

Practical decision checklist

  • Name every content type and its owner.
  • Choose one source of truth for property data.
  • Define property fields, units and states.
  • Map only the relationships that earn their place.
  • Test long, missing and archived content.
  • Preserve context through enquiry routing.

Frequently asked questions

Can Webflow CMS manage property listings?

It can manage many curated inventories, but live high-volume feeds may require an external source and integration.

Should agents be a separate Collection?

Use a separate Collection when agents have reusable profiles and real relationships to properties or locations.

How should sold properties be handled?

Choose an archive, redirect or removal policy based on visitor value, search demand and business requirements rather than deleting automatically.

How can I tell whether the model is good before launch?

Add one complete property yourself. If it publishes without developer help and without retyping information that already exists elsewhere, the model is sound.

Should prices be stored in the CMS?

Yes, if published, and as a dedicated numeric field rather than inside descriptive text. Only then can listings be filtered or sorted by price and updated in a single action.