Kontoprüfung

Unternehmensentität über Website, Schema, Unternehmensprofil und Verzeichnisse vergleichen und jede Abweichung auflisten

Vergleicht Firmenname, Adresse, Telefonnummer, Social-Media-Profile und Identitätslinks zwischen dem sichtbaren Website-Text, dem JSON-LD-@id-Graphen, dem Google Unternehmensprofil, lokalen Verzeichnissen und Wikidata. Liefert einen Korrekturplan und einen reinen Fakten-Entwurf in JSON-LD, damit KI-Systeme dich korrekt erkennen. Es wird nichts verändert.

Wann du ihn nutzt

Wenn KI-Systeme oder Suchmaschinen Ihr Unternehmen verwechseln oder falsch wiedergeben könnten, weil Name, Adresse, Telefonnummer oder Website auf Ihrer Seite, im Schema, im Unternehmensprofil und in Verzeichnissen voneinander abweichen.

Was du bekommst

Eine Vergleichstabelle aller Abweichungen, ein priorisierter Korrekturplan mit alten und neuen Werten und ein faktenbasierter JSON-LD-Entwurf mit einem verknüpften @id-Graph, ohne dass etwas geändert wird.

Ändert er etwas in meinem Konto?

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

Funktioniert mit

SEO Intelligence, Business Profile

Vor dem Senden ausfüllen

[business name][site URL][location name or domain, or "none"][profile URLs][city][NEEDS CONFIRMATION]

Prüfe, ob die Entitätsinformationen für mein Unternehmen [business name] im Web durchgehend konsistent sind. Meine Website: [site URL]. Mein Standort im Google Unternehmensprofil: [location name or domain, or "none"]. Meine offiziellen Social-Media-Profile: [profile URLs]. Stadt: [city]. Das ist ein reiner Lese- und Planungsauftrag, ändere nichts. KI-Systeme erkennen ein Unternehmen, indem sie dieselben Fakten über verschiedene Quellen hinweg abgleichen. Weichen Name, Adresse, Telefonnummer oder Website zwischen den Quellen voneinander ab, behandelt ein System sie womöglich als zwei Unternehmen oder gibt falsche Angaben wieder. Vergleiche daher jeden Fakt Zeichen für Zeichen. 1. Sichtbare Fakten auf der Website. Lies die Startseite, die Kontaktseite und die Über-uns-Seite mit site_read_url und text=true (wenn truncated true ist, lies erneut mit max_bytes=1000000). Extrahiere Seite für Seite den sichtbaren Firmennamen, die Adresse, die Telefonnummer, die E-Mail-Adresse und die Öffnungszeiten. Weise gesondert darauf hin, wenn eine dieser Angaben ohne JavaScript nicht sichtbar ist. 2. Schema auf der Website. Lies dieselben drei Seiten sowie die zwei wichtigsten Leistungsseiten mit site_read_url und max_bytes=1000000 und extrahiere die `application/ld+json`-Blöcke aus dem Body. Liste für jeden Block Typ, @id, name, url, logo, telephone, address, sameAs und parentOrganization auf. Prüfe: Erscheint der Knoten Organization oder LocalBusiness auf jeder Seite mit derselben @id? Fehlt die @id ganz, lassen sich die Knoten nicht verknüpfen. Wird dasselbe Unternehmen auf verschiedenen Seiten unter unterschiedlichen Namen geführt? Stimmen Telefonnummer und Adresse im Schema mit dem sichtbaren Text überein? Liefert jede sameAs-URL mit site_read_url und max_bytes=0 den Status 200? 3. Unternehmensprofil. Falls ich einen Standort angegeben habe, lies Name, Adresse, Telefonnummer, Website, Kategorien und Öffnungszeiten mit gbp_location_details aus. Notiere, ob das Website-Feld auf die Startseite oder auf die passende Filialseite verweist. 4. Lokale Verzeichnisse. Prüfe in seo_history, ob es einen früheren Lauf mit diesen Argumenten gibt. Falls nicht, führe seo_local_listings mit brand=[business name] und city=[city] aus. Das Tool verbraucht pro Verzeichnis Credits. Sag mir also, wie viele Verzeichnisse abgefragt werden, bevor du den Standardsatz verwendest. Erfasse die Anzahl der Einträge pro Verzeichnis, als geschlossen markierte Einträge und Dubletten. Wenn ein Verzeichnis einen Fehler zurückgegeben hat, schreibe "konnte nicht gemessen werden", nicht "kein Eintrag". 5. Wikidata. Lies https://www.wikidata.org/w/api.php?action=wbsearchentities&search=[business name]&language=en&format=json mit site_read_url. Gibt es ein Item, prüfe, ob die offizielle Website mit meiner Website übereinstimmt. Gibt es keines, sag das, schlage aber bei einem kleinen Unternehmen nicht vor, eines anzulegen, weil für Wikidata Relevanzkriterien gelten. Gliedere die Ausgabe so. Zuerst eine Zusammenfassung in drei Sätzen. Dann eine Vergleichstabelle: Fakt (Name, Adresse, Telefonnummer, Website, Öffnungszeiten, Social-Media-Profile), sichtbarer Website-Text, Schema der Website, Unternehmensprofil, Verzeichnisse, Status (konsistent, abweichend, fehlt). Dann eine Schema-Tabelle: Seite, Typ, @id, Problem. Dann einen nach Wichtigkeit geordneten Korrekturplan: Nenne zu jedem Punkt, wo etwas geändert wird, den alten Wert, den neuen Wert und wer die Änderung vornimmt. Schreibe am Ende einen JSON-LD-Entwurf für einen einzigen @id-Graphen, der auf der gesamten Website verwendet werden kann: Organization oder den passenden LocalBusiness-Untertyp mit der id `[site URL]/#org` oder `/#business`, WebSite mit `/#website` und einer Publisher-Verknüpfung sowie sameAs, das nur offizielle Profile enthält, die den Status 200 liefern. Verwende nur Fakten, die auf der Website stehen oder die ich dir genannt habe. Wenn Öffnungszeiten, Koordinaten, Bewertungen oder ein Gründungsdatum nicht vorliegen, lass das Feld komplett weg, und kennzeichne jedes Feld, bei dem du unsicher bist, mit [NEEDS CONFIRMATION]. Das Umsetzen dieses Entwurfs ist ein eigener Auftrag, fasse also jetzt keine Datei und kein Profil an.

KI-Systeme erkennen ein Unternehmen, indem sie dieselben Fakten über verschiedene Quellen hinweg abgleichen. Weichen Name, Adresse, Telefonnummer oder Website zwischen den Quellen voneinander ab, behandelt ein System sie womöglich als zwei Unternehmen oder gibt falsche Angaben wieder. Vergleiche daher jeden Fakt Zeichen für Zeichen.

1. Sichtbare Fakten auf der Website. Lies die Startseite, die Kontaktseite und die Über-uns-Seite mit site_read_url und text=true (wenn truncated true ist, lies erneut mit max_bytes=1000000). Extrahiere Seite für Seite den sichtbaren Firmennamen, die Adresse, die Telefonnummer, die E-Mail-Adresse und die Öffnungszeiten. Weise gesondert darauf hin, wenn eine dieser Angaben ohne JavaScript nicht sichtbar ist.
2. Schema auf der Website. Lies dieselben drei Seiten sowie die zwei wichtigsten Leistungsseiten mit site_read_url und max_bytes=1000000 und extrahiere die `application/ld+json`-Blöcke aus dem Body. Liste für jeden Block Typ, @id, name, url, logo, telephone, address, sameAs und parentOrganization auf. Prüfe: Erscheint der Knoten Organization oder LocalBusiness auf jeder Seite mit derselben @id? Fehlt die @id ganz, lassen sich die Knoten nicht verknüpfen. Wird dasselbe Unternehmen auf verschiedenen Seiten unter unterschiedlichen Namen geführt? Stimmen Telefonnummer und Adresse im Schema mit dem sichtbaren Text überein? Liefert jede sameAs-URL mit site_read_url und max_bytes=0 den Status 200?
3. Unternehmensprofil. Falls ich einen Standort angegeben habe, lies Name, Adresse, Telefonnummer, Website, Kategorien und Öffnungszeiten mit gbp_location_details aus. Notiere, ob das Website-Feld auf die Startseite oder auf die passende Filialseite verweist.
4. Lokale Verzeichnisse. Prüfe in seo_history, ob es einen früheren Lauf mit diesen Argumenten gibt. Falls nicht, führe seo_local_listings mit brand=[business name] und city=[city] aus. Das Tool verbraucht pro Verzeichnis Credits. Sag mir also, wie viele Verzeichnisse abgefragt werden, bevor du den Standardsatz verwendest. Erfasse die Anzahl der Einträge pro Verzeichnis, als geschlossen markierte Einträge und Dubletten. Wenn ein Verzeichnis einen Fehler zurückgegeben hat, schreibe "konnte nicht gemessen werden", nicht "kein Eintrag".
5. Wikidata. Lies https://www.wikidata.org/w/api.php?action=wbsearchentities&search=[business name]&language=en&format=json mit site_read_url. Gibt es ein Item, prüfe, ob die offizielle Website mit meiner Website übereinstimmt. Gibt es keines, sag das, schlage aber bei einem kleinen Unternehmen nicht vor, eines anzulegen, weil für Wikidata Relevanzkriterien gelten.

Gliedere die Ausgabe so. Zuerst eine Zusammenfassung in drei Sätzen. Dann eine Vergleichstabelle: Fakt (Name, Adresse, Telefonnummer, Website, Öffnungszeiten, Social-Media-Profile), sichtbarer Website-Text, Schema der Website, Unternehmensprofil, Verzeichnisse, Status (konsistent, abweichend, fehlt). Dann eine Schema-Tabelle: Seite, Typ, @id, Problem. Dann einen nach Wichtigkeit geordneten Korrekturplan: Nenne zu jedem Punkt, wo etwas geändert wird, den alten Wert, den neuen Wert und wer die Änderung vornimmt.

Schreibe am Ende einen JSON-LD-Entwurf für einen einzigen @id-Graphen, der auf der gesamten Website verwendet werden kann: Organization oder den passenden LocalBusiness-Untertyp mit der id `[site URL]/#org` oder `/#business`, WebSite mit `/#website` und einer Publisher-Verknüpfung sowie sameAs, das nur offizielle Profile enthält, die den Status 200 liefern. Verwende nur Fakten, die auf der Website stehen oder die ich dir genannt habe. Wenn Öffnungszeiten, Koordinaten, Bewertungen oder ein Gründungsdatum nicht vorliegen, lass das Feld komplett weg, und kennzeichne jedes Feld, bei dem du unsicher bist, mit [NEEDS CONFIRMATION]. Das Umsetzen dieses Entwurfs ist ein eigener Auftrag, fasse also jetzt keine Datei und kein Profil an.

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 einem fiktiven Unternehmen, nicht auf echten Kundendaten)

Zusammenfassung. Blue Door Vets hat auf der Website und im Business Profile denselben Namen und dieselbe Telefonnummer, aber die Adresse lautet auf der Website "12 High St" und im Profil "12A High Street". Keiner der vier JSON-LD-Blöcke auf der Website hat eine @id, daher sind die Knoten Organization, WebSite und Seiten nicht miteinander verknüpft. In einem Verzeichnis gibt es zwei getrennte Einträge, und einer davon zeigt die alte Telefonnummer.

Fakt	Sichtbarer Text	Schema	Business Profile	Verzeichnisse	Status
Name	Blue Door Veterinary Clinic	Blue Door Vets	Blue Door Veterinary Clinic	2 Einträge, gleicher Name	Abweichend (Schema)
Adresse	12 High St	keine	12A High Street	Alte Adresse bei 1 Eintrag	Abweichend
Telefon	0161 000 0000	0161 000 0000	0161 000 0000	Alte Nummer bei 1 Eintrag	Abweichend (Verzeichnis)
Instagram	ja	in sameAs, 200	ja		Konsistent

Seite	Typ	@id	Problem
/	Organization	keine	Knoten kann nicht mit anderen Seiten verknüpft werden
/contact/	VeterinaryCare	keine	Adressfeld leer

Eine Verzeichnisabfrage hat einen Anbieterfehler zurückgegeben und ist daher als "konnte nicht gemessen werden" vermerkt. Es gibt kein Wikidata-Item.

Maßnahmenplan
1. Überall dasselbe Adressformat verwenden: "12A High Street" auf der Website und im Schema (Sie, nach Freigabe).
2. Das Verzeichnis bitten, den Eintrag mit der alten Telefonnummer zu schließen (Sie).
3. Den unten stehenden @id-Graphen auf alle Seiten anwenden (ein separater Auftrag).

Im JSON-LD-Entwurf sind die Öffnungszeiten mit [NEEDS CONFIRMATION] markiert, weil Website und Profil voneinander abweichen.

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

Konten kostenlos verbinden

Weitere Prompts

KontoprüfungNur lesend

Vollständiges Google-Ads-Konto-Audit mit den drei Maßnahmen, die zuerst umgesetzt werden sollten

Prüft das gesamte Konto in einem Durchgang, von Messung und Gebotsstrategie bis zu Kontostruktur und Landingpages. Sortiert die Ergebnisse nach Wirkung und benennt die ersten drei Maßnahmen, ohne etwas zu ändern.

Wann du ihn nutztWenn du ein Google-Ads-Konto übernimmst oder ihm misstraust und wissen willst, was wirklich falsch läuft und wo du mit der Behebung anfangen sollst.

Führe ein vollständiges Audit meines Google-Ads-Kontos [Kontoname] durch. Wenn das Konto jünger als 90 Tage ist, nutze alle verfügbaren Tage, andernfalls die letzten 90 Tage. Das ist eine reine Leseprüfung, ändere nichts.

Beginne mit account_snapshot, um für jede Kampagne Status, Budget, Gebotsstrategie, Alter und die Ergebnisse seit dem Start zu erhalten. Trenne die Kampagnen, die Ergebnisse liefern, von denen, die Budget verbrauchen, ohne zu konvertieren. Gehe dann diese Bereiche der Reihe nach durch:

1. Messung. Liste die primären Conversion-Aktionen mit list_conversion_actions auf. Markiere jede primäre Aktion, die in den letzten 30 Tagen nichts erfasst hat. Suche nach Konfigurationen, die dieselbe Person doppelt zählen können, zum Beispiel ein Klick auf die Telefonnummer und ein Klick auf WhatsApp auf der Website, die als zwei getrennte primäre Aktionen eingerichtet sind, oder das Google-Ads-Tag und ein importiertes GA4-Event, die beide für dasselbe Formular als primär gelten. Prüfe, wie viele Klicks auf den Anrufbutton in den Anzeigen entfielen und ob diese Anrufe tatsächlich erfasst wurden, mit google_ads_query auf call_view.
2. Gebote und Budget. Zeige mit impression_share_analysis pro Kampagne den durch Budget und durch Rang verlorenen Anteil an Impressionen. Finde mit keyword_quality_report Keywords, die unter dem Gebot für die erste Seite liegen oder wegen niedriger Qualität selten ausgeliefert werden. Sage bei Kampagnen mit Smart Bidding, ob die letzten 30 Tage genügend Conversions für das verwendete Ziel enthalten.
3. Struktur. Prüfe, ob Markensuchen sich eine Kampagne mit generischen Suchen teilen, ob jede Anzeigengruppe auf die Seite ihrer eigenen Leistung verweist und ob dasselbe Keyword in mehr als einer Anzeigengruppe steht.
4. Suchbegriffe. Trenne mit search_terms_report Begriffe, die Budget verbrauchen, ohne zu konvertieren, Wettbewerbermarken und informationsorientierte Suchen. Zähle einen Begriff mit mindestens einer Conversion nie als Verschwendung.
5. Anzeigen und Assets. Prüfe die Anzeigeneffektivität, abgelehnte Assets und ob Sitelinks auf die richtige Seite verweisen. Markiere separat jeden Text und jedes Asset, das eine Leistung beschreibt, die das Unternehmen nicht anbietet: [nicht angebotene Leistungen, oder "keine" eintragen].
6. Landingpages. Hole mit google_ads_query aus landing_page_view Klicks, Kosten und Conversion-Rate pro Seite. Prüfe auf den Seiten mit dem höchsten Budgetverbrauch, ob ein Telefon- und ein WhatsApp-Button vorhanden sind, und kontrolliere die mobile Ladegeschwindigkeit mit core_web_vitals.
7. Standort, Zeitplan und Gerät. Zeige, ob die Standortoption auf "Präsenz" eingestellt ist, wie viel Budget außerhalb des Zielgebiets ausgegeben wird sowie Ausgaben und Conversions außerhalb von [Geschäftszeiten].

Formatiere die Ausgabe so: zuerst eine Zusammenfassung in fünf Sätzen, wie das Konto dasteht. Danach eine nach Wichtigkeit sortierte Ergebnistabelle: Problem, Beleg, geschätzte Wirkung, Empfehlung. Am Ende die drei Maßnahmen, die zuerst umgesetzt werden sollten, und warum jede davon zuerst kommt. Wo die Daten für eine Schlussfolgerung nicht ausreichen, rate nicht, sondern sage, was fehlt.

KontoprüfungNur lesend

Vollständiges Meta-Ads-Konto-Audit mit den drei wichtigsten Sofortmaßnahmen

Prüft in einem Durchgang Messung, Auslieferungsprobleme, Lernphase, Targeting, Placements und Creative-Ermüdung. Priorisiert die Erkenntnisse und nennt die ersten drei Maßnahmen, ohne etwas zu verändern.

Wann du ihn nutztWenn die Ergebnisse deiner Meta-Anzeigen eingebrochen sind oder stagnieren und du wissen willst, was im Konto schiefläuft, bevor du etwas änderst.

Prüfe mein Meta-Werbekonto [ad account] von Anfang bis Ende. Nimm die letzten 30 Tage als Hauptzeitraum und die 30 Tage davor als Vergleich. Das ist eine reine Leseprüfung, verändere nichts.

Beginne mit account_snapshot für die Plattform meta, um Status, Budget, Zielsetzung, Alter und die Ergebnisse seit dem Start jeder Kampagne zu erhalten. Meta kennt keine einheitliche Conversion-Zahl, verwende also für jede Kampagne das Ergebnis, auf das sie tatsächlich optimiert (Leads, begonnene Nachrichtenunterhaltungen, Käufe). Gehe dann diese Bereiche der Reihe nach durch:

1. Messung. Prüfe mit list_meta_pixels den Zeitpunkt des letzten Pixel-Events. Bestätige, dass das Event, auf das jede Kampagne optimiert, tatsächlich erfasst wird. Markiere Setups, die dasselbe Ergebnis doppelt zählen können, zum Beispiel Leads, die sowohl über den Pixel als auch über ein Sofortformular erfasst werden.
2. Auslieferung. Liste Anzeigengruppen auf, die abgelehnt wurden, in der Prüfung hängen, keine aktive Anzeige mehr haben oder weniger als die Hälfte ihres Budgets ausgeben. Nenne zu jeder den von Meta angegebenen Grund.
3. Lernphase. Finde Anzeigengruppen, die so stark aufgeteilt sind, dass sie keine 50 Ergebnisse pro Woche erreichen können. Zeige mit meta_change_history die Änderungen der letzten 14 Tage, die das Lernen zurückgesetzt haben.
4. Targeting und Zielgruppen. Markiere Anzeigengruppen, die dieselbe Zielgruppe ansprechen, sowie Anzeigengruppen, deren Frequenz über [maximum frequency] liegt.
5. Placements und Geräte. Vergleiche mit get_report die Kosten pro Ergebnis nach publisher_platform und nach Gerät mit dem Kontodurchschnitt. Triff keine Entscheidungen auf Basis von Segmenten mit weniger als 20 Ergebnissen.
6. Creatives. Betrachte eine Anzeige als ermüdet, wenn die Frequenz steigt, während die Klickrate sinkt und die Kosten pro Ergebnis zunehmen. Beschreibe kurz den Ansatz, den die erfolgreichen Anzeigen gemeinsam haben.
7. Ziel. Prüfe, ob die Seite oder der WhatsApp-Link, auf die die Anzeigen verweisen, funktioniert und zur Zielsetzung passt.

Gliedere die Ausgabe so: zuerst eine Zusammenfassung in fünf Sätzen, wie das Konto dasteht. Danach eine nach Wichtigkeit geordnete Tabelle der Erkenntnisse: Problem, Beleg, geschätzte Auswirkung, Empfehlung. Zum Schluss die drei Maßnahmen, die zuerst umgesetzt werden sollten, und warum jede davon an dieser Stelle steht. Wo die Daten für eine Schlussfolgerung nicht ausreichen, rate nicht, sondern sage, was fehlt.

KontoprüfungÄndert nach deiner Freigabe

Telefon- und WhatsApp-Anfragen zu einer verlässlichen Conversion zusammenführen

Verhindert, dass eine Person doppelt gezählt wird, wenn sie sowohl anruft als auch eine Nachricht schickt. Verknüpft die beiden Buttons auf der Website mit einer einzigen Conversion und prüft, ob der Anruf-Button in den Anzeigen überhaupt gemessen wird.

Wann du ihn nutztWenn Interessenten über Ihre Website sowohl anrufen als auch per WhatsApp schreiben und Sie vermuten, dass eine Person doppelt als Conversion gezählt wird und Ihre Kosten pro Conversion zu günstig aussehen.

In meinem Google-Ads-Konto [Kontoname] erreichen uns Interessenten über die Telefon- und WhatsApp-Buttons auf der Website. Wenn eine Person, die beide Buttons klickt, als zwei Conversions zählt, sehen meine Kosten pro Conversion günstiger aus, als sie tatsächlich sind, und der Gebotsalgorithmus lernt das Falsche. Behebe das.

1. Bestehende Einrichtung erfassen. Liste mit list_conversion_actions die primären Aktionen, ihre Kategorien und Zählweisen auf. Zeige in meinem Tag-Manager-Container [GTM-Container-ID] mit list_gtm_tags, welcher Tag welches Conversion-Label auslöst. Schätze anhand von Zahlen, wie oft ein einzelner Anzeigenklick in den letzten 30 Tagen mehr als eine Kontakt-Conversion erzeugt haben könnte.
2. Der Anruf-Button in den Anzeigen. Prüfe mit google_ads_query, wie viele Klicks und wie viel Budget auf den Anruf-Button in den Anzeigen entfielen, und kontrolliere mit call_view, ob diese Anrufe erfasst wurden. Wenn es Klicks, aber keine Einträge gibt, sag das deutlich und biete zwei Optionen an: das Anruf-Asset entfernen oder diese Klicks als nicht gemessenen Traffic akzeptieren.
3. Plan vorlegen. Schlage eine einzige Conversion-Aktion mit dem Namen "Kontakt-Klick (Telefon + WhatsApp)" vor, bei der die Zählweise auf "Eine" steht. Verknüpfe sie mit einem Tag, das sowohl beim Telefon- als auch beim WhatsApp-Trigger feuert. Stelle die beiden alten Aktionen auf sekundär. Sag, ob bei Kampagnen mit Smart Bidding das Ziel überprüft werden muss, weil die Zahl der Conversions sinken wird.
4. Nach meiner Freigabe umsetzen. Lege die Conversion-Aktion an, stelle die Zählweise auf "Eine", aktualisiere den Tag im Tag Manager und zeige mir vor der Veröffentlichung die Liste der Änderungen. Notiere nach der Veröffentlichung, welche Version wiederhergestellt werden kann.

Schließe mit einem kurzen Testplan ab: Wie sehe ich im Vorschaumodus, dass nur der neue Tag feuert, wenn beide Buttons geklickt werden, und wie viele Tage dauert es, bis sich die Korrektur in den echten Daten zeigt?

KontoprüfungNur lesend

Vollständiges SEO-, AEO- und GEO-Audit mit belegter Scorecard

Bewertet Zugriff, technischen Zustand, strukturierte Daten, Zitierfähigkeit der Inhalte, Vertrauenssignale und gemessene KI-Sichtbarkeit in sechs Bereichen mit je fünf konkreten Prüfpunkten. Zeigt zu jedem Punkt den Beleg und sortiert die Maßnahmen nach Wirkung und Aufwand, ohne etwas zu verändern.

Wann du ihn nutztWenn Sie wissen möchten, wie sichtbar und vertrauenswürdig Ihre Website in der klassischen Suche, in Antwortmaschinen und in KI-Suche ist, und eine priorisierte Liste brauchen, was zuerst zu beheben ist.

Auditiere meine Website [site URL] von Anfang bis Ende für die klassische Suche, Answer Engines (AEO) und KI-Suche (GEO). Meine Search-Console-Property: [Search Console property]. Wichtigster Wettbewerber: [competitor domain, or "none"]. Markt: [country], Sprache: [language code]. Die 3 Suchanfragen, die mir das meiste Geschäft bringen: [3 commercial queries]. Meine wichtigsten Seitentemplates: [homepage, one service page, one blog post URL]. Die Aufgabe ist rein lesend.

Credit-Regel: Prüfe vor dem Start mit seo_history frühere Läufe und rufe die wiederverwendbaren mit denselben Argumenten erneut auf. Zeige mir einmal die Liste der neuen Aufrufe, die Credits verbrauchen, und hole meine Freigabe ein.

Datenerhebung:
1. Führe die gebündelte Analyse mit seo_full_analysis aus und übergib domain, competitor, location und language. Der Abschnitt zur KI-Sichtbarkeit misst das einzelne Keyword, für das die Website am besten rankt, und das kann mit meinem Geschäft nichts zu tun haben; verwende diesen Abschnitt nicht für die Bewertung, sondern miss meine 3 kommerziellen Suchanfragen mit seo_ai_overview und target=[domain]. Wenn references leer ist, zähle die Domains der Links innerhalb von ai_answer.
2. Führe seo_site_crawl mit max_pages nahe an der Seitenzahl der Website aus (höchstens [page limit]). Der Aufruf liefert eine task_id; rufe ihn nach 60 bis 90 Sekunden erneut mit derselben task_id auf und warte, bis die Zusammenfassung vorliegt. Hole bei Bedarf die vollständige URL-Liste eines Problems über den Parameter issue. Wenn das Crawl-Limit nicht die gesamte Website abdeckt, weise darauf hin, dass die Ergebnisse eine Stichprobe sind.
3. Lies robots.txt, sitemap.xml und llms.txt mit site_read_url. Lies meine Template-Seiten mit text=true (wenn truncated true ist, erneut mit max_bytes=1000000) und mit outline=true. Für JSON-LD lies dieselben Seiten mit max_bytes=1000000 und extrahiere die Blöcke.
4. Miss die Startseite und die Leistungsseite mit seo_audit und strategy='mobile'. Verwende für die Core Web Vitals reale Nutzerdaten (Felddaten), sofern vorhanden, andernfalls den Labor-Wert, und gib an, welchen du genutzt hast.
5. Nutze get_report mit platform='search_console' und den Aufschlüsselungen 'query by impressions' und 'page by impressions' für die letzten 90 Tage. Prüfe die 10 Seiten mit den meisten Impressionen mit gsc_inspect_urls. Hole den Sitemap-Status mit gsc_sitemaps.
6. Denke daran, dass verschiedene Tools unterschiedliche Versionen derselben Seite sehen können: Wenn seo_technical_audit oder seo_site_crawl einen Title in einer anderen Sprache misst als site_read_url anzeigt, halte das als Befund fest, denn die Website leitet Besucher möglicherweise nach Land um.

Scorecard: sechs Bereiche mit je fünf Prüfpunkten, jeder Prüfpunkt bestanden (1) oder nicht bestanden (0). Wenn zu einem Prüfpunkt keine Daten vorliegen, schreibe "nicht gemessen" und nimm ihn aus dem Nenner; bewerte niemals durch Raten.
1. Zugriff und Crawlbarkeit: robots.txt ist für KI-Crawler mit Suchfunktion geöffnet; wichtige Seiten liefern 200 mit höchstens einer Weiterleitung; kein noindex auf wichtigen Seiten; die Sitemap enthält keine Fehler und enthält die wichtigen Seiten; der Hauptinhalt ist ohne JavaScript sichtbar.
2. Technischer Zustand und Geschwindigkeit: LCP mobil unter 2,5 Sekunden; CLS unter 0,1; INP unter 200 ms; keine defekten Seiten oder defekten internen Links im Crawl; keine doppelten Titles oder Descriptions.
3. Strukturierte Daten und Entität: Ein Organization- oder LocalBusiness-Knoten ist vorhanden; die Knoten sind über @id verknüpft; das Schema passt zum Seitentyp (Service, Article, Product); die Fakten im Schema stimmen mit dem sichtbaren Text überein; die sameAs-URLs funktionieren.
4. Zitierfähigkeit der Inhalte: Der erste Absatz wichtiger Seiten beantwortet die Frage direkt; Überschriften benennen das Thema oder die Frage klar; vergleichbare Fakten stehen in einer Tabelle; eine seitenspezifische FAQ ist vorhanden; es gibt konkrete Zahlen und Daten.
5. Vertrauenssignale: Die Über-uns-Seite ist konkret (wer, wo, seit wann); Kontaktdaten stehen auf der Website und sind konsistent; Beiträge nennen einen Autor oder Herausgeber; Veröffentlichungs- und Aktualisierungsdatum sind sichtbar; Rechtstexte sind über statische Links im Footer erreichbar.
6. Gemessene KI-Sichtbarkeit: Für mindestens eine der 3 kommerziellen Suchanfragen wird die Website in der KI-Antwort von Google zitiert; sie wird bei der Markenanfrage zitiert; llms.txt ist vorhanden und korrekt; die Search Console zeigt Klicks von Non-Brand-Suchanfragen; wenn der wichtigste Wettbewerber bei diesen Suchanfragen zitiert wird, gibt es mindestens eine, bei der auch ich zitiert werde.

Formatiere die Ausgabe so. Zuerst eine Management-Zusammenfassung in fünf Sätzen. Dann die Score-Tabelle: Bereich, Score (z. B. 3/5), nicht bestandene Prüfpunkte. Dann die Beleg-Tabelle: Bereich, Prüfpunkt, Ergebnis, Beleg (Tool-Name und zurückgegebener Wert), betroffene URLs. Dann die Maßnahmenliste: zu jedem Punkt die Wirkung (hoch, mittel, niedrig), der Aufwand (Stunden, Tage, Wochen) und wer ihn umsetzt; hohe Wirkung bei geringem Aufwand zuerst. Zum Schluss die ersten drei Maßnahmen und warum sie an erster Stelle stehen. Fälle kein Urteil über etwas, das nicht gemessen wurde.