En la información actual, que cambia rápidamente y queda obsoleta con la misma velocidad, la velocidad de indexación es uno de los factores más importantes para el éxito.
Porque a nadie le importó lo suficiente como para crear un plugin o una pull request para admitirlo. Lo que, diría yo, probablemente se deba al hecho de que Google no admite IndexNow, que es el motor de búsqueda que más le importa a la gente.
¡Pero si quieres crear un plugin para añadir esta función, es una contribución bienvenida!
¿Alguna noticia sobre Index Now? Ahora que incluso OpenAI ejecuta un motor de búsqueda que se basa en el índice de Bing y que está vinculado a IndexNow, tiene aún más sentido.
Entonces podrías encargar el plugin en Marketplace. Puedo imaginar soluciones en el rango de $500 a $2000. Otros podrían tener mejor imaginación que yo.
Después de revisar la funcionalidad de IndexNow, estoy de acuerdo en que debería ser una de las características/plugins principales. También entiendo que los recursos de desarrollo son limitados.
Aquí están mis pensamientos sobre el plugin requerido para ayudar al equipo principal. No dude en agregar comentarios adicionales.
Supuestos:
El plugin IndexNow utilizará notificaciones masivas en un modelo de tiempo programado - Ver Consideración de Diseño #1
Las notificaciones masivas se establecerán en un intervalo de tiempo.
Las notificaciones solo usarán temas públicos.
Las notificaciones serán solo para temas nuevos/modificados/eliminados cuando el plugin esté habilitado.
El plugin no notificará retroactivamente cambios/eventos históricos.
Instrucciones para los usuarios:
Regístrese en el motor de búsqueda de IndexNow de su elección.
Obtenga su clave API
Obtenga la URL del punto final del motor de búsqueda
Instalar Plugin
Configurar administrador
Caso de uso - Configuración del administrador
Permitir al usuario activar/desactivar las capacidades de envío automático.
Permitir al usuario ingresar el punto final del motor de búsqueda IndexNow. Ver Consideración de Diseño #3.
El campo de entrada es un parámetro de texto.
El campo de entrada debe ser una URL válida.
Por defecto, la URL de Bing en https://www.bing.com/indexnow
Permitir al usuario ingresar y almacenar la clave API.
Campo de cadena de entrada para almacenar la clave API.
El campo de entrada es alfanumérico.
El valor predeterminado será “”.
Permitir al usuario definir parámetros de tiempo programado para notificaciones masivas.
El parámetro de tiempo se establecerá por intervalo de horas.
Cadena de entrada para almacenar el valor de la hora.
Las entradas válidas serán enteros.
Las entradas válidas pueden variar de 1 a 24.
El valor predeterminado será 12.
Caso de uso - Archivo de clave de texto
El sistema generará un archivo llamado indexnowkey.txt.
El archivo de clave debe almacenarse en el nivel raíz.
El sistema poblará el archivo con la clave API.
El archivo será accesible para cualquier usuario/sistema remoto a través de http/https.
Caso de uso - Programación del proceso de notificación masiva
El sistema programará los trabajos para que se procesen a intervalos según la configuración definida en la configuración del administrador.
El valor del intervalo define el retraso entre trabajos en horas. Por ejemplo, un valor de entrada de 2 indicaría que el trabajo debe ejecutarse cada 2 horas. Un valor de 4 indica que el trabajo debe ejecutarse cada 4 horas. Un valor de 24 indicaría que el trabajo debe ejecutarse una vez al día.
Caso de uso - Proceso de notificación masiva
El sistema determinará si el proceso de notificación está activado a través de la configuración del sitio definida en la configuración del administrador.
El sistema determinará si una clave API es válida en la configuración del sitio - no “”.
El sistema creará una lista de temas basada en la configuración del intervalo de tiempo definido. Ver Consideración de Diseño #2 sobre los marcos de tiempo de consulta. Los parámetros del tema para la inclusión son:
Los temas deben ser solo de vista pública.
Temas nuevos
Temas con nuevas publicaciones
Temas con publicaciones editadas
Temas eliminados
La lista de temas debe ser distinta, sin duplicados.
El sistema creará el paquete JSON utilizando el siguiente formato.
El paquete JSON se enviará con las siguientes cabeceras:
Content-Type: application/json; charset=utf-8
Http/1.1
Host: bing
Validar la recepción de la solicitud HTTP.
http 200 - envío exitoso - fin del proceso
Http 429 - Demasiados intentos de envío - Enviar notificación al administrador para aumentar el tiempo de intervalo.
Consideraciones de diseño:
Notificaciones masivas vs. Notificaciones individuales: Una notificación individual sería aceptable para dominios pequeños, pero para foros más grandes, agregar una notificación por cada publicación nueva/actualizada podría crear muchos procesos de eventos. Desde la perspectiva del rendimiento de indexación del motor de búsqueda, las notificaciones masivas cada hora serían aceptables para el 80% de los foros.
Tiempo de consulta de notificaciones masivas: SideKiq controla los tiempos de intervalo. Si SideKiq está en un estado de proceso intenso, el proceso de notificación masiva podría retrasarse. El proceso de notificación masiva podría perder temas nuevos/actualizados si el marco de tiempo de consulta es igual al intervalo de programación. ¿Debería un parámetro de tiempo extender la consulta para cubrir procesos retrasados? ¿O es posible que el programador pase marcas de tiempo iniciadas para controlar los intervalos de tiempo de consulta? ¿O necesitamos crear una tabla/valor de base de datos para los temas enviados con una marca de tiempo?
¿Deberíamos crear una tabla interna con cada motor de búsqueda y el punto final de URL IndexNow definido? El usuario puede seleccionar las opciones de un menú desplegable en lugar de ingresar una URL. Esto elimina posibles errores humanos.
Eso parece un esquema bastante decente. Creo que solo haría envíos masivos/por lotes para evitar tener dos métodos para escribir, depurar, probar y mantener.
O tal vez un solo trabajo masivo/por lotes podría evitar los problemas de limitación de velocidad y luego tener solo una forma de enviar cosas (solo en un lote, nunca a nivel de publicación individual).
Una versión que se enviara a un solo punto final costaría entre $2000 por algo que pareciera funcionar y tuviera un manejo mínimo de errores, y $5000 por algo con al menos algunas especificaciones para hacer pruebas; y tal vez podría manejar la notificación a múltiples puntos finales.
Estás haciendo una gran pregunta de “Cómo”. No soy la mejor persona para hacer preguntas de “Cómo” sobre Discourse.
Soy bueno documentando “Qué” se necesita. Obtener una definición buena y clara de “Qué” se necesita hará que la codificación sea más rápida y, por lo tanto, más barata.
Para responder al “Qué” para los webhooks, creo que se refiere a notificaciones individuales frente a notificaciones masivas. Tengo un foro de tamaño mediano y preferiría notificaciones masivas.
No necesito que los motores de búsqueda sean notificados cuando se crea o actualiza un tema.
No me gusta agregar eventos de menor prioridad dentro de procesos críticos como la creación de temas y publicaciones. Agregar eventos adicionales aumenta el tiempo de espera para los usuarios. Un método masivo solo requiere una consulta SQL y un envío HTTP. Puede procesarse como un evento de backend fuera de la interacción del usuario.
El plugin solo necesitaría ser desarrollado para un endpoint. El acuerdo IndexNow requiere que los motores de búsqueda compartan las presentaciones entre ellos. Es decir, tú envías a Bing y luego Bing envía a los otros motores de búsqueda que cumplen con IndexNow.
Necesitamos 30 miembros para financiar colectivamente a $100 cada uno para desarrollar el plugin.