OFDb ist schlecht für Suchmaschinen geeignet

[Gurkenpapst]

Mir ist aufgefallen, dass Filmeinträge in der OFDb in Suchmaschinen auffällig schlecht gelistet sind. Die Gründe dafür sind vielfältig:

• Fehlende robots.txt, die irrelevante Seiten von der Indizierung ausschließt und so das "Niveau" hebt. So ist z. B. die Indizierung von http://www.ofdb.de/view.php?page=suchergebnis oder http://www.ofdb.de/usercenter/view.php?page=login unsinnig, da dort nur eine Fehlermeldung bzw. Loginseite erscheint. Die Indizierung des gesamte User-Center scheint auch eher weniger sinnvoll.
• Semantisch bedeutungsloses Markup mit schlechter Quote zwischen Markup und Inhalt. Beispiel: Anstatt Filmtitel auf ihren jeweiligen Seiten sinnvoll in z. B. <h2>Filmtitel</h2> zu setzen und diese dann mit CSS zu formatieren, wird grundlos eine Tagsuppe wie <font face="Arial,Helvetica,sans-serif" size="3">Filmtitel</font> verwendet. Das Problem zieht sich durch alle Templates, so sind Listen auch nicht über ul/ol-Elemente aufgebaut, sondern einfach mit Zeilenumbrüchen aneinandergeklatschter Fließtext
• Sortierung in den Seitentiteln ist nicht optimal: "OFDb - Pate, Der (1971)" Besser wäre "Der Pate (1971)- OFDb" - Das Nachstellen von Artikel ist zwar für die Sortierung sinnvoll, sonst aber nicht. Und der Name des Films ist wichtiger als das auf der Seite eh omnipräsente OFDb. Die Wikipedia macht es vor, wie man Titel sinnvoll wählt.
• Keine "sprechenden" URIs wie z. B. http://www.ofdb.de/film/2242-Der-Pate anstatt http://www.ofdb.de/view.php?page=film&fid=2242
• Sich wiederholende Seitentitel bei den Reviews, dort könnte man z. B. den Namen mit angeben
• Vielleicht habe ich es übersehen, aber es gibt offenbar keine direkt verlinkte durchsuchbare Liste der eingetragenen Filme, weder alphabetisch, noch nach Bewertung, noch in sonst irgendeiner Form. Das macht es Suchmaschinen natürlich schwer bis unmöglich, die Filme überhaupt ohne Umwege wie z. B. über Benutzer und deren Reviews zu finden.
• Unnötig allgemein gehaltene Linkbezeichnungen zu den Review-Seiten: "Zur Übersichtsseite des Films" Warum nicht "Zur Übersichtsseite des Films Der Pate"
• URIs mit Partner-ID werden von Suchmaschinen indiziert und verursachen so Duplicate Content: http://www.google.com/search?q=site%3Aofdb.de+inurl%3Apartner - alles unnötig indizierte Seiten, die keinen Mehrwert bringen. Ein permanenter Redirect oder ein Ausschluss von der Indizierung wäre sinnvoller.

Insbesondere die ersten zwei bis drei Punkte sollten sich leicht verbessern lassen und vergleichsweise viel bringen. Vielleicht greift ihr ja den einen oder anderen Punkt auf. Aber passt auf, dass ihr dann nicht irgendwann von über die Suchmaschinen kommenden Besucher überrannt werdet. :D Als Ausgleich kann man dann aber bei einer suchmaschinentauglichen Site in Zeiten mit hoher Serverlast problemlos die Suchfunktion auf die Suchmaschinen abwälzen, eine Google-Suchbox habt ihr ja schon auf der Site.

[Dr. Kosh]

Vielen Dank für die ausführlichen Hinweise! Ich kann leider auch nicht leugnen, daß wir in diesem Bereich noch einige Defizite haben... Ich habe mir den Beitrag auf jeden Fall abgespeichert und werde versuchen, nach und nach die einzelnen Punkte in Angriff zu nehmen.

Gruß
Dr. Kosh

[Gurkenpapst]

Ich sehe gerade, dass du offenbar bereits angefangen hast. Die "sprechenden" URIs sind allerdings eine Sache, die man gut planen sollte, da man sich damit idealerweise einmal festlegt. Insbesondere sollte man darauf achten, dass es immer nur einen gültigen URI zu einer Seite gibt. In dem aktuellen Status wird extrem viel Duplicate Content erzeugt, da zum einen die alten URIs den Suchmaschinen bekannt sind und von extern und teilweise auch noch intern darauf verlinkt wird, zum anderen nun massenweise neue URIs indiziert werden. Richte daher unbedingt für URIs mit der alten Syntax eine permanente(!) Umleitung mit Statuscode 301 auf die neuen URIs ein. Sonst geht die Aktion schnell nach hinten los.

Bei dem DC durch die Domain mit und ohne www hast du ja schon vorgesorgt, allerdings ist die Umleitung nicht permanent sondern temporär und zudem ist da irgendein Fehler drin: http://ofdb.de/view.php?page=start leitet auf http://www.ofdb.deview.php?page=start [sic] um. Warum gibt es überhaupt eine Umleitung von / auf /view.php?page=start? Unter / sollte direkt die Homepage sichtbar sein.

Ich hätte mit der robots.txt angefangen und dann mit dem Markup weitergemacht. Da ist keine große Planung notwendig und man kann wenig falsch machen.

[Defender]

Wenn man nichts gegen hat, würd ich mein Senf noch kurz dazu abgeben. Hab mich vor kurzem länger mit dem Thema ModRewrite befasst.

Sehe aber, hast da mit Gurkenpapst jemanden der bereits eindeutig erfahrung hat.


Generell beim Einsatz von ModRewrite immer prüfen ob die Url die korrekte ist, wenn nicht, weiterleiten. (Also auch ob der "anhang" der korrekte ist.)
Ansonsten führt das zu problemen. (Die Umleitung alter URL und die prüfung auf die korrekte Url lässt sich in 1nem Prüfen.)
BSP für DC-Content bei nicht überprüfung:
143121,Wilden-Kerle-5-Die-(2008)
143121,Wilden-Kerle-5-D-(2008)
usw...

Das ganze kannst du relativ einfach mit einer Funktion realisieren.
Hier mal ein in etwa beispiel:

function checkRequestURI($uri){
global $requesturi;   ## muss natuerlich entsprechend bearbeitet sein. z.b. alles nach domain an. Also alles nach ofdb.de/   entscheidung auf www oder nicht muesste natuerlich auch getroffen werden.
if($uri != $requesturi) Header("Location: .....");  ## code nicht vergessen
}
checkRequestURI("film/$movieID,".functionzurformatierungdesanhang($movieName)."");


Was ich auch noch empfehlen würde, dem ding eine Endung zu geben.
Das:
film/143121,Wilden-Kerle-5-Die-(2008)
ist irgendwas

Hier:
film/143121,Wilden-Kerle-5-Die-(2008)/
hätte man ein Verzeichnis

Persönlich hab ich, zumindest was die indizierung angeht gute erfahrung mit der endung .html gemacht.
film/143121,Wilden-Kerle-5-Die-(2008).html

Wobei man hier wieder das selbe Prinzip anwenden könnte das Gurkenpapst als 3ter Punkt erwähnt hat. Verschiebung des "Der/Die/Das/etc"

* Defender verkriecht sich nun wieder in sein eckchen.

[Gurkenpapst]

Dem Hinweis auf die (permanente) Weiterleitung bei verfremdeten URIs kann ich nur beipflichten, die bräuchte man ja eh schon um die bisherigen URIs weiterzuleiten, da dort ja bisher die Namen nicht drinstehen. Eine Lösung über mod_rewrite wäre daher nicht möglich. Bezüglich der Endung des URIs auf / oder .html sehe ich aber keinen Vorteil. Als Verzeichnis hat man eher mit den Pfaden zu kämpfen, da müssen dann ja alle relativen Pfade von einer tieferen Ebene aus adressiert werden. Gut, das Argument greift hier nur begrenzt, da eh schon ein Verzeichnis hinzu gekommen ist, aber sowohl die URIs als auch etwaige relative Pfade werden länger, ohne dass ich einen Vorteil erkennen kann.

Dass .html als Endung einen Vorteil haben soll, liest man zwar oft, aber ich habe bisher keine positiven Effekte dadurch beobachten können. Man hat dadurch ein Keyword im URI, das überhaupt keinen Bezug zu dem Seiteninhalt hat. Wer mal nach einer PHP-spezifischen Lösung eines Problems gesucht hat, kennt das Problem möglicherweise: Man findet Seiten die zwar das Problem im allgemeinen Beschreiben, aber PHP taucht dann nur als Endung im URI auf. Für HTML wird das ähnlich sein. Auch wenn das nicht unmittelbar ein Nachteil für den Seitenbetreiber sein wird, so wird die Existenz eines unnötigen Keyword sicherlich die Gewichtung anderer, relavanter Keywords abschwächen. Ein Weiteres Argument dagegen: Erfolgreiche, große Sites wie die Wikipedia, Amazon oder eBay verwenden keine Endungen. Es kann also nicht so völlig verkehrt sein, die ebenfalls wegzulassen.

[Dr. Kosh]

Vorab möchte ich erst einmal erwähnen, daß ich es toll finde, hier wirklich hilfreiche, technische Hinweise zu erhalten! Außerdem hätte ich ohne diesen "Anschubser" vermutlich auch noch längst nicht damit begonnen, in die Materie der Link-Optimierung einzusteigen. Also: Vielen Dank!

Grundsätzlich scheint das momentan von mir angepeilte Link-Format (siehe Film-, Review- und IA-Links) ja schon ganz gut gewählt zu sein. Das beruhigt mich natürlich! :icon_mrgreen:

Eine allgemeine HTTP 301-Weiterleitung von den alten Links auf die neuen habe ich bereits eingerichtet. Die Ausführungen, die ich zum Thema "Duplicate Content" im Zusammenhang mit Suchmaschinen gelesen habe, machten mir dann doch in soweit Sorgen, daß ich mich lieber sofort daran gemacht habe, die alten Links durch 301 zu "invalidieren".

Als Keyword-Trenner in der URI scheint ja der Bindestrich das beste Symbol zu sein (wobei angeblich auch Leerzeichen recht gut geeignet sein sollen); ich habe mich jedenfalls für die Verwendung des Bindestrichs entschieden. Nicht ganz sicher bin ich mir allerdings, was das Filtern von Sonderzeichen aus der URI anbelangt. Momentan filtere ich praktisch alles nicht-alphanumerische heraus. Ich sehe bei anderen Seiten aber auch häufiger mal, daß alle Sonderzeichen erhalten bleiben (manchmal URL-encoded, manchmal nicht einmal das). Wie sollte man da verfahren? Was ist z.B. mit Umlauten oder Buchstaben anderer Sprachen? Beibehalten? URL-encoden? Ich bin nicht sicher...

Gruß
Dr. Kosh

[Defender]

Bezüglich Dateiendung: Dürfte geschmacksache sein. Ich nutz es aus dem "optischen" Effekt und der "verdeutlichung" das es statisch ist. (Klar, Header sagt dann schon das es php ist..) Bin bis jetzt eigentlich immer davon ausgegangen das es vorteilhafter ist, wenn es eine statische, sprich .html, Seite ist. Wikipedia ist allerdings ein gutes gegenargument. (Wobei wir hier uns jetzt den Kopf einschlagen könnten, wieviel der PR ausmacht..)

Bezüglich trennzeichen gab es mal vor langer Zeit im Abakus Forum einen netten Test..  Link.. letztendlich ist dabei rausgekommen, das _ nicht geeignet ist. Aber ob es nun - , ist, ist egal.

Sonderzeichen:
Ich selber replace die, da ich auf sprechende Urls setzte und nicht "nur" für Suchmaschinen optimiere. Bei mir ist der hintergedanke immer der, das die struktur sinnvoll sein soll und der Besucher auch was mit der URL anfangen kann.
Bezüglich Seo dürfte z.b. das ä kein Problem sein. Ich vermute sogar es ist besser als wenn du z.b. ae machst. (Ich bleib aber bei meinem ae)
Google erkennt das ä [klick]
Kodiert wird das ja meistens vom Browser schon alleine. Wenn ich bei obrigen Link den Link zur Wikipedia anklicke, macht FF automatisch ein %C3%84 daraus. Aber achtung. Es gibt wohl auch noch Browser die das nicht tun.

Ich würde mal frech behaupten, das es Suchmaschinenmässig besser ist das ä zu behalten. Es sollte aber wohl codiert sein. (Dürfte sogar dem standard entsprechen, oder? @Gurkenpapst) Sollte es nicht ein standard dafür geben, könnt ich dazu auch nur vermuten.

[OffTopic] Da es aber mein FF macht, und du mich dann auf die korrekte Umleiten wirst, dürfte das in ner Endlosschleife enden?
Bin ehrlich gesagt grad zu faul zum testen, aber wird die RequestVariable automatisch decodet? (Falls ja, dann kann ja das problem mit der Umleitung nicht passieren.)
E: Habs grad mal mit der OFDB getestet. Man suche nach "Hör mal wer". Der link kommt ohne kodierung, wähl ich ihn an, codiert FF allein.. Umleitung auf überprüfung des anhangs ist anscheinend bei Filmen noch nicht da, daher ka wie das gehandhabt werden würde.
[/OffTopic]

[Gurkenpapst]

Leerzeichen in URIs sind eher ungünstig, da sie in ihrer zwingend erforderlichen %-Kodierung die URI kaum noch "sprechend" machen, das kann man nur noch schwer lesen. Der Unterstrich wäre IMO optisch am schönsten, aber solange Google den nicht als Worttrenner ansieht, ist der aus SEO-Sicht nicht unbedingt sinnvoll. Yahoo! macht es da übrigens anders, dort "funktioniert" auch der Unterstrich. Als nächstbeste Lösung würde ich den Bindestrich empfehlen, den du ja auch schon verwendest.

Interpunktionszeichen würde ich alle herausfiltern, die bringen keinen Vorteil und sind ggf. problematisch bzw. bei %-Kodierung und Darstellung als solche wieder unleserlich. Nicht in US-ASCII darstellbare Buchstaben sind ein schwieriges Feld. Man kann sie zwar umschreiben, aber das ist nicht immer eindeutig. Wenn man es genau nimmt, muss man zunächst einmal die Sprache des Worts kennen, und dann die dafür gültigen Regeln anwenden. Alternativ kann man sie %-kodieren, dann muss der Text jedoch zuvor in UTF-8 kodiert werden. So fordert das zumindest RFC 3986 und spätestens bei Zeichen außerhalb des von ISO-8859-1 abgedeckten Zeichenvorrats funktioniert eine Kodierung in ISO-8859-1 nicht mehr. Eventuell wäre eine komplette Umstellung auf UTF-8 sinnvoll, das ist aber ein recht großer Aufwand, der dafür aber sämtliche Kodierungsprobleme lösen würde.

Ich weiß nicht, ob es in der OFDb überhaupt Filme mit nicht lateinischen Buchstaben gibt. Wenn ja, wäre eine mittel- bis langfristige Umstellung auf UTF-8 sicherlich sinnvoll. Sonst muss man sich ja ständig mit der Konvertierung von ISO-8859-1 nach UTF-8 und umgekehrt sowie der Maskierung der Zeichen in ISO-8859-1-kodierten Bereichen beschäftigen.

Ich sehe für die URIs eigentlich nur zwei sinnvolle Möglichkeiten: Entweder alle nicht-ASCII-Buchstaben unter den Tisch fallen lassen oder aber als UTF-8-Bytefolge %-kodieren. Alternativ könnte man auch Umlaute und ß nach den hierzulande üblichen Regeln als ae, ue, oe, ss umschreiben. Das wäre zwar gegenüber den vergleichsweise vielen "zerstörten" Wörtern beim Weglassen von Umlauten ein großer Vorteil, würde aber ggf. einige Wörter in anderen Sprachen entstellen, weil dort andere Regeln gelten. Immerhin: In diesen Sprachen wäre das Weglassen sicherlich auch falsch. Man würde also wohl durch den Mehraufwand nichts schlimmer machen, aber vieles besser.

Unkodiert sind nicht-ASCII-Zeichen in URIs absolut unzulässig. Dass es dennoch irgendwie funktioniert, liegt allein daran, dass solche URIs normalerweise vom Browser vor dem Aufruf in UTF-8-%-Notation nachkodiert werden sollten. Siehe http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.1 (beachte, dass der dort angesprochene RFC 1738 durch RFC 3986 ergänzt wurde) Dabei kommt es aber zu Unstimmigkeiten, denn mache Browser kodieren die Zeichen aus historischen Gründen in ISO-8859-1 oder in der Kodierung der aktuellen Seite. Somit erzeugen die Browser unterschiedliche URIs, das ist natürlich nicht Sinn der Sache. Daher sollte man immer dafür sorgen, dass korrekte URIs verwendet werden, wo die Browser keine Fehlerkorrektur vornehmen müssen.

Das von Defender angesprochene Beispiel auf der Google-Ergebnisseite ist übrigens kein solcher Fall mit einem fehlerhaften URI. Wenn man dort mal in den Quellcode guckt, findet man <a href="http://de.wikipedia.org/wiki/%C3%84" class=l>Ä - Wikipedia</a> - Es wurde das Ä korrekt in UTF-8-basierter %-Kodierung angegeben. Dass bei den grünen Zeilen die Umlaute lesbar sind, ist etwas inkonsequent, trägt aber zur Lesbarkeit bei. Vergleiche auch die Darstellung in der Adresszeile der Browser. SeaMonkey zeigt die %-Kodierung an, Opera dagegen tut es nicht.

Das Hör-mal-wer-Beispiel ist (wie jeder andere URI mit nicht-ASCII-Zeichen) bei der derzeit fehlerhaften URI-Generierung und der Korrektur durch den Browser tatsächlich ein Problem, zumindest wenn dann auf den generierten String geprüft werden würde. Da URIs ausschließlich ASCII-Zeichen enthalten können, kann solch ein URI ja technisch bedingt niemals aufgerufen werden, daher würde man immer wieder eine Umleitung auf einen falschen URI bekommen, die der Browser dann wieder fleißig korrigiert.

[Cyriaxx]

Hallo,

diesen Thread und die mit ihm einhergehenden Änderungen habe ich mit Interesse verfolgt. Als betroffener Webmaster (Echolog Filmtipps) stellt sich mir natürlich die Frage, ob a) in jedem Fall die angehängte Partner-ID noch ausgewertet wird und b) wie man jetzt idealerweise einen Link auf einen OFDb-Film setzen sollte. Das Problem: Den Link, wie er in der schlussendlichen Weiterleitung aussieht (Beispiel: http://www.ofdb.de/film/13684,Der-Tag-an-dem-die-Erde-Feuer-fing) kann ich nicht nehmen, da meine Filmtipps aus einer Datenbank generiert werden und dort nur die OFDb-Filmnummer eingetragen ist.

Derzeit ist obiger Film bei mir so verlinkt:
http://www.ofdb.de/view.php?page=film&fid=13684&partner=29421

Durch Ausprobieren habe ich festgestellt, dass es beim neuen Format egal ist, was nach dem Komma kommt (und ob überhaupt etwas nach dem Komma kommt), also http://www.ofdb.de/film/13684, funktioniert auch (obgleich ein Komma als letztes Zeichen einer URL natürlich etwas, ähem, ungewöhnlich ist) und http://www.ofdb.de/film/13684,Irgendein-Quatsch funktioniert ebenfalls.

Das Format meiner Links könnte ich ohne Probleme ändern in zum Beispiel:
http://www.ofdb.de/film/13684,?partner=29421

Bringt das für irgendwen irgendwelche Vorteile oder ist es ganz einfach egal, ob ich das so ändere oder bei der alten Form bleibe? Und, wie gesagt, würde bei der obigen Form mein Partner-Zusatz überhaupt ausgewertet oder ist dafür die alte Form mit view.php zwingend? (womit sich die Frage ja dann erledigt hätte ...)

Grüße
Cyriaxx

[Dr. Kosh]

Bringt das für irgendwen irgendwelche Vorteile oder ist es ganz einfach egal, ob ich das so ändere oder bei der alten Form bleibe? Und, wie gesagt, würde bei der obigen Form mein Partner-Zusatz überhaupt ausgewertet oder ist dafür die alte Form mit view.php zwingend? (womit sich die Frage ja dann erledigt hätte ...)

Keine Sorge, der Partner-Zusatz wird auch bei der neuen Form ausgewertet (Du hast die URL auch gleich in der richtigen Form angegeben, d.h. mit Fragezeichen ans Ende gesetzt).

Die neue URL mit "irgendwas" zu verwenden, würde ich allerdings nicht empfehlen. Es funktioniert zwar gegenwärtig noch, aber wahrscheinlich nicht dauerhaft.

Ich würde daher vorschlagen, daß Du einfach bei der bisherigen Form bleibst. Das "alte" Link-Format bleibt ja weiterhin gültig. Daran wird sich auch nichts ändern. Besucher, die über Deinen Link zu uns gelangen, landen dann ohnehin beim neuen Link, ohne davon groß etwas zu merken. Und die Partner-ID wird selbstverständlich auch in diesem Fall "durchgereicht".

Gruß
Dr. Kosh

[Gurkenpapst]

Da es immer recht interessant ist, wie schnell die Suchmaschinen bei solchen URI-Umstellungen reagieren, habe ich mir den Prozess in den letzten Tagen beobachtet. Dabei bin ich über eine andere Domain gestolpert, unter der ebenfalls die OFDb erreichbar ist: http://www.google.com/search?q=site%3Aweb1.ofdb.net-build.de - Hier sollte auch eine Umleitung auf www.ofdb.de/$1 erfolgen, oder aber diese über eine Domain-spezifische robots.txt komplett gesperrt werden. Sonst ist das wieder schöner DC.

Die neue URL mit "irgendwas" zu verwenden, würde ich allerdings nicht empfehlen. Es funktioniert zwar gegenwärtig noch, aber wahrscheinlich nicht dauerhaft.

Empfehlenswert wäre die Verwendung natürlich nicht, aber auf der anderen Seite wäre es auch unsinnig, solche URIs nicht mehr funktionieren zu lassen. Eine Umleitung auf den kanonischen URI ist allemal besser als eine 404 Seite.

In das meta-Description-Feld könnte man bei den einzelnen Filmen übrigens die Inhaltsangaben verwenden. Das erscheint mir sinnvoller als immer der gleiche Satz auf allen Seiten.

[Cyriaxx]

Ich würde daher vorschlagen, daß Du einfach bei der bisherigen Form bleibst.

Danke für die Info. Ich konnte übrigens feststellen, dass Google die neuen URLs unterdessen gefressen hat. Rein interessehalber: Wie haben sich die Änderungen denn nun konkret auf die Besucherzahlen ausgewirkt? Ich tippe mal, ein Anstieg auf das 2- bis 3-Fache ...?  :respekt: