SEO und Inhalte

Prüfen, ob KI-Crawler die richtige Sprachversion Ihrer mehrsprachigen Website sehen

Prüft die Abstimmung von hreflang, Canonical und html lang auf jeder Sprachversion, die Alternates in der Sitemap sowie automatische Weiterleitungen nach Land oder Browsersprache der Besucher. Misst, welche Version Google auswählt und welche Sprachseite in KI-Antworten zitiert wird, ohne etwas zu verändern.

Wann du ihn nutzt

Wenn Ihre mehrsprachige Website in der falschen Sprache rankt oder zitiert wird oder Sie vermuten, dass automatische Weiterleitungen nach Land oder Browsersprache verhindern, dass Google und KI-Crawler Ihre deutsche oder französische Version sehen.

Was du bekommst

Ein Seite-für-Seite-Bericht zu hreflang, Canonical, html lang und Sitemap-Abgleich, ein Redirect-Vergleich pro Sprache, Googles gewählter Canonical und Impressionen je Markt, die in KI-Antworten zitierte Sprachversion sowie eine nach Schweregrad sortierte Fix-Liste.

Ändert er etwas in meinem Konto?

Nein. Der Assistent liest nur deine Daten und berichtet dir.

Funktioniert mit

SEO Intelligence, Search Console

Vor dem Senden ausfüllen

[site URL][languages and URL structure, e.g. en: /, de: /de/, fr: /fr/][Search Console property][homepage and one service page URL in each language][one question per language][domain]

Meine Website [site URL] ist in diesen Sprachen veröffentlicht: [languages and URL structure, e.g. en: /, de: /de/, fr: /fr/]. Meine Search-Console-Property: [Search Console property]. Die beiden wichtigsten Seiten pro Sprache: [homepage and one service page URL in each language]. Eine kommerzielle Frage pro Markt: [one question per language]. Diese Aufgabe ist rein lesend. Die meisten KI-Crawler und die Crawler von Google kommen von Servern in den USA, und ihre Browsersprache ist in der Regel Englisch. Wenn die Website Besucher automatisch nach IP-Land oder Browsersprache weiterleitet, sehen diese Crawler die deutsche oder französische Seite womöglich nie. Genau das soll diese Aufgabe messen. 1. Abstimmung der Tags. Lesen Sie die beiden Seiten jeder Sprache mit site_read_url (Standard-max_bytes; wird der Body vor `</head>` abgeschnitten, verwenden Sie max_bytes=1000000). Extrahieren Sie pro Seite den Wert von `<html lang>`, die Canonical-URL, jeden `rel="alternate" hreflang`-Link und x-default. Prüfen Sie: Zeigt der Canonical auf die Seite selbst (verweist der Canonical einer Sprachversion auf eine andere Sprache, fällt diese Version aus dem Index)? Sind die hreflang-Links gegenseitig (wenn A auf B verweist, muss B auf A verweisen)? Liefert jede hreflang-URL den Status 200 (site_read_url mit max_bytes=0)? Sind die Sprachcodes gültig (z. B. "en", "de", "en-GB"; mischen Sie nicht "de-DE" und "de")? Nennen html lang und hreflang dieselbe Sprache? 2. Sitemap. Lesen Sie die sitemap.xml und eventuelle untergeordnete Sitemaps mit site_read_url. Vergleichen Sie bei zwei Seiten die xhtml:link-Alternates mit dem hreflang auf der Seite. 3. Weiterleitungsverhalten. Lesen Sie die Startseite jeder Sprache mit site_read_url und max_bytes=0 und notieren Sie die Liste der Weiterleitungen (redirects). Dieses Tool sendet Anfragen wie ein Browser von einem festen Server aus und zeigt daher nicht, was ein Besucher aus einem anderen Land sieht. Messen Sie deshalb die Startseite jeder Sprache zusätzlich mit seo_technical_audit, das die Seite mit JavaScript von Servern an einem anderen Standort rendert. Zeigen die beiden Tools einen Title oder H1 in unterschiedlichen Sprachen, leitet die Website Besucher von diesem Standort auf eine andere Sprachversion um. Markieren Sie das mit höchster Dringlichkeit und fragen Sie mich: Nimmt die Weiterleitungsregel Such- und KI-Crawler aus (Googlebot, Bingbot, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot), und verwendet sie 302 statt 301? Sie können weder den Code noch die Servereinstellungen einsehen, also raten Sie die Antwort nicht. 4. Googles Auswahl. Prüfen Sie die beiden Seiten pro Sprache in einem einzigen Aufruf von gsc_inspect_urls. Weicht der von Google gewählte Canonical von der Seite selbst ab (z. B. wird für die deutsche Seite die englische gewählt), sagen Sie das. Verwenden Sie get_report mit platform='search_console' und breakdown='country' für die letzten 90 Tage, danach breakdown='page by impressions', und summieren Sie Impressionen und Klicks pro Sprachordner. Markieren Sie jede Sprachversion, die im eigenen Markt kaum Impressionen erhält. 5. Die Sprache, die die KI sieht. Lassen Sie die kommerzielle Frage jedes Marktes mit den Standort- und Sprachwerten dieses Marktes und target=[domain] durch seo_ai_overview laufen. Wird eine meiner Seiten zitiert, notieren Sie, welche Sprachversion es ist. Ist references leer, nutzen Sie die Links innerhalb von ai_answer. Wird meine englische Seite für eine deutsche Frage zitiert, ist das ein Zeichen dafür, dass die deutsche Seite nicht ausreichend gesehen wird. Formatieren Sie die Ausgabe so: Zuerst eine Zusammenfassung in vier Sätzen. Dann eine Seitentabelle: URL, html lang, Canonical (selbst oder nicht), Anzahl und Gegenseitigkeit der hreflang, x-default, von Google gewählter Canonical, Status. Dann eine Weiterleitungstabelle: Startseite der Sprache, Title in site_read_url, Title in seo_technical_audit, Unterschied. Dann eine Markttabelle: Sprache, Impressionen und Klicks im Hauptmarkt, in der KI-Antwort zitierte Version. Schließen Sie mit einer Maßnahmenliste nach Dringlichkeit. Gibt es eine automatische Sprachweiterleitung, fügen Sie diese allgemeine Empfehlung hinzu: Crawler von der Weiterleitung auszunehmen oder Besuchern statt einer Weiterleitung einen Banner mit einem Sprachvorschlag zu zeigen, ist der Ansatz, den Google für mehrsprachige Websites empfiehlt.

Die meisten KI-Crawler und die Crawler von Google kommen von Servern in den USA, und ihre Browsersprache ist in der Regel Englisch. Wenn die Website Besucher automatisch nach IP-Land oder Browsersprache weiterleitet, sehen diese Crawler die deutsche oder französische Seite womöglich nie. Genau das soll diese Aufgabe messen.

1. Abstimmung der Tags. Lesen Sie die beiden Seiten jeder Sprache mit site_read_url (Standard-max_bytes; wird der Body vor `</head>` abgeschnitten, verwenden Sie max_bytes=1000000). Extrahieren Sie pro Seite den Wert von `<html lang>`, die Canonical-URL, jeden `rel="alternate" hreflang`-Link und x-default. Prüfen Sie: Zeigt der Canonical auf die Seite selbst (verweist der Canonical einer Sprachversion auf eine andere Sprache, fällt diese Version aus dem Index)? Sind die hreflang-Links gegenseitig (wenn A auf B verweist, muss B auf A verweisen)? Liefert jede hreflang-URL den Status 200 (site_read_url mit max_bytes=0)? Sind die Sprachcodes gültig (z. B. "en", "de", "en-GB"; mischen Sie nicht "de-DE" und "de")? Nennen html lang und hreflang dieselbe Sprache?
2. Sitemap. Lesen Sie die sitemap.xml und eventuelle untergeordnete Sitemaps mit site_read_url. Vergleichen Sie bei zwei Seiten die xhtml:link-Alternates mit dem hreflang auf der Seite.
3. Weiterleitungsverhalten. Lesen Sie die Startseite jeder Sprache mit site_read_url und max_bytes=0 und notieren Sie die Liste der Weiterleitungen (redirects). Dieses Tool sendet Anfragen wie ein Browser von einem festen Server aus und zeigt daher nicht, was ein Besucher aus einem anderen Land sieht. Messen Sie deshalb die Startseite jeder Sprache zusätzlich mit seo_technical_audit, das die Seite mit JavaScript von Servern an einem anderen Standort rendert. Zeigen die beiden Tools einen Title oder H1 in unterschiedlichen Sprachen, leitet die Website Besucher von diesem Standort auf eine andere Sprachversion um. Markieren Sie das mit höchster Dringlichkeit und fragen Sie mich: Nimmt die Weiterleitungsregel Such- und KI-Crawler aus (Googlebot, Bingbot, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot), und verwendet sie 302 statt 301? Sie können weder den Code noch die Servereinstellungen einsehen, also raten Sie die Antwort nicht.
4. Googles Auswahl. Prüfen Sie die beiden Seiten pro Sprache in einem einzigen Aufruf von gsc_inspect_urls. Weicht der von Google gewählte Canonical von der Seite selbst ab (z. B. wird für die deutsche Seite die englische gewählt), sagen Sie das. Verwenden Sie get_report mit platform='search_console' und breakdown='country' für die letzten 90 Tage, danach breakdown='page by impressions', und summieren Sie Impressionen und Klicks pro Sprachordner. Markieren Sie jede Sprachversion, die im eigenen Markt kaum Impressionen erhält.
5. Die Sprache, die die KI sieht. Lassen Sie die kommerzielle Frage jedes Marktes mit den Standort- und Sprachwerten dieses Marktes und target=[domain] durch seo_ai_overview laufen. Wird eine meiner Seiten zitiert, notieren Sie, welche Sprachversion es ist. Ist references leer, nutzen Sie die Links innerhalb von ai_answer. Wird meine englische Seite für eine deutsche Frage zitiert, ist das ein Zeichen dafür, dass die deutsche Seite nicht ausreichend gesehen wird.

Formatieren Sie die Ausgabe so: Zuerst eine Zusammenfassung in vier Sätzen. Dann eine Seitentabelle: URL, html lang, Canonical (selbst oder nicht), Anzahl und Gegenseitigkeit der hreflang, x-default, von Google gewählter Canonical, Status. Dann eine Weiterleitungstabelle: Startseite der Sprache, Title in site_read_url, Title in seo_technical_audit, Unterschied. Dann eine Markttabelle: Sprache, Impressionen und Klicks im Hauptmarkt, in der KI-Antwort zitierte Version. Schließen Sie mit einer Maßnahmenliste nach Dringlichkeit. Gibt es eine automatische Sprachweiterleitung, fügen Sie diese allgemeine Empfehlung hinzu: Crawler von der Weiterleitung auszunehmen oder Besuchern statt einer Weiterleitung einen Banner mit einem Sprachvorschlag zu zeigen, ist der Ansatz, den Google für mehrsprachige Websites empfiehlt.

In Claude öffnen In ChatGPT öffnen Im Forum diskutieren

Beispielergebnis

Ein Beispiel für die Ausgabe dieses Prompts. Die Struktur stammt aus der echten Ausgabe der Tools, Zahlen und Namen sind fiktiv.

Beispielausgabe (basiert auf einer fiktiven Website, keine echten Kundendaten)

Zusammenfassung. examplesoft.example wird in drei Sprachen veröffentlicht, die hreflang-Tags sind wechselseitig gesetzt und x-default ist korrekt. Allerdings zeigt site_read_url auf /de/ einen deutschen Titel, während seo_technical_audit auf derselben URL einen englischen Titel gemessen hat; die Website leitet Besucher aus den USA von /de/ auf die englische Version um. Ob diese Weiterleitung Crawler ausnimmt, lässt sich mit diesen Tools nicht erkennen, daher brauchen wir hierzu Ihre Antwort. Bei der deutschen Kaufanfrage hat die KI-Antwort von Google Ihre englische Seite zitiert.

URL	html lang	Canonical	hreflang	x-default	Google-Canonical	Status
/	en	self	3, wechselseitig	/	/	OK
/de/	de	self	3, wechselseitig	/	/de/	OK
/fr/tarifs/	fr	/pricing/	3, wechselseitig	/	/pricing/	Canonical verweist auf eine andere Sprache

Startseite der Sprachversion	Titel in site_read_url	Titel in seo_technical_audit	Abweichung
/de/	Deutsch	Englisch	Ja
/fr/	Französisch	Französisch	Nein

Sprache	Impressionen / Klicks im Hauptmarkt	In der KI-Antwort zitierte Version
de	Deutschland: 3.900 / 100	Englisch (/pricing/)
fr	Frankreich: 2.200 / 38	Keine Zitierung

Reihenfolge der Korrekturen
1. Bestätigen, dass die Sprachweiterleitung Crawler ausnimmt und als 302 umgesetzt ist; falls nicht, von einem Entwickler eine entsprechende Regel ergänzen lassen.
2. Den Canonical von /fr/tarifs/ auf die Seite selbst setzen.
3. Den Preis auf der deutschen Preisseite direkt in den ersten Absatz schreiben; die KI übernimmt ihn derzeit von der englischen Seite.

Diese Prompts funktionieren am besten, wenn dein KI-Assistent über Opus Growth mit deinen Konten verbunden ist.

Konten kostenlos verbinden

Weitere Prompts

SEO und InhalteÄndert nach deiner FreigabeLive-Demo

Meine gehostete Website auf Türkisch und Englisch veröffentlichen, mit hreflang, Sitemaps pro Sprache und llms.txt

Ergänzt eine englische Version einer statischen Website unter /en/: Sprach-URLs, hreflang und x-default, og:locale und Schema-Sprache je Sprache, einen statischen Sprachumschalter, Sitemaps und llms.txt pro Sprache. Prüft Übersetzungszuordnung und -qualität per Skript und misst jede Seite auf zwei Geräten.

Wann du ihn nutztWenn Ihre Website nur in einer Sprache online ist und Sie eine englische Version ergänzen möchten, die Google und KI-Assistenten korrekt mit dem Original verbinden.

Meine Website [site address] auf meinem Opus Growth Server ist bisher nur auf Türkisch. Ich möchte, dass du eine englische Version ergänzt und beide Sprachen so einrichtest, dass Suchmaschinen und KI-Assistenten sie korrekt einander zuordnen. Zielgruppe der englischen Version: [audience, for example foreign tourists]. Namen, die nie übersetzt werden: [brand name, product names, place names]. Die Sprache, die Besucher von anderswo standardmäßig sehen (x-default): [Turkish or English].

1. Ist-Zustand erfassen. Lies site_seo_guide, liste die Seiten mit site_list_files auf und notiere die Wiederherstellungsversion mit site_versions. Schlage für jede türkische Seite eine englische Adresse vor und zeige die Zuordnungstabelle: Türkisch bleibt im Stammverzeichnis (/, /hizmetler/), Englisch liegt unter /en/ (/en/, /en/services/). Schreibe die Adressen in englischen Wörtern, kleingeschrieben, als Verzeichnisse mit abschließendem Schrägstrich. Ändere die bestehenden türkischen Adressen nicht; falls eine geändert werden muss, leite sie per 301 mit site_redirects um. Warte auf meine Freigabe.
2. Übersetzung. Schreibe jede Seite auf Englisch so, dass sie für die Zielgruppe natürlich klingt, übersetze den Sinn, nicht Satz für Satz. Behalte Daten wie Telefonnummern, Adressen, Preise und Öffnungszeiten exakt bei und füge keine neuen Behauptungen hinzu. Titel mit 50 bis 60 Zeichen, Beschreibungen mit 140 bis 160 Zeichen, in jeder Sprache einzigartig. Beide Sprachen haben dieselbe Anzahl an Abschnitten. Jede englische Seite hat `<html lang="en">` und beantwortet die Frage direkt im ersten Absatz.
3. Konfiguration. Füge in assets/site.config.js einen Block `locales.en` hinzu: Präfix "/en/", hreflang "en", ogLocale "en_US", die englische Unternehmensbeschreibung, das englische Menü, den Call-to-Action, den Footer-Hinweis und die Oberflächentexte (skip to content, menu, pages, contact). Trage in einem `i18n`-Block die Stammsprache, die x-default-Sprache, die türkisch-englischen Adresspaare, die nie übersetzten Wörter (keepWords) und ein Fachbegriff-Glossar ein.
4. Schreibe ein Skript i18n-stamp.mjs und lege es im Stammverzeichnis der Website ab. Seine Aufgaben:
   1. Auf jeder Seite zwischen `` und `` absolute Tags `<link rel="alternate" hreflang="tr-TR">`, `hreflang="en"` und `hreflang="x-default"` ausgeben.
   2. Innerhalb des von seo-stamp.mjs ausgegebenen Blocks auf englischen Seiten og:locale auf en_US setzen, in beiden Sprachen die jeweils andere Sprache als og:locale:alternate ergänzen, inLanguage des WebSite-Knotens auf ["tr-TR", "en"] setzen und auf englischen Seiten die description des Unternehmensknotens durch die englische ersetzen.
   3. sitemap-tr.xml und sitemap-en.xml mit xhtml:link-Alternates für jede Adresse und dem tatsächlichen Änderungsdatum der Datei als lastmod erzeugen und sitemap.xml in einen Sitemapindex umwandeln, der auf beide verweist.
   4. Die Übersetzung prüfen und bei Fehlern mit einem Exit-Code ungleich null beenden: eine Seite ohne Gegenstück, html lang passt nicht zum Ordner, eine unterschiedliche Telefon- oder lange Nummer in den beiden Sprachen; als Warnungen eine unterschiedliche Anzahl an h2, h3, Bildern oder FAQ-Einträgen in den beiden Sprachen, Wörter mit türkischen Sonderzeichen im englischen Text außerhalb von keepWords und nicht verwendete Glossarbegriffe.
   Der WebPage-Knoten jeder Seite trägt deren eigene Sprache als inLanguage. seo-check.mjs nimmt nur die Startseite im Stammverzeichnis von der BreadcrumbList-Pflicht aus, ergänze daher auf der /en/-Startseite eine BreadcrumbList mit einem Element.
5. Sprachumschalter. Das Skript chrome-stamp.mjs, das Menü und Footer als statisches HTML ausgibt, gibt Seiten unter /en/ das Menü und die Oberflächentexte aus locales.en und baut den Sprachumschalter aus den hreflang-Tags der Seite, sodass jede Seite auf IHR eigenes Gegenstück in der anderen Sprache verlinkt und nicht auf die Startseite. Jeder Sprachlink trägt die Attribute hreflang und lang und eine Tippfläche von mindestens 44 Pixeln. Wähle die Sprache nicht per Weiterleitung anhand der Browsersprache.
6. llms.txt. Schreibe die türkische /llms.txt im Stammverzeichnis und die englische Version unter /en/llms.txt; jede enthält eine kurze, genaue Zusammenfassung der Website, die Seitenliste in der eigenen Sprache und die Kontaktdaten und verlinkt auf die jeweils andere. robots.txt bleibt offen für KI-Crawler und verweist nur auf den Index sitemap.xml.
7. Ausführungsreihenfolge nach jeder Änderung: `node seo-stamp.mjs`, `node i18n-stamp.mjs`, `node chrome-stamp.mjs`, der Tailwind-Build, dann `node seo-check.mjs`, `node design-check.mjs`, `npx --yes html-validate "**/*.html"`. seo-stamp überschreibt bei jedem Lauf seinen eigenen Block, daher muss i18n-stamp IMMER danach laufen. Falls die Website noch über das Tailwind Play CDN und Schriften von Drittanbietern läuft, stelle sie zuerst auf kompiliertes CSS und selbst gehostete Schriften um.
8. Messen. core_web_vitals auf Mobil und Desktop für jede Seite in beiden Sprachen; seo_audit für beide Versionen der Startseite. Öffne die türkische und die englische Startseite mit site_preview bei 360, 390, 768 und 1440 Pixel Breite; englische Überschriften sind oft länger, achte daher genau auf Überläufe. Kriterien: mobile Performance mindestens 95 und die anderen drei Werte 100; null Fehler bei seo-check, i18n-stamp und html-validate.
9. Nach der Veröffentlichung. Bestätige die hreflang-Tags und den Sprachumschalter auf der /en/-Startseite mit site_read_url. Falls meine Search-Console-Property [Search Console property] ist, reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die /en/-Startseite mit gsc_url_inspect.

Ausgabe: die Zuordnungstabelle der türkischen und englischen Adressen, eine Tabelle der Werte pro Seite und Sprache, die Ausgabe der i18n-stamp-Prüfung, die verbleibenden Übersetzungswarnungen und eine Liste der Sätze, die ich prüfen sollte.

SEO und InhalteÄndert nach deiner Freigabe

Money Page nach dem Answer-First-Prinzip umbauen, damit KI-Antworten sie zitieren können

Zieht die Fragen, die die Seite bereits in der Search Console bekommt, und wer in KI-Antworten zitiert wird, und gliedert dann den bestehenden Content neu: direkte Antwort ganz oben, Fragen als Überschriften, Vergleichstabelle und seitenspezifische FAQ. Erfindet nichts, wird erst nach Vorschau und Freigabe umgesetzt und hält eine Baseline für die Erfolgsmessung fest.

Wann du ihn nutztWenn die Antwort einer wichtigen Leistungs- oder Preisseite im Text versteckt ist und die Seite bei Fragesuchen rankt, aber selten in KI-Antworten oder Google-Snippets zitiert wird.

Baue die Seite [page URL] auf meiner Website in ein "Answer-First"-Layout um, das KI-Antworten und Google leicht zitieren können. Website-Typ: [Opus Growth hosting or WordPress]. Meine Search-Console-Property: [Search Console property]. Ich vermute, dass die Hauptfrage der Seite lautet: [main question, e.g. "how much does a boiler service cost in Hackney"]. Fakten, die nicht auf der Website stehen und die ich als korrekt bestätige: [price range, duration, warranty and so on, or "none"].

1. Die Fragen, die die Seite bekommt. Nutze get_report mit platform='search_console', breakdown='page,query' für die letzten 90 Tage und behalte nur die Zeilen dieser Seite. Filtere die Suchanfragen im Fragestil (was, wie, warum, wie viel, welche, Unterschied, Preis und deren Entsprechungen in der Sprache der Seite) mit mindestens 20 Impressionen heraus und sortiere sie nach Impressionen. Behalte diese Zeilen als Mess-Baseline: Suchanfrage, Impressionen, Klicks, durchschnittliche Position.
2. Der aktuelle Content. Lies die Seite mit site_read_url, zuerst mit outline=true und dann mit text=true (wenn truncated true ist, lies erneut mit max_bytes=1000000). Liste den Überschriftenbaum, den ersten Absatz und jede Zahl, jeden Preis, jede Dauer und jede Behauptung auf der Seite auf. Diese Liste ist alles, was du verwenden darfst.
3. Was die KI sagt. Prüfe seo_history auf frühere Läufe und führe dann seo_ai_overview für die Hauptfrage und die zwei Fragen mit den meisten Impressionen aus (target=[domain], Standort und Sprache für meinen Markt). Notiere, was der erste Satz der KI-Antwort sagt, welche Arten von Fakten sie enthält (Preisspanne, Dauer, Schritte, Vergleich) und welche Seiten sie zitiert. Wenn references leer ist, zähle die Domains der Links innerhalb von ai_answer. Diese Aufrufe kosten Credits, führe daher nicht mehr als drei aus, ohne mich zu fragen.
4. Die neue Struktur. Behalte den bestehenden Text bei und schlage dieses Layout vor:
   1. Das H1 bleibt oder wird leicht angepasst, damit es die Hauptfrage klarer aufgreift.
   2. Direkt unter dem H1 ein Antwortabsatz mit 40 bis 60 Wörtern: eine direkte Antwort auf die Hauptfrage im ersten Satz, dann die zwei wichtigsten konkreten Fakten. Keine Einstiege wie "Heutzutage" oder "Wenn Sie sich fragen".
   3. Die Abschnitte im Haupttext bekommen H2-Überschriften im Fragestil, übernommen aus den echten Search-Console-Fragen. Der erste Satz unter jedem H2 beantwortet die jeweilige Frage.
   4. Eine Tabelle, wenn die Seite vergleichbare Fakten enthält (Pakete, Dauern, Optionen). Wenn nicht, erfinde keine.
   5. Am Ende eine FAQ mit 4 bis 6 seitenspezifischen Fragen. Die Fragen stammen aus der Search Console oder aus Themen, die die Seite tatsächlich beantwortet.
   6. Eine sichtbare Zeile "Zuletzt aktualisiert: [date]" und die Angabe, wer die Seite erstellt hat (der Firmenname, sofern ich keinen echten Personennamen angegeben habe).
   7. Da diese FAQ auf der Seite sichtbar ist, kann FAQPage-JSON-LD ergänzt werden. Weise darauf hin, dass Google FAQ-Rich-Results seit 2023 nur noch für bekannte Behörden- und Gesundheitsseiten anzeigt. Das Markup dient also dazu, dass Maschinen den Content lesen können, nicht dazu, ein Rich Result zu erhalten.
5. Keine erfundenen Fakten. Schreibe keine Zahl, keinen Preis, keine Dauer, keine Garantie, keine Kundenzahl, keine Bewertung und kein Zertifikat, die nicht auf der Seite oder in den oben genannten Fakten stehen. Wenn der Antwortabsatz einen Fakt braucht, den wir nicht haben, schreibe stattdessen [FACT NEEDED: ...] und frage mich.
6. Qualitätsprüfung. Lass den gesamten neuen Text durch seo_content_lint laufen. Wenn human_score unter 80 liegt oder eine Formulierung markiert wird, schreibe diese Absätze um und führe die Prüfung erneut aus.
7. Vorschau. Zeige die alte und die neue Struktur nebeneinander, Abschnitt für Abschnitt, vermerke, auf welchem bestehenden Fakt jeder neue Satz beruht, und warte auf meine Freigabe.
8. Nach der Freigabe umsetzen.
   1. Hosting: Lies die Seitendatei mit site_read_file und ändere sie Abschnitt für Abschnitt mit site_edit_file. Schreibe den FAQPage-Block statisch in den Head der Seite und verknüpfe ihn mit dem bestehenden @id-Graphen der Website.
   2. WordPress: Lies den Inhalt mit wordpress_get_post. Wenn die Seite mit Elementor gebaut ist, lies das Layout mit wordpress_page_design und ändere es mit wordpress_edit_page_design; andernfalls nutze wordpress_update_post. Ändere den Veröffentlichungsstatus der Seite nicht.
9. Verifizieren. Zeige mit site_read_url und outline=true das einzelne H1, die neuen H2-Überschriften und den Antwortabsatz live. Bestätige mit text=true, dass der Antwortabsatz auch ohne JavaScript sichtbar ist.

Schließe mit einem Messplan ab: In 4 bis 6 Wochen vergleichen wir die Search-Console-Zeilen für dieselben Suchanfragen und die seo_ai_overview-Ergebnisse für dieselben Fragen mit der Baseline. Beurteile die Wirkung der Änderung nicht vor diesem Zeitpunkt.

SEO und InhalteNur lesend

Intent-basierte Keyword-Cluster aus wenigen Seed-Keywords aufbauen

Eine gerankte Liste von Keyword-Clustern mit Volumen, Schwierigkeit und dem passenden Seitentyp oder der passenden Anzeigengruppe für jedes Cluster.

Wann du ihn nutztWenn du die Keyword-Recherche für ein Unternehmen startest und nur wenige Seed-Keywords hast.

Ich verkaufe [Produkt oder Service] in [Stadt oder Land]. Starte mit diesen Seed-Keywords: [3 bis 5 Seed-Keywords].

Prüfe zuerst seo_history, damit du frühere Ergebnisse wiederverwendest, statt für dieselbe Abfrage doppelt zu zahlen. Nutze dann den Keyword Planner und die SEO-Keyword-Recherche, um Ideen mit durchschnittlichen monatlichen Suchanfragen, Wettbewerb und Keyword-Schwierigkeit zu sammeln.

Bereinige die Liste:
- entferne Keywords unter 30 monatlichen Suchanfragen
- entferne Job-, Gratis-, DIY-, Kurs- und Wettbewerber-Markenbegriffe, es sei denn, sie passen eindeutig zu meinem Geschäft
- führe enge Varianten und Pluralformen zusammen

Clustere den Rest nach Suchintention, mit einem Cluster pro eigenständigem Bedürfnis eines Suchenden. Gib für jedes Cluster an:
- Clustername und Haupt-Keyword
- 5 bis 10 unterstützende Keywords
- gesamtes monatliches Volumen und durchschnittliche Schwierigkeit
- Intention: informativ, kommerziell oder transaktional
- beste Verwendung: Serviceseite, Blogbeitrag oder eine Google-Ads-Anzeigengruppe

Sortiere die Cluster nach Volumen und Eignung für ein kleines Unternehmen mit begrenztem Budget. Markiere die Top 3 für den Start und begründe das jeweils in einer Zeile.

SEO und InhalteÄndert nach deiner Freigabe

Konvertierende Suchbegriffe aus Ads in organische Content-Cluster verwandeln

Nutzt 90 Tage konvertierende Suchbegriffe aus Google Ads und Microsoft Ads, um Themen zu finden, bei denen du für Conversions zahlst, aber organisch kaum oder gar nicht sichtbar bist. Liefert einen priorisierten Content-Plan und eine reine Vorschau-Liste mit Keyword-Ergänzungen.

Wann du ihn nutztWenn du für Conversions auf Suchbegriffe zahlst, aber nicht weißt, welche Themen organische Inhalte verdienen, um weniger von Anzeigen abhängig zu sein.

Ich möchte meine Ads-Daten nutzen, um zu entscheiden, worüber ich schreiben soll. Verwende bei jeder Quelle die letzten 90 Tage.

1. Ziehe meine Google-Ads-Suchbegriffe der letzten 90 Tage (days=90 oder ein explizites Start- und Enddatum), sortiert nach Conversions. Behalte nur Begriffe mit mindestens 1 Conversion. Wenn die Antwort abgeschnitten ist, blättere weiter, bis du alle konvertierenden Begriffe hast.
2. Wenn Microsoft Ads verbunden ist, finde das Standardkonto und ziehe dessen Suchbegriffe für dieselben 90 Tage. Behalte nur Begriffe mit mindestens 1 Conversion und füge sie dem Pool hinzu. Markiere dabei, von welcher Plattform jeder Begriff stammt.
3. Gruppiere alle konvertierenden Begriffe nach Suchintention in Themen-Cluster. Zeige für jedes Cluster die Gesamtkosten, Conversions und Kosten pro Conversion, aufgeteilt nach Plattform, wo beide vorhanden sind.
4. Finde meine Search-Console-Property (nutze [Site-Property], falls ich eine genannt habe) und ziehe organische Daten für die letzten 90 Tage mit der Dimension query sowie einen zusätzlichen page,query-Abruf, damit du siehst, welche Seite für welche Query rankt. Nutze ein ausreichend hohes Limit, um den Long Tail abzudecken.
5. Ordne jedes Cluster den Search-Console-Queries zu, die dieselbe Intention ausdrücken. Nutze dein Urteilsvermögen bei nahen Varianten und unterschiedlichen Formulierungen und nenne, welche Queries du gezählt hast. Berichte organische Klicks, Impressionen und durchschnittliche Position pro Cluster sowie die am besten rankende Seite, falls es eine gibt.

Klassifiziere jedes Cluster:
- Content-Lücke: konvertiert in Ads, organische Durchschnittsposition schlechter als 10 oder keine organischen Impressionen. Hier sollte ich eine Seite erstellen.
- Verbessern: konvertiert in Ads, organische Position 4 bis 10. Nenne die bestehende Seite, die gestärkt werden muss.
- Abgedeckt: organische Position 1 bis 3. Vermerke es als möglichen Ansatz, später weniger Werbebudget zu testen.

Liefere eine Tabelle, sortiert nach Ads-Conversions, und dann die Top 5 Content-Lücken-Cluster mit je einem Vorschlag für Seitentitel und URL-Slug.

Liste separat meine Google-Ads-Keywords auf (list_entities, entity keywords) und zeige konvertierende Google-Suchbegriffe, die im Konto noch keine Keywords sind. Bei Microsoft-Begriffen markiere sie nur; prüfe oder ändere keine Microsoft-Keywords. Füge nichts hinzu. Wenn du meinst, dass einige Google-Begriffe als Exact Match ergänzt werden sollten, sag mir, in welche Anzeigengruppe jeder gehört, und führe add_keywords mit confirm=false aus, damit ich die genaue Vorschau sehe. Warte auf meine Freigabe, bevor du etwas anwendest.