Mehrsprachige SEO 2026: Der komplette Leitfaden für globale Suchsichtbarkeit (Mit KI-Agent-Workflows)

---
name: multilingual-market-scorer
description: Analysieren Sie GA4- und GSC-Daten, um Zielmärkte für die mehrsprachige SEO-Expansion zu bewerten und zu priorisieren
---

# Multilingual Market Scorer (Mehrsprachiger Marktbewerter)

Bewerten Sie potenzielle Zielmärkte anhand vorhandener Analysedaten. Dieser Skill hilft Ihnen zu priorisieren, welche Sprachen und Länder Sie zuerst für die mehrsprachige SEO anvisieren sollten.

## Voraussetzungen
- Nutzer hat GA4- und GSC-Daten bereitgestellt (CSV-Exporte von jeder Plattform)
- Nutzer hat seine Top-5-englischsprachigen Ziel-Keywords definiert
- Nutzer kennt seine geschäftlichen Einschränkungen (Versandregionen, unterstützte Währungen, Sprachen des Kundensupports)

## Eingabe
1. GA4-Länder-Organik-Traffic-Export (CSV)
2. GSC-Länder-Leistungsexport (CSV)
3. Top-5-Ziel-Keywords auf Englisch
4. Liste der Länder/Regionen, in denen das Unternehmen derzeit tätig ist

## Workflow

### Phase 1: Nachfragesignale extrahieren
- GA4-CSV parsen, um zu extrahieren: Land, monatliche organische Sitzungen, Conversion-Rate nach Land
- GSC-CSV parsen, um zu extrahieren: Land, Klicks, Impressionen, durchschnittliche CTR, durchschnittliche Position
- Die beiden Datensätze anhand des Ländernamens zusammenführen

### Phase 2: Jeden Markt bewerten
Für jedes Land mit messbarem Traffic:
- **Nachfrage-Score (1–5):** Basierend auf monatlichen organischen Sitzungen. <100 = 1, 100–500 = 2, 500–2.000 = 3, 2.000–5.000 = 4, 5.000+ = 5
- **Chancen-Score (1–5):** Basierend auf der durchschnittlichen CTR. Unter 1 % = 5 (hohe Chance – Nutzer finden Sie, können Sie aber nicht lesen), 1–2 % = 4, 2–4 % = 3, 4–7 % = 2, 7 %+ = 1
- **Geschäftseignungs-Score (1–5):** Muss vom Nutzer basierend darauf angegeben werden, ob er in diesem Land tätig ist. Standardmäßig 3, falls unbekannt.

### Phase 3: Rangfolge und Empfehlungen
- Nachfrage × Chance × Geschäftseignung für einen Gesamtscore multiplizieren (max. 125)
- Stufe 1 (60+): sofortige Priorität – Lokalisierung für diese Märkte beginnen
- Stufe 2 (30–59): Kandidaten für die zweite Welle – für das nächste Quartal planen
- Stufe 3 (<30): beobachten – erneut prüfen, wenn Stufe 1 und 2 live sind
- Eine sortierte Tabelle ausgeben mit: Land, Hauptsprache, Gesamtscore, Nachfrage-Score, Chancen-Score, Geschäftseignungs-Score, empfohlene URL-Struktur, geschätzte Anzahl zu lokalisierender Seiten

### Phase 4: Einen Prioritäts-Aktionsplan ausgeben
- Top-3-Märkte, die zuerst anvisiert werden sollten, mit empfohlenen Sprachen und URL-Struktur
- Liste der zuerst zu lokalisierenden Seiten (basierend auf den GSC-Top-Seiten für jedes Land)
- Geschätzte Wortanzahl und Übersetzungsbudget (unter Verwendung aktueller KI-Übersetzungs-API-Preise)
- Risiko: Länder auflisten, in denen hohe Nachfrage + niedrige CTR besteht, das Unternehmen aber nicht tätig ist – als strategische Entscheidungen kennzeichnen

## Ausgabe
Ein strukturierter Bericht mit:
1. Marktpriorisierungstabelle (alle Länder bewertet und in Stufen eingeteilt)
2. Top-3-empfohlene Märkte mit Begründung
3. Lokalisierungsseitenliste für die erste Welle (max. 20 Seiten pro Markt)
4. Geschätztes Budget und Zeitplan
5. Gekennzeichnete strategische Lücken

## Einschränkungen
- Alle Bewertungen sind Schätzungen basierend auf verfügbaren Daten – die tatsächliche Performance kann abweichen
- Ersetzt keine muttersprachliche Marktforschung oder lokale Wettbewerbsanalyse
- GA4- und GSC-Daten spiegeln die aktuelle englischsprachige Performance wider, nicht die latente nicht-englische Nachfrage
- Greift nicht auf kostenpflichtige APIs zu; ist auf vom Nutzer bereitgestellte CSV-Exporte angewiesen

---
name: multilingual-keyword-research
description: Erstellen und validieren Sie lokalisierte Keyword-Listen für jede Zielsprache und jedes Land, mit KI-Übersetzung und SERP-Validierung
---

# Multilingual Keyword Research Agent (Mehrsprachiger Keyword-Recherche-Agent)

Erstellen Sie einen lokalisierten Keyword-Recherche-Bericht für jede Zielsprache und jeden Markt. Kombiniert KI-Übersetzung mit SERP-Validierungsschritten, um Keyword-Listen zu produzieren, die widerspiegeln, wie echte Nutzer suchen.

## Voraussetzungen
- Nutzer hat Zielland (ISO-Code) und Sprache definiert
- Nutzer hat 10–20 Seed-Keywords auf Englisch (oder seiner Ausgangssprache) bereitgestellt
- Nutzer hat Zugang zum Google Keyword Planner, DataForSEO oder ist mit manuellen SERP-Prüfungen vertraut
- Keine API-Schlüssel für den Basis-Workflow erforderlich; DataForSEO-Integration ist optional für automatisierte Volumendaten

## Eingabe
1. Zielland (z. B. `DE`, `ES`, `JP`) und Sprache (z. B. `de`, `es`, `ja`)
2. 10–20 Seed-Keywords in der Ausgangssprache
3. Geschäftskategorie oder Branche (für Kontext)
4. Optional: DataForSEO-API-Zugangsdaten (für automatisierte Suchvolumendaten)

## Workflow

### Phase 1: Seed-Keywords übersetzen und erweitern
Für jedes Seed-Keyword:
- Eine erste Übersetzung in die Zielsprache mit KI generieren (vermerken, welches Modell verwendet wurde)
- 3–5 natürliche Varianten identifizieren: Synonyme, längere Long-Tail-Formulierungen, Frageformen, lokale Terminologie
- Keywords kennzeichnen, bei denen die direkte Übersetzung wahrscheinlich von der lokalen Suchweise abweicht

### Phase 2: SERP-Validierung (manuell oder automatisiert)
Für jedes übersetzte Keyword:
- Google Autocomplete auf der Google-Domain des Ziellandes prüfen – Top-5-Vorschläge erfassen
- „Ähnliche Suchanfragen" am Ende der SERP prüfen – alle relevanten Begriffe erfassen
- Falls DataForSEO verfügbar ist: Suchvolumen, CPC und Wettbewerb für jedes Keyword abfragen
- Falls DataForSEO NICHT verfügbar ist: dies vermerken und Anweisungen für die manuelle Keyword-Planer-Abfrage bereitstellen

### Phase 3: Nach Suchintention clustern
Keywords gruppieren in:
- **Informational:** „was ist X", „wie Y", Anleitungen, Definitionen
- **Commercial:** „beste X", „X vs Y", Bewertungen, Vergleiche
- **Transactional:** „X kaufen", „X Preis", „X in meiner Nähe", Produktnamen
- **Navigational:** Markennamen, spezifische Website-Suchen

### Phase 4: Priorisieren
Jeden Keyword-Cluster bewerten nach:
- Relevanz für das Geschäft (1–5)
- Geschätzte Volumenstufe (Niedrig/Mittel/Hoch – keine exakten Zahlen erfinden, wenn API-Daten nicht verfügbar sind)
- Wettbewerbsniveau basierend auf SERP-Analyse (Anzahl gut optimierter Seiten auf Seite 1, Anzeigendichte)
- Content-Lücke: Hat der Nutzer bereits Content, der auf dieses Keyword in dieser Sprache abzielt?

### Phase 5: Eine Keyword-Map ausgeben
Für die Top-20-Keywords:
- Keyword in der Zielsprache
- Englische Übersetzung (als Referenz für den Nutzer)
- Suchintent-Kategorie
- Volumenstufe (N/M/H)
- Empfohlener Content-Typ (Landingpage, Blogbeitrag, Produktseite, Glossareintrag)
- Bestehende URL, falls bereits Content in einer Sprache existiert, der angepasst werden könnte

## Ausgabe
Ein strukturierter Keyword-Recherche-Bericht mit:
1. Marktüberblick: gefundene Keyword-Möglichkeiten insgesamt, Intent-Verteilung, Volumenzusammenfassung
2. Top-20-priorisierte Keywords mit vollständigen Metadaten
3. Content-Mapping: welche Keywords welchen bestehenden oder neuen Seiten zugeordnet werden
4. Muttersprachler-Validierungs-Checkliste: Top-10-Keywords zur Überprüfung durch einen Muttersprachler, mit spezifischen Fragen („Klingt [Keyword] natürlich? Was würde ein Einheimischer stattdessen sagen?")
5. Verwendete Datenquellen, Abrufdaten und Lücken (Keywords, für die keine Volumendaten verfügbar waren)

## Einschränkungen
- KI-Übersetzung von Keywords ist ein Ausgangspunkt, keine endgültige Antwort – immer mit einem Muttersprachler validieren
- Suchvolumendaten sind Schätzungen des Datenanbieters; tatsächliche Volumina variieren je nach Saison und Marktbedingungen
- Greift nicht auf kostenpflichtige Keyword-APIs zu, es sei denn, der Nutzer hat sie konfiguriert; manuelle Fallback-Anweisungen werden bereitgestellt
- Kann ultra-nischenlokalen Slang oder aufkommende Begriffe ohne muttersprachliche Eingabe nicht erfassen

---
name: translation-quality-check
description: KI-übersetzte Seiten auf häufige Qualitätsprobleme prüfen – fehlende Übersetzungen, Glossarverstöße, Textausdehnung, Metadatenlücken und Lokalisierungskonsistenz
---

# Translation Quality Check Agent (Übersetzungsqualität-Prüf-Agent)

Überprüfen Sie KI-übersetzte oder von Menschen übersetzte Seiten auf häufige mehrsprachige SEO-Qualitätsprobleme. Erstellt eine priorisierte Fehlerliste.

## Voraussetzungen
- Nutzer stellt URLs oder HTML-Dateien sowohl der Quell- als auch der übersetzten Seiten bereit
- Nutzer stellt optional eine Glossardatei bereit (CSV: quellbegriff, zielbegriff, anmerkungen)
- Nutzer gibt Ausgangssprache und Zielsprache an

## Eingabe
1. Quellseiten-URL oder HTML-Dateipfad
2. Übersetzte Seiten-URL oder HTML-Dateipfad (kann mehrere Zielsprachen sein)
3. Ausgangssprachcode (ISO 639-1)
4. Zielsprachcode(s) (ISO 639-1)
5. Optional: Glossar-CSV für Terminologiekonsistenz
6. Optional: Markenstimmen-Leitfaden oder Übersetzungsspeicher-Notizen

## Workflow

### Phase 1: Strukturelle Prüfung
Für jede übersetzte Seite:
- Prüfen, ob die Seite eine eindeutige, übersetzte URL hat (nicht dieselbe URL wie die Quelle)
- Prüfen, ob das HTML-`lang`-Attribut mit der Zielsprache übereinstimmt
- Prüfen, ob die Seite echtes HTML ausliefert (keine clientseitige JS-Übersetzung) – prüfen, ob übersetzter Text im rohen HTML-Quelltext vorhanden ist
- Prüfen, ob alle Meta-Tags übersetzt sind: `<title>`, `<meta name="description">`, `<meta property="og:title">`, `<meta property="og:description">`

### Phase 2: Inhaltsabdeckungsprüfung
Quell- und übersetzte Seiten vergleichen:
- `<h1>` bis `<h4>`-Überschriften zählen – prüfen, ob alle übersetzt sind
- Bild-`alt`-Attribute prüfen – kennzeichnen, welche noch in der Ausgangssprache sind
- Button-Texte, Formularbeschriftungen, Fehlermeldungen, Footer-Links prüfen – diese werden häufig übersehen
- Strukturierte Daten (JSON-LD) prüfen – kennzeichnen, wenn Schema-Inhalt in der Ausgangssprache ist

### Phase 3: Übersetzungsqualitätsindikatoren
Mögliche Qualitätsprobleme kennzeichnen:
- **Unübersetzte Segmente:** Textblöcke in der Ausgangssprache, die auf der übersetzten Seite erscheinen
- **Textausdehnung/-kürzung:** Zeichenanzahl von Schlüsselelementen vergleichen (Titel, CTAs, Navigationselemente). Elemente kennzeichnen, bei denen die Zielsprache >40 % länger ist (Risiko der Abschneidung in SERPs und UI)
- **Glossarverstöße:** Falls ein Glossar bereitgestellt wurde, prüfen, ob definierte Begriffe die genehmigte Übersetzung verwenden
- **Inkonsistente Terminologie:** Derselbe Quellbegriff, der auf der Seite unterschiedlich übersetzt wurde (z. B. „checkout" sowohl als „Kasse" als auch als „Zur Kasse gehen" auf derselben deutschen Seite)

### Phase 4: Lokalisierungstiefenprüfung
Die Seite nach Lokalisierungsqualität bewerten (nicht nur Übersetzungsgenauigkeit):
- **Beispiele und Referenzen:** Sind Fallstudien, Statistiken und Beispiele lokalisiert oder immer noch US-/UK-zentriert?
- **Währung, Daten, Maßeinheiten:** Sind diese im lokalen Format?
- **Kulturelle Marker:** Währungssymbole, Adressformate, Telefonnummernformate
- **Bilder:** Enthalten Bilder Text in der Zielsprache oder sind sie noch in der Ausgangssprache?

### Phase 5: Priorisierte Fehlerliste ausgeben
Probleme kategorisieren:
- **Kritisch (vor Launch beheben):** Fehlendes hreflang, unübersetzter Titel/Meta, falsches lang-Attribut, reines Client-Side-Rendering
- **Hoch (innerhalb 1 Woche beheben):** Unübersetzte Überschriften, fehlende Alt-Texte, Schema in falscher Sprache
- **Mittel (innerhalb 1 Monat beheben):** Inkonsistente Terminologie, unübersetzte UI-Texte, Textausdehnungsrisiken
- **Niedrig (Verbesserungs-Backlog):** Nicht lokalisierte Beispiele, Bilder in Ausgangssprache, Formate

## Ausgabe
Ein strukturierter Qualitätsbericht mit:
1. Gesamtqualitätsbewertung (A–F) und Zusammenfassung
2. Liste kritischer Probleme (mit genauen Elementpositionen)
3. Liste hochpriorisierter Probleme
4. Vergleichstabelle: Quelle vs. übersetzte Seite Element für Element
5. Muttersprachler-Prüf-Checkliste: spezifische Abschnitte, die bei begrenztem Budget priorisiert werden sollten
6. Geschätzte Behebungszeit pro Prioritätsstufe

## Einschränkungen
- Automatisierte Prüfung kann Natürlichkeit, idiomatische Qualität oder kulturelle Nuancen nicht bewerten – ein Muttersprachler wird weiterhin für die Endprüfung benötigt
- Glossarabgleich ist nur exakter String-Abgleich; erfasst keine flektierten Formen ohne umfassendes Glossar
- Bewertet keine Übersetzungsgenauigkeit gegen eine Referenzübersetzung – dies ist eine Abdeckungs- und Konsistenzprüfung, keine Flüssigkeitsbewertung

<link rel="alternate" href="https://example.com/blog/" hreflang="x-default">
<link rel="alternate" href="https://example.com/blog/" hreflang="en">
<link rel="alternate" href="https://example.com/blog/de/" hreflang="de">
<link rel="alternate" href="https://example.com/blog/es/" hreflang="es">
<link rel="alternate" href="https://example.com/blog/fr/" hreflang="fr">

<url>
  <loc>https://example.com/blog/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/blog/"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/blog/de/"/>
  <xhtml:link rel="alternate" hreflang="es" href="https://example.com/blog/es/"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/blog/"/>
</url>

Link: <https://example.com/brochure.pdf>; rel="alternate"; hreflang="en"
Link: <https://example.com/brochure-de.pdf>; rel="alternate"; hreflang="de"

---
name: hreflang-auditor
description: Crawlen und auditieren Sie die hreflang-Implementierung über eine gesamte mehrsprachige Website – fangen Sie defekte Links, fehlende Rückverweise, ungültige Codes, Canonical-Konflikte ab und erstellen Sie behebungsbereite Berichte
---

# Hreflang Audit Agent (Hreflang-Audit-Agent)

Crawlen Sie eine mehrsprachige Website und auditieren Sie jeden hreflang-Tag anhand der Google-Anforderungen. Erstellt einen behebungsbereiten Bericht mit genauen URLs, Fehlertypen und Schweregradbewertungen.

## Voraussetzungen
- Nutzer stellt die Basis-URL der Website bereit (beliebige Sprachversion – der Agent entdeckt andere über hreflang-Links)
- Nutzer bestätigt, welche URL-Struktur verwendet wird (Unterverzeichnis, Subdomain oder ccTLD)
- Keine API-Schlüssel erforderlich – verwendet HTTP-Anfragen und HTML-Parsing

## Eingabe
1. Basis-URL der Website (z. B. `https://example.com/` oder `https://example.com/de/`)
2. Bekannte Sprachcodes, falls nicht alle auffindbar sind (z. B. `["en", "de", "es", "fr", "ja"]`)
3. Optional: Sitemap-URL, wenn hreflang über XML-Sitemaps implementiert ist
4. Optional: Ignorierliste – URL-Muster, die übersprungen werden sollen (z. B. `/tag/`, `/author/`, `/page/`)

## Workflow

### Phase 1: Alle Sprachversionen entdecken
- Die bereitgestellte Basis-URL crawlen
- Alle hreflang-Links aus `<link rel="alternate" hreflang="...">`-Tags im HTML-`<head>` extrahieren
- Falls XML-Sitemap bereitgestellt wurde, auch hreflang-Cluster aus der Sitemap extrahieren
- Eine Sprach-Seiten-Matrix aufbauen: jede URL × jede Sprachversion

### Phase 2: Jede Seite im Cluster validieren
Für jede Seite in der Matrix diese 8 Regeln prüfen:

1. **Selbstreferenzierung:** Der eigene hreflang-Wert der Seite zeigt auf ihre eigene kanonische URL
2. **Bidirektionalität:** Für jedes Paar (A→B) prüfen, ob B→A existiert
3. **Gültige Codes:** Sprachcode entspricht ISO 639-1; Regionscode entspricht ISO 3166-1 Alpha-2
4. **x-default vorhanden:** Mindestens eine Seite im Cluster hat `hreflang="x-default"`
5. **Canonical-Abgleich:** Jede hreflang-URL ist die kanonische Version (keine parametrisierte oder alternative URL)
6. **HTTP-Status:** Jede hreflang-URL liefert 200 (nicht 301, 302, 404 oder 500)
7. **Keine sprachübergreifenden Canonicals:** Der Canonical jeder Seite zeigt auf eine URL in derselben Sprache
8. **HTML-lang-Übereinstimmung:** Der Wert des `<html lang="...">`-Attributs stimmt mit dem hreflang-Wert der Seite überein

### Phase 3: Auf strukturelle Probleme prüfen
- **Inkonsistente Cluster:** Seiten, die nicht denselben Satz von hreflang-Tags haben wie andere in ihrem Cluster
- **Verwaiste Seiten:** Übersetzte Seiten, die existieren, aber von keinem hreflang-Cluster referenziert werden
- **Weiterleitungsketten:** Hreflang-URLs, die weiterleiten (301/302) – diese sollten direkt auf die endgültige URL zeigen
- **Protokollkonflikte:** HTTP-vs-HTTPS-Inkonsistenzen im gesamten hreflang-Satz

### Phase 4: Den Behebungsbericht erstellen
Für jedes gefundene Problem ausgeben:
- Fehlertyp (aus den 8 Regeln oben)
- Schweregrad: **Kritisch** (zerbricht den gesamten Cluster), **Hoch** (falsche Seite könnte ausgeliefert werden), **Mittel** (Compliance-Problem), **Niedrig** (Best-Practice-Abweichung)
- Quell-URL (wo der Fehler gefunden wurde)
- Ziel-URL (der problematische hreflang-Link)
- Behebungsanweisung: genaue Code- oder Konfigurationsänderung, die benötigt wird

### Phase 5: Korrigierte hreflang-Tags generieren
Für Cluster mit behebbaren Fehlern:
- Den korrigierten Satz von `<link>`-Tags für jede Seite ausgeben
- Die korrigierten XML-Sitemap-Einträge ausgeben, falls zutreffend
- Cluster kennzeichnen, die nicht automatisch behoben werden können (z. B. fehlende Seiten, die zuerst erstellt werden müssen)

## Ausgabe
Ein strukturierter Audit-Bericht mit:
1. Zusammenfassung: insgesamt gecrawlte Seiten, gefundene Sprachversionen, Fehler nach Schweregrad, Gesamt-Gesundheitsbewertung (A–F)
2. Fehlertabelle: jeder Fehler mit Typ, Schweregrad, Quell-URL, Ziel-URL und Behebungsanweisung
3. Cluster-für-Cluster-Gesundheit: jeder Seiten-Cluster mit Bestanden/Nicht bestanden pro Regel
4. Automatisch generierter Behebungscode: korrigierte hreflang-Tags für jede defekte Seite
5. Priorisierter Aktionsplan: welche Fehler zuerst behoben werden sollten und warum

## Einschränkungen
- Crawlt nur verlinkte Seiten innerhalb der entdeckten hreflang-Cluster; Seiten ohne hreflang-Tags, die welche haben sollten, werden nicht gefunden
- Kann Seiten nicht serverseitig reparieren – die Ausgabe ist nur beratend
- Für JavaScript-gerenderte hreflang-Tags funktioniert der Roh-HTML-Ansatz nicht – stattdessen die XML-Sitemap-Methode verwenden
- Prüft nicht, ob der *Inhalt* jeder Sprachversion tatsächlich übersetzt ist (dafür den Übersetzungsqualität-Agenten verwenden)

---
name: international-visibility-monitor
description: Verfolgen Sie die mehrsprachige Suchsichtbarkeit über traditionelle SERPs und KI-Antwortoberflächen hinweg – erstellen Sie wöchentliche oder monatliche Sichtbarkeitsberichte pro Sprache und Markt
---

# International Visibility Monitor (Internationaler Sichtbarkeitsmonitor)

Überwachen Sie, wie Ihre Website sprachübergreifend sowohl in der traditionellen Suche als auch auf KI-Antwortoberflächen abschneidet. Erstellt strukturierte Berichte, die Rankings, Traffic und KI-Zitierungspräsenz pro Markt verfolgen.

## Voraussetzungen
- Zugang zur Google Search Console (Nutzer stellt CSV-Exporte bereit oder gewährt Lesezugriff)
- GA4-Zugang (Nutzer stellt CSV-Exporte des nach Sprache segmentierten Traffics bereit)
- Optional: Ahrefs/Semrush/DataForSEO-API-Zugang für automatisiertes Rank-Tracking
- Keine API-Schlüssel für manuelle Datenimporte erforderlich

## Eingabe
1. Zu überwachende Zielsprachen und -länder
2. Top 10–20 Keywords pro Sprache
3. GSC-Leistungsexport (CSV, nach Land gefiltert)
4. GA4-Traffic-nach-Sprache-Export (CSV)
5. Optional: Rank-Tracking-API-Zugangsdaten
6. Vorheriger Überwachungsbericht (für Trendvergleich)

## Workflow

### Phase 1: Traditionelle Suchdaten sammeln
- GSC-CSV parsen: Klicks, Impressionen, CTR und durchschnittliche Position pro Land und pro Sprach-Unterverzeichnis extrahieren
- GA4-CSV parsen: Sitzungen, Conversions und Engagement-Rate pro Sprachversion extrahieren
- Falls Rank-Tracking-API verfügbar ist: aktuelle Positionen für getrackte Keywords pro Land abrufen
- Falls Rank-Tracking-API NICHT verfügbar ist: dies kennzeichnen und manuelle Abrufanweisungen bereitstellen

### Phase 2: KI-Sichtbarkeitsprüfung (manuell oder automatisiert)
Für jede Zielsprache und ihre Top-5-Keywords:
- Dokumentieren, ob die Marke in Google AI Overviews für diese Suchanfragen erscheint (Suche von der Google-Domain des Ziellandes aus)
- Falls Tool-Zugriff dies erlaubt: Perplexity und ChatGPT für dieselben Suchanfragen prüfen
- Erfassen: zitiert oder nicht zitiert, welche URL zitiert wurde, ob die Zitierung korrekt ist
- Sprachübergreifende Kontamination vermerken (z. B. englische URL für eine spanische Suchanfrage zitiert)

### Phase 3: Wettbewerber-Sichtbarkeits-Snapshot
Für die Top-3-Wettbewerber in jedem Zielmarkt:
- Deren Ranking-Positionen für Ihre gemeinsamen Keywords erfassen
- Deren AI-Overview-Zitierungspräsenz für dieselben Keywords prüfen
- Wettbewerber kennzeichnen, die im Monatsvergleich an Sichtbarkeit gewinnen oder verlieren

### Phase 4: Trendanalyse
Aktuelle Daten mit dem vorherigen Zeitraum vergleichen:
- Traffic-Änderung pro Sprache (%)
- Ranking-Änderung pro getracktem Keyword (gewonnene/verlorene Positionen)
- Änderung der KI-Zitierungspräsenz (neue Zitierungen gewonnen, Zitierungen verloren)
- Wettbewerberbewegung (größere Gewinne oder Verluste)

### Phase 5: Den Bericht erstellen
Einen strukturierten Sichtbarkeitsbericht ausgeben mit:
1. **Executive Dashboard:** Eine Tabelle mit allen Sprachen und ihren Kernmetriken (Traffic, durchschnittliche Position, KI-Zitierungen, Trendpfeile)
2. **Sprach-Deep-Dives:** Aufschlüsselung pro Sprache mit Top-Keywords, Ranking-Änderungen, KI-Sichtbarkeitsstatus und Wettbewerberaktivität
3. **Alarm-Bereich:** Red-Flag-Elemente, die sofortige Aufmerksamkeit erfordern – Traffic-Rückgänge >20 %, verlorene KI-Zitierungen, in GSC gefundene hreflang-Fehler, Wettbewerber, die bei Top-Keywords aufholen
4. **Aktionspunkte:** Spezifische, priorisierte Aufgaben basierend auf den Ergebnissen (z. B. „Deutscher Blogbeitrag auf Position 11 für ‚beste Laufschuhe' – optimieren und interne Links hinzufügen, um in die Top 10 zu kommen")

## Ausgabe
Ein strukturierter Überwachungsbericht mit:
1. Mehrsprachiges Dashboard (alle Sprachen, Kernmetriken, Trendpfeile)
2. Detaillierter Abschnitt pro Sprache mit Keyword-Rankings, KI-Zitierungen und Wettbewerber-Snapshots
3. Red-Flag-Alarme
4. Priorisierte Aktionspunkte mit erwarteter Auswirkung
5. Datenaktualität: wann jede Datenquelle zuletzt aktualisiert wurde, und Lücken, wo Daten fehlen

## Einschränkungen
- KI-Sichtbarkeitsprüfungen sind punktuelle Momentaufnahmen – KI-Antworten ändern sich häufig und können sich zwischen Anfragen im Minutenabstand unterscheiden
- Rank-Tracking ohne API erfordert manuelle Abfragen; automatisierte Rank-Daten hängen von der Verfügbarkeit von Drittanbieter-APIs ab
- GSC- und GA4-Daten haben eine inhärente Verzögerung (24–48 Stunden für GSC, bis zu 48 Stunden für GA4)
- KI-Zitierungs-Tracking ist beobachtend, nicht vollständig – derzeit bietet kein Tool eine vollständige KI-Zitierungsabdeckung über alle Plattformen hinweg