---
title: "هزینه وب اسکرپینگ: ساخت اسکرپر خودتان یا API اسکرپینگ؟"
description: "ابزارهای وب اسکرپینگ رایگان‌اند، اجرای آن‌ها نه. هشت قلم هزینه اسکرپر خودساخته، وزن اندازه‌گیری‌شده صفحه‌ها و زمانی که API اسکرپینگ ارزان‌تر تمام می‌شود."
url: https://proxynet.io/fa/blog/web-scraping-cost
date: 2026-11-09
author: "Acar Diveroli"
category: "وب اسکرپینگ, کاربردها"
lang: fa
---

# هزینه وب اسکرپینگ: ساخت اسکرپر خودتان یا API اسکرپینگ؟

یک مدیر محصول می‌پرسد جمع‌آوری قیمت از 60 فروشگاه اینترنتی در هر صبح چقدر هزینه دارد. توسعه‌دهنده پاسخ می‌دهد که Scrapy و Playwright رایگان‌اند، پس «چند روز کار». شش ماه بعد صورت‌حساب از جایی سر درمی‌آورد که هیچ‌کس برایش بودجه نگذاشته بود: تعمیر تجزیه‌گرها در هر هفته، فاکتور پروکسی‌ای که با هر تلاش دوباره بزرگ‌تر می‌شود و سروری پر از مرورگرهای headless.

در این نوشته هشت قلم هزینه یک اسکرپر خودساخته را فهرست می‌کنیم و می‌گوییم هر کدام چگونه رشد می‌کند، اندازه می‌گیریم که دریافت ساده HTML و بارگذاری کامل در مرورگر روی یک صفحه عمومی واقعاً چقدر داده منتقل می‌کنند، یک برآورد فرضی را گام‌به‌گام حساب می‌کنیم و آن را در برابر شیوه قیمت‌گذاری APIهای اسکرپینگ می‌گذاریم.

> **نکته: پاسخ کوتاه**
>
> وب اسکرپینگ با وجود رایگان بودن کتابخانه‌ها هزینه دارد: زمان مهندسی، نگهداری وقتی سایت‌ها تغییر می‌کنند، سرور (با رندر در مرورگر بسیار بیشتر)، ترافیک پروکسی، تلاش‌های دوباره که بقیه قلم‌ها را چند برابر می‌کنند، ذخیره‌سازی، پایش و بررسی حقوقی. API اسکرپینگ بیشتر این‌ها را در یک قیمت به‌ازای هر درخواست موفق جمع می‌کند. ساختن برای چند سایت پایدار و پرحجم با تیمی داخلی به‌صرفه است؛ API برای سایت‌های زیاد، صفحه‌های پر از JavaScript و پروژه‌های کوتاه؛ حجم بزرگ و پیوسته معمولاً به راه ترکیبی ختم می‌شود.

## آیا وب اسکرپینگ هزینه دارد؟

بله: نرم‌افزار رایگان است، اداره کردن آن نه. Scrapy، Beautiful Soup، Playwright و Puppeteer هزینه مجوز ندارند و نخستین اسکریپت روی یک لپ‌تاپ اجرا می‌شود. هزینه از جایی آغاز می‌شود که اسکریپت باید هر روز، روی صفحه‌های زیاد و از کشور درست اجرا شود و از بازطراحی بعدی سایت هدف جان سالم به در ببرد. شما بابت یک فرایند پول می‌دهید، نه یک ابزار.

API اسکرپینگ تغییر می‌دهد که چه کسی کدام قلم را می‌پردازد: ارائه‌دهنده مرورگرها، پروکسی‌ها و تلاش‌های دوباره را اداره می‌کند و به‌ازای هر صفحه تحویل‌شده هزینه می‌گیرد. سازوکار چنین سرویسی در [API وب اسکرپینگ چیست؟](/fa/blog/what-is-a-web-scraping-api) آمده است؛ این نوشته به پول می‌پردازد.

## ساختن و اداره اسکرپر خودتان چقدر هزینه دارد؟

یک اسکرپر خودساخته هشت قلم هزینه دارد و فقط اولی یک بار پرداخت می‌شود.

1. **زمان مهندسی برای ساختن.** دریافت‌کننده (fetcher)، یک تجزیه‌گر برای هر سایت، زمان‌بند، ذخیره‌سازی، آزمون‌ها؛ این قلم با تعداد سایت‌های متفاوت رشد می‌کند، چون هر چیدمان تجزیه‌گر خودش را لازم دارد.

2. **نگهداری وقتی سایت‌ها تغییر می‌کنند.** هزینه‌ای که فراموش می‌شود. یک بازطراحی، تغییر نام یک کلاس CSS، یک پنجره رضایت کوکی تازه یا محافظت سخت‌گیرانه‌تر در برابر ربات‌ها تجزیه‌گر را یک‌شبه از کار می‌اندازد و داده بی‌صدا قطع می‌شود یا نادرست می‌رسد. این قلم با حاصل‌ضرب تعداد سایت‌ها در نرخ تغییرشان رشد می‌کند؛ آن را به شکل سهمی ماهانه و تکرارشونده از هزینه ساخت بودجه‌بندی کنید.

3. **پردازش: درخواست HTTP یا مرورگر headless.** یک درخواست ساده فقط HTML را دانلود می‌کند و نه چیز دیگری؛ مرورگر headless مانند یک بازدیدکننده اسکریپت‌ها، استایل‌ها، فونت‌ها و تصویرها را دانلود می‌کند، JavaScript را اجرا می‌کند و در هر ساعت روی هر سرور صفحه‌های بسیار کمتری رندر می‌کند. بخش بعدی این تفاوت را اندازه می‌گیرد.

4. **ترافیک پروکسی.** بسیاری از سایت‌های هدف در هر کشور قیمت متفاوتی نشان می‌دهند و جریان پیوسته درخواست از یک آدرس نخستین چیزی است که محدودیت نرخ آن را می‌گیرد، پس اسکرپرهای عملیاتی درخواست‌ها را از راه پروکسی می‌فرستند. هزینه پروکسی مسکونی (رزیدنتال) به‌ازای هر گیگابایت محاسبه می‌شود (قیمت ما از ‎$ 1.50 شروع می‌شود)، پس با بایت‌ها رشد می‌کند: وزن صفحه × تعداد صفحه × تلاش‌های دوباره. هزینه پروکسی ISP ثابت و دیتاسنتر به‌ازای هر IP و با ترافیک بدون سهمیه محاسبه می‌شود، پس با تعداد آدرس‌ها رشد می‌کند.

5. **تلاش دوباره به‌عنوان ضریب.** پایان مهلت، پاسخ‌های `5xx` و صفحه‌های مسدودی یعنی یک صفحه بیش از یک بار دریافت می‌شود و هر تکرار دوباره پردازش و ترافیک می‌خواهد: با نرخ شکست 30 درصد، برای همان تعداد صفحه قابل استفاده 1.3 برابر ترافیک جابه‌جا می‌کنید. پاسخ `429` یا کپچا نشانه‌ای برای کم کردن سرعت است، نه برای تلاش دوباره با شدت بیشتر؛ [وب اسکرپینگ بدون مسدود شدن](/fa/blog/web-scraping-without-getting-blocked) قاعده‌های backoff را توضیح می‌دهد که نرخ تلاش دوباره را پایین نگه می‌دارند.

6. **ذخیره‌سازی، تجزیه و کنترل کیفیت.** HTML خامی که برای تجزیه دوباره نگه داشته می‌شود روی هم انباشته می‌شود و رکوردهای تجزیه‌شده به اعتبارسنجی طرح‌واره (schema)، حذف تکراری‌ها و بررسی‌های نمونه‌ای نیاز دارند. قیمت‌های خالی پس از یک بازطراحی از نبود داده گران‌تر تمام می‌شوند، چون کسی بر اساس آن‌ها تصمیم می‌گیرد.

7. **پایش و هشدار.** کسی باید ظرف چند ساعت بفهمد که سایتی شروع به برگرداندن صفحه مسدودی کرده یا نرخ موفقیت از 97 درصد به 60 درصد افتاده است. داشبوردها، هشدارها و زمان واکنش حتی وقتی چیزی خراب نمی‌شود هزینه دارند.

8. **بررسی حقوقی و انطباق.** خواندن شرایط هر سایت هدف، بررسی robots.txt، تصمیم درباره اینکه داده شخصی در میان هست یا نه و مستند کردن مبنای قانونی، ساعت‌ها از وقت افرادی غیر از توسعه‌دهندگان را می‌گیرد. استاندارد robots.txt می‌گوید قاعده‌های آن «نوعی مجوز دسترسی نیستند» ([⁦RFC 9309⁩](https://www.rfc-editor.org/rfc/rfc9309.html#section-1)): این فایل چیزی را اجبار نمی‌کند، پس انطباق بر عهده شما می‌ماند. برای یک پروژه مشخص، با یک وکیل مشورت کنید.

## مرورگر headless چقدر داده بیشتری منتقل می‌کند؟

روی صفحه‌ای که اندازه گرفتیم، بارگذاری کامل در مرورگر headless 18.7 برابر دریافت ساده HTML بایت منتقل کرد.

در 9 نوامبر 2026 یک صفحه عمومی را به سه روش دریافت کردیم. صفحه، مرجع MDN برای کد وضعیت HTTP `429 Too Many Requests` بود که فایل robots.txt آن این مسیر را مجاز می‌داند. سه روش: یک درخواست GET فشرده HTTPS برای HTML به‌تنهایی؛ بارگذاری کامل در Chromium headless از راه Playwright با کش خالی؛ و همان بارگذاری با لغو درخواست‌های تصویر، فونت و رسانه. بایت‌ها شامل هدرها به‌علاوه بدنه‌های کدگذاری‌شده از `request.sizes()` در Playwright هستند که `responseBodySize` آن همان اندازه فشرده‌ای است که روی خط منتقل می‌شود ([Playwright: request.sizes()](https://playwright.dev/docs/api/class-request#request-sizes)).

| روش | درخواست‌ها | منتقل‌شده | زمان |
|---|---|---|---|
| دریافت ساده HTML | 1 | 23.4 کیلوبایت | 47 میلی‌ثانیه |
| مرورگر headless، بارگذاری کامل | 81 | 436.6 کیلوبایت | 4.2 ثانیه |
| مرورگر headless، با مسدود کردن تصویر، فونت و رسانه | 64 | 209.3 کیلوبایت | 1.5 ثانیه |

HTML در مرورگر هم 23.3 کیلوبایت بود؛ 413 کیلوبایت دیگر 39 اسکریپت (155.5 کیلوبایت)، دو فونت (133.3 کیلوبایت)، 15 تصویر (78 کیلوبایت)، 17 برگه سبک و چند درخواست کوچک آنالیتیکس بود. لغو تصویرها، فونت‌ها و رسانه با `page.route()` ([Playwright: لغو درخواست‌ها](https://playwright.dev/docs/network#abort-requests)) ترافیک را نصف کرد و زمان بارگذاری را به یک‌سوم رساند.

این صفحه مستندات سبک است: ⁦Web Almanac 2025⁩ اندازه میانه صفحه اصلی را 2.86 مگابایت در دسکتاپ و 2.56 مگابایت در موبایل می‌داند که 22 کیلوبایت آن HTML است ([⁦Web Almanac 2025⁩: وزن صفحه](https://almanac.httparchive.org/en/2025/page-weight)). آنجا بارگذاری در مرورگر به‌ازای هر صفحه مگابایت‌ها جابه‌جا می‌کند و با پروکسی‌ای که به‌ازای هر گیگابایت هزینه می‌گیرد، رندر به بزرگ‌ترین قلم فاکتور تبدیل می‌شود.

اول هدف‌های خودتان را اندازه بگیرید: پنل Network در Chrome DevTools تعداد درخواست‌ها و حجم منتقل‌شده یک بارگذاری را نشان می‌دهد و با **Disable cache** (غیرفعال کردن کش) نمای بازدیدکننده‌ای را می‌دهد که برای نخستین بار می‌آید ([مرجع Network در Chrome DevTools](https://developer.chrome.com/docs/devtools/network/reference)). اگر فیلدهایی که لازم دارید از قبل در HTML یا در یک پاسخ JSON هستند، به مرورگر نیازی ندارید.

## قیمت API را چگونه با هزینه‌های خودتان مقایسه کنید؟

هر دو را به هزینه هر 1,000 صفحه قابل استفاده روی هدف‌های خودتان تبدیل کنید؛ هیچ چیز دیگری قابل مقایسه نیست.

APIهای اسکرپینگ به‌ازای هر صفحه دریافت‌شده هزینه می‌گیرند، در واحدهایی که از ارائه‌دهنده‌ای به ارائه‌دهنده دیگر فرق می‌کند (به‌ازای هر درخواست، اعتبار با ضریب برای رندر و IP خروجی مسکونی، حداقل ماهانه، تعریفی از موفقیت)؛ نوشته‌ای که بالاتر به آن اشاره کردیم این مدل‌ها را توضیح می‌دهد. همان عدد را برای راه خودتان بسازید: ساعت‌ها با نرخ خودتان به‌علاوه سرورها، هزینه پروکسی یا IP، ذخیره‌سازی و پایش، تقسیم بر صفحه‌های قابل استفاده.

| قلم هزینه | ساخت خودتان | API اسکرپینگ | رشد می‌کند با |
|---|---|---|---|
| ساخت | ساعت‌های شما برای هر سایت | یک یکپارچه‌سازی | تعداد سایت‌ها |
| نگهداری | ساعت‌های شما، با هر تغییر | کار ارائه‌دهنده | سایت‌ها × نرخ تغییر |
| پردازش | سرورها و مرورگرها | در قیمت (رده رندر) | صفحه‌ها، سهم رندر |
| ترافیک پروکسی | به‌ازای هر گیگابایت یا هر IP | در قیمت (رده IP خروجی) | بایت‌ها یا تعداد IP |
| تلاش دوباره | هر تلاش را شما می‌پردازید | معمولاً فقط موفق‌ها شمرده می‌شوند | نرخ شکست |
| ذخیره‌سازی، کنترل کیفیت، پایش | با شما | با شما، به‌علاوه آپتایم آن‌ها | صفحه‌ها، سایت‌ها |
| بررسی حقوقی | با شما | با شما | هدف‌ها، داده شخصی |

## یک نمونه محاسبه با متغیرها

عددهای زیر گرد و ساختگی‌اند و فقط برای نشان دادن حساب آمده‌اند؛ آن‌ها را با اندازه‌گیری‌های خودتان جایگزین کنید.

| متغیر | معنا | مقدار فرضی |
|---|---|---|
| P | صفحه قابل استفاده در ماه | 1,000,000 |
| r | ضریب تلاش دوباره (1 + سهم تلاش‌های ناموفق) | 1.3 |
| s | بایت منتقل‌شده در هر تلاش | 60 کیلوبایت ساده، 1.5 مگابایت رندرشده |
| h | ساعت مهندسی و نگهداری در ماه | 40 |

رندر برای همان صفحه‌ها ترافیک را 25 برابر می‌کند:

| ردیف | فرمول | HTTP ساده | رندرشده |
|---|---|---|---|
| ترافیک پروکسی | P × r × s | 78 گیگابایت | 1,950 گیگابایت |
| پروکسی مسکونی | ترافیک × قیمت هر گیگابایت | ⁦78 × G⁩ | ⁦1,950 × G⁩ |
| پروکسی ISP یا دیتاسنتر | تعداد آدرس × قیمت هر IP | ⁦n × I⁩ | ⁦n × I⁩ |
| نیروی انسانی | h × نرخ ساعتی | ⁦40 × R⁩ | ⁦40 × R⁩، به‌علاوه نگهداری مرورگر |

با پروکسی مسکونی گیگابایتی، ضریب رندر روی فاکتور می‌نشیند؛ با آدرس‌های بدون سهمیه، روی سرورهای شما. ضریب تلاش دوباره در هر ردیف حضور دارد: کاهش شکست‌ها از 30 درصد به 10 درصد حدود 15 درصد از ترافیک کم می‌کند. سمت API برابر است با P ضرب در قیمت آن برای هر 1,000 صفحه قابل استفاده، به‌علاوه ساعت‌های شما برای یکپارچه‌سازی و بررسی.

## ساختن کی به‌صرفه است و API کی؟

ساختن وقتی به‌صرفه است که کار محدود، پایدار و طولانی باشد؛ API وقتی که کار گسترده، متغیر یا کوتاه باشد.

**با پروکسی بسازید** برای چند سایت پایدار، حجمی که قیمت به‌ازای هر صفحه را سنگین می‌کند و تیمی که از قبل اسکرپر اداره می‌کند. **از API اسکرپینگ استفاده کنید** وقتی فهرست سایت‌ها بلند است یا هر فصل عوض می‌شود، بیشتر هدف‌ها با JavaScript رندر می‌شوند یا پروژه سه ماه دیگر تمام می‌شود. **راه ترکیبی را بروید** وقتی چند سایت حجم را به دوش می‌کشند و دنباله‌ای بلند پیچیدگی را.

## کدام هزینه‌های پنهان از برآوردها جا می‌مانند؟

چهار هزینه به‌ندرت در جدول محاسبات دیده می‌شوند. **هزینه فرصت:** توسعه‌دهنده‌ای که تجزیه‌گرها را نگه می‌دارد، محصولی را نمی‌سازد که قرار است از این داده تغذیه شود. **کیفیت داده:** اسکرپری که بی‌صدا فیلدهای کهنه برمی‌گرداند ارزان‌تر از اسکرپر درست اداره می‌شود، تا روزی که تصمیمی بر پایه آن گرفته شود. **انطباق:** بررسی شرایط استفاده، بررسی robots.txt، حداقل‌سازی داده و قرارداد پردازش با هر ارائه‌دهنده‌ای که داده شخصی را مدیریت می‌کند، برای هر هدف تازه وقت می‌گیرد. **ریسک وابستگی به یک نفر (bus factor):** خط لوله‌ای که فقط یک نفر آن را می‌فهمد، از روزی که آن نفر برود یک بدهی است.

## چه زمانی خرید پروکسی به‌تنهایی درست است؟

خرید پروکسی به‌تنهایی وقتی درست است که از قبل اسکرپری دارید که کار می‌کند و فقط IP خروجی کم دارید: کشور درست، آدرس‌های متمایز کافی یا یک IP ثابت برای یک نشست.

برای سایت‌هایی که محتوایشان با موقعیت تغییر می‌کند، [پروکسی مسکونی](https://proxynet.io/fa/residential-proxy) نشست چرخشی یا ثابت با هدف‌گیری کشور و شهر می‌دهد و هزینه‌اش به‌ازای هر گیگابایت محاسبه می‌شود؛ پس هر جا می‌توانید HTML ساده دریافت کنید و هر جا نمی‌توانید تصویرها و فونت‌ها را مسدود کنید.

برای حجم بالا روی هدف‌های پایدار، هزینه [پروکسی ISP](https://proxynet.io/fa/static-isp-residential-proxy) به‌ازای هر IP و با ترافیک بدون سهمیه محاسبه می‌شود؛ پروکسی دیتاسنتر از همین مدل پیروی می‌کند و کمترین هزینه را به‌ازای هر آدرس دارد. هر دو به‌طور پیش‌فرض با محدودیت سایت هدف تحویل می‌شوند و دسترسی به همه وب‌سایت‌ها یک افزونه پولی است. پرداخت به شکل موجودی کیف پول است که هرگز نمی‌سوزد، بدون اشتراک و بدون تست رایگان.

## چه زمانی خرید API اسکرپینگ مدیریت‌شده درست است؟

API مدیریت‌شده وقتی خرید درستی است که فهرست سایت‌ها بلند است یا زیاد تغییر می‌کند، بیشتر صفحه‌ها به رندر نیاز دارند یا پروژه کوتاه‌تر از آن است که هزینه ساخت را سرشکن کند: شما URLها را می‌فرستید و صفحه یا فیلد تحویل می‌گیرید و ارائه‌دهنده مرورگرها، IPهای خروجی، تلاش‌های دوباره و نگهداری را بر عهده می‌گیرد. پیش از امضا، واحد صورت‌حساب، تعریف موفقیت، پایبندی به robots.txt و شیوه قیمت‌گذاری رندر را بپرسید. Web Scraping API ما، استخراج صفحات به‌صورت مدیریت‌شده، از طریق تیم فروش در دسترس است؛ [صفحه استخراج داده](/fa/data-scraping) بخش پروکسی و راه تماس با آن‌ها را شرح می‌دهد.

## اشتباه‌های رایج

- **شمردن فقط هزینه ساخت.** در بازه دو سال، مهندسی ماه اول کوچک‌ترین ردیف است.
- **نادیده گرفتن تلاش‌های دوباره.** نرخ شکست 30 درصد یعنی 30 درصد هزینه اضافه روی پردازش و ترافیک.
- **پروکسی مسکونی برای هر هدف.** سایت‌هایی که با موقعیت تغییر نمی‌کنند روی IPهای بدون سهمیه ارزان‌تر تمام می‌شوند.
- **اندازه نگرفتن وزن صفحه.** انتخاب پروکسی گیگابایتی بدون دانستن اینکه صفحه 25 کیلوبایت است یا 2.5 مگابایت.
- **رندر کردن همه چیز.** داده بسیاری از صفحه‌ها در خود HTML یا در یک پاسخ JSON است.
- **نداشتن سقف هزینه.** اسکرپر، حساب پروکسی و کلید API هر کدام به یک سقف ماهانه و یک هشدار نیاز دارند.

## راهنمای انتخاب

| نیاز | پیشنهاد |
|---|---|
| سه سایت پایدار، میلیون‌ها صفحه، تیم خودتان | ساختن؛ IPهای بدون سهمیه ISP یا دیتاسنتر |
| قیمت‌ها همان‌طور که بازدیدکنندگان ده کشور می‌بینند | IP خروجی مسکونی، درخواست ساده |
| شصت سایت با چیدمان‌های متفاوت، تیم کوچک یا پروژه سه‌ماهه | API اسکرپینگ |
| بیشتر هدف‌ها با JavaScript رندر می‌شوند | API با رندر به‌ازای هر هدف |
| حجم پیوسته روی چند سایت به‌علاوه یک دنباله بلند | ترکیبی: اسکرپر خودتان، API برای دنباله |
| سایت API رسمی با فیلدهای شما دارد | API رسمی |

## پرسش‌های متداول

### آیا وب اسکرپینگ هزینه دارد؟

بله. کتابخانه‌ها رایگان‌اند، اما اداره یک اسکرپر زمان مهندسی، نگهداری، سرور، ترافیک پروکسی، ذخیره‌سازی، پایش و بررسی حقوقی می‌خواهد. یک اسکریپت یک‌باره تقریباً رایگان است؛ یک خط لوله روزانه روی سایت‌های زیاد هزینه‌ای تکرارشونده است.

### هزینه یک وب اسکرپر چقدر است؟

عدد واحدی وجود ندارد: به تعداد سایت‌ها، صفحه در ماه، سهم رندر و اینکه هدف‌ها چند وقت یک بار تغییر می‌کنند بستگی دارد. آن را ماهانه برآورد کنید: ساعت‌ها با نرخ خودتان به‌علاوه سرورها، هزینه پروکسی، ذخیره‌سازی و پایش، تقسیم بر صفحه‌های قابل استفاده.

### آیا API اسکرپینگ از پروکسی ارزان‌تر است؟

برای سایت‌های زیاد و متفاوت یا پر از JavaScript و یک تیم کوچک، معمولاً بله، چون قیمت آن مرورگرها، تلاش‌های دوباره و نگهداری را در بر می‌گیرد. برای حجم بالا روی چند سایت پایدار، اسکرپر خودتان با پروکسی بدون سهمیه معمولاً به‌ازای هر صفحه ارزان‌تر است.

### پهنای باند پروکسی برای اسکرپینگ را چگونه برآورد کنم؟

تعداد صفحه در ماه را در ضریب تلاش دوباره و در بایت منتقل‌شده به‌ازای هر صفحه ضرب کنید، آن هم اندازه‌گیری‌شده روی هدف‌های واقعی خودتان؛ دریافت ساده اغلب ده‌ها کیلوبایت است و بارگذاری در مرورگر مگابایت‌ها.

### چرا هزینه وب اسکرپینگ با گذشت زمان بیشتر می‌شود؟

چون هدف‌ها تغییر می‌کنند و حجم رشد می‌کند: بازطراحی‌ها ساعت نگهداری می‌خواهند، سایت‌های تازه تجزیه‌گر اضافه می‌کنند، با سخت‌تر شدن محافظت تلاش‌های دوباره کم‌کم بالا می‌روند و صفحه‌های خام ذخیره‌شده روی هم انباشته می‌شوند.

### آیا ابزارهای رایگان اسکرپینگ واقعاً رایگان‌اند؟

مجوز رایگان است؛ اداره کردن نه. اسکرپرهای متن‌باز هزینه نرم‌افزار را حذف می‌کنند؛ سرورها، پروکسی‌ها، نگهداری و مسئولیت آنچه جمع می‌کنند با شماست.

## خلاصه

وب اسکرپینگ هزینه دارد چون یک عملیات است، نه یک دانلود، و تلاش‌های دوباره و رندر هر ردیف دیگر را چند برابر می‌کنند. وزن صفحه و نرخ شکست را روی هدف‌های واقعی خودتان اندازه بگیرید، هر گزینه را به هزینه هر 1,000 صفحه قابل استفاده تبدیل کنید و سپس انتخاب کنید: اسکرپر خودتان روی پروکسی بدون سهمیه برای چند سایت پایدار، API اسکرپینگ برای سایت‌های زیاد یا متغیر، راه ترکیبی برای حجم پیوسته با یک دنباله بلند. اگر آنچه کم دارید IP خروجی است نه اسکرپر، با [خدمات پروکسی ما](/fa/proxy) شروع کنید.