Discourse-indexnow — мгновенное уведомление Bing и Yandex о создании или редактировании тем

soul · 23.Август.2026 06:12:27


	Сводка	Автоматически отправляет публичные URL тем при создании, редактировании, удалении и ответах в протокол IndexNow, чтобы Bing, Yandex и другие совместимые поисковые системы могли обнаружить или удалить ваш контент в течение минут, не дожидаясь сканеров.
	Репозиторий	github.com/imlotso/discourse-indexnow
	Руководство по установке	Как установить плагины в Discourse

Также доступна статья на китайском языке с дополнительной информацией на моем форуме: sitetalk.net/t/topic/642

Возможности

Автоматическая отправка новых публичных тем; повторная отправка при изменении первого сообщения или критических атрибутов темы.
Отправка при ответе: Автоматически отправляет URL с пагинацией (например, ?page=3) при публикации новых ответов, с настраиваемым временем ожидания (cooldown) для каждого URL для предотвращения спама.
Автоматическая отправка URL тем при удалении, чтобы помочь поисковым системам обнаружить ошибки 404/410 и быстро удалить их из выдачи.
Автоматически группирует локализованные URL тем, когда активны локализация контента и параметры запроса локали сканера. Использует фактически настроенный параметр локали, а не захардкоженное значение.
Объединяет канонические и локализованные URL в единые пакетные запросы urlList IndexNow, вместо отправки по одному.
Заполнение истории (Backfill): Фильтрация по категории и диапазону дат, предпросмотр количества совпадений и пакетная отправка. Автоматическое разбиение на части для пакетов, превышающих лимит протокола в 10 000. Активные задачи можно отменить на вкладке Журнал.
Ручная отправка: Отправка пользовательских URL по запросу, строка за строкой; внешние или неподходящие ссылки автоматически отфильтровываются.
Умное ограничение частоты: Применяет почасовые и суточные лимиты, используя алгоритм скользящего окна с высокой точностью. Автоматически замедляет работу при ошибке 429 (с учетом заголовка Retry-After). В административном интерфейсе есть визуальные Полосы квоты, показывающие текущее использование и точное время до освобождения квоты.
Исключение определенных категорий и тегов как правила бизнес-логического уровня поверх автоматических фильтров конфиденциальности.
Ротация ключей с диалогом подтверждения случайного перезаписывания; предыдущие ключи немедленно аннулируются.
Административная проверка публичной доступности /<key>.txt.
Перемещение тем, изменение видимости категорий и обновление тегов вызывают асинхронную повторную отправку или исключение в фоновых задачах, чтобы предотвратить блокировку интерфейса.
Подробные записи журнала с ID пакетов, локалью, причинами срабатывания, диаграммами тенденций успеха/неудачи за 7 дней и категоризированными причинами сбоев (Ограничение частоты, Ошибка ключа, Несоответствие домена).
Полностью асинхронная отправка с соблюдением границ конфиденциальности: личные сообщения, ограниченные категории, скрытые/удаленные темы и сайты, требующие входа, никогда не отправляются.
Доступно на английском и упрощенном китайском языках.

Шаги настройки

Установите плагин, следуя руководству выше, и пересоберите ваш контейнер.
Перейдите в Администрирование > Плагины > discourse-indexnow.
В разделе Настройки нажмите Сгенерировать ключ (или вставьте существующий 32-символьный hex-ключ).
Отметьте Включить отправки IndexNow.
Проверьте публичную доступность ключа:

https://your-forum-domain.com/<key>.txt

Должен возвращать HTTP 200 со строкой ключа. Панель администратора также отображает индикатор (зеленый/красный) из кэша.
6. (Необязательно) На вкладке Журнал используйте панель «Backfill»: выберите критерии, нажмите Предпросмотр, затем Отправить.
7. (Необязательно) Используйте поле ручной отправки для отправки отдельных URL вне автоматического процесса.

Страница журнала также содержит полосы использования квоты, диаграмму тенденций за 7 дней и метрики разбивки сбоев для легкого диагностирования проблем с отправкой.

Настройки конфигурации

Настройка	Описание
`indexnow_enabled`	Главный переключатель. Автоматически отключается, если включен `login_required`.
`indexnow_api_key`	32-символьный hex-ключ для верификации отправки.
`indexnow_submit_on_create`	Автоотправка при создании новой публичной темы.
`indexnow_submit_on_edit`	Автоповторная отправка при изменении первого сообщения или атрибутов темы.
`indexnow_submit_on_reply`	Автоотправка конкретного URL с пагинацией при публикации новых ответов.
`indexnow_url_cooldown_minutes`	Период ожидания (cooldown) для каждого URL (в минутах) для предотвращения дублирования отправки.
`indexnow_excluded_category_ids`	Категории, которые следует исключить, даже если они публичные.
`indexnow_excluded_tag_names`	Теги, которые следует исключить, даже если категория темы подходит.
`indexnow_hourly_limit`	Максимальное количество URL для отправки в час (скользящее окно).
`indexnow_daily_limit`	Максимальное количество URL для отправки в день (скользящее окно).

Известные ограничения

Google в настоящее время не участвует в протоколе IndexNow.
Локализованные URL отправляются только тогда, когда активны параметры локали сканера и существует локализованный контент.
В настоящее время поддерживаются редактирование первого сообщения и пагинация новых ответов, но редактирование промежуточных ответов не вызывает отправку независимо.

Это независимый неофициальный плагин — он не поддерживается командой Discourse. Он работает в продуктивной среде на моем собственном форуме, имеет покрытие тестами RSpec с CI при каждом пуше/PR, и я буду признателен за любые сообщения об ошибках или запросы функций через GitHub issues или ответы здесь.

AJ_Quick · 01.Сентябрь.2026 05:19:17

Спасибо за это! Я буквально только что спрашивал себя, нужно ли мне самому делать плагин для Indexnow? И вот! Нашёл это!

Подскажи, пожалуйста: метод indexnow_submit_on_edit отправляет запрос на индексацию при каждом пересобирании (rebake), которое изменяет контент?

soul · 07.Сентябрь.2026 03:11:27

Нет — срабатывание происходит только при настоящих правках через обычный поток PostRevisor и только для первого поста темы (OP). Ответы, не являющиеся OP, и повторные пересборки, инициированные системой (например, cron-задачи по исправлению изображений, массовая пересборка администратором и т. д.), не вызывают повторную отправку, поскольку они не проходят через событие, на которое этот плагин реагирует.

AJ_Quick · 07.Сентябрь.2026 17:18:52

Я пользуюсь этим плагином уже неделю, и он мне очень нравится. Он работает ровно так, как мне нужно, хотя я столкнулся с несколькими ошибками, из-за которых плагин сразу же выходил из строя после установки.

В частности, я обнаружил конфликты маршрутов с другими плагинами, использующими те же конечные точки. Также была проблема с ограничением частоты запросов: отправка могла достигать лимита, ждать несколько минут, а затем снова его превышать. Кроме того, таблица стилей админ-панели внедрялась в публичные области, а классы CSS не были должным образом префиксированы для плагина.

Я также добавил функцию, которую очень хотел: возможность отправлять уведомления, когда на тему появляется ответ. Эта привязана к конкретному номеру страницы, чтобы не обрабатывать всю тему целиком. Для тем со сотнями ответов отправляется только последняя страница, что помогает поисковому роботу быстрее находить ответ и обновлять тему.

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 · 09.Сентябрь.2026 07:38:11

Слилось.

Спасибо, что уделил время и так глубоко погрузился в код. Логика группировки для скользящего окна и пакетная обработка фоновых задач — это серьёзные улучшения. Отличное решение и с триггером ответа.

Я обновил документацию основного поста, чтобы охватить новые полосы квот и настройки кулдауна, которые ты добавил.

Очень ценю высококачественный PR и подробное описание.

Тема		Ответов	Просм.
Why doesn't Discourse support IndexNow? Feature seo	10	996	03.01.2025
Discourse 2.3.0.beta10 Release Notes Announcements release-notes	1	3474	30.05.2019
Discourse 2.4.0.beta3 Release Notes Announcements release-notes	1	3876	04.09.2019
Discourse Version 1.3 Announcements release-notes	1	20948	25.05.2015
Discourse Version 1.8 Announcements release-notes	3	18243	31.05.2017

Discourse-indexnow — мгновенное уведомление Bing и Yandex о создании или редактировании тем

Возможности

Шаги настройки

Настройки конфигурации

Связанные темы