.txt
```
Sollte HTTP 200 mit der Schlüsselzeichenfolge zurückgeben. Das Admin-Panel zeigt auch einen zwischengespeicherten grünen/roten Indikator an.
6. (Optional) Verwenden Sie im Reiter **Logs** das Panel „Backfill“: Wählen Sie Kriterien, klicken Sie auf **Vorschau** , dann auf **Senden**.
7. (Optional) Verwenden Sie das manuelle Sendefeld, um einzelne URLs außerhalb des automatisierten Flusses zu senden.
Die Log-Seite bietet auch Quota-Nutzungsleisten, ein 7-Tage-Trenddiagramm und Fehlerschritt-Metriken, um Übermittlungsprobleme leicht zu diagnostizieren.
### Konfigurationseinstellungen
| Einstellung | Beschreibung |
| --- | --- |
| `indexnow_enabled` | Hauptschalter. Wird automatisch deaktiviert, wenn `login_required` aktiviert ist. |
| `indexnow_api_key` | Der 32-stellige Hex-Schlüssel zur Verifizierung der Übermittlung. |
| `indexnow_submit_on_create` | Automatisch senden, wenn ein neues öffentliches Thema erstellt wird. |
| `indexnow_submit_on_edit` | Automatisch erneut senden, wenn der erste Beitrag oder Themenattribute geändert werden. |
| `indexnow_submit_on_reply` | Automatisch die spezifische paginierte URL senden, wenn neue Antworten gepostet werden. |
| `indexnow_url_cooldown_minutes` | Abklingzeit pro URL (in Minuten), um doppelte Übermittlungen zu verhindern. |
| `indexnow_excluded_category_ids` | Kategorien, die ausgeschlossen werden sollen, auch wenn sie öffentlich sind. |
| `indexnow_excluded_tag_names` | Tags, die ausgeschlossen werden sollen, auch wenn die Themenkategorie berechtigt ist. |
| `indexnow_hourly_limit` | Maximale Anzahl der pro Stunde zu sendenden URLs (Sliding Window). |
| `indexnow_daily_limit` | Maximale Anzahl der pro Tag zu sendenden URLs (Sliding Window). |
**Bekannte Einschränkungen**
- Google nimmt derzeit nicht am IndexNow-Protokoll teil.
- Lokalisierte URLs werden nur übermittelt, wenn Crawler-Locale-Parameter aktiv sind und lokalisierte Inhalte vorhanden sind.
- Derzeit werden Bearbeitungen des ersten Beitrags und die Paginierung neuer Antworten unterstützt, aber Bearbeitungen von Zwischenantworten lösen keine eigenständigen Übermittlungen aus.
Dies ist ein unabhängiges, inoffizielles Plugin – nicht vom Discourse-Team gewartet. Es läuft produktiv auf meinem eigenen Forum, hat RSpec-Testabdeckung mit CI bei jedem Push/PR, und ich würde mich über Bug-Reports oder Funktionswünsche über GitHub-Issues oder Antworten hier freuen.
---
### Author:  [@AJ\_Quick](https://meta.discourse.org/u/AJ_Quick)
#### Post date: [1. September 2026 um 05:19 UTC](https://meta.discourse.org/t/discourse-indexnow-instantly-notify-bing-yandex-when-topics-are-created-or-edited/410722/2 "2026-09-01T05:19:17Z")
Danke dafür! Ich wollte gerade gerade sagen, muss ich mir nicht selbst ein Indexnow-Plugin bauen? Und schwupps! Gefunden!
Kannst du mir sagen, ob `indexnow_submit_on_edit` bei allen Rebakes, die den Inhalt ändern, eine Indexnow-Übermittlung auslöst?
---
### Author:  [@soul](https://meta.discourse.org/u/soul)
#### Post date: [7. September 2026 um 03:11 UTC](https://meta.discourse.org/t/discourse-indexnow-instantly-notify-bing-yandex-when-topics-are-created-or-edited/410722/3 "2026-09-07T03:11:27Z")
**Nein** — es wird nur bei echten Bearbeitungen über den normalen PostRevisor-Flow ausgelöst und nur für den ersten Beitrag (OP) eines Themas. Antworten anderer Nutzer und systemausgelöste Neuberechnungen (z. B. Cron-Jobs zur Bildkorrektur, Massen-Neuberechnung durch Admins usw.) lösen keine erneute Einreichung aus, da diese nicht über das Ereignis laufen, an das sich dieses Plugin andockt.
---
### Author:  [@AJ\_Quick](https://meta.discourse.org/u/AJ_Quick)
#### Post date: [7. September 2026 um 17:18 UTC](https://meta.discourse.org/t/discourse-indexnow-instantly-notify-bing-yandex-when-topics-are-created-or-edited/410722/4 "2026-09-07T17:18:52Z")
Ich verwone das Plugin seit einer Woche und bin damit sehr zufrieden. Es funktioniert genau so, wie ich es brauche, allerdings bin ich auf einige Bugs gestoßen, die dazu führten, dass das Plugin unmittelbar nach der Installation fehlschlug.
Konkret habe ich Routenkonflikte mit anderen Plugins festgestellt, die dieselben Endpunkte nutzen. Außerdem gab es ein Problem mit dem Rate-Limiting: Einreichungen konnten das Limit erreichen, nach einigen Minuten erneut versuchen und es dann wieder ausschöpfen. Zudem wurde das Stylesheet des Admin-Bereichs in öffentliche Bereiche injiziert, und die CSS-Klassen waren nicht korrekt mit dem Plugin-Präfix versehen.
Außerdem habe ich eine Funktion hinzugefügt, die ich mir sehr gewünscht hatte: die Möglichkeit, eine Einreichung vorzunehmen, wenn auf ein Thema geantwortet wurde. Diese Einreichung ist auf eine bestimmte Seitennummer bezogen, damit nicht das gesamte Thema verarbeitet werden muss. Bei Themen mit hunderten von Antworten wird nur die letzte Seite eingereicht, was dem Crawler hilft, die Antwort schneller zu finden und das Thema entsprechend zu aktualisieren.
>
>
> 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/\/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 \`/\.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.
---
### Author:  [@soul](https://meta.discourse.org/u/soul)
#### Post date: [9. September 2026 um 07:38 UTC](https://meta.discourse.org/t/discourse-indexnow-instantly-notify-bing-yandex-when-topics-are-created-or-edited/410722/5 "2026-09-09T07:38:11Z")
Merged.
Danke, dass du dir die Zeit genommen hast, dich so tief in den Code einzuarbeiten. Die Bucketing-Logik für das Sliding Window und das Batching der Hintergrundjobs sind solide Verbesserungen. Auch der Reply-Trigger ist ein nettes Detail.
Ich habe die Doku des Hauptposts aktualisiert, um die neuen Quota-Balken und Cooldown-Einstellungen abzudecken, die du hinzugefügt hast.
Ich schätze die hochwertige PR und die detaillierte Beschreibung sehr. :content: