تله خزنده یا Crawler Trap چیست

مخاطب این مقاله

 مدیران سایت، متخصصان SEO، توسعه دهندگان وب، مدیران سرور و صاحبان سایت های دارای URLهای پویا.

خلاصه یک جمله ای مقاله

Crawler Trap زمانی رخ می دهد که ساختار سایت، خزنده را وارد مجموعه بزرگی یا تقریبا نامحدود از URLهای کم ارزش، تکراری یا بی اعتبار کند.

تله خزنده چیست؟ بررسی Crawler Trap، علت ایجاد و روش جلوگیری از آن

اگر یک ربات موتور جستجو یا Web Crawler بتواند در سایت شما دائما URLهای جدیدی پیدا کند که ارزش محتوایی مستقلی ندارند، ممکن است سایت وارد وضعیتی شود که به آن تله خزنده یا Crawler Trap می گویند. در مستندات Google برای وضعیت های مشابه اصطلاح Infinite Space یا فضای تقریبا بی نهایت URL نیز به کار رفته است.

در یک تله خزنده، مسئله فقط تعداد زیاد صفحات نیست. مشکل اصلی این است که خزنده احساس می کند هنوز URL جدیدی برای بررسی وجود دارد و در نتیجه می تواند بخش بزرگی از درخواست های خود را صرف صفحاتی کند که محتوای جدید یا ارزش قابل توجهی ندارند. Google هشدار می دهد که وجود تعداد بسیار زیاد URLهای کم ارزش می تواند منابع خزش را مصرف کند و کشف صفحات مفیدتر را کندتر کند.

بنابراین پاسخ کوتاه به پرسش تله خزنده چیست این است: تله خزنده یک ساختار URL یا رفتار نرم افزاری است که فضای خزش بسیار بزرگ یا تقریبا نامحدودی ایجاد می کند و ربات ها را به دنبال کردن URLهای غیرضروری سوق می دهد.

Crawler Trap دقیقا چگونه کار می کند؟

خزنده های وب URLها را کشف می کنند، آنها را درخواست می کنند، محتوای پاسخ را بررسی می کنند و لینک های جدید را برای بررسی های بعدی وارد صف می کنند. Search Engineها از همین فرایند برای کشف صفحات وب استفاده می کنند. RFC 9309 نیز Crawler را یک Client خودکار معرفی می کند که می تواند URIها را به صورت بازگشتی دنبال کند.

مشکل زمانی ایجاد می شود که هر URL به مجموعه دیگری از URLهای متفاوت منتهی شود و این زنجیره مرز منطقی مشخصی نداشته باشد.

برای مثال، تصور کنید سایتی یک تقویم دارد که برای ماه بعد همیشه یک URL جدید تولید می کند. خزنده می تواند از سال جاری به سال های بسیار دور حرکت کند، در حالی که اکثر آن صفحات هیچ محتوای ارزشمندی ندارند. Google این سناریو را یکی از نمونه های کلاسیک Infinite Space معرفی کرده است.

همین وضعیت می تواند در سیستم های فیلتر، Pagination، جستجوی داخلی، شناسه Session، لینک کوتاه و Routeهای پویا نیز رخ دهد.

مهم ترین دلایل ایجاد تله خزنده

تولید URLهای پویا و بدون محدودیت

یکی از خطرناک ترین طراحی ها حالتی است که برنامه بتواند برای یک منبع واحد تعداد بسیار زیادی URL متفاوت تولید کند.

برای مثال ممکن است یک مقاله از طریق صدها پارامتر، شناسه موقت یا لینک کوتاه متفاوت قابل دسترسی باشد. اگر این URLها در صفحات سایت ظاهر شوند، خزنده می تواند آنها را به عنوان آدرس های مستقل کشف کند.

Google توصیه می کند ساختار URL به گونه ای طراحی شود که خزنده مجبور نباشد تعداد زیادی URL پیچیده یا تکراری را بررسی کند.

Faceted Navigation یا فیلترهای ترکیبی

فروشگاه ها و سایت های دارای فیلتر معمولا یکی از مستعدترین معماری ها برای Crawler Trap هستند.

فرض کنید کاربر بتواند محصولات را همزمان بر اساس برند، قیمت، رنگ، اندازه، وضعیت موجودی و چند ویژگی دیگر فیلتر کند. ترکیب این متغیرها می تواند تعداد بسیار بزرگی URL ایجاد کند.

Google توضیح می دهد که Faceted Navigation می تواند یک فضای URL تقریبا نامحدود ایجاد کند. خزنده قبل از مشاهده صفحه نمی تواند همیشه تشخیص دهد URL جدید ارزشمند است یا خیر، بنابراین ممکن است تعداد زیادی از این آدرس ها را درخواست کند.

Pagination نامحدود یا اشتباه

صفحه بندی نیز می تواند تله ایجاد کند.

فرض کنید مجموعه مطالب فقط 30 صفحه دارد، اما سرور برای آدرس صفحه 100000 نیز پاسخ 200 OK برگرداند. خزنده ممکن است تصور کند صفحات بیشتری وجود دارند و بررسی را ادامه دهد.

Google در راهنماهای مربوط به Infinite Space دقیقا به سناریوهایی اشاره کرده است که صفحات خارج از محدوده همچنان پاسخ موفق HTTP می دهند.

لینک کوتاه تصادفی

سیستم Short Link در صورت طراحی اشتباه می تواند یک Crawler Trap جدی ایجاد کند.

فرض کنید برای هر مقاله یک لینک کوتاه وجود دارد، اما برنامه در هر بار نمایش صفحه یک Token تصادفی جدید تولید می کند:

/s/a8fk21qz

در بار بعد:

/s/j3m9rx71

و سپس یک شناسه جدید دیگر.

اگر خزنده هر بار URL تازه ای مشاهده کند، مجموعه آدرس ها به مرور رشد می کند؛ در حالی که همه آنها ممکن است به یک محتوای واحد اشاره کنند.

طراحی بهتر این است که هر منبع یک Short URL پایدار داشته باشد یا سیستم فقط در زمان درخواست واقعی کاربر لینک جدید ایجاد کند.

پاسخ 200 برای URLهای نامعتبر

این مورد اهمیت زیادی دارد.

اگر کاربر یا خزنده آدرسی را درخواست کند که واقعا وجود ندارد، اما Application همچنان 200 OK برگرداند، موتور جستجو ممکن است با وضعیت Soft 404 مواجه شود.

Google توصیه می کند برای منابعی که واقعا وجود ندارند کد HTTP مناسب مانند 404 یا در شرایط حذف دائمی 410 ارسال شود. صفحات Soft 404 می توانند همچنان Crawl شوند و منابع خزش را هدر دهند.

برای مثال، اگر تنها این Token معتبر باشد:

/short/3fa91ac2

درخواست یک Token ساختگی مانند:

/short/xxxxxxxx

نباید همان صفحه عمومی را همراه با 200 OK نمایش دهد.

Application باید وجود Token را بررسی کند و در صورت نامعتبر بودن پاسخ درست HTTP بدهد.

شناسه Session و پارامترهای غیرضروری

قرار دادن اطلاعات Session یا متغیرهایی که محتوای صفحه را تغییر نمی دهند در URL می تواند نسخه های زیادی از یک صفحه تولید کند.

Google توصیه می کند تا جای ممکن Session ID را از URL خارج کنید و برای اطلاعاتی که نیازی به حضور در آدرس ندارند از روش هایی مانند Cookie استفاده کنید.

لینک های نسبی اشتباه

حتی یک خطای ساده در Relative URL می تواند ساختارهای عجیبی ایجاد کند.

Google نمونه ای را توضیح داده است که یک لینک نسبی اشتباه می تواند مسیرهای تکرارشونده و URLهای ساختگی ایجاد کند. اگر سرور برای این مسیرهای غیرواقعی پاسخ صحیح خطا ندهد، مشکل بزرگ تر می شود.

تله خزنده چه تاثیری بر SEO دارد؟

خود وجود یک URL اضافی لزوما رتبه سایت را کاهش نمی دهد. مشکل زمانی شکل می گیرد که تعداد URLهای بی ارزش یا تکراری آن قدر افزایش پیدا کند که خزش سایت ناکارآمد شود.

Google مفهوم Crawl Budget یا بودجه خزش را مجموعه URLهایی تعریف می کند که سیستم خزنده می تواند و می خواهد در یک سایت Crawl کند. این موضوع بیشترین اهمیت را برای سایت های بزرگ، سایت هایی با تغییرات سریع یا سایت هایی دارد که حجم بزرگی از URLهای آنها در وضعیت کشف شده اما ایندکس نشده قرار دارد.

بنابراین نباید هر سایت کوچک را صرفا به دلیل چند URL اضافه گرفتار بحران Crawl Budget دانست.

اما در مقیاس بالا، URLهای کم ارزش، محتوای تکراری، Soft 404 و Infinite Space می توانند فعالیت خزنده را از صفحات مهم منحرف کنند و کشف محتوای جدید را به تاخیر بیندازند.

از طرف دیگر، هر درخواست HTTP هزینه دارد. Application ممکن است برای پاسخ به یک URL پویا به PHP، Laravel، WordPress، Database، Cache Server یا سرویس های دیگر مراجعه کند. بنابراین یک Crawler Trap می تواند بدون اینکه بازدیدکننده واقعی زیادی وجود داشته باشد، CPU، RAM، Database Connection و پهنای باند سرور را مصرف کند.

چگونه تله خزنده را تشخیص دهیم؟

بررسی Access Log سرور

یکی از دقیق ترین منابع برای تشخیص Crawler Trap، Access Log است.

دنبال الگوهایی مانند موارد زیر باشید:

• هزاران URL متفاوت در یک Route مشخص
• تغییر مداوم Token یا Query Parameter
• تعداد زیاد درخواست از یک Crawler
• درخواست Pagination خارج از محدوده
• پاسخ 200 برای URLهایی که نباید وجود داشته باشند
• تکرار سریع درخواست روی صفحات کم ارزش

اگر Route مشخصی مانند /filter/، /search/، /short/ یا /calendar/ سهم غیرعادی از درخواست ها دارد، باید نحوه تولید URL آن را بررسی کنید.

بررسی Crawl Stats در Google Search Console

Google توصیه می کند برای بررسی رفتار Googlebot از گزارش Crawl Stats استفاده کنید. این گزارش می تواند تاریخچه خزش و مشکلات Host Availability را نشان دهد. برای بررسی یک URL مشخص نیز می توان از URL Inspection استفاده کرد.

افزایش ناگهانی تعداد Requestها بدون افزایش متناسب محتوای واقعی می تواند نشانه ای برای بررسی عمیق تر باشد.

بررسی Page Indexing

وجود حجم بزرگی از URLهای کم ارزش، Soft 404 یا صفحات کشف شده اما ایندکس نشده می تواند سرنخ دیگری باشد.

البته هر URL ایندکس نشده به معنی Crawler Trap نیست. باید این داده را همراه با Server Log، معماری URL و رفتار Application بررسی کرد.

آزمایش URLهای ساختگی

یک آزمایش ساده نیز بسیار موثر است.

اگر مسیر سایت به شکل زیر باشد:

/article-short/{token}

چند Token کاملا ساختگی درخواست کنید.

اگر همه آنها پاسخ 200 OK و محتوای معتبر دریافت کنند، طراحی Route نیاز به بررسی جدی دارد.

URL نامعتبر باید رفتار مشخص و محدودی داشته باشد.

چگونه Crawler Trap را برطرف کنیم؟

ابتدا منبع تولید URL را متوقف کنید

مهم ترین اصل این است که ریشه مشکل را اصلاح کنید.

اگر Application دائما URL جدید تولید می کند، صرفا Block کردن یک Bot مشکل معماری را حل نمی کند. ممکن است Googlebot، Bingbot یا Crawler دیگری دوباره همان فضای URL را کشف کند.

موجودی URL یا URL Inventory باید محدود، قابل پیش بینی و متناسب با محتوای واقعی سایت باشد.

برای URL نامعتبر 404 یا 410 برگردانید

اگر یک Resource وجود ندارد، پاسخ موفق ندهید.

Google برای URLهای حذف شده یا ناموجود استفاده از 404 یا 410 را توصیه می کند. همچنین تاکید می کند Soft 404 می تواند Crawl Budget را هدر دهد.

این موضوع برای لینک کوتاه، Pagination، فیلتر و شناسه های تصادفی اهمیت زیادی دارد.

از robots.txt برای کنترل Crawl استفاده کنید

اگر دسته ای از URLها برای موتور جستجو ارزش ندارند، می توان Crawl آنها را با robots.txt محدود کرد.

Google برای URLهایی که فضای بی نهایت ایجاد می کنند، Dynamic URLها و برخی Faceted Navigationها استفاده از robots.txt را توصیه می کند.

اما باید تفاوت مهمی را در نظر گرفت:

robots.txt یک سیستم کنترل دسترسی یا Firewall نیست.

RFC 9309 صراحتا Robots Exclusion Protocol را مکانیزم Authorization نمی داند. این فایل به Crawler سازگار اعلام می کند چه مسیری را Crawl نکند، اما نباید آن را ابزار امنیتی برای جلوگیری قطعی از HTTP Request در نظر گرفت.

تغییر robots.txt ممکن است فوری اثر نکند

Crawlerها می توانند نسخه robots.txt را Cache کنند. RFC 9309 می گوید خزنده ها می توانند این فایل را Cache کنند و در شرایط عادی بهتر است نسخه Cache شده را بیش از 24 ساعت نگه ندارند.

در نتیجه ممکن است بعد از تغییر robots.txt برای مدتی همچنان درخواست هایی از یک Crawler مشاهده کنید.

اگر هدف شما جلوگیری قطعی از دسترسی یک Bot مزاحم است، باید علاوه بر robots.txt از کنترل در Web Server، WAF، CDN یا Firewall استفاده کنید.

Short Linkها را پایدار طراحی کنید

اگر سایت لینک کوتاه تولید می کند، بهتر است یک Resource مشخص تا جای ممکن Short URL ثابت داشته باشد.

تولید Token جدید در هر Page View طراحی مناسبی برای سیستم اشتراک گذاری عمومی نیست.

همچنین Token باید قبل از بارگذاری کامل صفحه اعتبارسنجی شود. Token نامعتبر نباید باعث اجرای Queryهای سنگین، Render کامل Template یا پاسخ 200 شود.

Sitemap را تمیز نگه دارید

Sitemap باید URLهایی را شامل شود که واقعا می خواهید موتور جستجو آنها را Crawl و بررسی کند.

Google توصیه می کند URLهایی که نمی خواهید در Search ظاهر شوند داخل Sitemap قرار ندهید، زیرا این کار می تواند Crawl منابع غیرضروری را افزایش دهد.

Short URLهای موقت، URLهای Filter و نسخه های تکراری معمولا نباید بدون دلیل وارد Sitemap اصلی شوند.

Redirect را فقط زمانی استفاده کنید که مقصد واقعی وجود دارد

اگر یک URL قدیمی واقعا به URL جدید مشخصی منتقل شده است، Redirect می تواند منطقی باشد.

اما URL تصادفی یا نامعتبر را نباید صرفا به Homepage یا یک صفحه عمومی Redirect کرد. برای منبعی که وجود ندارد، پاسخ Not Found معمولا سیگنال دقیق تری است.

Google نیز برای ترکیب های نامعتبر در Faceted Navigation توصیه می کند مستقیما HTTP 404 برگردد و سیستم آنها را به یک صفحه خطای عمومی Redirect نکند.

robots.txt به تنهایی برای مقابله با Bot مخرب کافی نیست

این نکته یکی از تفاوت های مهم میان SEO و Security است.

اگر Googlebot را مدیریت می کنید، robots.txt ابزار استاندارد و مناسبی برای کنترل Crawl است.

اگر یک Bot ناشناس، Scraper یا Crawler متجاوز عمدا robots.txt را نادیده می گیرد، مسئله دیگر فقط SEO نیست. در این وضعیت مدیر سایت باید محدودیت را در سطح Web Server، Reverse Proxy، CDN، WAF یا Firewall اعمال کند.

بنابراین دو مفهوم را باید جدا نگه داشت:

Crawl Control: تعیین می کند یک خزنده سازگار چه URLهایی را Crawl کند.

Access Control: تعیین می کند چه Clientهایی اساسا اجازه دریافت پاسخ از سرور را دارند.

Robots Exclusion Protocol برای مورد اول طراحی شده است، نه مورد دوم.

جلوگیری از دسترسی خزنده مزاحم با .htaccess در LiteSpeed

اگر یک خزنده robots.txt را رعایت نکند یا ادامه درخواست های آن باعث افزایش بار سرور شود، می توان دسترسی آن را در سطح Web Server مسدود کرد. در سرورهای LiteSpeed Web Server فایل .htaccess یکی از روش های عملی برای این کار است.

LiteSpeed امکان شناسایی درخواست بر اساس User-Agent و مسیر URL را از طریق Rewrite Rule فراهم می کند. همچنین قابلیت اختصاصی blockbot می تواند اتصال Client تطبیق یافته با Rule را در سطح LiteSpeed متوقف کند؛ بنابراین درخواست پیش از رسیدن به Applicationهایی مانند Laravel یا WordPress قطع می شود. مستندات رسمی LiteSpeed استفاده از [E=blockbot:1] را برای مقابله با Botهایی که درخواست های سنگین ایجاد می کنند معرفی کرده است.

برای مثال، فرض کنید خزنده meta-externalagent تعداد زیادی درخواست به لینک های کوتاه موجود در مسیرهای /asl/ و /psl/ ارسال می کند. در LiteSpeed می توان Rule زیر را در فایل .htaccess اصلی سایت و پیش از Rewrite Ruleهای Application قرار داد:

 # -------------------------------------------------------------------
# Programmer       : Ebrahim Shafiei (EbraSha)
# Email            : [email protected]
# -------------------------------------------------------------------

<IfModule LiteSpeed>
    RewriteEngine On

    RewriteCond %{HTTP_USER_AGENT} meta-externalagent [NC]
    RewriteCond %{REQUEST_URI} ^/(asl|psl)/ [NC]
    RewriteRule .* - [E=blockbot:1]
</IfModule>

 

این Rule دو شرط را همزمان بررسی می کند. ابتدا User-Agent باید شامل meta-externalagent باشد و سپس درخواست باید به یکی از مسیرهای /asl/ یا /psl/ مربوط باشد. در نتیجه سایر کاربران، موتورهای جستجو و حتی همان خزنده در مسیرهای دیگر سایت تحت تاثیر این قانون قرار نمی گیرند.

این روش نسبت به Block کردن یک محدوده IP معمولا کنترل دقیق تری ایجاد می کند؛ زیرا IPهای یک سرویس ممکن است متعدد یا متغیر باشند. با این حال، User-Agent نیز قابل جعل است و نباید آن را مکانیزم احراز هویت یا کنترل امنیتی مطلق در نظر گرفت.

چه زمانی Crawler Trap خطرناک تر است؟

شدت مشکل به معماری سایت بستگی دارد.

سایتی با چند صد صفحه ممکن است تاثیر قابل توجهی از Crawl Budget احساس نکند. Google نیز راهنمای Crawl Budget خود را عمدتا برای سایت های بسیار بزرگ، سایت های متوسط با تغییرات سریع یا سایت هایی با حجم زیاد URLهای کشف شده اما ایندکس نشده ارائه کرده است.

اما حتی در سایت کوچک، یک تله خزنده می تواند از نظر منابع سرور مشکل ساز شود. اگر هر URL باعث Query سنگین Database، اجرای PHP یا Render کامل صفحه شود، هزاران Request غیرضروری می توانند بار واقعی ایجاد کنند.

در نتیجه Crawler Trap را باید از دو زاویه بررسی کرد: Crawl Efficiency و Server Performance.

بهترین معماری برای جلوگیری از تله خزنده

یک معماری سالم چند ویژگی اصلی دارد:

هر محتوای مستقل تا جای ممکن URL اصلی مشخصی دارد. URLهای موقت بدون دلیل در HTML منتشر نمی شوند. Routeهای دارای شناسه فقط شناسه معتبر را قبول می کنند. URL نامعتبر پاسخ HTTP صحیح دریافت می کند. Pagination سقف منطقی دارد. ترکیب Filterها کنترل می شود و Sitemap فقط URLهای مورد نیاز را معرفی می کند.

همچنین توسعه دهنده باید URL Generation را بخشی از معماری سیستم بداند، نه صرفا یک موضوع ظاهری.

Google تاکید می کند که URLهای پیچیده، تکراری و فضای URL نامحدود می توانند Crawl سایت را ناکارآمد کنند.

پرسش های متداول

تله خزنده چیست؟

تله خزنده یا Crawler Trap وضعیتی است که ساختار سایت تعداد بسیار بزرگی URL کم ارزش، تکراری یا نامعتبر ایجاد می کند و خزنده را به ادامه بررسی آنها سوق می دهد. Google برای بسیاری از این وضعیت ها اصطلاح Infinite Space را به کار می برد.

آیا Crawler Trap باعث افت رتبه گوگل می شود؟

الزاما افت رتبه مستقیم ایجاد نمی کند. مشکل اصلی، خزش ناکارآمد، مصرف منابع سرور و در سایت های بزرگ احتمال کاهش سرعت کشف محتوای مهم است. Google اعلام کرده URLهای کم ارزش و Infinite Space می توانند منابع Crawl را از محتوای مفید منحرف کنند.

آیا robots.txt مشکل Crawler Trap را کامل حل می کند؟

خیر. robots.txt می تواند Crawl برخی مسیرها را برای ربات های سازگار محدود کند، اما ریشه تولید URL را اصلاح نمی کند و ابزار Access Control نیز نیست.

برای URL تصادفی نامعتبر باید 404 برگردانیم یا 200؟

اگر URL واقعا هیچ Resource معتبری ندارد، باید وضعیت مناسب Not Found مانند 404 برگردد. پاسخ 200 برای صفحه ناموجود می تواند به Soft 404 منجر شود.

چگونه بفهمیم Googlebot بیش از حد سایت را Crawl می کند؟

Crawl Stats در Google Search Console و Access Log سرور دو منبع اصلی برای تحلیل هستند. Google نیز برای بررسی رفتار خزنده و Host Availability استفاده از Crawl Stats را توصیه می کند.