Najlepsze ustawienia Cloudflare /crawl dla dowolnej strony internetowej

Endpoint /crawl w ramach Cloudflare Browser Rendering to jeden z najszybszych sposobow na ekstrakcje tresci stron internetowych na duzej skali, ale domyslne ustawienia nie sa optymalne dla wiekszosci zastosowan. Po przeprowadzeniu crawli na dziesiaatkach witryn – od sklepow Shopify, przez aplikacje SPA w React, po strony dokumentacji – oto ustawienia, ktore konsekwentnie daja najlepsze wyniki.

Ten przewodnik opisuje, co robi kazde ustawienie, kiedy je zmieniac i jakie konkretne polecenia najlepiej sprawdzaja sie dla popularnych typow stron.

Najwazniejsza decyzja: tryb renderowania

Kazdy crawl zaczyna sie od jednego wyboru: czy Cloudflare powinien zaladowac strone w przegladarce bezglowej, czy po prostu pobrac surowy HTML?

render: false (--no-render) pobiera HTML bez wykonywania JavaScript. Jest szybki, darmowy w okresie beta i generuje czysty wynik dla kazdej strony, ktora serwuje tresc w poczatkowej odpowiedzi HTML.

render: true (domyslny) laduje kazda strone w bezglowej instancji Chromium, wykonuje JavaScript, czeka az strona sie ustabilizuje, a nastepnie wyodrebnia tresc. Jest wolniejszy, zuzywa godziny przegladarki i kosztuje po przekroczeniu darmowych 10 godzin/miesiac.

Kiedy kazdy tryb ma sens

W naszych testach sklepy Shopify zwracaly okolo 90% identycznej tresci w obu trybach renderowania. Dodatkowa tresc z renderowania to glownie dynamiczne elementy interfejsu, takie jak szuflady koszyka i widgety rekomendacji, a nie istotne dane produktowe. Pelne porownanie trybow renderowania z benchmarkami bezposrednimi omawiamy w artykule Zalety i wady endpointu Cloudflare Crawl dla sklepow Shopify.

Zasada ogolna: zacznij od --no-render. Jesli w wynikach brakuje potrzebnej tresci, przelacz sie na tryb renderowania.

Wykrywanie adresow URL: mapy witryn vs linki

Flaga --source kontroluje sposob, w jaki Cloudflare znajduje strony do crawlowania.

--source sitemaps odczytuje plik sitemap.xml witryny i crawluje tylko adresy URL w nim wymienione. Jest to przewidywalne, obejmuje strony, ktore wlasciciel witryny uwaza za kanoniczne, i pozwala uniknac crawlowania zduplikowanych lub malo wartosciowych stron.

--source links zaczyna od podanego adresu URL i podaza za linkami <a href> znajdowanymi na kazdej stronie. Wykrywa strony w sposob, w jaki robilaby to wyszukiwarka, ale moze pominac osierocone strony i moze wchodzic w paginacje, filtry lub inne malo wartosciowe wzorce adresow URL.

--source all (domyslny) laczy obie metody.

Ktore wybrac

Uzyj --source sitemaps, gdy strona ma kompletna, dobrze utrzymywana mape witryny. Wiekszosc stron Shopify i WordPress ja posiada. Jest to najbardziej niezawodna opcja do ekstrakcji tresci calej witryny.

Uzyj --source links lub all, gdy mapa witryny jest brakujaca, niekompletna lub gdy chcesz specjalnie przeprowadzic audyt wewnetrznej struktury linkow witryny.

Blokowanie zasobow dla crawli render-true

To pojedyncza najskuteczniejsza optymalizacja dla crawli render-true. Domyslnie przegladarka bezglowa laduje kazdy obraz, czcionke, arkusz stylow i plik multimedialny na kazdej stronie. Jest to marnotrawstwo, gdy potrzebujesz tylko tresci tekstowej.

Dodaj --block-resources image media font stylesheet do kazdego crawla render-true. Efekt jest znaczacy:

• Szybkosc: czas crawla spada z okolo 7 sekund na strone do okolo 2 sekund na strone
• Koszt: zuzycie godzin przegladarki zmniejsza sie o 60-70%
• Niezawodnosc: strony, ktore zawieszalyby sie w nieskonczonosc czekajac na wolne zasoby CDN, teraz koncza sie normalnie

Przegladarka nadal wykonuje JavaScript i buduje DOM. Po prostu pomija pobieranie zasobow, ktore nie wplywaja na tresc tekstowa.

Warunek oczekiwania

Flaga --wait-until mowi przegladarce, kiedy przestac czekac i wyodrebniac tresc. Domyslna wartosc czeka na zakonczenie calej aktywnosci sieciowej, co jest wolne i niepotrzebne do ekstrakcji tresci.

--wait-until domcontentloaded mowi przegladarce, aby wyodrebnila tresc, gdy tylko DOM bedzie gotowy. Do ekstrakcji tekstu jest to prawie zawsze wystarczajace. JavaScript ladujacy tresc zostanie juz wykonany, ale pingi analityczne w tle i wywolania sieci reklamowych nie beda opozniac crawla.

Zalecane polecenia wedlug typu strony

Sklep Shopify (cala witryna)

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

Szybki, darmowy i obejmuje caly katalog produktow. Mapy witryn Shopify sa kompleksowe, wiec --source sitemaps daje pelne pokrycie bez crawlowania paginowanych kolekcji czy stron wynikow wyszukiwania.

Sklep Shopify (tylko produkty)

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

Flaga --include-patterns ogranicza crawl do adresow URL pasujacych do podanego wzorca. Przydatna, gdy potrzebujesz tylko stron produktowych i chcesz pominac kolekcje, wpisy na blogu i strony z regulaminami.

WordPress lub blog statyczny

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

Te same ustawienia co dla Shopify. Strony WordPress sa renderowane po stronie serwera i maja niezawodne mapy witryn. Generatory stron statycznych (Hugo, Jekyll, Eleventy, Astro) produkuja gotowy HTML, wiec render-false przechwytuje wszystko.

Aplikacja SPA React lub Vue

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 jest domyslny, wiec nie jest potrzebna dodatkowa flaga. Kluczowe dodatki to --block-resources i --wait-until domcontentloaded. Bez nich crawl bedzie wolny i kosztowny.

Jesli aplikacja SPA nie ma mapy witryny, przelacz sie na --source links.

Strona dokumentacji

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

Strony dokumentacji czesto maja glebokie struktury linkow. Zwieksz --depth, aby sledzic zagniezdzone hierarchie stron. Uzyj --exclude-patterns, aby pominac strony z logiem zmian, zarchiwizowane wersje lub inna tresc, ktorej nie potrzebujesz.

Benchmarki wydajnosci

Te liczby pochodza z rzeczywistych crawli sklepow Shopify i e-commerce w marcu 2026 roku. Nazwy witryn zostaly zanonimizowane.

Kluczowe wzorce z danych:

• No-render jest 5 do 10 razy szybszy niz render-true dla tej samej witryny
• No-render zuzywa zero czasu przegladarki (darmowy w okresie beta)
• Rzeczywisty czas skaluje sie liniowo z liczba stron dla crawli no-render
• Witryny z dyrektywami crawl-delay w robots.txt beda wolne niezaleznie od ustawien, poniewaz crawler je respektuje

Optymalizacja kosztow

Plan Workers Paid kosztuje 5$/miesiac. Poza tym koszty wynikaja z godzin przegladarki zuzywanych przez crawle render-true.

Darmowy poziom: 10 godzin przegladarki/miesiac. Crawl render-true na 500 stronach z blokowaniem zasobow zuzywa okolo 15-20 minut czasu przegladarki. Mozesz przeprowadzic ponad 30 zoptymalizowanych crawli miesiecznie w ramach darmowego poziomu.

Bez blokowania zasobow: ten sam crawl na 500 stronach moze zuzyc ponad 60 minut czasu przegladarki, co zmniejsza twoja darmowa pojemnosc do okolo 10 crawli miesiecznie.

Crawle no-render sa darmowe w okresie beta. Dla stron renderowanych po stronie serwera nie ma powodu, aby uzywac render-true.

Wzor na koszt

Browser cost = (pages x seconds_per_page) / 3600 x $0.09

Przy 2 sekundach na strone (zoptymalizowany render-true): 500 stron = 0,28 godziny = 0,025$

Przy 7 sekundach na strone (niezoptymalizowany): 500 stron = 0,97 godziny = 0,087$

Roznica jest niewielka na jeden crawl, ale kumuluje sie przy codziennym lub tygodniowym crawlowaniu wielu witryn.

Limity, ktore warto znac

Czeste problemy i rozwiazania

Bledy 403 na wiekszosci stron: witryna ma ochrone przed botami (Cloudflare Bot Management, Akamai, Datadome). Nie mozna tego obejsc przez endpoint /crawl. Crawl zakonczy sie, ale wiekszosc stron zwroci bledy.

Crawl render-true zawiesza sie pod koniec: jedna lub wiecej stron ma wolno ladujace sie zasoby blokujace przegladarke. Dodaj --block-resources image media font stylesheet i --wait-until domcontentloaded.

Brakujaca tresc w trybie no-render: strona laduje tresc przez JavaScript. Przelacz sie na render-true z optymalizacjami blokowania zasobow i oczekiwania.

Skrypt ulega awarii w trakcie crawla: zadanie crawl kontynuuje dzialanie na serwerach Cloudflare. Sprawdz status i pobierz wyniki, gdy sie zakonczy:

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

Puste wyniki ze zrodla sitemaps: mapa witryny moze byc brakujaca lub zablokowana. Przelacz sie na --source links lub --source all.

Znane ograniczenia

Przed zbudowaniem przepywu pracy wokol endpointu /crawl, nalezy byc swiadomym tych ograniczen:

• Bledne rozwiazywanie wzglednych adresow URL: konwerter markdown Cloudflare nieprawidlowo rozwiazuje wzgledne adresy URL, takie jak //www.example.com/path, poprzedzajac je adresem URL strony. Tworzy to znieksztalcone sciezki w wynikach, szczegolnie na stronach Shopify.
• Tresc szablonowa na kazdej stronie: menu nawigacyjne, mega menu i stopki pojawiaja sie w formacie markdown na kazdej stronie. Dla typowej strony Shopify okolo 90% tresci na strone to powtarzajaca sie tresc szablonowa. Zobacz nasza analize wskaznikow tresci szablonowej na prawdziwych crawlach Shopify.
• Brak ekstrakcji danych strukturalnych: dane JSON-LD, schema.org i OpenGraph nie sa parsowane w trybie no-render. Render-true przechwytuje podstawowe tagi OG w metadanych, ale nie pelny schemat.
• Brak wykrywania bledow 404: crawl przetwarza tylko aktywne adresy URL. Martwe linki i uszkodzone linki wewnetrzne nie sa raportowane.
• Pojedynczy poczatkowy adres URL: API akceptuje jeden adres URL i rozchodzi sie na zewnatrz. Nie akceptuje listy adresow URL. Do wsadowego pobierania adresow URL uzyj zamiast tego endpointow /markdown lub /scrape.

Czesto zadawane pytania

Czy powinienem uzywac render true czy render false w Cloudflare /crawl?

Uzyj render false (--no-render) dla stron renderowanych po stronie serwera, takich jak Shopify, WordPress i strony statyczne. Uzyj render true tylko dla aplikacji jednostronicowych zbudowanych w React, Vue lub Angular, gdzie tresc ladowana jest przez JavaScript. W testach sklepy Shopify zwracaly okolo 90% identycznej tresci w obu trybach.

Ile kosztuje Cloudflare Browser Rendering /crawl?

Plan Workers Paid kosztuje 5$/miesiac. Crawle w trybie render-false nie zuzywaja czasu przegladarki i sa darmowe w okresie beta. Crawle w trybie render-true zuzywaja godziny przegladarki: 10 godzin/miesiac jest darmowych, potem 0,09$/godzine. Blokowanie obrazow, czcionek i arkuszy stylow podczas crawli render-true znaczaco zmniejsza czas przegladarki.

Jakie jest najlepsze zrodlo wykrywania adresow URL dla Cloudflare /crawl?

Uzyj --source sitemaps dla stron z kompletnymi mapami witryn, takich jak Shopify i WordPress. Daje to przewidywalne, pelne pokrycie. Uzyj --source links lub all, gdy mapa witryny moze byc niekompletna lub chcesz odkrywac strony w sposob, w jaki robilaby to wyszukiwarka.

Dlaczego moj crawl Cloudflare render-true zawiesza sie na ostatnich stronach?

Strony z wolno ladujacymi sie zasobami, takimi jak duze obrazy lub skrypty firm trzecich, moga blokowac przegladarke bezglowa na ponad 60 sekund. Napraw to, dodajac --block-resources image media font stylesheet i --wait-until domcontentloaded do polecenia crawla.