Was ist eine Web-Reader-API? URL rein, lesbares Markdown raus

Was macht eine Web-Reader-API Schritt für Schritt?

Sie erledigt fünf Aufgaben, die jede Page-to-Text-Pipeline braucht, in einem Aufruf:

1. Berechtigung prüfen. Ein sorgfältiger Reader sieht vor dem Abruf in der robots.txt der Seite nach – für den eigenen Namen und für alle Robots.
2. Die Seite abrufen. Er lädt das HTML herunter, folgt Weiterleitungen und bricht bei einem Timeout ab.
3. Bei Bedarf rendern. Ist das HTML eine leere Hülle, die per JavaScript gefüllt wird, lädt er die Seite in einem Headless-Browser und liest das Ergebnis aus.
4. Den Hauptinhalt extrahieren. Ein Schritt im Stil von Readability findet den Artikel oder den Dokumentationstext und entfernt das Drumherum der Seite.
5. Umwandeln und beschreiben. Er schreibt den Inhalt als Markdown und ergänzt Metadaten: Titel, Autor, Erscheinungsdatum, Sprache und Wortzahl.

Der Aufrufer erhält ein JSON-Objekt mit dem Markdown darin. Ein Modell kann es auf einmal lesen, oder eine Pipeline zerlegt es in Chunks für einen Vektorspeicher.

Warum brauchen Modelle Markdown statt HTML?

Weil der größte Teil einer HTML-Seite kein Inhalt ist. Menüs, Script-Tags, Tracking-Code und Layout-Markup verbrauchen Tokens, die ein Modell lesen muss und die Sie bezahlen müssen. Markdown behält die Teile, die Bedeutung tragen: Überschriften, Listen, Tabellen, Links und Hervorhebungen.

Cloudflare nannte ein konkretes Beispiel, als das Unternehmen am 12. Februar 2026 die Funktion „Markdown for Agents“ startete: Eine Seite schrumpfte von 16.180 Tokens als HTML auf 3.150 Tokens als Markdown, rund 80 % weniger. Die Ergebnisse variieren je nach Seite, aber die Richtung ist auf den meisten Artikel- und Dokumentationsseiten dieselbe.

Wie unterscheidet sich eine Web-Reader-API von einer Scraping-API?

Eine Scraping-API gibt zurück, was der Server gesendet hat; ein Reader gibt zurück, was ein Mensch lesen würde. Scraping-APIs sind darauf ausgelegt, Seiten in großem Umfang abzurufen, oft um bestimmte Felder wie Preise oder Produktnamen zu entnehmen, und sie liefern in der Regel rohes HTML oder strukturiertes JSON zurück, das Sie definieren.

Ein Web-Reader ist enger gefasst und stärker auf eine Meinung festgelegt. Er entscheidet, was der Hauptinhalt ist, entfernt den Rest und schreibt sauberen Text. Das ist das richtige Werkzeug, wenn der nächste Konsument ein Sprachmodell, ein Suchindex oder ein Mensch ist, der eine Zusammenfassung liest. Es ist das falsche Werkzeug, wenn Sie jedes Feld eines Produktrasters brauchen; dafür wollen Sie das vollständige HTML oder eine schema-basierte Extraktion.

Wie unterscheidet sie sich von einer Such-API?

Eine Such-API beantwortet die Frage „Welche Seiten handeln von diesem Thema?“; ein Reader beantwortet die Frage „Was steht auf dieser Seite?“. Die Suche liefert eine Liste von URLs mit Titeln und Snippets zu einer Suchanfrage. Ein Reader nimmt eine dieser URLs und gibt ihren vollständigen Text zurück.

Agenten verketten oft beides: erst suchen, um Kandidatenseiten zu finden, dann die besten drei oder vier lesen, um mit Quellenangaben zu antworten. Wenn Sie die Schritte getrennt halten, können Sie selbst bestimmen, wie viele Seiten gelesen werden, was Tokens und Credits spart.

Kann ich statt einer API Open-Source-Tools verwenden?

Ja, und viele Teams fangen so an. Mozillas Readability extrahiert den Hauptinhalt einer Seite in einem Browser-Kontext; Trafilatura erledigt die Extraktion in Python; Microsofts MarkItDown wandelt Dokumente, auch PDFs, in Markdown um; Crawl4AI kombiniert Crawling und Markdown-Ausgabe.

Die Bibliothek ist der einfache Teil. Sie in Produktion zu betreiben heißt, Headless-Browser für JavaScript-Seiten zu hosten, robots.txt zu prüfen, Timeouts, Weiterleitungen und Zeichensätze zu behandeln, PDFs umzuwandeln und all das gepatcht zu halten. Eine API lohnt sich, wenn Sie lieber pro Seite bezahlen, statt diese Maschinerie zu betreiben; eine Bibliothek lohnt sich, wenn die Mengen stabil sind und Sie die Zeit haben, sie zu betreiben.

Wie rechnen Web-Reader-APIs ab?

Drei Abrechnungsmodelle sind 2026 üblich. Credit-basierte Tarife berechnen eine feste Anzahl Credits pro Seite: Die Preisseite von Firecrawl, gelesen am 22. Oktober 2026, zählt 1 Credit pro gescrapter Seite und 4 zusätzliche Credits pro Seite für das JSON-Format. Token-basierte Abrechnung berechnet den zurückgegebenen Text: Jina Reader rechnet seit dem 6. Mai 2025 so ab und schenkt jedem neuen API-Schlüssel 10 Millionen kostenlose Tokens. Monatliche Tarife setzen ihre Credits in jedem Zyklus zurück, während Prepaid-Packs sie behalten.

WebReaderAPI verwendet Prepaid-Credits, die nie verfallen: 1 Credit = 1 gelesene Seite ohne Browser; 2 Credits, wenn die Seite einen Browser braucht, um JavaScript auszuführen. Eine Suchanfrage, die fehlschlägt oder die eine robots.txt einer Website verweigert, wird nicht abgerechnet. 10.000 Seiten kosten 3,75 $, und der Satz sinkt auf 0,07 $/1K Seiten bei 5.000.000 Seiten, Stand Oktober 2026.

Was sollte ich prüfen, bevor ich eine Web-Reader-API wähle?

Testen Sie sie mit zwanzig Ihrer eigenen URLs und achten Sie auf sechs Dinge:

• Extraktionsqualität. Behält das Markdown den Artikel und entfernt den Rest, einschließlich Tabellen und Codeblöcken?
• JavaScript. Kommen im Browser erzeugte Seiten mit Text zurück, und was kostet das Rendern?
• PDFs. Werden sie unterstützt, und wie werden Seiten gezählt?
• Entscheidungen der Seiteninhaber. Respektiert der Dienst robots.txt und erklärte KI-Präferenzen, und sagt er das in seinen Docs?
• Fehlerfälle. Werden fehlgeschlagene und abgelehnte Seiten berechnet?
• Budgetkontrolle. Können Sie die Länge jeder Seite begrenzen, und verfallen Credits?

Unser Vergleich der Preise von Web-Reader-APIs stellt die wichtigsten Anbieter mit Datumsangaben nebeneinander.