URL Hygiene

[mogli]

Wieso sollte das Verhältnis interessant sein?

Es gibt Webprojekte, wo zahlreiche Varianten mit minimalen Veränderungen des Contents (beispielsweise Sortierung einer Tabelle) in x-facher Ausführung notwendig sind.

Solange man darauf achtet, dass trotzdem nur eine Seite mit diesem Inhalt in den Index kommt, gibt es in Googles Augen auch kein Problem.

Ob der Inhalt dieser Seite an sich nun panda-sicher ist, hängt ja vom jeweiligen Content ab. Das stand aber in deinem Beitrag nicht zur Debatte, da es generell nur um eine unendliche Zahl an URL-Möglichkeiten ging (wo jeder erstmal davon ausgehen muss, dass der Inhalt trotzdem gut ist, nur eben doppelt und dreifach verfügbar) und nicht um schwache Inhalte.

Am Ende wird der Index immer mit der gleichen Zahl an Seiten gefüttert, egal ob nun 5 oder 10000 Duplikate ausgezeichnet werden.

hrrr ja aber unter anderen voraussetzungen.

bei der empfehlung geht es um die onpage optimierung von toten seiten.
also genau das gegenteil um was es hier geht^^

Nein, es geht bei Googles Empfehlung explizit um das Problem des Autoren: gleicher Content, der unter diversen URLs abgerufen werden kann. Zitat: "In CMS und Online-Shopping-Systemen sind dieselben Inhalte gewöhnlich über mehrere URLs abrufbar. [...] Zur Lösung dieser Probleme empfehlen wir Ihnen, für identische oder ähnliche Inhalte, die über verschiedene URLs abrufbar sind, eine kanonische URL festzulegen."

Googles Empfehlung trifft hier also EXAKT zu.

[Melegrian]

Bis dahin natürlich sinnvoll: Pragmatische Lösung übers Canonical Tag.

Damit bekommst Du aber d12 nicht weg und wenn Du bei d123345 bist, dann kommst Du nie und nimmer mehr dazu.

[Lyk]

Ich lass mich gern mit guten Argumenten davon abbringen! ... und was in dem Supportlink von Google fehlt: Das Verhältnis. Grundsätzlich is das canonical Tag klar sinnvoll. Aber was eben, wenn DC domainweit systematisch erzeugt wird

so siehts aus.

[Lyk]

Bis dahin natürlich sinnvoll: Pragmatische Lösung übers Canonical Tag.

Damit bekommst Du aber d12 nicht weg und wenn Du bei d123345 bist, dann kommst Du nie und nimmer mehr dazu.

schau mal hier:
https://youtu.be/NW3vxnlu3QQ?t=9m47s

[Adversus]

Wieso sollte das Verhältnis interessant sein?
Ob der Inhalt dieser Seite an sich nun panda-sicher ist, hängt ja vom jeweiligen Content ab. Das stand aber in deinem Beitrag nicht zur Debatte, da es generell nur um eine unendliche Zahl an URL-Möglichkeiten ging (wo jeder erstmal davon ausgehen muss, dass der Inhalt trotzdem gut ist, nur eben doppelt und dreifach verfügbar) und nicht um schwache Inhalte.

Grüß Dich


Hintergrund meiner Aussage war ein Artikel von Jonas Weber aus der WebsiteBoosting. Warum? Wenn ich mich richtig erinnere wurde hier gesagt, dass die Verhältnismäßigkeit von originärem Content zu thin Content und nicht erreichbarem Content wichtiger Faktor für den Panda ist.

Thin Content ist auch domainweit ein Thema und Sistrix schreibt zB, dass ein von Panda bedachte Qualitätsfaktor "ein hoher Prozentsatz an doppelten Inhalten (duplicate content)" ist. (Siehe https://www.sistrix.de/frag-sistrix/goo ... da-update/.

An anderer Stelle auch: "Google warnt in seinen Richtlinien für Webmaster (Google Webmaster Guidelines) davor, dass die mutwillige Erstellung von Duplicate Content durch verschiedene Algorithmen und Filter, wie z.B. dem Google Panda Update, geahndet werden kann."

Und weiter: "Matt Cutts, Head of Googles Webspam-Team, stellt erneut klar, dass Duplicate Content von Google nicht als Spam betrachtet wird, der bestraft würde. Wer allerdings exzessiv Content einsammelt (z. B. automatisiert) und damit keinen echten Mehrwert schafft, der könnte allerdings schon Probleme haben."

Daher meine obige -theoretische - Einschätzung.
Hoffe es ist damit besser verständlich

[Melegrian]

Wenn es Dir unheimlich ist, dann setze doch alles auf noindex, was Deinem gewünschten Muster nicht entspricht. Im Augenblick sieht es zumindest so aus, als hättest Du gar keinen Plan.

Oder besser, speichere die Titel mit strtolower, fülle die Leerzeichen mit - auf und sorge dafür, dass die Seiten nur noch darüber aufgerufen werden, in dem Du bei Aufruf abfragst, ob seite= in DB vorhanden ist.

https://www.abakus-internet-marketing.d ... 30380.html

Oder einfacher, wenn noch nicht mehr als ein paar Seiten vorhanden sind, warum wechselst Du nicht auf ein System, welches diese Probleme nicht bereitet?

[Adversus]

Hallo Melegrian


Ich weiß nicht, ob wir uns irgendwie missverstehen, aber wie kommst Du jetzt drauf, dass ich gar keinen Plan habe?

Wir haben hier bisher über zwei Sachverhalte gesprochen:
1) Wie man technisch am besten vorgehen sollte, wenn systematisch DC produziert wird
2) Ob systematischer DC nach Einsatz eines rel canonicals weiterhin problematisch ist (Panda)

Mein Plan ist der, den ich vorher schon geäußert habe:
1) Erstmal an wichtigen Stellen canonicals setzen
2) Mittelfristig dafür sorgen, dass ich in Richtung des Vorschlags von sawascwoolf gehe und nicht nur das Symptom bekämpfe, sondern den Ursprung
... dass ich mit den Canonicals anfangen will liegt dabei einzig daran, dass der zweite Weg einfach länger dauert und daher ist der canonical nur ein Lückenfüller. Ansonsten könnte man natürlich - klar - auch direkt in Richtung sawascwoolf gehen.

[Melegrian]

Wir haben hier bisher über zwei Sachverhalte gesprochen:
1) Wie man technisch am besten vorgehen sollte, wenn systematisch DC produziert wird
2) Ob systematischer DC nach Einsatz eines rel canonicals weiterhin problematisch ist (Panda)

Weder Du noch Dein Script erzeugt systematisch DC, denn Du legst ja keine Seiten gezielt mit DC an oder verlinkst diese intern so, dass DC entstehen würde. Das können nur andere von außen und da kann man einen Riegel vorschieben. Alles andere ist nicht mehr als ein Notbehelf.

Aber wenn ich das mache, wird die Frage kommen:"Ja wie soll Google denn an die URL heuteistschöneswetter und kuchenessen kommen, wenn wir doch nur d12 benutzen?

Und wenn Du, wie Du eingangs erwähntest, keine d12 haben möchtest, sondern kuchenessen, dann ist es doch Unfug und kein Plan, mit einem Notbehelf zu beginnen, um mit der Umsetzung zu warten, bis aus d12 vielleicht d1221 geworden ist.

Canonical würde dann genügen, wenn zum Beispiel neben einer normalen Seitenansicht noch eine Druckversion existiert oder wenn ab und an mal fehlerhaft verlinkt wird oder eine Einstellung vorgenommen wurde, ähnliche URLs auszuliefern. Nicht aber wenn sich eine ID als URL unabhängig von der Anzahl der in der URL abgebildeten Ebenen und deren Bezeichnungen aufrufen lässt. Das ist kein Plan, das ist Pfusch und möglicherweise sogar noch ein Angriffspunkt für Hacker.

[mogli]

die Verhältnismäßigkeit von originärem Content zu thin Content und nicht erreichbarem Content wichtiger Faktor für den Panda ist

Sicherlich, aber das betrifft dich doch gar nicht, denn:

1.) Reden wir ja nicht über Thin Content Seiten, die nur wenig Mehrwert bieten (dein DC ist ja kein Thin Content, sondern eben einfach nur DC).
2.) Reden wir ja nicht über nicht erreichbaren Content (sprich viele 404-Fehler) und falsche interne Links etc.
3.) Wollen wir nur originären Content in den Index lassen, daher wird DC mit kanonischen URLs ausgestattet.

"Thin Content ist auch domainweit ein Thema und Sistrix schreibt zB, dass ein von Panda bedachte Qualitätsfaktor "ein hoher Prozentsatz an doppelten Inhalten (duplicate content)" ist."

Deswegen lässt man Thin Content gar nicht erst in den Index. Aber wie gesagt, um Thin Content geht es ja bei dir nicht. Du hast nur Duplikate.

"Wer allerdings exzessiv Content einsammelt (z. B. automatisiert) und damit keinen echten Mehrwert schafft, der könnte allerdings schon Probleme haben."

Klar kann er das, WENN er den Kram in den Index stellt. Das wollen wir ja gar nicht machen. Weder mit deinen DC-Seiten noch mit Thin Content Zeug, welches du ja gar nicht hast. Also thematisch nicht relevant.

Deine Lage ist wirklich etwas völlig anderes als eine Seite, die beispielsweise automatisiert zu hunderten Keywords diverse Texte aggregiert und so zig Unterseiten mit äußerst dünnen Inhalten entstehen lässt, mit denen er auch noch ranken möchte.

Am Ende läuft es immer auf die gleiche Schiene hinaus: stelle der Suchmaschine vernünftige Seiten zur Indexierung aus und halte den Rest draußen. Da gibt es keinen geheimen Schwellenwert, der canonicals, noindex oder via robots.txt gesperrte Seiten mitzählt und irgendwann überschritten sein kann. Aus gutem Grund, denn das wäre für zahlreiche Projekte schlicht fatal und widerspricht genau dem Grundgedanken Webmastern die Möglichkeit zu geben entsprechend ihre "unwichtigen" Seiten zu kennzeichnen.

[Melegrian]

@ Adversus, ich sehe eine mögliche Gefahr, weil täglich irgendwelche Bots kommen, die nur versuchen das System auszukundschaften, dazu URLs in allen möglichen und unmöglichen Ausführungen versuchen aufrufen wie. Bei mir landen die dann auf einer Fehlerseite und bei Dir?

[Adversus]

Hi Melegrian


Danke für den Hinweis. Hast Du meine PM bekommen?
Sonst würde ich Dich da lieber ausfragen als hier, damit der Beitrag nicht verwirrender wird

[Melegrian]

Hast Du meine PM bekommen?

Ja, habe ich, doch eigentlich betrachte ich das mehr als eine öffentliche Diskussion.

[Adversus]

Alles klar, dann machen wir das auch so


Weder Du noch Dein Script erzeugt systematisch DC, denn Du legst ja keine Seiten gezielt mit DC an oder verlinkst diese intern so, dass DC entstehen würde. Das können nur andere von außen und da kann man einen Riegel vorschieben. Alles andere ist nicht mehr als ein Notbehelf
--> Wie kann man denn hier einen Riegel vorschieben? Hast Du da einen guten Tipp für mich?


Und wenn Du, wie Du eingangs erwähntest, keine d12 haben möchtest, sondern kuchenessen, dann ist es doch Unfug und kein Plan, mit einem Notbehelf zu beginnen, um mit der Umsetzung zu warten, bis aus d12 vielleicht d1221 geworden ist.
--> Das Problem ist einfach, dass zeitnah durch das CMS erstmal nur Canonicals möglich sind und alles andere länger dauert und bedeuten würde, dass das CMS aufgebohrt werden muss. Oder, wie Du selbst schreibst, man das System wechseln muss.

@ Adversus, ich sehe eine mögliche Gefahr, weil täglich irgendwelche Bots kommen, die nur versuchen das System auszukundschaften, dazu URLs in allen möglichen und unmöglichen Ausführungen versuchen aufrufen wie. Bei mir landen die dann auf einer Fehlerseite und bei Dir?
--> Nein hier wird nichts spezifisch ausgeliefert. Ich muss auch gestehen, dass mir diese Problematik bisher nicht bewusst war. Wo kann ich mich einlesen oder kannst Du kurz aufklären?

[Melegrian]

--> Nein hier wird nichts spezifisch ausgeliefert. Ich muss auch gestehen, dass mir diese Problematik bisher nicht bewusst war. Wo kann ich mich einlesen oder kannst Du kurz aufklären?

Na ja, zum Beispiel ist hier ein Bot durchgelaufen, um nach einem Editor zu suchen. Hat er etwas Pech gehabt, meiner nennt sich bei der Seite anders und nicht ein Verzeichnis von diesen ist bei mir davon vorhanden.

Code: Alles auswählen

/dekra/FCKeditor/editor/fckeditor.html
/c4sql8-solidarieta/html/images_sys/fckeditor.o/editor/fckeditor.html
/adminicpsb/script/fckeditor/editor/fckeditor.html
/gbe/modules/content/admin/fckeditor/editor/fckeditor.html
/blog/FCKeditor/editor/fckeditor.html
/webmanager/FCKeditor/editor/fckeditor.html
/controls/fckeditor/editor/fckeditor.html
/crm/include/fckeditor/editor/fckeditor.html
/sites/efeefe.no-ip.org/modules_bak/fckeditor/fckeditor/editor/fckeditor.html
/kmustkjc/plugins/editors/fckeditor/editor/fckeditor.html
/newsite/FCKeditor/editor/fckeditor.html
/sites/all/modules/fckeditor/fckeditor/editor/fckeditor.html
/system/lib/ext/fckeditor/editor/fckeditor.html
/portfolio/aui/FCKeditor/editor/fckeditor.html
/site/lib/FCKeditor/editor/fckeditor.html
/joshiken/html/mambots/editors/fckeditor/editor/fckeditor.html
/ documents/CMGA6/registration/public/fckeditor/editor/fckeditor.html
/javascript/editors/fckeditor/editor/fckeditor.html
/html/editor/wp-content/plugins/fckeditor_for_wordpress/fckeditor/editor/fckeditor.html
/cf/scripts/ajax/FCKeditor/editor/fckeditor.html
/UI/Tools/FCKeditor/editor/fckeditor.html
/adm_gerencia/fckeditor/editor/fckeditor.html
/stara/include/FCKeditor/editor/fckeditor.html
/ pi/opiti/pppblog/FCKeditor/editor/fckeditor.html
/user_data/packages/miyabunnew/fckeditor/editor/fckeditor.html
/common/fckeditor/editor/fckeditor.html
/libs/fckeditor/editor/fckeditor.html
/webmail/plugins/html_mail/fckeditor/editor/fckeditor.html
/jeunes/fckeditor/editor/fckeditor.html
/wysiwyg/fckeditor/editor/fckeditor.html
/drupal/sites/all/modules/fckeditor/fckeditor/editor/fckeditor.html
/admin/libexterne/fckeditor/editor/fckeditor.html
/inc/fckeditor/editor/fckeditor.html
/cms/_includes/fckeditor/editor/fckeditor.html
/frame/lib/fckeditor/editor/fckeditor.html
/mt/mt-static/plugins/FCKeditor/fckeditor/editor/fckeditor.html
/GestaoProService/includes/fckeditor/editor/fckeditor.html
/blog/wp-content/plugins/fckeditor-for-wordpress-plugin/fckeditor/editor/fckeditor.html
/ccmail/fckeditor/editor/fckeditor.html
/web-files/fckeditor/editor/fckeditor.html
/pliki/adm/fckeditor/editor/fckeditor.html
/js/3rdparty/fckeditor/editor/fckeditor.html
/glossary/fckeditor/editor/fckeditor.html
/module/00023/59/FCKeditor/editor/fckeditor.html
/codemis_cms/js/fckeditor/editor/fckeditor.html
/shop/assets/js/fckeditor/editor/fckeditor.html
/customcontent/USDA_ECM_OVERVIEW/cvx06_sco01/FCKeditor/editor/fckeditor.html
/plugins/fckeditor-spip-2/fckeditor/editor/fckeditor.html
/sites/all/libraries/fckeditor/editor/fckeditor.html
/system/ext/fckeditor/editor/fckeditor.html
/portlets/sisRapid/dream/libs/V2.56/vcl/FCKeditor/editor/fckeditor.html
/themes/mantaTheme1/newsmail/templates/javaScript/fckeditor/editor/fckeditor.html
/modules/editor/fckeditor/editor/fckeditor.html
/utilities/external/fckeditor/editor/fckeditor.html
/distancelearning/sites/all/modules/fckeditor/fckeditor/editor/fckeditor.htm
/cms/app/webroot/js/fckeditor/editor/fckeditor.html
/script/fckeditor/editor/fckeditor.html
/componentes3.7/fckeditor/editor/fckeditor.html
/common/third_party/FCKeditor/editor/fckeditor.html
/wp-content/plugins/fckeditor_for_wordpress/fckeditor/editor/fckeditor.html
/ cwcheng/C_Lan/fckeditor/editor/fckeditor.html
/Providers/HtmlEditorProviders/Fck/fckeditor/editor/fckeditor.html
/affiliate/affiliate53/fckeditor/editor/fckeditor.html
/bip/KW/fckeditor/editor/fckeditor.html
/files/static/fckeditor/editor/fckeditor.html
/app/resources/javascript/FCKeditor/2.3.1/editor/fckeditor.html
/forms/admin/scripts/fckeditor.2641/editor/fckeditor.html
/template/js_lib/fckeditor/editor/fckeditor.html
/intranet/fckeditor/editor/fckeditor.html
/bscw_resources/javascript/FCKeditor/editor/fckeditor.html
/addon/FCKeditor/editor/fckeditor.html
/dadamail/dada/extras/packages/fckeditor/editor/fckeditor.html
/includes/phpEasyAdmin/form/textarea/editor/fckeditor.html
/webyep-system/program/opt/fckeditor/editor/fckeditor.html

Und das machen die Bots halt so, mal wird nach einem Zugang für den Admin-Bereich gesucht, mal nach etwas anderem, nur bei Deiner Seite wäre ich mir nicht so sicher, dass die dann doch einmal etwas finden könnten, was mit einer Lücke verbunden sein könnte.

[top]

Ich will auch nicht wissen wie Google darauf reagiert, wenn ein fieser Mitbewerber irgendwo einige Links zu "deineseite.tld/blaue-wunderpillen/d3" oder "deineseite.tld/f***ing/teens/d7" setzt, und dort ganz normaler Inhalt und keine 404-Seite kommt.