Pourquoi Discourse ne supporte-t-il pas IndexNow ?

Après avoir examiné la fonctionnalité IndexNow, je suis d’accord pour qu’elle fasse partie des fonctionnalités/plugins principaux. Je comprends également que les ressources de développement sont limitées.

Voici mes réflexions sur le plugin requis pour aider l’équipe principale. N’hésitez pas à ajouter des commentaires supplémentaires.

Hypothèses :

  1. Le plugin IndexNow utilisera des notifications groupées selon un modèle temporel planifié - Voir Considération de conception n°1
  2. Les notifications groupées seront définies par un intervalle de temps
  3. Les notifications n’utiliseront que des sujets publics
  4. Les notifications ne concerneront que les sujets nouveaux/modifiés/supprimés lorsque le plugin est activé.
  5. Le plugin ne notifiera pas rétroactivement les changements/événements historiques.

Instructions pour les utilisateurs :

  1. Inscrivez-vous auprès du moteur de recherche IndexNow de votre choix.
    • Obtenez votre clé API
    • Obtenez l’URL du point de terminaison du moteur de recherche
  2. Installez le plugin
  3. Configuration de l’administrateur

Cas d’utilisation - Paramètres d’administration

  1. Permettre à l’utilisateur d’activer/désactiver les capacités de soumission automatique
  2. Permettre à l’utilisateur d’entrer le point de terminaison du moteur de recherche IndexNow. Voir Considération de conception n°3.
    • Le champ de saisie est un paramètre de texte
    • Le champ de saisie doit être une URL valide
    • Par défaut, l’URL de Bing est https://www.bing.com/indexnow
  3. Permettre à l’utilisateur de saisir et de stocker la clé API
    • Champ de saisie de type chaîne pour stocker la clé API
    • Le champ de saisie est alphanumérique
    • La valeur par défaut sera “”
  4. Permettre à l’utilisateur de définir les paramètres de planification pour les notifications groupées
    • Le paramètre de temps sera défini par un intervalle d’heures
    • Chaîne de saisie pour stocker la valeur des heures
    • Les entrées valides seront des entiers
    • Les entrées valides peuvent varier de 1 à 24
    • La valeur par défaut sera 12

Cas d’utilisation - Fichier de clé texte

  1. Le système générera un fichier appelé indexnowkey.txt
  2. Le fichier de clé doit être stocké à la racine.
  3. Le système remplira le fichier avec la clé API
  4. Le fichier sera accessible par tout utilisateur/système distant via http/https

Cas d’utilisation - Planification du processus de notification groupée

  1. Le système planifiera les tâches à traiter à intervalles réguliers en fonction du paramètre défini dans les paramètres d’administration.
  2. La valeur de l’intervalle définit le délai entre les tâches en heures. Par exemple, une valeur d’entrée de 2 indiquerait que la tâche doit s’exécuter toutes les 2 heures. Une valeur de 4 indique que la tâche doit s’exécuter toutes les 4 heures. Une valeur de 24 indique que la tâche doit s’exécuter une fois par jour.

Cas d’utilisation - Processus de notification groupée

  1. Le système déterminera si le processus de notification est activé via le paramètre du site défini dans les paramètres d’administration.
  2. Le système déterminera si une clé API est valide dans les paramètres du site - pas “”.
  3. Le système créera une liste de sujets basée sur le paramètre d’intervalle de temps défini. Voir la considération de conception n°2 sur les délais de requête. Les paramètres de sujet à inclure sont :
    • Les sujets doivent être en lecture seule publique
    • Nouveaux sujets
    • Sujets avec de nouveaux messages
    • Sujets avec des messages modifiés
    • Sujets supprimés
    • La liste des sujets doit être distincte - pas de doublons
  4. Le système créera le paquet JSON en utilisant le format suivant.
{
  "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. Le paquet JSON sera envoyé à l’adresse suivante : sitesettings.search_engine_indexnow_endpoint
  2. Le paquet JSON sera envoyé avec les en-têtes suivants :
    • Content-Type: application/json; charset=utf-8
    • Http/1.1
    • Host: bing
  3. Valider la réception de la soumission de la requête HTTP
    • http 200 - soumission réussie - fin du processus
    • Http 429 - Trop de tentatives de soumission - Envoyer une notification à l’administrateur pour augmenter le délai d’intervalle

Considérations de conception :

  1. Notifications groupées vs. Notifications individuelles — Une notification individuelle serait acceptable pour les petits domaines, mais pour les forums plus importants, l’ajout d’une notification pour chaque publication nouvelle/mise à jour pourrait créer de nombreux processus événementiels. Du point de vue des performances d’indexation par les moteurs de recherche, des notifications groupées sur une base horaire seraient acceptables pour 80 % des forums.
  2. Délai de requête des notifications groupées - SideKiq contrôle les délais d’intervalle. Si SideKiq est dans un état de traitement intensif, le processus de notification groupée pourrait être retardé. Le processus de notification groupée pourrait manquer les sujets nouveaux/mis à jour si le délai de requête est égal à l’intervalle de planification. Un paramètre de temps devrait-il étendre la requête pour couvrir les processus retardés ? Ou est-il possible que le planificateur transmette des horodatages initiés pour contrôler les délais de requête ? Ou devons-nous créer une table/valeur de base de données pour les sujets soumis avec un horodatage ?
  3. Devrions-nous créer une table interne avec chaque moteur de recherche et le point de terminaison d’URL IndexNow défini ? L’utilisateur pourrait choisir parmi un menu déroulant au lieu de saisir une URL. Cela élimine les erreurs humaines potentielles.

Qu’est-ce qui manque ? Qu’ajouteriez-vous ?