Die besten Cloudflare /crawl-Einstellungen für jede Website

Der Cloudflare Browser Rendering /crawl-Endpoint ist eine der schnellsten Möglichkeiten, Website-Inhalte in großem Umfang zu extrahieren, aber die Standardeinstellungen sind für die meisten Anwendungsfälle nicht optimal. Nach der Durchführung von Crawls auf Dutzenden von Websites – von Shopify-Shops über React-SPAs bis hin zu Dokumentationsseiten – sind dies die Einstellungen, die durchgehend die besten Ergebnisse liefern.

Diese Anleitung behandelt, was jede Einstellung bewirkt, wann sie geändert werden sollte, und die spezifischen Befehle, die für gängige Website-Typen am besten funktionieren.

Die wichtigste Entscheidung: Render-Modus

Jeder Crawl beginnt mit einer Wahl: Soll Cloudflare die Seite in einem Headless-Browser laden oder nur das rohe HTML abrufen?

render: false (--no-render) ruft das HTML ab, ohne JavaScript auszuführen. Es ist schnell, während der Beta-Phase kostenlos und erzeugt saubere Ausgaben für jede Website, die Inhalte in der initialen HTML-Antwort liefert.

render: true (Standardeinstellung) lädt jede Seite in einer Headless-Chromium-Instanz, führt JavaScript aus, wartet, bis die Seite geladen ist, und extrahiert dann den Inhalt. Dies ist langsamer, verbraucht Browser-Stunden und kostet Geld nach den kostenlosen 10 Stunden/Monat.

Wann welcher Modus sinnvoll ist

In unseren Tests lieferten Shopify-Websites in beiden Render-Modi etwa 90 % identische Inhalte. Die zusätzlichen Inhalte durch das Rendering waren größtenteils dynamische UI-Elemente wie Warenkorb-Seitenleisten und Empfehlungs-Widgets, keine aussagekräftigen Produktdaten. Den vollständigen Render-Modus-Vergleich mit direkten Benchmarks behandeln wir in Vor- und Nachteile des Cloudflare Crawl Endpoints bei Shopify-Shops.

Die Faustregel: Beginnen Sie mit --no-render. Wenn die Ergebnisse Inhalte vermissen lassen, die Sie benötigen, wechseln Sie zum Render-Modus.

URL-Erkennung: Sitemaps vs. Links

Das --source-Flag steuert, wie Cloudflare Seiten zum Crawlen findet.

--source sitemaps liest die sitemap.xml der Website und crawlt nur die dort aufgelisteten URLs. Dies ist vorhersehbar, deckt die Seiten ab, die der Website-Betreiber als kanonisch betrachtet, und vermeidet das Crawlen von doppelten oder minderwertigen Seiten.

--source links beginnt an der angegebenen URL und folgt <a href>-Links, die auf jeder Seite gefunden werden. Damit werden Seiten so entdeckt, wie es eine Suchmaschine tun würde, aber verwaiste Seiten können übersehen werden, und der Crawler kann in Paginierung, Filter oder andere minderwertige URL-Muster geraten.

--source all (Standardeinstellung) kombiniert beide Methoden.

Was zu verwenden ist

Verwenden Sie --source sitemaps, wenn die Website eine vollständige, gut gepflegte Sitemap hat. Die meisten Shopify- und WordPress-Websites haben das. Dies ist die zuverlässigste Option für die vollständige Inhaltsextraktion der Website.

Verwenden Sie --source links oder all, wenn die Sitemap fehlt, unvollständig ist oder Sie gezielt die interne Linkstruktur der Website überprüfen möchten.

Ressourcenblockierung für Render-True-Crawls

Dies ist die wirkungsvollste einzelne Optimierung für Render-true-Crawls. Standardmäßig lädt der Headless-Browser jedes Bild, jede Schriftart, jedes Stylesheet und jede Mediendatei auf jeder Seite. Das ist verschwenderisch, wenn Sie nur den Textinhalt benötigen.

Fügen Sie --block-resources image media font stylesheet zu jedem Render-true-Crawl hinzu. Die Auswirkung ist erheblich:

• Geschwindigkeit: Die Crawl-Zeit sinkt von etwa 7 Sekunden pro Seite auf etwa 2 Sekunden pro Seite
• Kosten: Der Verbrauch von Browser-Stunden wird um 60-70 % reduziert
• Zuverlässigkeit: Seiten, die endlos auf langsame CDN-Assets warten würden, werden nun normal abgeschlossen

Der Browser führt weiterhin JavaScript aus und baut den DOM auf. Er überspringt lediglich das Herunterladen von Assets, die den Textinhalt nicht beeinflussen.

Die Wartebedingung

Das --wait-until-Flag teilt dem Browser mit, wann er aufhören soll zu warten und den Inhalt extrahieren soll. Die Standardeinstellung wartet, bis alle Netzwerkaktivität beendet ist, was langsam und für die Inhaltsextraktion unnötig ist.

--wait-until domcontentloaded weist den Browser an, den Inhalt zu extrahieren, sobald der DOM bereit ist. Für die Textextraktion ist dies fast immer ausreichend. JavaScript, das Inhalte lädt, wurde bereits ausgeführt, aber Hintergrund-Analytics-Pings und Werbenetzwerk-Aufrufe verzögern den Crawl nicht.

Empfohlene Befehle nach Website-Typ

Shopify-Shop (gesamte Website)

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --source sitemaps \
  -o results.json

Schnell, kostenlos und deckt den gesamten Produktkatalog ab. Shopify-Sitemaps sind umfassend, sodass --source sitemaps vollständige Abdeckung bietet, ohne in paginierte Kollektionen oder Suchergebnisseiten zu crawlen.

Shopify-Shop (nur Produkte)

python crawl.py run https://example.com \
  --limit 1000 \
  --format markdown \
  --no-render \
  --include-patterns "https://example.com/products/**" \
  -o products.json

Das --include-patterns-Flag beschränkt den Crawl auf URLs, die dem angegebenen Muster entsprechen. Nützlich, wenn Sie nur Produktseiten benötigen und Kollektionen, Blogbeiträge und Richtlinienseiten überspringen möchten.

WordPress oder statischer Blog

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --source sitemaps \
  -o results.json

Gleiche Einstellungen wie bei Shopify. WordPress-Websites werden serverseitig gerendert und haben zuverlässige Sitemaps. Statische Website-Generatoren (Hugo, Jekyll, Eleventy, Astro) erzeugen vorgeneriertes HTML, sodass render-false alles erfasst.

React- oder Vue-SPA

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --source sitemaps \
  --block-resources image media font stylesheet \
  --wait-until domcontentloaded \
  -o results.json

Render-true ist die Standardeinstellung, daher ist kein zusätzliches Flag erforderlich. Die entscheidenden Ergänzungen sind --block-resources und --wait-until domcontentloaded. Ohne diese wird der Crawl langsam und teuer.

Wenn die SPA keine Sitemap hat, wechseln Sie zu --source links.

Dokumentationsseite

python crawl.py run https://docs.example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --depth 5 \
  --exclude-patterns "*/changelog/**" "*/archive/**" \
  -o docs.json

Dokumentationsseiten haben oft tiefe Linkstrukturen. Erhöhen Sie --depth, um verschachtelten Seitenhierarchien zu folgen. Verwenden Sie --exclude-patterns, um Changelog-Seiten, archivierte Versionen oder andere nicht benötigte Inhalte zu überspringen.

Performance-Benchmarks

Diese Zahlen stammen aus realen Crawls über Shopify- und E-Commerce-Shops im März 2026. Website-Namen wurden anonymisiert.

Wesentliche Muster aus den Daten:

• No-render ist 5- bis 10-mal schneller als render-true für dieselbe Website
• No-render verbraucht keine Browser-Zeit (kostenlos in der Beta-Phase)
• Die Gesamtzeit skaliert linear mit der Seitenzahl bei No-render-Crawls
• Websites mit robots.txt-Crawl-Delay-Anweisungen sind unabhängig von den Einstellungen langsam, da der Crawler diese respektiert

Kostenoptimierung

Der Workers-Paid-Plan kostet 5 $/Monat. Darüber hinaus entstehen Kosten durch Browser-Stunden, die von Render-true-Crawls verbraucht werden.

Kostenloser Tarif: 10 Browser-Stunden/Monat. Ein Render-true-Crawl mit 500 Seiten und Ressourcenblockierung verbraucht etwa 15-20 Minuten Browser-Zeit. Sie können über 30 optimierte Crawls pro Monat innerhalb des kostenlosen Tarifs durchführen.

Ohne Ressourcenblockierung: Derselbe 500-Seiten-Crawl könnte über 60 Minuten Browser-Zeit verbrauchen, was Ihre kostenlose Kapazität auf etwa 10 Crawls pro Monat reduziert.

No-render-Crawls sind kostenlos während der Beta-Phase. Für serverseitig gerenderte Websites gibt es keinen Grund, render-true zu verwenden.

Kostenformel

Browser-Kosten = (Seiten x Sekunden_pro_Seite) / 3600 x 0,09 $

Bei 2 Sekunden pro Seite (optimiertes render-true): 500 Seiten = 0,28 Stunden = 0,025 $

Bei 7 Sekunden pro Seite (nicht optimiert): 500 Seiten = 0,97 Stunden = 0,087 $

Der Unterschied ist pro Crawl gering, summiert sich aber bei täglichen oder wöchentlichen Crawls über mehrere Websites.

Wichtige Limits

Häufige Probleme und Lösungen

403-Fehler auf den meisten Seiten: Die Website hat Bot-Schutz (Cloudflare Bot Management, Akamai, Datadome). Dies kann über den /crawl-Endpoint nicht umgangen werden. Der Crawl wird abgeschlossen, aber die meisten Seiten geben Fehler zurück.

Render-true-Crawl hängt gegen Ende: Eine oder mehrere Seiten haben langsam ladende Ressourcen, die den Browser blockieren. Fügen Sie --block-resources image media font stylesheet und --wait-until domcontentloaded hinzu.

Fehlende Inhalte im No-render-Modus: Die Website lädt Inhalte per JavaScript. Wechseln Sie zu render-true mit den Optimierungen für Ressourcenblockierung und Wartebedingung.

Skript stürzt während des Crawls ab: Der Crawl-Job läuft weiterhin auf den Servern von Cloudflare. Überprüfen Sie den Status und rufen Sie die Ergebnisse ab, wenn er fertig ist:

python crawl.py status <job_id>
python crawl.py results <job_id> -o out.json

Leere Ergebnisse bei Sitemaps-Quelle: Die Sitemap der Website fehlt möglicherweise oder ist blockiert. Wechseln Sie zu --source links oder --source all.

Bekannte Einschränkungen

Bevor Sie einen Workflow rund um den /crawl-Endpoint aufbauen, beachten Sie diese Einschränkungen:

• Fehlerhafte relative URL-Auflösung: Der Markdown-Konverter von Cloudflare löst relative URLs wie //www.example.com/path fehlerhaft auf, indem er die Seiten-URL voranstellt. Dies erzeugt fehlerhafte Pfade in der Ausgabe, insbesondere bei Shopify-Websites.
• Boilerplate-Inhalte auf jeder Seite: Navigationsmenüs, Mega-Menüs und Footer erscheinen im Markdown für jede Seite. Bei einer typischen Shopify-Website sind etwa 90 % des Inhalts pro Seite wiederholter Template-Inhalt. Siehe unsere Analyse der Boilerplate-Anteile bei realen Shopify-Crawls.
• Keine strukturierte Datenextraktion: JSON-LD, schema.org und OpenGraph-Daten werden im No-render-Modus nicht geparst. Render-true erfasst grundlegende OG-Tags in den Metadaten, aber kein vollständiges Schema.
• Keine 404-Erkennung: Der Crawl verarbeitet nur aktive URLs. Tote Links und defekte interne Links werden nicht gemeldet.
• Einzelne Start-URL: Die API akzeptiert eine URL und crawlt von dort ausgehend. Sie akzeptiert keine URL-Liste. Für das Abrufen mehrerer URLs verwenden Sie stattdessen die /markdown- oder /scrape-Endpoints.

Häufig gestellte Fragen

Sollte ich render true oder render false mit Cloudflare /crawl verwenden?

Verwenden Sie render false (--no-render) für serverseitig gerenderte Websites wie Shopify, WordPress und statische Seiten. Verwenden Sie render true nur für Single-Page-Apps, die mit React, Vue oder Angular erstellt wurden, bei denen Inhalte per JavaScript geladen werden. In unseren Tests lieferten Shopify-Websites in beiden Modi etwa 90 % identische Inhalte.

Was kostet Cloudflare Browser Rendering /crawl?

Ein Workers-Paid-Plan kostet 5 $/Monat. Render-false-Crawls verbrauchen keine Browser-Zeit und sind in der Beta-Phase kostenlos. Render-true-Crawls verbrauchen Browser-Stunden: 10 Stunden/Monat sind kostenlos, dann 0,09 $/Stunde. Das Blockieren von Bildern, Schriftarten und Stylesheets bei Render-true-Crawls reduziert die Browser-Zeit erheblich.

Was ist die beste URL-Erkennungsquelle für Cloudflare /crawl?

Verwenden Sie --source sitemaps für Websites mit vollständigen Sitemaps wie Shopify und WordPress. Dies bietet vorhersehbare, vollständige Abdeckung. Verwenden Sie --source links oder all, wenn die Sitemap unvollständig sein könnte oder Sie Seiten so entdecken möchten, wie es eine Suchmaschine tun würde.

Warum hängt mein Cloudflare-Render-true-Crawl bei den letzten Seiten?

Seiten mit langsam ladenden Ressourcen wie großen Bildern oder Drittanbieter-Skripten können den Headless-Browser für über 60 Sekunden blockieren. Beheben Sie dies, indem Sie --block-resources image media font stylesheet und --wait-until domcontentloaded zu Ihrem Crawl-Befehl hinzufügen.