Welche Auswirkungen haben Probleme mit doppelten Inhalten bei Drupal-Kommentaren?

Angenommen, wir haben einen Knoten namens node / 123 mit aktivierten Kommentaren. Wenn Kommentare abgegeben werden, werden zusätzliche URLs generiert / comment / 1, / comment / 2 ... und / comment / reply / 2/1 usw. Leider sind diese neuen URLs eine Seite, die eine vollständige Kopie des Inhalts in der enthält Originalseite / Knoten / 123 oder der Kommentar als Antwort. Die robots.txt von Core hat nurDisallow: /comment/reply/

Würde das Hinzufügen der folgenden Dateien zur robots.txt-Datei Auswirkungen haben? Wäre dies zu empfehlen (oder würde sogar ein Kernproblem veröffentlicht, das auf dieses Problem hinweist?)

# Paths (clean URLs)
Disallow: /comment/
Disallow: /comment*/
Disallow: /comment/reply/
Disallow: /comment/reply*/
...
# Paths (no clean URLs)
Disallow: /?q=comment/
Disallow: /?q=comment*/
Disallow: /?q=comment/reply/
Disallow: /?q=comment/reply*/

Ich bin der Autor des Sandbox-Moduls ( Permalink to Nodepath ), das im ersten Kommentar zur Frage erwähnt wurde. Marios Antwort ist in Bezug auf kanonische URLs gut beschrieben - aber leider nicht die einzige Implikation .

Diese Kommentar- / * -URLs stammen von Drupal 7. In Drupal 6 hatten Kommentare keine eigenen URLs. Kanonische URLs können das Problem mit doppelten Inhalten lösen, was für die meisten IMO-Websites vollkommen in Ordnung ist. Spam-Kommentare können Ihrer Site-Fehlerliste jedoch nach Belieben 404- und 403-Fehler hinzufügen. Dies war meine persönliche Erfahrung, dass mein Spam-Suchdienst einige der Kommentare nicht löschen konnte, sodass ich sie manuell löschen musste. Aber Google hatte sie bereits indiziert.

Das eigentliche Problem ist, dass anonyme Benutzer jede Art von Kommentaren veröffentlichen können. Wenn sie gelöscht oder unveröffentlicht wurden, protokolliert Google (und andere Suchmaschinen) sie als Crawling-Fehler, was ziemlich ärgerlich ist und wahrscheinlich auch Ihren Seitenrang beeinflusst.

Andererseits respektieren die meisten Link-Sharing-Sites, einschließlich Facebook, die kanonische URL nicht. Zum Beispiel http://example.com/node/1können 56 (Facebook) Likes vorhanden sein, aber sie werden nicht synchronisiert, wenn der Benutzer dies mag http://example.com/comment/5(angenommen, Kommentar 5 ist ein Kommentar zu Knoten 1). Aus Facebook-Sicht sind es 2 verschiedene URLs (tatsächlich sind sie es), so wie die Anzahl unterschiedlich ist.

Module wie Boost basieren auch auf der tatsächlichen Anforderungs-URI-Einstellung von $ _SERVER, die noch vorhanden ist comment/5(obwohl die kanonische URL lautet node/5). Sie können jedoch die Konfiguration des Boost-Moduls ändern, um dies zu beheben.

Es ist sehr beliebt arg(1) , die Knoten-ID in benutzerdefinierten Blöcken, Modulen, Ansichten usw. abzurufen. Sie funktionieren , da diese Funktion in der Rückruffunktion von Kommentar- /% -URLs $_GET['q']auf die kanonische URL festgelegt wird. Diese $ _GET-Änderung löst die meisten Probleme in programmierbaren Dingen.

Nach der Untersuchung glaube ich nicht, dass es hier ein SEO-Problem gibt. Es ist sicher ein Ärger, aber es ist kein Problem und hier ist der Grund:

Gemäß den Empfehlungen von Google hier http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html für kanonische URLs und doppelte Inhalte haben Sie keine Probleme, wenn Sie nur dann doppelte Inhalte haben, wenn Sie Ihre ordnungsgemäß angeben kanonische URLs. Außerdem zeigt Google (und höchstwahrscheinlich alle anderen Suchmaschinen) nur die kanonische URL in den Suchergebnissen an und nicht die anderen URLs.

In Drupals Fall sind die kanonischen URLs richtig eingestellt. Zum Beispiel habe ich einen Testartikel (Knoten / 2) erstellt und Kommentare und Antworten hinzugefügt und die folgenden Seiten erhalten:

• / node / 2
• / comment / 2
• / comment / 3

Nach der Überprüfung des generierten Quellcodes haben alle den gleichen <link rel="canonical" href="https://drupal.stackexchange.com/node/2" />Quellcode ordnungsgemäß erstellt. Grundsätzlich wird in den Suchergebnissen nur die Hauptartikelseite angezeigt.

Ob ich nun den Core so ändern soll, dass nur eine einzelne Seite generiert wird oder die robots.txt-Datei wie angegeben gepatcht wird, ist mir ein Rätsel. Ich bin mir sicher, dass vor der Implementierung eines der oben genannten Punkte viele Überlegungen und Sonderfälle zu berücksichtigen sind. Da es wirklich kein Problem gibt, ist es vielleicht am besten, die Dinge so zu belassen, wie sie sind.

Prost!

Hinweis: Ich verwende Drupal 7.17 (neueste Version ab heute).