Firecrawl selbst hosten: Webseiten als Wissensquelle für RAG

Constantin Budin, Azure- und Microsoft-Berater bei Pexon Consulting | 11 Min. Lesezeit | 22.09.2026

TL;DR: Firecrawl in fünf Sätzen

Firecrawl verwandelt Webseiten in sauberen Text für KI-Anwendungen. Der Kern ist quelloffen unter der AGPL und lässt sich selbst betreiben. Die selbst betriebene Fassung kann weniger als die Cloud: kein Fire-Engine gegen Bot-Schutz, keine Bildschirmfotos, keine Aktionen auf der Seite. Sie braucht außerdem vier Dienste, nicht nur einen Container. Für interne Quellen ist das trotzdem oft der richtige Weg.

Das Problem: Die Antwort steht auf einer Webseite, nur nicht im Chat

Der Fall kommt in fast jedem RAG-Projekt vor. Die Wissensbasis ist aus PDFs und einem Laufwerk gebaut, und dann fragt jemand nach den Garantiebedingungen aus dem Partnerportal, nach der aktuellen Produktbeschreibung aus dem eigenen Webauftritt oder nach der Doku eines Herstellers. Diese Inhalte liegen im Web, nicht im Laufwerk.

Der erste Reflex ist ein Skript mit einer HTML-Bibliothek. Das funktioniert bis zur ersten Seite, die ihren Inhalt per JavaScript nachlädt. Danach kommen Navigation, Cookie-Banner und Fußzeilen mit in den Text, das Modell zitiert den Cookie-Hinweis, und niemand versteht, warum die Antwort so seltsam ist.

Genau diese Lücke füllt Firecrawl: Es holt die Seite, rendert sie, entfernt das Beiwerk und gibt Markdown zurück, das man einem Modell vorlegen kann.

Was Firecrawl anbietet

Vier Bausteine, die man auseinanderhalten sollte, weil sie unterschiedlich teuer im Betrieb sind:

Die Lizenz ist AGPL-3.0 für den Kern, die Bibliotheken und Oberflächen stehen unter MIT. Für den Eigenbetrieb ist die AGPL wichtig: Wer den Dienst verändert und anderen über ein Netz anbietet, muss den Quelltext offenlegen. Für die interne Nutzung im eigenen Unternehmen ist das unkritisch, für ein Produkt, das Sie Ihren Kunden verkaufen, gehört es geprüft.

Was der Eigenbetrieb kostet, ehrlich gerechnet

Die Projektdokumentation ist an dieser Stelle ungewöhnlich offen, und das sollte man ernst nehmen:

• Der Kern braucht vier Dienste. Postgres für die Warteschlange, Redis, RabbitMQ und Playwright für das Rendern. Das ist kein Container, das ist ein kleines System.
• Fire-Engine fehlt. Der Teil, der mit Bot-Schutz umgeht, ist in der Standardfassung nicht dabei. Seiten hinter Cloudflare oder ähnlichem Schutz bleiben also oft außen vor.
• Bildschirmfotos und Aktionen fehlen. Formulare ausfüllen, klicken, warten: nicht im Standardumfang.
• Der Schnellstart ist kein Produktivbetrieb. Die Doku schreibt selbst, dass der Schnellstart die Authentifizierung ausschaltet und keine produktive Architektur ist. Dauerhafter Speicher, Anmeldung, TLS und Sicherungen sind Ihre Entscheidungen, es gibt keinen Schalter dafür.
• Strukturierte Auszüge brauchen ein Modell. Wer nicht nur Text, sondern Felder will, hängt einen eigenen Modellanbieter an, etwa über Ihr Gateway.

Daraus folgt eine einfache Entscheidungsregel, die wir in Projekten anwenden:

Schritt für Schritt: von der Seite zur Antwort

Die Aufnahme ist mehr als ein Crawl. Diese fünf Schritte haben sich bewährt:

1. Umfang klären, bevor gecrawlt wird. Mit map die Adressen listen und aussortieren: Paginierung, Kalender, Druckansichten und Archivseiten blähen die Wissensbasis auf und verschlechtern die Antworten.
2. Extrahieren und prüfen. Zehn Seiten als Markdown ausgeben und selbst lesen. Wenn dort Navigation und Cookie-Hinweise stehen, ist der Auswahlbereich falsch gesetzt, nicht das Modell schlecht.
3. Sinnvoll zerlegen. Entlang der Überschriften trennen und in jedem Abschnitt die Quelle mitführen. Wie das geht und warum die Größe entscheidet, steht im Beitrag zum Chunking.
4. Einbetten und speichern. Für die meisten Häuser reicht pgvector im vorhandenen Postgres, weil die Metadaten ohnehin dort liegen und ein einziger Abfrageweg genügt.
5. Aktuell halten. Der Teil, den alle vergessen. Eine Wissensbasis, die einmal gefüllt wurde, ist nach drei Monaten falsch. Sie brauchen einen Takt, einen Vergleich mit dem letzten Stand und eine Regel für gelöschte Seiten.

Schritt fünf ist der Grund, warum das ein Betriebsthema ist und kein Skript. Wir bauen dafür eine Strecke, die den Crawl regelmäßig fährt, geänderte Seiten erkennt, nur die neu einbettet und protokolliert, was sich geändert hat.

Eine Mengenrechnung vorweg

Vor dem ersten Crawl lohnt eine grobe Schätzung, weil sie fast immer die Erwartung korrigiert. Ein mittlerer Hilfebereich hat 800 Seiten. Nach dem Aussortieren von Paginierung, Archiven und Druckansichten bleiben vielleicht 500 echte Inhaltsseiten. Zerlegt in Abschnitte von rund 800 Zeichen ergibt das 4.000 bis 6.000 Einträge in der Wissensbasis.

Das ist für pgvector eine kleine Menge, für die Qualität der Antworten aber schon kritisch: Jede Seite, die nur Navigation enthält, verdrängt in den Treffern eine Seite mit Inhalt. Deshalb ist das Aussortieren vor dem Crawl kein Aufräumen, sondern der Hebel für die Antwortqualität. Wer stattdessen alles aufnimmt und später filtert, zahlt das mit schlechteren Antworten und mit Rechenzeit für Einbettungen, die niemand braucht.

Zwei Punkte, die rechtlich zählen

Erstens: fremde Seiten. Firecrawl beachtet standardmäßig die robots.txt. Das Projekt schreibt zugleich, dass es allein in der Verantwortung der Nutzer liegt, die Richtlinien der Webseiten zu beachten. Wer den Katalog eines Wettbewerbers absaugt, hat kein technisches, sondern ein juristisches Problem. Klären Sie vorher, welche Quellen erlaubt sind, und halten Sie die Liste schriftlich fest.

Zweitens: personenbezogene Daten. Team-Seiten, Foren und Kommentare enthalten Namen. Sobald das in eine Wissensbasis wandert, ist es eine Verarbeitung mit allem, was dazugehört. Der praktische Weg ist, solche Bereiche schon beim Crawl auszuschließen, statt sie später wieder herauszufiltern.

Die Alternativen, kurz eingeordnet

Für PDFs und Scans ist Firecrawl nicht der richtige Griff. Dafür gibt es den Vergleich von Parsern für die Dokumentenverarbeitung.

Häufig gestellte Fragen

Was ist Firecrawl?

Firecrawl ist ein offener Dienst, der Webseiten holt, rendert und als sauberes Markdown für KI-Anwendungen zurückgibt. Er kann einzelne Adressen verarbeiten, einer Domain folgen, deren Adressen auflisten und Suchergebnisse mit Inhalt liefern.

Kann ich Firecrawl selbst hosten?

Ja, der Kern steht unter der AGPL-3.0. Sie brauchen dafür Postgres, Redis, RabbitMQ und Playwright. Einige Funktionen der Cloud fehlen, darunter der Schutz gegen Bot-Erkennung, Bildschirmfotos und Aktionen auf der Seite.

Was fehlt der selbst betriebenen Fassung?

Vor allem Fire-Engine, also der Umgang mit Bot-Schutz, dazu Bildschirmfotos und Interaktionen. Für strukturierte Auszüge müssen Sie außerdem selbst einen Modellanbieter anbinden. Der Schnellstart schaltet die Authentifizierung ab und ist ausdrücklich nicht für den Produktivbetrieb gedacht.

Ist das Crawlen fremder Webseiten erlaubt?

Firecrawl beachtet standardmäßig die robots.txt, die Verantwortung für die Nutzungsbedingungen der Quelle bleibt aber bei Ihnen. Interne Quellen und die eigenen Webauftritte sind unkritisch, fremde Kataloge und Portale gehören vorher geprüft.

Wie halte ich die Wissensbasis aktuell?

Mit einem festen Takt statt einer einmaligen Befüllung: Crawl wiederholen, geänderte Seiten erkennen, nur diese neu einbetten, gelöschte entfernen und protokollieren, was sich geändert hat.

Nächster Schritt

Wenn Inhalte aus dem Web in Ihre Wissensbasis sollen, ist der Crawl der kleinste Teil. Wir bauen die Strecke von der Quelle bis zur Antwort, inklusive Aktualisierung und Messung.

Verwandte Themen

Quellen: Firecrawl-Projektseite und Dokumentation (Lizenz, Endpunkte, Anleitung zum Eigenbetrieb inklusive der genannten Einschränkungen und Warnungen). Stand 22.09.2026.