متخصص SEO یک بررسی فنی از یک سایت بزرگ را آغاز می‌کند — و پس از 10 دقیقه، Screaming Frog شروع به نمایش مداوم 403 Forbidden یا 429 Too Many Requests می‌کند. سرور امنیتی کرالر را به عنوان یک ربات مهاجم شناسایی کرده و آدرس IP را مسدود کرده است. نتیجه — بررسی باید دوباره آغاز شود و به مشتری توضیح داده شود که چرا گزارش تأخیر داشته است. این مشکل با تنظیم صحیح پروکسی برای کرالر حل می‌شود — بیایید بررسی کنیم که چگونه.
چرا سایت‌ها Screaming Frog را در هنگام بررسی مسدود می‌کنند
Screaming Frog، Sitebulb، JetOctopus و Netpeak Spider به طور فنی مشابه ربات‌های موتورهای جستجو عمل می‌کنند: آنها به سرعت هزاران URL را به طور متوالی مرور کرده، HTML، CSS، JS و تصاویر را دانلود می‌کنند و ریدایرکت‌ها و کدهای وضعیت را بررسی می‌کنند. از نظر امنیت سایت (Cloudflare، Qrator، DDoS-Guard، WAF داخلی هاستینگ) این فعالیت به عنوان یک فعالیت مشکوک به نظر می‌رسد — درخواست‌های زیادی از یک IP در مدت زمان کوتاه.
مسدودیت‌ها به ویژه در هنگام بررسی اتفاق می‌افتند:
- فروشگاه‌های اینترنتی بزرگ با زیرساختی مشابه Wildberries که دارای حفاظت خود از پارسینگ هستند؛
- سایت‌هایی که در Cloudflare هستند و حالت "Under Attack" یا سطح امنیتی بالا فعال است؛
- پورتال‌هایی با محتوای دینامیک که هر درخواست بار سنگینی بر روی سرور ایجاد می‌کند (جستجو، فیلترها، لیست محصولات)؛
- سایت‌های رقبایی که شما آنها را از دامنه خود تحلیل می‌کنید — آنها دلیلی برای اعتماد به IP شما ندارند.
پیچیدگی اضافی: اگر یک آژانس یک IP استاتیک برای دفتر خود داشته باشد و بررسی سایت‌ها به طور منظم انجام شود (چندین مشتری در روز)، این IP به سرعت در لیست سیاه سیستم‌های امنیتی قرار می‌گیرد. پس از آن، نه تنها بررسی‌های فعلی، بلکه بررسی‌های آینده از همان آدرس نیز مسدود می‌شوند — حتی برای سایت‌هایی که قبلاً بدون مشکل باز می‌شدند.
چگونه مسدودیت را با کدهای پاسخ شناسایی کنیم
قبل از تغییر تنظیمات پروکسی، مهم است که بفهمید چه اتفاقی در حال وقوع است. Screaming Frog کد پاسخ را در ستون کد وضعیت نمایش می‌دهد — با استفاده از آن به راحتی می‌توان علت توقف کرالینگ را تعیین کرد.
| کد پاسخ | این چه معنی دارد | چه کار کنیم |
|---|---|---|
| 403 Forbidden | IP توسط حفاظت سایت مسدود شده است | IP را تغییر دهید، سرعت کرالینگ را کاهش دهید |
| 429 Too Many Requests | حد مجاز درخواست‌ها در یک واحد زمان تجاوز شده است | تعداد جریان‌ها را کاهش دهید، تأخیر اضافه کنید |
| 503 Service Unavailable | سرور بارگذاری شده یا حفاظت از ربات‌ها فعال است | User-Agent را تغییر دهید، از IP مسکونی استفاده کنید |
| بدون پاسخ / Timeout | IP در لیست سیاه است، درخواست‌ها به مقصد نمی‌رسند | تعویض کامل پروکسی‌پول |
اگر در گزارش به طور مکرر یک کد مشابه در هزاران URL مشاهده شود — این تقریباً همیشه مسدودیت بر اساس IP است، نه یک مشکل واقعی در سایت. بررسی فرضیه بسیار ساده است: URL مشکل‌دار را در یک مرورگر عادی با همان IP باز کنید. اگر صفحه به طور عادی باز می‌شود و Screaming Frog 403 دریافت می‌کند — مشکل از کرالر است، نه از سایت.
کدام پروکسی‌ها برای کرالینگ SEO مناسب هستند
انتخاب نوع پروکسی بستگی به وظیفه دارد: بررسی یکباره سایت خود، نظارت منظم بر رقبا یا اسکن یک بازار محافظت شده. بیایید سه نوع اصلی و کاربرد آنها برای کرالرها را بررسی کنیم.
| نوع پروکسی | سرعت | ریسک مسدودیت | کی استفاده کنیم |
|---|---|---|---|
| پروکسی دیتاسنتر | بالا | متوسط-بالا در سایت‌های محافظت شده | بررسی سایت خود بدون حفاظت سخت |
| پروکسی‌های مسکونی | متوسط | پایین | بررسی رقبا، سایت‌های پشت Cloudflare، بازارها |
| پروکسی‌های موبایلی | متوسط-پایین | حداقل | محافظت‌های بسیار تهاجمی، بررسی نقطه‌ای نادر |
برای اکثر بررسی‌های فنی منظم، تعادل بهینه را پروکسی‌های مسکونی فراهم می‌کنند — آنها از IPهای واقعی ارائه‌دهندگان استفاده می‌کنند، بنابراین حفاظت سایت درخواست‌های کرالر را به عنوان ترافیک کاربر عادی درک می‌کند. این امر به ویژه مهم است اگر شما دامنه خود را تحلیل نمی‌کنید، بلکه سایت رقیب یا بازار با سیستم ضد ربات سخت را بررسی می‌کنید.
پروکسی‌های دیتاسنتر همچنان گزینه خوبی هستند زمانی که شما سایت خود را بررسی می‌کنید و می‌توانید از قبل محدوده IP را در لیست سفید در سطح WAF یا Cloudflare اضافه کنید — در این صورت سرعت اسکن به حداکثر خواهد رسید بدون ریسک مسدودیت.
تنظیمات مرحله به مرحله پروکسی در Screaming Frog
Screaming Frog به طور پیش‌فرض از پروکسی پشتیبانی می‌کند، تنظیم آن چند دقیقه طول می‌کشد:
- برنامه را باز کنید و به منوی Configuration → System → Proxy بروید.
- تیک Use Proxy Server for All Traffic را بزنید.
- آدرس و پورت پروکسی سرور را که از ارائه‌دهنده دریافت کرده‌اید وارد کنید.
- اگر پروکسی نیاز به احراز هویت با نام کاربری و رمز عبور دارد — آنها را در پنجره پاپ‌آپ هنگام اولین درخواست مشخص کنید.
- روی OK کلیک کنید و کرالینگ را برای اعمال تنظیمات دوباره راه‌اندازی کنید.
نکته مهم: Screaming Frog در نسخه رایگان و پولی فقط می‌تواند با یک پروکسی سرور در یک زمان از طریق رابط داخلی کار کند. اگر نیاز به چرخش IP به صورت آنی دارید (این موضوع در هنگام اسکن از 50,000 صفحه به روز است)، از پروکسی با تغییر خودکار IP در سمت ارائه‌دهنده استفاده کنید — این در خود کرالر تنظیم نمی‌شود، بلکه در پنل کاربری سرویس پروکسی تنظیم می‌شود، جایی که فاصله تغییر IP (به عنوان مثال، هر 10 دقیقه یا با هر درخواست جدید) تعیین می‌شود.
این طرح بار را از یک آدرس حذف می‌کند: کرالر با یک پورت کار می‌کند، در حالی که IP به طور خودکار تغییر می‌کند و سایت فرکانس غیرعادی بالای درخواست‌ها را از یک آدرس خاص نمی‌بیند.
تنظیمات سرعت و جریان برای سایت‌های بزرگ
حتی با پروکسی کارآمد، تنظیمات سرعت کرالینگ بسیار تهاجمی می‌تواند منجر به مسدودیت شود. در Screaming Frog این موضوع به بخش Configuration → Speed مربوط می‌شود. مقادیر پیشنهادی برای سایت‌های با بیش از 100,000 صفحه:
- Max Threads: 2–5 برای سایت‌های محافظت شده، 10–15 برای سایت‌های بدون حفاظت سخت؛
- Max URI/s: در ابتدا 2–3 درخواست در ثانیه محدود کنید، به تدریج افزایش دهید و کدهای پاسخ را زیر نظر داشته باشید؛
- Custom User-Agent: در بخش Configuration → HTTP Header از User-Agent مرورگر واقعی به جای "Screaming Frog SEO Spider" استفاده کنید، اگر سایت کرالرها را بر اساس هدر مسدود می‌کند؛
- Respect robots.txt / crawl-delay: اگر دستور Crawl-delay نوشته شده است، آن را در نظر بگیرید — نادیده‌گیری معمولاً منجر به مسدودیت در سطح سرور می‌شود.
برای سایت‌هایی با حفاظت تهاجمی از ربات‌ها، همچنین مفید است که حالت JavaScript Rendering را فقط در جاهایی که واقعاً ضروری است فعال کنید (سایت‌های SPA بر روی React/Vue) — رندرینگ JS به شدت بار سرور را افزایش می‌دهد و شانس مسدودیت را در هنگام کرالینگ از طریق یک IP افزایش می‌دهد.
چرخش IP هنگام اسکن بیش از 100,000 صفحه
هر چه سایت بزرگتر باشد، توزیع بار بین آدرس‌های IP مهم‌تر است. برای بررسی‌های به این مقیاس دو طرح کار می‌کنند:
چرخش بر اساس زمان. IP به طور خودکار هر 5–15 دقیقه تغییر می‌کند، صرف نظر از تعداد درخواست‌ها. این برای کرالینگ طولانی و یکنواخت مناسب است، زمانی که اسکن به چند ساعت کشیده می‌شود.
چرخش بر اساس درخواست. هر درخواست HTTP جدید از یک IP جدید از پول خارج می‌شود. این حالت حداکثر حفاظت را در برابر مسدودیت‌ها فراهم می‌کند، اما ممکن است با کارکرد صحیح با احراز هویت مبتنی بر کوکی یا پارامترهای جلسه سایت تداخل کند — برای یک بررسی فنی خالص (جمع‌آوری کدهای وضعیت، ریدایرکت‌ها، متا تگ‌ها) این موضوع بحرانی نیست.
برای آژانس‌هایی که بررسی‌های همزمان چندین سایت مشتری را انجام می‌دهند، منطقی است که پول‌های IP را بر اساس پروژه‌ها تقسیم کنند — این از وضعیتی جلوگیری می‌کند که مسدودیت در یک دامنه به "اشتباه" بر شهرت IP در هنگام کار با سایت دیگر گسترش یابد.
نکته عملی: قبل از یک بررسی بزرگ، یک کرالینگ آزمایشی بر روی 500–1000 URL با تنظیمات فعلی سرعت و پروکسی انجام دهید. اگر در این مدت خطاهای 403/429 ظاهر نشد، می‌توانید با اطمینان اسکن را به کل سایت گسترش دهید.
چک‌لیست قبل از شروع بررسی
- ✅ پروکسی متصل و برای دسترسی آزمایش شده است (بررسی از طریق curl یا مرورگر جداگانه)؛
- ✅ Max Threads و Max URI/s به طور محافظه‌کارانه برای اولین بار تنظیم شده‌اند؛
- ✅ User-Agent به درستی تنظیم شده است و باعث مشکوک شدن WAF نمی‌شود؛
- ✅ Respect robots.txt فعال است، اگر سایت به وضوح درخواست رعایت Crawl-delay را دارد؛
- ✅ JavaScript Rendering فقط در صورت واقعی بودن نیاز فعال شده است؛
- ✅ چرخش IP برای حجم سایت از 20,000–30,000 صفحه تنظیم شده است؛
- ✅ ذخیره پیشرفت کرالینگ فعال است (Configuration → Save Crawl) در صورت قطع جلسه؛
- ✅ برای بررسی بازارها و پورتال‌های محافظت شده، پروکسی‌های مسکونی یا موبایلی به جای دیتاسنتر انتخاب شده‌اند.
اشتباهات رایج هنگام کرالینگ از طریق پروکسی
سرعت بسیار بالا در شروع. متخصصان اغلب حداکثر جریان‌ها را به طور همزمان تنظیم می‌کنند، امیدوارند که بررسی را تسریع کنند. در نتیجه، حفاظت سایت به سرعت واکنش نشان می‌دهد و تنها پس از چند دقیقه کل پول پروکسی در لیست سیاه قرار می‌گیرد.
یک IP استاتیک برای تمام پروژه‌های مشتری. اگر آژانس از یک دیتاسنتر پروکسی یکسان برای ده‌ها بررسی در ماه استفاده کند، شهرت این IP به سرعت کاهش می‌یابد — سیستم‌های امنیتی سایت‌های مختلف داده‌ها را درباره آدرس‌های مشکوک از طریق پایگاه‌های مشترک مبادله می‌کنند (به عنوان مثال، شهرت IP Cloudflare).
نادیده‌گیری geo-targeting. اگر سایت مورد بررسی برای یک منطقه خاص تنظیم شده باشد (به عنوان مثال، فروشگاه اینترنتی روسی با مسدودیت ترافیک خارجی)، استفاده از پروکسی با IP کشور دیگر به خودی خود می‌تواند منجر به محدودیت دسترسی شود — حتی بدون کرالینگ تهاجمی.
عدم نظارت در حین فرآیند. پس از راه‌اندازی کرالینگ برای چند ساعت، متخصصان اغلب کدهای پاسخ میانی را بررسی نمی‌کنند. در نتیجه، تنها پس از اتمام، مشکل را کشف می‌کنند، زمانی که نیمی از گزارش شامل خطاهای مسدودیت است، نه داده‌های واقعی درباره سایت.
نتیجه‌گیری
مسدودیت‌ها در هنگام بررسی فنی در Screaming Frog تقریباً همیشه با ترکیبی از سه عامل حل می‌شوند: نوع صحیح پروکسی، سرعت معقول کرالینگ و چرخش صحیح IP. برای سایت‌های خود بدون حفاظت سخت، پروکسی‌های دیتاسنتر با افزودن به لیست سفید کافی است. برای بررسی رقبا، بازارها و سایت‌های پشت Cloudflare به IPهایی نیاز دارید که به عنوان ترافیک کاربر عادی به نظر برسند.
اگر شما به طور منظم دامنه‌های دیگر یا پلتفرم‌های محافظت شده را بررسی می‌کنید، توصیه می‌کنیم با پروکسی‌های مسکونی شروع کنید — آنها ریسک مسدودیت را در سخت‌ترین سیستم‌های ضد ربات کاهش می‌دهند. برای وظایف نقطه‌ای در منابع حداکثر محافظت شده، باید پروکسی‌های موبایلی را در نظر بگیرید، و برای بررسی‌های مقیاس‌پذیر زیرساخت خود، پروکسی‌های دیتاسنتر گزینه‌ای خوب و سریع باقی می‌مانند.