چرا فیلترها و مرتب‌سازی‌ها در URL باعث تولید صفحات تکراری و مصرف محدودیت‌های پارسر می‌شوند

پارسر را در 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 به‌طور متناسب با تعداد درخواست‌ها افزایش می‌یابد. سیستم‌های ضد ربات بازارها فراوانی درخواست‌ها از یک آدرس را محاسبه می‌کنند. اگر شما سه برابر بیشتر از آنچه که برای جمع‌آوری داده‌های هدف نیاز دارید درخواست کنید، سه برابر سریع‌تر «اعتبار اعتماد» پروکسی را تمام می‌کنید و به CAPTCHA یا مسدودیت می‌افتید.

نمونه‌های واقعی: Wildberries، Ozon، Avito

در Wildberries یک کاتالوگ یکسان می‌تواند با پارامترهای ?sort=popular, ?sort=rate, ?sort=newly ارائه شود، به‌علاوه فیلترها fbrand, fsize, priceU. اگر پارسر لینک‌ها را به‌صورت «کارت → کالاهای مشابه → دوباره کارت» جمع‌آوری کند، به راحتی URLهایی با ترکیب‌های همه این پارامترها تولید می‌کند، در حالی که مجموعه کالاها درون آن‌ها 90% همپوشانی دارد.

در Ozon داستان مشابهی با پارامتر ?sorting= و فیلترها بر اساس ویژگی‌های کالا وجود دارد — در آنجا ترکیب‌ها حتی بیشتر است، زیرا هر دسته فیلترهای خاص خود را دارد (مواد، حجم، رنگ و غیره).

در Avito درد جداگانه — پارامترهای جغرافیایی و شعاع جستجو (?radius=, ?district=). یک آگهی یکسان می‌تواند با ترکیب‌های مختلف این پارامترها در خروجی «ظاهر شود»، و پارسر ساده این را به‌عنوان یافته‌های مختلف در نظر می‌گیرد و پایگاه داده را با رکوردهای تکراری بزرگ می‌کند.

چگونه تکرارها بودجه پروکسی و زمان را مصرف می‌کنند

بیایید در یک مثال فرضی حساب کنیم. فرض کنید، یک دسته 500 کالای منحصر به فرد دارد، اما به دلیل 8 گزینه مرتب‌سازی و 12 ترکیب فیلترهای محبوب، پارسر بدون نرمال‌سازی URL به جای 500، 4000-5000 صفحه با لیست را بررسی می‌کند، به‌علاوه ورودهای تکراری به همان کارت‌ها. اگر یک درخواست از طریق پروکسی مقیم هزینه یک واحد ترافیک داشته باشد، در یک بررسی ساده شما 8-10 برابر بیشتر از آنچه برای دریافت همان حجم داده‌های منحصر به فرد نیاز دارید، هزینه می‌کنید.

بدتر از آن، درخواست‌های تکراری از یک IP به URLهای مشابه — یک الگوی مشخص برای سیستم‌های ضد ربات است. هرچه فراوانی و یکنواختی درخواست‌ها بیشتر باشد، حفاظت سریع‌تر فعال می‌شود. این یک حلقه بسته ایجاد می‌کند: تکرارها تعداد درخواست‌ها را افزایش می‌دهند → بار بر روی مجموعه پروکسی افزایش می‌یابد → IPها سریع‌تر مسدود می‌شوند → مجبور به تغییر پروکسی و راه‌اندازی مجدد جمع‌آوری می‌شوید → زمان و هزینه نهایی پارسینگ حتی بیشتر افزایش می‌یابد.

در عمل اینگونه به نظر می‌رسد: فروشنده می‌خواهد قیمت 200 رقیب را در Wildberries روزی یک بار نظارت کند، اما به دلیل URLهای ناپاک، اسکریپت او 15,000 درخواست به جای 2,000 انجام می‌دهد، به محدودیت‌های مجموعه پروکسی برخورد می‌کند و به جای صبح، داده‌های ناقص را تا عصر دریافت می‌کند.

چگونه تکرارها را قبل از راه‌اندازی پارسر شناسایی کنیم

قبل از اینکه جمع‌آوری را مقیاس‌گذاری کنید، بهتر است یک ساعت را صرف تحلیل ساختار URL سایت هدف کنید. در اینجا ترتیب عملیاتی وجود دارد:

1. کاتالوگ هدف را در مرورگر باز کنید و به‌صورت دستی فیلترها و مرتب‌سازی‌ها را بررسی کنید — ثبت کنید که کدام پارامترها در نوار آدرس ظاهر می‌شوند.
2. بررسی کنید که آیا محتوای صفحه با اضافه کردن پارامتری که بر خروجی تأثیر نمی‌گذارد (به‌عنوان مثال، برچسب UTM) تغییر می‌کند یا خیر — اگر محتوا همان باشد، این پارامتر باید در جمع‌آوری نادیده گرفته شود.
3. به rel="canonical" در کد منبع صفحه نگاه کنید — سایت‌ها اغلب خودشان نشان می‌دهند که کدام URL به‌عنوان «اصلی» برای گزینه‌های تکراری در نظر گرفته می‌شود.
4. یک نمونه کوچک آزمایشی از 100-200 URL جمع‌آوری کنید و آن را از طریق یک ددآپلیکیشن ساده بر اساس پارامترهای کلیدی عبور دهید — ببینید لیست چقدر کاهش می‌یابد.
5. 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ها را می‌سوزانید. ابتدا تعداد درخواست‌های بی‌فایده را کاهش دهید، سپس باقی‌مانده را از طریق چرخش پروکسی مقیاس‌گذاری کنید — دقیقاً به همین ترتیب این بیشترین صرفه‌جویی را به همراه دارد.

چک‌لیست قبل از راه‌اندازی جمع‌آوری داده‌ها

قبل از اینکه پارسر را در مقیاس واقعی راه‌اندازی کنید، به یک لیست کوتاه از بررسی‌ها بپردازید:

مورد بررسی	چرا نیاز است
فهرست پارامترهای مرتب‌سازی و فیلتر شناسایی شده است	درک اینکه کدام URLها می‌توانند تکراری در نظر گرفته شوند
قانون نرمال‌سازی URL تنظیم شده است	تکرارها را به یک آدرس کاننیکال کاهش دهید
ددآپلیکیشن بر اساس هش فعال است	از بارگذاری مجدد داده‌های مشابه جلوگیری کنید
نوع پروکسی بر اساس حجم و شدت حفاظت انتخاب شده است	خطر مسدود شدن را کاهش دهید و جمع‌آوری را تسریع کنید
محدودیت‌های درخواست‌ها بر روی IP با احتیاط تنظیم شده‌اند	از مسدود شدن انبوه مجموعه پروکسی جلوگیری کنید

نتیجه‌گیری

فیلترها، مرتب‌سازی‌ها و پارامترهای خدماتی در URL — این‌ها تنها یک جزئیات فنی نیستند، بلکه یکی از منابع اصلی ترافیک بی‌فایده در هنگام پارسینگ بازارها هستند. بدون نرمال‌سازی URL، پارسر می‌تواند 5-10 برابر بیشتر از آنچه برای دریافت همان داده‌ها نیاز دارد، درخواست کند، که به‌طور مستقیم بر بودجه پروکسی، سرعت جمع‌آوری و خطر مسدودیت تأثیر می‌گذارد.

راه‌حل ساده است، اما نیاز به انضباط در مرحله آماده‌سازی دارد: ساختار URL سایت هدف را تحلیل کنید، مشخص کنید کدام پارامترها بر محتوا تأثیر می‌گذارند و کدام نه، ددآپلیکیشن بر اساس آدرس نرمال‌شده را تنظیم کنید و فقط پس از آن جمع‌آوری را از طریق چرخش پروکسی مقیاس‌گذاری کنید. اگر هدف شما نظارت پایدار بر قیمت‌ها و تنوع در Wildberries، Ozon یا Avito در حجم بالا است، بهتر است با پروکسی‌های مقیم شروع کنید — آن‌ها بهترین تعادل را بین اعتماد سیستم‌های ضد ربات و انعطاف‌پذیری تنظیمات برای وظیفه خاص شما ارائه می‌دهند.