Knowledge Graph Modul 500 €

Nach WordPress-Migration oder anderer Stack-Modernisierung haben viele KMU schnelles HTML — aber nur wenige URLs mit Substanz. Die AI-Readiness-Studie (Modern Stack, 6.675 Audits) zeigt flächig schwache Extrahierbarkeit: Agent-Ready Ø 25/100, llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %, robots 72,5 %, Markdown-Negotiation 0,3 %, Legacy-CMS 69,4 %. Ein thematischer Seitenkatalog schließt die Lücke zwischen „Marke bekannt“ und „Leistung zitierbar“. Dieses Thema ist bewusst Angebotsseite mit Methode — Lieferumfang, Abgrenzung zu Google’s Knowledge Graph, Reihenfolge nach Migration und die Trennung Readiness vs. Sichtbarkeit.

Was ist das Knowledge-Graph-Modul — und was nicht?

Antwort zuerst: Das Modul liefert deinen eigenen Themenkatalog auf der Webseite — nicht Googles Knowledge Panel und nicht eine magische „KI-Ranking-Garantie“.

Im Glossar Knowledge Graph (Begriff) ist ein Graph ein Netz aus Knoten (Entities) und benannten Beziehungen. Auf deiner Webseite heißt das praktisch: eigene URLs für Leistungen, Regionen, FAQ und Fachbegriffe, die sich gegenseitig erklären und verlinken. Googles Knowledge Graph und ein Knowledge Panel sind fremde Systeme. Das Modul erhöht die Chance, dass Maschinen deine Fakten korrekt extrahieren — es verspricht kein Panel und keine einzelne ChatGPT-Antwort.

Abgrenzung in einem Satz:

Warum reicht eine modernisierte Startseite für GEO nicht?

Antwort zuerst: Google und generative Engines brauchen thematische Anker-URLs — eine schnelle Homepage allein liefert zu wenig extrahierbare Passagen für Leistungs-, Regions- und FAQ-Intent.

Ohne Themenkatalog ranken und zitieren Systeme vor allem den Markennamen. Der Knowledge Graph schafft zusätzliche, zitierfähige Einstiege und macht GEO & AI-Sichtbarkeit operational. Eine Entity ohne verwandte Themen ist für Maschinen eine Visitenkarte — kein Wissensnetz.

Typische Symptome nach Cutover:

1. Search Console: Impressions nur auf Markenqueries.
2. ChatGPT/Perplexity nennen Wettbewerber bei „Physio in …“, dich nur bei Markenprompt.
3. FAQ leben nur als Akkordeon auf der Startseite — ohne eigene, zitierfähige URL.
4. Regionen und Leistungen teilen sich eine dünne Sammelseite ohne Answer-First.

Für dokumentzentrierte Intent-Verdichtung ohne teures Query-Sampling siehe QI-GEO. Warum WordPress-HTML oft scheitert: Next.js vs WordPress in der KI-Suche.

Eine Entity ohne verwandte Themen ist für Maschinen eine Visitenkarte — kein Wissensnetz.

Was unterscheidet AI-Readiness von AI-Sichtbarkeit?

Antwort zuerst: AI-Readiness misst, ob Maschinen deine Webseite technisch und strukturell extrahieren können; AI-Sichtbarkeit misst, ob generative Systeme dich tatsächlich nennen oder zitieren — beides ist Ziel, aber nicht austauschbar.

AI-Readiness (technische Audit-Scores): sauberes HTML, erreichbare Bots, Sitemap, robots, JSON-LD, optional llms.txt, Markdown-Negotiation, wenig Builder-Rauschen. Census-Benchmark: Agent-Ready Ø 25/100.

AI-Sichtbarkeit (Citation / Mentions): wirst du bei Intent-Prompts genannt, verlinkt oder als Quelle genutzt? Das hängt von Inhalt, Autorität, Konkurrenz und Modell-Verhalten ab — nicht nur von einem fehlenden llms.txt.

Harte Trennregel bei Modern Stack: Fehlen von llms.txt oder niedrige Agent-Ready-Scores allein sind kein Nachweis für „unsichtbar in ChatGPT“. Solche Gaps erklären, warum Extraktion und Grounding schwerer sind — nicht, dass ein Modell dich nie nennen könnte. Der Knowledge Graph adressiert die inhaltliche Brücke: thematische URLs mit Claims und Entities. Stack und Schema bleiben Voraussetzung — siehe Reihenfolge unten.

Was der Census zu Themenlücken und AI-Readiness sagt

Antwort zuerst: Der Census zeigt flächig dünne Maschinen-Schichten und Legacy-Last — thematische URL-Dichte und Claims fehlen oft parallel.

In 6.675 Audits der AI-Readiness-Studie:

Stichprobe = auditierte Dienstleister-Webseiten im Outreach-/Studienkontext — keine DE-weite Bevölkerungsstatistik. Interpretation: Readiness-Lücken und Themenlücken koexistieren. Migration behebt den Legacy-Bottleneck; der Knowledge Graph behebt die thematische Dünne.

Warum nach der Migration — nicht statt?

Antwort zuerst: Themen auf Pagebuilder-DOM und Plugin-Chaos zu „optimieren“ multipliziert Rauschen; erst stabiles HTML und stabile URLs, dann Katalog.

Modern Stack defaultet auf diese Reihenfolge:

1. WordPress-Migration / Webseite-Modernisierung
2. optional Redesign, wenn Story und Layout nicht tragen
3. Knowledge Graph (Themen, Entities, Claims, Schema)
4. Conversion & Anfragen auf denselben Einstiegen

Warum nicht parallel zur Legacy-Origin:

• Redirect-Matrix und Canonicals sind noch in Bewegung — Themen-URLs würden doppelt umgezogen.
• Gutenberg-/Elementor-Markup erschwert Answer-First-Extraktion (Pagebuilder-Ablösung).
• Schema und Meta wären Theme-Plugin-Zufall statt Code-Kontrolle (strukturierte Daten für GEO).
• Princeton-Taktiken (Stats, Zitate, Quellen) wirken auf extrahierbarem HTML — nicht auf DIV-Wüsten.

Parallel buchbar nur, wenn Kernseiten und Cutover-Plan bereits stehen und die Ziel-URLs fest sind. Sonst: Stack zuerst, Katalog danach.

Was liefert das Modul konkret für 500 €?

Antwort zuerst: Du erhältst einen abgestimmten Katalog aus Leistungs-, FAQ- und Fachseiten — jeweils mit Direct Answer, Key Takeaways, Entities, Claims und Schema auf dem modernen Stack.

Typischer Umfang:

1. Themen- und Leistungsseiten mit answer-first-Abschnitten
2. FAQ-Seiten oder FAQ-Blöcke zu echten Kundenfragen (FAQ-Struktur)
3. Entity-Verlinkung im Fließtext ([…](/themen/…)-Logik wie auf modern-stack.de)
4. Claims mit Quellen an kritischen Aussagen
5. Technische Basis: kanonische URLs, Meta, JSON-LD wo sinnvoll
6. Interne Link-Matrix zwischen Leistungen, Regionen und Glossarbegriffen

Preis: 500 € fest als Zusatzmodul. Nicht enthalten: jahrelange Lektorat-Pflege, unbegrenzt viele Stub-Seiten, Ads, Outreach-Versand. Der Katalog ist der Startpunkt, den du erweiterst. Optional ergänzen wir llms.txt im Rahmen der Maschinenschicht.

Beispielhafte Themen (lokal anpassbar)

• Leistung × Region (Webseite-Modernisierung Bad Schönborn)
• FAQ zu Migration, Kosten, Redesign
• Vergleichsthemen (WordPress-Migration)
• Prozessseiten (Cutover, Redirects)
• Branchen-Intent (AI-Sichtbarkeit Steuerberater)

Was liefern Entities, Claims, Links und Schema?

Antwort zuerst: Vier Bausteine machen eine Themen-URL zitierfähig — Name und Beziehung klar, Aussage belegbar, Navigation maschinenlesbar, Struktur maschinenlesbar.

Entities

Eine Entity ist ein benanntes Ding mit stabiler Identität: Firma, Leistung, Ort, Begriff. Auf der Seite heißt das: klare H1, konsistente Bezeichnung, Verlinkung zu verwandten Entities statt Pronomen-Nebel. Glossar und Regionen werden im Fließtext verknüpft — z. B. Bruchsal, Kraichgau, Entity.

Claims

Kritische Aussagen tragen Quelle und Kontext (Zahl + Jahr + URL). Census-Zahlen gehören an die Aussage, nicht in einen Fußnoten-Friedhof. Claims ohne Beleg bleiben Marketing — und sind für GEO schwach.

Interne Links

Jede Themen-URL braucht bidirektionale Sinn-Links: Leistung ↔ Region ↔ FAQ ↔ Marke. Keine Orphan-Pages. Interne Links sind die sichtbare Kante des Graphen — Schema allein ersetzt sie nicht.

Schema (JSON-LD)

Pro URL ein konsistenter @graph mit stabilen @id-Werten: Service, FAQPage, Organization, Place — je nach Seitentyp. sameAs nur für Identitätsäquivalenz, nicht als Themen-Spam. Census: nur 41,9 % liefern überhaupt JSON-LD; das Modul setzt Schema pro Themen-URL, nicht einmalig auf der Startseite.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Service",
      "@id": "https://example.com/leistungen/migration#service",
      "name": "Webseite-Modernisierung",
      "provider": { "@id": "https://example.com/#organization" },
      "areaServed": { "@id": "https://example.com/regionen/bad-schoenborn#place" }
    }
  ]
}

Prinzip: sichtbarer Text und JSON-LD widersprechen sich nicht. Schema ohne Answer-First-Body ist Dekoration.

Wie greifen Princeton-GEO-Taktiken auf Knowledge-Graph-Seiten?

Antwort zuerst: Statistiken, Zitate und Quellen gehören auf Seiten, die eine Frage sauber beantworten — genau das ist das Seitenmodell des Moduls.

Aggarwal et al. (arXiv:2311.09735, KDD 2024) zeigen Visibility-Lifts durch belegbare Fakten statt vager Claims. Paper-Befunde sind kein Produktranking-Versprechen — aber sie erklären, warum Knowledge-Graph-Seiten der natürliche Ort für Cite/Stats/Quotes sind.

Praktisch pro Seite:

1. Direct Answer im ersten Absatz der Sektion
2. Eine greifbare Zahl mit Quelle (Census, Studie, Messwert)
3. Klare Entity-Namen statt „wir/unser Team“-Nebel
4. FAQ zu Anschlussfragen
5. Interne Links zu verwandten Entities

Empirie-Kontext: GEO-Empirie 2026/2027.

Wie priorisieren wir Themen für den Katalog?

Antwort zuerst: Nicht jedes Keyword bekommt eine Seite — Priorität haben kaufnahe, lokal relevante und einwandklärende Themen.

Priorität haben Themen, die:

1. Kaufnah sind (Leistungen, Preise/Ablauf, Migration vs. Redesign)
2. Lokal relevant sind (Region × Leistung)
3. Häufige Einwände klären (Dauer, Inhalte behalten, Plugins)
4. Differenzierung tragen (Stack, GEO, Wartung)

Wir starten schlank: lieber 8–15 dichte Seiten als 40 dünne. Princeton-aligned heißt: jede Seite braucht Fakten und klare Aussagen, nicht Fülltext. Ortsseiten ohne Conversion-Brücke priorisieren wir nicht nur wegen Search-Console-Impressionen — kommerzielle und Studien-URLs zuerst, Place-Entities wenn sie die Marken-/Leistungsbrücke tragen.

Wie hängen Knowledge Graph und Conversion zusammen?

Antwort zuerst: Knowledge-Graph-Seiten erzeugen Einstiege; Conversion stellt sicher, dass jede Seite denselben Anfrageweg bietet — sonst steigt Traffic ohne Pipeline.

Conversion & Anfragen (ab 500 €) setzt Primär-CTA, schlanke Formulare, Trust und WhatsApp. Ohne einheitliche Conversion-Pfade multipliziert der Katalog Einstiege, die nirgendwo hinführen. Reihenfolge oft: Migration → optional Redesign → Knowledge Graph → Conversion (oder Conversion parallel auf festen Kernseiten).

Wie hängt das mit der Mallorca-Expats-Referenz zusammen?

Antwort zuerst: Mallorca Expats zeigt live, wie thematische Struktur plus moderner Stack Sichtbarkeit erzeugen — Modern Stack überträgt die Methode, nicht fremden Content.

Eigene Themen, eigene Regionen (Bruchsal, Kraichgau, Landkreis Karlsruhe, Rhein-Neckar), eigene Entities. Kurz: Der Knowledge Graph ist dein Themenkatalog für Menschen und Maschinen — fest kalkuliert, GEO-tauglich, nach der technischen Basis.

Wann lohnt sich das Modul — und wann nicht?

Antwort zuerst: Sinnvoll, wenn Stack und Kernangebot tragen, aber thematische URLs und zitierfähige Antworten fehlen — nicht als Ersatz für Migration oder schwaches Angebot.

Sinnvoll bei: Marken-only-Sichtbarkeit, FAQ nur auf der Startseite, Regionen/Leistungen ohne eigene Dense-URLs, GEO-Ziel nach Cutover.

Allein zu wenig, wenn: Origin noch Legacy/Pagebuilder ist → zuerst Migration; Layout und Ask begraben Conversion → Redesign/Conversion; Angebot unklar → Conversion vor Themenflut.

Was kostet das Modul — und was ist nicht enthalten?

Antwort zuerst: 500 € fest nach abgeschlossener Webseite-Modernisierung — Themenkatalog im vereinbarten Scope, kein Stundenkontingent.

Im Modul typisch:

• Themeninventar und Priorisierung (8–15 Startseiten-Scope üblich)
• Answer-First-Seiten mit FAQ
• Entity-Links und Claim-/Quellen-Nähe
• Schema/Meta/Canonicals für den Scope
• Interne Link-Matrix

Nicht enthalten: unbegrenzt Content-Produktion, laufendes Redaktionsabo als Ersatz, Ads, Outreach-Kampagnen, Google-Knowledge-Panel-„Optimierung“, Shop-Kataloge. Preise im Kontext: Preise & Pakete. Eltern-Angebot: Webseite-Modernisierung.

Welche Grenzen hat das Modul — und was misst Erfolg?

Antwort zuerst: Der Katalog erhöht zitierfähige Einstiege und Extrahierbarkeit; er garantiert keine Prompt-Antwort, kein Google-Panel und keinen festen Citation-Share.

Erfolg misst du pragmatisch:

1. Baseline: Marken- vs. Themen-Impressions (Search Console), vorhandene FAQ-/Leistungs-URLs, Agent-Ready-/Schema-Stichprobe.
2. Lieferung: 8–15 dichte Seiten live, intern verlinkt, mit Schema und Claims.
3. Vergleich: neue thematische Landing-Impressions, Indexierung der Katalog-URLs, qualitative Prompt-Stichprobe (Brand vs. Intent) — ohne erfundene „+X % Citations“.
4. Pipeline: Anfragen über die neuen URLs nur zählen, wenn Conversion-Pfade gesetzt sind.

Grenzen klar benennen: Modelle ändern Grounding-Verhalten; Konkurrenz hat eigene Entities; lokale Nischen reagieren unterschiedlich. Deshalb trennen wir Readiness-Scores von Sichtbarkeitsbeobachtung — und versprechen keine Panel-Platzierung.

Checkliste vor dem Kick-off

Liste der Leistungen und Regionen, die wirklich Anfragen treiben; Top-Einwände aus Sales; vorhandene FAQ; Search-Console-Queries (Marke vs. Thema); Klarheit ob Cutover schon steht; welche Claims ihr mit Quelle freigeben könnt; gewünschter Conversion-Pfad auf neuen URLs; Abgrenzung zu Glossar- vs. Leistungsseiten; robots/sitemap-Status nach Migration; ob llms.txt parallel oder danach kommt.

Referenzmethode: Mallorca Expats — thematische Struktur auf modernem Stack, nicht Copy-Paste fremder Texte. Einstieg nach Webseite-Modernisierung; optional parallel Conversion, sobald Kern-URLs fest sind. Preise und Module im Überblick: Preise & Pakete.

Kurz: Der Knowledge Graph ist dein Themenkatalog für Menschen und Maschinen — 500 €, Entities/Claims/Links/Schema, nach der Migration. Anfrage stellen