Cena wyjściowa to najtańsza rzecz na stronie
Każde API do scrapingu zaczyna od podobnej liczby. Od dziewięciu centów za 1000 zapytań. Od dolara. Od 1,50 USD. Czysto, tanio, łatwo wrzucić do oferty dla klienta.
Ta liczba jest prawdziwa. To jednocześnie cena za jedno zapytanie, którego prawie nigdy nie wyślesz: zwykły HTTP GET do witryny, której zupełnie nie obchodzi, kto pyta.
Witryny, za których scraping faktycznie dostajesz pieniądze, dbają o to bardzo. W momencie, gdy cel wymaga renderowania strony lub proxy residential, podana stawka przestaje obowiązywać i wchodzi mnożnik. Cena wyjściowa to dolny pułap. Rachunek ląduje znacznie wyżej, a większość kupujących dowiaduje się gdzie dopiero po pierwszej fakturze.
Jak faktycznie działa ten mnożnik
Otwórz dokumentację kredytów niemal dowolnego API, a zobaczysz tę samą tabelę. Zwykły request kosztuje 1 kredyt. Włącz renderowanie JavaScript i robi się 5. Poproś o proxy residential lub premium i masz 10. Potrzebujesz obu, bo strona sprawdza, kto wysyła zapytanie, i płacisz 25. Najwyższy poziom ScrapingBee sięga 75 kredytów za pojedynczą stronę (ScrapingBee docs, październik 2026).
ScraperAPI wycenia to w tym samym układzie: renderowanie 10 kredytów, proxy premium 10, oba naraz 25, poziom ultra 30, a niektóre chronione domeny 10 same z siebie (ScraperAPI docs). ZenRows ląduje w tym samym miejscu: 1 za standard, 5 za JS, 10 za premium, 25 za połączenie obu (ZenRows pricing).
Oto część, której nikt nie umieszcza na stronie marketingowej. Dostawcy zbiegają się na szczycie tabeli. Możesz wybrać tanie API albo drogie, ale gdy witryna stawia opór, oba naliczają około 25 razy więcej niż ich własna stawka bazowa. Liczba, na podstawie której porównywałeś dostawców, nie jest liczbą decydującą o Twoim rachunku.
Reklamowany pakiet to zły pakiet
W którym pakiecie w takim razie faktycznie mieści się Twoja praca?
Zyte, które sprzedaje w modelu pakietowym, opublikowało własne zestawienie: około 80% stron internetowych znajduje się w dwóch najprostszych pakietach, a tylko około 0,1% zmienia pakiet w danym kwartale (Zyte, 2026). Na papierze brzmi to uspokajająco. Większość sieci jest tania.
Spójrz na to jednak z drugiej strony. Tanie 80% jest tanie u każdego dostawcy. Nikt nie buduje na tym przewagi. Zadania, za które klient płaci freelancerowi lub software house'owi (katalogi sklepów, ceny biletów, oferty na marketplace'ach, cokolwiek użytecznego komercyjnie), dotyczą dokładnie tych witryn, które należą do drogiej mniejszości. Z badań samego Zyte wynika, że 18,5% czołowych stron znajduje się za dedykowanym systemem ochrony (Zyte State of Web Access).
Na tym polega pułapka. Cena wyjściowa dotyczy zadań, do których nikt cię nie zatrudnia. Cena 25x dotyczy tych, które faktycznie realizujesz. (To ta sama kalkulacja jednostkowa, przez którą ekstrakcja przez LLM przestaje się opłacać na dużą skalę, gdy rośnie wolumen).
Najniższy próg wejścia po cichu znika
Podczas gdy koszt pojedynczej strony rósł, tani start stał się trudniejszy do znalezienia.
ScrapingBee zlikwidowało plan za 19 USD w październiku 2026 roku; próg wejścia wynosi teraz 49 USD miesięcznie. Zestawienie rynkowe samego Firecrawl wskazuje, że 49 USD bez stałego darmowego pakietu stało się standardowym punktem wyjścia. Oxylabs połączyło swoje produkty scraperowe w jedną subskrypcję. Decodo i Bright Data przeszły na rozliczanie za request i za rekord, gdzie licznik bije przy każdym wywołaniu (cennik Bright Data Web Scraper).
Żadne z tych rozwiązań nie uderza w klienta korporacyjnego z podpisaną umową. Trafia to we freelancera i dwuosobowy zespół: ludzi, którzy w tym miesiącu muszą obsłużyć jedną stronę dla jednego klienta i nie mogą rozłożyć planu za 500 USD na setkę zleceń. (Przeanalizowaliśmy, kto faktycznie ponosi ten ciężar, w tekście o ukrytych kosztach utrzymywania własnych scraperów).
Co to oznacza dla każdego wyceniającego scraping
Przestań wyceniać na podstawie ceny wyjściowej. Wyceniaj na podstawie wymagań celu.
Zanim podasz wycenę klientowi, przeanalizuj konkretne strony w projekcie i podziel je: które zwracają użyteczny HTML przy zwykłym request, które wymagają renderowania strony, a które potrzebują dodatkowo residential proxy. Ta proporcja, a nie stawka z nagłówka oferty, stanowi twój koszt. Zadanie obejmujące w 90% proste strony i w 10% trudne jest tanie. Zadanie oparte wyłącznie na chronionych sklepach online to 25-krotność kwoty z twojej oferty, a różnicę pokryjesz z własnej kieszeni.
Przelicz to raz, a różnica stanie się uderzająca. Załóżmy, że klient potrzebuje 50 000 stron produktów miesięcznie ze sklepu, który wymaga renderowania strony i residential proxy. Przy 25 kredytach za stronę daje to 1,25 miliona kredytów. W API, które promuje tysiąc kredytów za dolara, wstępna kalkulacja w twojej głowie wynosiła 50 USD. Rzeczywisty koszt na fakturze to 1 250 USD. Te same strony, ten sam miesiąc, 25-krotna różnica, a cennik w żadnym miejscu nie zestawił tego mnożnika z główną stawką.
Następnie sprawdź zasady rozliczania błędów, ponieważ różnią się one między dostawcami i nigdy nie trafiają do nagłówków. Firecrawl pobiera jeden kredyt za stronę zwracającą 403 lub 404, a nie pobiera nic, gdy request nie zwraca żadnego wyniku (cennik Firecrawl). Inni uznają każdy kod 2xx lub 4xx za sukces i naliczają opłatę. W przypadku celu, który często odrzuca połączenia, ten jeden zapis w regulaminie może kosztować więcej niż samo renderowanie.
Prawdziwym wskaźnikiem pod tym wszystkim nie jest plan miesięczny. To koszt pojedynczego wywołania, który możesz sprawdzić po fakcie i powiązać z konkretnym requestem, który go wygenerował. Plan to tylko szacunek. Koszt per call to rachunek, i to jedyna rzecz, na której można faktycznie oprzeć fakturę dla klienta. (Wersję z podziałem na modele znajdziesz w naszym zestawieniu rozliczania za GB a za stronę.)
Dokąd to zmierza
Rynek ulega standaryzacji. Podstawowe plany znikają. W ciągu roku stawka bazowa powie ci jeszcze mniej niż teraz, ponieważ każdy poważny dostawca zaoferuje niemal tę samą drabinkę 1-5-10-25 i te same obietnice rozliczania tylko za sukces.
Różnica polega na tym, czy widzisz koszt danego wywołania i płacisz wyłącznie za te, które zadziałały. W FourA umieszczamy koszt każdego requestu bezpośrednio w response, dzięki czemu możesz wycenić zadanie na podstawie faktycznych operacji, zamiast zgadywać w oparciu o plan. Następnym razem, gdy dostawca poda stawkę, właściwe pytanie nie brzmi, jak niska ona jest. Pytanie brzmi, co się z nią stanie w ułamku sekundy, gdy serwis zacznie blokować ruch.