کنترل فیلترهای فروشگاه برای جلوگیری از overcrawling و هدررفت crawl budget

این فناوری چیست و چه مسئله‌ای را حل می‌کند؟

ناوبری وجهی همان فیلترهای فروشگاه برای رنگ، برند، قیمت و ویژگی‌هاست؛ مدیریت درست آن کمک می‌کند URLهای کم‌ارزش منابع سرور و crawl budget را هدر ندهند.

ناوبری وجهی یا Faceted Navigation همان فیلترهایی است که در فروشگاه برای رنگ، برند، بازهٔ قیمت، اندازه و ویژگی‌های محصول می‌بینیم. این فیلترها برای کاربر مفیدند، اما اگر هر انتخاب به یک URL پارامتردار جداگانه تبدیل شود، ترکیب‌های بسیار زیادی ساخته می‌شود. نتیجه می‌تواند خزش بیش‌ازحد، مصرف منابع سرور و دیرتر پیدا شدن صفحات مهم فروشگاه باشد. راهنمای رسمی Google Crawling Infrastructure برای کنترل این URLها، بین فیلترهایی که ارزش حضور در جست‌وجو دارند و فیلترهایی که فقط ابزار تجربهٔ کاربر هستند تفاوت می‌گذارد.

چرا URLهای فیلترشده مشکل‌ساز می‌شوند؟

فرض کنید یک فروشگاه ۲۰ برند، ۱۲ رنگ و ۱۰ بازهٔ قیمت داشته باشد. اگر ترتیب انتخاب‌ها و ترکیب پارامترها کنترل نشود، تعداد زیادی URL ظاهراً متفاوت تولید می‌شود؛ حتی زمانی که چند URL دقیقاً یک محصول یا مجموعهٔ یکسان را نشان می‌دهند. Google می‌گوید خزنده معمولاً باید URL را درخواست کند تا بفهمد صفحه ارزشمند است یا نه؛ بنابراین قبل از تشخیص بی‌فایده بودن، منابع زیادی صرف URLهای فیلترشده می‌شود.

کنترل فیلترهای فروشگاه در این مرحله یعنی تشخیص رابطهٔ هر فیلتر با صفحهٔ اصلی، نه حذف همهٔ گزینه‌ها. اگر یک فیلتر فروشگاه صفحه‌ای با تقاضای واقعی می‌سازد، باید مسیر مستقلی برای آن تعریف شود؛ اگر فقط ترکیب موقتی برای کاربر است، نباید به صدها URL قابل خزش تبدیل شود.

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

این وضعیت فقط مسئلهٔ سئو نیست. درخواست‌های اضافی می‌توانند PHP، دیتابیس، جست‌وجوی ووکامرس و کش را درگیر کنند. در سایت‌های بزرگ، همین بار اضافه ممکن است کشف محصولات تازه و دسته‌های اصلی را کند کند. از طرف دیگر، بستن عجولانهٔ همهٔ فیلترها هم می‌تواند صفحات واقعاً ارزشمند و قابل ایندکس را از دسترس خارج کند.

در یک پروژهٔ بهینه‌سازی فنی وردپرس، کنترل فیلترهای فروشگاه باید کنار بهینه‌سازی سرعت، کش و ساختار لینک‌های داخلی بررسی شود؛ چون کاهش URLهای کم‌ارزش زمانی نتیجه می‌دهد که مسیرهای مهم فروشگاه همچنان برای کاربر و خزنده قابل کشف باشند.

۱. فیلترها را بر اساس ارزش جست‌وجو دسته‌بندی کنید

قبل از تغییر robots.txt یا کد قالب، از لاگ وب‌سرور و گزارش‌های Search Console نمونه بگیرید. فیلترها را در سه گروه قرار دهید: فیلترهایی که صفحهٔ مستقل و تقاضای جست‌وجوی واقعی دارند؛ فیلترهایی که فقط برای مرتب‌سازی و تجربهٔ کاربر لازم‌اند؛ و ترکیب‌هایی که محتوای تکراری، بسیار کم‌ارزش یا بدون نتیجه تولید می‌کنند.

برای گروه اول، قرارداد URL ثابت، محتوای قابل‌تفاوت، canonical منطقی و لینک‌سازی داخلی کنترل‌شده تعریف کنید. گروه دوم معمولاً نباید بودجهٔ خزش را مصرف کند. گروه سوم باید به‌صورت پیش‌فرض از چرخهٔ خزش خارج شود یا پاسخ مناسب «یافت نشد» بگیرد.

این دسته‌بندی، پایهٔ کنترل فیلترهای فروشگاه است و باید برای هر نوع محصول، برند و ویژگی در مستندات فنی ثبت شود. بدون این فهرست، تیم محتوا، توسعه و سئو ممکن است برای یک فیلتر فروشگاه سه رفتار متفاوت پیاده کنند.

۲. قرارداد URL و پارامترها را ثابت نگه دارید

اگر URL فیلترشدنی قرار است قابل خزش باشد، نام پارامترها و ترتیب آن‌ها را ثابت کنید. از جداکنندهٔ استاندارد & استفاده کنید و اجازه ندهید یک فیلتر دوبار در URL بیاید یا یک انتخاب با چند نام متفاوت تولید شود. برای مسیرهای مبتنی بر path نیز ترتیب منطقی فیلترها باید همیشه یکسان باشد.

این قواعد، تعداد URLهای تکراری را کم می‌کنند و تحلیل لاگ و گزارش‌گیری را ساده‌تر می‌سازند. همچنین قبل از انتشار، چند URL معادل را با curl یا DevTools مقایسه کنید تا مشخص شود آیا واقعاً پاسخ و محتوای متفاوتی دارند یا فقط شکل URL عوض شده است.

۳. برای فیلترهای کم‌ارزش، خزش را آگاهانه محدود کنید

اگر فیلترها قرار نیست در Google Search دیده شوند، Google استفاده از robots.txt را برای جلوگیری از خزش آن‌ها پیشنهاد می‌کند. این قانون را محدود و بر پایهٔ الگوی واقعی پارامترها بنویسید؛ مسدودکردن کلی مسیر فروشگاه ممکن است صفحات محصولات را هم از دسترس خارج کند. در بعضی رابط‌های تعاملی، استفاده از fragment به‌جای پارامتر URL می‌تواند فیلتر را از چرخهٔ معمول خزش و ایندکس خارج کند، اما باید با رفتار جاوااسکریپت و دسترس‌پذیری سایت سازگار باشد.

canonical و nofollow می‌توانند سیگنال‌های کمکی باشند، ولی جایگزین طراحی درست مسیر خزش نیستند. canonical به‌تنهایی تضمین نمی‌کند که Google هرگز URL را درخواست نکند و nofollow نیز وقتی مؤثرتر است که تمام لینک‌های منتهی به URL فیلترشده را پوشش دهد.

برای کنترل فیلترهای فروشگاه، ابتدا گزارش URLها را جمع کنید و بعد قانون بنویسید؛ اضافه‌کردن چند disallow عمومی بدون شناخت پارامترها می‌تواند نتیجهٔ معکوس داشته باشد. در فروشگاه‌های چندزبانه یا چندقالبی نیز همین فیلترهای فروشگاه ممکن است با نام‌های متفاوت تکرار شوند و باید در قرارداد URL یکسان‌سازی شوند.

در مستندات هر کنترل فیلترهای فروشگاه، نمونهٔ URL مجاز، نمونهٔ URL مسدود و نتیجهٔ مورد انتظار را ثبت کنید. این مستندات از بازگشت ناخواستهٔ فیلترهای فروشگاه در به‌روزرسانی بعدی قالب یا افزونه جلوگیری می‌کند.

۴. برای ترکیب‌های نامعتبر، ۴۰۴ واقعی برگردانید

ترکیب بدون نتیجه، فیلتر تکراری، پارامتر نامفهوم و صفحه‌بندی‌ای که وجود ندارد نباید با ۲۰۰ یا redirect به یک صفحهٔ عمومی پاسخ داده شوند. توصیهٔ Google این است که در همان URL، پاسخ HTTP ۴۰۴ واقعی برگردد. این کار به خزنده و ابزارهای پایش نشان می‌دهد صفحه‌ای برای ایندکس وجود ندارد و از soft ۴۰۴ و خزش دوبارهٔ مسیرهای بی‌فایده جلوگیری می‌کند.

در ووکامرس، این منطق باید با منبع دادهٔ محصولات و کش هماهنگ باشد. ابتدا ترکیب فیلتر را normalize کنید، سپس نتیجه را بررسی کنید و فقط برای حالت واقعاً بدون محصول پاسخ ۴۰۴ بدهید. برای فیلترهای قابل‌ایندکس، عنوان، متن، canonical و داده‌های ساختاریافته باید با همان مجموعهٔ محصولات سازگار باشند.

پس از اجرای کنترل فیلترهای فروشگاه، چند مسیر واقعی را با وضعیت‌های ۲۰۰ و ۴۰۴ بررسی کنید. این آزمون باید هم روی صفحهٔ دسکتاپ و هم در درخواست‌های AJAX انجام شود تا رابط کاربری، پاسخ سرور و سیگنال‌های سئو از یک منطق پیروی کنند.

چک‌لیست اجرای امن

۱. از لاگ سرور، Search Console و نمونه‌های واقعی URL شروع کنید.

۲. فیلترهای ارزشمند را از فیلترهای صرفاً تعاملی جدا کنید.

۳. نام، ترتیب و جداکنندهٔ پارامترها را ثابت کنید و لینک‌های داخلی را کنترل کنید.

۴. robots.txt یا fragment را فقط برای گروه کم‌ارزش و پس از آزمون staging به‌کار ببرید.

۵. برای ترکیب‌های خالی، تکراری و صفحه‌بندی ناموجود، ۴۰۴ واقعی تست کنید؛ redirect یا soft ۴۰۴ نسازید.

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

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

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

منبع: راهنمای رسمی Google برای مدیریت URLهای ناوبری وجهی