كل المقالات

مراقبة SERP على نطاق واسع بعد num=100

أصبح تتبع تصنيفات Google على نطاق واسع أكثر صعوبة بمجرد إيقاف num=100. إليك كيف تعيد فرق هندسة SEO بناء البنية التحتية لمراقبة SERP لعام 2026.

التحدي

إذا كان فريقك يبني أدوات تتبع التصنيف، أو لوحات معلومات SEO، أو أدوات تحليل المنافسين، فقد أطاح عام 2026 باقتصاديات الوحدة الخاصة بك. أوقفت Google بهدوء معامل URL‏ num=100 في Google Search هذا العام، وهي الحيلة التي استخدمتها كل أداة كشط SERP لسحب 100 نتيجة في request واحد. الآن يتطلب الحصول على التغطية نفسها عشرة requests بدلاً من واحد.

هذه هي التكلفة الواضحة. أما التكاليف الخفية فهي أكثر صعوبة.

لا يعمل تتبع التصنيف إلا عندما ترى SERP التي يراها باحث حقيقي في البلد والمنطقة والمدينة الصحيحة. الكلمة المفتاحية التي تحتل المرتبة رقم 4 في لندن قد تحتل المرتبة رقم 11 في إدنبرة ورقم 19 في بلفاست. حزم النتائج المحلية الثلاثية (Local 3-packs)، وعارضات التسوق الدوارة، وصناديق الأخبار، ولوحات المعرفة، وميزات AI Overviews. تتغير كل ميزة من ميزات SERP مع الجغرافيا والجهاز. (قامت Scrape.do بقياس ظهور نصوص AI Overview في حوالي 36% من الاستعلامات خلال أوائل عام 2026.) إذا قامت أداة الكشط الخاصة بك بالتوجيه عبر proxy في المدينة الخاطئة، فإن بيانات التصنيف الخاصة بك ستكون مجرد خيال يُروى بثقة.

لذلك، يحتاج أي منتج SERP قوي في عام 2026 إلى ثلاثة أشياء تعمل معاً: request يبدو كأنه متصفح حقيقي على مستوى الشبكة (wire level)، وproxy يتواجد في المدينة المحددة التي تحاول مراقبتها، والقدرة على معالجة (render) لغة JavaScript عندما تقرر Google تحميل نصف النتيجة من جانب العميل (client-side). إذا فقدت أيًا من هذه الثلاثة، فستتدهور جودة بياناتك بصمت.

نهج FourA

إن عنق الزجاجة في كشط SERP على نطاق واسع ليس الـ request. بل هو التوجيه (routing).

تبدأ معظم خطوط المعالجة (pipelines) المطورة داخلياً بمجموعة proxy ثابتة وتتعامل مع الاستعلام كمتغير. ومع الاستهداف الجغرافي من Google، ينعكس الأمر تماماً. الاستعلام هو ما تملكه بالفعل. أما الـ proxy فهو ما يجب عليك تحديده بدقة.

لقد رأينا فرقاً تصمم هذا النموذج فوق FourA على النحو التالي تقريباً:

  1. يحتفظ Proxy Finder بمجموعة عمل من الـ proxies التي تم التحقق من نشاطها عبر فحوصات حية حديثة، وتم تصنيفها حسب البلد، والمنطقة، والمدينة، وASN. عندما يحتاج request إلى القدوم من مانشستر أو بوسطن أو ساو باولو، يختار Proxy Finder خادماً يعيش هناك بالفعل وكان نشطاً في الفحص الأخير. عملية الاختيار تتم قبل الجلب (fetch)، وليس أثنائه. لمزيد من المعلومات حول سبب أهمية طبقة التوجيه هذه، راجع مقالنا حول Smart Proxy Routing.

  2. يتولى Single عملية جلب SERP نفسها. بالنسبة لنتائج البحث الطبيعية القياسية، فإن الـ HTML الخام كافٍ تماماً. اضبط unblocker: true وسيمر الـ request عبر جدران الحماية من البوتات على مستوى المصافحة (handshake-level) دون أن تحتاج إلى معرفة التوقيع (signature) الذي تتحقق منه Google في ذلك الأسبوع. لقد قمنا بتفصيل ما يفعله هذا الرمز (flag) على مستوى الشبكة في مقالنا Web Unblocker post.

  3. يتولى Browser معالجة صفحات SERP التي يظهر فيها المحتوى المهم بعد تشغيل JavaScript. ميزات AI Overviews، وحزم التسوق الموسعة، ومحتوى لوحة المعرفة، وحزم النتائج المحلية الثلاثية الثابتة. نفس الـ URL، ونفس الهدف، كل ما في الأمر أن الـ request يمر عبر جلسة متصفح كاملة ويعيد الصفحة مرسومة بالكامل (fully painted). (بالإضافة إلى لقطات الشاشة، والتي تنقذك في اليوم الذي يسألك فيه مسؤول الـ SEO عن سبب إظهار لوحة المعلومات للمرتبة رقم 3 بينما يرى هو المرتبة رقم 6 في متصفحه).

استدعاء واحد لـ API الموجه عبر proxy:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

هذا فصل واضح لثلاث مهام: عمل الـ proxy الصحيح جغرافياً (Proxy Finder)، والـ request نفسه (Single)، ومعالجة JavaScript عند الحاجة إليها (Browser). لا يحمل الكود الخاص بك منطق التحقق من سلامة الـ proxy أو تخمين أي عنوان IP لا يزال نشطاً في الساعة 3 صباحاً. هذه مشكلة شخص آخر.

وقم بتخزين كل response مفتاحياً بواسطة (keyword, location, device, timestamp). هذه هي وحدة الحقيقة الفعلية لتتبع التصنيف. ليست "لقد تصدرنا هنا لهذه الكلمة المفتاحية اليوم"، بل "لقد تصدرنا هنا لهذه الكلمة المفتاحية، من هذه المدينة، على هذا الجهاز، في هذه الدقيقة". بدون هذا المستوى من الإسناد، يمكن لبيانات يومين أن تتعارض بصمت ولن يكون لديك أي طريقة لمعرفة أيهما كان صحيحاً. تعيش فرق SEO التي تراقب القطاعات المحمية (protected verticals) هذا الواقع بالفعل. لقد كتبنا أيضاً عن كيف bot detection went behavioral، مما يضيف محوراً رابعاً (استمرارية الجلسة) للمواقع التي تنظر في تسلسل الـ requests بدلاً من إشارات كل request على حدة.

النتائج

كانت أداة تتبع التصنيف التي تراقب 5,000 كلمة مفتاحية عبر 12 مدينة، مرتين يومياً، تستهلك حوالي 120,000 requests يومياً في ظل نظام num=100 القديم. الآن يقترب هذا الرقم من 1.2 مليون، بحسابات تقسيم الصفحات البسيطة (سيناريو توضيحي يعتمد على معايير الصناعة).

تميل الفرق التي نقلت هذا النموذج إلى حزمة مكونة من ثلاثة منتجات إلى الإبلاغ عن:

  • انخفاض بنسبة 40-60% في تكلفة الـ request الواحد مقارنة بتشغيل مجموعة الـ proxies الخاصة بهم، ويرجع ذلك أساساً إلى توقفهم عن الدفع مقابل استبدال الـ proxies، وعناوين IP الميتة، وساعات العمل الهندسي المخصصة لصيانة التدوير (rotation).
  • ارتفاع دقة الموقع على مستوى المدينة من ~70% إلى أكثر من 95%، لأن Proxy Finder يقوم بالتصفية حسب المدينة ويتحقق من النشاط في الفحص الأخير قبل تسليم الـ proxy.
  • لا يوجد مسار خاص لميزات AI Overviews. الكلمة المفتاحية التي يتم جلبها عبر Single يمكن ترقيتها إلى Browser دون إعادة كتابة خط المعالجة (pipeline). العقد متطابق: URL في المدخلات، وresponse في المخرجات.

لا تحتاج إلى أي من هذا من أجل عشر كلمات مفتاحية وجهاز كمبيوتر محمول. ولكنك تحتاجه بمجرد أن يقوم خط المعالجة بمراقبة عشرات الآلاف من الكلمات المفتاحية عبر البلدان، ويقوم عملاؤك بتحديث لوحة المعلومات في الساعة 9 صباحاً من يوم الاثنين، ويجب أن تكون التصنيفات حقيقية.

الخلاصة الرئيسية

لقد توقف الجزء الصعب من مراقبة SERP عن كونها الـ request منذ فترة طويلة. بل كان دائماً التوجيه (routing). من أي مدينة تجلب البيانات؟ وهل عنوان IP هذا نشط؟ وهل أعادت Google التخطيط (layout) الذي يراه باحث حقيقي في ذلك الموقع بالفعل، أم التخطيط الفارغ الذي تقدمه عندما تشم رائحة أداة كشط؟

إذا كنت فريق SEO يدير تتبع التصنيف على حزمة برمجية قمت ببنائها بنفسك، فإن السؤال لعام 2026 ليس ما إذا كنت ستقوم بكشط Google أم لا. أنت تفعل ذلك بالفعل. السؤال هو ما إذا كانت بنيتك التحتية قادرة على الاستمرار في إنتاج تصنيفات جديرة بالثقة عندما تتغير القواعد دون سابق إنذار، وكم من وقت فريقك الهندسي أنت مستعد لإنفاقه للحفاظ عليها على هذا النحو.