فلاتر المتجر وصفحات النتائج: كيف تحدد أي التركيبات تستحق الزحف؟

فلاتر المقاس واللون والسعر تساعد المتسوق في العثور على منتج مناسب. لكن إذا أنشأ كل اختيار ترتيبًا مختلفًا من معاملات URL، فقد ينتج عدد كبير من الروابط التي تعرض مجموعات متقاربة أو فارغة. الحل ليس تعطيل الفلاتر للناس؛ بل تحديد أي صفحات نتائج لها قيمة مستقلة وأي روابط ينبغي ألا تتحول إلى مسارات زحف غير محدودة.

تصف Google التنقل ذي الأوجه بأنه مصدر محتمل لمساحات كبيرة من عناوين URL، لأن برامج الزحف لا تعرف دائمًا قبل فتح الرابط إن كانت النتيجة مفيدة. توصي وثائقها إما بمنع زحف التركيبات التي لا تحتاج أن تظهر، أو باتباع قواعد واضحة إذا كانت صفحات الفلاتر مهمة للبحث. توضح أيضًا أن إدارة crawl budget المتقدمة موجهة أساسًا للمواقع الكبيرة والمتغيرة بسرعة؛ كثير من المتاجر الأصغر تحتاج أولًا إلى خريطة URL واضحة ومحتوى قابل للاكتشاف. إدارة التنقل ذي الأوجه · إرشادات ميزانية الزحف

ارسم التركيبات التي ينشئها المتجر

ابدأ بتسجيل كل عنصر يغير URL: فئة، لون، مقاس، سعر، علامة تجارية، تقييم، ترتيب، صفحة، أو رمز جلسة. لكل نوع، دوّن هل يغير المنتجات فعلًا، وهل يحتاج المشتري إلى رابط قابل للمشاركة، وهل يتوقع الفريق أن تظهر الصفحة منفصلة في نتائج البحث.

افحص شكل الروابط كما ينشئها الموقع، لا كما تتخيلها من واجهة الفلتر. سجّل الفرق بين ?color=black&size=m و?size=m&color=black، وما إذا كانت إضافة الفلتر مرتين تنشئ رابطًا آخر، وما الذي يحدث عند تغيير الترتيب فقط. قد تبدو الروابط مختلفة بينما تعرض الصفحة نفسها.

قرر أي الصفحات لها قيمة بحث مستقلة

لا تجعل كل مجموعة منتجات قابلة للفهرسة لمجرد أن لها URL. قيّم كل نوع من الصفحات بهذه الأسئلة:

1. هل توجد حاجة واضحة للصفحة تتجاوز إعادة ترتيب الفئة؟
2. هل المنتجات متاحة فعلًا وبعدد يكفي لاتخاذ قرار؟
3. هل تستطيع الصفحة وصف المجموعة بدقة من دون نص آلي عام؟
4. هل سيجدها المستخدم عبر رابط داخلي ثابت ومفيد؟
5. هل يستطيع الفريق تحديثها عند نفاد المنتجات أو تغير المجموعة؟

إذا كانت الإجابة نعم، صمم صفحة مستقرة لها عنوان ومحتوى ومعلومات منتج متسقة. إذا لم توجد قيمة مستقلة، حافظ على وظيفة الفلتر للمستخدم، لكن لا تجعل كل تركيب مسارًا جديدًا يجب على الزاحف استكشافه.

اختر إشارة التحكم وفق النتيجة المطلوبة

• لا تحتاج الزحف إلى هذه التركيبات: وثائق Google تذكر robots.txt كوسيلة لمنع زحف روابط الفلاتر. استخدم قواعد دقيقة على المعاملات التي لا تريد زحفها، وجرّبها على أمثلة تمثل المسارات المراد حمايتها والمسارات التي يجب أن تبقى مفتوحة.
• تحتاج الزحف إلى مجموعة محددة: استخدم صيغة ثابتة للمعاملات، وترتيبًا موحدًا، وروابط داخلية فقط للصفحات التي اعتمدها فريق المحتوى والتجارة.
• توجد نسخ متقاربة وتريد دمج إشاراتها: يمكن أن يساعد rel="canonical" في توضيح النسخة الأساسية، لكنه ليس بديلًا عن قرار URL أو رابط داخلي فوضوي. لا تعتبره حظرًا للزحف.
• تولّد الفلاتر بلا حاجة روابط قابلة للفهرسة: قد يؤدي استخدام شظايا URL (#) إلى عدم إنشاء مسارات زحف مستقلة في Google Search، لكن تحقق من تجربة المستخدم والدعم في تطبيقك قبل اختيار هذا التصميم.
• لا توجد نتائج فعلًا: أعد حالة 404 مناسبة للتركيبة غير الموجودة بدل عرض صفحة فارغة مع استجابة تبدو كأنها صفحة سليمة.

اختيار robots.txt أو noindex ليسا مترادفين. إذا منعت الزاحف من فتح الصفحة، فلن يستطيع قراءة noindex داخلها. وإذا استخدمت noindex فقط، قد يستمر الزاحف بطلب الروابط لمعاينة الإشارة. حدّد هل هدفك منع الفهرسة أم تقليل الزحف أم توحيد النسخ؛ لكل هدف قرار مختلف.

ثبّت قواعد URL قبل نشر الفلاتر

لأي نوع تسمح بزحفه، استخدم أسماء معاملات واضحة من شكل ?key=value، ولا تكرر المعامل نفسه، وثبّت ترتيبًا منطقيًا للفلاتر إذا كان نظامك يغير ترتيبها. استبعد رموز الجلسة والتتبع والوقت والخيارات المؤقتة من الروابط الداخلية الدائمة. لا تضع كل التركيبات في sitemap؛ احتفظ به للصفحات التي تريد من محركات البحث اكتشافها.

اختبر قواعد التصنيف مع الحالات التالية: فئة بلا فلتر، فلتر واحد، فلتران، ترتيب فقط، لا نتائج، فلتر مكرر، صفحة متأخرة، متغير غير صالح، ورابط تتبع. تحقق من canonical وحالة HTTP والروابط الداخلية كما تظهر في HTML النهائي.

راقب الأدلة قبل افتراض وجود مشكلة crawl budget

إذا كان الموقع صغيرًا ولم تظهر قيود خادم أو كمية كبيرة من روابط الفلاتر في تقارير الفهرسة، لا تبدأ بإعادة تصميم واسعة بسبب مصطلح crawl budget وحده. راجع سجلات الزحف أو تقارير Search Console عند توفرها، واحسب أمثلة URL التي يتكرر زحفها، وافحص هل صفحات مهمة فعلًا غير مكتشفة.

في متجر كبير أو سريع التغير، قارن حجم الروابط ذات المعاملات مع عدد الفئات والمنتجات والصفحات المعتمدة، وراجع الأخطاء ومعدل استجابة الخادم. Blocking لا ينقل تلقائيًا موارد الزحف إلى صفحات أخرى إذا لم يكن الزاحف يواجه حد السعة أصلًا. عالج المشكلة الموثقة بدل تعديل كل ملف robots.txt على أمل تسريع الفهرسة.

مثال توضيحي: لون ومقاس وترتيب

لنفترض أن فئة أحذية تسمح بفلتر اللون والمقاس والسعر والترتيب. قد ينشئ المتجر روابط كثيرة تجمع اللون والمقاس وترتيب السعر، مع وجود أكثر من صيغة للتركيبة نفسها. يحتفظ الفريق بصفحات مستقرة لمجموعات محددة لها طلب ومخزون ووصف واضح، ويمنع أو يقلل زحف تركيبات الترتيب والخيارات المكررة وفق القواعد المناسبة. يظل المستخدم قادرًا على فرز المنتجات وفحص المخزون، لكن الرابط الذي يصل إلى الزاحف لا يتغير مع كل حركة غير لازمة.

هذا مثال تصميمي لا يصف متجرًا فعليًا ولا يضمن تحسن ترتيب أو زحف.

سكريبت فيديو قصير: الفلتر مفيد للعميل، لكن ليس كل URL صفحة بحث

المدة: ٤٥ ثانية. الصورة: فئة أحذية ثم معاملات اللون والمقاس والترتيب.

٠–٥ ثوانٍ — الخطاف: «لون ومقاس وترتيب السعر ممكن يولدوا عشرات الروابط لنفس الفئة.»

٦–١٧ ثانية — اشرح المشكلة: اعرض نفس المنتجات بترتيب مختلف ورابطين متشابهين. «الزاحف يرى URLs مختلفة؛ لازم نحدد أيها يضيف قيمة فعلًا.»

١٨–٣٠ ثانية — القرار: «احتفظ بالصفحة التي تجيب عن حاجة مستقلة ولها منتجات ومعلومات محدثة. واضبط التركيبات التي لا نحتاج زحفها.»

٣١–٣٩ ثانية — فحص: اختبر الرابط والحالة وcanonical والروابط الداخلية ونتائج Search Console.

٤٠–٤٥ ثانية — الخلاصة: «حافظ على الفلتر للمتسوق، ونظّم URL للزاحف.»

استخدم بيانات اختبار أو لقطة من متجر مصرح بعرضه. لا تعرض معلومات الحساب أو التقارير الحساسة.

كاروسيل تعليمي: سياسة واضحة لروابط الفلاتر

1. الغلاف: كل فلتر مفيد للعميل—هل يحتاج URL منفصلًا؟
2. احصر المعاملات: لون، مقاس، سعر، ترتيب، جلسة، وتتبع.
3. قيّم المهمة: هل التركيبة تجيب عن حاجة مستقلة؟
4. اعتمد صفحات محددة: بيانات صحيحة، مخزون، وصف، ورابط داخلي.
5. وحّد الباقي: ترتيب معاملات ثابت، ومنع التكرار والروابط المؤقتة.
6. اختر التحكم: منع زحف، canonical، أو بنية لا تنتج URL جديدًا حسب هدفك.
7. افحص الحالات الفارغة: استجابة 404 فعلية للتركيبات غير الموجودة.
8. قِس قبل التعديل الشامل: تحقق من دلائل الزحف وتقارير الفهرسة.

سلسلة تجربة ميدانية: اختبر قاعدة واحدة للفلاتر

هذه خطة تقنية مقترحة وليست نتيجة موقع أو توصية بتغيير robots.txt مباشرة.

١/ اختر فئة واحدة واكتب أمثلة URL للفلاتر الحالية مع نتيجة كل رابط: منتجات ظاهرة، نسخة مكررة، صفحة فارغة، أو ترتيب فقط.

٢/ حدد التركيبات التي تحتاج ظهورًا مستقلًا في البحث، مع سبب وقيمة للزائر ومالك للمحتوى والمخزون.

٣/ صمم قاعدة واحدة فقط، ثم اختبرها على قائمة روابط تشمل صفحة فئة أساسية، تركيبة معتمدة، معاملات مكررة، ترتيب، جلسة، ولا نتائج.

٤/ تحقق من حالة HTTP وcanonical والروابط الداخلية ونتيجة اختبار robots.txt أو URL Inspection قبل تعميمها.

٥/ راقب سجلات أو تقارير الزحف والفهرسة المتاحة بعد التغيير، وقارن الصفحات المهمة التي تريد اكتشافها. وثّق ما لم يتغير؛ لا تستنتج إعادة توزيع crawl budget من مجرد حظر الروابط.

حزمة مطالبات محايدة للأدوات: راجع سياسة التنقل ذي الأوجه

المطالبة ١ — صنّف معاملات URL

هذه أمثلة روابط ونتائجها [الصق URL منقحة ووصف الصفحة]. صنف كل معامل إلى فلتر محتوى، ترتيب، تتبع، جلسة، أو غير معروف. حدد الروابط المتكررة أو الفارغة وما يحتاج مراجعة بشرية. لا تقترح حظرًا قبل معرفة وظيفة الصفحة.

المطالبة ٢ — اختبر القاعدة المقترحة

هذه قاعدة URL/robots/canonical [الصق القاعدة]، وهذه الحالات التي يجب أن تبقى قابلة للوصول [قائمة]. أنشئ مصفوفة تحقق تبين ما تسمح به القاعدة وما تمنعه، وحدد أي مسار معتمد قد يتأثر. لا تنفذ أو تعدل ملفات الموقع.

المطالبة ٣ — اكتب سجل قرار

بناءً على هذه الأدلة [تقارير زحف، عينة URL، حالة الفهرسة، حجم الموقع، استقرار الخادم]، اكتب قرارًا يوضح هدف المعالجة، الصفحات التي نحتاجها، الصفحات التي نحدها، الأداة المختارة، المخاطر، وطريقة التراجع. إذا لم تثبت مشكلة crawl budget، اذكر ذلك.

ملف أمثلة: أوقف هذا: حظر كل معاملات URL بلا فرز

توقف عن: «أي URL فيه علامة استفهام نمنع زحفه.» قد يحتوي المعامل صفحة مهمة أو رابط ترقيم أو لغة يعتمد عليها المتجر.

افعل بدلًا منه: صنّف المعاملات، وحدد روابط البحث المعتمدة، واختبر قاعدة ضيقة على عينة تشمل الصفحات التي يجب أن تبقى مفتوحة.

وتوقف عن: اعتبار noindex بديلًا مطابقًا لـ robots.txt.

✅ استخدم القرار المناسب: إذا أردت منع الزحف، تحقّق من قواعد robots.txt. إذا أردت منع الفهرسة مع السماح بالزحف لقراءة الإشارة، لا تحجب الصفحة عن الزاحف. وثّق الهدف قبل اختيار الأداة.

الخطاف والقيمة والقالب: اعتمد سياسة فلاتر قابلة للاختبار

الخطاف: كل اختيار فلتر يمكن أن يصنع URL؛ وليس كل URL يستحق أن يصبح صفحة بحث.

القيمة: اربط الزحف بقيمة الصفحة ومهمتها. ثبّت قواعد روابط التركيبات المعتمدة، وتعامل بدقة مع الترتيب والجلسات والنتائج الفارغة، واختبر أثر القاعدة على الصفحات المهمة.

قالب سياسة تنقل:

نوع المتجر والفئة: [النظام / فئة الاختبار]
المعاملات ووظيفتها: [فلتر / ترتيب / تتبع / جلسة]
صفحات تستحق الظهور ولماذا: [URL / مهمة الزائر / دليل القيمة]
تركيبات لا تحتاج زحفًا: [الأنماط / سبب الاستبعاد]
قاعدة URL: [ترتيب ثابت / منع تكرار / حالات لا نتائج]
الإشارة المختارة: [robots.txt / canonical / بنية URL / غيرها]
المسارات التي يجب ألا تتأثر: [قائمة اختبار]
الدليل الحالي: [سجلات أو تقارير / تاريخ]
المالك والمراجع: [الأسماء أو الأدوار]
اختبار بعد التغيير وخطة التراجع: [الخطوات]

راجع السياسة مع مالك المنصة وSEO قبل تغيير تعليمات الزحف؛ الاختيار يعتمد على البنية الفعلية وأهداف الصفحات.