Hallo zusammen.
Zunächst mal hat Duplicate Content nicht die Bedeutung wie oft angenommen: Es gibt keinen pauschalen Strafbonus wenn man Inhalt wiederverwendet oder unter unterschiedlichen URLs anbietet. In dieser Beziehung gibt es genau zwei Situationen die sich negativ auswirken können: 1.: Bei bewusster Manipulation des Index wird Google Maßnahmen treffen. Wie diese aussehen weiß nur Google, allerdings liegt der Focus auf "bewusst". Sofern der doppelte Inhalt nicht zur absichtlichen Täuschung/Manipulation des Index erstellt wurde, greift Google nicht zusätzlich regelnd ein. 2.: Wenn mehrere URLs den gleichen Inhalt aufweisen, kämpfen diese im Index gegeneinander. Hier kommen dann alle sonstigen Rankingmechanismen zum Tragen, je weniger sinnvoll/bekannt/beliebt eine URL ist desto weiter unten wird sie im Index auftauchen, bzw. die URL mit der größten Relevanz (häufig die einzige der vielen möglichen die von anderen Seiten außer der eigenen, verschachtelten Menüliste verlinkt wird) ist der für Google relevante Suchtreffer. Kurz: Google wird aus den vielen URLs die den gleichen Inhalt präsentieren einen möglichst sinnvollen Repräsentanten wählen und alle anderen als unwichtig klassifizieren weil sie "nichts neues" bieten. http://www.google.com/support/webmasters/bin/answer.py?hl=de&answer=66359 Zum eigentlichen Problem: Es ist also nicht wirklich wiederverwendbarer Inhalt sondern vielmehr eine Verschlagwortung von Seiten gewünscht. Es sollen also nicht viele unterschiedliche Inhaltsblöcke nach Bedarf auf Seiten verteilt werden um dem Redakteur die Arbeit zu ersparen, Inhalte mehrfach tippen zu müssen sondern es sollen vielmehr einer Seite einzelne Schlagworte zugeordnet werden, in Verbindung mit einem Schlagwort-Auswahlmenü als Navigationshilfe im Frontend und einem Schlagwort-Auswahlmenü als Konfigurationselement im Backend. Das hierarchisch abzubilden dürfte schwer bis unmöglich sein, insbesondere wenn es um SEO-URLs geht. Angenommen die SEO-URL enthält die Schlagworte immer alphabetisch sortiert und ein Schlagwort immer doppelt. Bei nur zwei Schlagwörtern ergeben sich vier URL-Varianten (kein Schlagwort, je eines de Schlagwörter, beide Schlagwörter), bei drei Schlagwörtern schon acht (kein Schlagwort, 3* je eines, 3* je zwei, 1* alle drei Schlagwörter). Bei n Schlagwörtern dann 2^n Kominationen. SEO-URLs dafür würde ich deshalb praktisch ausschließen, das ist also kein Punkt über den wir uns groß Gedanken machen müssen. Was der Benutzer an solch einer Stelle gerne hat ist facettierte Navigation. Wenn er SchlagwortA angeklickt hat und es keine Treffer mit SchlagwortA&SchlagwortB dafür aber 10 Treffer mit SchlagwortA&SchlagwortC gibt, sollte man dem Benutzer in der Navigation die Option von SchlagwortB überhaupt nicht geben, dafür SchlagwortC mit dem Hinweis über die zehn zu erwartenden Treffer geben. Siehe das Produktmenü bei Amazon. Wenn sowas eine relevante Konfiguration ist würde ich einen Blick Richtung Apache Solr werfen. Das geht allerdings nur ganz begrenzt generisch, jedenfalls ist das kein Plug'n'Play-Plugin sondern benötigt Kenntnis über die eigenen Daten sowie zusätzlich eine Solr-Server-Instanz. Grundsätzlich ließe sich damit zwar ein generisches Taggingsystem realisieren, allerdings hatte ich bisher noch nicht die Anforderung, das auf tt_content zu verwirklichen. Deshalb kann ich leider nicht mit einer fertigen Konfiguration für tt_content dienen. Meine bisherigen Solr-Integrationen befassten sich stets mit sehr kundenspezifischen ExtBase- oder FLOW3-Models. Auch wenn das jetzt vielleicht ein wenig übers Ziel hinausgeschossen ist, aber vielleicht ist es ja auch genau das richtige. Ich kenne immerhin die Größenordnung deines Projekts nicht: http://media.netlogix.de/community/details/artikel/apache-solr-storage-backend-for-extbase-our-little-christmas-gift-for-you http://forge.typo3.org/projects/extension-nxsolrbackend/repository Leider ist das zugehörige Repository zur Zeit etwas hinten dran weil unser FLOW3-Solr-Storage und unser ExtBase-Solr-Storage dieselbe Codebase sind und die letzten Änderungen im FLO3-Zweig nicht so einfach in den ExtBase-Zweig unseres Solr-Projekts einzugliedern sind. Grüße, Stephan Schuler. Am 19. November 2011 19:07 schrieb Robert Wildling <robertwildl...@gmail.com>: >> Allerdings musst du auch bedenken, dass bei so einem System dann alle Tags >> wieder für alle Records zu Verfügung stehen. Aber du willst bestimmte Tags >> vielleicht nur für News Records verwenden, manche nur für den Kalender, >> manche für Content Elemente und zugleich für Adressen. >> Also müsste man konfigurieren können, wo was angezeigt wird - zumindest >> wenn >> man ein Lösung für alles anstrebt. Außerdem musst du noch bedenken, dass >> verschieden Backend Benutzer verschiedene Rechte haben. >> Ach, und Workspaces gibt es auch ;) > > Ufff... das wird ja 'ne lange Kette an ifs und elses und cases undundund... > > Wie wäre es, wenn man es als CE anbietet, so wie "Text And Images" ein > "Content To Page selector". Damit könnte man vielleicht schon mal eine > Schwelle nehmen, indem man es nicht allen erlaubt, es zu verwenden. > > Eine 2. wäre vielleicht genommen, wenn man sich zur Bedinung macht, dass die > Inhalte an sich schon exisiteren und diese Ext ja nur eine Zuordnung > vornimmt. Damit könnte man vielleicht auch das Workspace-Problem umgehen? > (Mit dem ich mich sowas von überhaupt gar nicht auskenne, auch weil ich > Workspaces noch nie verwendet habe...) > >> Toll wäre es wenn es eine Core Lösung gäbe. Dann würden zumindest die >> meisten Extensions das gleiche System verwenden. >> Dagegen steht die Komplexität um es universell zu machen. > > A-ha... gibt es vielleicht mehrere, die diese Idee gut finden? Vielleicht > wollen sich da noch andere zu Wort melden??? Philipp - du bist > Core-Entwickler, oder? Ist dein letztes Statement bezügl Komplexität und > universell ein ultimatives? Oder meinst du, man kann das zumindest mal wo > als Idee einbringen? > > Danke für deine Antwort übrigens! > LG, Robert > > _______________________________________________ > TYPO3-german mailing list > TYPO3-german@lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german