Seit zwanzig Jahren bedeutete das Extrahieren von Daten aus Webseiten, Selektoren zu schreiben: das Element finden, den Text holen, es reparieren, wenn sich die Seite ändert. Large Language Models bieten ein anderes Angebot. Man gibt dem Modell die Seite, beschreibt die gewünschten Felder und erhält strukturierte Daten zurück, ohne Selektoren schreiben zu müssen und ohne dass diese bei einem Redesign brechen.
Das Angebot ist real, aber es hat einen Preis, eine Geschwindigkeit und einen Fehlermodus, und alle drei sind es wert, gemessen zu werden, bevor man eine Pipeline darum herum neu aufbaut. Also haben wir gemessen. Dieser Beitrag beschreibt einen kleinen, ehrlichen Test an lebenden Seiten, was die Fehltreffer offenbarten, was es im großen Maßstab kostet und wo ein Modell in einer Extraktions-Pipeline seinen Platz hat.
Die wichtigsten Erkenntnisse
- Bei 18 lebenden Nachrichtenartikeln extrahierte ein großes Claude-Modell jede Schlagzeile exakt, 17 von 18 Daten und 14 von 18 Autorenlisten, bewertet anhand der strukturierten Daten jeder einzelnen Seite.
- Die meisten “Fehltreffer” waren keine Modellfehler. Auf jeder Seite, auf der die Autoren nicht übereinstimmten, enthielten die strukturierten Daten einen generischen Platzhalter; bei zweien davon gab das Modell den Autorennamen an, den die sichtbare Seite tatsächlich zeigte.
- Das Modell erfand nichts: Jede zurückgegebene Schlagzeile und jeder Autor erscheint im Seitentext. Es machte dennoch einen echten Fehler, indem es einen Fotografen als Autor benannte.
- Es kostete etwa 1,9 Cent pro Seite zum Listenpreis und dauerte im Median 2,4 Sekunden. Das Parsen strukturierter Daten kostet fast nichts und dauert Millisekunden.
- Modelle dort einsetzen, wo Selektoren teuer in der Pflege sind, etwa bei vielen unterschiedlichen Site-Templates oder Feldern ohne strukturierte Quelle, und alles validieren, was sie zurückgeben.
Was wir getestet haben
| Einstellung | Wert |
|---|---|
| Seiten | 18 lebende Artikel von den Rubrik-Startseiten eines großen Nachrichtenverlags, erfasst am 28. September 2026 |
| Modell-Input | Der sichtbare Text der Seite, einschließlich Navigation und anderer Seitenelemente, durchschnittlich etwa 8.700 Zeichen |
| Felder | Schlagzeile, Veröffentlichungsdatum wie auf der Seite angezeigt, und Autorennamen |
| Modell | Claude Opus 5, mit niedrigem Aufwand, mit einem die Ausgabe beschränkenden JSON-Schema |
| Referenzdaten | Die eigenen JSON-LD-strukturierten Daten derselben Seite |
| Bewertung | Schlagzeile und Datum müssen exakt übereinstimmen; Autorenlisten müssen als Mengen übereinstimmen |
Die Referenzdaten sind bewusst die Art von Daten, die in stop parsing HTML behandelt werden: die strukturierten Daten, die Verlage für Suchmaschinen einbetten. Sie sind meist korrekt. Wie sich herausstellte, nicht immer.
Ergebnisse
| Messgröße | Ergebnis |
|---|---|
| Schlagzeile korrekt | 18 von 18 |
| Datum korrekt | 17 von 18 |
| Autoren korrekt | 14 von 18 |
| Extrahierte Werte im Seitentext gefunden | 18 von 18 Schlagzeilen, 18 von 18 Autorenlisten |
| Tokens pro Seite | etwa 3.380 ein, 66 aus |
| Latenz | Median 2,4 s, Spanne 1,8 bis 10,6 s |
| Kosten für den Durchlauf | 0,33 $ zum Listenpreis, etwa 1,9 Cent pro Seite |
Die Fehltreffer waren der interessante Teil
Die Schlagzeilenzahlen unterschätzen das Modell und überschätzen die Referenzdaten. Betrachtet man jede Abweichung im Einzelnen:
- Eine Meinungskolumne. Die strukturierten Daten nannten als Autor einen generischen Platzhalter für Redaktionsmitarbeiter. Die sichtbare Namenszeile nannte den tatsächlichen Kolumnisten. Das Modell gab den Kolumnisten zurück.
- Eine Agenturmeldung. Die strukturierten Daten enthielten erneut den generischen Platzhalter; die sichtbare Namenszeile lautete “Staff and agencies”. Das Modell gab zurück, was die Seite zeigte.
- Eine Newsletter-Anmeldeseite, die sich in die Menge eingeschlichen hatte. Sie zeigte weder Autor noch Datum. Die strukturierten Daten lieferten dennoch einen generischen Autor und ein Datum; das Modell ließ beide Felder leer, statt sie zu erfinden.
- Eine Fotoreportage. Die strukturierten Daten nannten denselben generischen Platzhalter. Die Seite schrieb die Fotos einem namentlich genannten Fotografen zu, und das Modell gab den Fotografen als Autor zurück. Das ist ein echter Fehler.
Von den vier Seiten mit einer Abweichung spiegelten also zwei wider, dass die Referenzdaten weniger genau waren als die sichtbare Seite, eine zeigte, dass das Modell korrekt darauf verzichtete zu raten, und eine war ein echter Fehler. Das verändert die Frage, die es zu stellen lohnt. Strukturierte Daten sind ein starker Standardwert, aber keine gesicherte Wahrheit, und ein Modell, das die sichtbare Seite liest, kann erkennen, wo diese falsch liegen, ebenso wie es gelegentlich falsch lesen kann, was es sieht.
Was es im großen Maßstab kostet
Der Test kostete 0,33 $ für 18 Seiten zum Listenpreis von Claude Opus 5 von 5 $ pro Million Input-Tokens und 25 $ pro Million Output-Tokens. Das sind etwa 1,9 Cent pro Seite, was auf ungefähr 18.600 $ pro Million Seiten hochgerechnet wird. Anthropics Batch API halbiert diese Token-Preise für Arbeiten, die warten können. Kleinere Modelle sind pro Token noch einmal günstiger, Claude Haiku 4.5 wird mit 1 $ und 5 $ gelistet, aber wir haben sie hier nicht getestet, und ihre Genauigkeit bei den eigenen Seiten ist etwas, das man messen sollte, nicht annehmen.
Auch die Latenz spielt eine Rolle. Ein Median von 2,4 Sekunden pro Seite, mit gelegentlichen Ausreißern, ist für Monitoring und Anreicherung gut geeignet und eine echte Einschränkung für hochvolumiges Crawling. Das Parsen von JSON-LD oder das Ausführen von Selektoren dauert Millisekunden und kostet über den Abruf hinaus praktisch nichts. Diese Extraktionskosten kommen zu den Erfassungskosten hinzu, weshalb Kosten pro sauberem Datensatz beides einbeziehen sollte.
Wann welche Methode
| Situation | Beste Vorgehensweise |
|---|---|
| Die Seite veröffentlicht die Felder in JSON-LD oder eingebettetem JSON | Die strukturierten Daten parsen |
| Hohes Volumen von einem oder wenigen Site-Templates | Selektoren oder strukturierte Daten, mit Validierung |
| Viele verschiedene Websites, jede mit eigenem Template | Ein Modell, validiert, das möglicherweise Selektoren erzeugt, die man dann wiederverwendet |
| Felder, die nur im Fließtext existieren, etwa Bedingungen, Voraussetzungen oder Spezifikationen | Ein Modell |
| Strukturierte Daten scheitern bei der Validierung auf einer Seite | Ein Modell als Fallback |
| Geringes Volumen, hoher Wert, häufiger Layoutwechsel | Ein Modell |
Die stärksten Pipelines kombinieren beides. Zuerst strukturierte Daten parsen, bei einem fehlenden oder die Validierung nicht bestehenden Pflichtfeld auf ein Modell zurückgreifen, und festhalten, welche Methode welchen Datensatz erzeugt hat, dasselbe Fallback-Ketten-Muster, das für strukturierte Daten beschrieben wurde. Wo ein einziges Site-Template Tausende von Seiten abdeckt, kann es sich zudem lohnen, ein Modell einmal Selektoren vorschlagen zu lassen und diese Selektoren dann günstig auf jeder Seite auszuführen, mit dem Modell in Bereitschaft für den Fall, dass sie brechen.
Ein Modell sicher einsetzen
Vier Praktiken machen aus Modellextraktion etwas Verlässliches statt nur Beeindruckendes.
Die Ausgabe einschränken. Ein JSON-Schema sorgt dafür, dass das Modell die gewünschten Felder und Typen zurückgibt; dennoch sollte man den Stopgrund prüfen, da eine verweigerte oder abgeschnittene Antwort nichts zum Parsen bietet. Dem Modell sagen, dass es ein Feld leer lassen soll, wenn die Seite es nicht zeigt; in unserem Test tat es genau das.
Die Verankerung prüfen. Jede extrahierte Zeichenkette, die auf der Seite erscheinen sollte, etwa ein Name, eine Schlagzeile oder ein Produkttitel, sollte im Seitentext auffindbar sein. Das ist eine günstige Prüfung, die erfundene Werte abfängt. Sie fängt keinen echten Namen ab, der dem falschen Feld zugeordnet wurde, wie der Fall des Fotografen zeigt, sie ist also ein Filter, kein Beweis.
Für menschliche Überprüfung stichprobenartig testen. Jede Woche eine kleine Zufallsstichprobe gegen die Lektüre einer Person bewerten und die Genauigkeit pro Feld und pro Website im Zeitverlauf verfolgen.
Seitentext als nicht vertrauenswürdigen Input behandeln. Eine Seite wird von jemand anderem geschrieben. Modelle bei Webinhalten nur zur Extraktion nutzen, Seiteninhalte niemals Aktionen auslösen lassen, und die Anweisungen des Modells vom Seiteninhalt getrennt halten.
Dies ist der von uns verwendete Extraktionsaufruf, gefolgt von der Verankerungsprüfung:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
const SCHEMA = {
type: "object",
properties: {
headline: { type: "string" },
date_published: { type: "string", description: "YYYY-MM-DD, as shown on the page" },
authors: { type: "array", items: { type: "string" } },
},
required: ["headline", "date_published", "authors"],
additionalProperties: false,
};
export async function extractArticle(pageText) {
const response = await client.beta.messages.create({
model: "claude-opus-5",
max_tokens: 2000,
betas: ["server-side-fallback-2026-07-01"],
fallbacks: "default",
output_config: { effort: "low", format: { type: "json_schema", schema: SCHEMA } },
messages: [{
role: "user",
content:
"Below is the visible text of a news article web page, including navigation and other page furniture. " +
"Extract the article's headline exactly as written, its publication date as shown on the page (YYYY-MM-DD), " +
"and the author names. Leave a field empty if the page does not show it.\n\n<page>\n" + pageText + "\n</page>",
}],
});
if (response.stop_reason === "refusal") return null;
const text = response.content.filter((b) => b.type === "text").map((b) => b.text).join("");
return { record: JSON.parse(text), usage: response.usage };
}
// Grounding check: every extracted string must actually appear in the page text.
export function grounded(record, pageText) {
const norm = (s) => s.replace(/[‘’]/g, "'").replace(/[“”]/g, '"').replace(/\s+/g, " ").toLowerCase();
const page = norm(pageText);
return {
headline: page.includes(norm(record.headline)),
authors: record.authors.every((a) => page.includes(norm(a))),
};
}Der Input ist genauso wichtig wie das Modell. Ein Modell kann nur extrahieren, was die Seite tatsächlich enthält, sodass eine Blockseite, eine Zustimmungswand oder eine leere Hülle zu einer selbstsicheren Extraktion des falschen Inhalts führt. Validieren, was man abgerufen hat, bevor man daraus extrahiert, wie in the silent failure rate beschrieben, und aus dem Markt abrufen, dessen Version der Seite man benötigt.
Die Grenzen dieses Tests
Achtzehn Seiten von einem Verlag sind eine kleine Stichprobe, gewählt um ehrlich zu sein statt endgültig. Nachrichtenartikel sind zudem ein einfacher Fall: klare Schlagzeilen, sichtbare Namenszeilen, gut gekennzeichnete Daten. Produktseiten mit Varianten, Preisen und Verfügbarkeit oder Seiten in anderen Sprachen werden sich anders verhalten. Wir haben ein Modell auf einer Aufwandsstufe getestet. Die Methode lässt sich leicht an den eigenen Seiten wiederholen, und die eigenen Seiten sind der einzige Maßstab, der zählt.
Fazit
Ein Modell, das die Seite liest, hat jede Schlagzeile korrekt erfasst, nichts erfunden und in mehreren Fällen die Seite treuer wiedergegeben als deren eigene strukturierte Daten. Es hat auch einmal einen Autor falsch zugeordnet, kostete Cents statt Bruchteile eines Cents und dauerte Sekunden statt Millisekunden.
Das macht es zu einem starken Werkzeug für die Teile der Extraktion, mit denen Selektoren schlecht zurechtkommen: viele Templates, reine Fließtextfelder und Fallbacks, wenn strukturierte Daten fehlschlagen. Es ist kein Ersatz für strukturierte Daten, wo strukturierte Daten existieren. Parsen, was die Seite veröffentlicht, ein Modell einsetzen, wo sie es nicht tut, beides validieren, und festhalten, welches man verwendet hat.
Quellen und Referenzen
- Anthropic, Pricing. Modell- und Batch-API-Preise zum Zeitpunkt des Tests.
- Schema.org, NewsArticle.
- Testlauf durchgeführt von Shifter am 28. September 2026 an 18 öffentlich zugänglichen Nachrichtenartikeln, unter Verwendung des obigen Codes.