Stopp mit Scraping, starte mit Downloading: Der höfliche Weg, Prompt-Daten zu bekommen

Stoppt das Scraping, startet den Download: Der höfliche Weg, um Prompt-Daten zu erhalten

Wenn ihr gerade einen Headless-Browser gegen /search laufen lasst, Seite für Seite durch Ergebnisse blättert und HTML parst, das nie zum Parsen gedacht war, ist dieser Beitrag für euch. Es gibt einen schnelleren Weg, und der beinhaltet nicht, sich als Mensch auszugeben.

Wir sehen den Traffic. Jede Woche treffen ein paar Scraper auf die Suchseite von wikiprompt.org mit rotierenden User-Agents, zufälligen Verzögerungen und gelegentlichen Retry-Stürmen, wenn ein Selektor bricht, weil wir eine UI-Änderung ausgeliefert haben. Es funktioniert irgendwie, bis es das nicht mehr tut. Dann muss jemand den Scraper wieder neu schreiben, weil wir eine CSS-Klasse umbenannt oder die Paginierung geändert haben.

In der Zwischenzeit liegt der gesamte Katalog, alle 55.000+ Prompts, hinter einem JSON-Endpoint, der in Millisekunden antwortet und dem es egal ist, wie oft ihr fragt.

Warum Scraping der Seite hier das falsche Werkzeug ist

Das Scrapen einer Such-UI ist eine vernünftige Technik, wenn es keine Alternative gibt. Es ist eine schlechte Technik, wenn es eine gibt, und hier ist, warum es speziell für einen Prompt-Katalog schlecht ist:

Nichts davon ist eine Drohung, es ist nur eine Beschreibung dessen, was Scraping euch kostet. Wir würden lieber, ihr überspringt das alles.

Der höfliche Weg: der Bulk-Datensatz

Wir veröffentlichen den Datensatz genau deshalb, damit niemand uns scrapen muss. Holt zuerst das Manifest:

curl "https://www.wikiprompt.org/dataset"

Es gibt total_prompts, die record_fields, die ihr bei jedem Datensatz erwarten könnt, und das Paginierungsschema zurück. Dann zieht Datensätze von /dataset/prompts:

curl "https://www.wikiprompt.org/dataset/prompts?limit=500"

Diese einzelne Anfrage liefert euch bis zu 500 vollständig strukturierte Prompt-Datensätze in einer Antwort, kein Headless-Browser, kein HTML zum Parsen, kein Rendering zum Warten. Jeder Datensatz enthält bereits slug, url, title, description, content (den eigentlichen Prompt-Text), category, tags, media, model, das strukturierte metadata-Objekt, author, original_source und beide Zeitstempel. Das ist alles, was ihr aus der Seite scrapen wolltet, euch vorab geparst übergeben.

Die Paginierung ist Keyset, nicht Offset, was das Detail ist, das am meisten zählt, wenn ihr je einen Scraper hattet, der still Datensätze übersprungen oder dupliziert hat, weil sich die zugrunde liegende Liste während des Crawls verschoben hat. Folgt der next-URL in jeder Antwort, bis sie null zurückkommt. Eine minimale Schleife in Python:

import requests

url = "https://www.wikiprompt.org/dataset/prompts?limit=500"

records = []

while url:

resp = requests.get(url).json()

records.extend(resp["records"])

url = resp.get("next")

print(len(records), "Prompts gezogen, null Seiten gerendert")

Keine Sleep-und-Retry-Logik, keine User-Agent-Rotation, keine Selektor-Wartung. Der gesamte Katalog, erledigt in einer Schleife, die in Sekunden läuft, weil jede Antwort edge-gecacht und CORS-aktiviert ist (Access-Control-Allow-Origin: *) für direkte Browser-Nutzung ebenfalls.

Was ihr bekommt, das Scraping euch nie gab

Über die Geschwindigkeit hinaus trägt der Datensatz Signal, das nie auf der gerenderten Seite in nutzbarer Form war. Nehmt einen handgeschnittenen Linolschnitt-Reiseplakat-Prompt: Der Datensatz enthält das style-Array und das Seitenverhältnis direkt in metadata, die Art von Feld, die ihr sonst aus einem Bild ableiten müsst. Oder ein redaktionelles Porträt, das um eine architektonische Treppe gebaut ist, wo das model-Feld euch genau sagt, was es erzeugt hat, ohne dass ihr aus dem Bildstil raten müsst. Oder einen Prompt zum Verwandeln einer Figur in eine Spinnentierform, der mit seiner Qualitätsbewertung bereits angehängt kommt, etwas, das kein Scraper, der die sichtbare Seite liest, je sauber aufnehmen würde.

Jeder Datensatz behält auch original_source, den Link zurück zum ursprünglichen Tweet oder Post, von dem der Prompt stammt. Das ist das Stück, das Wiederverwendung legitim macht: wikiprompt.org aggregiert öffentliche Prompts, die von anderen Leuten geschrieben wurden, wir sind nicht der Autor des zugrunde liegenden Inhalts, und ihr seid es auch nicht, wenn ihr aus dem Datensatz zieht. Wenn ihr diese Datensätze nutzt, gebt sowohl wikiprompt.org als Quelle an als auch original_source für den einzelnen Prompt. Wir beanspruchen keine formale Lizenz über die Posts anderer Leute, wir sind nur der Katalog, und wir bitten euch, es auch so zu behandeln.

Wenn ihr etwas Engeres als den ganzen Dump braucht

Der vollständige Datensatz ist für Bulk-Nutzung, Trainingssets, Analysen, Spiegel. Wenn ihr tatsächlich nur eine Live-Abfrage braucht, nutzt die Such-API statt /search zu scrapen, sie gibt dasselbe strukturierte JSON für eine einzelne Abfrage zurück, ohne dass ihr die UI überhaupt anfassen müsst. Wenn ihr einen Agenten baut, stellt der MCP-Server Suche, Abruf und sogar Einreichung als Werkzeuge bereit. Und wenn ihr herausfinden wollt, was überhaupt im Rahmen ist, bevor ihr Code schreibt, ist llms.txt die Karte.

Die eigentliche Bitte

Das Scrapen von /search gibt euch eine schlechtere Kopie von Daten, die wir bereits kostenlos herausgeben, langsamer, fragiler und schwerer für unsere Server, als es sein müsste. Der Datensatz gibt euch denselben Inhalt, strukturiert, vernünftig paginiert, kontinuierlich aktualisiert, und er kostet euch einen einzigen curl-Befehl zum Starten.

Wenn ihr gerade einen Scraper gegen wikiprompt.org wartet, sind wir nicht genervt, wir verstehen es, die meisten Seiten bieten das nicht an. Wir tun es. Richtet euer Skript stattdessen auf /dataset/prompts, löscht den Scraper und verbringt die Zeit, die ihr zurückbekommt, mit dem, was ihr eigentlich bauen wolltet.