# AI Readiness Audit

Das AI Readiness Audit crawlt jede Seite Ihrer Website (oder eine gefilterte Teilmenge) und bewertet sie über sieben Dimensionen, die beeinflussen, wie wirksam KI-Systeme Ihre Inhalte finden, verstehen und zitieren können. Sie erhalten eine Aufschlüsselung je Seite sowie einen aggregierten Website-Score, um genau zu erkennen, wo sich Optimierungsaufwand lohnt.

> **Erfordert eine Property mit eigener crawlbarer Domain.** Das Audit crawlt und bewertet eine ganze Website, es läuft daher **nur auf Marken-Properties**. [Produkt](/docs/ai-visibility-features/product-tracking)-, [Personen](/docs/ai-visibility-features/person-tracking)-, Kategorie- und [Standort](/docs/dashboards/locations)-Properties besitzen keine eigene Website — die Seiten eines Produkts liegen zum Beispiel auf der Domain des Mutterunternehmens. Führen Sie das Audit auf der übergeordneten Marken-Property aus, dann sind diese Seiten dort abgedeckt.

## Was Sie lernen

In dieser Anleitung erfahren Sie:

- Was die sieben Bewertungsdimensionen sind und warum sie zählen
- Wie jede Dimension bewertet wird (Schwellenwerte, Gewichte und Methodik)
- Wie Sie ein Audit starten, Seiten filtern und Seitengruppen speichern
- Wie Sie Ihre Ergebnisse lesen und daraus Maßnahmen ableiten
- Wie Preise und Verbrauch bei den verschiedenen Plantypen funktionieren

---

## Die sieben Dimensionen

Jede auditierte Seite erhält in jeder anwendbaren Dimension einen Wert von 0 bis 100. Manche Dimensionen sind nicht für jeden Seitentyp anwendbar — ist eine Dimension für die erkannte Absicht einer Seite nicht relevant (z. B. Lesbarkeit auf einer Startseite), wird sie vom Gesamtscore dieser Seite ausgenommen und die übrigen Gewichte werden neu normalisiert.

| Dimension | Gewicht | Was sie misst |
|---|---|---|
| **Statischer Inhaltsanteil** | 22 % | Wie viel Inhalt ohne JavaScript sichtbar ist |
| **Citation Readiness** | 20 % | Wie gut Inhalte für die Zitierung durch KI strukturiert sind |
| **Strukturierte Daten** | 18 % | Ob die richtigen JSON-LD-Schemata vorhanden und vollständig sind |
| **Performance für KI** | 14 % | Wie schnell und effizient Inhalte an KI-Crawler ausgeliefert werden |
| **E-E-A-T-Signale** | 14 % | Vertrauens- und Autoritätssignale auf Marken- und Seitenebene |
| **Lesbarkeit** | 10 % | Ob Inhalte auf einem angemessenen Leseniveau verfasst sind |
| **Barrierefreiheit** | 10 % | Ob die Seite KI-relevante Standards der Barrierefreiheit erfüllt |

Der **Gesamtscore einer Seite** ist der gewichtete Durchschnitt aller nicht leeren Dimensionswerte. Liefert eine Dimension für eine bestimmte Seite „N/A", wird ihr Gewicht anteilig auf die übrigen Dimensionen verteilt.

Der **Gesamtscore der Website** ist der Durchschnitt aller Seiten-Gesamtscores.

---

## Details zu den Dimensionen

### Statischer Inhaltsanteil

KI-Crawler — darunter Googlebot für Gemini, GPTBot und ClaudeBot — führen in der Regel kein JavaScript aus. Wird Ihr Seiteninhalt clientseitig gerendert (etwa mit React, Vue oder einem anderen SPA-Framework), sehen diese Crawler womöglich wenig oder gar keinen Inhalt.

Diese Dimension vergleicht den Text aus einem einfachen HTTP-Abruf (ohne JavaScript) mit dem Text aus einer vollständig JavaScript-gerenderten Fassung der Seite.

**So funktioniert es:**

1. Wir rufen das rohe HTML Ihrer Seite ohne JavaScript-Ausführung ab und extrahieren lesbaren Text
2. Wir rendern die Seite in einem Headless-Browser mit vollständiger JavaScript-Ausführung und extrahieren lesbaren Text
3. Wir zählen die Token beider Fassungen und berechnen ein Verhältnis: `statische Token / gerenderte Token`

**Bewertungsschwellen:**

| Verhältnis | Wertebereich | Status |
|---|---|---|
| 80 % oder mehr | 80–100 | Grün |
| 50–79 % | 40–79 | Gelb |
| Unter 50 % | 0–39 | Rot |
| Kein gerenderter Inhalt | 0 | Rot |

**Was ein niedriger Wert bedeutet:** KI-Crawlern entgeht ein erheblicher Teil Ihrer Inhalte. Erwägen Sie serverseitiges Rendering (SSR), statische Generierung (SSG) oder stellen Sie sicher, dass kritische Inhalte bereits in der ersten HTML-Antwort enthalten sind.

---

### Citation Readiness

Diese Dimension bewertet mit einem LLM, wie gut Ihre Inhalte dafür strukturiert sind, von einem KI-System herangezogen und zitiert zu werden. Die Bewertungskriterien richten sich nach dem Seitentyp.

**Bewertungsprofile:**

- **Informationsinhalte** (Artikel, Forschung, technische Dokumentation, Support-Seiten): bewertet nach Qualität der direkten Antwort, Informationsdichte, struktureller Klarheit, Quellenangaben, Vollständigkeit, Aktualitätssignalen, Grounding-Effizienz und Übereinstimmung der Meta-Beschreibung
- **Produktinhalte** (Produktseiten, Preise, Kaufstrecken): bewertet nach Produktklarheit, Spezifikationsdichte, Alleinstellungsmerkmalen, Social Proof, Kaufkontext, Vergleichbarkeit und Übereinstimmung der Meta-Beschreibung
- **Service-/Markeninhalte** (Startseiten, Unternehmensseiten, Community, Events, Karriere): bewertet nach Leistungsdefinition, Zielgruppenklarheit, Prozesstransparenz, Vertrauenssignalen, Ergebniskonkretheit, Kontaktwegen und Übereinstimmung der Meta-Beschreibung

**Vorabprüfungen:**

- Seiten mit weniger als 50 Wörtern erhalten automatisch den Wert 0
- Seiten mit 50–99 Wörtern werden als N/A gewertet (übersprungen) — es fehlt an Inhalt für eine sinnvolle Bewertung der Citation Readiness. Das betrifft häufig CTA-Seiten, Splash-Seiten, Sammlungen (Kategorie- oder Tag-Seiten für Blogs oder Produktkollektionen) sowie dünne Marketingseiten. Ergänzen Sie substanzielle Inhalte, um einen Wert zu erhalten.
- Fehlende `<h1>`-Überschrift: −15 Punkte
- Fehlende `<h2>`- oder `<h3>`-Zwischenüberschriften: −10 Punkte
- Fehlende Meta-Beschreibung: −10 Punkte
- Meta-Beschreibung kürzer als 120 Zeichen: −5 Punkte
- Generische Meta-Beschreibung (z. B. „Willkommen bei …", „Erfahren Sie mehr über …"): −5 Punkte

**Warum die Meta-Beschreibung für KI zählt:** Untersuchungen von [QueryBurst](https://queryburst.com/blog/how-chatgpt-works/) und [RESONEO](https://think.resoneo.com/chatgpt) haben gezeigt, dass KI-Such-Pipelines wie ChatGPT einen mehrstufigen Auswahlprozess nutzen. Bevor der Inhalt einer Seite überhaupt gelesen wird, filtert ein leichtgewichtiges Auswahlmodell die Kandidatenseiten allein anhand von SERP-Metadaten: Titel, Meta-Beschreibung und URL. Eine fehlende, generische oder unpassende Meta-Beschreibung verringert die Chance, dass die Seite vom KI-System überhaupt abgerufen wird. Damit ist die Meta-Beschreibung ein kritisches **Auswahltor** — nicht bloß eine Klickraten-Optimierung für menschliche Suchende.

Das Audit prüft, ob Ihre Meta-Beschreibung:

- **Den Kerninhalt der Seite zutreffend vorwegnimmt**, sodass ein Auswahlmodell die Relevanz bestimmen kann, ohne die Seite zu lesen
- **Zur Absicht der Seite passt** — die Meta-Beschreibung einer Produktseite sollte das Produkt und sein zentrales Unterscheidungsmerkmal nennen; eine Informationsseite sollte ihr Thema benennen
- **Konkret statt generisch ist** — Floskeln wie „Willkommen bei [Marke]" oder „Offizielle Seite für …" liefern Auswahlmodellen kein Signal
- **In der optimalen Länge liegt** (120–160 Zeichen) — dem Bereich, der in Suchergebnissen am zuverlässigsten angezeigt wird

Auf Website-Ebene erkennt das Audit außerdem **doppelte Meta-Beschreibungen** — Seiten, die sich dieselbe Meta-Beschreibung mit mehr als zwei weiteren Seiten teilen, werden markiert, da identische Beschreibungen auf Vorlagen-Inhalte hindeuten, die kein eigenständiges Auswahlsignal liefern.

**Übersprungene Seiten:** Authentifizierungs- und Rechtsseiten werden nicht auf Citation Readiness geprüft (Wertung N/A). Seiten mit weniger als 100 Wörtern werden ebenfalls übersprungen — ihnen fehlt die Substanz für eine sinnvolle Bewertung.

**Schwellenwerte:** Grün ≥ 70 | Gelb 40–69 | Rot 0–39

**Was ein niedriger Wert bedeutet:** Ihre Inhalte sind vielleicht fachlich korrekt, aber nicht so strukturiert, dass KI-Systeme sie leicht extrahieren, zusammenfassen und zitieren können. Achten Sie auf klare Überschriften, knappe Antworten auf wahrscheinliche Fragen, gut gegliederte Abschnitte und eine Meta-Beschreibung, die Inhalt und Absicht der Seite klar vorwegnimmt.

#### Analyse der Token-Chunk-Qualität

Ergänzend zur LLM-Bewertung umfasst die Citation Readiness eine **Analyse der Token-Chunk-Qualität**. Sie prüft, wie gut Ihre Inhalte für die gechunkten Token-Verarbeitungsfenster strukturiert sind, die KI-Systeme wie ChatGPT verwenden.

**Hintergrund:** Untersuchungen von [QueryBurst](https://queryburst.com/blog/how-chatgpt-works/) zeigen, dass die Such-Pipeline von ChatGPT und GPT-OSS-20B ein gleitendes Aufmerksamkeitsfenster von etwa 128 Token nutzen. Inhalte, die sich nicht an diesen Fenstern ausrichten — oder die sich über lange Strecken ohne strukturelle Marker erstrecken — laufen Gefahr, beim Extrahieren teilweise übersprungen oder fehlinterpretiert zu werden.

**So funktioniert es:**

Bevor eine Chunk-Analyse möglich ist, müssen wir den tatsächlichen Inhalt Ihrer Seite vom umgebenden Beiwerk isolieren (Navigationsmenüs, Fußbereiche, Seitenleisten, Cookie-Banner, Warenkorb-Panels usw.). Das geschieht in drei Stufen:

1. **Extraktion des Hauptinhalts-Containers** — Wir nutzen eine priorisierte Liste von CSS-Selektoren, um den spezifischsten Inhaltscontainer im rohen HTML zu finden. Gewählt wird der erste passende Selektor, dessen Inhalt die Mindestgrößen erfüllt (mindestens 100 Zeichen und mindestens 5 % der gesamten Body-Größe). Passt kein Container, fallen wir auf den vollständigen `<body>` zurück.

2. **Defuddle-Bereinigung** — Das isolierte HTML läuft durch [Defuddle](https://github.com/kepano/defuddle), das verbliebenes Beiwerk entfernt, das die Container-Extraktion passiert hat: Seitenleisten, Filter-/Sortier-Oberflächen, Cookie-Banner, Kommentarbereiche, Werbeelemente und Reste mobiler Menüs.

3. **Markdown-Konvertierung** — Das bereinigte HTML wird mit [Turndown](https://github.com/mixmark-io/turndown) in Markdown umgewandelt, mit Überschriften im ATX-Stil (`##`), umschlossenen Codeblöcken und `-` als Aufzählungszeichen. Link-URLs werden entfernt (nur der Ankertext bleibt) und Bilder in ein leichtgewichtiges Format `[Image: Alternativtext]` überführt.

**Container-Selektoren nach Plattform:**

Die Selektorenliste wird in Prioritätsreihenfolge geprüft — der erste Treffer gewinnt. Diese Tabelle zeigt die geprüften Selektoren, gruppiert nach Plattform. Nutzt Ihre Website eine hier nicht gelistete Plattform oder ein anderes Theme und wir isolieren Ihren Inhalt nicht korrekt, [sagen Sie uns Bescheid](/contact) — wir können Unterstützung ergänzen.

| Priorität | Plattform | Selektoren |
|---|---|---|
| 1 | **Artikel-Container** (alle Plattformen) | `<article>`, `[role="article"]` |
| 2 | **Semantisches HTML5** (alle Plattformen) | `<main>`, `[role="main"]` |
| 3 | **Gängige IDs** (plattformübergreifend) | `#main-content`, `#MainContent`, `#main`, `#content`, `#primary`, `#page-content`, `#site-content` |
| 4 | **Gängige Klassen** (plattformübergreifend) | `.main-content`, `.page-content`, `.site-content`, `.content-area`, `.entry-content`, `.post-content` |
| 5 | **Shopify** | `#shopify-section-template--main`, `[data-section-type="collection-template"]`, `[data-section-type="product-template"]`, `[data-section-type="article-template"]`, `.shopify-section--main` |
| 6 | **WordPress** | `#primary .entry-content`, `article.post`, `article.page`, `.hentry` |
| 7 | **Wix** | `#PAGES_CONTAINER`, `#SITE_PAGES` |
| 8 | **Squarespace** | `.Main-content`, `#page` |

**Warum das für die Chunk-Qualität zählt:** Gelingt es der Inhaltsextraktion nicht, den Hauptinhalt zu isolieren, enthält das Markdown Navigationslinks, Fußbereichs-Beiwerk und anderen Nicht-Inhalt. Das verschwendet Token und erzeugt strukturelle Wüsten, die die Chunk-Qualität senken. Websites mit `<article>`-Elementen erhalten die sauberste Extraktion, da `<article>` typischerweise nur den Primärinhalt umschließt, während `<main>` auch Seitenleisten, Brotkrumen oder Bereiche mit verwandten Inhalten einschließen kann. Fehlt ein `<article>`, ist `<main>` bzw. `[role="main"]` das nächstbeste Signal.

Nach abgeschlossener Inhaltsextraktion:

1. Das Markdown wird mit dem GPT-4o-Tokenizer tokenisiert (Kodierung `o200k_base`)
2. Eine Zuordnung von Token- zu Zeichen-Offsets wird aufgebaut, damit Ergebnisse am Originalinhalt angezeigt werden können
3. Drei Prüfungen werden durchgeführt:

**Umgang mit Bild-Alternativtexten:** Statt Bilder ganz zu entfernen (und wertvollen Kontext zu verlieren) oder die volle Markdown-Bildsyntax zu behalten (und ~10 Token je Bild an URLs zu verschwenden), bewahrt die Analyse den Alternativtext im leichtgewichtigen Format `[Image: beschreibender Alternativtext]`. Das erhält das semantische Signal des Alternativtexts — er stützt EEAT (belegt, dass visuelle Inhalte existieren) und liefert Barrierefreiheitskontext — und eliminiert zugleich URL-Token ohne Bedeutung für die Chunk-Analyse. Bilder mit leerem oder fehlendem Alternativtext entfallen vollständig. Der Marker `[Image:` gilt als strukturelle Grenze, sodass Bilder mit beschreibendem Alternativtext strukturelle Wüsten auf natürliche Weise unterbrechen. Diese Darstellung weicht leicht davon ab, wie LLMs eine Seite tatsächlich „sehen" (in den meisten Such-Pipelines sehen sie Bilder überhaupt nicht) — wir nehmen sie dennoch auf, weil Alternativtext ein bedeutsames Inhaltssignal ist, das beeinflusst, wie KI-Systeme Vollständigkeit und Autorität der Seite einschätzen.

**Prüfung 1: Erkennung struktureller Wüsten**

Eine „strukturelle Wüste" ist eine Folge aufeinanderfolgender Token ohne Überschrift, Listenpunkt, Absatzumbruch, Zitatmarker oder Bild-Alternativtext-Marker. Lange Wüsten bedeuten, dass das KI-System mehrere Token-Chunks ohne strukturellen Kontext verarbeiten könnte.

- Wüsten zwischen 200 und 384 Token werden als Warnung markiert (gelb)
- Wüsten über 384 Token werden als kritisch markiert (rot)
- Jede Wüste über 256 Token führt zu einem Abzug (−10 Punkte, gedeckelt bei −30)

**Prüfung 2: Ausrichtung der Fensteranfänge (nur informativ)**

Diese Prüfung ermittelt, welcher Prozentsatz der Token-Fenster an einer strukturellen Grenze (Überschrift, Listenpunkt, Absatzumbruch) oder einer Satzgrenze beginnt. Die Ausrichtungsdaten werden in der Chunk-Analyse visualisiert, **beeinflussen den Wert aber nicht**. Jede Änderung am Seiteninhalt verschiebt Token-Grenzen, und es gibt keinen Beleg dafür, dass die Fensterausrichtung mit der KI-Tauglichkeit zusammenhängt.

**Prüfung 3: Eigenständigkeit des besten Chunks**

Die Analyse bestimmt den thematisch relevantesten 200-Token-Chunk (nach Überschneidung mit Seitentitel und H1-/H2-Überschriften) und bewertet, ob er als eigenständige Zitation Sinn ergäbe:

- **Beginnt an einer Grenze** — startet der Chunk an einer Satz- oder Strukturgrenze?
- **Endet an einer Grenze** — endet der Chunk an einer Satz- oder Strukturgrenze?
- **Enthält einen vollständigen Satz** — umfasst der Chunk mindestens einen vollständigen Satz?

Erfüllt er alle drei Bedingungen, ist der Chunk **eigenständig** (30 Punkte). Zwei Bedingungen: **teilweise** (15 Punkte). Weniger: **fragmentiert** (0 Punkte).

**Zusammengesetzter Chunk-Qualitäts-Score:**

Zwei bewertete Prüfungen ergeben zusammen einen Wert von 0–100: 100 − Wüstenabzug − Abzug für fehlende Eigenständigkeit. Die Fensterausrichtung wird zur Visualisierung angezeigt, fließt aber nicht in den Wert ein. Der zusammengesetzte Wert wird anschließend im Verhältnis 20/80 mit der LLM-Bewertung der Citation Readiness verrechnet — 80 % des Citation-Readiness-Werts stammen also aus der inhaltlichen Bewertung des LLM und 20 % aus der strukturellen Chunk-Analyse.

**Visualisierung:**

In der Seiten-Detailansicht zeigt der Tab **Chunk-Analyse** eine gerenderte Vorschau Ihres Seiteninhalts mit Inline-Emoji-Markern, die anzeigen, wo Chunk-Grenzen, Wüsten und der beste Chunk liegen:

- 🏅⏵ / ⏴🏅 — Anfang und Ende des **besten Chunks**. Das ist das 200-Token-Fenster mit der größten Stichwortüberschneidung zu Titel und Überschriften Ihrer Seite — der Chunk, der bei einer Zitation Ihrer Seite am ehesten gewählt wird.
- 🟠⏵ / ⏴🟠 — Anfang und Ende einer **Wüste**. Lange Textstrecken ohne strukturelle Marker (Überschriften, Listen, Absatzumbrüche). KI-Systeme verarbeiten innerhalb einer Wüste womöglich mehrere aufeinanderfolgende Fenster ohne strukturellen Kontext.
- 🟢 — **Ausgerichtete Fenstergrenze.** Dieses Token-Fenster beginnt an oder nahe einer Satzgrenze bzw. einem Strukturelement (Überschrift, Listenpunkt, Absatzumbruch). Beginnt ein Fenster an einer sauberen Grenze, erhält das KI-System einen zusammenhängenden Textabschnitt.
- 🔴 — **Nicht ausgerichtete Fenstergrenze.** Dieses Fenster beginnt mitten im Satz. Das Verarbeitungsfenster des KI-Systems setzt mitten in einem Gedanken ein, was zu fragmentierter Extraktion oder verlorenem Kontext führen kann.

Jeder Schalter in der Werkzeugleiste steuert, welche Marker sichtbar sind. Der Schalter „Fenster" zeigt die Zahl ausgerichteter gegenüber allen Fenstern (z. B. „2/8 ausgerichtet").

**Fensterausrichtung verstehen — warum Grün zählt:**

KI-Such-Pipelines wie die von ChatGPT verarbeiten Ihre Inhalte, indem sie sie in Fenster fester Größe von etwa 128 Token zerlegen. Diese Fenster beginnen an festen Token-Offsets (Token 0, 128, 256, 384 …), unabhängig von Ihrer Inhaltsstruktur. Beginnt ein Fenster zufällig an einer Satzgrenze oder Überschrift, erhält die KI einen sauberen, zusammenhängenden Abschnitt. Beginnt es mitten im Satz, sind die ersten Token das Ende eines vorherigen Gedankens — Kontext, der verworfen oder fehlgedeutet werden kann.

Ein höherer Anteil grüner (ausgerichteter) Fenster bedeutet, dass mehr Ihrer Inhalte als zusammenhängende, in sich geschlossene Einheiten verarbeitet werden. Das verbessert unmittelbar die Qualität von KI-Zitationen und senkt die Gefahr, dass Ihre Inhalte in KI-Antworten teilweise übersprungen oder verstümmelt werden.

**Die Visualisierung der Fensterausrichtung verstehen:**

Sie können nicht direkt steuern, wo die Grenzen liegen — das bestimmt der Tokenizer. Die Visualisierung zeigt, wo die Grenzen relativ zu Ihrer Inhaltsstruktur zufällig landen. KI-Assistenten nutzen die Seitenstruktur allerdings häufig als Orientierung und richten ihre Chunks an der Struktur Ihrer Inhalte aus.

Die strukturellen Verbesserungen, die den *bewerteten* Prüfungen helfen (Wüsten und Eigenständigkeit) — mehr Überschriften, kürzere Absätze, Aufzählungen — erhöhen als Nebeneffekt auf natürliche Weise den Anteil ausgerichteter Fenster. Konzentrieren Sie sich um ihrer selbst willen auf klare Inhaltsstruktur, statt Ausrichtungsprozenten hinterherzujagen.

**Übersprungene Absichten:** Authentifizierungs- und Rechtsseiten werden nicht analysiert (wie bei der Citation Readiness). Seiten mit weniger als 256 Markdown-Token werden ebenfalls übersprungen, da sie zu wenig Inhalt für eine sinnvolle Fensteranalyse enthalten.

---

### Strukturierte Daten

Strukturierte Daten helfen KI-Systemen, eindeutig zu verstehen, worum es auf Ihrer Seite geht. Diese Dimension prüft, ob die korrekten JSON-LD-Schemata für Ihren Seitentyp vorhanden sind, ob die richtigen `@type`-Werte verwendet werden und ob zentrale Felder befüllt sind.

**So funktioniert es:**

1. Wir erkennen die Absicht der Seite (z. B. Produkt, Information, Startseite)
2. Wir schlagen nach, welche JSON-LD-Schematypen für diese Absicht erforderlich und welche optional sind
3. Wir prüfen, ob die erforderlichen Schemata vorhanden sind, ob die `@type`-Werte passen und welcher Anteil der Schlüsselfelder befüllt ist

**Beispielhafte Schema-Anforderungen:**

| Seitentyp | Erforderlich (eines davon) | Bonus |
|---|---|---|
| Startseite | Organization, WebSite | FAQPage, SiteNavigationElement |
| Produkt | Product, Offer | FAQPage, Review, AggregateRating |
| Information | Article, BlogPosting | FAQPage, HowTo, BreadcrumbList |
| Support | FAQPage, HowTo | BreadcrumbList |
| Karriere | JobPosting | Organization |

**Bewertungsstufen:**

| Bedingung | Wert |
|---|---|
| Kein JSON-LD gefunden | 0 |
| JSON-LD vorhanden, aber falsche Typen | 40 |
| Erforderliches Schema vorhanden | 75 Basis |
| + Bonus für Feldvollständigkeit | bis zu +15 |
| + Bonus-Schemata vorhanden | bis zu +10 |
| Absicht ohne Schema-Zuordnung | N/A (ausgenommen) |

**Aktualität in strukturierten Daten:** Für die Schemata Article, BlogPosting, TechArticle und NewsArticle gilt `datePublished` als Pflichtfeld — sein Fehlen senkt den Wert der Feldvollständigkeit. Ist `datePublished` vorhanden, `dateModified` jedoch nicht, erzeugt das Audit eine Empfehlung, es zu ergänzen. `dateModified` signalisiert Suchmaschinen und KI-Pipelines, dass der Inhalt aktiv gepflegt wird — besonders wichtig für Seiten, die auf aktualitätsgefilterte Anfragen zielen.

**Schema.org-Links in den Befunden:** Fehlen erforderliche oder Bonus-Schemata, nennt der Audit-Befund die für die Absicht Ihrer Seite nötigen Schematypen und verlinkt auf deren Definitionen bei [schema.org](https://schema.org). Einer Produktseite ohne `Offer`-Schema wird beispielsweise ein direkter Link auf https://schema.org/Offer angezeigt, damit Sie genau wissen, welche Eigenschaften zu implementieren sind. Befunde zur Feldvollständigkeit verlinken ebenfalls auf die passende Schema-Definition und listen die konkret fehlenden Felder auf.

**Was ein niedriger Wert bedeutet:** Ergänzen oder korrigieren Sie das JSON-LD-Markup der Seite. Prüfen Sie Ihr Markup mit Googles [Rich Results Test](https://search.google.com/test/rich-results) und stellen Sie sicher, dass Schlüsselfelder wie `name`, `description`, `image` und absichtsspezifische Eigenschaften befüllt sind.

---

### Performance für KI

KI-Crawler rendern Seiten nicht im Browser — sie rufen rohes HTML ab. Diese Dimension misst, wie schnell und effizient Ihr Server Inhalte ausliefert.

**Geprüfte Metriken:**

| Metrik | Grün | Gelb (−15) | Rot (−35) |
|---|---|---|---|
| **Time to First Byte (TTFB)** | < 800 ms | 800 ms – 2 s | > 2 s |
| **HTML-Übertragungszeit** | < 1 s | 1–2 s | > 2 s |
| **HTML-Dokumentgröße** | < 500 KB | 500 KB – 2 MB | > 2 MB (−30) |

Die Bewertung startet bei 100 und zieht je Metrik Punkte ab. Das Verhältnis von Inhalt zu Markup wird informativ erfasst, beeinflusst den Wert aber nicht.

**Was ein niedriger Wert bedeutet:** Ihre Seiten antworten langsam oder sind mit HTML überladen. Verbessern Sie die Serverantwortzeiten, reduzieren Sie unnötiges Markup und erwägen Sie Caching-Strategien für Traffic von KI-Crawlern.

---

### E-E-A-T-Signale

E-E-A-T steht für **Experience, Expertise, Authoritativeness und Trustworthiness** (Erfahrung, Fachkompetenz, Autorität und Vertrauenswürdigkeit). Zwar gibt es keinen veröffentlichten oder allgemein anerkannten Standard dafür, wie Suchmaschinen E-E-A-T genau bewerten, doch es gilt weithin als bedeutender Faktor dafür, wie Google und andere KI-Systeme Inhaltsqualität und Vertrauenswürdigkeit einschätzen.

Unsere E-E-A-T-Bewertung kombiniert mehrere Signale, die aus unserer Sicht in Googles Bewertung dieser Qualitätsdimension einfließen. Der Wert hat zwei Bestandteile:

#### Signale auf Markenebene (40 % des E-E-A-T-Werts)

Diese werden einmal pro Audit für Ihre gesamte Website geprüft:

| Signal | Punkte |
|---|---|
| Organization-Schema mit `sameAs`-Links | 18 |
| Über-uns-Seite vorhanden | 15 |
| HTTPS aktiviert | 15 |
| Kontaktseite vorhanden | 12 |
| Datenschutzerklärung vorhanden | 10 |
| Nutzungsbedingungen vorhanden | 10 |
| robots.txt vorhanden | 8 |
| HSTS-Header vorhanden | 8 |
| Content-Security-Policy-Header | 4 |
| **Maximal möglich** | **100** |

#### Signale auf Seitenebene (60 % des E-E-A-T-Werts)

Diese werden je Seite geprüft, wobei die Relevanz vom Seitentyp abhängt:

| Signal | Basisgewicht | Anwendbar auf |
|---|---|---|
| Autorenzeile vorhanden | 30 | Artikel, Forschung, technische Inhalte |
| Externe Zitationen (eindeutige Domains) | 22 | Artikel, Forschung, Informationsinhalte |
| Veröffentlichungs-/Änderungsdaten | 20 | Informations-, Forschungs-, technische und Support-Seiten |
| Bewertungen oder Referenzen | 18 | Produkt-, Preis-, Kaufseiten |
| Maschinenlesbare Aktualitätssignale | 10 | Information, Forschung, Technik, Support, Produkt, Preise |

Nur Signale, die zur Absicht der Seite passen, fließen ein. Die Gewichte irrelevanter Signale werden auf die übrigen anwendbaren Signale verteilt.

**Hinweis zu Veröffentlichungsdaten:** Daten werden nur für inhaltsorientierte Seitentypen bewertet (Information, Forschung, Technik, Support). Für andere Seitentypen wie Startseite, Produkt, Preise und Unternehmensseiten meldet das Audit informativ, ob Daten vorhanden sind, straft ihr Fehlen aber nicht ab. Ein Veröffentlichungsdatum auf einer Start- oder Produktseite ist kein aussagekräftiges Vertrauenssignal.

#### Maschinenlesbare Aktualitätssignale

Untersuchungen von [RESONEO](https://think.resoneo.com/chatgpt) (Februar 2026) haben explizite Aktualitätsfilter in der ChatGPT-Such-Pipeline dokumentiert: Anfragen werden mit Aktualitätsfenstern von 1 Tag, 7 Tagen, 14 Tagen oder 30 Tagen versehen. Diese Filter arbeiten auf dem Datumssignal, das die zugrunde liegende Suchmaschine für die Seite extrahiert hat — **bevor** das Auswahlmodell sie überhaupt sieht. Hat eine Seite kein maschinenlesbares Datum, ordnet die Suchmaschine ihr womöglich gar keines zu, womit sie für aktualitätsgefilterte Anfragen ausscheidet.

Das ist etwas anderes als die bestehende Prüfung auf „auf der Seite sichtbare Veröffentlichungsdaten" (bei der es um menschliches Vertrauen geht). Bei Aktualitätssignalen geht es um maschinenlesbare Daten, die Suchmaschinen und KI-Pipelines extrahieren und filtern können.

Das Audit prüft drei Ebenen von Datumssignalen:

**Ebene 1: JSON-LD-Datumseigenschaften (40 Punkte)**

Für Seiten mit den Schemata Article, BlogPosting, NewsArticle, TechArticle oder WebPage:

- `datePublished` ist vorhanden und ein gültiges ISO-8601-Datum
- `dateModified` ist vorhanden und ein gültiges ISO-8601-Datum
- `dateModified` ≥ `datePublished` (ein Änderungsdatum vor dem Veröffentlichungsdatum wird als Datenfehler markiert)
- Beide Daten sind plausibel (nicht in der Zukunft, nicht vor dem Jahr 2000)

Beide vorhanden und gültig: volle Punktzahl (40 Punkte). Nur `datePublished`: Teilpunktzahl (25 Punkte). Keines vorhanden: keine Punkte. Ungültige oder widersprüchliche Daten: keine Punkte mit einem konkreten Befund.

**Ebene 2: Open-Graph-Datumstags (30 Punkte)**

Geprüft werden die Meta-Tags `article:published_time` und `article:modified_time`. Ihr Vorhandensein bringt 30 Punkte. Sind sowohl OG- als auch JSON-LD-Daten vorhanden, prüft das Audit, ob sie innerhalb von 24 Stunden übereinstimmen — widersprüchliche Signale zwischen den Ebenen werden markiert.

**Ebene 3: HTTP-Header „Last-Modified" (10 Punkte)**

Sendet der Server einen `Last-Modified`-Antwortheader, gibt es 10 Punkte. Ein fehlender HTTP-`Last-Modified` wird mit geringer Schwere vermerkt — viele CDNs und Single-Page-Anwendungen senden diesen Header nicht, sein Fehlen ist also verbreitet und weniger gravierend als fehlende Schema-Daten.

**Ebenenübergreifende Konsistenz (20 Punkte)**

Die wertvollste Prüfung: Erzählen die Datumssignale aller drei Ebenen dieselbe Geschichte? Punkte werden abgezogen, wenn:

- Die Veröffentlichungsdaten aus JSON-LD und OG um mehr als 24 Stunden abweichen
- Das HTTP-`Last-Modified` mehr als 30 Tage vor dem JSON-LD-`dateModified` liegt (Hinweis darauf, dass das Schema-Datum aktualisiert wurde, ohne die Seite tatsächlich neu auszurollen)

**Anwendbarkeit:**

- **Vollständige Prüfung** (alle drei Ebenen): Informations-, Forschungs-, technische und Support-Seiten
- **Teilprüfung** (nur JSON-LD): Produkt- und Preisseiten — sie profitieren von `dateModified` als Signal aktiver Pflege, während OG-Datumstags und HTTP-`Last-Modified` weniger relevant sind
- **Übersprungen:** Startseite, Rechtsseiten, Authentifizierung und andere Nicht-Inhaltsseiten

**Was ein niedriger Wert bedeutet:** Ihrer Website oder Seite fehlen Vertrauenssignale. Beginnen Sie mit websiteweiten Verbesserungen (Über-uns-Seite, Kontaktdaten, Datenschutzerklärung, HTTPS) für die größte Wirkung und ergänzen Sie dann Signale auf Seitenebene wie Autorenangaben und Daten. Für Aktualitätssignale im Besonderen: Stellen Sie sicher, dass Ihre Artikel-Schemata sowohl `datePublished` als auch `dateModified` enthalten, und erwägen Sie die Open-Graph-Tags `article:published_time` und `article:modified_time`.

---

### Lesbarkeit

Inhalte auf einem angemessenen Leseniveau lassen sich von KI-Systemen leichter auswerten, zusammenfassen und Nutzern präsentieren. Entscheidet die KI, Ihre Inhalte in eine Antwort aufzunehmen, und sind sie nicht auf einem zum übrigen Material passenden Niveau geschrieben, schreibt das LLM sie womöglich um. Dann wäre die Mühe, die Sie in Ihre Formulierungen gesteckt haben, vergebens.

Diese Dimension bewertet drei Aspekte Ihres Schreibens. Alle drei Teilmetriken werden in den Befunden stets mit ihren tatsächlichen Werten ausgewiesen (z. B. „Flesch Reading Ease: 52,3"), unabhängig davon, ob sie im Zielbereich liegen — so können Sie die Ergebnisse nachvollziehen.

**Anwendbare Seitentypen:** ausschließlich Informations-, Forschungs-, technische und Support-Seiten. Alle anderen Seitentypen erhalten N/A.

**Teilmetriken:**

| Teilmetrik | Grün (kein Abzug) | Gelb | Rot |
|---|---|---|---|
| **Flesch Reading Ease** | 45–65 | 30–44 oder 66–80 (−20) | Unter 30 oder über 80 (−40) |
| **Flesch-Kincaid Grade Level** | Stufen 8–11 | Stufen 12–16 (−15) | Über Stufe 16 (−30) |
| **Durchschnittliche Satzlänge** | ≤ 25 Wörter | Über 25 Wörter (−15) | — |

Die Bewertung startet bei 100 und zieht je Teilmetrik Punkte ab. Der Idealbereich zielt auf ein Publikum mit Hochschulniveau — fachlich genug, um autoritativ zu wirken, und zugleich zugänglich genug für die Zusammenfassung durch KI.

**Mindestanforderung an den Inhalt:** Seiten mit weniger als 100 Zeichen lesbarem Text erhalten den Wert 0.

**Was ein niedriger Wert bedeutet:** Ihre Inhalte sind womöglich zu dicht oder zu simpel für eine wirksame KI-Zusammenfassung. Streben Sie klare, gut gegliederte Absätze mit abwechslungsreichen Satzlängen an.

---

### Barrierefreiheit

Seiten, die semantisches HTML verwenden und grundlegende Standards der Barrierefreiheit einhalten, lassen sich von KI-Systemen leichter auswerten und präziser zitieren. Wir führen gegen eine im Browser gerenderte Fassung jeder Seite eine fokussierte Auswahl von [axe-core](https://github.com/dequelabs/axe-core)-Prüfungen aus, beschränkt auf Regeln, die unmittelbar beeinflussen, wie KI-Abrufsysteme die Inhaltsstruktur deuten.

**Geprüfte Regeln (7):**

| Regel | Warum sie für KI zählt |
|---|---|
| `image-alt` | KI-Systeme sehen keine Bilder — Alternativtext ist ihr einziges Signal für visuelle Inhalte |
| `heading-order` | Die Überschriftenhierarchie (`h1` → `h2` → `h3`) bildet die Gliederung, die die KI zur Extraktion und Zusammenfassung nutzt |
| `document-title` | Das `<title>`-Element nutzen KI-Auswahlmodelle, um die Relevanz der Seite zu bestimmen |
| `html-has-lang` | Das `lang`-Attribut sagt KI-Systemen, welche Sprache sie bei der Verarbeitung erwarten dürfen |
| `landmark-one-main` | Ein `<main>`-Element hilft KI-Systemen, den Primärinhalt von Navigation und Beiwerk zu trennen |
| `list` | Korrektes Listen-Markup (`<ul>`, `<ol>`) liefert semantische Struktur, auf die sich die KI bei Aufzählungen und Schritt-für-Schritt-Inhalten stützt |
| `empty-heading` | Leere Überschriften zerreißen die Gliederung und lassen die KI Abschnittsgrenzen falsch deuten |

**Hinweis:** Verstöße gegen `heading-order` werden unabhängig von der axe-core-Einstufung stets als hohe Schwere (rot) gemeldet, weil die Überschriftenhierarchie für die Strukturauswertung durch KI entscheidend ist.

**Warum nur 7 Regeln?** Wir beschränken die Prüfung bewusst auf Regeln, die beeinflussen, wie ein KI-Abrufsystem Seiteninhalte liest und strukturiert. Das ist kein vollständiges Barrierefreiheits-Audit und sollte auch nicht als Ersatz dafür dienen. WCAG-Konformität ist ein ebenso wichtiger Teil von Webentwicklung und -pflege.

**Abzüge je Verstoß:**

| Schwere | Punkte je Vorkommen | Maximaler Abzug |
|---|---|---|
| Kritisch | −10 | −40 |
| Schwerwiegend | −5 | −30 |
| Mittel | −3 | −20 |
| Gering | −1 | −10 |

Die Bewertung startet bei 100 und zieht je einzelnem Element ab, das gegen eine Regel verstößt (nicht je Regeltyp).

**Was ein niedriger Wert bedeutet:** Beheben Sie Barrierefreiheitsverstöße, beginnend mit kritischen und schwerwiegenden. Häufige schnelle Erfolge sind Alternativtexte für Bilder, eine korrigierte Überschriftenhierarchie und ein `<main>`-Landmark-Element.

---

## Grounding-Abdeckung (informativ)

Zusätzlich zu den sieben bewerteten Dimensionen erhält jede Seite eine **Schätzung der Grounding-Abdeckung**. Das ist keine bewertete Dimension — sie erscheint in den Seitenbefunden als informativer Kontext zur Citation Readiness.

Die Grounding-Abdeckung schätzt, welcher Anteil Ihres Seiteninhalts vom Grounding-System von Googles Gemini ausgewählt würde, wenn es Ihre Seite zitiert. Grundlage sind Untersuchungen von [DEJAN AI](https://dejan.ai/blog/how-big-are-googles-grounding-chunks/), die ergaben, dass Googles Grounding-System unabhängig von der Seitenlänge typischerweise rund 540 Wörter auswählt.

**Kernerkenntnis:** Seiten unter 1.000 Wörtern erreichen etwa 61 % Abdeckung, Seiten über 3.000 Wörter nur rund 13 %. Wollen Sie den zitierten Anteil Ihrer Inhalte maximieren, gilt: **Dichte schlägt Länge.** Knappe, gut strukturierte Inhalte schneiden besser ab als detaillierte, aber lange Artikel.

Überschreitet eine Seite 2.000 Wörter, enthält das Audit einen Befund mit der Anregung, den Inhalt in kürzere, fokussiertere Seiten aufzuteilen.

---

## Ein Audit starten

### Seiten auswählen

Sie können Seiten auf zwei Wegen für ein Audit auswählen:

**Seiten wählen:** Klicken Sie auf **Seiten wählen**, um den Auswahlassistenten zu öffnen, mit dem Sie eine Liste konkreter Seiten zusammenstellen. Im Assistenten können Sie:

- **Würfeln** — eine zufällige, repräsentative Auswahl von bis zu 25 Seiten erzeugen, verteilt über Seitentypen (Startseite, Produkt, Information, Support usw.), mit mindestens einer Seite je Typ, für den klassifizierte Seiten vorliegen. Erneutes Klicken „würfelt" eine andere Auswahl.
- **Manuell suchen** — nach Seitentyp (Absicht) und/oder Pfadmuster filtern, passende Seiten finden und einzeln zur Liste hinzufügen. Sie können mehrere Suchen durchführen und Seiten über Suchen hinweg sammeln.
- **Als Gruppe speichern** — Ihre Auswahl optional als benannte Seitengruppe zur Wiederverwendung sichern.

**Aus einer gespeicherten Gruppe:** Wählen Sie eine zuvor gespeicherte Seitengruppe, um ein Audit schnell für dieselben Seiten erneut auszuführen.

### Seitengruppen speichern

Sie können jede Seitenauswahl als wiederverwendbare Gruppe speichern. Klicken Sie im Auswahlassistenten nach Prüfung Ihrer Auswahl auf **Auch als Seitengruppe speichern**, vergeben Sie einen Namen und speichern Sie. Gruppen lassen sich außerdem im Tab **Gespeicherte Gruppen** über **Gruppe erstellen** anlegen. Gespeicherte Gruppen erscheinen sowohl im Audit-Starter als auch in der Property-Seitenansicht.

### Aus einem Audit ein SEO-Projekt erstellen

Ist ein Audit abgeschlossen, können Sie seine Seiten mit einem Klick in ein SEO-Projekt überführen. Achten Sie im Kartenkopf des Audits auf das **Ordnersymbol** (<kbd>SEO-Projekt aus diesen Seiten erstellen</kbd>), neben den Schaltflächen zum Speichern und Exportieren. Ein Klick darauf:

1. Legt automatisch eine neue Seitengruppe namens **Audit – [Datum]** mit allen Seiten des Audits an
2. Führt Sie zum Formular **Neues Projekt** mit dem Projekttyp **SEO** und der neuen Seitengruppe bereits ausgewählt

Von dort müssen Sie nur noch Prompts zuweisen und dem Projekt einen Namen geben. Das ist der schnellste Weg von „Ich habe diese Seiten gerade auditiert" zu „Ich verfolge jetzt, ob eine davon zitiert wird."

> **Tipp:** Die Seitengruppe besteht unabhängig vom Projekt weiter. Sie können künftige Audits gegen dieselbe Gruppe laufen lassen, um Score-Verbesserungen über die Zeit zu verfolgen.

### E-Mail-Benachrichtigung

Größere Audits können mehrere Minuten dauern, eine Website mit über 1.000 Seiten auch eine Stunde und mehr. Klicken Sie auf das **Briefsymbol** neben einem laufenden Audit, um bei Abschluss eine E-Mail zu erhalten. Sie enthält den Gesamtscore, die Zahl der analysierten Seiten sowie die Anzahl kritischer Probleme und Warnungen.

---

## Ihre Ergebnisse lesen

### Übersichtsbereich

Der Übersichtsbereich oben in einem abgeschlossenen Audit zeigt:

- **Gesamtscore der Website** (0–100) mit kreisförmiger Fortschrittsanzeige
- **Analysierte Seiten** und **Dauer** im Untertitel
- Anzahl **kritischer Probleme** (Seiten mit weniger als 40 Punkten)
- **Aufschlüsselung der Dimensionswerte** mit Kreisanzeigen für jede der sieben Dimensionen sowie Verteilungsbalken mit den Seitenzahlen in Grün/Gelb/Rot
- **Häufige Probleme**, gruppiert nach Typ (z. B. „16 Seiten haben Probleme mit der Citation Readiness")
- **Werte nach Seitentyp** mit Durchschnittswert und Seitenzahl je Absicht

### Tabelle der Seitenergebnisse

Die Tabelle listet jede auditierte Seite mit Spalten für:

- **Seiten-URL** (überfahren für Titel und Pfad; auf das Symbol für externe Links klicken, um die Seite zu öffnen)
- **Absicht** (erkannter Seitentyp, farblich kodiert)
- **Gesamtwert**
- Einzelne Dimensionswerte (Statischer Inhalt, Performance, Strukturierte Daten, E-E-A-T, Lesbarkeit, Citation, Barrierefreiheit)

**Farben der Werte:** Grün (70–100), Gelb (40–69), Rot (0–39). „N/A" bedeutet, dass die Dimension für die Absicht der Seite nicht anwendbar ist. „ERR" bedeutet, dass eine Prüfung während der Verarbeitung fehlgeschlagen ist (siehe [Fehlgeschlagene Prüfungen](#fehlgeschlagene-prüfungen) unten).

### Filtern

Nutzen Sie die Filter über der Tabelle, um Ergebnisse einzugrenzen:

- **Absichtsfilter:** nur bestimmte Seitentypen anzeigen
- **Wertebereich:** nur kritische (0–39), Warnungs- (40–69) oder gute Seiten (70–100) anzeigen
- **Suche:** nach URL-Pfad filtern

### Seiten-Detailbereich

Klicken Sie eine Zeile an, um den Detailbereich aufzuklappen. Er zeigt:

- **Metrikraster** mit detaillierten Teilwerten und Befunden je Dimension
- **Tab „Befunde"** mit konkreten Problemen, Empfehlungen und Kontextinformationen
- **Tab „Screenshots"** mit Aufnahmen vor (statisches HTML) und nach (JavaScript-gerendert) der Verarbeitung, sodass Sie visuell vergleichen können, was KI-Crawler sehen und was Browsernutzer sehen

### CSV-Export

Klicken Sie bei einem abgeschlossenen Audit auf **CSV exportieren**, um alle Ergebnisse herunterzuladen. Die CSV enthält:

- Kopfzeilen mit Zusammenfassung (Domain, Datum, Gesamtscore, Dimensionsdurchschnitte, Konfigurationsdetails)
- Eine Zeile je Seite mit Pfad, Titel, Absicht und allen sieben Dimensionswerten

---

## Fehlgeschlagene Prüfungen

Manche Seiten haben Konfigurationen, die unsere Werkzeuge nicht vollständig verarbeiten können. Schlägt eine Prüfung fehl, zeigt die betroffene Dimension in der Ergebnistabelle **ERR**, und der Gesamtscore der Seite wird aus den erfolgreichen Dimensionen berechnet.

### Warum Prüfungen fehlschlagen

Die häufigsten Ursachen sind:

- **Restriktive Content Security Policies (CSP):** Manche Websites (namentlich Shopify-Storefronts und bestimmte Unternehmensplattformen) nutzen strenge CSP-Header, die unseren Barrierefreiheits-Scanner am Einspielen seines Analyseskripts hindern. Dann zeigt die Dimension „Barrierefreiheit" ERR, alle übrigen Dimensionen werden jedoch normal bewertet.
- **Umfangreiches JavaScript oder endloses Laden:** Seiten mit komplexem JavaScript, die nie einen stabilen „Idle"-Zustand erreichen, können unsere browserbasierten Prüfungen (Barrierefreiheit, statischer Inhaltsanteil, Screenshots) in eine Zeitüberschreitung laufen lassen. Die auf statischem Abruf beruhenden Dimensionen (Performance, Strukturierte Daten, EEAT, Lesbarkeit, Citation Readiness) sind davon nicht betroffen.
- **Nicht-HTML-Inhaltstypen:** Seiten, die RSS-Feeds, XML-Sitemaps, JSON oder andere Nicht-HTML-/Nicht-Markdown-Inhaltstypen zurückgeben, werden sofort als ERR markiert, da sie keine auditierbaren Webseiten sind.
- **Rate-Limiting oder Bot-Blockade:** Manche Server blockieren oder drosseln automatisierte Anfragen. Kann eine Seite gar nicht abgerufen werden, zeigen alle Dimensionen ERR.

### Wie fehlgeschlagene Prüfungen abgerechnet werden

Berechnet werden nur Seiten, die erfolgreich abgeschlossen wurden. Weist eine Seite Fehler in einzelnen Dimensionen auf, wird sie dennoch berechnet, sofern sie einen Gesamtwert erhalten hat. Seiten, die vollständig fehlschlagen (z. B. Nicht-HTML-Inhaltstyp, Abruffehler), werden **nicht** berechnet.

Schlagen alle Seiten eines Audits fehl, werden keine Credits abgebucht.

### Hilft ein erneuter Lauf?

In den meisten Fällen **nein**. Ist das Audit an der Konfiguration der Website gescheitert (CSP-Richtlinie, Bot-Blockade, umfangreiches JavaScript), werden dieselben Seiten bei weiteren Läufen sehr wahrscheinlich erneut fehlschlagen. Die Ursache liegt auf Seiten der Website, nicht bei uns.

Zur Behebung müsste die Website-Betreiberin die Ursache angehen — etwa CSP-Regeln für bekannte Audit-Tools lockern, das Laden von JavaScript optimieren oder sicherstellen, dass Seiten korrekte HTML-Inhaltstypen zurückgeben.

Halten Sie den Fehler für sporadisch (etwa durch vorübergehendes Rate-Limiting), können Sie das Audit erneut ausführen — wir empfehlen jedoch, mindestens eine Stunde zu warten.

---

## Preise und Verbrauch

### Agency-Pläne (Core und Pro)

Agency-Pläne enthalten ein monatliches Kontingent auditierbarer Seiten:

- **Agency Core:** 2.500 Seiten pro Monat
- **Agency Pro:** 10.000 Seiten pro Monat

Jedes Audit zieht von Ihrem monatlichen Seitenkontingent ab. Ein Audit über 300 Seiten im Plan Agency Core lässt Ihnen also 2.200 Seiten für den Monat.

Müssen Sie mehr Seiten auditieren, als Ihr Monatskontingent hergibt, verwendet das Audit für die Überschreitung Credits zum Standardsatz (siehe unten).

### Pay-As-You-Go-Pläne

Pay-as-you-go-Kunden zahlen in Credits:

- **1 Credit je 50 Seiten** (oder Teile davon)
- **Mindestens 1 Credit je Audit**, unabhängig von der Seitenzahl

Beispiele:
- Ein Audit über 35 Seiten kostet 1 Credit
- Ein Audit über 89 Seiten kostet 2 Credits
- Ein Audit über 423 Seiten kostet 9 Credits

Credits werden vor dem Start des Audits geprüft und nach Abschluss auf Basis der tatsächlich analysierten Seitenzahl abgebucht. Schlägt ein Audit fehl, entstehen keine Kosten.

---

## Best Practices

### Mit einem repräsentativen Audit beginnen

Führen Sie Ihr erstes Audit über alle Seitentypen hinweg aus, um eine Ausgangsbasis zu erhalten. Spyglasses bietet eine Funktion, die automatisch bis zu 25 Seiten über die Website hinweg auswählt, gewichtet zugunsten häufig zitierter Seitentypen. Dieses Audit legt websiteweite Muster offen und hilft Ihnen beim Priorisieren.

### Zuerst auf hoch gewichtete Dimensionen konzentrieren

Statischer Inhalt (22 %), Citation Readiness (20 %) und Strukturierte Daten (18 %) machen zusammen 60 % des Gesamtwerts aus. Verbesserungen in diesen Dimensionen wirken am stärksten.

### Seitentyp-Filter für gezielte Nacharbeit nutzen

Filtern Sie nach Ihrem Basis-Audit nach Seitentyp, um Verbesserungen zu fokussieren. Auditieren Sie etwa nur Ihre Blog-Inhalte, um Lesbarkeit und Citation Readiness über die Zeit zu verfolgen.

### Websiteweite Probleme zuerst angehen

E-E-A-T-Signale auf Markenebene (Über-uns-Seite, Kontaktdaten, Datenschutzerklärung) betreffen jede Seite Ihrer Website. Sie sind oft die wirkungsvollsten Verbesserungen.

### Seitengruppen für wiederkehrende Audits speichern

Auditieren Sie regelmäßig bestimmte Bereiche Ihrer Website, speichern Sie diese als Seitengruppen. Das erleichtert es, dasselbe Audit erneut auszuführen und Fortschritte zu verfolgen.

### Werte über die Zeit beobachten

Führen Sie regelmäßig Audits aus, um zu verfolgen, ob sich Ihre Optimierungen in besseren Werten niederschlagen. Vergleichen Sie Gesamtwerte und Dimensionsaufschlüsselungen zwischen den Audit-Läufen.

## Audits mit einem KI-Assistenten erkunden (MCP)

Verbinden Sie den [Spyglasses MCP-Server](/docs/mcp), und ein Assistent kann ein Audit im Gespräch aufschlüsseln. `get_site_audit_summary` liefert Gesamt- und Dimensionswerte, `list_site_audit_pages` (aufsteigend nach Wert sortiert) fördert die schwächsten Seiten zutage, und `get_site_audit_page` liefert die vollständigen Details je Seite. Der [Prompt](/docs/mcp/prompts) **Find my weakest pages** erledigt das automatisch.

Die vollständige Referenz finden Sie unter [MCP → Report-Tools](/docs/mcp/reports#site-readiness-audit).

## Verwandte Themen

- [MCP-Server](/docs/mcp) — Audit-Seiten aus einem KI-Assistenten heraus aufschlüsseln
- [Property-Seiten](/docs/dashboards/property-pages) — Die für Ihre Property erfassten Seiten ansehen und verwalten
- [AI Visibility Reports](/docs/dashboards/ai-visibility-reports) — AI Visibility Reports ausführen und sehen, wie KI-Systeme Ihre Marke empfehlen
- [Citation Intelligence](/docs/dashboards/citation-intelligence) — Verfolgen, wie oft KI-Systeme Ihre Inhalte zitieren
- [Projekte](/docs/dashboards/projects) — SEO-Projekte aus Audit-Ergebnissen erstellen, um die Zitationswirkung über die Zeit zu verfolgen