تكرار الصفحات من فلاتر URL: كيف لا تتجاوز حدود برنامج التحليل

هل قمت بتشغيل المحلل على Wildberries أو Ozon، وضبطت البروكسي، وبعد ساعة واجهت الحدود وحصلت على مجموعة من IP المحظورة - رغم أنك جمعت فقط بضع آلاف من بطاقات المنتجات؟ المشكلة تكاد تكون واحدة دائمًا: معلمات URL. الفلاتر، الترتيبات، الصفحات المتعددة وعلامات UTM تحول كتالوجًا واحدًا إلى عشرات الآلاف من النسخ الفنية المكررة، ويقوم المحلل بزيارة جميعها بدلاً من جمع البيانات الفريدة.

ما هي الصفحات المكررة بسبب معلمات URL

الصفحة المكررة هي URL يختلف تقنيًا عن آخر، ولكن المحتوى يقدم نفس الشيء أو شيئًا مشابهًا. مثال كلاسيكي: كتالوج الفساتين على Wildberries متاح على العنوان /catalog/zhenshchinam/odezhda/platya، ولكن نفس النتائج، المرتبة حسب السعر، تتحول إلى /catalog/zhenshchinam/odezhda/platya?sort=price. أضف فلتر حسب الحجم، العلامة التجارية، اللون، نطاق السعر - وستحصل في النهاية على مئات من تركيبات المعلمات، كل منها URL فريد من الناحية الشكلية.

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

فئة منفصلة من النسخ المكررة هي علامات UTM ومعلمات الجلسة (utm_source، clid، _openstat). إنها لا تؤثر على محتوى الصفحة على الإطلاق، ولكن إذا كان المحلل يجمع الروابط من صفحات أخرى على الموقع كما هي، فسوف يسحب نفس بطاقة المنتج عشرات المرات مع ذيول مختلفة في العنوان.

لماذا هذا حرج بشكل خاص للمحلل

بالنسبة لأخصائي SEO، تعتبر النسخ المكررة للصفحات مشكلة في الفهرسة وتخفيف الوزن. بالنسبة لمن يقوم بتحليل السوق لمراقبة الأسعار أو جمع التشكيلة، فإن النسخ المكررة تعني خسارة مباشرة للمال والوقت، وذلك في ثلاثة اتجاهات في نفس الوقت.

أولاً، كل تحميل لصفحة مكررة هو طلب عبر البروكسي. إذا كنت تستخدم بروكسي مدفوع دوار (وللتغلب على حماية Wildberries و Ozon لا يمكنك الاستغناء عن ذلك)، فأنت تدفع مقابل حركة المرور حتى للطلبات غير المفيدة. عند حجم يصل إلى عشرات الآلاف من بطاقات المنتجات، فإن 30-40% من الطلبات الزائدة على النسخ المكررة تزيد بشكل ملحوظ من الاستهلاك.

ثانيًا، تنخفض سرعة الجمع بشكل كبير. إذا كان المحلل الخاص بك قادرًا فعليًا على إجراء 10 طلبات في الثانية، وثلثها يذهب إلى صفحات بنفس البيانات، فإن السرعة الفعلية لجمع المحتوى الفريد تنخفض إلى 6-7 بطاقات في الثانية. في الكتالوجات الكبيرة، هذه هي الفرق بين جمع البيانات في ساعة وجمعها في نصف يوم.

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

أمثلة حقيقية: Wildberries، Ozon، Avito

على Wildberries، يمكن أن يتم تقديم نفس الكتالوج مع معلمات ?sort=popular، ?sort=rate، ?sort=newly، بالإضافة إلى الفلاتر fbrand، fsize، priceU. إذا كان المحلل يجمع الروابط "بطاقة → منتجات مشابهة → مرة أخرى بطاقة"، فإنه يولد بسهولة URL مع تركيبات جميع هذه المعلمات، على الرغم من أن مجموعة المنتجات الداخلية تتداخل بنسبة 90%.

على Ozon، هناك قصة مشابهة مع المعلمة ?sorting= والفلاتر حسب خصائص المنتج - هناك المزيد من التركيبات، لأن كل فئة لديها مجموعة فلاتر خاصة بها (المادة، الحجم، اللون وما إلى ذلك).

على Avito، الألم المنفصل هو معلمات الجيولوكاشن ونطاق البحث (?radius=، ?district=). يمكن أن "تطفو" نفس الإعلان في النتائج مع تركيبات مختلفة من هذه المعلمات، وسيفترض المحلل الساذج أن هذه اكتشافات مختلفة، مما يؤدي إلى تضخيم قاعدة البيانات بسجلات مكررة.

كيف تستهلك النسخ المكررة الميزانية للبروكسي والوقت

دعنا نحسب على مثال افتراضي. لنفترض أن الفئة تحتوي على 500 منتج فريد، ولكن بسبب 8 خيارات للترتيب و 12 تركيبة من الفلاتر الشائعة، يقوم المحلل بدون تطبيع URL بزيارة 4000-5000 صفحة مع القوائم بالإضافة إلى الزيارات المتكررة لنفس البطاقات. إذا كانت تكلفة طلب واحد عبر بروكسي مقيم تعادل وحدة معينة من حركة المرور، فإنك تنفق بشكل ساذج 8-10 مرات أكثر مما تحتاجه للحصول على نفس حجم البيانات الفريدة.

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

في الممارسة العملية، يبدو الأمر هكذا: يريد البائع مراقبة أسعار 200 منافس على Wildberries مرة واحدة في اليوم، ولكن بسبب URLs غير المنظفة، يقوم سكريبته بعمل 15,000 طلب بدلاً من 2,000، ويواجه حدود مجموعة البروكسي ويحصل على بيانات غير مكتملة في المساء بدلاً من الصباح.

كيف تكتشف النسخ المكررة قبل تشغيل المحلل

قبل توسيع نطاق الجمع، من الأفضل قضاء ساعة في تحليل هيكل URL للموقع المستهدف. إليك ترتيب عملي للإجراءات:

افتح الكتالوج المستهدف في المتصفح وقم بتجربة الفلاتر والترتيبات يدويًا - وثق أي معلمات تظهر في شريط العنوان.
تحقق مما إذا كان محتوى الصفحة يتغير عند إضافة معلمة لا تؤثر على النتائج (مثل علامة UTM) - إذا كان المحتوى هو نفسه، يجب تجاهل هذه المعلمة عند الجمع.
انظر إلى rel="canonical" في الشيفرة المصدرية للصفحة - غالبًا ما تشير المواقع إلى أي URL يعتبر "أساسيًا" للنسخ المكررة.
اجمع عينة اختبار صغيرة من 100-200 URL ومررها عبر عملية بسيطة لإزالة التكرار بناءً على المعلمات الرئيسية - انظر إلى مدى تقليص القائمة.
تحقق من robots.txt - أحيانًا تكون هناك توجيهات Disallow لمعلمات URL المخصصة، وهذا أيضًا إشارة إلى أي المعلمات تعتبر "قمامة".

تطبيع URL: القواعد والأمثلة

التطبيع هو تحويل URL إلى شكل موحد قبل اتخاذ القرار بشأن ما إذا كان يجب زيارته. المبدأ الأساسي: تحديد المعلمات "المهمة" (مثل رقم صفحة التصفح أو الفئة) والتخلص من المعلمات "غير المهمة" (الترتيب، UTM، معرفات الجلسة).

مثال عملي لقواعد التطبيع لكتالوج مشابه لـ Wildberries:

import urllib.parse as up

IGNORED_PARAMS = {"sort", "utm_source", "utm_medium", "utm_campaign", "clid", "_openstat"}

def normalize_url(url: str) -> str:
    parsed = up.urlparse(url)
    query = up.parse_qsl(parsed.query)
    # نحتفظ فقط بالمعلمات المهمة، والباقي نتخلص منه
    filtered = [(k, v) for k, v in query if k not in IGNORED_PARAMS]
    filtered.sort()  # نعيد ترتيب المعلمات إلى شكل موحد
    new_query = up.urlencode(filtered)
    return up.urlunparse(parsed._replace(query=new_query))

بعد التطبيع، يتم دمج جميع خيارات نفس القائمة مع ترتيب مختلف في URL واحد. قبل إرسال الطلب عبر البروكسي، يتحقق المحلل مما إذا كان هذا العنوان المنظم قد تم زيارته بالفعل - إذا كان الأمر كذلك، فإنه يتخطاه. هذه هي أرخص طريقة لتقليل عدد الطلبات دون فقدان شمولية البيانات.

بالنسبة للحالات غير المعقدة، يمكن تنفيذ نفس المنطق بدون كود - من خلال إعدادات أداة التحليل: تحديد "تجاهل المعلمات" وإدراج القائمة، أو تعيين تعبير عادي لقطع ذيل URL بعد علامة الاستفهام، إذا كانت المعلمات لا تحمل معلومات مهمة لمهمتك.

إعداد المحلل لتجاهل المعلمات

تدعم معظم الحلول الجاهزة لجمع البيانات من الأسواق ومنشئي التحليل قواعد استثناء معلمات URL على مستوى إعدادات المشروع. إليك ما يجب التحقق منه وضبطه أولاً:

قائمة المعلمات المتجاهلة. أضف إليها جميع المعلمات التي تم العثور عليها في مرحلة تحليل الترتيب، علامات UTM ومعرفات الجلسة.
إزالة التكرار بناءً على هاش URL المنظم. العديد من المحللين يحتفظون بقائمة العناوين التي تمت زيارتها بالفعل - من المهم أن يكون المقارنة على النسخة المنظمة، وليس على السلسلة الأصلية.
تحديد عمق تصفح الفلاتر. إذا كانت المهمة هي جمع تشكيلات الفئة، فإن مرور "أساسي" واحد بدون ترتيبات وفلاتر يكفي، وليس تصفح جميع التركيبات بشكل متكرر.
إعطاء الأولوية للصفحات المتعددة على الفلاتر. إذا كان الموقع يقدم قائمة كاملة من المنتجات من خلال التنقل عبر الصفحات، فإن هذا عادة ما يكون كافيًا - تصفح نفس القائمة مع تطبيق الفلاتر بشكل منفصل يكون زائدًا.

بعد هذه الإعدادات، عادة ما ينخفض حجم الطلبات بمعدل 3-6 مرات حسب مدى "تخصيص" كتالوج الموقع المصدر.

دور البروكسي عند توسيع التحليل

حتى بعد التطبيع المثالي لعنوان URL، يتطلب تحليل الكتالوجات الكبيرة على Wildberries أو Ozon توزيع الطلبات بين العديد من عناوين IP - وإلا ستتتبع حماية مكافحة الروبوتات النشاط غير الطبيعي من مصدر واحد بسرعة. من المهم اختيار نوع البروكسي المناسب للمهمة.

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

بالنسبة للمهام الدقيقة - على سبيل المثال، للتحقق من كيفية عرض سعر منتج معين من جهاز محمول في منطقة معينة - ستكون بروكسي موبايل مفيدة، والتي تحاكي الاتصال عبر مشغل الهاتف المحمول ونادرًا ما تتعرض للحظر بشكل جماعي.

من المهم أن نفهم: الاختيار الصحيح للبروكسي لا يحل محل تطبيع URL، بل يكملها. بدون تنظيف النسخ المكررة، ستقوم فقط بحرق أسرع حتى أفضل مجموعة من عناوين IP. أولاً، قلل عدد الطلبات غير المفيدة، ثم قم بتوسيع المتبقي من خلال تدوير البروكسي - هذا هو الترتيب الذي يوفر أقصى توفير.

قائمة التحقق قبل بدء جمع البيانات

قبل تشغيل المحلل على نطاق واسع، قم بمراجعة قائمة قصيرة من الفحوصات:

نقطة الفحص	لماذا هو ضروري
تم تحديد قائمة معلمات الترتيب والفلاتر	لفهم أي URLs يمكن اعتبارها مكررة
تم إعداد قاعدة تطبيع URL	لدمج النسخ المكررة في عنوان أساسي واحد
تم تفعيل إزالة التكرار بناءً على الهاش	لاستبعاد إعادة تحميل نفس البيانات
تم اختيار نوع البروكسي وفقًا للحجم ودرجة حماية الموقع	لتقليل خطر الحظر وتسريع الجمع
تم تعيين حدود الطلبات على IP مع هامش	لتجنب الحظر الجماعي لمجموعة البروكسي

الخاتمة

الفلاتر، الترتيبات والمعلمات الوظيفية في URL ليست مجرد تفاصيل تقنية، بل هي واحدة من المصادر الرئيسية لحركة المرور غير المفيدة عند تحليل الأسواق. بدون تطبيع URL، يمكن أن يقوم المحلل بعمل 5-10 مرات أكثر من الطلبات اللازمة للحصول على نفس البيانات، مما يؤثر بشكل مباشر على ميزانية البروكسي، سرعة الجمع وخطر الحظر.

الحل بسيط من حيث الصياغة، ولكنه يتطلب الانضباط في مرحلة التحضير: قم بتحليل هيكل URL للموقع المستهدف، حدد أي المعلمات تؤثر على المحتوى وأيها لا تؤثر، قم بإعداد إزالة التكرار بناءً على العنوان المنظم، وبعد ذلك فقط قم بتوسيع الجمع من خلال تدوير البروكسي. إذا كانت مهمتك هي مراقبة أسعار وتشكيلات Wildberries، Ozon أو Avito بشكل مستقر وبكميات كبيرة، فمن الأفضل البدء بـ بروكسي مقيم - فهي توفر أفضل توازن بين ثقة أنظمة مكافحة الروبوتات ومرونة الإعداد لمهمة معينة.