For the people who build the product

What does AEO look like for a Dubai real estate developer?

It's not a content calendar. It's a question set, a facts layer most developers have never published, a trust surface, working plumbing, and a wave-by-wave measurement habit - built to answer the questions buyers ask before they ever reach a sales team.

28 Labs · September 2026

For a Dubai developer, AEO means building a program around the real questions buyers ask AI engines - which area, is off-plan safe, which developer, what's the yield, does this unit clear the golden visa threshold - and publishing the comparable, dated facts those questions need. Most Dubai developer sites currently answer none of them, which is why the answers cite portals and news archives instead. The program has five parts, and none of them is "write more blog posts."

Why this is a developer problem, not a marketing problem

We covered the diagnosis already: ask an AI engine about Dubai areas, yields, or off-plan safety, and the answer draws on property portals, long-running news archives, and agency yield breakdowns - almost never on the developer's own site. That's not a ranking accident. It's a publishing gap. Portals and agencies publish comparable, dated facts. Developer sites publish renders and a lead form.

This piece is the execution side of that diagnosis: what a developer actually builds to close the gap, concretely, without buying content that doesn't match how buyers ask.

Part one: the question set

You can't fix visibility on questions you haven't defined. Most Dubai buyer questions cluster into a short list, and a developer's program should be measured against the ones relevant to its markets, not a generic keyword list:

This is the same discipline we use across every category we measure - see how to build a buyer question set for the general method. For a developer, the set has to be specific to the submarkets and project types that developer actually sells, frozen once you start measuring, and re-run wave over wave.

Part two: the answerable-facts layer

This is the part almost nobody has built. Engines cite the source that answers the comparison question with numbers and dates attached, not the source with the nicest renders. That means publishing the facts forums and portals currently own:

Handover history
Every completed project, original handover date versus actual handover date, in one place. If the record is good, this is the single highest-leverage page a developer can publish - it's the exact fact "is [developer] reliable" needs answered.
Service charge ranges
Per project, per unit type, published before a buyer has to ask a sales agent. Absence of this number is what pushes the question to forums.
Payment plan structures, side by side
Not one plan described in marketing copy - a table comparing the developer's current and past plans, so an engine can answer "is this payment plan good" with something other than a generic explainer.
Escrow and compliance explanation
Plain, specific description of how the developer's escrow account works under Law 8 of 2007 - funds released against certified construction milestones, not against a marketing timeline.
Yield by unit type
Where the developer has data - rental performance by unit type and area - published with dates, the way an agency yield table already is.

Part three: the trust surface

Answerable facts only work if the entity behind them is unambiguous. That means consistent company facts everywhere the developer appears (name, registration, project list, founding date), claims that hold up if a journalist or an AI engine checks them, and genuine third-party coverage - press, RERA registration records, industry recognition - that corroborates what the developer publishes about itself. An AI engine weighs a developer's own claim about its handover record more heavily when independent coverage says the same thing.

Part four: the plumbing

Most developer sites are JavaScript-heavy brochureware built around a single active launch. That's a rendering and crawling problem before it's a content problem - if an engine's crawler can't reliably read the page, the facts on it don't matter. The fix is unglamorous: server-renderable pages for the facts layer, fast load times, clean HTML, and Article or FAQ schema on the pages meant to answer a specific buyer question. None of that is exotic. Most developer sites simply haven't done it, because the site was built to convert a lead form, not to be read by a machine building an answer.

Part five: the measurement cadence

1
Baseline wave: run the question set now
2
Publish the facts layer
3
Re-wave on the same frozen questions
4
Repeat around launches and model updates
A single measurement is a snapshot. A launch changes the questions worth asking; a model update can change the answers without anything on the developer's site changing at all.

AI answers move for reasons that have nothing to do with a developer's own actions - a competitor publishes a handover record, a model gets retrained, a news cycle shifts coverage. The only way to know whether a change in the answer came from the developer's own publishing or from something upstream is to keep the question set identical and re-run it.

What NOT to buy

What moves an AEO number

  • Handover track record with dates, published once and kept current
  • Service charge tables per project
  • Payment plans compared side by side
  • Escrow and compliance explained in plain terms
  • Fast, crawlable pages with the right schema

What doesn't

  • "Luxury living in Dubai" blog volume
  • Lifestyle copy with no comparable numbers
  • A payment plan graphic with no delivery history behind it
  • One-off content with no re-measurement
  • Brochureware rebuilt to look nicer, not to answer more

The intermediation cost this fixes

Every buyer who reaches a developer through a portal costs margin - the portal or agency answered the early questions, built the relationship, and the developer meets the buyer last, with a shortlist and a yield expectation already set by someone else. AI answers are re-deciding who gets met first, faster than most developers have registered. The developer who publishes comparable, dated, answerable facts first becomes the source engines cite in its own category. Right now, in most Dubai submarkets, nobody has done it - which means the opening is still open.

The honest readThis isn't about writing more content. It's about publishing the specific, comparable facts a buyer needs to decide - facts most developers already have internally and have simply never put in a format an AI engine can read and trust. The developer that does it first doesn't just get cited more. It changes which questions get answered with its own name in them.

What we do about it

We run the actual buyer questions for a developer's market - area choice, off-plan safety, golden visa thresholds, developer trust, yield by area - against ChatGPT, Claude, Gemini and Perplexity, and read what comes back: which sources get cited, which developers get named, and where the answer sends the buyer instead. From there the facts layer and plumbing work follows directly from what the baseline wave shows is missing. Audits run from AED 8,000 to 40,000 depending on depth. Everything we report re-derives to a specific question and a specific answer, the same discipline covered in how to build a buyer question set and applied to this category in how AI answers Dubai property questions.

28 Labs measures how AI engines answer real buyer questions - and what moves the counts. Every number we publish re-derives to specific questions and engines. try28labs.com