لماذا لا يدعم Discourse تقنية IndexNow؟

ميزة
1

في عالم اليوم سريع الخطى والمعلومات التي تتقادم بسرعة، تعد سرعة الفهرسة أحد أهم عوامل النجاح.
ولكن لماذا لا يدعم ديسكورس هذا البروتوكول على الإطلاق؟ https://www.indexnow.org/

3 إعجابات
2

لأن لا أحد اهتم بما يكفي لبناء إضافة أو طلب سحب لدعمه. وهو ما أقول إنه ربما ناتج عن حقيقة أن جوجل لا تدعم IndexNow، وهي محرك البحث الذي يهتم به معظم الناس.

ولكن إذا كنت ترغب في بناء إضافة لإضافة هذه الميزة، فهذا مساهمة مرحب بها!

14 إعجابًا
3

أود المساهمة في المجتمع وبرمجة هذا الامتداد، لكننا لسنا مبرمجين.

موقف جوجل تجاه IndexNow هو أنها تختبره وسنرى.

4

هل هناك أي أخبار عن Index Now؟ الآن بعد أن قامت OpenAI بتشغيل محرك بحث يستمد من فهرس Bing وهو مرتبط بـ IndexNow، أصبح الأمر منطقيًا أكثر.

5

إذًا، يمكنك تكليف بإنشاء المكون الإضافي في Marketplace. يمكنني تخيل حلول في نطاق 500 دولار إلى 2000 دولار. قد يكون لدى الآخرين خيال أفضل مني.

3 إعجابات
11

أوافق، يبدو الآن وقتًا رائعًا لـ Discourse لدعم IndexNow :))

إعجاب واحد (1)
12

بعد مراجعة إمكانية IndexNow، أتفق على أن هذه يجب أن تكون إحدى الميزات/الإضافات الأساسية. أفهم أيضًا أن موارد المطور محدودة.

إليك أفكاري حول المكون الإضافي المطلوب لمساعدة الفريق الأساسي. لا تتردد في إضافة تعليقات إضافية.

الافتراضات:

  1. سيستخدم المكون الإضافي IndexNow الإشعارات المجمعة في نموذج وقت مجدول - انظر اعتبارات التصميم #1
  2. سيتم تعيين الإشعارات المجمعة على فترات زمنية
  3. ستستخدم الإشعارات المواضيع العامة فقط
  4. ستكون الإشعارات فقط للمواضيع الجديدة/المعدلة/المحذوفة عند تمكين المكون الإضافي.
  5. لن يقوم المكون الإضافي بإخطار التغييرات/الأحداث التاريخية بأثر رجعي.

تعليمات للمستخدمين:

  1. قم بالتسجيل في محرك البحث IndexNow الذي تختاره.
    • احصل على مفتاح API الخاص بك
    • احصل على عنوان URL لنقطة نهاية محرك البحث
  2. تثبيت المكون الإضافي
  3. إعداد المسؤول

حالة الاستخدام - إعدادات المسؤول

  1. السماح للمستخدم بتشغيل/إيقاف قدرات الإرسال التلقائي
  2. السماح للمستخدم بإدخال نقطة نهاية محرك بحث IndexNow. انظر اعتبارات التصميم #3.
    • حقل الإدخال هو معلمة نصية
    • يجب أن يكون حقل الإدخال عنوان URL صالحًا
    • الافتراضي إلى عنوان URL لـ Bing على https://www.bing.com/indexnow
  3. السماح للمستخدم بإدخال وتخزين مفتاح API
    • حقل سلسلة إدخال لتخزين مفتاح API
    • حقل الإدخال أبجدي رقمي
    • القيمة الافتراضية ستكون “”
  4. السماح للمستخدم بتحديد معلمات الوقت المجدول للإشعارات المجمعة
    • سيتم تعيين المعلمة الزمنية حسب فترات الساعات
    • سلسلة إدخال لتخزين قيمة الساعة
    • المدخلات الصالحة ستكون أعدادًا صحيحة
    • المدخلات الصالحة يمكن أن تتراوح من 1 إلى 24
    • القيمة الافتراضية ستكون 12

حالة الاستخدام - ملف مفتاح النص

  1. سيقوم النظام بإنشاء ملف يسمى indexnowkey.txt
  2. يجب تخزين ملف المفتاح في المستوى الجذر.
  3. سيقوم النظام بملء الملف بمفتاح API
  4. سيكون الملف متاحًا لأي مستخدم/نظام خارجي عبر http/https

حالة الاستخدام - جدولة عملية الإشعارات المجمعة

  1. سيقوم النظام بجدولة المهام للمعالجة على أساس فترات زمنية بناءً على الإعداد المحدد في إعدادات المسؤول.
  2. تحدد قيمة الفترة الزمنية التأخير بين المهام بالساعات. على سبيل المثال، تشير قيمة إدخال 2 إلى أنه يجب تشغيل المهمة كل ساعتين. تشير قيمة 4 إلى أنه يجب تشغيل المهمة كل 4 ساعات. تشير قيمة 24 إلى أنه يجب تشغيل المهمة مرة واحدة يوميًا.

حالة الاستخدام - عملية الإشعارات المجمعة

  1. سيحدد النظام ما إذا كانت عملية الإخطار نشطة عبر إعداد الموقع المحدد في إعدادات المسؤول.
  2. سيحدد النظام ما إذا كان مفتاح API صالحًا في إعدادات الموقع - ليس “”.
  3. سيقوم النظام بإنشاء قائمة بالمواضيع بناءً على إعداد الفترة الزمنية المحدد. انظر اعتبارات التصميم #2 حول أطر زمنية الاستعلام. معلمات الموضوع للتضمين هي:
    • يجب أن تكون المواضيع للعرض العام فقط
    • مواضيع جديدة
    • مواضيع بها منشورات جديدة
    • مواضيع تم تعديل المنشورات فيها
    • مواضيع محذوفة
    • يجب أن تكون قائمة المواضيع مميزة - لا توجد تكرارات
  4. سيقوم النظام بإنشاء حزمة JSON باستخدام التنسيق التالي.
{
  "host": "current_site",
  "key": "api_key",
  "keyLocation": "https://current_site/indexnowkey.txt",
  "urlList": [
      "https://www.example.com/url1",
      "https://www.example.com/folder/url2",
      "https://www.example.com/url3"
      ]
}
  1. سيتم إرسال حزمة JSON إلى ما يلي
    • URL: sitesettings.search_engine_indexnow_endpoint
  2. سيتم إرسال حزمة JSON مع رؤوس HTTP التالية
    • Content-Type: application/json; charset=utf-8
    • Http/1.1
    • Host: bing
  3. التحقق من استلام طلب HTTP
    • http 200 - إرسال ناجح - إنهاء العملية
    • Http 429 - محاولات إرسال كثيرة جدًا - إرسال إشعار إلى المسؤول لزيادة توقيت الفترة الزمنية

اعتبارات التصميم:

  1. الإشعارات المجمعة مقابل الإشعارات الفردية - ستكون الإشعارات الفردية مقبولة للمجالات الصغيرة، ولكن بالنسبة للمنتديات الكبيرة، قد يؤدي إضافة إشعار لكل منشور جديد/محدث إلى إنشاء العديد من عمليات الأحداث. من منظور أداء فهرسة محركات البحث، ستكون الإشعارات المجمعة على أساس كل ساعة مقبولة لـ 80٪ من المنتديات.
  2. توقيت استعلام الإشعارات المجمعة - يتحكم SideKiq في توقيتات الفترات الزمنية. إذا كان SideKiq في حالة معالجة ثقيلة، فقد تتأخر عملية الإشعارات المجمعة. قد تفوت عملية الإشعارات المجمعة المواضيع الجديدة/المحدثة إذا كان إطار زمني الاستعلام يساوي فترة الجدولة. هل يجب أن يمد معلم الوقت الاستعلام لتغطية العمليات المتأخرة؟ أم هل من الممكن أن يقوم المجدول بتمرير الطوابع الزمنية المبادر بها للتحكم في فترات زمنية الاستعلام؟ أم هل نحتاج إلى إنشاء جدول قاعدة بيانات/قيمة للمواضيع المرسلة مع طابع زمني؟
  3. هل يجب علينا بناء جدول داخلي مع كل محرك بحث وعنوان URL لنقطة نهاية IndexNow المحدد؟ يمكن للمستخدم اختيار الخيارات من قائمة منسدلة بدلاً من إدخال عنوان URL. هذا يزيل الأخطاء البشرية المحتملة.

ما هو المفقود؟ ماذا ستضيف؟

13

هل هناك طريقة للاستفادة من دعم خطافات الويب الصادرة الحالية لدينا لتحقيق بعض/كل ما تريده؟

إعجاب واحد (1)
14

يبدو هذا مخططًا لائقًا جدًا. أعتقد أنني سأقوم فقط بإرسال الدُفعات/الكميات لتجنب وجود طريقتين للكتابة وتصحيح الأخطاء واختبارها وصيانتها.

أو ربما يمكن لوظيفة واحدة مجمعة/دفعة أن تتجنب مشكلات تحديد المعدل، ثم يكون لديك طريقة واحدة فقط لتقديم الأشياء (فقط في دفعة، وليس على مستوى كل منشور أبدًا).

قد يكلف إصدار يرسل إلى نقطة نهاية واحدة 2000 دولار لشيء يبدو أنه يعمل ولديه الحد الأدنى من معالجة الأخطاء، و 5000 دولار لشيء لديه على الأقل بعض المواصفات لإجراء الاختبارات؛ وربما يمكنه التعامل مع إخطار نقاط نهاية متعددة؟

15

أنت تطرح سؤال “كيف” رائعًا. لست الشخص الأفضل لطرح أسئلة “كيف” حول Discourse.

أنا جيد في توثيق “ما” هو مطلوب. الحصول على تعريف جيد وواضح لـ “ما” هو مطلوب سيجعل البرمجة أسرع وبالتالي أرخص.

للإجابة على “ما” الخاص بالخطافات (webhooks)، أعتقد أنها تشير إلى الإشعارات الفردية مقابل الإشعارات المجمعة. لدي منتدى متوسط الحجم وأفضل الإشعارات المجمعة.

  1. لا أحتاج إلى إخطار محركات البحث عند إنشاء موضوع أو تحديثه.
  2. لا أحب إضافة أحداث ذات أولوية أقل ضمن عمليات حرجة مثل إنشاء الموضوع والمنشور. إضافة أحداث إضافية يزيد من وقت الانتظار للمستخدمين. تتطلب الطريقة المجمعة استعلام SQL واحدًا وإرسال HTTP واحدًا. يمكن معالجتها كحدث خلفي خارج تفاعل المستخدم.
16

لن يحتاج المكون الإضافي إلا إلى التطوير لنقطة نهاية واحدة. يتطلب اتفاق IndexNow من محركات البحث مشاركة عمليات الإرسال فيما بينها. أي، تقوم بالإرسال إلى Bing، ثم يقوم Bing بالإرسال إلى محركات البحث الأخرى المتوافقة مع IndexNow.

نحتاج إلى 30 عضوًا لتمويل جماعي بقيمة 100 دولار لكل منهم للحصول على المكون الإضافي مطورًا.

إعجاب واحد (1)