AI search and commercial real estate: what an assistant can actually see.

A tenant rep used to open a portal. Some of them now open a chat window first and type something close to what they would have said out loud: second generation restaurant space near Buena Park, two to three thousand feet, drive-thru if possible. The assistant answers in a paragraph and a few links. Whether your property is in that answer has very little to do with how the flyer looks and almost everything to do with whether the facts exist as readable text on a page a crawler is allowed to fetch.

What the assistant is actually doing

It helps to separate three different things, because they have different fixes and only two of them are worth your attention.

A live fetch, at the moment of the question. A search-connected assistant runs a query, gets back results, and opens some of the pages to read them. This is the path that can surface a vacancy you listed last week.
An index built ahead of time by a crawler. Slower to update than a live fetch, faster than anything involving retraining. This is where most citations come from.
The model's training data. Frozen, months old at best, and never where a current availability lives. Nothing you publish today changes it in any timeframe that matters to a listing.

So the work is aimed at the first two, and both of them are ordinary web plumbing. The crawlers are named and documented: OpenAI publishes its bots page listing GPTBot, OAI-SearchBot, and ChatGPT-User as three separate agents doing three separate jobs, and Anthropic and Perplexity publish theirs. You can look up every name and decide about each one, which matters because they are separable: an owner who does not want a property's copy in a training set can still welcome the search crawler that produces citations.

All of that runs on robots.txt, a voluntary protocol standardized as RFC 9309 by the IETF in 2022. It is an instruction, not a lock, and the reason to get it right is that the well-behaved crawlers, the ones attached to the assistants people actually use, do respect it. We have seen brokerage sites that quietly block half the internet because a developer copied a robots file out of a template years ago and nobody read it since.

The PDF problem

Here is the uncomfortable part for an industry that markets in documents. Most commercial real estate marketing is a PDF. The offering memorandum is a PDF. The flyer is a PDF. The tour book is a PDF. Many of them exist only as email attachments or as files sitting behind a form, which means the deal facts inside them are not on the public web in any form a machine can read.

An assistant asked about your building cannot open an attachment that was sent to forty tenant reps. It can only read a page. If the square footage, the cross streets, the zoning, the ceiling height, and the availability date live exclusively inside a designed document, the property is invisible to that entire path, no matter how good the document is. We build a lot of those documents and we still say this plainly.

An assistant cannot read your flyer. It can only read the page you were going to put the flyer on.

The fix is not to publish the confidential material. It is to be deliberate about the line. Marketing facts belong on a public page: address, spaces, sizes, use, condition, timing, contact. Financials belong behind the gate, with the confidentiality agreement recorded, which is exactly what a deal room is for. A listing that publishes the first half and gates the second half loses nothing and becomes findable. A listing that gates everything is a rumor.

Say the facts in text

This sounds too simple to be the answer, and it is most of the answer. Property pages routinely bury their own facts inside images. The address is set in the hero graphic. The suite sizes are labels on the site plan. The traffic counts are drawn onto an annotated aerial. All of that is correct design work for a human, and all of it is a blank space to a crawler.

So repeat yourself in text. On the Lincoln site we built for a 2,660 SF corner suite in Buena Park, the traffic counts are labeled on the aerial where a tenant expects to see them, and they also appear in a plain table with the source and the year attached to each figure: the city's published GIS layer for the street segments, Caltrans for the freeway context. That table is there for tenant reps first, because sourced numbers are how you survive a conversation with someone who knows the corridor. That it is also the only version a machine can read is a second benefit that cost nothing. The build is written up in the three day case notes and in the case study.

The practical checklist for a property page is short. The address as text. Each suite with its size in digits. The use and any zoning language a searcher would actually type. Availability status with a date on it. The rate, or an honest rate on request. A named contact with a phone number. If a fact would come up in the first phone call, it should be a sentence on the page.

Structured data, and what it is worth

Schema.org markup gets discussed as if it were a switch that turns on citations. It is not. Google's own guidance on AI features in Search says there is no special markup for AI Overviews: pages that can be indexed are eligible, and the same preview controls that govern an ordinary snippet, nosnippet and max-snippet and data-nosnippet, govern what can be shown. Google's rich results gallery documents the content types that earn a visual treatment in search, and a commercial lease listing is not among them.

What markup does buy is disambiguation. It states, in a form that leaves no room for a guess, which building this is, where it sits, what the page is, and who published it. On the Marbella Plaza and Lincoln case studies we mark up WebPage, Place, CreativeWork, and a BreadcrumbList; the service pages carry ProfessionalService and a real FAQ block. We cannot prove that any particular citation came from that markup, and we do not tell clients otherwise. It is cheap, it is correct, and it removes ambiguity. That is the whole claim.

What we do on our own site, and why

Our robots file names the answer-engine crawlers explicitly and allows them: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot and Applebot-Extended, CCBot. That is a position, not a default, and it is one worth taking on purpose rather than inheriting. A studio that publishes its methods wants them read. A client with a confidential disposition may want the opposite, and the crawler names give you the granularity to decide property by property.

We also publish an llms.txt at the root, a plain text summary of what the studio does and where the important pages live. It follows the proposal at llmstxt.org, published by Jeremy Howard in 2024. Being straight about it: no major assistant has committed to reading that file, and we do not present it to clients as a ranking factor. It costs an afternoon, it doubles as a clean internal summary of the business, and if the convention gets adopted the file is already there. When something is cheap and might matter, we do it and we say which bucket it is in.

The last piece is delivery. A crawler that fetches a page and gets an empty shell waiting on JavaScript may or may not come back to render it. Our property sites ship the content in the markup and load fast on a phone in a parking lot, which was already the requirement for tenants standing in front of the building. The specifics of that are in page speed for property websites, and the same discipline is what makes the pages readable to everything else.

What you cannot measure, and what you can

There is no rank tracking inside an assistant. Two people asking the same question in the same hour can get different answers, and the same person can get a different answer by rephrasing. A position report for AI search is a number somebody invented.

What you can do is modest and still useful. Watch your referrers: visits arriving from chatgpt.com, perplexity.ai, and similar hosts show up in analytics like any other source, and they are worth a line in the owner's report next to the portals. Separately, write down the ten questions a tenant rep or a buyer would plausibly ask about your property type and your submarket, ask them once a month, and keep the answers with the date. That is a log, not a metric, and it will tell you within a quarter whether your listings are turning up. It belongs alongside the rest of what an owner should be getting, which we lay out in website analytics for listings.

What to do this quarter, in order

Read your robots.txt. Confirm nothing is blocking the search crawlers by accident. This takes five minutes and is the only item here that can be silently costing you everything.
Get the facts out of the PDFs. Every active listing needs a public page stating the marketing facts in text. Gate the financials, publish the rest.
One property, one durable URL. A page that moves loses whatever recognition it built. The tradeoffs between a property domain, a subdomain, and a nested path are in our note on domain names.
Keep availability current. A stale suite is worse than no suite, on your own site and on the portals both. The upkeep rhythm is in portal listing hygiene.
Mark up the basics, expect nothing dramatic. Correct, cheap, worth doing, not a growth strategy.
Start the log. Ten questions, once a month, dated.

None of this is a new discipline. It is the same work that made a property page useful to a human being who is standing in the parking lot with a phone: say what the building is, say it in words, publish it where it can be reached, and keep it true. The classic version of that argument is in our SEO guide, and it has aged well, because the assistants are reading the same web everyone else is. If you want the pages built this way rather than audited later, that is what we do.

Start a project

Want to know what an assistant says about your property today?

Send the address → See the Marbella case study