Warum Schema in der AI-Ära mehr zählt, nicht weniger
Es hält sich der Mythos, Schema sei obsolet, weil LLMs unstrukturierten Text parsen können. Das Gegenteil stimmt. LLMs parsen unstrukturierten Text generativ — das heißt, sie generieren auch Halluzinationen, Mehrdeutigkeiten und selbstbewusst falsche Antworten. Schema ist der Weg, der Engine einen maschinenlesbaren Faktencheck dessen zu geben, was der Text behauptet. Es ist der Unterschied zwischen „das Modell glaubt, Ihre Marke sei ein Pharmaunternehmen" und „das Modell weiß, dass Ihre Marke ein Pharmaunternehmen ist, weil das Schema es sagt und der Text es bestätigt". Jede Engine, die wir gemessen haben, belohnt das kohärente Paar.
Die Schema-Typen, die wirklich zählen
Organization — einer pro Website, der kanonische Knoten. Mit name, url, logo, sameAs (auf Wikidata, LinkedIn, Crunchbase etc.), foundingDate, address und contactPoint. Das ist der Wurzelknoten, auf den jeder andere Schema-Block referenzieren sollte.
ProfessionalService / Service / Product — für jedes Angebot. Name, description, serviceType, provider (per @id zurück auf die Organization), areaServed, offers. Hier sind die meisten Websites entweder abwesend oder liefern Schrott.
Article — auf jeder redaktionellen Seite. Headline, description, datePublished, dateModified, author (mit @id), publisher (mit @id auf die Organization), mainEntityOfPage. Entscheidend für Artikel-Zitierungen.
FAQPage — auf Service- und Artikelseiten, die Fragen beantworten. Jede Question bekommt ihre Answer explizit, strukturiert und deckungsgleich mit dem Fließtext. FAQPage nicht als Keyword-Stuffing-Vehikel missbrauchen — Engines ignorieren oder werten ab.
BreadcrumbList — auf jeder Seite. Unglamourös. Hohe Verzinsung. Sie sagt der Engine, wo die Seite in der Hierarchie der Website sitzt.
HowTo — auf schrittbasierten Inhalten. Stark genutzt von Google AI Overviews bei „Wie mache ich"-Anfragen.
Der Zug mit dem höchsten Hebel: stabile @id-Verkettung
Was ernsthaftes Schema von dekorativem Schema trennt: stabile @id-Referenzen, die über die gesamte Website einen kohärenten Graphen bauen. Der Organization-Block jeder Seite nutzt dieselbe @id (z. B. https://ihreseite.de/#organization). Jeder Service-Block referenziert dieselbe @id als provider. Jeder Article referenziert dieselbe Organization als publisher. Das Ergebnis: Eine Antwortmaschine, die eine einzelne Seite parst, kann den gesamten Knowledge Graph der Marke rekonstruieren. Genau das belohnen LLMs — weil ihre internen Entitätsmodelle ohnehin so strukturiert sind.
Drei Fehler, die Zitieranteile killen
Fehler 1 — Schema liefern, das dem Text widerspricht. Wenn Ihr Schema „gegründet 2015" sagt und Ihre About-Seite „gegründet 2018", verliert die Engine das Vertrauen in beides. Konsistenz ist das ganze Spiel.
Fehler 2 — FAQPage-Blöcke mit Keywords vollstopfen. Jede moderne Antwortmaschine hat Filter dafür. FAQPage mit Marketing-Fragen zu füllen, die keine echten Fragen sind, führt dazu, dass Ihr Schema ignoriert oder die Seite abgewertet wird. Nur FAQ-Schema für Fragen liefern, die echte Nutzer wirklich stellen.
Fehler 3 — instabile oder nicht auflösbare @ids. Wenn Ihre @ids nicht auf echte URL-Fragmente auflösen oder sich zwischen Seitenaufrufen ändern, kann die Engine die Knoten nicht zu einem Graphen verbinden. Wählen Sie eine Konvention (z. B. https://ihreseite.de/#organization) und nutzen Sie sie überall.
Eine minimale Schema-Architektur zum Starten
Jede Seite: BreadcrumbList. Jede Startseite: Organization + WebSite. Jede Service-Seite: Service + FAQPage + BreadcrumbList. Jeder Artikel: Article + FAQPage + BreadcrumbList. Jede Produktseite: Product + FAQPage + BreadcrumbList. Das deckt 95 % der GEO-relevanten Fälle einer typischen B2B-Website ab — und ein Senior Engineer implementiert es sauber in etwa zwei Wochen.