SEO für mit KI gebaute Websites: Was wirklich zählt
Eine mit KI gebaute Website kann genauso gut ranken wie jede andere: Suchmaschinen bewerten, was die Seite enthält und wie gut sie den Besucher bedient, nicht welches Werkzeug den Code geschrieben hat. Der Haken ist technisch. Viele KI-Builder erzeugen Single-Page-Apps, die dem Browser eine fast leere HTML-Datei schicken und den Inhalt mit JavaScript zeichnen. Das macht jede Seite für Crawler schwerer lesbar und teilbar. Behebe das mit Prerendering oder Server-Rendering, gib jeder Seite einen eigenen Titel, eine eigene Beschreibung und eine eigene URL, füge eine Sitemap hinzu, halte die Seite schnell und schreibe dann den Teil, den dir kein Tool abnimmt: Inhalte, nach denen Menschen tatsächlich suchen.
Warum Single-Page-Apps in der Suche Probleme haben können
Eine klassische Website sendet den vollständigen Text jeder Seite in ihrem HTML. Eine Single-Page-App (SPA) — die Standardausgabe vieler KI-Builder, typischerweise React mit einem Werkzeug wie Vite — sendet eine kleine HTML-Hülle, etwa ein leeres <div id="root">, plus ein JavaScript-Bundle. Der Browser führt das JavaScript aus, das dann die Seite aufbaut.
Das ist für die Suche aus drei Gründen wichtig:
- Rendern ist ein zusätzlicher Schritt. Google beschreibt drei Phasen für JavaScript-Seiten: Das HTML wird gecrawlt, in einem Headless-Chromium-Browser gerendert und dann das gerenderte Ergebnis indexiert. Googles eigene Richtlinien sagen, dass Server-seitiges Rendering oder Prerendering dennoch sinnvoll ist, weil es für Nutzer und Crawler schneller ist und weil nicht alle Bots JavaScript ausführen können.
- Andere Leser deiner Seite rendern gar nicht. Link-Vorschauen in Chat-Apps und sozialen Netzwerken sowie viele andere Crawler lesen typischerweise nur das anfängliche HTML. Wenn Titel und Vorschaubild erst nach dem Laden per JavaScript gesetzt werden, zeigen diese Vorschauen die Standardwerte der leeren Hülle — oft denselben Titel auf jeder Seite.
- Alles teilt sich eine HTML-Datei. Solange die App sie nicht aktualisiert, hat jede URL denselben
<title>und dieselbe Beschreibung, was Suchmaschinen wenig über jede einzelne Seite verrät.
Das heißt nicht, dass eine SPA nicht indexiert werden kann. Es heißt, dass du dich darauf verlässt, dass der Crawler mehr Arbeit leistet, und dass du die Kontrolle darüber verlierst, was Leser ohne Rendering sehen.
Einen Rendering-Ansatz wählen
Es gibt vier gängige Wege, Crawlern echtes HTML auszuliefern. In grober Reihenfolge, wie stark sie deine App verändern:
| Ansatz | Wie es funktioniert | Geeignet für | Nachteil |
|---|---|---|---|
| Statische Seite | Seiten sind im Voraus gebaute, einfache HTML-Dateien | Marketingseiten, Portfolios, Doku, Blogs | Weniger geeignet für eingeloggte, personalisierte Seiten |
| Prerendering (statische Site-Generierung) | Beim Build wird jede öffentliche Route in eine HTML-Datei gerendert; JavaScript übernimmt danach im Browser | SPAs mit einer bekannten Menge öffentlicher Seiten | Seiten aktualisieren sich nur bei einem neuen Build |
| Server-seitiges Rendering (SSR) | Der Server rendert das HTML für jede Anfrage (Next.js, Remix, Nuxt und ähnliche) | Große oder oft wechselnde öffentliche Inhalte, z. B. Verzeichnisse | Braucht einen laufenden Server; mehr bewegliche Teile |
| Dynamisches Rendering | Bots bekommen vorgerendertes HTML, Menschen die SPA | Veralteter Notbehelf | Google nennt es inzwischen einen Notbehelf statt einer langfristigen Lösung und empfiehlt stattdessen SSR, statisches Rendering oder Hydration |
Eine praktische Regel: Der öffentliche, durchsuchbare Teil deiner Seite sollte statisch oder vorgerendert sein; die eingeloggte App dahinter kann eine normale SPA bleiben. Suchmaschinen sollten ohnehin keine Dashboards indexieren.
Wenn du bei null anfängst und SEO wichtig ist, sag es schon im ersten Prompt, damit die KI ein passendes Setup wählt:
Baue eine Marketingseite für eine Physiotherapie-Praxis mit Seiten für Startseite, Leistungen (eine Seite pro Leistung), Über uns, Preise und Kontakt. SEO ist wichtig: Jede Seite muss ihren vollständigen Inhalt sowie ihren eigenen Titel und ihre eigene Meta-Beschreibung im anfänglichen HTML ausliefern — verwende einen statischen oder vorgerenderten Aufbau, keine reine clientseitige Single-Page-App.
Wenn du bereits eine Vite-SPA hast, bitte um Prerendering der öffentlichen Routen:
Behalte diese React-App bei, aber rendere die öffentlichen Routen (/, /pricing, /about, /blog und jede /blog/:slug) beim Build als statisches HTML vor, jeweils mit eigenem Titel, eigener Meta-Beschreibung, eigener kanonischer URL und eigenen Open-Graph-Tags. Die eingeloggten /app-Routen können clientseitig gerendert bleiben.
Prüfe danach selbst das Ergebnis: Öffne eine Seite, wähle Seitenquelltext anzeigen (nicht das Elemente-Panel der Entwicklerwerkzeuge, das die gerenderte Seite zeigt) und bestätige, dass Text und Titel im rohen HTML stehen.
Die Grundlagen auf der Seite richtig setzen
Das gilt unabhängig vom Rendering-Ansatz.
Titel und Meta-Beschreibungen
- Ein eindeutiger
<title>pro Seite, mit dem Hauptthema der Seite vorne. Rund 50–60 Zeichen sind eine übliche Richtgröße, weil zu lange Titel in den Ergebnissen abgeschnitten werden. - Eine eindeutige Meta-Beschreibung pro Seite — ein Satz, den eine Person anklicken möchte, keine Keyword-Liste. Google kann sie umschreiben, aber eine gute wird oft übernommen.
- Verzichte auf Meta-Keywords. Google sagt, dass das Tag keinen Einfluss auf Indexierung oder Ranking hat.
URLs, Überschriften und Links
- Echte URLs für echte Seiten. Jeder Inhalt braucht einen eigenen Pfad (
/leistungen/sportmassage), nicht einen Tab oder ein Modal, das erst nach einem Klick existiert. Vermeide#-Fragment-Routing für Inhalte, die indexiert werden sollen. - Eine
h1pro Seite, dann eine sinnvolle Gliederung mith2/h3. KI-generierte Designs verwenden Überschriften manchmal zur Gestaltung; bitte um semantische Überschriften. - Crawlbare Links. Verwende echte
<a href>-Links für die Navigation. Schaltflächen, die die Seite per JavaScript wechseln, sind für Crawler unsichtbar, die Links folgen. - Canonical-Tags, die jede Seite auf ihre bevorzugte URL verweisen lassen, damit
?utm=-Varianten und Duplikate mit abschließendem Schrägstrich nicht miteinander konkurrieren. - Aussagekräftiger Alt-Text für bedeutsame Bilder.
Social-Vorschauen
Füge jeder öffentlichen Seite Open-Graph-Tags (og:title, og:description, og:image, og:url) im anfänglichen HTML hinzu. Genau das vergessen SPAs am häufigsten, weil Link-Vorschau-Bots kein JavaScript ausführen.
Sitemaps und robots.txt
Eine Sitemap ist eine XML-Datei, die die URLs auflistet, die indexiert werden sollen. Sie hilft Suchmaschinen, Seiten zu finden, besonders bei neuen Websites mit wenigen eingehenden Links. Laut Googles Dokumentation gilt Stand September 2026:
- Eine einzelne Sitemap kann bis zu 50.000 URLs oder 50 MB unkomprimiert enthalten; größere Websites teilst du mit einem Sitemap-Index auf.
- Google ignoriert
<priority>und<changefreq>. - Google verwendet
<lastmod>nur, wenn es konsistent korrekt ist. Aktualisiere es also bei echten Inhaltsänderungen, nicht bei jedem Build.
Die robots.txt sagt Crawlern, welche Pfade sie nicht crawlen sollen. Verwende sie, um Crawler von /app, /admin und API-Routen fernzuhalten, und verweise in ihr auf die Sitemap. Denke daran: robots.txt stoppt das Crawlen, nicht das Indexieren. Um eine Seite aus den Ergebnissen herauszuhalten, verwende ein noindex-Robots-Meta-Tag und lass die Seite gecrawlt werden.
Reiche die Sitemap in der Google Search Console ein, sobald die Website unter ihrer endgültigen Domain erreichbar ist. Die Search Console zeigt außerdem, welche Seiten indexiert sind und warum andere es nicht sind — das nützlichste kostenlose SEO-Werkzeug, das es gibt.
Strukturierte Daten
Strukturierte Daten sind maschinenlesbare Auszeichnungen, die beschreiben, worum es auf einer Seite geht: eine Organisation, ein lokales Unternehmen, ein Produkt, ein Artikel, ein Event. Google empfiehlt das JSON-LD-Format und ist in zwei Punkten eindeutig:
- Sie können Seiten für Rich Results qualifizieren, garantieren diese aber nicht.
- Sie müssen Informationen beschreiben, die auf der Seite sichtbar sind. Markiere keine Bewertungen, Preise oder FAQs, die Besucher nicht sehen können.
Sinnvolle Ausgangspunkte: Organization oder LocalBusiness auf der Startseite, Product auf Produktseiten, Article auf Blogbeiträgen, BreadcrumbList auf tieferen Seiten. Teste mit Googles Rich-Results-Test.
Füge JSON-LD-strukturierte Daten hinzu: LocalBusiness auf der Startseite mit der Adresse, Telefonnummer und den Öffnungszeiten, die bereits auf der Seite stehen, und Article auf jedem Blogbeitrag. Füge keine Bewertungen oder Rezensionen hinzu.
Geschwindigkeit und Mobil
Google nutzt Signale der Seitenerfahrung, darunter die Core Web Vitals, und Geschwindigkeit ist für Besucher ohnehin wichtig. Googles Schwellen für „gut“, gemessen am 75. Perzentil der Seitenaufrufe, sind:
| Metrik | Misst | Gut |
|---|---|---|
| Largest Contentful Paint (LCP) | Wie schnell der Hauptinhalt erscheint | 2,5 s oder weniger |
| Interaction to Next Paint (INP) | Wie schnell die Seite auf Eingaben reagiert | 200 ms oder weniger |
| Cumulative Layout Shift (CLS) | Wie stark sich das Layout beim Laden verschiebt | 0,1 oder weniger |
Die üblichen Lösungen für mit KI gebaute Websites:
- Bilder — verkleinern, komprimieren, moderne Formate verwenden, Breite und Höhe setzen (das verhindert Layout-Verschiebungen) und Bilder unterhalb des Falzes verzögert laden.
- JavaScript — ein großes Bundle verzögert bei einer SPA alles. Prerendering hilft; ebenso das Aufteilen des Codes pro Route.
- Schriften — Anzahl der Familien und Schnitte begrenzen und die oberhalb des Falzes verwendete vorladen.
- Skripte von Drittanbietern — jedes Chat-Widget und jeder Tracking-Pixel kostet Geschwindigkeit. Behalte nur die, die du tatsächlich nutzt.
Teste die Live-URL mit PageSpeed Insights oder Lighthouse im Mobil-Modus.
Inhalte sind immer noch das Wichtigste
Technische SEO entfernt Hindernisse, sie erzeugt aber keine Nachfrage. Seiten ranken, weil sie eine Suche besser beantworten als die Alternativen. Für die meisten kleinen Websites heißt das:
- Eine Seite pro Thema, nach dem Menschen suchen. Ein Klempner braucht eine Seite pro Leistung und pro Einzugsgebiet, nicht eine „Leistungen“-Seite, die alles auflistet.
- Konkrete, eigenständige Details — Preise, Ablauf, Fotos echter Arbeiten, Antworten auf die Fragen, die Kunden am Telefon stellen.
- Aktualisiert, wenn sich etwas ändert. Veraltete Öffnungszeiten und alte Preise verspielen schnell Vertrauen.
KI kann Seiten schnell entwerfen, was verlockend macht, viele dünne, ähnliche Seiten zu veröffentlichen. Googles Richtlinien richten sich gegen Inhalte, die hauptsächlich zum Ranking statt zum Helfen von Menschen erstellt wurden, egal wie sie entstanden sind. Nutze KI zum Entwerfen und ergänze dann, was nur du weißt. Verzeichnisartige Seiten sind davon am stärksten betroffen; siehe wie du eine Verzeichniswebsite baust, um Listenseiten zu erstellen, die indexiert zu werden lohnen.
Launch-Checkliste
- Öffentliche Seiten liefern den vollständigen Inhalt im anfänglichen HTML (prüfe mit „Seitenquelltext anzeigen“)
- Eindeutiger Titel, Meta-Beschreibung und kanonische URL auf jeder Seite
- Open-Graph-Tags und ein Vorschaubild auf jeder öffentlichen Seite
- Eine
h1pro Seite, echte<a href>-Links, Alt-Text bei Bildern -
sitemap.xmlmit echten URLs;robots.txt, das App- und API-Pfade blockiert - Strukturierte Daten nur für sichtbare Inhalte, getestet
- LCP, INP und CLS im Bereich „gut“ auf dem Handy
- Website unter ihrer endgültigen Domain mit HTTPS und in der Search Console eingereicht
Bevor du Suchverkehr aufbaust, zieh auf deine eigene Domain um — so vermeidest du spätere Weiterleitungen. Siehe wie du eine eigene Domain verbindest. Für den gesamten Bauprozess lies wie du eine Website mit KI baust, und für Seiten, die Besucher überzeugen sollen, wie du eine konvertierende Landingpage baust.
SEO bei Mythex
Mythex hat kein eigenes SEO-Panel; du verbesserst SEO, indem du die App selbst änderst, über Chat oder Code. Neue Web-Apps starten standardmäßig als Vite- und React-Single-Page-App. Wenn Suche wichtig ist, bitte deshalb von Anfang an um eine statische oder vorgerenderte Website oder um Next.js. Die Dokumentation enthält einen Startprompt für Titel, Open-Graph-Tags, Sitemap und robots.txt unter SEO für deine App, und statische Websites behandelt inhaltsorientierte Seiten. Veröffentliche nach Änderungen erneut, damit die Live-Seite sie übernimmt. Eigene Domains sind im Pro-Tarif verfügbar.
Fragen
Sind mit KI gebaute Websites schlecht für SEO?
Nicht grundsätzlich. Suchmaschinen bewerten die Seite, nicht das Werkzeug, mit dem sie erstellt wurde. Das übliche Problem ist technischer Natur: Viele KI-Builder erzeugen Single-Page-Apps, deren Inhalt erst erscheint, nachdem JavaScript läuft, was manche Crawler schlecht verarbeiten. Prerendering oder Server-Rendering behebt das.
Kann Google eine React-Single-Page-App indexieren?
Google kann JavaScript rendern und deshalb eine clientseitig gerenderte React-App oft indexieren. Rendern ist aber ein zusätzlicher Schritt, und Google selbst weist darauf hin, dass nicht alle Bots JavaScript ausführen können. Wo möglich, empfiehlt Google daher Server-seitiges Rendering oder Prerendering.
Sind Meta-Keywords noch wichtig?
Nein. Google erklärt, dass es das Meta-Keywords-Tag weder für die Indexierung noch für das Ranking verwendet. Investiere die Mühe lieber in einen eindeutigen Titel und eine eindeutige Meta-Beschreibung für jede Seite.
Verbessern strukturierte Daten das Ranking?
Strukturierte Daten helfen Suchmaschinen, eine Seite zu verstehen, und können sie für Rich Results qualifizieren, garantieren diese aber nicht. Sie müssen Inhalte beschreiben, die auf der Seite tatsächlich sichtbar sind.