SEO-Probleme mit RSS-Duplikat-Inhalten

Wir verwenden das RSS-Plugin (oder manuelle Kopien), um unsere Blogbeiträge als Diskussionsanker in einer Kategorie zu erstellen. Google mag solche „kopierten“ Inhalte nicht und droht, die SEO-Reputation des Blogs zu beschädigen.

Natürlich können wir die Google-Indexierung des Diskurses (oder der Kategorie) stoppen, aber hat jemand Erfahrung damit, irgendwie zu definieren, dass dies beabsichtigt ist. So etwas wie „dieses Subdomain gehört zum Blog, wir versuchen keine Linkfarmen zu erstellen“ oder so etwas? Wenn ja, wie implementiert man das in den Discourse-Einstellungen?

Ich glaube, ich erinnere mich grob daran, dass mit rel=nofollow oder Ähnlichem zumindest der Aspekt des Backlink-Farmings angesprochen werden sollte (bezüglich des Aspekts der doppelten Inhalte bin ich mir nicht sicher). Gibt es vielleicht einen Header „dies ist eine Kopie von“, der Google besänftigt?

2 „Gefällt mir“

Die Website-Einstellung embed set canonical url könnte bei dem Problem helfen:

Es lohnt sich jedoch, die Dokumentation von Google zu lesen:

Der Grund, warum ich auf die Dokumentation verlinkt habe, ist, dass ich mir nicht sicher bin, ob die Einstellung embed set canonical url aktiviert werden kann, wenn die Einstellung embed truncate aktiviert ist. Wenn embed truncate aktiviert ist, ist nur ein Ausschnitt des Originalartikels für Google auf Discourse verfügbar. Der vollständige Artikel wird in einem iFrame angezeigt, wenn Benutzer auf die Schaltfläche „Vollständigen Beitrag anzeigen“ klicken. Ich bin ziemlich sicher, dass der iFrame-Inhalt nicht von Google gecrawlt wird. Der erste Punkt im Artikel „5 häufige Fehler“ befasst sich irgendwie mit diesem Problem.

2 „Gefällt mir“

Danke für den Hinweis, Simon! Tatsächlich scheint das kanonische Tag das zu sein, was ich im Sinn hatte. Ich habe es versucht, aber es funktioniert nicht vollständig, es bettet eine kanonische URL ein, die auf sich selbst verweist, nicht auf die RSS-Quelle:

<link rel="canonical" href="https://community.domain.com/t/invoicing-mandate/537?page=0" />

anstatt

<link rel="canonical" href="https://blog.domain.com/t/invoicing-mandate/537" />

(Dies ist stable/3.2.0)

Außerdem, kann/sollte dies auch als hervorgehobener Link gesetzt werden?

In unserem Fall verwenden wir kein Truncate (obwohl der RSS-Feed bereits gekürzt ist). Aber ich hoffe, Google wird es trotzdem akzeptieren.

1 „Gefällt mir“

Versuchen Sie, die Seitenquelle anzuzeigen, anstatt sie mit dem Web-Inspektor Ihres Browsers anzuzeigen. Ich glaube, Sie werden sehen, dass die kanonische URL auf die URL des RSS-Posts gesetzt ist, wenn Sie die Seitenquelle anzeigen, und auf die URL des Discourse-Themas, wenn Sie das HTML mit dem Web-Inspektor anzeigen. Wenn das stimmt, sollten Sie keine Warnungen vor doppeltem Inhalt für die RSS-Themen erhalten.

Hier ist, was ich sehe (mit aktiviertem embed set canonical url), wenn ich ein aus dem RSS-Feed von Discourse abgerufenes Thema in meinem Web-Inspektor anzeige:

Und hier ist die kanonische URL, wenn ich die Seitenquelle anzeige (indem ich mit der rechten Maustaste auf die Seite klicke und “Seitenquelltext anzeigen” aus dem Menü auswähle):

<link rel="canonical" href="https://blog.discourse.org/2023/03/how-discourse-scaled-to-10m-arr-with-only-1-salesperson" />

Die Ansicht der Seitenquelle mit der korrekt gesetzten kanonischen URL ist das, was ein Crawler sehen wird.

Eine andere Möglichkeit, den Unterschied zu sehen, ist die Verwendung des Web-Inspektors, aber die Auswahl von Googlebot als User-Agent:

Ich glaube, die Einstellung funktioniert in Bezug auf das, was Crawler sehen, wie erwartet, aber sie hat mich verwirrt. Das Problem scheint zu sein, dass Discourse das kanonische URL-Attribut mit JavaScript überschreibt, wenn die Seite mit aktiviertem JavaScript angezeigt wird. Als Referenz geschieht dies hier:

https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/instance-initializers/meta-tag-updater.js#L25-L27

Ich glaube nicht, dass es (derzeit) möglich ist, den hervorgehobenen Link für aus RSS-Feeds erstellte Themen zu setzen. Ich bin kein SEO-Experte, aber ich glaube nicht, dass das Setzen oder Nicht-Setzen davon Auswirkungen auf SEO hätte.

2 „Gefällt mir“

Ich habe curl -i | grep canon verwendet und eine falsche Tag-URL (und keine Header) gesehen, aber ich kann es mit einer anderen UA erneut versuchen (was allerdings etwas seltsam ist) – ich musste die Beiträge mehrmals neu erstellen, vielleicht war ich verwirrt. Ich werde hier aktualisieren.

Stimmt, der hervorgehobene Link ist nicht für SEO, aber ich hatte intern den Wunsch, den Blog-Link sichtbarer zu machen. Und da es sich um dieselbe URL handelt…

(Aber es sieht so aus, als ob ich eine längere Liste von Anforderungen erhalte, daher muss ich möglicherweise den rss-poll forken (unglücklicherweise sieht es so aus, als ob die meiste Arbeit nicht im Plug-in erledigt wird). Ist der Embed-Code auch erweiterbar?

Für ein Thema, das aus einem RSS-Feed erstellt wurde, mit aktiviertem embed set canonical url, würde ich erwarten, dass curl -i die URL des RSS-Elements als kanonische URL zurückgibt. Das funktioniert, wenn ich es auf meiner lokalen Website teste.

Angenommen, Sie haben Zugriff auf die Discourse Rails-Konsole, können Sie bestätigen, was vor sich geht, indem Sie das Thema finden und dann dessen topic_embed-Eigenschaft überprüfen. Zum Beispiel:

t = Topic.find 495
t.topic_embed

oder einfach:

TopicEmbed.find_by(topic_id: 495)

Es sollte ein TopicEmbed zurückgegeben werden. Seine embed_url ist das, was Discourse verwenden soll, um die kanonische URL des Themas festzulegen.

Das habe ich mich auch schon gefragt. Es wäre schwieriger als Änderungen am RSS-Plugin, da das Einbetten Teil des Kerncodes von Discourse ist.