السعر المعلن هو أرخص ما في الصفحة
تتصدر كل واجهات برمجة تطبيقات الـ scraping API بالنوع نفسه من الأرقام. تبدأ من 9 سنتات لكل 1,000 طلب request. تبدأ من دولار واحد. تبدأ من 1.50 دولار. رقم واضح، منخفض، ويسهل إدراجه في عروض الأسعار المقدمة للعملاء.
هذا الرقم حقيقي. وهو أيضاً سعر الطلب الوحيد الذي لن ترسله غالباً: طلب HTTP GET عادي إلى موقع لا يهتم بهوية من يرسل الطلب.
المواقع التي تتقاضى أجراً مقابل استخراج بياناتها تهتم كثيراً بذلك. وفي اللحظة التي يحتاج فيها الهدف إلى تصيير الصفحة عبر JavaScript أو إلى proxy سكني، يتوقف السعر المذكور عن التطبيق ويبدأ تطبيق المضاعف. السعر المعلن هو الحد الأدنى فقط. أما الفاتورة الفعلية فتكون أعلى من ذلك بكثير، ومعظم المشترين لا يكتشفون ذلك إلا بعد صدور الفاتورة الأولى.
كيف يعمل هذا المضاعف عملياً
افتح وثائق الرصيد الخاصة بأي API تقريباً وستجد الجدول نفسه. يكلف الطلب العادي رصيداً واحداً (1 credit). فعّل تصيير JavaScript وسيرتفع إلى 5. اطلب proxy سكنياً أو مميزاً وسيرتفع إلى 10. اطلب الاثنين معاً، لموقع يتحقق من هوية الطالب، وستصل إلى 25. تصل أعلى فئة في ScrapingBee إلى 75 رصيداً لصفحة واحدة (وثائق ScrapingBee، أكتوبر 2026).
تسعر ScraperAPI بالهيكل نفسه: التصيير يكلف 10 أرصدة، الـ proxies المميزة 10، كلاهما معاً 25، وفئتها الفائقة 30، وبعض النطاقات المحمية 10 بمفردها (وثائق ScraperAPI). وتصل ZenRows إلى النتيجة نفسها: 1 للطلب القياسي، و5 لـ JS، و10 للـ proxy المميز، و25 للاثنين معاً (تسعير ZenRows).
إليك الجزء الذي لا تذكره أي صفحة تسويقية. يتطابق مقدمو الخدمات عند قمة الجدول. يمكنك اختيار API رخيص أو مكلف، ولكن بمجرد أن يفرض الموقع حماية ضدهما، سيفرض كلاهما رسوماً تعادل حوالي 25 ضعف سعرهما الأساسي المعلن. الرقم الذي قارنت بين المزودين على أساسه ليس هو الرقم الذي يحدد فاتورتك النهائية.
الفئة المعلنة هي الفئة الخاطئة
إذن، في أي فئة تقع مشاريعك الفعلية؟
نشرت Zyte، التي تعتمد نموذج الفئات المتعددة، تفاصيلها الخاصة: حوالي 80% من مواقع الويب تقع في أبسط فئتين، ونحو 0.1% فقط تتغير فئتها في ربع سنوي معين (Zyte، 2026). يبدو هذا نظرياً أمراً مطمئناً. معظم الويب رخيص التكلفة.
ولكن انظر إلى الأمر من زاوية أخرى. نسبة الـ 80% الرخيصة رخيصة لدى كل مزود. لا توجد أي ميزة تنافسية هناك. المهام التي يدفع لك العميل مقابل إنجازها، سواء كنت مستقلاً أو فريقاً صغيراً (كتالوجات المتاجر، أسعار السفر، قوائم المنتجات، وأي شيء له قيمة تجارية)، هي تحديداً المواقع التي تقع ضمن الأقلية المكلفة. وتؤكد أبحاث Zyte نفسها أن 18.5% من المواقع الكبرى تقع خلف نظام حماية مخصص (تقرير Zyte State of Web Access).
هذا هو الفخ. يصف السعر المعلن المهام التي لا يوظفك أحد من أجلها. بينما يصف سعر 25x المهام التي يطلبونها بالفعل. (إنها نفس حسابات التكلفة لكل وحدة التي تجعل استخراج البيانات عبر LLM غير مجدٍ اقتصادياً على نطاق واسع بمجرد زيادة الحجم.)
الفئة المبتدئة تتلاشى في صمت
بينما أصبحت حسابات التكلفة لكل صفحة أكثر غلاء، بات الوصول الرخيص أصعب من ذي قبل.
ألغت ScrapingBee خطتها البالغة 19 دولار في أكتوبر 2026؛ وأصبحت نقطة البداية الآن 49 دولار شهريا. يشير ملخص الفئات الخاص بشركة Firecrawl إلى أن 49 دولار دون أي فئة مجانية دائمة أصبح هو الحد الأدنى المعتاد. ودمجت Oxylabs منتجات scrapers الخاصة بها في اشتراك واحد. كما انتقلت كل من Decodo وBright Data إلى نظام الحساب لكل request ولكل سجل، حيث يعمل العداد مع كل استدعاء (Bright Data Web Scraper pricing).
لا يستهدف أي من هذا مشتري المنصات بعقود موثقة. بل يقع العبء على المستقلين والفرق المكونة من شخصين: أولئك الذين يحتاجون إلى استخراج موقع واحد لعميل واحد هذا الشهر ولا يمكنهم توزيع خطة بقيمة 500 دولار على مئة مهمة. (لقد فصلنا من يتحمل هذا العبء فعليا في the hidden cost of maintaining your own scrapers.)
ماذا يعني هذا لمن يسعر عملية كشط بيانات
توقف عن التسعير بناء على السعر المعلن. بل سعر بناء على فئة الموقع المستهدف.
قبل تقديم عرض سعر لعميل، انظر إلى المواقع الفعلية المشمولة وصنفها: أيها يعيد HTML صالحا للاستخدام عبر request عادي، وأيها يحتاج إلى صفحة معالجة (rendered)، وأيها يتطلب residential proxy فوق ذلك. هذا المزيج، وليس السعر الترويجي للخطة، هو تكلفتك الحقيقية. المهمة التي تحتوي على 90% صفحات عادية و10% صفحات معقدة تكون رخيصة. أما المهمة التي تستهدف متاجر تجزئة محمية بالكامل فتكلف 25 ضعف الرقم الموجود في عرضك، وستتحمل أنت هذا الفارق.
احسبها مرة واحدة وستتضح الفجوة الكبيرة. لنفترض أن عميلا يريد 50,000 صفحة منتج شهريا من موقع تجزئة يحتاج إلى صفحة معالجة وresidential proxy. بمعدل 25 رصيدا للصفحة، يعادل ذلك 1.25 مليون رصيد. على API تعلن عن ألف رصيد مقابل دولار واحد، كان السعر التقديري في ذهنك هو 50 دولار. التكلفة الفعلية هي 1,250 دولار. نفس الصفحات، ونفس الشهر، بفارق 25 ضعفا، ودون أن تضع صفحة التسعير هذا المضاعف بجوار العنوان الرئيسي إطلاقا.
ثم اقرأ شروط الفوترة عند الفشل، لأنها تختلف وليست مذكورة أبدا في العنوان الرئيسي. تفرض Firecrawl رصيدا مقابل صفحة تعود برمز 403 أو 404، ولا تفرض شيئا عندما لا يعيد الـ request أي نتيجة (Firecrawl pricing). بينما يعتبر آخرون أي رمز 2xx أو 4xx نجاحا ويفرضون تكلفته. عند استهداف موقع يرفض الطلبات بكثرة، يمكن لهذا البند وحده أن يكلف أكثر من عملية المعالجة نفسها.
المؤشر الحقيقي تحت كل هذا ليس الخطة الشهرية. بل هو تكلفة كل استدعاء يمكنك قراءتها بعد التنفيذ وربطها بالطلب الدقيق الذي تسبب فيها. الخطة مجرد تقدير. أما رقم التكلفة لكل استدعاء فهو الإيصال الفعلي، وهو الشيء الوحيد الذي يمكن بناء فاتورة موجهة للعميل عليه. (للاطلاع على تفاصيل كل نموذج، راجع تحليلنا لـ التسعير لكل جيجابايت مقابل التسعير لكل صفحة.)
إلى أين يتجه هذا المجال
الخيارات تتقارب. باقات الدخول تتلاشى. وفي غضون عام، سيخبرك السعر الرئيسي بأقل مما يخبرك به الآن، لأن كل مزود جاد سيطرح تسعيراً قريباً من نفس تدرج 1-5-10-25 ونفس لغة المحاسبة على النجاح فقط.
ما يميزهم بعد ذلك هو ما إذا كان بإمكانك معرفة تكلفة كل استدعاء والدفع مقابل ما نجح منها فقط. في FourA، نضع تكلفة كل request داخل الـ response، حتى تتمكن من حساب تكلفة المهمة بناءً على ما أنجزته فعلياً بدلاً من التخمين عبر باقة اشتراك. في المرة القادمة التي يبدأ فيها مزود برقم معين، فالسؤال المفيد ليس مدى انخفاضه. بل ما يحدث له في اللحظة التي يفرض فيها الموقع قيوداً.