Discourse-indexnow: notifica de inmediato a Bing y Yandex cuando se crean o editan temas

soul · 23 Agosto, 2026 06:12


	Resumen	Envía automáticamente las URLs de temas públicos al protocolo IndexNow al crear, editar, eliminar o responder temas, para que Bing, Yandex y otros motores de búsqueda compatibles puedan descubrir o desindexar tu contenido en minutos, sin esperar a los rastreadores.
	Repositorio	github.com/imlotso/discourse-indexnow
	Guía de instalación	Cómo instalar plugins en Discourse

También está disponible una descripción en chino con más antecedentes en mi foro: sitetalk.net/t/topic/642

Funciones

Envía automáticamente nuevos temas públicos; vuelve a enviarlos cuando cambia la primera publicación o atributos críticos del tema.
Enviar en respuesta: Envía automáticamente la URL paginada (p. ej., ?page=3) cuando se publican nuevas respuestas, con un tiempo de espera configurable por URL para evitar el envío excesivo.
Envía automáticamente las URLs de los temas al eliminarlos para ayudar a los motores a detectar 404/410 y desindexarlos rápidamente.
Agrupa automáticamente las URLs de temas localizados cuando Content Localization y los parámetros de consulta de idioma del rastreador están activos. Utiliza el parámetro de idioma configurado realmente, no uno codificado.
Agrupa las URLs canónicas y localizadas en solicitudes por lotes de urlList de IndexNow en lugar de enviarlas una por una.
Relleno histórico: Filtra por categoría y rango de fechas, previsualiza el número de coincidencias y envía en lote. División automática para lotes que excedan el límite de 10.000 del protocolo. Los trabajos activos pueden cancelarse desde la pestaña Registros.
Envío manual: Envía URLs personalizadas bajo demanda línea por línea; los enlaces externos o no elegibles se filtran automáticamente.
Limitación de tasa inteligente: Aplica límites horarios y diarios utilizando un algoritmo de ventana deslizante de grano fino. Se retrasa automáticamente ante un 429 (respetando Retry-After). La interfaz de administración presenta Barras de Cuota visuales que muestran el uso actual y la hora exacta hasta que se libere capacidad.
Excluye categorías específicas y etiquetas como reglas de la capa de negocio además de los filtros de privacidad automatizados.
Rotación de claves con un cuadro de diálogo de confirmación de sobrescritura accidental; las claves anteriores se invalidan inmediatamente.
Verificación de administrador para la accesibilidad pública de /<key>.txt.
Los movimientos de temas, los cambios de visibilidad de categorías y las actualizaciones de etiquetas desencadenan un reenvío o exclusión asíncrona en trabajos de fondo para evitar bloqueos de la interfaz.
Entradas de registro detalladas con IDs de lote, idioma, razones de activación, gráficos de tendencia de éxito/fallo de 7 días y razones de fallo categorizadas (Límite de tasa, Error de clave, Desajuste de dominio).
Envíos totalmente asíncronos que respetan los límites de privacidad: los mensajes privados, las categorías restringidas, los temas no listados/eliminados y los sitios que requieren inicio de sesión nunca se envían.
Disponible en inglés y chino simplificado.

Pasos de configuración

Instala el plugin siguiendo la guía anterior y reconstruye tu contenedor.
Ve a Administración > Plugins > discourse-indexnow.
En Configuración, haz clic en Generar clave (o pega una clave hexadecimal de 32 caracteres existente).
Marca Habilitar envíos de IndexNow.
Verifica la accesibilidad pública de la clave:

https://tu-dominio-foro.com/<key>.txt

Debe devolver HTTP 200 con la cadena de la clave. El panel de administración también muestra un indicador verde/rojo en caché.
6. (Opcional) En la pestaña Registros, usa el panel “Relleno”: selecciona los criterios, haz clic en Previsualizar y luego en Enviar.
7. (Opcional) Usa el cuadro de envío manual para enviar URLs individuales fuera del flujo automatizado.

La página de Registros también presenta barras de uso de cuota, un gráfico de tendencia de 7 días y métricas de desglose de fallos para diagnosticar fácilmente los problemas de envío.

Configuración de ajustes

Ajuste	Descripción
`indexnow_enabled`	Interruptor principal. Se deshabilita automáticamente si `login_required` está habilitado.
`indexnow_api_key`	La clave hexadecimal de 32 caracteres para la verificación del envío.
`indexnow_submit_on_create`	Envío automático cuando se crea un nuevo tema público.
`indexnow_submit_on_edit`	Reenvío automático cuando cambia la primera publicación o los atributos del tema.
`indexnow_submit_on_reply`	Envío automático de la URL paginada específica cuando se publican nuevas respuestas.
`indexnow_url_cooldown_minutes`	Período de espera por URL (en minutos) para evitar envíos duplicados.
`indexnow_excluded_category_ids`	Categorías a excluir aunque sean públicas.
`indexnow_excluded_tag_names`	Etiquetas a excluir aunque la categoría del tema sea elegible.
`indexnow_hourly_limit`	Número máximo de URLs a enviar por hora (ventana deslizante).
`indexnow_daily_limit`	Número máximo de URLs a enviar por día (ventana deslizante).

Limitaciones conocidas

Google no participa actualmente en el protocolo IndexNow.
Las URLs localizadas solo se envían cuando los parámetros de idioma del rastreador están activos y existe contenido localizado.
Actualmente, se admiten las ediciones de la primera publicación y la paginación de nuevas respuestas, pero las ediciones de respuestas intermedias no desencadenan envíos de forma independiente.

Este es un plugin independiente y no oficial; no es mantenido por el equipo de Discourse. Está funcionando en producción en mi propio foro, tiene cobertura de pruebas RSpec con CI en cada empuje/PR, y agradecería cualquier informe de errores o solicitud de función a través de issues de GitHub o respuestas aquí.

AJ_Quick · 1 Septiembre, 2026 05:19

¡Gracias por esto! Acababa de decir literalmente, ¿necesito crear mi propio plugin de Indexnow? ¡Y boom! ¡Lo encontré!

¿Puedes decirme si indexnow_submit_on_edit emite un envío de Indexnow en TODAS las re-creaciones que cambian el contenido?

soul · 7 Septiembre, 2026 03:11

No — solo se dispara en ediciones genuinas a través del flujo normal de PostRevisor, y únicamente
para la primera publicación del tema (OP). Las respuestas que no son OP y los rebakes desencadenados por el sistema
(crons de corrección de imágenes, rebake masivo de administradores, etc.) no disparan un nuevo envío, ya que
esos no pasan por el evento en el que este plugin se engancha.

AJ_Quick · 7 Septiembre, 2026 17:18

Llevo una semana usando el plugin y ha sido excelente. Funciona exactamente como lo necesito, aunque me encontré con algunos errores que hacían que el plugin fallara inmediatamente tras la instalación.

Específicamente, detecté colisiones de rutas con otros plugins que utilizan los mismos puntos de acceso. También hubo un problema con la limitación de velocidad, donde los envíos podían alcanzar el límite, esperar unos minutos y volver a alcanzarlo. Además, la hoja de estilos del panel de administración se estaba inyectando en las áreas públicas, y las clases CSS no estaban prefijadas correctamente para el plugin.

También añadí una función que realmente quería: la capacidad de enviar cuando hay una respuesta a un tema. Este envío se asocia a un número de página específico para que no procese todo el tema. En temas con cientos de respuestas, solo envía la última página, lo que ayuda al rastreador a encontrar la respuesta y actualizar el tema mucho más rápido.

github.com/imlotso/discourse-indexnow

Issues found running discourse-indexnow on a production forum

opened 12:16AM - 02 Sep 26 UTC

ajquick

Thanks for building this. The feature set is genuinely useful and I want to keep… using it. I ran it on a live Discourse forum and hit a set of problems, some of them severe. I verified each of these against the code rather than reporting them from symptoms alone. Everything below refers to `v0.2.0`. I have fixes for most of these and I am happy to send them as PRs if you want. ## 1. The admin route path collides with other plugins and can take the browser down **Severity: High. The admin panel becomes unusable and the tab can run out of memory.** `assets/javascripts/discourse/admin-indexnow-route-map.js`: ```js export default { resource: "admin.adminPlugins.show", map() { this.route("discourse-indexnow", { path: "logs" }); }, }; ``` `adminPlugins.show` is mounted at `/plugins/:plugin_id`. Using `path: "logs"` does not restrict it to IndexNow's logs page. It claims `/admin/plugins/<ANY_PLUGIN>/logs` across the entire site. Any other installed plugin that uses `path: "logs"` will collide with it. On my forum `discourse-sitemap-autolink` did exactly that. Straight from the browser console: ```js Discourse.__container__.lookup("service:router") .recognize("/admin/plugins/discourse-indexnow/logs").name // => 'adminPlugins.show.discourse-sitemap-autolink-logs' ``` Visiting IndexNow's logs page rendered the *other plugin's* page under the IndexNow heading. **Why this escalates to a browser crash:** Core's `AdminPluginsShowIndexRoute.afterModel` (`frontend/discourse/admin/routes/admin-plugins/show/index.js`) does this: ```js afterModel(model) { if (this.adminPluginNavManager.currentPluginDefaultRoute) { this.router.replaceWith( this.adminPluginNavManager.currentPluginDefaultRoute, model.id ); } } ``` There is no check that the route exists. If the advertised nav route cannot be resolved, this throws on *every* visit to `/admin/plugins/discourse-indexnow`. Ember retries the route and the DOM grows on each retry. What I saw was: ```text Error: There is no route named adminPlugins.show.discourse-indexnow at CO.afterModel (index.js:14:19) ``` This was followed by the page rendering the site header over and over, scrolling forever, until the browser tab ran out of memory. Deactivating the plugin immediately made the admin panel accessible again. **Suggested fix:** Give both the route name and the path a plugin-specific prefix, like `this.route("discourse-indexnow-logs", { path: "indexnow-logs" })`. Naming the child route after the plugin id is also worth avoiding since it reads like the plugin's index route. *(Two upstream Discourse issues are arguably in play here too: `mapRoutes()` gives no warning when two plugins claim the same child path, and `replaceWith` above has no existence check. The plugin can avoid both by scoping its path.)* ## 2. The admin nav tab is registered without checking if the route resolves `assets/javascripts/initializers/indexnow-admin-plugin-configuration-nav.js` calls `api.addAdminPluginConfigurationNav(...)` unconditionally. Because of the unguarded `replaceWith` mentioned above, advertising a nav entry whose route failed to register is not a cosmetic problem. It is the difference between a missing tab and a completely broken admin panel. Confirming the route resolves before advertising it (`router.recognize(url)`) turns a hard crash into a gracefully absent tab. ## 3. Rate limits can be exceeded by 2x due to clock-based resets **Severity: High. This is the issue most likely to get a site rate-limited by IndexNow.** `lib/discourse_index_now/throttle.rb` keys its counters by clock hour and date: ```ruby def hourly_key(time = Time.zone.now) "indexnow:rate:hourly:#{time.strftime('%Y%m%d%H')}" end ``` The counter drops to zero on the clock boundary rather than as the counts age out. The full hourly cap can go out at 1:59 and the full cap again at 2:01. Run against the current code: ```text spend 200 at 01:59 -> at 02:01 used=0 capacity=200 ``` That pushes 400 URLs in two minutes against a configured cap of 200/hour. The same trick works across midnight for the daily cap, letting `indexnow_daily_limit` run twice over in a few minutes. IndexNow answers sustained over-submission with `429 Too Many Requests (potential Spam)`. **Suggested fix:** Sum fine-grained buckets covering a trailing window instead of using one bucket per calendar period. 60 one-minute buckets for the hourly cap and 24 one-hour buckets for the daily cap keeps the read to a single `MGET` of a fixed 84 keys. Cost does not grow with submission volume. Numbering buckets off the epoch rather than a formatted clock string also removes the time-zone dependency in the current keys. ## 4. The admin stylesheet is served globally and contains unprefixed selectors `plugin.rb`: ```ruby register_asset "stylesheets/admin.scss" ``` Without the `:admin` scope, this is linked on every forum page for every visitor, including anonymous ones, for a stylesheet only the admin panel uses. That would just be wasted bandwidth, but `assets/stylesheets/admin.scss` contains: ```scss .indexnow-controls, .status-filters, .url-search, ``` `.status-filters` and `.url-search` are generic enough to match theme or core markup. Shipped site-wide, they can restyle unrelated elements on public pages. **Suggested fix:** Use `register_asset "stylesheets/admin.scss", :admin` and prefix those two selectors (`.indexnow-status-filters`, `.indexnow-url-search`). ## 5. The JSON API returns an HTML page to non-JSON requests `config/routes.rb` declares the management endpoints without a format default: ```ruby scope "/admin/plugins/discourse-indexnow", module: "discourse_index_now", constraints: ::StaffConstraint.new do get "/logs.json" => "admin_logs#index" ... ``` These actions inherit `Admin::AdminController`, and `check_xhr` runs before the controller's own filters. A request that is neither an XHR nor explicitly asking for JSON gets the admin SPA HTML shell with HTTP 200. Confirmed by test with the format default removed: ```text GET /admin/plugins/discourse-indexnow/logs.json (Accept: */*) expected: "application/json" got: "text/html" ``` Scripts, `curl`, and uptime checks get a full HTML page where they asked for data. Because `check_xhr` fires first, `requires_plugin` never runs, meaning a disabled plugin still answers 200. **Suggested fix:** Add `defaults: { format: :json }` to that scope. ## 6. Category and tag changes fan out synchronously inside the web request `lib/discourse_index_now/submission_service.rb`: ```ruby def self.handle_category_updated(category) ... topics = Topic.where(category_id: category.id) if category.read_restricted? topics.find_each { |topic| mark_topic_logs_failed(topic, "category_restricted") } else topics.find_each do |topic| enqueue_topic(topic, localized: false, trigger_reason: :category_changed) end end end ``` This runs in the request that saved the category. Each `enqueue_topic` writes submission log rows and enqueues its own Sidekiq job. Flipping the visibility of a category with N topics costs N jobs and N sets of DB writes before the admin's save returns. On a large category, that is a guaranteed request timeout. `handle_tag_updated` has the same shape and lacks a `saved_change_to_*` guard. Any tag update, including editing a tag's description, resubmits every topic carrying that tag. **Suggested fix:** Move both into a background job and batch the URLs rather than spawning one job per topic. ## 7. Generating a key destroys a working key with no confirmation `generateKey` POSTs straight to `/generate_key.json`: ```js async generateKey() { try { this.loading = true; await ajax("/admin/plugins/discourse-indexnow/generate_key.json", { type: "POST" }); ``` One click on a live install replaces a key that is currently working, with no prompt and no undo. This goes beyond UX. After a rotation, IndexNow answers `202 URL received. IndexNow key validation pending` until it refetches `/<key>.txt`, and drops those URLs if validation fails. An accidental click quietly costs you submissions. **Suggested fix:** Add a confirmation dialog when a key already exists. Discourse's `dialog` service has `deleteConfirm` for exactly this. Skip the prompt when the field is empty. ## 8. HTTP 202 is logged as "Successful" identically to 200 `lib/discourse_index_now/client.rb`: ```ruby expects: [200, 202], ... { success: true, status: response.status } ``` Per the IndexNow spec these mean different things: * **200**: URL submitted successfully * **202**: URL received. IndexNow key validation pending 202 is not an acceptance. If key validation fails, those URLs are discarded. I hit this directly on my forum. Submissions came back 202, never showed up in Bing, and the admin log reported them as Successful alongside genuine 200s. The `response_code` is already stored on the log row, making this a display fix rather than a schema change. As it stands, an admin cannot tell landed submissions from pending ones. ## 9. Setting a limit to 0 blocks submissions and busy-loops the job queue `available_capacity` returns 0 when either limit is `<= 0`: ```ruby return 0 if hourly_limit <= 0 || daily_limit <= 0 ``` Here `0` means "submit nothing", not "unlimited". This is a reasonable choice, but neither setting has a `min:` constraint in `settings.yml` and the admin UI does not clarify this. An admin who sets 0 expecting no limits gets total silence with no explanation. Worse, `SubmitBatch` reschedules itself when capacity is 0, and `next_window_delay` has no branch for this case: ```ruby if hourly_limit.positive? && hourly_remaining <= 0 # false when limit is 0 ... retry_delay || 60 ``` The job reenqueues itself every 60 seconds indefinitely. Because it uses a fresh `Jobs.enqueue_in` rather than a Sidekiq retry, the `retry: 5` limit does not apply. **Suggested fix:** Enforce `min: 1` on both settings, or add an explicit branch that fails the batch with a clear reason instead of looping. ## Not a bug (noting so nobody chases it) **Replies are never submitted.** `handle_post_created` returns early on anything that isn't the first post: ```ruby return unless post.is_first_post? ``` I initially read this as an oversight, but I was wrong. Crawlers get the paginated view (`app/views/topics/show.html.erb`, chunked at `TopicView::CHUNK_SIZE`). Page 1's content genuinely only changes when the first post, title, category, or tags change. Submitting the topic's base URL on every reply asks search engines to refetch an unchanged page. That is exactly the pattern that earns a 429. The real gap is narrower. Later crawler pages do change on a reply, and those are never submitted. On a long topic, `/t/slug/id?page=17` is its own canonical URL and search engines never hear that it changed. Submitting `?page=N` for the page the reply landed on rather than the base URL addresses that without the over-submission the current gate protects against. I have forked the repo and will be submitting fixees that address these issues and add a few more features and options.

soul · 9 Septiembre, 2026 07:38

Fusionado.

Gracias por tomarte el tiempo para hacer un análisis tan profundo de la base de código. La lógica de agrupación para la ventana deslizante y el procesamiento por lotes de tareas en segundo plano son mejoras sólidas. El disparador de respuesta también es un gran detalle.

He actualizado la documentación de la publicación principal para cubrir las nuevas barras de cuota y las configuraciones de tiempo de espera que añadiste.

Aprecio mucho la alta calidad de la PR y la descripción detallada.

Tema		Respuestas	Vistas
Why doesn't Discourse support IndexNow? Feature seo	10	997	3 Enero 2025
Discourse 2.3.0.beta10 Release Notes Announcements release-notes	1	3474	30 Mayo 2019
Discourse 2.4.0.beta3 Release Notes Announcements release-notes	1	3876	4 Septiembre 2019
Discourse Version 1.3 Announcements release-notes	1	20948	25 Mayo 2015
Discourse Version 1.8 Announcements release-notes	3	18244	31 Mayo 2017

Discourse-indexnow: notifica de inmediato a Bing y Yandex cuando se crean o editan temas

Funciones

Pasos de configuración

Configuración de ajustes

Temas relacionados