Der Webentwickler empfiehlt React. Der nächste sagt Next.js. Ein Dritter schwört auf Vue. Und alle versichern Ihnen, dass das ‚moderner‘ ist. Was niemand Ihnen erklärt: Für KI-Systeme wie ChatGPT und Perplexity, die Ihre Website crawlen und entscheiden ob sie Sie zitieren, ist ‚moderner JavaScript-Stack‘ oft gleichbedeutend mit ’schwerer lesbar‘ – oder sogar ‚unsichtbar‘.
Das ist keine Polemik gegen moderne Technologien. Es ist eine nüchterne Bestandsaufnahme, wie KI-Crawler funktionieren und was das für die Architektur-Entscheidung Ihrer nächsten Website bedeutet. Dieser Leitfaden erklärt die technischen Zusammenhänge – ohne Entwickler-Jargon, aber mit den Konsequenzen, die für Ihr Marketing und Ihre Sichtbarkeit relevant sind.
Wie KI-Crawler eine Website lesen – und was sie dabei brauchen
Bevor wir den Unterschied zwischen statischen und JavaScript-basierten Websites erklären, müssen wir verstehen, wie KI-Crawler funktionieren. Ein KI-Crawler – also das Programm, das im Auftrag von ChatGPT, Perplexity oder Google AI Overviews Websites liest und indexiert – verhält sich grundsätzlich anders als ein menschlicher Browser.
Was ein Browser tut
Ein Browser lädt eine Webseite herunter, führt dann alle JavaScript-Programme aus, die auf dieser Seite hinterlegt sind, wartet bis alle Daten geladen sind, und stellt erst dann den fertigen visuellen Inhalt dar. Dieser Prozess dauert manchmal Sekunden – aber der Browser hat alle Zeit der Welt.
Was ein KI-Crawler tut
Ein KI-Crawler hat diese Zeit nicht. Er lädt die rohe HTML-Datei einer Webseite herunter – und liest direkt darin. Er führt JavaScript oft gar nicht oder nur eingeschränkt aus. Was er sieht, ist das, was im ursprünglichen HTML steht – nicht das, was JavaScript nachträglich in die Seite lädt.
Das Problem in einem Satz
Wenn der Inhalt Ihrer Website erst durch JavaScript erzeugt wird – also beim ersten Laden der HTML-Datei noch gar nicht im Text steht – sieht ein KI-Crawler eine leere oder halbfertige Seite.Das bedeutet: Er kann Sie nicht zitieren. Er weiß nicht, was Sie anbieten. Für ihn existieren Sie inhaltlich kaum.
Statisches HTML vs. JavaScript-Rendering: Der technische Unterschied
Vereinfacht gibt es drei Arten, wie eine Website ihren Inhalt ausliefern kann:
1. Statisches HTML (Server-Side Rendering / Static Site Generation)
Der gesamte Inhalt ist bereits beim Laden der Seite als fertiger Text im HTML vorhanden. Ein KI-Crawler öffnet die Seite und sieht sofort alle Texte, alle Überschriften, alle FAQ-Antworten, alle Glossar-Einträge. Alles, was für GEO relevant ist, ist sofort und vollständig lesbar.
Beispiele: Einfache WordPress-Seiten ohne schwere JavaScript-Frameworks, klassische HTML-Seiten, Seiten die mit Generatoren wie Hugo oder Eleventy gebaut wurden.
2. Client-Side Rendering (CSR)
Die HTML-Datei ist beim ersten Laden fast leer. Sie enthält nur ein kleines JavaScript-Programm, das dann alle Inhalte erst nachlädt und in die Seite einfügt. Der Nutzer sieht nach kurzer Wartezeit die fertige Seite. Ein KI-Crawler, der kein JavaScript ausführt, sieht eine leere Seite.
Typische Vertreter: Reine React-Anwendungen, Angular-Frontends, Vue.js ohne Server-Side Rendering. Diese Technologien sind exzellent für Web-Applikationen (Online-Konfiguratoren, Portale, interaktive Tools) – aber problematisch für öffentliche, zu indizierende Marketing-Websites.
3. Hybride Ansätze (Server-Side Rendering mit JavaScript)
Frameworks wie Next.js (React) oder Nuxt (Vue) können so konfiguriert werden, dass der erste Seitenaufruf bereits fertig gerendertes HTML ausliefert – und JavaScript dann nur noch für interaktive Funktionen zuständig ist. Wenn korrekt umgesetzt, ist das für KI-Crawler akzeptabel. Die Betonung liegt auf ‚wenn korrekt umgesetzt‘ – viele Implementierungen haben hier Lücken.
Was das für Ihre B2B-Website konkret bedeutet
Für eine klassische B2B-Marketing- und Unternehmenswebsite gelten klare Empfehlungen:
Was gut funktioniert
- WordPress mit sauberem HTML-Output und ohne schwere JavaScript-Frontends – der Standard für informationsorientierte B2B-Websites
- Statische Site Generatoren für sehr performance-kritische Seiten
- Next.js oder Nuxt – aber ausschließlich im Server-Side-Rendering-Modus, nicht als reine Single-Page-Application
- Laravel oder andere PHP-Frameworks, die HTML serverseitig rendern
Was problematisch ist
- Reine React-, Angular- oder Vue-Anwendungen für öffentliche Marketing-Websites ohne SSR-Konfiguration
- Website-Builder, die Inhalte stark per JavaScript nachladen (einige Webflow-Konfigurationen, bestimmte Shopify-Themes)
- Headless-CMS-Setups, bei denen das Frontend rein client-side rendert
Die Konsequenz für den Website-Briefing
Wenn Sie eine Agentur beauftragen, stellen Sie explizit diese Frage:
„Ist der Inhalt dieser Website beim ersten HTTP-Request vollständig als HTML vorhanden – ohne JavaScript-Ausführung?“
Wenn die Antwort ‚Nein‘ oder ‚Es kommt darauf an‘ ist, brauchen Sie eine klare technische Erklärung, wie das GEO-Problem gelöst wird.Die Werbeagentur dmp setzt B2B-Industrie-Websites standardmäßig mit vollständigem HTML-Rendering auf – genau aus diesem Grund.
Performance: Der zweite Grund, warum Technologie-Wahl für GEO relevant ist
Neben der Lesbarkeit ist Performance – also die Ladegeschwindigkeit einer Website – ein eigenständiges Ranking- und GEO-Signal. Google wertet Core Web Vitals direkt in das Ranking ein. Und eine langsam ladende Seite erzeugt auch höhere Absprungraten bei menschlichen Nutzern.
Die drei wichtigsten Core Web Vitals
LCP (Largest Contentful Paint): Wie lange dauert es, bis das größte sichtbare Element einer Seite geladen ist? Zielwert: unter 2,5 Sekunden. Schwere JavaScript-Frameworks sind hier häufig die Hauptbremse.
CLS (Cumulative Layout Shift): Wie stark ’springt‘ der Inhalt beim Laden herum? Zielwert: unter 0,1. JavaScript-geladene Inhalte, die nachträglich eingefügt werden, verursachen oft Layout Shifts.
INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Klicks? Zielwert: unter 200 Millisekunden. Schwere JavaScript-Bundles verlangsamen die Reaktionszeit.
Gerade für B2B-Industriewebsites, die oft viele technische Bilder, 3D-Visualisierungen und umfangreiche Produktbeschreibungen enthalten, ist das Thema Performance besonders relevant. Schlechte Core Web Vitals können eine ansonsten gut optimierte Website im GEO-Ranking deutlich zurückwerfen.
Die Rolle von Hero-Videos und schweren Mediendateien
Viele B2B-Industriewebsites setzen auf eindrucksvolle Hero-Videos – rotierende Maschinen, Animationen, Showreels. Diese sind visuell wertvoll und stärken den Markeneindruck. Sie haben aber eine kritische GEO-Schwäche: Wenn ein unkomprimiertes MP4-Video als erstes Element der Seite lädt, verzögert das den LCP massiv.
Best Practices für Videos und schwere Medien
- Videos immer lazy-loaden: Das Video lädt erst, wenn der Nutzer in den entsprechenden Bereich scrollt – nicht sofort beim Seitenaufruf
- Poster-Bild definieren: Ein statisches Bild erscheint sofort, während das Video im Hintergrund lädt
- Videos komprimieren: Ein 50 MB-MP4 kann oft auf 5 MB reduziert werden ohne sichtbaren Qualitätsverlust
- Bilder als WebP ausliefern: WebP ist 25–35 % kleiner als PNG oder JPEG bei gleicher Qualität
- Responsive Bilder: Für Mobile kleinere Bildvarianten ausliefern – ein Desktop-Bild mit 2000 Pixeln Breite auf einem Smartphone zu laden ist reine Ressourcenverschwendung
Was das für einen Website-Relaunch bedeutet
Wenn Sie eine neue Website planen oder einen Relaunch in Auftrag geben, sollten technische Architektur und GEO-Tauglichkeit von Anfang an in das Briefing einfließen. Die fünf wichtigsten Technologie-Entscheidungen:
1. CMS-Wahl: Inhaltskontrolle vs. technische Flexibilität
WordPress bleibt für die meisten B2B-Marketing-Websites die richtige Wahl – weil es serverseitig rendert, weil Redakteure einfach Inhalte pflegen können, weil es ein riesiges Plugin-Ökosystem für Schema Markup und SEO gibt. Für spezielle Anforderungen (Konfiguratoren, Portale) können andere Technologien sinnvoll sein – aber die öffentliche Marketing-Website sollte HTML-zuerst sein.
2. Plugin-Strategie: Weniger ist mehr
Jedes WordPress-Plugin lädt zusätzliche JavaScript- und CSS-Dateien. Eine schlecht optimierte WordPress-Website mit 50 Plugins kann langsamer sein als eine React-App. Die Faustregel: Nur Plugins installieren, die einen klar definierten Zweck haben. Regelmäßig ausmisten.
3. Caching: Pflicht, nicht Kür
Ein Caching-Plugin erstellt statische Versionen der WordPress-Seiten und liefert diese aus, ohne den Server jedes Mal neu berechnen zu lassen. Das reduziert Ladezeiten drastisch. Für B2B-Websites empfehlenswert: WP Rocket, W3 Total Cache oder die Caching-Funktion des Hosting-Anbieters.
4. CDN: Globale Performance für internationale Kunden
Ein Content Delivery Network (CDN) speichert Kopien Ihrer Website auf Servern weltweit und liefert diese vom geografisch nächstgelegenen Server aus. Für ein österreichisches oder deutsches Maschinenbauunternehmen mit internationalen Kunden in Asien oder Amerika ist das besonders relevant – und oft der einfachste Performance-Gewinn.
5. Hosting: Die unterschätzte Grundlage
Billiges Shared Hosting ist für B2B-Unternehmenswebsites keine Option. Managed WordPress Hosting bei Anbietern wie Kinsta, WP Engine oder Raidboxes kostet 30 bis 100 Euro pro Monat – und liefert dafür deutlich bessere Performance, automatische Backups und Sicherheitsupdates. Diese Investition amortisiert sich bereits durch bessere Core Web Vitals und damit bessere Sichtbarkeit.
FAQ – Häufige Fragen zu Website-Technologie und GEO
Muss ich meine bestehende WordPress-Website neu aufsetzen, um GEO-tauglich zu sein?
Nicht zwingend. Wenn Ihre WordPress-Website serverseitig rendert (was bei den meisten Standard-WordPress-Installationen der Fall ist), sind die technischen Grundvoraussetzungen für GEO gegeben. Was dann typischerweise fehlt, sind inhaltliche Maßnahmen: FAQ-Blöcke, Glossare, Schema Markup, llms.txt. Diese können auf eine bestehende Website nachgerüstet werden, ohne das Fundament zu ändern.
Wir haben eine React-Website. Müssen wir sie komplett neu bauen?
Nicht unbedingt, aber es hängt von der Konfiguration ab. Wenn Ihre React-Website mit Next.js im Server-Side-Rendering-Modus betrieben wird, ist sie für KI-Crawler grundsätzlich lesbar. Wenn es eine reine Single-Page-Application ist, die Inhalte komplett per JavaScript lädt, dann ist eine Migration auf SSR oder ein Wechsel der Technologie sinnvoll. Das sollte ein technisches Audit klären.
Wie messe ich, ob meine Website für KI-Crawler lesbar ist?
Öffnen Sie Ihre Website und wählen Sie im Browser ‚Seitenquelltext anzeigen‘ (Strg+U oder Cmd+U). Was Sie dort sehen, ist das, was ein KI-Crawler sieht. Wenn der Quelltext Ihre wichtigsten Inhalte – Überschriften, Fließtext, FAQ-Antworten – direkt enthält, ist die Seite gut lesbar. Wenn Sie hauptsächlich JavaScript-Code und kaum lesbaren Text sehen, haben Sie ein GEO-Problem.
Was ist der Unterschied zwischen robots.txt und llms.txt?
Die robots.txt ist die klassische Steuerdatei für alle Crawler – sie legt fest, welche Bereiche einer Website gecrawlt werden dürfen. Die llms.txt ist eine neue, ergänzende Datei speziell für KI-Sprachmodelle. Sie beschreibt in einfachem Text, wer das Unternehmen ist, was die wichtigsten Inhalte sind und wie KI-Systeme den Content nutzen sollen. Es ist die ‚Visitenkarte für KI-Crawler‘ – und 2026 für GEO-optimierte Websites Pflicht.
Wie oft sollte eine B2B-Website technisch überprüft werden?
Empfehlenswert ist ein technisches Audit mindestens einmal pro Jahr sowie nach jedem größeren Update des CMS oder der verwendeten Plugins. Core Web Vitals sollten kontinuierlich über Google Search Console monitoriert werden. Konkret: Alerts einrichten, die benachrichtigen, wenn der LCP über 3 Sekunden steigt oder der CLS über 0,25 – beides sind Schwellenwerte, ab denen Google aktiv Ranking-Abzüge vornimmt.
Beeinflusst die Domain-Endung (.de vs. .at) die GEO-Sichtbarkeit?
Ja, indirekt. Länderspezifische Domains (.de, .at, .ch) signalisieren geografische Relevanz. Für DACH-Industrieunternehmen empfiehlt die Werbeagentur dmp eine primäre .de-Domain als Hauptpräsenz mit 301-Weiterleitung von der .at-Domain – da das Suchvolumen im deutschsprachigen Raum auf .de-Domains deutlich höher ist und KI-Systeme die .de-Domain als gewichtigere Entität werten.
