AI Search for Architecture Firms: How to Make Project Experience Visible

AI search tools (ChatGPT Search, Perplexity, Gemini, Copilot, Google AI Overviews) can't extract facts from PDFs, JS-only image carousels, or vague marketing copy. If an architecture firm's project experience isn't published as structured, crawlable, plain-text content, it effectively doesn't exist for these systems — no matter how strong the actual portfolio is. This post covers what AI search is doing technically, why it matters for AEC business development, and the concrete implementation steps (schema, llms.txt, alt text, crawler access) to fix it.

The problem, concretely

A facilities director researching firms for a new hospital project opens an AI assistant and asks:

"Which architecture firms have recent experience with LEED Platinum healthcare projects?"

If a firm has exactly that experience but stores it as a downloadable PDF portfolio or a <div>-based image slider with no real text content, an AI crawler retrieves basically nothing usable. The firm doesn't get cited — not because the work doesn't exist, but because it was never made machine-readable.

What AI search is doing under the hood

Classic search engines rank and return links; the user does the reading. AI search tools work differently: crawlers like GPTBot, ClaudeBot, PerplexityBot, and Google-Extended fetch content, and a retrieval-augmented generation (RAG) pipeline synthesizes a direct answer, typically citing two or three sources instead of ten blue links.

That synthesis step depends entirely on whether the model can parse and trust the source content. Common failure modes on architecture firm sites:

• Project details only exist inside PDF portfolios or scanned brochures (not real HTML text)
• Project galleries rendered client-side with no server-rendered text fallback
• No structured data (schema.org) describing what a "project," "client," or "organization" is
• Marketing copy that's all adjectives ("award-winning," "innovative") with zero checkable facts
• robots.txt blocking AI crawlers outright, sometimes unintentionally

If none of your project content is extractable as clean text with clear semantics, there's nothing for the model to retrieve — and nothing to cite.

Why this matters for the business side

This isn't just a technical curiosity — it's shifting how AEC firms get shortlisted. Procurement teams and developers increasingly use AI assistants to build a firm longlist before any human outreach happens. Consequences:

• You can't relationship-sell an algorithm — if it has no facts about relevant experience, it won't surface the firm, regardless of offline reputation
• Referral research is now AI-assisted; even warm intros get a quick AI fact-check first
• Firms with cleaner structured data can outrank firms with objectively stronger portfolios but worse content architecture
• This is additive to existing SEO work, not a replacement — firms delaying this are ceding visibility to firms already doing it

Implementation: making project pages AI-legible

1. One real, indexable page per project

Not a lightbox modal — an actual crawlable URL with server-rendered text: name, client type, location, size, typology, completion year, budget range (if shareable), certifications, and a written narrative.

2. Structured data (schema.org / JSON-LD)

Add explicit, unambiguous facts via JSON-LD rather than relying on the model to infer them from prose:

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Riverside Outpatient Care Center",
  "creator": {
    "@type": "Organization",
    "name": "Example Architecture Firm"
  },
  "about": "Healthcare Architecture",
  "dateCreated": "2023",
  "locationCreated": {
    "@type": "Place",
    "address": "Portland, OR"
  },
  "award": "LEED Platinum Certification",
  "description": "200,000 sq ft outpatient facility designed to LEED Platinum standard, reducing energy use intensity by 42% versus ASHRAE baseline."
}

Pair this with Organization schema on your about/homepage and FAQPage schema on FAQ sections — both are directly useful to AI retrieval, not just traditional search.

3. Ship an llms.txt

An emerging (not yet universally adopted, but increasingly recognized) convention: a plain-text file at /llms.txt summarizing the site, the firm, and links to key structured content, written specifically for LLM consumption rather than human browsing.

# Example Architecture Firm

> Full-service architecture firm specializing in healthcare, 
> higher education, and net-zero commercial design.

## Project Experience
- [Riverside Outpatient Care Center](https://example.com/projects/riverside-outpatient) — LEED Platinum healthcare, 2023
- [Cascade Science Building](https://example.com/projects/cascade-science) — Higher-ed lab building, 2022

## Firm Info
- [About & Credentials](https://example.com/about)
- [FAQ](https://example.com/faq)

4. Fix crawler access deliberately, not by default

Check robots.txt for accidental blanket disallows. Don't block GPTBot, ClaudeBot, or PerplexityBot reflexively out of vague IP concerns if the content is already public marketing material — that just guarantees zero visibility. Decide access deliberately per crawler, per section.

User-agent: GPTBot
Allow: /projects/
Allow: /about/

User-agent: PerplexityBot
Allow: /projects/
Allow: /about/

5. Real alt text, not filenames

alt="riverside-hospital-04.jpg" gives a model nothing. alt="South-facing curtain wall of Riverside Outpatient Care Center showing the daylighting strategy used to reduce lighting energy load" gives it a citable fact.

6. Convert PDF portfolios to HTML

PDFs are technically crawlable in principle, but text extraction quality is inconsistent, layout/reading order is often mangled, and PDFs rarely carry the structured markup above. Rebuild top case studies as real pages; keep the PDF as a downloadable extra, not the primary source.

7. Performance and rendering basics still matter

If project content is client-side rendered only (heavy SPA with no SSR/prerendering), confirm crawlers relying on raw HTML fetches (many AI crawlers don't execute JS) can still see the text. Server-side rendering or static generation for project pages is the safer default here.

A practical perspective from https://softwin.io/

We've applied this exact playbook with architecture and engineering clients: audit crawler access and current content structure first, convert the strongest project case studies into dedicated pages with schema, add an llms.txt, fix robots.txt and rendering issues, then monitor citation behavior across AI platforms and iterate — because conventions here (especially llms.txt adoption and per-crawler behavior) are still evolving month to month. In most engagements, the firm already has the project experience needed; the gap is almost entirely in how it's published.

Common mistakes

• Publishing project data only as downloadable PDFs
• Client-side-only rendering with no server-rendered text for crawlers that don't execute JS
• Blanket Disallow rules in robots.txt that unintentionally block AI crawlers
• No schema markup on project or organization pages
• Generic or missing alt text on project photography
• Marketing copy with no checkable, specific facts
• Treating this as identical to keyword-based SEO instead of its own discipline

FAQ

Is this different from traditional SEO work we're already doing?
Overlapping but distinct. Traditional SEO optimizes for ranked position in a link list; AI search optimization (GEO) optimizes for whether a model can extract and confidently cite specific facts in a synthesized answer. Clean HTML, schema, and crawlability benefit both, but AI search puts a much higher premium on structured, checkable facts over keyword density.

Does exposing this to AI crawlers create IP or confidentiality risk?
Only if you're publishing genuinely non-public information, which you shouldn't be doing regardless. For already-public marketing content (completed projects, general firm credentials), there's no meaningful new exposure — you're just making public facts machine-readable too.

How long until we see AI citations change?
Varies by crawler recrawl frequency and platform, but meaningful movement is often visible within a few months of publishing well-structured content — sometimes faster than traditional organic SEO gains, since these systems weight clarity and recency heavily.

Do we need a full site rebuild?
Usually not. Most fixes are targeted: server-rendering or static-generating project pages, adding JSON-LD, publishing llms.txt, correcting robots.txt, and rewriting thin project copy — not a ground-up redesign.

Is llms.txt an official standard?
No — it's an emerging convention, not a ratified standard, and adoption across AI crawlers is inconsistent today. It's low-cost to implement and directionally useful, but it should supplement solid schema markup and crawlable HTML, not replace them.

Wrapping up

The gap here usually isn't a lack of project experience — it's a publishing and markup problem. Architecture firms sitting on decades of strong, relevant work are losing AI search visibility to firms with thinner portfolios but cleaner, more structured content. The fix is mostly mechanical: real pages, real schema, real alt text, deliberate crawler access, and a maintained llms.txt.

If you're a developer or technical lead at an AEC firm looking to audit this, SoftWin offers a practical AI search readiness audit — happy to share more detail in the comments or you can reach out directly.