Ältere über WordPress-Embed veröffentlichte Themen fehlen x-robots: noindex und Canonical-Tags

Hallo zusammen,

mir ist ein seltsames Verhalten bei alten Themen aufgefallen, die automatisch von WordPress nach Discourse veröffentlicht wurden (um als Kommentarbereich zu dienen).

Normalerweise fügt Discourse, wenn ein Beitrag auf diese Weise veröffentlicht wird, korrekt den X-Robots-Tag: noindex zum HTTP-Header hinzu und setzt die canonical-URL, die auf den WordPress-Blogbeitrag verweist.

Ich habe jedoch festgestellt, dass ältere Themen diese Tags verlieren. Der noindex-Header verschwindet, und das canonical-Tag ist nicht mehr vorhanden. Hier sind einige Beispiele für Themen, bei denen dies auftritt:

Weiß jemand einen Weg, dieses Problem zu beheben?

Beachten Sie bitte, dass ich nicht genau weiß, wie viele Themen bisher betroffen sind, aber es scheint eine beträchtliche Anzahl zu sein.

Es wäre großartig, wenn es in den Einstellungen der Kategorie (oder des Tags?) ein Kontrollkästchen gäbe, das bei Aktivierung automatisch noindex zu allen Themen hinzufügt, die unter dieser Kategorie veröffentlicht werden. Etwas wie:

[ ] Themen aus dieser Kategorie in den Suchergebnissen ausblenden.

Hey Thiago,

Nur um sicherzugehen, fasse ich das wie folgt zusammen:

  1. Du hast die Site-Einstellung „Canonical-URL einbetten

Hallo Angus!

Ja, das ist es.

Die Option Embed: Canonical-URL festlegen ist ebenfalls aktiviert:

Du kannst hier sehen, dass neue Themen mit den Tags noindex und canonical veröffentlicht werden. Allerdings sehe ich bei älteren Themen diese Tags nicht.

Thiago, wenn du Zugriff auf den Server hast, könntest du bitte die ID eines Themas ermitteln, bei dem die kanonische URL nicht funktioniert, den folgenden Befehl in der Rails-Konsole ausführen und das Ergebnis teilen.

./launcher enter app
rails c
TopicEmbed.with_deleted.find_by(topic_id: hier die Topic-ID einfügen)
discourse(prod)> TopicEmbed.with_deleted.find_by(topic_id:73608)
=> nil
discourse(prod)> TopicEmbed.with_deleted.find_by(topic_id:79015)
=> nil
discourse(prod)> TopicEmbed.with_deleted.find_by(topic_id:74248)
=> nil
discourse(prod)> TopicEmbed.with_deleted.find_by(topic_id:76598)
=> nil

Das ist das Problem. Damit die Funktion für die kanonische URL bei Einbettungen funktioniert, muss das Thema über einen topic_embed-Datensatz verfügen. Können Sie sich einen Grund vorstellen, warum diese Themen möglicherweise keine Einbettungsdatensätze haben?

Ich weiß ehrlich gesagt nicht, was dazu geführt haben könnte, dass diese Themen ihre topic_embed-Datensätze verpasst haben.

Aber wenn man die Gesamtsituation betrachtet, wäre es nicht sinnvoller, die Konfiguration zu wählen, die ich früher vorgeschlagen habe? Wenn wir in den Kategorieneinstellungen direkt ein Kontrollkästchen hinzufügen, um noindex auf alle Themen innerhalb dieser Kategorie anzuwenden, müssten wir uns nicht auf die Embed-Funktion verlassen oder darüber Gedanken machen, ob diese Datensätze überhaupt existieren.

Das mag für deine Website sinnvoll sein, wäre aber eine andere Funktion als die Art und Weise, wie kanonische URLs für Themen-Einbettungen funktionieren. Du könntest sie zwar implementieren, müsstest sie dann aber als benutzerdefiniertes Plugin erstellen.

Kanonische URLs für Einbettungen funktionieren wie erwartet, jedoch scheint es, als wären die Einbettungsdatensätze zu einem bestimmten Zeitpunkt gelöscht worden oder es wurde eine andere Operation auf deiner Website durchgeführt. Discourse löscht Einbettungsdatensätze für Themen nicht hart, also muss etwas anderes passiert sein. Sofern du keine benutzerdefinierten Anpassungen vornimmst, musst du diese Themen erneut veröffentlichen, um die Einbettungsdatensätze wieder zu erstellen.

Während sich dies anders verhält als Topic-Einbettungen, ist die Indexierungskontrolle auf Kategorieebene eine grundlegende SEO-Anforderung für jedes moderne CMS. Es gibt mehrere andere Meta-Themen dazu, und eine native Umsetzung würde mehrere Anwendungsfälle gleichzeitig lösen.

Ich könnte versuchen, ein Plugin mit KI zu entwickeln, da Ruby nicht mein Stack ist, aber dies sollte wirklich eine native Funktion sein.

Bezüglich der fehlenden Datensätze: Wir haben keine Datenbankbefehle oder -operationen ausgeführt, die dies verursachen könnten. Auch eine Neuveröffentlichung ist nicht machbar. Wir haben fast 50.000 Beiträge, und wir wissen nicht einmal, welche davon betroffen sind. Die Behebung dieses Problems würde komplexe API-Skripte erfordern, um alles zu finden, zu löschen und neu zu veröffentlichen…