Be the source: getting AEC data ready for AI search

Open Google today and type a real engineering question, the long kind with a design code and a material in it. Before you see a single link, Google has already written you an answer, with a handful of sources underneath. That short list is the new first page of search results. For an AEC company, it is worth checking which sources appear for the questions its customers ask.

Google is already an AI search engine

When people hear “AI search,” they think of ChatGPT. That misses the bigger shift. At Google I/O in May 2026, Google reported that AI Overviews had passed 2.5 billion monthly users and its conversational AI Mode more than one billion, and announced that the two are merging into a single AI search experience.1 Your customers don’t need to switch to a chatbot. The search engine they have used for twenty years has become one.

Engineering questions are exactly the kind of search that now gets an answer instead of a list: long, specific and full of constraints. Which software can design a CLT floor to NDS? Which anchor is approved for cracked concrete? The engineer reads the answer, and perhaps one of its sources. Add ChatGPT, Claude, Gemini and Perplexity, and the pattern is the same everywhere.

For twenty years, a good product page with sharp photos was the finish line. Today it is raw material. Whether an engineer ever sees it depends on whether an AI system can read it, trust it and quote it. Alongside search rankings, I now pay attention to whether a page is cited as a source in AI answers.

“A product page should make it clear what the product supports, where it applies and what its limits are.”

What localization taught me about AI visibility

Since 2021 I have worked on websites and content for engineering software, adapting it for engineers in the United States, Canada and Europe. A large part of that work is localization, and it taught me the lesson that matters most for AI search long before AI search existed.

Translating a page is easy. Localizing it means asking how an engineer in another market looks for the same thing: which design code they work with, which terms they use, which spelling they expect. A translated page can be perfectly correct and still invisible to the people it was written for, because it answers a question they never ask.

Example: a timber page for North America

The project that made this click for me was a timber design solution page I optimized for structural engineers in the United States and Canada, on behalf of an engineering software vendor. The original content came from a European product context. It was accurate and thorough, and it spoke the language of Eurocode. But a timber engineer in Portland or Vancouver doesn’t think in Eurocode. They design to NDS in the U.S. and CSA O86 in Canada, and that is how they phrase their questions, whether they type them into Google or ask an assistant.

So I reworked the page around the engineer’s question rather than around the product. The North American design codes are named explicitly in the text, where an engineer would look for them. The language follows U.S. English and U.S. terminology, with “design standards” as the umbrella term instead of “Eurocode.” Nothing on the page depends on the reader, or the machine, translating from one standards world to the other.

The same applied to the images. A screenshot is part of the message: an engineer who sees a model checked to Eurocode, with European labels throughout the interface, reads it as a product made for someone else. So I localized the screenshots too. They show the North American design standards and U.S. English in the software’s interface, so engineers recognize their own working environment at a glance. And because search and AI systems still rely mainly on the text around an image, every image also gets localized text: a title, alt text, a description and a caption that name the design standard shown. The screenshot convinces the engineer. The text around it is what a machine can quote.

The lesson goes well beyond timber. I name the relevant standards explicitly so readers and search systems do not have to infer which ones the product supports. If your pages only mention Eurocode, you won’t be named when someone asks about AISC 360, whatever your software actually supports. Localization used to be for people. Now it is for machines as well.

One page, several regions

Localization by IP address is part of my daily work. One page, one URL, and visitors from France, Italy, Germany or the United States each see content adapted to their market, for example local contacts, language or the design standards they work with. For people it works very well. For machines it needs care, because a crawler sees only the variant served to its own IP address. By default, Googlebot crawls from U.S. addresses, and AI crawlers largely operate from the U.S. as well.3 Unless you plan for it, the French, Italian and German versions of your content may never reach an AI answer at all. The fix is to let IP localization shape the experience, while every regional version of an important fact also has its own URL, linked with hreflang. Visitors get the right variant automatically, and crawlers can still find all of them.

How a fact travels into an AI answer

Localization also changed how I measure content. An AI system doesn’t browse your site the way a person does. It extracts facts and decides which statements it trusts enough to repeat. A hundred vague pages lose to one page that states precisely which design codes you support, in which units, for which markets. So when I review a website, I don’t count pages. I follow single facts, such as a supported design code, a load capacity or an office location, and check whether each one survives the trip from the server into an AI answer. I think of it as a load path. Every member along the way has to carry the fact:

Like any load path, it fails at its weakest member, and the first two fail more often than people expect. According to crawl data from Vercel and MERJ, the major AI crawlers don’t execute JavaScript at all.2 Google does, which is why a page can rank in Google and show up in AI Overviews, yet be empty to ChatGPT, Claude and Perplexity. Content that appears only after a script runs, in a configurator, a web app or an interactive table, simply isn’t there for them. Text inside PDFs and images reaches them unreliably at best.

My rules for AI-ready data

1. HTML is the source of truth. PDFs, images and videos are copies of it, never the only place a fact lives.
2. One fact, one canonical page. State it there clearly and identically everywhere else.
3. Markup never says more than the page. I don’t put a fact into structured data unless the visible page states it. Markup that contradicts the page doesn’t fix confusion; it automates it.
4. Write in the language of the question. The design code, the units and the spelling of the market you want to reach, in your text and in your images.
5. Answer first. Lead with the answer and make every passage stand on its own. AI systems quote passages, not whole pages.
6. Don’t start with llms.txt. It belongs on documentation and API sites, where coding assistants actually read it. On a marketing site it is a cheap experiment at best, and Google says its Search ignores it. Fix crawlability first.

Try it this week

You don’t need an agency to see where you stand. Three checks take less than half an hour:

1. Fetch a key page the way a crawler does. No browser, no JavaScript. Search for a sentence that matters, such as a product name or a supported design code:
   curl -sL -A "GPTBot" https://example.com/product | grep -i "AISC 360" Copy

   No output = AI crawlers can’t see this sentence
2. Read every robots.txt you own, including app, docs and support subdomains, and ask whoever runs your CDN or firewall whether AI bots are being blocked.
3. Ask the questions your customers ask. Put ten real ones into Google’s AI Mode, ChatGPT, Claude and Perplexity. Note whether you are named, how you are described and whom the answers cite instead.

Copy-paste kit: a robots.txt that lets AI in

If the second check left you unsure, start here. This is the baseline I use for a typical company website. Replace the domain and the private paths with your own:

# robots.txt for https://example.com
# Default: all crawlers, including AI search and AI assistants,
# may read everything except private areas
User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /account/

# Optional: opt out of AI model training only.
# ChatGPT search (OAI-SearchBot) and Claude search
# (Claude-SearchBot) are separate bots and stay allowed.
User-agent: GPTBot
User-agent: ClaudeBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Two things I check every time: Disallow: / under User-agent: * belongs only on staging, never on a live site, because it closes the door to every crawler at once. And every subdomain needs its own file; docs.example.com doesn’t inherit the rules of your main domain, and a CDN or firewall rule can block AI bots no matter what robots.txt says.

Where I would start

Start with one product or service page that matters to your business. Check whether it clearly states what you offer, which standards or approvals apply, and which markets it serves. Then check whether those facts are accessible in the page’s HTML and consistent with your documentation. That gives you a concrete starting point for improving the rest of the site.

Most AEC companies already own the material: product pages, datasheets, project references, documentation. Software vendors need a readable page for every capability and supported code. Manufacturers need their load values, fire ratings and approvals in text, not only in PDFs. Engineering firms need project pages that state system, material, code and role instead of a photo gallery. None of it is new content. It is the content you have, made readable.

Martin Motlík

Independent AEC digital strategist and Head of Web Content at Dlubal Software. Writing about AI, BIM and engineering-software marketing.