Werden Sie zur Quelle: AEC-Daten fit für die KI-Suche machen

Öffnen Sie heute Google und geben Sie eine echte Ingenieursfrage ein – eine dieser langen, mit Bemessungsnorm und Werkstoff. Noch bevor Sie einen einzigen Link sehen, hat Google Ihnen bereits eine Antwort geschrieben, mit einer Handvoll Quellen darunter. Diese kurze Liste ist die neue erste Seite der Suchergebnisse. Für ein AEC-Unternehmen lohnt es sich zu prüfen, welche Quellen bei den Fragen seiner Kunden erscheinen.

Google ist bereits eine KI-Suchmaschine

Bei „KI-Suche“ denken die meisten an ChatGPT. Damit übersehen sie die größere Verschiebung. Auf der Google I/O im Mai 2026 meldete Google, dass die Übersicht mit KI (AI Overviews) mehr als 2,5 Milliarden monatliche Nutzer erreicht hat und der dialogorientierte KI-Modus (AI Mode) mehr als eine Milliarde, und kündigte an, beide zu einer einzigen KI-Sucherfahrung zusammenzuführen.1 Ihre Kunden müssen nicht zu einem Chatbot wechseln. Die Suchmaschine, die sie seit zwanzig Jahren nutzen, ist selbst einer geworden.

Ingenieursfragen sind genau die Art von Suche, die heute eine Antwort statt einer Trefferliste bekommt: lang, konkret und voller Randbedingungen. Welche Software kann eine BSP-Decke nach NDS bemessen? Welcher Dübel ist für gerissenen Beton zugelassen? Der Ingenieur liest die Antwort und vielleicht eine ihrer Quellen. Nehmen Sie ChatGPT, Claude, Gemini und Perplexity hinzu – das Muster ist überall dasselbe.

Zwanzig Jahre lang war eine gute Produktseite mit gestochen scharfen Fotos das Ziel. Heute ist sie Rohmaterial. Ob ein Ingenieur sie je zu sehen bekommt, hängt davon ab, ob ein KI-System sie lesen, ihr vertrauen und sie zitieren kann. Neben den Suchrankings achte ich heute auch darauf, ob eine Seite in KI-Antworten als Quelle zitiert wird.

„Eine Produktseite sollte klar sagen, was das Produkt unterstützt, wofür es sich eignet und wo seine Grenzen liegen.“

Was mich Lokalisierung über KI-Sichtbarkeit gelehrt hat

Seit 2021 arbeite ich an Websites und Inhalten für Ingenieursoftware und passe sie für Ingenieure in den USA, in Kanada und in Europa an. Ein großer Teil dieser Arbeit ist Lokalisierung – und sie hat mich die wichtigste Lektion für die KI-Suche gelehrt, lange bevor es KI-Suche überhaupt gab.

Eine Seite zu übersetzen ist einfach. Sie zu lokalisieren heißt zu fragen, wie ein Ingenieur in einem anderen Markt nach derselben Sache sucht: mit welcher Bemessungsnorm er arbeitet, welche Begriffe er verwendet, welche Schreibweise er erwartet. Eine übersetzte Seite kann völlig korrekt sein und trotzdem für die Menschen unsichtbar bleiben, für die sie geschrieben wurde – weil sie eine Frage beantwortet, die diese nie stellen.

Beispiel: eine Holzbau-Seite für Nordamerika

Das Projekt, bei dem es bei mir klick gemacht hat, war eine Lösungsseite zur Holzbaubemessung, die ich im Auftrag eines Herstellers von Ingenieursoftware für Tragwerksplaner in den USA und Kanada optimiert habe. Der ursprüngliche Inhalt stammte aus einem europäischen Produktkontext. Er war präzise und gründlich und sprach die Sprache des Eurocodes. Doch ein Holzbauingenieur in Portland oder Vancouver denkt nicht in Eurocode. Er bemisst in den USA nach NDS und in Kanada nach CSA O86 – und so formuliert er auch seine Fragen, ob er sie bei Google eintippt oder einem Assistenten stellt.

Also habe ich die Seite um die Frage des Ingenieurs herum aufgebaut statt um das Produkt. Die nordamerikanischen Bemessungsnormen werden im Text ausdrücklich genannt, genau dort, wo ein Ingenieur sie sucht. Die Sprache folgt amerikanischem Englisch und US-Terminologie, mit „design standards“ als Oberbegriff statt „Eurocode“. Nichts auf der Seite setzt voraus, dass der Leser – oder die Maschine – von einer Normenwelt in die andere übersetzt.

Dasselbe galt für die Bilder. Ein Screenshot ist Teil der Botschaft: Ein Ingenieur, der ein nach Eurocode nachgewiesenes Modell mit europäischen Beschriftungen in der gesamten Oberfläche sieht, liest es als Produkt für jemand anderen. Also habe ich auch die Screenshots lokalisiert. Sie zeigen die nordamerikanischen Bemessungsnormen und eine Softwareoberfläche in amerikanischem Englisch, sodass Ingenieure ihre eigene Arbeitsumgebung auf einen Blick wiedererkennen. Und weil Such- und KI-Systeme sich nach wie vor vor allem auf den Text rund um ein Bild stützen, bekam jedes Bild auch lokalisierten Text: einen Titel, einen Alt-Text, eine Beschreibung und eine Bildunterschrift, die die gezeigte Bemessungsnorm nennen. Der Screenshot überzeugt den Ingenieur. Der Text darum herum ist das, was eine Maschine zitieren kann.

Die Lektion reicht weit über den Holzbau hinaus. Ich nenne die relevanten Normen ausdrücklich, damit Leser und Suchsysteme nicht erraten müssen, welche davon das Produkt unterstützt. Wenn Ihre Seiten nur den Eurocode erwähnen, werden Sie nicht genannt, wenn jemand nach AISC 360 fragt – ganz gleich, was Ihre Software tatsächlich unterstützt. Lokalisierung war früher für Menschen. Heute ist sie auch für Maschinen.

Eine Seite, mehrere Regionen

Lokalisierung nach IP-Adresse gehört zu meinem Arbeitsalltag. Eine Seite, eine URL – und Besucher aus Frankreich, Italien, Deutschland oder den USA sehen jeweils Inhalte, die auf ihren Markt zugeschnitten sind, etwa lokale Ansprechpartner, die Sprache oder die Bemessungsnormen, mit denen sie arbeiten. Für Menschen funktioniert das sehr gut. Bei Maschinen ist Sorgfalt gefragt, denn ein Crawler sieht nur die Variante, die an seine eigene IP-Adresse ausgeliefert wird. Standardmäßig crawlt der Googlebot von US-Adressen aus, und auch KI-Crawler arbeiten größtenteils aus den USA.3 Wenn Sie das nicht einplanen, erreichen die französische, italienische und deutsche Version Ihrer Inhalte womöglich nie eine KI-Antwort. Die Lösung: Die IP-Lokalisierung gestaltet das Nutzererlebnis, und zugleich hat jede regionale Version eines wichtigen Fakts eine eigene URL, verknüpft per hreflang. Besucher bekommen automatisch die richtige Variante, und Crawler finden trotzdem alle.

Wie ein Fakt in eine KI-Antwort gelangt

Die Lokalisierung hat auch verändert, wie ich Inhalte bewerte. Ein KI-System durchstöbert Ihre Website nicht wie ein Mensch. Es extrahiert Fakten und entscheidet, welchen Aussagen es genug vertraut, um sie zu wiederholen. Hundert vage Seiten verlieren gegen eine einzige, die genau sagt, welche Bemessungsnormen Sie unterstützen, in welchen Einheiten und für welche Märkte. Wenn ich eine Website prüfe, zähle ich deshalb keine Seiten. Ich verfolge einzelne Fakten – etwa eine unterstützte Bemessungsnorm, eine Tragfähigkeit oder einen Bürostandort – und prüfe, ob jeder davon den Weg vom Server bis in eine KI-Antwort übersteht. Ich stelle mir das als Lastpfad vor. Jedes Bauteil auf dem Weg muss den Fakt tragen:

Wie jeder Lastpfad versagt er am schwächsten Bauteil, und die ersten beiden versagen häufiger, als man erwartet. Laut Crawl-Daten von Vercel und MERJ führen die großen KI-Crawler überhaupt kein JavaScript aus.2 Google schon – deshalb kann eine Seite bei Google ranken und in der Übersicht mit KI erscheinen und für ChatGPT, Claude und Perplexity trotzdem leer sein. Inhalte, die erst erscheinen, nachdem ein Skript gelaufen ist – in einem Konfigurator, einer Web-App oder einer interaktiven Tabelle –, existieren für sie schlicht nicht. Text in PDFs und Bildern erreicht sie bestenfalls unzuverlässig.

Meine Regeln für KI-taugliche Daten

1. HTML ist die maßgebliche Quelle. PDFs, Bilder und Videos sind Kopien davon, nie der einzige Ort, an dem ein Fakt steht.
2. Ein Fakt, eine kanonische Seite. Dort klar formuliert, überall sonst identisch.
3. Markup sagt nie mehr als die Seite. Ich nehme einen Fakt nur dann in strukturierte Daten auf, wenn die sichtbare Seite ihn nennt. Markup, das der Seite widerspricht, beseitigt keine Verwirrung, sondern automatisiert sie.
4. Schreiben Sie in der Sprache der Frage. Bemessungsnorm, Einheiten und Schreibweise des Markts, den Sie erreichen wollen – im Text und in den Bildern.
5. Die Antwort zuerst. Beginnen Sie mit der Antwort und machen Sie jeden Abschnitt für sich allein verständlich. KI-Systeme zitieren Passagen, nicht ganze Seiten.
6. Fangen Sie nicht mit llms.txt an. Die Datei gehört auf Dokumentations- und API-Websites, wo Coding-Assistenten sie tatsächlich lesen. Auf einer Marketing-Website ist sie bestenfalls ein günstiges Experiment, und laut Google ignoriert die Google-Suche sie. Sorgen Sie zuerst für Crawlbarkeit.

Testen Sie es noch diese Woche

Um zu sehen, wo Sie stehen, brauchen Sie keine Agentur. Drei Prüfungen dauern weniger als eine halbe Stunde:

1. Rufen Sie eine wichtige Seite so ab wie ein Crawler. Kein Browser, kein JavaScript. Suchen Sie nach einem Satz, auf den es ankommt, etwa einem Produktnamen oder einer unterstützten Bemessungsnorm:
   Terminal Kopieren

   curl -sL -A "GPTBot" https://example.com/product | grep -i "AISC 360"

   Keine Ausgabe = KI-Crawler sehen diesen Satz nicht
2. Lesen Sie jede robots.txt, die Sie betreiben, auch auf App-, Docs- und Support-Subdomains, und fragen Sie die Verantwortlichen für Ihr CDN oder Ihre Firewall, ob KI-Bots blockiert werden.
3. Stellen Sie die Fragen Ihrer Kunden. Geben Sie zehn echte Fragen in den KI-Modus von Google, in ChatGPT, Claude und Perplexity ein. Notieren Sie, ob Sie genannt werden, wie Sie beschrieben werden und wen die Antworten stattdessen zitieren.

Vorlage zum Kopieren: eine robots.txt, die KI hereinlässt

Wenn Sie nach der zweiten Prüfung unsicher sind, beginnen Sie hier. Das ist die Basis, die ich für eine typische Unternehmenswebsite verwende. Ersetzen Sie die Domain und die privaten Pfade durch Ihre eigenen:

# robots.txt für https://example.com
# Standard: Alle Crawler, auch KI-Suche und KI-Assistenten,
# dürfen alles lesen außer privaten Bereichen
User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /account/

# Optional: nur dem Training von KI-Modellen widersprechen.
# Die ChatGPT-Suche (OAI-SearchBot) und die Claude-Suche
# (Claude-SearchBot) sind eigene Bots und bleiben erlaubt.
User-agent: GPTBot
User-agent: ClaudeBot
Disallow: /

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

Zwei Dinge prüfe ich jedes Mal: Disallow: / unter User-agent: * gehört nur auf eine Staging-Umgebung, nie auf eine Live-Website, denn es sperrt alle Crawler auf einmal aus. Und jede Subdomain braucht ihre eigene Datei: docs.example.com übernimmt die Regeln Ihrer Hauptdomain nicht, und eine CDN- oder Firewall-Regel kann KI-Bots blockieren, ganz gleich, was in der robots.txt steht.

Wo ich anfangen würde

Beginnen Sie mit einer Produkt- oder Leistungsseite, die für Ihr Geschäft wichtig ist. Prüfen Sie, ob sie klar sagt, was Sie anbieten, welche Normen oder Zulassungen gelten und welche Märkte Sie bedienen. Prüfen Sie dann, ob diese Fakten im HTML der Seite zugänglich sind und mit Ihrer Dokumentation übereinstimmen. Damit haben Sie einen konkreten Ausgangspunkt, um den Rest der Website zu verbessern.

Die meisten AEC-Unternehmen haben das Material längst: Produktseiten, Datenblätter, Projektreferenzen, Dokumentation. Softwarehersteller brauchen eine lesbare Seite für jede Funktion und jede unterstützte Norm. Bauproduktehersteller brauchen ihre Tragfähigkeiten, Feuerwiderstandsklassen und Zulassungen als Text, nicht nur in PDFs. Ingenieurbüros brauchen Projektseiten, die Tragsystem, Werkstoff, Norm und ihre eigene Rolle nennen, statt nur eine Fotogalerie zu zeigen. Nichts davon ist neuer Inhalt. Es ist der Inhalt, den Sie schon haben – nur lesbar gemacht.

Martin Motlík

Unabhängiger AEC-Digitalstratege und Leiter Web-Content bei Dlubal Software. Schreibt über KI, BIM und Marketing für Ingenieursoftware.

Alle Beiträge →