So baust du eine Web-Scraper-App mit Lovable

Mit Lovable lässt sich eine Web-Scraper-App bauen: Oberfläche generieren, Supabase-Backend anbinden und eine Scraping-API über eine serverseitige Funktion ansprechen. API-Keys und Fetch-Logik gehören dabei keinesfalls in den Browser. Diese Anleitung zeigt den Bau eines Single-Page-Scrapers mit gespeicherten Ergebnissen, CSV-Export und Limits, die verhindern, dass aus einem kleinen Tool plötzlich eine teure Rechnung wird.

Was entsteht und was es kostet

Das Ziel ist ein Recherche-Werkzeug, keine universelle Crawling-Plattform. Ein angemeldeter Nutzer übergibt eine freigegebene, öffentliche URL, erhält Seitentitel sowie extrahierten Text und kann frühere Ergebnisse exportieren.

Für den Stand dieses Leitfadens setzt der Stack auf Lovable, Supabase und Firecrawl. Tarife und Integrationsoberflächen ändern sich ständig. Daher nutzt diese Anleitung eine explizite serverseitige API-Anbindung, statt sich auf bestimmte Lovable-Menüs zu verlassen.

Der Request-Pfad ist simpel:

`Browser -> authentifizierte Backend-Funktion -> Firecrawl -> gespeichertes Ergebnis -> Browser`

Lovable generiert die Anwendung. Supabase verwaltet Accounts, Datenbankeinträge und die Backend-Funktion. Firecrawl ruft die Seite ab und wandelt den Inhalt in ein brauchbares Format um. Ein KI-Modell braucht man nicht, um Titel und Fließtext auszulesen.

Die erste Version bewusst schlank halten

Unterstütze anfangs nur eine URL pro Vorgang. Begrenze den Zugriff auf wenige geladene Tester. Erlaube ausschließlich Domains, die dir gehören oder für die eine Scraping-Erlaubnis vorliegt.

Rekursives Crawling, zeitgesteuertes Monitoring, passwortgeschützte Seiten oder Proxy-Rotation gehören hier noch nicht hinein. Jedes dieser Features verändert die betrieblichen Anforderungen grundlegend. Ein Scraper, der die eigene Dokumentation sauber erfasst, taugt nicht automatisch als stabiles Tool für die Konkurrenzbeobachtung.

Wer einen enger gefassten Anwendungsfall sucht, findet Anregungen in der App-Ideen-Sammlung. Ein Tool für Doku-Bestände oder freigegebene Lieferantenkataloge lässt sich deutlich leichter validieren als der Anspruch, "einfach alles" zu scrapen.

Zeit und Budget vor dem Prompting planen

Dies sind Schätzwerte für einen kleinen Piloten, keine verbindlichen Preisangebote der Provider.

| Arbeitsschritt | Geschätzte Zeit | Budget-Annahme | |---|---|---| | UI und Authentifizierung | 45-90 Minuten | Verbraucht das Lovable-Build-Kontingent | | Datenbank und Backend-Integration | 90-180 Minuten | Ein kleiner Pilot passt oft in kostenlose Freikontingente | | Sicherheit, Fehlertests und CSV | 90-180 Minuten | Reine Umsetzungszeit | | Scraping-Nutzung | Variiert je nach Seite | 5-20 $ als Puffer für die Pilotphase einplanen | | Erster funktionierender Pilot gesamt | 4-8 Stunden | 30-100 $ für den ersten Monat ansetzen |

Einsteiger sollten eher ein Wochenende einplanen. Mindestumsätze, Hosting, Steuern oder widerspenstige Zielseiten können die Kosten nach oben treiben. Ein Blick in den Lovable-Preisratgeber und die aktuellen Tarife der Anbieter schützt vor Überraschungen.

Zur Kapazitätsplanung: 10 Tester mit jeweils 10 Abfragen pro Tag erzeugen 3.000 Anfragen im Monat. Das entspricht nicht zwingend 3.000 abgerechneten Credits. Browser-Rendering, Retries oder Extraktionen verändern oft die Abrechnungseinheit des Providers.

Oberfläche und Datenbank aufsetzen

Schritt 1: Die kleinste funktionale Version generieren

Starte ein Lovable-Projekt und gib ihm eine klar begrenzte Spezifikation mit. Die Formulierung "Enterprise-Scraping-Dashboard" sollte man vermeiden. Meist liefert das bunte Diagramme, bevor der erste echte Request überhaupt funktioniert.

Folgenden Prompt einfügen:

```text Baue eine authentifizierte Single-Page-Web-Scraper-App namens Page Ledger.

Nutze Supabase für Authentifizierung, Datenbank und eine serverseitige Edge Function. Rufe den Scraping-Provider keinesfalls aus dem Browser auf.

Screens:

1. Login.
2. Dashboard mit Eingabefeld für eine HTTPS-URL und einem Button "Scrape page".
3. Ergebnistabelle mit URL, Titel, Status und Erstellungsdatum.
4. Ergebnis-Detailansicht mit extrahiertem Markdown und Link zur Quelle.

Erstelle eine Tabelle scrape_jobs mit: id, user_id, requested_url, final_url, status, title, markdown, error_code, created_at, completed_at.

Anforderungen:

• Nutzer dürfen per Row-Level Security nur eigene Jobs lesen.
• Der Server weist die Eigentümerschaft anhand der verifizierten Nutzersitzung zu.
• Zugangsdaten des Providers verbleiben in Backend-Secrets.
• Nur exakte Hostnamen aus einer serverseitig verwalteten Allowlist werden akzeptiert.
• Starte mit maximal einem aktiven Job pro Nutzer und 10 Anfragen pro Tag.
• Quotas müssen serverseitig atomar durchgesetzt werden.
• Zeige die Status queued, running, succeeded, failed und timed_out an.
• Gib niemals Mock-Daten als erfolgreiches Ergebnis aus.
• Integriere einen CSV-Export für die Ergebnisse des eingeloggten Nutzers.
• Extrahierten Inhalt sicher rendern, rohes HTML deaktivieren.

Implementiere zuerst das Schema, die Zugriffsregeln und das UI. Erkläre vor dem Einbinden des Provider-Aufrufs den Auth-Flow, die Secret-Speicherung und die geplante Quota-Durchsetzung zur Prüfung. ```

Die Implementierung sollte in überprüfbare Schritte unterteilt werden. Die Prompt-Bibliothek bietet weitere Muster, um Folgeprompts fokussiert zu halten.

Schritt 2: Supabase verbinden und Berechtigungen prüfen

Verbinde das gewünschte Supabase-Projekt über den regulären Integrations-Flow von Lovable. Vor dem Ausführen von Migrationen lohnt sich der prüfende Blick auf die Projekt-ID. Aus Versehen eine Produktionsdatenbank zu erwischen, wird schnell teuer.

Generierte Zugriffsregeln sind Code und müssen getestet werden.

Das Feld `scrape_jobs.user_id` muss auf einen authentifizierten Nutzer verweisen. Aktiviere Row-Level Security und erlaube Lesezugriffe nur dann, wenn der Besitzer der Zeile mit dem aktuellen Nutzer übereinstimmt.

Bei diesem Aufbau darf der Browser keine Jobs direkt einfügen oder aktualisieren. Das Backend prüft das Token des Nutzers, weist die Eigentümerschaft eigenständig zu und schreibt den Job-Status. Einem im Request-Body übergebenen `user_id` darf man niemals vertrauen.

Verwendet das Backend ein privilegiertes Datenbank-Secret, umgeht dies unter Umständen die Row-Level Security. Jeder Lese- oder Schreibzugriff über diesen Client muss die Besitzverhältnisse explizit prüfen. Solche Zugangsdaten haben in Frontend-Umgebungsvariablen oder Bundles nichts zu suchen.

Schritt 3: Statusangaben aussagekräftig gestalten

Lege den Job an, bevor der Call an Firecrawl rausgeht. So hinterlassen auch Fehlversuche einen Eintrag in der Datenbank, statt spurlos hinter einer flüchtigen Toast-Meldung zu verschwinden.

Lesbare Fehlercodes wie `DOMAIN_NOT_ALLOWED`, `RATE_LIMITED`, `FETCH_FAILED` oder `PROVIDER_TIMEOUT` erleichtern die Fehlersuche. Detaillierte Diagnosemeldungen des Anbieters gehören in geschützte Logs, nicht in die Antwort an den Client.

Reißt ein Request das synchrone Zeitlimit, gehört der Status auf `timed_out` gesetzt. Nutzer sollten nicht ewig auf einen Ladekreis starren.

Den Scraper sicher anbinden

Schritt 4: API-Schlüssel hinterlegen

Erstelle einen Firecrawl-API-Key und hinterlege ihn als Backend-Secret, etwa unter dem Namen `FIRECRAWL_API_KEY`. Er darf ausschließlich innerhalb der Server-Funktion ausgelesen werden.

Echte Keys gehören weder in Chat-Nachrichten mit Lovable noch in Variablen wie `VITE_FIRECRAWL_API_KEY`, die im Browser landen. Taucht ein Schlüssel im fertigen JavaScript-Bundle auf, kann ihn jeder Besucher kopieren.

Die Scrape-API von Firecrawl v2 erwartet folgendes Format. Vor dem Deployment empfiehlt sich ein Abgleich mit der aktuellen Dokumentation des Anbieters:

```http POST https://api.firecrawl.dev/v2/scrape Authorization: Bearer YOUR_SERVER_SIDE_KEY Content-Type: application/json

{ "url": "https://your-approved-domain.example/docs/start", "formats": ["markdown"], "onlyMainContent": true } ```

Ersetze die Beispiel-URL durch eine freigegebene Seite. Bei Erfolg liefert die API das extrahierte Markdown unter `data.markdown` und Seiten-Metadaten unter `data.metadata`. Fehlende Metadaten, leerer Content, Provider-Fehler und Antworten, die kein JSON sind, müssen sauber abgefangen werden.

Speichere den Seitentitel, sofern vorhanden. Liefert der Provider eine verifizierte Ziel-URL nach Redirects mit, wandert diese ins Feld `final_url` - andernfalls bleibt das Feld leer. So wird vermieden, fälschlicherweise die eingegebene Adresse als endgültiges Ziel auszugeben.

Schritt 5: URLs validieren, bevor Credits verbraucht werden

Das Backend sollte diese Prüfungen nacheinander durchführen:

1. Token des angemeldeten Nutzers verifizieren.
2. URL mit einem echten URL-Parser zerlegen, nicht nur mit regulären Ausdrücken.
3. HTTPS erzwingen, eingebettete Benutzernamen oder Passwörter abweisen.
4. Reine IP-Adressen als Host sowie unübliche Ports blockieren.
5. Normalisierten Hostnamen mit einer exakten, serverseitigen Allowlist abgleichen.
6. Nutzerkontingent und Slot für aktive Jobs atomar reservieren.
7. Job anlegen und den Request an den Provider abschicken.
8. Ergebnis oder Fehler speichern und den aktiven Job-Slot freigeben.

Keine ungenauen Suffix-Prüfungen verwenden: Die Freigabe von `example.com` darf nicht versehentlich `notexample.com` durchwinken. Subdomains sollten für die Testphase einzeln erfasst werden.

Eine Hostname-Allowlist ist Pflicht, schützt aber nicht vor allen Risiken durch Server-Side Request Forgery (SSRF). Weiterleitungen und DNS-Änderungen können Anfragen an unerwartete Ziele lenken. Die Abrufschicht muss den Zugriff auf Loopback-, private, Link-Local- und Cloud-Metadata-Adressen bei jedem Redirect und jedem DNS-Lookup rigoros unterbinden.

Bei einem gehosteten Scraping-Dienst sollten diese Schutzmechanismen beim Anbieter erfragt werden. Sind die Schutzvorkehrungen unklar, gehört die Eingabe beliebiger URLs nicht ins offene Netz. Beschränke den Piloten auf selbst kontrollierte Domains ohne benutzerdefinierte Weiterleitungen. Erst nach dem Abruf die Ziel-URL zu prüfen, bietet keinen vorbeugenden Schutz.

Schritt 6: Limits setzen, die der Browser nicht umgehen kann

Für den Start empfehlen sich folgende Limits:

• Ein aktiver Request pro Nutzer.
• Zehn Anfragen pro Nutzer und Tag.
• Ein Anwendungs-Timeout von 30 Sekunden, sofern die Serverless-Laufzeit das erlaubt.
• Maximal 200.000 Textzeichen pro Ergebnis speichern.
• Keine automatischen Wiederholungsversuche in Version eins.

Das sind interne Anwendungsregeln, keine Limits des Scraping-Dienstes. Akzeptierte Anfragen sollten auch bei Fehlversuchen vom Kontingent abgezogen werden. Sonst können endlose Fehlversuche schnell teure API-Rechnungen nach sich ziehen.

Reserviere Ressourcen innerhalb einer Datenbanktransaktion oder einer vergleichbaren atomaren Operation. Zwei parallele Anfragen dürfen nicht gleichzeitig einen freien Slot vorfinden und loslaufen.

Sofern möglich, sollte das Timeout beim Provider kürzer sein als das Zeitlimit der Backend-Funktion. Bricht man den eigenen HTTP-Request ab, verarbeitet oder berechnet der Provider den Vorgang oft trotzdem weiter. Abgebrochene Jobs sollten erfasst und keinesfalls blind wiederholt werden.

Bei trägen Zielseiten lohnt später der Wechsel zu asynchronen Background-Jobs. Eine unzuverlässige synchrone Schnittstelle lässt sich nicht dauerhaft hinter einem längeren Ladespinner verstecken.

Testen, exportieren und starten

Schritt 7: Verhalten prüfen, nicht nur Screenshots

Richte eine Testseite auf einer eigenen Domain ein, bestückt mit bekannter Überschrift, Absatz und Link. Prüfe, ob das extrahierte Ergebnis genau diese Daten enthält und korrekt auf die Quelle verweist.

Danach hilft diese Testmatrix:

| Test | Erwartetes Ergebnis | |---|---| | Freigegebene öffentliche Seite | Gespeichertes Ergebnis mit echten extrahierten Inhalten | | Unbekannter Hostname | Blockiert vor dem Aufruf des Providers | | URL mit Zugangsdaten | Blockiert vor dem Aufruf des Providers | | Private IP-Adresse | Blockiert vor dem Aufruf des Providers | | Elfte Anfrage am selben Tag | Quota-Fehler ohne neuen Provider-Aufruf | | Zwei gleichzeitige Anfragen | Nur ein aktiver Job wird zugelassen | | Nutzer B fragt Ergebnis von Nutzer A ab | Kein Zugriff auf den Datensatz | | Provider meldet Fehler oder blockiert | Status failed oder timed_out mit lesbarer Fehlermeldung |

Teste auch eine Weiterleitung auf einer kontrollierten Domain. Die Abruf-Ebene muss die Beschränkungen auch auf das Ziel anwenden, nicht nur auf den ursprünglichen Hostnamen.

Ein HTTP-Status 200 beweist noch lange keinen erfolgreichen Scrape. Eine CAPTCHA-Abfrage, eine Login-Maske oder ein leeres Dokument dürfen nicht ungeprüft als valides Recherche-Ergebnis durchgehen. Schlagen die Qualitätsprüfungen fehl, gehört eine Warnung in die Oberfläche.

Schritt 8: Daten sicher exportieren

Für den Anfang genügen `requested_url`, `title`, `status` und `created_at` im Export. Das vollständige Markdown bleibt besser in der Detailansicht, solange niemand Massenexporte des Inhalts verlangt.

Nutze eine CSV-Bibliothek, die Anführungszeichen, Kommas und Zeilenumbrüche korrekt verarbeitet. Formel-Präfixe wie `=`, `+`, `-` oder `@` müssen unschädlich gemacht werden, selbst wenn Leerzeichen oder Steuerzeichen vorangestellt sind. Ein bloßes Einklammern in Anführungszeichen schützt in Tabellenkalkulationen nicht vor der Ausführung von Formeln.

Gescrapte Inhalte gelten grundsätzlich als unsicher. Beim Rendern von Markdown sollte rohes HTML deaktiviert oder über einen gepflegten Sanitizer bereinigt werden. Zurückgegebenes HTML darf niemals ungefiltert ins DOM wandern.

Schritt 9: Einen kontrollierten Piloten starten

Lade fünf Tester ein und bitte jeden, fünf freigegebene Seiten abzurufen. Werte alle 25 Durchläufe aus: Erfolgsquote, Antwortzeiten, API-Verbrauch und Fehlerursachen.

Sinnvolle Zielmarken für den Start: Mindestens 23 von 25 Abfragen liefern brauchbare Daten, und kontoübergreifende Zugriffe sind ausgeschlossen. Das sind Kriterien für die Abnahme, keine Garantien. Jeder Sicherheitsfehler muss analysiert werden, ganz gleich wie gut die Erfolgsquote insgesamt ausfällt.

Vor dem Rollout hilft diese Checkliste:

• [ ] Keine Provider-Keys oder privilegierten Datenbank-Secrets im Browser-Code.
• [ ] Authentifizierung und Besitzprüfungen mit zwei getrennten Accounts erfolgreich getestet.
• [ ] Hostname-Filter, Redirect-Schutz und Quotas funktionieren nachweislich.
• [ ] Timeouts führen verlässlich zu einem finalen Job-Status.
• [ ] Gescrapte Daten und CSV-Exporte werden sicher verarbeitet.
• [ ] Gespeicherte Inhalte lassen sich löschen, Aufbewahrungsfristen sind geregelt.
• [ ] Nutzungs-Alerts beim Provider und ein Not-Aus-Schalter (Kill Switch) sind eingerichtet.
• [ ] Test-Domains sind freigegeben, unzulässige Einsatzzwecke dokumentiert.

Bringe diese Version an den Start, bevor Crawling ins Spiel kommt. Verlässliche Ergebnisse auf fünf freigegebenen Seiten wiegen mehr als ein schickes Dashboard, das vollmundig das halbe Web verspricht.

Kann Lovable Websites ohne API scrapen?

Ja. Lovable kann Code für eigene serverseitige Fetcher oder Browser-Automatisierungen generieren. Reine Abrufe im Browser scheitern jedoch meist an Cross-Origin-Beschränkungen (CORS), und dynamische Seiten verlangen oft volles Rendering. Eine gehostete Scraping-API spart Infrastruktur-Aufwand, garantiert aber weder Zugriff noch rechtliche Erlaubnis.

Ist es legal, einen Web-Scraper mit Lovable zu bauen?

Ein solches Werkzeug zu bauen bedeutet nicht, fremde Daten automatisch erfassen und weiterverarbeiten zu dürfen. Geltendes Recht, Nutzungsbedingungen, Datenschutz und Urheberrechte wollen beachtet werden. Anweisungen für Webcrawler und Zugriffssperren sollten respektiert werden, wobei eine robots.txt keine juristische Freigabe darstellt. Am sichersten startet man mit eigenen Inhalten oder ausdrücklicher Zustimmung.

Wie lässt sich KI-Extraktion im Scraper ergänzen?

Nach dem erfolgreichen Abruf wird ein separater Schritt auf dem Server zwischengeschaltet. Das Modell erhält ein striktes Schema, muss Fundstellen im Quelltext belegen und bei fehlenden Angaben `null` zurückgeben. Gescrapte Anweisungen aus fremden Texten sind strikt als nicht vertrauenswürdig zu behandeln, niemals als Steuerbefehle für Tools. Die Kosten für KI-Modelle sollten zudem getrennt vom Scraping-Verbrauch erfasst werden.