Structured Data for Real Estate Agents: What to Mark Up

Structured data is a block of description added to a page that states, in a vocabulary machines already agree on, what the page is. For an agent website it is worth doing, it is not worth overdoing, and there is one specific piece of it that will cost you more than it gains. This covers which types belong where, what each one realistically produces, and the rules that decide whether markup helps you or gets your site’s rich results switched off.

What structured data actually is

Structured data is a small block of JSON added to a page, describing the page’s content using the schema.org vocabulary. It sits in the source, invisible to readers, and it is read by anything that wants to understand the page without parsing the layout.

Consider the difference. Without it, a search engine looking at your contact page sees a heading, some text and a string of digits, and has to infer that the digits are a phone number, that the address below them is an address, and that the whole thing describes a business rather than describing somebody else’s business. With it, the page states directly: this is a RealEstateAgent, this is its name, this is its telephone, this is its postal address, these are the areas it serves.

That is the whole idea. It is a description, not an argument. It cannot make a page about something it is not about, and it should never try.

The types that belong on an agent site

Five types cover almost everything an agent website needs.

RealEstateAgent describes the business. On schema.org it is a subtype of LocalBusiness, so it inherits the properties a local business needs: name, address, telephone, opening hours, area served, logo, and links to your profiles elsewhere. This belongs on the home page or the contact page, once, as the canonical description of who you are. Emitting it on every page is unnecessary and makes the site harder to reason about.

RealEstateListing describes a single property page: address, geographic coordinates, number of rooms, floor size, lot size. The honest framing is that this makes the page machine readable rather than that it produces a search feature, which is covered below.

Article or BlogPosting describes a piece of writing: its headline, its author, when it was published, when it was last modified. If you publish articles, mark them up, because the author and date properties are how a piece is attributed and dated by anything reading it.

Person describes a human: you, or whoever writes for the site. Linked from the article markup as the author, it connects the writing to a named individual rather than leaving it anonymous.

FAQPage describes a set of questions and answers on a page. Google documents specific requirements for it, including that the questions and answers must be visible on the page and that the content must not be promotional.

BreadcrumbList describes where a page sits in the hierarchy. It is small, it is easy, and it is one of the more reliably useful pieces of markup because it helps a search result show a path rather than a bare URL.

That is the set. Almost everything beyond it is either not applicable to an agent site or is one of the things in the next section.

The rule that everything else follows from

Markup must describe content that a visitor can actually see on the page.

Google’s general structured data guidelines state this directly, and it is the rule that most violations reduce to. Marking up a price that is not shown. Marking up questions and answers that are hidden behind a toggle nobody opens, or worse, not on the page at all. Marking up an address for a location you do not operate from. Marking up a rating for something nobody rated.

The consequence is specific and worth knowing: structured data violations can result in a manual action that removes rich result eligibility. That can apply beyond the single offending page. Trading the site’s rich results for one badge on one page is a bad trade, and it is a trade people make without realising it.

The practical test is simple. For every property in your markup, point at where it appears on the rendered page. If you cannot point at it, remove it.

Review markup: the one to avoid

Do not emit review or aggregate rating markup for your own business on your own website.

This is the most common structured data mistake in the industry and it is made with entirely good intentions. An agent collects genuine testimonials, publishes them on the site, and adds review markup so the stars appear in search results. It seems like an accurate description of real content.

Google’s review snippet documentation is explicit that self serving reviews are not eligible: reviews about a business, on that business’s own site, where the business controls what is published. The reasoning is obvious once stated. A business that selects which reviews to display, and then marks them up with a rating it calculated itself, is describing its own reputation in a format designed to look independent.

There is a second problem specific to this industry. An aggregate rating requires a rating, and a rating requires a scale and a count. On a site with four testimonials and no rating system, any number you emit is invented. Inventing structured data is the fastest way to have the rest of it distrusted.

What to do instead:

• Publish the testimonials for readers. They work perfectly well as text on a page and they are persuasive there.
• Label them honestly. If they are illustrative rather than verified, say so on the page.
• Emit no review markup for them. None.
• Let ratings live where they are independently collected, on the platforms that gather and verify them.

The same applies to sample or illustrative quotes on a marketing site. If the quotes are representative rather than attributed, they are copy, not reviews, and marking them as reviews would be describing them as something they are not.

What to expect, honestly

Not every schema type produces a visible enhancement in search results, and this is the area where expectations are most frequently oversold.

Google maintains a gallery of the structured data features it supports, and that gallery is the authoritative list of what produces a visible result. Types that are not in it are still valid schema.org and still worth emitting where accurate, but they will not produce a badge, a carousel or a panel simply because you added them.

Real estate listings are a case in point. There is no general property listing rich result in web search of the kind that exists for recipes or events. That does not make RealEstateListing markup pointless: it makes the page’s content explicit to anything that reads it, it is the correct description, and the correct description ages well. But it should be added because it is true, not because it is expected to change how the result looks tomorrow.

FAQ markup is another case worth understanding, because its treatment has changed over time. The lesson from that is general rather than specific: what a given markup type produces in search results is decided by the search engine and can change. The markup that survives those changes is the markup that was accurate description in the first place.

Describing the areas you serve

The area served property is the one an agent site underuses, and it is the one most closely aligned with how an agent actually works.

A RealEstateAgent entity can state the geographic areas it serves, as named places rather than as a sentence in a paragraph. That matters because “serving Springfield, Millbrook and the surrounding communities” is prose, and prose has to be interpreted. A list of named administrative areas does not.

Two things are worth getting right here.

The first is that the list should be honest. Area served is a claim about where you work, and a list of forty municipalities from an agent who closes in four of them is the structured data equivalent of stuffing a footer with town names. It is also self defeating, because the pages backing those claims will be thin, and thin pages are the ones that sit unindexed.

The second is that the markup should match the site. If you state that you serve eight areas, there should be eight area pages, each with real content about that area. Structured data that describes a coverage the site does not actually carry is describing something that is not there, which brings us back to the rule this whole piece turns on.

Done properly, the area served list and the area pages reinforce each other. The markup says where you work. The pages prove it. A search engine encountering both has a consistent picture instead of a claim with nothing behind it.

Where to put it, and in what format

Use JSON-LD, in a script block, and put it in the head or at the top of the body.

There are three syntaxes for structured data. Microdata and RDFa interleave the description with the HTML, attribute by attribute, which means every template change risks breaking the markup and every markup change requires touching the layout. JSON-LD keeps the whole description in one block, separate from the markup it describes. Google recommends it, and on maintenance grounds alone it is the right choice: one block, one place to check, one thing to update when a fact changes.

A few practical conventions that save trouble later:

• Use one @id per entity and reference it. Define the business once with an identifier, and let the article, the listing and the breadcrumb refer to that identifier rather than repeating the whole description. When your phone number changes, it changes in one place.
• Use absolute URLs. Relative ones are ambiguous to a consumer that is not resolving them against your page.
• Keep dates in ISO format, with a timezone offset where the time of day matters.
• Generate it from the same data that renders the page. If the markup is written by hand in a separate file, it will drift from the page within months. If both are built from one source, they cannot disagree.

That last point is the one that matters most over time. Structured data goes stale silently. Nothing on the page looks wrong, nobody notices, and the site is quietly describing itself inaccurately for a year.

Keeping it accurate when the facts change

Structured data goes wrong quietly, months after it was written, and the reason is always the same: the page changed and the markup did not.

Three things change on an agent site more often than people expect. The phone number, when a business line is added or a brokerage affiliation shifts. The address, when an office moves or a suite number changes. The areas served, when a farm expands or contracts. Each of those is stated in two places, on the page and in the markup, and the page is the one that gets edited.

The structural fix is to generate the markup from the same source as the page. If the phone number lives in one configuration file and both the contact page and the JSON-LD read from it, they cannot disagree. If the areas served come from the same list that builds the area pages, the markup cannot claim an area that has no page. This is not a sophisticated technique, it is just a decision to hold facts in one place, and it removes an entire class of slow decay.

Where that is not possible, the alternative is a calendar entry. Twice a year, open each page that carries markup, run the point at it test, and fix what has drifted. It is a dull hour and it is considerably better than discovering in Search Console that a template change broke a hundred pages in March.

Testing, and what testing does not tell you

Two tools, two different questions.

The Rich Results Test answers “does this parse, and is it eligible for a feature?” It is the right first check, it catches syntax errors and missing required properties, and it will tell you which feature a block qualifies for.

Search Console answers “what is Google actually seeing on the live site, over time?” This is where you find out that a template change three weeks ago broke the markup on a hundred pages, which no one off test would tell you.

Neither tool answers the question that actually matters, which is “is this true?” A block can parse perfectly, qualify for a feature, and describe a price that is not on the page. The validator has no way to know. That check is yours, and it is the point at it test above.

A minimum set for a working agent site

If you do nothing else:

1. RealEstateAgent on the home page or the contact page, with name, address, telephone, area served and links to your profiles elsewhere.
2. BreadcrumbList on every page below the top level.
3. Article with a Person author on every piece of writing.
4. RealEstateListing on each listing page, describing what is visible.
5. FAQPage only where the questions and answers are genuinely on the page as text.
6. No review or rating markup anywhere on your own site about your own business.

Six decisions. Five of them are a few lines each, generated once from the data you already hold, and the sixth is a decision not to do something.

How this fits with everything else

Structured data is a clarification, not a strategy. It makes a good page easier to understand. It does nothing for a page that has nothing specific to say, because the problem there is not that the description is ambiguous, it is that there is nothing to describe.

The order is always the same. Build pages that answer specific searches, which for an agent means one page per area you serve and one page per listing. Make sure those pages load quickly, which is mostly a photography question. Then describe them accurately in markup so that nothing reading them has to guess.

Do it in that order and the markup is a finishing step that takes an afternoon. Do it in reverse and it is a decoration on an empty room.