ما هو Web Scraping ولماذا تحتاج إلى SERP API

معظم البيانات المفيدة على الإنترنت ليست متاحة عبر واجهة برمجية. هي معروضة في صفحات HTML مصمّمة لعين الإنسان لا لبرنامجك. عملية تحويل تلك الصفحات إلى بيانات منظّمة يمكن لبرنامجك التعامل معها هي ما نسمّيه web scraping.

في هذا المقال سنفهم كيف تعمل العملية فعلياً، ولماذا تُعدّ نتائج محرّكات البحث الحالة الأصعب على الإطلاق، ومتى يكون بناء scraper بنفسك قراراً هندسياً سيّئاً.

من HTML إلى بيانات

الفكرة الأساسية بسيطة في ثلاث خطوات:

1. الجلب (fetch): ترسل طلب HTTP وتستقبل نصّ الصفحة.
2. التحليل (parse): تحوّل ذلك النصّ إلى شجرة DOM يمكن الاستعلام عنها.
3. الاستخراج (extract): تختار العناصر التي تريدها عبر CSS selectors أو XPath.

مثال مباشر بـ Python:

import requests
from bs4 import BeautifulSoup

response = requests.get("https://example.com")
soup = BeautifulSoup(response.text, "html.parser")

for heading in soup.select("h2.article-title"):
    print(heading.get_text(strip=True))

هذا الكود يعمل. المشكلة أنّه يعمل اليوم فقط.

لماذا تنهار هذه الطريقة على محرّكات البحث

حين يكون هدفك صفحة نتائج Google، تصطدم بسلسلة من العوائق التي لا علاقة لها بالبرمجة نفسها:

الأول: البنية غير مستقرّة. أسماء الـ CSS classes في صفحة نتائج Google مولّدة آلياً وتتغيّر دون إشعار. الـ selector الذي كتبته هذا الأسبوع قد يعيد قائمة فارغة الأسبوع القادم، وغالباً لن تكتشف ذلك إلّا حين يشتكي أحدهم من أنّ التقرير صار فارغاً.

الثاني: الحظر. إرسال عدد كبير من الطلبات من نفس عنوان IP يقود بسرعة إلى صفحات CAPTCHA أو إلى الحظر الكامل. الحلّ يتطلّب شبكة proxies ودورانها وإدارة فشلها، وهذه بنية تحتية قائمة بذاتها.

الثالث: النتائج ليست واحدة. هذه النقطة يغفل عنها الكثيرون. صفحة نتائج Google تختلف باختلاف البلد واللغة والجهاز وحتى المدينة. البحث عن نفس الكلمة من الدار البيضاء ومن الرياض يعطي ترتيباً مختلفاً. إن لم تتحكّم في هذه المتغيّرات صراحةً، فأنت لا تقيس شيئاً محدّداً.

الرابع: الصفحة ليست قائمة روابط. صفحة النتائج الحديثة تحتوي على featured snippets و knowledge graph و related questions و local pack. كلّ عنصر منها له بنية HTML مختلفة تماماً، وكل واحد يحتاج منطق استخراج خاصّاً به.

أين يدخل الـ SERP API

الـ SERP API هي خدمة تتولّى الطبقة القذرة من هذه العملية: تدير الـ proxies، وتحلّ الـ CAPTCHAs، وتتتبّع تغيّرات بنية الصفحة، وتعيد إليك JSON منظّماً وثابت الشكل.

فبدل أن تكتب:

soup = BeautifulSoup(html, "html.parser")
results = []
for block in soup.select("div.g"):          # هذا الـ selector سيتغيّر
    title = block.select_one("h3")
    link = block.select_one("a")
    if title and link:
        results.append({"title": title.text, "link": link["href"]})

تكتب:

results = client.search({"engine": "google", "q": "قهوة"})
for result in results["organic_results"]:
    print(result["position"], result["title"], result["link"])

الفرق ليس في عدد الأسطر. الفرق أنّ السطر الأول مسؤوليتك أنت في كل مرة يغيّر فيها Google شيئاً، والثاني مسؤولية غيرك.

متى تبني بنفسك ومتى تستخدم API

هذا قرار هندسي وليس مسألة تفضيل. الجدول التالي يلخّص الحالات:

الحالة	القرار المعقول
موقع واحد بسيط، بنيته مستقرّة، عدد طلبات صغير	ابنِ scraper بنفسك
مشروع تعليمي، الهدف هو الفهم لا التشغيل	ابنِ بنفسك، ستتعلّم أكثر
نتائج محرّكات بحث، بشكل دوري، في نظام إنتاج	استخدم SERP API
تحتاج مقارنة عبر دول أو لغات متعدّدة	استخدم SERP API
ميزانيتك صفر ووقتك غير محدود	ابنِ بنفسك، لكن احسب تكلفة الصيانة

القاعدة العملية: إن كان استخراج البيانات ليس هو منتجك، فلا تبنِ له بنية تحتية. تكلفة الصيانة الحقيقية ليست في كتابة الكود أول مرة، بل في إصلاحه كل شهرين حين يتغيّر شيء لم تتحكّم فيه أصلاً.

ملاحظة حول الجانب القانوني

الوضع القانوني لاستخراج البيانات ليس أبيض وأسود، ويختلف بحسب الولاية القضائية وطبيعة البيانات. من الحصافة التمييز بين ثلاثة أمور: البيانات المتاحة علناً دون تسجيل دخول، والبيانات خلف حساب مستخدم، والبيانات الشخصية. الفئة الأخيرة تخضع لقوانين حماية البيانات بغضّ النظر عن كونها ظاهرة في صفحة عامة. إن كان مشروعك تجارياً وواسع النطاق، فهذه استشارة قانونية لا مقال تقني.

الخطوة التالية

في المقال التالي سنكتب أول طلب فعلي إلى SerpApi ونقرأ بنية الاستجابة سطراً سطراً، بـ Python و JavaScript و cURL.