Relevanssi إضافة تستبدل منطق البحث الافتراضي في WordPress بمحرك يعتمد على فهرس مستقل ودرجات صلة قابلة للضبط. فائدتها تظهر عندما لا يكفي البحث الافتراضي: مواقع محتوى كبيرة، Knowledge Base، حقول مخصصة، Taxonomies، أوحاجة لتحسين التعامل مع اللغة العربية.
حتى سبتمبر 2026، أحدث الإصدارات المنشورة رسميًا هي Relevanssi Free 4.28 وRelevanssi Premium 2.31. هذا الدليل لا يعتمد على Screenshots قديمة؛ واجهة الإضافة تتغير، لذلك نركز على طريقة الإعداد والقرارات التي يجب فهمها.
المصدر الرسمي: Relevanssi Release Notes لمراجعة الإصدارات الحالية، وUser Manual للإعدادات.
ماذا تضيف Relevanssi فوق بحث WordPress؟
وفق المقارنة الرسمية الحالية، Relevanssi Free توسع البحث ليشمل خيارات مثل التعليقات وكتّاب التعليقات والتصنيفات والوسوم وCustom Taxonomies وCustom Fields ومحتوى Shortcodes، مع ترتيب النتائج حسب الصلة بدل الاعتماد فقط على السلوك الافتراضي.
Premium يضيف خصائص أوسع مثل فهرسة محتوى PDF وبعض أنواع الملفات، البحث في Taxonomy terms كصفحات نتائج، دعم أوسع للـMultisite، WP-CLI وخصائص متقدمة أخرى.
| الاحتياج | Free | Premium |
|---|---|---|
| بحث أفضل في Posts/Pages | نعم | نعم |
| Custom Fields/Taxonomies | نعم في نطاق موثق | نعم بمرونة أكبر |
| البحث داخل نص PDF/مرفقات | محدود | متاح للأنواع المدعومة |
| بحث عبر مواقع Multisite متعددة | لا | متاح ضمن الشبكة مع قيود موثقة |
| WP-CLI وإدارة متقدمة | محدود | نعم |
طريقة إعداد Relevanssi بشكل صحيح
1. ثبت الإضافة ثم حدد ما الذي يجب فهرسته
بعد التفعيل لا تبدأ بتحديد كل الخيارات. اختر فقط أنواع المحتوى التي يحتاج المستخدم البحث فيها: Posts، Pages، Products، Custom Post Types، Taxonomies أوCustom Fields حسب الموقع.
كل عنصر تضيفه للفهرس يرفع حجم البيانات التي يجب بناؤها والبحث فيها. لا تفهرس Metadata تقنية أوحقولًا داخلية لا تفيد المستخدم.
2. ابنِ الفهرس بعد ضبط Indexing
إعدادات Indexing لا تصبح فعالة على المحتوى القديم حتى يتم بناء الفهرس. وثائق Relevanssi توضح أن Build the index يعيد إنشاء الفهرس من الصفر وفق الإعدادات المحفوظة، وقد يستغرق وقتًا على المواقع الكبيرة.
بعد البناء، المحتوى الجديد أوالمعدل يُفهرس عند حفظه في الحالات المعتادة؛ لا تحتاج إعادة بناء كاملة بعد كل مقال جديد. أما عند تغيير قواعد الفهرسة نفسها، فقد تحتاج Rebuild.
3. اضبط AND/OR بناءً على نوع الموقع
Default Operator يغير اتساع النتائج:
- AND: يطلب وجود كل كلمات البحث، فيعطي نتائج أضيق.
- OR: يسمح بنتائج تحتوي جزءًا من الكلمات، فيوسع النتائج.
لا توجد قيمة مثالية لكل المواقع. متجر بآلاف المنتجات قد يحتاج سلوكًا مختلفًا عن Documentation site. اختبر Queries حقيقية من المستخدمين ثم اضبط النتيجة.
4. استخدم Weighting بحذر
يمكن رفع وزن Title أوPost type أوحقول معينة حتى تظهر النتائج الأكثر أهمية أولًا. لا تضاعف الأوزان بلا قياس؛ إذا أصبح العنوان أقوى من اللازم قد تتقدم صفحة تذكر الكلمة في العنوان على صفحة أكثر فائدة في المحتوى.
Relevanssi والبحث العربي: ما الذي يعمل فعليًا؟
النقطة القديمة التي تقول إن Partial matching وحدها تحل الهمزات والتشكيل غير دقيقة. المطابقة الجزئية قد تساعد في حالات Prefix/substring، لكنها ليست Normalization لغويًا.
توثيق Relevanssi الرسمي للغات يقدم معالجة إضافية للعربية عبر Filter يقوم بتوحيد بعض الحروف مثل أشكال الألف وإزالة التشكيل قبل الفهرسة والبحث. إذا كان موقعك يعتمد على العربية، اختبر على الأقل الحالات التالية:
- إضافة / اضافات / إضافات.
- ألف بأشكالها: أ، إ، آ، ا.
- النص المشكول وغير المشكول.
- التاء المربوطة والهاء إذا كنت ستطبق Normalization مخصصًا.
- جمع/مفرد الكلمات التي لا يحلها Partial matching تلقائيًا.
المصدر الرسمي: Relevanssi and languages. بعد أي تغيير في Normalization يجب إعادة بناء الفهرس حتى تتطابق البيانات القديمة مع القواعد الجديدة.
Partial matching: متى تستخدمها؟
Partial matching قد تحسن العثور على كلمات تبدأ أوتنتهي بمقطع متشابه، لكنها قد توسع النتائج وتزيد كلفة الاستعلام. لا تستخدمها كبديل لـStemming أوArabic normalization.
Relevanssi نفسها توضح في Troubleshooting أن البحث لا يفهم Stems لكل اللغات تلقائيًا، وأن المطابقة الجزئية ليست مساوية لمعالجة صرفية كاملة.
هل Relevanssi تبطئ الموقع؟
الإضافة تنشئ جداول فهرسة قد تصبح كبيرة، لكن حجم الجدول وحده لا يعني أن كل صفحات الموقع ستصبح أبطأ؛ الاستعلامات الثقيلة ترتبط أساسًا بعمليات البحث والفهرسة. على المواقع الكبيرة، موارد قاعدة البيانات وطبيعة الاستعلامات والحقول المفهرسة تظل عوامل مهمة.
المطور يذكر حاليًا أن المواقع الكبيرة جدًا قد تصل إلى حدود على Shared Hosting، ويوصي بتقييم Relevanssi Light عندما تكون قابلية التوسع أهم من بعض الخصائص.
عمليًا راقب:
- حجم جداول Relevanssi.
- زمن Search requests.
- Queries الأكثر استخدامًا.
- عدد Post Types/Fields المفهرسة.
- أداء إعادة الفهرسة.
- توافق Live Search إن كان القالب يستخدم AJAX خاصًا.
مشكلة شائعة: البحث العادي يعمل لكن Live Search لا يستخدم Relevanssi
بعض القوالب أوSearch widgets تبني AJAX endpoint خاصًا وتستدعي بحث WordPress مباشرة، لذلك قد يعمل Relevanssi في صفحة النتائج بينما Autocomplete لا يستخدمها.
الـChecklist الرسمية تنصح أولًا بمقارنة Relevanssi Admin Search مع Frontend. إذا كانت Admin Search تعرض النتائج الصحيحة والواجهة لا تعرضها، فالمشكلة غالبًا في Integration وليس في الفهرس نفسه.
متى تختار Relevanssi؟
- البحث الافتراضي لا يعيد النتائج المهمة بالترتيب المناسب.
- تحتاج البحث في Custom Fields أوTaxonomies.
- لديك Knowledge Base أومحتوى كثيف.
- تحتاج ضبط Weighting واستبعاد محتوى محدد.
- لديك متطلبات عربية وتستطيع اختبار Normalization بدل الاعتماد على الإعداد الافتراضي.
متى لا تحتاجها؟
- الموقع صغير والبحث نادر والنتائج الحالية جيدة.
- القالب أوSearch service الخارجي يقدم بالفعل Search Engine مناسبًا.
- موارد الاستضافة محدودة جدًا ولا توجد حاجة حقيقية للفهرس الإضافي.
- تحتاج Semantic/Vector Search؛ Relevanssi أساسًا محرك بحث نصي قابل للضبط وليس Vector Database.
Checklist بعد التفعيل
- حدد Post Types والحقول المطلوبة فقط.
- ابنِ الفهرس.
- اختبر 20 Query حقيقية، وليس كلمة واحدة.
- اختبر العربية بأشكال الهمزات والتشكيل.
- راجع AND/OR وPartial matching.
- اضبط Weighting تدريجيًا.
- اختبر Search page وLive/AJAX search.
- راقب زمن البحث وحجم الفهرس.
- بعد تغيير Indexing/Normalization أعد بناء الفهرس.
الخلاصة
Relevanssi في 2026 خيار قوي عندما تحتاج بحث WordPress قابلًا للضبط بدل النتائج الافتراضية، لكن أفضل إعداد ليس “OR + Partial للجميع”. حدد ما يستحق الفهرسة، اضبط الصلة بناءً على Queries حقيقية، وعالج العربية بـNormalization موثق عند الحاجة، ثم قِس أداء البحث على بيانات موقعك.


1 تعليق