به فروشگاه های وردپرسی و ووکامرس شما حمله نشده مشکل Crawl Trap است

یکی از مشکلات رایج در فروشگاه های اینترنتی، مخصوصا فروشگاه های وردپرسی مبتنی بر WooCommerce، افزایش ناگهانی مصرف CPU، کند شدن سایت، زیاد شدن Process های PHP و سنگین شدن Error Log است.

در نگاه اول، این وضعیت ممکن است شبیه حمله سایبری، نفوذ یا Exploit به نظر برسد؛ اما در بسیاری از موارد، مشکل اصلی از جای دیگری شروع می شود: ورود ربات ها به مسیرهای سنگین فروشگاه و باز کردن تعداد زیادی URL فیلتر شده.

این مشکل فقط مخصوص وردپرس نیست. هر فروشگاه آنلاینی که دارای فیلتر محصول، دسته بندی، مرتب سازی، جستجوی داخلی، وضعیت موجودی و Query String های مختلف باشد، ممکن است درگیر چنین مشکلی شود. با این حال، در فروشگاه های وردپرسی و WooCommerce این موضوع بیشتر دیده می شود، چون هر درخواست سنگین معمولا از مسیر PHP، افزونه ها، قالب، Database و در نهایت فایل هایی مانند index.php عبور می کند.

اگر Cache به درستی تنظیم نشده باشد، هر درخواست ربات می تواند دوباره پردازش کامل سمت سرور ایجاد کند و همین موضوع باعث بالا رفتن مصرف CPU و کند شدن سایت می شود.

Crawl Trap چیست؟

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

در فروشگاه های وردپرسی و WooCommerce، این مشکل معمولا در صفحه فروشگاه، دسته بندی محصولات، فیلترهای محصول و جستجوی داخلی دیده می شود.

برای مثال URL هایی با پارامترهایی مثل موارد زیر می توانند باعث ایجاد Crawl Trap شوند:

?filter_cat=...
?filter_colors=...
?orderby=...
?stock_status=...
?s=...
?post_type=product

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

نتیجه این می شود که ربات ها به جای بررسی صفحات مهم سایت، بارها و بارها صفحات فیلتر شده، جستجوهای محصول، مرتب سازی ها و ترکیب های مختلف Query String را باز می کنند.

Crawler Flood چیست؟

Crawler Flood زمانی رخ می دهد که تعداد زیادی درخواست از سمت ربات ها به سایت ارسال شود. این ربات ها ممکن است شامل موارد زیر باشند:

ربات های موتورهای جستجو

ربات های شبکه های اجتماعی

ابزارهای تحلیل سئو

Crawler های ناشناس

ربات های قیمت یاب

اسکنرهای عمومی وب

بات های کم کیفیت یا Scraper ها

در این حالت، الزاما با یک حمله امنیتی مستقیم روبرو نیستیم. ممکن است هیچ Exploit یا تلاش برای نفوذ وجود نداشته باشد، اما حجم درخواست ها آنقدر بالا باشد که منابع سرور مصرف شود.

در فروشگاه های WooCommerce، این فشار معمولا روی URL های سنگین ایجاد می شود؛ مخصوصا URL هایی که شامل فیلتر، مرتب سازی، جستجو، وضعیت موجودی و Query String هستند.

چرا این مشکل در وردپرس و WooCommerce بیشتر دیده می شود؟

وردپرس WordPress و ووکامرس WooCommerce انعطاف پذیری بالایی دارند، اما همین انعطاف پذیری گاهی باعث ایجاد URL های متعدد و سنگین می شود.

در یک فروشگاه ووکامرسی، معمولا چندین افزونه و بخش مختلف درگیر نمایش یک صفحه محصول یا صفحه فروشگاه هستند؛ از جمله:

• قالب سایت
• افزونه فروشگاه ساز WooCommerce
• افزونه های فیلتر محصول
• صفحه سازها مانند Page Builder ها
• افزونه های سئو
• افزونه های Cache
• افزونه های جستجو و مرتب سازی
• کدهای سفارشی قالب

وقتی یک ربات یک URL سنگین را باز می کند، ممکن است همه این بخش ها دوباره اجرا شوند. اگر آن URL قابل Cache نباشد، درخواست مستقیما به PHP و Database فشار وارد می کند.

به همین دلیل، در سرورهایی که از LiteSpeed، OpenLiteSpeed یا PHP Process هایی مانند lsphp استفاده می کنند، ممکن است تعداد Process ها زیاد شود و CPU به شکل غیر طبیعی بالا برود.

چرا URL های فیلتر شده برای سرور سنگین هستند؟

بسیاری از URL های فیلتر شده در فروشگاه های آنلاین Cache پایدار ندارند. دلیل آن این است که این URL ها براساس Query String ساخته می شوند و محتوای آنها بسته به پارامترها تغییر می کند.

برای مثال، یک صفحه فروشگاه ممکن است با چندین حالت باز شود:

• مرتب سازی براساس جدیدترین محصولات
• مرتب سازی براساس قیمت
• فیلتر براساس رنگ
• فیلتر براساس دسته بندی
• فیلتر براساس موجودی
• جستجو در محصولات
• ترکیب چند فیلتر با هم

اگر Cache Server یا Cache Plugin نتواند این حالت ها را درست مدیریت کند، هر درخواست باید دوباره از مسیر پردازش وردپرس عبور کند.

این یعنی:

• درخواست وارد index.php می شود.
• هسته وردپرس Load می شود.
• افزونه ها اجرا می شوند.
• قالب اجرا می شود.
• Query به Database ارسال می شود.
• خروجی صفحه ساخته می شود.
• PHP Worker یا lsphp درگیر می شود.
• CPU مصرف می شود.

وقتی این روند توسط ده ها یا صدها ربات تکرار شود، فشار شدیدی روی سرور ایجاد می شود.

آیا این مشکل یعنی سایت هک شده است؟

نه، لزوما.

افزایش مصرف CPU، زیاد شدن درخواست ها و سنگین شدن Error Log همیشه به معنی هک شدن سایت نیست. در بسیاری از موارد، مشکل از Crawl Trap، Crawler Flood و ساختار نامناسب URL های فروشگاه است.

تفاوت مهم اینجاست:

در حمله امنیتی مستقیم، معمولا درخواست ها شامل Payload، تلاش برای Exploit، دسترسی به فایل های حساس، مسیرهای مدیریتی یا رفتارهای مشکوک هستند.

اما در Crawl Flood، ربات ها معمولا همان URL های قابل مشاهده سایت را باز می کنند. مشکل این است که سایت اجازه داده تعداد زیادی URL کم ارزش، تکراری و سنگین تولید شود.

بنابراین این مشکل بیشتر در دسته Performance، SEO، Server Optimization و Crawl Management قرار می گیرد، نه الزاما نفوذ امنیتی.

البته اگر در لاگ ها درخواست های مشکوک، Payload های خطرناک، تلاش برای دسترسی به فایل های حساس یا مسیرهای غیرعادی دیده شود، باید بررسی امنیتی جداگانه هم انجام شود.

نقش Query String در افزایش مصرف CPU

Query String همان بخش بعد از علامت سوال در URL است. برای مثال:

/shop/?orderby=price
/shop/?filter_colors=black
/shop/?stock_status=instock

در فروشگاه های وردپرسی، بسیاری از فیلترها و مرتب سازی ها با Query String ساخته می شوند. اگر این Query String ها کنترل نشوند، می توانند باعث تولید تعداد زیادی URL متفاوت شوند.

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

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

چرا Error Log سایت سنگین می شود؟

گاهی در قالب، افزونه یا ویجت های سایت یک Warning یا Notice ساده وجود دارد. در حالت عادی شاید این Warning مشکل بزرگی ایجاد نکند، اما وقتی ربات ها هزاران بار صفحات سنگین را باز می کنند، همان Warning هزاران بار در Error Log ثبت می شود.

به همین دلیل، ممکن است فایل Error Log خیلی سریع بزرگ شود.

در این حالت، Warning به تنهایی بحران اصلی نیست. بحران اصلی ترکیب این موارد است:

• URL های سنگین فروشگاه
• درخواست های زیاد ربات ها
• عدم Cache صحیح
• اجرای مکرر PHP
• ثبت تکراری Warning در Error Log

به همین دلیل، برای رفع مشکل فقط پاک کردن Error Log کافی نیست. باید علت اصلی تولید درخواست های سنگین و تکراری برطرف شود.

نشانه های این مشکل در فروشگاه وردپرسی

اگر سایت شما فروشگاهی است و با افزایش مصرف CPU روبرو شده اید، این نشانه ها می توانند احتمال Crawl Trap یا Crawler Flood را بالا ببرند:

• افزایش CPU بدون افزایش واقعی کاربران
• زیاد شدن Process های PHP یا lsphp
• درخواست های زیاد به صفحه فروشگاه
• درخواست های زیاد به URL های دارای filter_
• درخواست های زیاد به URL های دارای orderby
• درخواست های زیاد به URL های دارای stock_status
• باز شدن مکرر صفحات جستجوی محصول
• پر شدن سریع Error Log
• کند شدن پنل مدیریت وردپرس
• کند شدن صفحه فروشگاه و دسته بندی محصولات
• افزایش Time To First Byte یا TTFB
• کاهش سرعت پاسخگویی سرور

در چنین شرایطی، باید Access Log و Error Log سرور بررسی شود تا مشخص شود بیشترین درخواست ها از کدام User-Agent ها، IP ها و URL ها ارسال شده اند.

راهکارهای اصولی برای رفع مشکل

1. محدود کردن Crawl روی URL های فیلتر شده

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

هدف این نیست که کل فروشگاه بسته شود. هدف این است که ربات ها وارد مسیرهای بی پایان فیلتر، مرتب سازی، جستجو و Query String نشوند.

برای مثال، URL هایی که شامل پارامترهای زیر هستند معمولا ارزش Crawl بالایی ندارند:

filter_
orderby
stock_status
s=
post_type=product

البته تنظیمات robots.txt باید با دقت انجام شود تا صفحات مهم سایت از Crawl خارج نشوند.

2. استفاده درست از Canonical URL

Canonical URL به موتورهای جستجو کمک می کند بفهمند نسخه اصلی یک صفحه کدام است.

در فروشگاه های WooCommerce، ممکن است چند URL مختلف محتوای مشابهی نمایش دهند. اگر Canonical درست تنظیم نشده باشد، موتور جستجو ممکن است همه آنها را به عنوان صفحات مستقل در نظر بگیرد.

این موضوع باعث افزایش Crawl، محتوای تکراری Duplicate Content و مصرف بیشتر منابع سرور می شود.

بنابراین صفحات فیلتر شده، مرتب سازی ها و URL های دارای Query String باید Canonical مناسب داشته باشند.

3. کنترل Index صفحات کم ارزش

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

برای این صفحات می توان از سیاست های سئویی مانند Noindex استفاده کرد. البته Noindex با Disallow در robots.txt تفاوت دارد و باید درست استفاده شود.

اگر صفحه ای Disallow شود، ممکن است موتور جستجو نتواند تگ Noindex آن را ببیند. بنابراین باید تصمیم گیری براساس وضعیت سایت، تعداد صفحات ایندکس شده و ساختار URL انجام شود.

4. بهینه سازی Cache در وردپرس و سرور

Cache یکی از مهم ترین بخش های کنترل مصرف CPU در فروشگاه های وردپرسی است.

اما در فروشگاه های WooCommerce، تنظیم Cache باید با دقت انجام شود. چون همه صفحات قابل Cache نیستند. برای مثال:

• سبد خرید نباید به صورت عمومی Cache شود.
• صفحه حساب کاربری نباید Cache عمومی شود.
• صفحات پرداخت نباید Cache عمومی شوند.
• اما صفحات عمومی فروشگاه، دسته بندی، محصول و مقالات باید تا حد امکان Cache شوند.

مشکل اصلی معمولا در URL های دارای Query String است. باید مشخص شود کدام Query String ها باید Cache شوند، کدام ها باید Ignore شوند و کدام ها باید از Cache خارج شوند.

5. کنترل فیلترهای محصول

فیلترهای محصول اگر درست طراحی نشوند، یکی از اصلی ترین عوامل Crawl Trap هستند.

برای کنترل این مشکل، باید مشخص شود:

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

در بسیاری از فروشگاه ها، بهتر است ربات ها فقط صفحات اصلی دسته بندی، محصول و محتوای مهم را Crawl کنند و وارد ترکیب های بی پایان فیلترها نشوند.

6. اعمال Rate Limit برای ربات ها

در سطح سرور، Web Server یا WAF می توان برای ربات ها Rate Limit تعریف کرد.

Rate Limit یعنی محدود کردن تعداد درخواست هایی که یک IP یا User-Agent در یک بازه زمانی مشخص می تواند ارسال کند.

این روش کمک می کند ربات ها نتوانند در مدت کوتاه تعداد زیادی URL سنگین را باز کنند.

البته Rate Limit باید با دقت تنظیم شود تا کاربران واقعی و ربات های معتبر موتور جستجو دچار مشکل نشوند.

7. بررسی User-Agent ها و IP های پرتکرار

یکی از بهترین راه ها برای تشخیص این مشکل، بررسی Access Log است.

باید مشخص شود:

• کدام User-Agent بیشترین درخواست را ارسال کرده است.
• کدام IP ها بیشترین فشار را ایجاد کرده اند.
• بیشترین درخواست ها به کدام URL ها بوده است.
• آیا درخواست ها روی صفحات فیلتر شده متمرکز هستند یا نه.
• آیا ربات ها به صفحات جستجو و مرتب سازی حمله کرده اند یا نه.
• اگر الگوی درخواست ها بیشتر روی URL های فیلتر شده باشد، احتمال Crawl Trap بسیار بالا است.

8. اصلاح Warning ها و خطاهای قالب یا افزونه

اگر Error Log پر از Warning یا Notice های تکراری است، باید منبع خطا پیدا و اصلاح شود.

در وردپرس، این خطاها ممکن است از بخش های مختلف بیایند:

• قالب
• Child Theme
• افزونه های فروشگاهی
• افزونه های فیلتر محصول
• صفحه سازها
• کدهای سفارشی
• ویجت های محصول

مشکل زمانی جدی می شود که همان Warning روی صفحاتی باشد که ربات ها زیاد باز می کنند. در این حالت، هر درخواست ربات یک خطای جدید در Error Log ثبت می کند.

9. بهینه سازی Database Query ها

در فروشگاه های بزرگ، بعضی فیلترها باعث اجرای Query های سنگین روی Database می شوند.

برای مثال، فیلتر براساس ویژگی محصول، قیمت، موجودی، دسته بندی و جستجو می تواند Query های پیچیده ایجاد کند.

اگر Database بهینه نباشد یا تعداد محصولات زیاد باشد، این Query ها می توانند باعث مصرف شدید CPU و کندی سایت شوند.

در چنین شرایطی، باید موارد زیر بررسی شود:

• Slow Query ها
• Index های Database
• تعداد محصولات
• تعداد ویژگی های محصول
• نوع فیلترها
• افزونه های جستجو
• Query های ووکامرس

10. جدا کردن مشکل امنیتی از مشکل Performance

یکی از اشتباهات رایج این است که هر افزایش CPU را حمله امنیتی فرض کنیم. در حالی که گاهی مشکل اصلی از ساختار فنی سایت است.

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

مسیر اول: بررسی امنیتی برای پیدا کردن Exploit، Malware، Backdoor و درخواست های مشکوک

مسیر دوم: بررسی Performance برای پیدا کردن Crawl Trap، Crawler Flood، Query String های سنگین، Cache نامناسب و Warning های تکراری

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

آیا این مشکل فقط در وردپرس اتفاق می افتد؟

خیر.

این مشکل فقط مخصوص وردپرس نیست. هر فروشگاه آنلاینی که دارای URL های فیلتر شده، Query String های زیاد، جستجوی داخلی، مرتب سازی محصول و صفحات ترکیبی باشد، می تواند درگیر Crawl Trap شود.

اما در فروشگاه های وردپرسی و WooCommerce، این مشکل بیشتر دیده می شود؛ چون معماری سایت معمولا به PHP، افزونه ها، قالب و Database وابسته است. اگر Cache درست تنظیم نشده باشد، هر درخواست ربات می تواند فشار مستقیم روی CPU ایجاد کند.

پس جمله دقیق این است:

این مشکل در همه فروشگاه های آنلاین ممکن است رخ دهد، اما در فروشگاه های وردپرسی و WooCommerce به دلیل ساختار پویا، افزونه های متعدد، فیلترهای محصول و وابستگی به PHP بیشتر دیده می شود.

افزایش مصرف CPU در فروشگاه های وردپرسی و WooCommerce همیشه به معنی هک شدن سایت نیست. در بسیاری از موارد، ربات ها وارد URL های فیلتر شده و کم ارزش فروشگاه می شوند و با ایجاد Crawl Trap یا Crawler Flood فشار زیادی روی سرور ایجاد می کنند.

وقتی این URL ها Cache پایدار نداشته باشند، هر درخواست دوباره از مسیر index.php، PHP، افزونه ها، قالب و Database عبور می کند. نتیجه این وضعیت افزایش مصرف CPU، زیاد شدن Process های PHP یا lsphp، کند شدن سایت و پر شدن Error Log است.

برای رفع اصولی این مشکل باید چند بخش همزمان بررسی شود:

• مدیریت Crawl با robots.txt
• استفاده درست از Canonical URL
• کنترل Noindex برای صفحات کم ارزش
• بهینه سازی Cache وردپرس و سرور
• محدود کردن Query String های سنگین
• کنترل فیلترهای محصول
• اعمال Rate Limit برای ربات ها
• بررسی Access Log و Error Log
• اصلاح Warning های قالب و افزونه
• بهینه سازی Query های Database

اگر این موارد درست پیاده سازی شوند، مصرف CPU کاهش پیدا می کند، Error Log سبک تر می شود، سرعت سایت بهتر می شود و موتورهای جستجو به جای هدر دادن Crawl Budget روی URL های بی ارزش، صفحات مهم فروشگاه را بهتر بررسی می کنند.

اگر درگیر چنین مشکلی هستید و نتوانستید آن را حل کنید از اینجا با ما تماس حاصل نمایید.