Auf dieser Seite
Christopher Helm
Christopher Helm Geschäftsführer & CTO

1. Gegenstand und Vorgehen

Diese GEO vs. SEO Analyse untersucht das Verhalten der Such- und Abruf-Tools, die Claude in der claude.ai-Oberfläche zur Verfügung stehen. Die Analyse wurde als fortlaufendes Gespräch durchgeführt, in dem einzelne Hypothesen aufgestellt, durch gezielte Suchanfragen getestet und anhand der zurückgegebenen Rohdaten verifiziert oder verworfen wurden.

Untersuchte Testdomains: wise-relations.com, wire.wise-relations.com, christopher-helm.com, seo-nest.de, blog2social.com, planinja.de sowie diverse weitere Domains aus organischen Suchergebnissen.

Gesamtzahl untersuchter Dokumente: ca. 170 (über alle Suchanfragen im Gesprächsverlauf).

2. Tool-Architektur

2.1 Verfügbare Tools

Claude verfügt über zwei getrennte Tools für den Webzugriff:

Merkmal web_search web_fetch
Funktion Suchindex abfragen Einzelne URL abrufen
Parameter nur query (String) url, html_extraction_method, text_content_token_limit, allowed_domains, blocked_domains, web_fetch_pdf_extract_text, u.a.
Steuerbarkeit Keine Filter (Sprache, Region, Anzahl) Token-Limit, Domain-Filter, Extraktionsmethode
Rückgabe Snippets (Textfragmente) Volltext der Seite
Typische Länge ~500 Wörter 2.000–8.000+ Wörter

2.2 Aufruf-Mechanik

Der Aufruf erfolgt über ein XML-ähnliches Format:

<invoke name="web_search">
  <parameter name="query">Suchbegriff</parameter>
</invoke>

Das Tool-Schema definiert additionalProperties: false — es können keine weiteren Parameter eingefügt werden. Alles, was die Suche beeinflussen soll (Sprache, Domain-Einschränkung, Zeitraum), muss im Query-String selbst codiert werden (z.B. site:, Jahreszahlen, Sprachwahl durch Begriffe).

2.3 Rückgabe-Struktur

Beide Tools liefern dieselbe XML-Struktur zurück:

<document index="[Nummer]">
  <source>[Seitentitel]</source>
  <document_content>
    <span index="[Nummer]-1">[Text]</span>
  </document_content>
  <metadata key="search_provider">anthropic</metadata>
  <metadata key="url">[URL]</metadata>
  <metadata key="age">[Datum/Alter]</metadata>           <!-- nur web_search -->
  <metadata key="content_type">[Typ]</metadata>           <!-- nur web_fetch -->
  <metadata key="mime_type">[MIME]</metadata>              <!-- nur web_fetch -->
  <metadata key="destination_url">[finale URL]</metadata>  <!-- nur web_fetch -->
</document>

Annahme: Der Span-Index erlaubt theoretisch mehrere Spans pro Dokument (X-1, X-2, X-3). Test: Über ca. 170 Dokumente (web_search + web_fetch) geprüft. Ergebnis: Kein einziges Dokument hatte mehr als einen Span. Die Notation X-2, X-3 etc. wird nie genutzt. Jedes Dokument hat exakt einen Span mit Index X-1.

3. Zitier-Mechanismus

3.1 Notation

Claude kann Textstellen mit paraphrasierter Text annotieren. Laut Anweisungen:

  • X-Y = Dokument X, Satz Y
  • X-Y:Z = Dokument X, Sätze Y bis Z
  • Kommasepariert für mehrere Bereiche

3.2 Praktische Funktion

Annahme: Die Satz-Indizes verweisen auf spezifische Sätze innerhalb des Spans. Test: Verschiedene Indizes (X-1, X-3, X-5, X-10) auf dasselbe Dokument angewendet. Ergebnis: Nicht verifizierbar — ob das Frontend unterschiedliche Sätze hervorhebt, konnte im Test nicht bestätigt werden. Der Span enthält keine Sub-Markierungen. Die Satz-Zählung ist eine Claude-interne Konstruktion ohne maschinelle Grundlage im Quellformat.

Fazit: Die Zitier-Notation dient primär als Rückverfolgbarkeits-Mechanismus für Claude selbst. Im Frontend verweist alles auf dasselbe Quelldokument, unabhängig vom Satz-Index.

4.1 Keyword-Matching: Exakt, nicht semantisch

Annahme: Snippets werden semantisch oder per Keyword-Match generiert. Test: Drei Suchen mit reinen Synonymen, die auf keiner Seite wörtlich vorkommen.

Query Keywords auf der Seite? Ergebnisse
site:wise-relations.com Neukäufer gewinnen ohne Werbeanzeigen Nein (nur Synonyme: "Neukunden", "organisch", "ohne bezahlte Werbung") 0
site:wise-relations.com Auftraggeber akquirieren ohne Anzeigenschaltung Nein 0
site:wise-relations.com Geschäftskunden anziehen unbezahlt Nein 0

Ergebnis: Null Ergebnisse bei semantisch passenden, aber lexikalisch verschiedenen Queries. Die Suche arbeitet keyword-basiert, nicht semantisch.

Ergänzender Test: Bei partiellen Keyword-Matches (2 von 4 Keywords treffen) werden Ergebnisse geliefert. Es müssen nicht alle Keywords matchen, aber mindestens einige.

4.2 Fragment-Auswahl: Query-abhängig

Annahme: Snippets sind statisch pro URL. Test: Dieselbe URL (/content-strategie/content-recycling/) mit 6 verschiedenen Queries gesucht.

Ergebnis: Jede Query erzeugt unterschiedliche Snippets. Die Textfragmente werden dynamisch basierend auf der Suchanfrage zusammengestellt. Der Suchindex hat den vollen Seitentext gespeichert und wählt die relevantesten Passagen pro Query aus.

4.3 Fragment-Anatomie

Analyse über 20 Snippets (10 Seiten × 2+ Queries):

Merkmal Wert
Fragment-Anzahl pro Snippet 1–6, typischerweise 5, abhängig von Seitenlänge und Query
Gesamtlänge (Token-Budget) ~500–600 Wörter (annähernd konstant)
Fragment-Länge 30–120 Wörter, Durchschnitt ~94
Duplikate pro Snippet 0–1 (8% aller Fragmente)
Überlappung zwischen Fragmenten ~20% der Fragmentpaare

4.4 Wie beginnen Fragmente?

Start-Typ Anteil Beispiel
Satzanfang 70% "Content Recycling hat sich 2026 als..."
Mitten im Satz 10% "Shopify wandelt How-to-Artikel..."
Duplikat 8% Identisch mit anderem Fragment
Breadcrumb/Navigation 4% "Sie sind hier: SEO Agentur » Blog"
Imperativ-Satz 4% "Teile Deine Beiträge auf Twitter..."
Meta-Description 2% Kürzestes Fragment (~30w)
Heading/Label 2% "Ausgangsmaterial: 60-min Webinar"

4.5 Keyword im Fragment-Anfang

  • 56% der Fragmente haben ein Query-Keyword in den ersten ~5 Wörtern
  • 44% haben kein Keyword am Anfang
  • Das Keyword steht aber fast immer innerhalb der ersten 1–2 Sätze des Fragments

4.6 Abschluss-Schnitt

  • 50% enden am Satzende (nach Punkt)
  • 30% brechen mitten im Satz ab (Token-Limit erreicht)
  • 15% enden am Ende eines HTML-Elements
  • 5% enden bei "..." (Original-Ellipse)

Fazit: Der Algorithmus versucht an Satzgrenzen zu schneiden, bricht aber bei ~120 Wörtern ab — unabhängig davon, ob ein Satz beendet ist.

5. Snippet-Positionierung im Gesamtartikel

5.1 Methodik

Für 4 Seiten wurde der Volltext per web_fetch geholt und die Snippet-Fragmente per Textsuche im Originalartikel lokalisiert. Die Position wurde als Prozentwert des Gesamtartikels ausgedrückt (0% = Artikelanfang, 100% = Artikelende).

5.2 Ergebnis: 1 Keyword vs. 3 Keywords (gleiche Seite)

Metrik 1 KW ("Recycling") 3 KW ("Recycling Blog Strategie")
Frühester Start 24% 26%
Spätestes Ende 56% 100%
Zusammenhängend? Ja (1 Block: 24–56%) Nein (3 Cluster: 26–42%, 74–80%, 96–100%)
Artikelanfang (0–20%) Nicht abgedeckt Nicht abgedeckt

Kernerkenntnis: Mehr Keywords in der Query erzeugen eine größere Streuung der Fragmente über den Artikel. Jedes zusätzliche Keyword "zieht" ein Fragment von einer anderen Stelle.

5.3 Vergleich über 4 Seiten (Query: "Content Recycling Blog Strategie SEO B2B")

Metrik wise-rel. (Pos 2) seo-nest (Pos 4) blog2soc (Pos 5) planinja (Pos 6)
Artikellänge ~3200w ~2800w ~2500w ~2100w
Frühester Start 24% 2% 8% 5%
Spätestes Ende 100% 82% 92% 95%
Cluster-Anzahl 3 4 4 4
Duplikate 0 1 1 1

Erkenntnis: Kein Zusammenhang zwischen Snippet-Abdeckung und Ranking-Position. Die breiteste Streuung (planinja, 90%) rankt am tiefsten. Snippets werden post-hoc generiert, sie sind kein Ranking-Signal.

5.4 Stabilitäts-Hierarchie (gleiche Seite, 6 verschiedene Queries)

Tier Seitenbereich Erscheint in X/6 Queries
Anker Intro-Absatz (24–28%) — höchste KW-Dichte 6/6
Kern Abgrenzung/Definition (32–40%) 4/6
Kern Brian-Dean-Zitat 4/6
Semi-stabil 3-1-10-Methode 3/6
Variabel Fazit (96–100%) 2/6
Variabel KI-Tools / Case Studies 2/6
Nie Guided Questions (0–20%) 0/6
Nie Fehler-Abschnitt (92–94%) 0/6

Fazit: Jeder Artikel hat ein stabiles "Anker-Fragment" (der Absatz mit der höchsten Keyword-Dichte), ergänzt durch query-abhängige variable Fragmente.

6. Keyword-Proximity-Effekt

Annahme: Die Nähe von Query-Keywords zueinander im Artikeltext beeinflusst die Fragment-Auswahl. Test: Vergleich des Intro-Absatzes (3 Keywords in 1 Satz) mit den Guided Questions (1 Keyword pro Satz).

Seitenbereich Keywords pro Satz Im Snippet?
Intro: "Content Recycling hat sich 2026 als Standardverfahren in B2B-Marketing-Abteilungen etabliert" 3 (Content, Recycling, B2B) Immer (6/6)
Guided Questions: "Wir haben viel alten Content, aber keinen systematischen Weg" 1 (Content) Nie (0/6)

Ergebnis: Keywords, die im Text nahe beieinander stehen, erzeugen "Hotspots", die bevorzugt als Fragment ausgewählt werden. Konsistent mit BM25/Proximity-Scoring.

7. Ranking-Faktoren

7.1 Keyword-Match als Grundvoraussetzung

Test: site:wise-relations.com mit steigender Keyword-Anzahl.

Position Seite Keyword-Treffer
1 /content-recycling/ 5/5
2 /blog-erstellen-lassen/ 4/5
3 /blog-management/ 3/5

Perfekte Abstufung bei Einschränkung auf eine Domain. Bei domainübergreifender Suche erklärt die Keyword-Anzahl allein das Ranking nicht.

7.2 Domainübergreifende Suche

Test: "Content Recycling Blog Strategie SEO B2B" (ohne site:), 10 Ergebnisse.

Pos Domain KW-Match Artikellänge
1 siegemedia.com 6/6 k.A. (403)
2 wise-relations.com 6/6 ~3200w
4 seo-nest.de 6/6 ~2800w
5 blog2social.com 5/6 ~2500w
6 planinja.de 4/6 ~2100w
8 ricketyroo.com 6/6 k.A.

Mehrere Seiten mit 6/6 Keyword-Match ranken unterschiedlich. Weitere Faktoren fließen ein.

7.3 BM25-Vergleich

Für 2 Seiten wurde ein BM25-Score berechnet:

Metrik wise-relations (Pos 2) seo-nest (Pos 4)
Gesamt-Keyword-Dichte 11.97% 11.74%
BM25-Score 2.14 2.04
Keywords im Title 2/6 4/6

BM25 erklärt die Reihenfolge besser als Title-Match (seo-nest hat 4/6 im Titel, rankt aber tiefer). Der Unterschied ist aber minimal — externe Signale (Domain Authority, Backlinks) spielen vermutlich die größere Rolle.

7.4 Artikellänge

Perfekte Korrelation zwischen Artikellänge und Ranking:

Position Wörter
2 ~3200
4 ~2800
5 ~2500
6 ~2100

Korrelation, nicht Kausalität — längere Artikel haben typischerweise auch mehr Backlinks, mehr interne Links und breitere semantische Abdeckung.

7.5 Messbare vs. nicht messbare Faktoren

Messbar (über web_fetch) Nicht messbar
Keyword-Dichte und -Verteilung Domain Authority / Backlink-Profil
BM25-Score Nutzersignale (CTR, Verweildauer)
Keyword-Proximity Core Web Vitals
Title-Tag-Match Schema.org Markup (indirekt)
Artikellänge Freshness-Signal
Interne Verlinkung (Anzahl Links) Crawl-Frequenz
URL-Keyword-Match JavaScript-Rendering

8. Vergleich web_search vs. web_fetch

8.1 Dieselbe URL, zwei Perspektiven

Aspekt web_search Snippet web_fetch Volltext
Textmenge ~500 Wörter 2.000–8.000+ Wörter
Struktur Fragmentiert, zusammengeklebt Seitenreihenfolge, Markdown
Überschriften In Fließtext eingebettet Als # , ## erhalten
Links Nicht sichtbar Als [text](url) erhalten
Listen Zu "·"-Text komprimiert Als * erhalten
Navigation Manchmal im Snippet Immer enthalten
Query-Abhängigkeit Ja (verschiedene Fragmente) Nein (immer gleicher Volltext)
Reihenfolge Nach Keyword-Relevanz Nach Seitenposition

8.2 Metadaten-Vergleich

Feld web_search web_fetch
source (Titel) Ja Ja
url Ja Nein
destination_url Nein Ja
age Ja (nicht immer) Nein
search_provider "anthropic" Nein
content_type Nein Ja
mime_type Nein Ja

8.3 Token-Limit bei web_fetch

  • Kein dokumentiertes Default-Limit
  • Ohne text_content_token_limit: Volltext wird geliefert
  • Mit Limit (z.B. 200 Tokens): Wird von oben abgeschnitten — Navigation und Header dominieren, Content fehlt
  • Empfehlung: Mindestens 5.000–8.000 Tokens für vollständige Artikelseiten

9. Snippet-Optimierung: Handlungsempfehlungen

9.1 Anker-Absatz gezielt platzieren

Den ersten inhaltlichen Absatz (nach Teaser/Intro) mit allen Ziel-Keywords bestücken, nah beieinander. Dieser Absatz wird zum stabilen Kern-Fragment, das bei jeder Query im Snippet erscheint.

Spezifikation: 80–100 Wörter, 3+ verschiedene Keywords, klare Nutzenaussage.

Prompt zur Replikation:

Suche: site:[domain] [Haupt-Keyword]
Prüfe: Beginnt das Snippet mit dem Intro-Absatz?
Vergleiche: Verschiedene Queries auf dieselbe URL
Erwartung: Der Anker-Absatz erscheint bei jeder Query

9.2 Keyword-Hotspots verteilen

Nicht alle Keywords in einen Absatz packen (erzeugt Duplikate). Stattdessen 3–4 Hotspots über den Artikel verteilen, jeder mit 2–3 Keywords nahe beieinander. So werden verschiedene Queries mit verschiedenen Fragmenten bedient.

Prompt zur Replikation:

Suche 1: site:[domain] Keyword-A
Suche 2: site:[domain] Keyword-B
Suche 3: site:[domain] Keyword-A Keyword-B
Vergleiche: Welche Fragmente ändern sich, welche bleiben stabil?

9.3 Artikelanfang nicht keyword-leer lassen

Die ersten 20% des Artikels werden nie als Snippet genutzt, wenn sie keine Keywords enthalten. Bei der getesteten Seite waren das Guided Questions und ein Teaser — viel Text, aber ohne Keyword-Dichte.

Empfehlung: Mindestens ein Keyword in den allerersten Absatz. Teaser und Guided-Question-Formate sollten Keywords enthalten, nicht nur generische Fragen.

9.4 Meta-Description mit Keywords

Die Meta-Description taucht manchmal als eigenes kurzes Fragment (~30 Wörter) im Snippet auf. Sie sollte die wichtigsten 2–3 Keywords enthalten.

9.5 Sätze kurz halten

Der Algorithmus schneidet bei ~120 Wörtern ab, unabhängig vom Satzende. Kürzere Sätze (15–20 Wörter) erzeugen sauberere Snippet-Grenzen. Lange Sätze werden mitten drin abgeschnitten.

9.6 Navigation keyword-arm halten

Breadcrumbs und Menü-Elemente landen manchmal im Snippet und "verschwenden" einen Fragment-Slot. Keywords in der Navigation sollten minimiert werden.

9.7 Artikellänge als indirekter Ranking-Faktor

In allen Tests korrelierte die Artikellänge mit der Ranking-Position. Längere Artikel (3.000+ Wörter) rankten höher als kürzere. Ob direkt kausal oder über Korrelation mit Backlinks/Autorität, konnte nicht isoliert werden.

10. Ranking-Optimierung für spezifische Queries

10.1 Title-Match

Test: Query mit exaktem Seitentitel vs. generische Queries.

Query Position
"Content Recycling Inhalte strategisch nutzen" (exakter Title) 1
"Content Recycling Blog Strategie SEO B2B" (6 Keywords) 2
"Content Recycling B2B" (generisch) 9
"Content Recycling Strategie" (sehr generisch) Nicht in Top 10

Empfehlung: Der Title-Tag sollte Long-Tail-Keywords enthalten, für die die Seite realistisch ranken kann. Bei generischen Head-Terms dominiert Domain Authority über On-Page-Faktoren.

10.2 Gleichmäßige Keyword-Verteilung vs. Keyword-Stuffing

seo-nest.de hatte extreme SEO-Keyword-Konzentration (43 pro 1000 Wörter), wise-relations.com eine gleichmäßigere Verteilung. wise-relations rankte höher.

Hypothese: Gleichmäßige Verteilung über alle Query-Terms wird besser bewertet als hohe Konzentration auf ein einzelnes Keyword.

11. Schema.org / JSON-LD: Nicht indexiert

11.1 Testaufbau

Auf der Seite /content-strategie/content-recycling/ enthält das Schema.org JSON-LD die Phrase "Workflows für systematische Verwertung" (in description). Dieselbe Phrase steht auch in der HTML-Meta-Description. Per curl + Python wurde verifiziert, dass diese Phrase NICHT im sichtbaren Body-Text der Seite vorkommt.

11.2 Tests

Query Ergebnis Enthält /content-recycling/?
site:wise-relations.com "systematische Verwertung" 0 Ergebnisse Nein
site:wise-relations.com systematische Verwertung Andere Seiten mit "systematisch" im Body Nein
site:wise-relations.com Workflows systematische Verwertung Seiten mit "Workflows" im Body Nein

11.3 Ergebnis

Schema.org JSON-LD wird NICHT für Keyword-Retrieval indexiert. Meta-Descriptions werden ebenfalls NICHT für Keyword-Matching genutzt, obwohl sie manchmal als kurzes Fragment (~30 Wörter) im Snippet erscheinen. Die Meta-Description wird vermutlich separat gespeichert und nur für die Snippet-Generierung verwendet.

11.4 Implikation

Keywords müssen im sichtbaren Body-Text stehen. Schema-Markup und Meta-Descriptions allein verbessern die Auffindbarkeit in Claudes Suchindex nicht. Structured Data (FAQ, HowTo, Recipe) bringt keinen Retrieval-Vorteil, wenn der Text nicht auch sichtbar auf der Seite steht.

12. Bilder-Alt-Texte: Nicht indexiert

12.1 Testaufbau

Auf der Seite blog.hubspot.de/marketing/content-recycling enthält ein Bild den Alt-Text: "Mitarbeiterinnen im Büro reichen sich Blatt Papier zwecks Content Recycling". Per curl + Python wurde verifiziert, dass die Wörter "zwecks", "Blatt Papier", "reichen sich" und "Mitarbeiterinnen im Büro" NICHT im sichtbaren Body-Text vorkommen — sie existieren ausschließlich im alt-Attribut des <img>-Tags.

12.2 Tests

Query Ergebnis Enthält /marketing/content-recycling/?
site:blog.hubspot.de zwecks Blatt Papier reichen Mitarbeiterinnen Andere Seiten mit diesen Wörtern im Body Nein
site:blog.hubspot.de zwecks Content Recycling Blatt Papier reichen /marketing/content-recycling/ erscheint Ja — aber wegen "Content Recycling" im Body

Gegenprobe: Die Seiten, die bei der ersten Query erschienen (Kundenorientierung, Corporate Blog, Serviceorientierung), enthalten die Query-Wörter im sichtbaren Body-Text, nicht in Alt-Attributen.

12.3 Ergebnis

Bilder-Alt-Texte werden NICHT für Keyword-Retrieval indexiert. Text, der ausschließlich in alt-Attributen steht, führt nicht zu Suchergebnissen.

12.4 Gesamtbild: Was wird indexiert?

Quelle Indexiert für Keyword-Matching?
Sichtbarer Body-Text (<p>, <h1>–<h6>, <li>, etc.) JA
Navigation / Breadcrumbs JA (leider, kann Fragment-Slots verschwenden)
Meta-Description NEIN (wird nur für Snippet-Generierung genutzt)
Schema.org / JSON-LD NEIN
Bilder-Alt-Texte NEIN
Anchor-Texte interner Links (auf Zielseite) NEIN (nur auf Quellseite indexiert)
<title>-Tag Erscheint im <source>-Feld, nicht im Snippet-Matching

Der Suchindex basiert ausschließlich auf sichtbarem Textinhalt der Seite. Alle nicht-sichtbaren Metadaten (Schema, Alt-Texte, Meta-Description) werden nicht für das Keyword-Retrieval herangezogen.

13.1 Testaufbau

Auf der Seite /content-strategie/content-recycling/ existieren Inline-Links mit beschreibenden Anchor-Texten, die auf andere Unterseiten verweisen. Es wurden drei Fälle identifiziert, bei denen der Anchor-Text NICHT auf der Zielseite vorkommt:

Anchor-Text Zielseite Im Body der Zielseite?
"systematische Content-Ideenfindung" /content-strategie/content-ideen/ NEIN
"automatisch generierte Featured Images" /content-strategie/wordpress-featured-images/ NEIN
"Daten zu unterschiedlichen Kanälen und Plattformen" /content-strategie/online-publizieren/ NEIN

13.2 Tests

Query Zielseite gefunden? Quellseite gefunden?
site:wise-relations.com systematische Content-Ideenfindung Nein — /content-ideen/ nicht in Ergebnissen Ja — /content-recycling/ auf Pos 1
site:wise-relations.com automatisch generierte Featured Images Nein — /wordpress-featured-images/ nicht in Ergebnissen Nein — aber /wordpress-plug-in.../ (hat Wörter im Body)

13.3 Ergebnis

Anchor-Texte von internen Links werden NICHT auf die Zielseite übertragen. Der Anchor-Text wird ausschließlich als Body-Text der Quellseite indexiert. Wenn nach "systematische Content-Ideenfindung" gesucht wird, erscheint die Seite, auf der dieser Text steht (/content-recycling/), nicht die Seite, auf die er verlinkt (/content-ideen/).

13.4 Einschränkungen

Dieser Test deckt nur interne Link-Anchor-Texte ab. Ob externe Backlink-Anchor-Texte ein Ranking-Signal darstellen, konnte nicht isoliert getestet werden — dafür wäre eine kontrollierte Umgebung mit bekannten externen Backlinks nötig. Die Beweislage deutet aber darauf hin, dass der Index grundsätzlich nur den Text indexiert, der auf einer Seite selbst steht.

13.5 Implikation

Für die Snippet-Generierung und das Keyword-Matching zählt nur der Body-Text der jeweiligen Seite selbst. Interne Verlinkung mit beschreibenden Anchor-Texten hilft der verlinkenden Seite (mehr Keywords im Body), aber nicht der verlinkten Seite.

14. Fragment-Maximum: Hartes Limit bei 6

14.1 Testaufbau

Um zu prüfen, ob die Fragment-Anzahl über 6 steigen kann, wurde eine Query mit 16 Keywords getestet ("Suchmaschinenoptimierung Leitfaden Anfänger Einführung Guide Grundlagen Tipps Strategie Ranking Keywords Backlinks Content Meta Tags Crawling Indexierung") und mit den früheren Tests (1, 3, 6, 10 Keywords) verglichen. Insgesamt 26 Snippets über alle Tests.

14.2 Ergebnis

Keywords in Query Snippets Min Fragmente Max Fragmente Durchschnitt
1 3 1 5 2.3
2–3 2 2 5 3.5
6 1 5 5 5.0
10 10 4 6 5.3
16 10 2 6 4.8

Über alle 26 Snippets: Kein einziges hatte mehr als 6 Fragmente. Auch nicht bei 16 Keywords auf Seiten mit >5.000 Wörtern.

14.3 Überraschung: Mehr Keywords ≠ mehr Fragmente

Die 16-Keyword-Query liefert sogar tendenziell weniger Fragmente (8/10 mit 5 Blöcken) als die 10-Keyword-Query (4/10 mit 6 Blöcken). Mehr Keywords führen nicht zu mehr Fragmenten, sondern zu anderen (relevanteren) Fragmenten.

14.4 Fragment-Budget-Modell

Das eigentliche Limit ist das Token-Budget von ~500–600 Wörtern pro Snippet. Bei ~100 Wörtern pro Fragment ergibt sich ein Maximum von 6. Die Formel:

Fragment-Anzahl = min(6, verfügbarer_Content / ~100_Wörter)
Snippet-Gesamtlänge ≈ 500–600 Wörter (konstant)

Verteilung nach Seitenlänge: unter 500 Wörter ergeben 1–2 Fragmente, 500–1.500 Wörter ergeben 3–4, 1.500–3.000 Wörter ergeben 4–5, über 3.000 Wörter ergeben 5–6.

15. Offene Fragen

Folgende Aspekte konnten mit den verfügbaren Tools nicht getestet werden:

  1. ~~Nutzt der Index Schema.org/JSON-LD-Daten?~~ → Nein. Siehe Kapitel 11.
  2. ~~Werden Bilder-Alt-Texte indexiert?~~ → Nein. Siehe Kapitel 12.
  3. Gibt es ein Freshness-Signal, das das Ranking beeinflusst?
  4. Wie oft wird der Suchindex aktualisiert?
  5. ~~Werden Anchor-Texte von (internen) Links auf die Zielseite übertragen?~~ → Nein. Siehe Kapitel 13.
  6. Wird JavaScript gerendert oder nur statisches HTML indexiert?
  7. ~~Gibt es ein Maximum für die Fragment-Anzahl über 6?~~ → Nein, 6 ist das harte Maximum. Siehe Kapitel 14.
  8. Wie verhält sich die Suche bei nicht-lateinischen Schriften?
  9. Gibt es eine Penalty für Duplicate Content zwischen Seiten?
  10. Beeinflusst der Nutzer-Standort (hier: Wetzlar, Hessen) die Ergebnisse?

16. Methodik-Hinweise

Alle Ergebnisse basieren auf Black-Box-Tests innerhalb eines einzelnen Chat-Verlaufs. Die Dokument-Nummerierung (1–170) läuft über das gesamte Gespräch und resettet nicht. Die Fragment-Zählung innerhalb der Snippets basiert auf visueller Inspektion der Absatzumbrüche — eine automatisierte Tokenisierung war nicht möglich.

BM25-Scores wurden auf Basis der extrahierten Snippets berechnet, nicht auf dem Volltext. Die tatsächlichen Ranking-Algorithmen von Anthropics Suchinfrastruktur sind nicht einsehbar. Alle Schlussfolgerungen sind Hypothesen auf Basis beobachtbarer Muster.

Erstellt im Rahmen einer explorativen Analyse des Claude.ai Web-Search-Tools, März 2026.