यूआरएल फ़िल्टर से पृष्ठों की डुप्लिकेट: पार्सर की सीमाओं को कैसे नष्ट न करें

क्या आपने Wildberries या Ozon पर पार्सर चलाया, प्रॉक्सी सेट की, और एक घंटे में सीमाओं में फंस गए और कई बैन किए गए IP प्राप्त किए - जबकि आपने केवल कुछ हजार कार्ड इकट्ठा किए? समस्या लगभग हमेशा एक ही होती है: URL पैरामीटर। फ़िल्टर, क्रमबद्धता, पेजिनेशन और UTM-टैग एक कैटलॉग को हजारों तकनीकी डुप्लिकेट में बदल देते हैं, और पार्सर ईमानदारी से सभी को पार करता है, बजाय इसके कि वह अद्वितीय डेटा इकट्ठा करे।

URL पैरामीटर के कारण पृष्ठों का डुप्लिकेट क्या है

पृष्ठ का डुप्लिकेट वह URL है जो तकनीकी रूप से दूसरे से भिन्न है, लेकिन सामग्री वही या लगभग वही है। एक क्लासिक उदाहरण: Wildberries पर महिलाओं के कपड़ों का कैटलॉग /catalog/zhenshchinam/odezhda/platya पर उपलब्ध है, लेकिन वही परिणाम, जो कीमत के अनुसार क्रमबद्ध है, /catalog/zhenshchinam/odezhda/platya?sort=price में बदल जाता है। आकार, ब्रांड, रंग, मूल्य सीमा के अनुसार फ़िल्टर जोड़ें - और आपको सैकड़ों पैरामीटर संयोजन मिलते हैं, जिनमें से प्रत्येक औपचारिक रूप से एक अद्वितीय URL है।

एक जीवित उपयोगकर्ता के लिए यह सुविधाजनक है: फ़िल्टर चुना - आवश्यक उत्पाद देखा। लेकिन पार्सर के लिए, जो लिंक को एक पैटर्न के अनुसार पार करता है या पेजिनेशन का पालन करता है, प्रत्येक ऐसा संयोजन एक अलग पृष्ठ है जिसे लोड करना, पार्स करना और सहेजना आवश्यक है। यदि नियम निर्धारित नहीं किए गए हैं, तो रोबोट अनंत फ़िल्टर की गहराई में गिर जाएगा: कीमत के अनुसार क्रमबद्धता → ब्रांड के अनुसार फ़िल्टर → आकार के अनुसार फ़िल्टर → फिर से क्रमबद्धता, लेकिन अब एक अलग क्रम में। अद्वितीय URL की संख्या तेजी से बढ़ती है, और उनमें उपयोगी डेटा नहीं बढ़ता - ये वही उत्पाद कार्ड हैं, केवल अलग क्रम में या संकुचित सेट में।

डुप्लिकेट की एक अलग श्रेणी 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=)। एक ही विज्ञापन विभिन्न संयोजनों के साथ परिणाम में "उभर सकता है", और एक naive पार्सर इसे विभिन्न खोजों के रूप में मान लेगा, डुप्लिकेट प्रविष्टियों के साथ डेटाबेस को बढ़ा देगा।

डुप्लिकेट प्रॉक्सी बजट और समय को कैसे नष्ट करते हैं

एक उदाहरण पर विचार करें। मान लीजिए, एक श्रेणी में 500 अद्वितीय उत्पाद हैं, लेकिन 8 क्रमबद्धता विकल्पों और 12 लोकप्रिय फ़िल्टर संयोजनों के कारण, पार्सर बिना URL सामान्यीकरण के 500 के बजाय 4000-5000 पृष्ठों को पार करता है, साथ ही एक ही कार्ड पर पुनः प्रवेश करता है। यदि एक अनुरोध निवासी प्रॉक्सी के माध्यम से एक शर्तीय ट्रैफ़िक यूनिट की लागत है, तो naive पार्सिंग के दौरान आप उसी मात्रा में अद्वितीय डेटा प्राप्त करने के लिए 8-10 गुना अधिक खर्च करते हैं।

इससे भी बुरा, एक ही IP से समान URL पर पुनरावृत्त अनुरोध एंटी-बॉट सिस्टम के लिए एक विशिष्ट पैटर्न है। जितनी अधिक आवृत्ति और समानता के अनुरोध होते हैं, उतनी ही तेजी से सुरक्षा सक्रिय होती है। यह एक बंद सर्कल बनाता है: डुप्लिकेट अनुरोधों की संख्या बढ़ाते हैं → प्रॉक्सी पूल पर लोड बढ़ता है → IP तेजी से बैन होते हैं → प्रॉक्सी को अधिक बार बदलना और संग्रह को फिर से शुरू करना पड़ता है → अंतिम संग्रह का समय और लागत और भी बढ़ जाती है।

व्यावहारिक रूप से यह इस तरह दिखता है: एक विक्रेता Wildberries पर 200 प्रतिस्पर्धियों की कीमतों की निगरानी करना चाहता है, लेकिन URL को साफ न करने के कारण उसका स्क्रिप्ट 15,000 अनुरोध करता है, जबकि 2,000 की आवश्यकता होती है, प्रॉक्सी पूल की सीमाओं में फंस जाता है और शाम को सुबह के बजाय अधूरी जानकारी प्राप्त करता है।

पार्सर चलाने से पहले डुप्लिकेट कैसे पहचानें

संग्रह को स्केल करने से पहले, लक्ष्य वेबसाइट के URL संरचना का विश्लेषण करने के लिए एक घंटे का समय निकालना चाहिए। यहाँ कार्यवाही का व्यावहारिक क्रम है:

ब्राउज़र में लक्ष्य कैटलॉग खोलें और फ़िल्टर और क्रमबद्धता को मैन्युअल रूप से पार करें - यह सुनिश्चित करें कि कौन से पैरामीटर एड्रेस बार में प्रकट होते हैं।
जांचें कि क्या पृष्ठ की सामग्री उस पैरामीटर को जोड़ने पर बदलती है जो परिणाम पर प्रभाव नहीं डालता (जैसे, UTM-टैग) - यदि सामग्री वही है, तो इस पैरामीटर को संग्रह के दौरान अनदेखा करना चाहिए।
पृष्ठ के स्रोत कोड में rel="canonical" पर ध्यान दें - वेबसाइटें अक्सर स्वयं संकेत देती हैं कि कौन सा URL डुप्लिकेट विकल्पों के लिए "मुख्य" माना जाता है।
100-200 URL का एक छोटा परीक्षण नमूना इकट्ठा करें और इसे प्रमुख पैरामीटर के अनुसार सरल डेडुप्लिकेशन के माध्यम से चलाएँ - देखें कि सूची कितनी कम हो जाती है।
robots.txt की जांच करें - कभी-कभी वहाँ पहले से ही पैरामीटर वाले URL के लिए Disallow निर्देश होते हैं, यह भी संकेत है कि कौन से पैरामीटर "कचरा" माने जाते हैं।

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 पूल को भी तेजी से जला देंगे। पहले बेकार अनुरोधों की संख्या को कम करें, फिर बचे हुए को प्रॉक्सी के रोटेशन के माध्यम से स्केल करें - यही क्रम अधिकतम बचत देता है।

डेटा संग्रह शुरू करने से पहले चेकलिस्ट

पार्सर को युद्ध के पैमाने पर चलाने से पहले, संक्षिप्त चेकलिस्ट पर जाएँ:

चेक बिंदु	क्यों आवश्यक है
क्रमबद्धता और फ़िल्टर के पैरामीटर की सूची पहचान ली गई है	यह समझना कि कौन से URL डुप्लिकेट माने जा सकते हैं
URL सामान्यीकरण का नियम सेट किया गया है	डुप्लिकेट को एक कैनोनिकल पते में समाहित करना
हैश द्वारा डेडुप्लिकेशन चालू है	एक ही डेटा को फिर से लोड करने से रोकना
प्रॉक्सी का प्रकार मात्रा और सुरक्षा की आक्रामकता के अनुसार चुना गया है	बैन के जोखिम को कम करना और संग्रह को तेज करना
IP पर अनुरोधों की सीमाएँ पर्याप्त रूप से निर्धारित की गई हैं	प्रॉक्सी पूल के बड़े पैमाने पर बैन से बचना

निष्कर्ष

URL में फ़िल्टर, क्रमबद्धता और सहायक पैरामीटर केवल तकनीकी विवरण नहीं हैं, बल्कि मार्केटप्लेस के पार्सिंग के दौरान बेकार ट्रैफ़िक के मुख्य स्रोतों में से एक हैं। URL सामान्यीकरण के बिना, पार्सर 5-10 गुना अधिक अनुरोध कर सकता है जितना कि वही डेटा प्राप्त करने के लिए आवश्यक है, जो सीधे प्रॉक्सी बजट, संग्रह की गति और ब्लॉक के जोखिम को प्रभावित करता है।

समाधान सूत्र में सरल है, लेकिन तैयारी के चरण में अनुशासन की आवश्यकता होती है: लक्ष्य वेबसाइट के URL संरचना का विश्लेषण करें, यह निर्धारित करें कि कौन से पैरामीटर सामग्री को प्रभावित करते हैं और कौन से नहीं, सामान्यीकृत पते पर डेडुप्लिकेशन सेट करें और केवल इसके बाद प्रॉक्सी के रोटेशन के माध्यम से संग्रह को स्केल करें। यदि आपका कार्य Wildberries, Ozon या Avito पर कीमतों और विविधता की स्थिर निगरानी करना है, तो निवासी प्रॉक्सी से शुरू करना उचित है - ये एंटी-बॉट सिस्टम के प्रति विश्वास और विशिष्ट कार्य के लिए सेटिंग्स में लचीलापन के बीच सबसे अच्छा संतुलन प्रदान करते हैं।