دموی رایگان

چرا فیلتر محصولات و سئو نتیجه نمی‌دهد؟ علت‌های پنهان

دلوین خیری مقدم خواندن ~۷ دقیقه ووکامرس و فروشگاه‌سازی
چرا فیلتر محصولات و سئو نتیجه نمی‌دهد؟ علت‌های پنهان
فیلتر محصولات و سئو وقتی به نتیجه نمی‌رسد که صفحات فیلتر بی‌کنترل ایندکس شوند: فروشگاهی با صد محصول و چهار فیلد فیلتر به‌راحتی چند ده‌هزار ترکیب آدرس می‌سازد و خزنده بخشی از بودجهٔ خزش را صرف صفحاتی می‌کند که تقاضای جستجویی ندارند. در ادامه چهار علت پنهان این شکست را با نشانهٔ زندهٔ هرکدام باز می‌کنیم و بعد سیاست کنترل — noindex/follow، مدیریت پارامترها و پایش گزارش پوشش سرچ‌کنسول — را می‌چینیم.

در خوشهٔ ووکامرس، مقالهٔ آموزش گام‌به‌گام فیلتر محصولات و سئو چیدن درست فیلترها را از صفر باز کرده است؛ این مقاله قدم بعدی است: فیلترها چیده شده‌اند، فروشگاه کار می‌کند، ولی سهمی از جستجو نمی‌بینید. تجربهٔ ما می‌گوید مشکل معمولاً در خود فیلتر نیست؛ در آدرس‌هایی است که فیلترها پشت سرش تولید می‌کنند.

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

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

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

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

علت اول؛ ایندکس‌شدن هزاران ترکیبِ محتوای نازک

سه نشانهٔ زندهٔ فیلتر مشکل‌دار
نشانه‌ها را پیش از هر تغییر، از سرچ‌کنسول ثبت کنید.

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

نشانهٔ زندهٔ این علت در گزارش Performance سرچ‌کنسول پیداست: هزاران نمایش با کلیک نزدیک صفر، همه از آدرس‌هایی با علامت سؤال و پارامتر فیلتر. اگر این الگو را می‌بینید، مشکل فیلترِ خراب نیست؛ سیاست ایندکسِ غایب است. این الگو خواهر مستقیم بحث محتوای تکراری است؛ در آموزش گام‌به‌گام محتوای تکراری فیلتر فروشگاه و رفع آن روش تشخیص و رفع همان محتوای تکراری را با جزئیات باز کرده‌ایم و خواندنش مکمل همین بخش است.

علت دوم؛ بودجهٔ خزش هدررفته در پارامترها

دومین علت، بودجهٔ خزش است. خزندهٔ گوگل برای هر دامنه سهم محدودی از زمان خزش دارد؛ وقتی بخش بزرگی از این سهم صرف آدرس‌های فیلتر می‌شود، صفحات واقعاً مهم — محصول تازه، دستهٔ پرفروش، به‌روزرسانی‌ها — دیرتر دوباره خزیده می‌شوند. فروشگاهی که هر هفته محصول اضافه می‌کند، تأخیر ایندکس محصول تازه را معمولاً به سرعت سایت نسبت می‌دهد، در حالی که علت در مصرف فیلترهاست.

مرز ابزارها را پیش از هر تغییر دقیق بگذارید: دستور Disallow در robots.txt خزش را می‌بندد، نه ایندکس را — مستندات رسمی گوگل همین را تأیید می‌کند و یادآور می‌شود که مقدار Crawl-delay نادیده گرفته می‌شود و robots.txt باید در ریشهٔ دامنه باشد (تاریخ گردآوری: آبان ۱۴۰۵). یعنی بستن فیلترها در robots.txt صفحات را از نتایج بیرون نمی‌آورد؛ فقط کاری می‌کند که noindex هیچ‌وقت دیده نشود. ترتیب درست را در بخش کنترل می‌چینیم.

علت سوم؛ canonical اشتباه روی صفحات فیلتر

سومین علت، canonical اشتباه است. دو خطای رایج دیده‌ایم: اول، اضافه‌کردن canonical دستی به صفحهٔ اصلی سایت روی همهٔ صفحات فیلتر — که به گوگل می‌گوید این صفحه کپی است و اعتبار لینک‌های داخلی به فیلترها را هدر می‌دهد؛ دوم، نادیده‌گرفتن canonical برای پارامترهای مرتب‌سازی و صفحه‌بندی، که نسخه‌های تکراریِ همان دسته را چندگانه می‌کند.

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

علت چهارم؛ ریدایرکت‌های زنجیره‌ای بعد از تغییر فیلترها

چهارمین علت بعد از هر تغییر بروز می‌کند: تغییر نام ویژگی‌ها، حذف یک فیلد یا مهاجرت ساختار فیلتر، صدها آدرس قدیمی را بی‌صاحب می‌کند. اگر این آدرس‌ها با زنجیرهٔ ریدایرکت — ۳۰۱ به ۳۰۱ به ۳۰۱ — مدیریت شوند، خزنده هر بار دو سه پرش اضافه را می‌پیماید و بخشی از اعتبار مسیر هم در هر پرش می‌ریزد. زنجیره‌های طولانی، هزینهٔ خزش و سیگنال را با هم می‌خورند.

نشانهٔ زنده: در گزارش پوشش، دستهٔ «ریدایرکت» با ورودی‌های بیش از حد؛ و در خروجی ممیزی فنی، زنجیره‌های بیش از یک پرش. اصلاح ساده است: هر آدرس قدیمی را مستقیم به مقصد نهایی وصل کنید و فهرست آدرس‌های قدیمی را نگه دارید؛ حذف ریدایرکت‌ها را با فاصله انجام دهید، چون ترافیک ذخیره‌شدهٔ قدیمی هنوز می‌آید.

کنترل؛ سیاست noindex/follow و مدیریت پارامترها

سه تصمیم برای هر صفحهٔ فیلتر
تصمیم را از دادهٔ تقاضا بگیرید، نه از سلیقهٔ روز.

راه‌حل، سیاست مکتوب برای هر فیلتر است، نه یک کلید واحد. سه تصمیم روی میز است: ایندکس برای فیلترهای پرتقاضا با محتوای تقویت‌شده؛ noindex,follow برای فیلترهای کم‌تقاضا؛ و canonical به آدرس تمیز برای پارامترهای مرتب‌سازی و صفحه‌بندی. تصمیم را از داده بگیرید: ترکیبی که در سرچ‌کنسول نمایش و کلیک واقعی دارد، شاخص می‌ماند؛ بقیه خروج می‌روند.

ترتیب اجرا هم مهم است: noindex فقط وقتی دیده می‌شود که صفحه قابل خزش بماند؛ پس اجازهٔ خزش بدهید تا noindex دیده شود و بعد از خروج از ایندکس، خزش ترکیب‌های کم‌ارزش را محدود کنید. جدول زیر این سه تصمیم را جمع می‌کند.

وضعیت فیلترتصمیمشرط اجرا
ترکیب پرتقاضا با کلیک واقعیایندکس با محتوای تقویت‌شدهمتن اختصاصی، canonical خودارجاع، لینک داخلی از دسته
ترکیب کم‌تقاضا یا بی‌تقاضاnoindex,followاجازهٔ خزش تا دیدن noindex؛ رصد خروج در گزارش پوشش
مرتب‌سازی و صفحه‌بندیcanonical به آدرس تمیز دستهبدون noindex؛ محتوای دسته یکپارچه بماند

تصمیم هر فیلتر را مکتوب کنید؛ فیلد تازهٔ بعدی با همان قاعده تصمیم می‌گیرد، نه با سلیقهٔ روز.

پایش؛ گزارش پوشش و چهار سنجهٔ سرچ‌کنسول

پایش، بدون گزارش پوشش سرچ‌کنسول ممکن نیست: گزارشی که نشان می‌دهد چه چیزی ایندکس شده، چه چیزی مستثنا شده و چرا. دو هفته پس از اجرای سیاست، روند مستثناها را ببینید؛ صفحات noindex به‌تدریج به سمت «استثنا با برچسب noindex» می‌روند و سهم صفحات محتوایی در بخش ایندکس‌شده بالا می‌رود. جهش یا افت ناگهانی ایندکس‌شده‌ها، زنگ اخطار سیاست canonical است.

برای سمت تقاضا، گزارش Performance چهار سنجهٔ رسمی دارد: نمایش، کلیک، CTR و میانگین جایگاه (تاریخ گردآوری: آبان ۱۴۰۵). این چهار عدد را برای آدرس‌های فیلتر جدا ببینید، نه در میانگین کل فروشگاه؛ میانگین، ترکیب برنده را قربانی هزار ترکیب بی‌تقاضا می‌کند. قضاوت اصلی را به بازهٔ چهار هفته بدهید؛ نوسان هفتگی در این مقیاس معنا ندارد.

جمع‌بندی؛ ترتیب اصلاح در دو هفته

ترتیب اصلاح در دو هفته: هفتهٔ اول، خروجی آدرس‌های فیلتر را از ممیزی بگیرید، سیاست سه‌گانه را روی کاغذ ببندید و noindex,follow ترکیب‌های کم‌تقاضا را اعمال کنید. هفتهٔ دوم، canonical ها را با قاعده اصلاح کنید، زنجیره‌های ریدایرکت را خلاصه کنید و داشبورد پایش — پوشش به‌علاوهٔ چهار سنجه — را برای چهار هفته بچینید. بعد از آن، هر ماه فقط یک تغییر بزرگ.

اگر ظرفیت فنی داخلی برای این اصلاح‌ها ندارید، این کار یک مأموریت مشخص است، نه پروژهٔ باز؛ در ممیزی رایگان دامنه نقطه‌های نشتی فنی دامنه‌تان را اول ببینید و در قیمت‌های شفاف سوئیت سِروِ اجرای مأموریت‌ها را با کیف پول یکپارچه بررسی کنید. صفحهٔ سوئیت برای فروشگاه اینترنتی خدمات هم‌خانوادهٔ همین موضوع را فهرست کرده است و برنامهٔ کامل خوشه در هاب ووکامرس و فروشگاه‌سازی نگه‌داری می‌شود.

سفارش مأموریت مرتبط از پنل

خدمات مأموریت‌ها (شروع/رشد/تسلط) با کیف پول یکپارچه

سفارش مأموریت مرتبط از پنل

رصد ما، رشد شما.

سؤالات پرتکرار

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

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

Disallow در robots.txt راه‌حل صفحات فیلتر است؟

خیر؛ طبق مستندات گوگل، Disallow خزش را می‌بندد نه ایندکس را (تاریخ گردآوری: آبان ۱۴۰۵). برای خروج از ایندکس باید صفحه قابل خزش بماند تا noindex دیده شود؛ بعد از خروج می‌توانید خزش را محدود کنید.

چقدر طول می‌کشد صفحات فیلتر از ایندکس خارج شوند؟

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

canonical همهٔ فیلترها به صفحهٔ دسته درست است؟

نه؛ برای پارامترهای مرتب‌سازی و صفحه‌بندی بله، ولی برای ترکیب‌های پرتقاضا canonical خودارجاع با محتوای تقویت‌شده انتخاب درست‌تری است؛ canonical کردن همهٔ فیلترها به دسته، تقاضای واقعی را هم بیرون می‌اندازد.

ریدایرکت زنجیره‌ای را چطور پیدا کنم؟

با ممیزی فنی روی خروجی خزنده: هر زنجیرهٔ بیش از یک پرش را به مقصد نهایی خلاصه کنید و فهرست آدرس‌های قدیمی را آرشیو کنید تا مسیر ترافیک زبانه‌دار از بین نرود.