also ich kenne mich mit dem contenido nicht so gut aus. ich habe es mal für einen bekannten implementiert, der allerdings nun auch nicht mehr bei google zu finden ist. da ich contenido trotz allem für ein wirklich einfach zu bedienendes system und zumindest für KMUs geeignet halte, habe ich mir das mal näher angeschaut und für den speziellen fall eine lösung gebaut, die vielleicht auch anderen weiter hilft.
(1) index.html
als erstes bin ich auf die index.html mit einer weiterleitung auf die front_content.php im ordner /cms gestossen. die hilft den robots (z.B. google) nicht wirklich - also wurde die gelöscht und die front_content.php in eine index.php kopiert (achtet darauf, dass die in der httpd.conf als DirectoryIndex deklariert ist - sollte auf den meisten systemen der fall sein).
(2) apache - alle ohne eigenen server gehen direkt zu (3)
ab jetzt wird mod_rewrite benötigt. das muss im apache installiert sein (LoadModule rewrite_module modules/mod_rewrite.so). wenn ihr die konfiguration des rewrite modules in einem .htaccess file vornehmen wollt, muss der apache das für dieses verzeichnis auch erlauben:
im entsprechenden <directory /pfad/zur/webroot/> container muss die direktive AllowOverride den parameter FileInfo und die direktive Options den parameter FollowSymLinks enthalten.
Lautet die AllowOverride direktive z.B. "AllowOverride FileInfo Limit Options" oder "AllowOverride All" und fehlt die direktive "Options FollowSymLinks", könnt ihr auch in das .htaccess file die zeile "Options +FollowSymLinks" einfügen
(3) contenido
hier bin ich unter "Style" -> "Module" in das modul "Hauptnavigation" gegangen und habe jeweils für die 1. bis 3. navi ebene die zeile
$tpl->set('d', 'HREF', $sess->url('front_content.php?idcat='.$data['idcat'].'&client='.$client.'&lang='.$lang));
durch
$tpl->set('d', 'HREF', $sess->url('/cms/'.$data['idcat'].'.html'));
ersetzt.
(4) mod_rewrite
in den ordner /cms kommt nun ein .htaccess file mit mindestens folgendem inhalt:
RewriteEngine on
RewriteRule ^([0-9]{1,9}).html$ /cms/front_content.php?idcat=$1&client=1&lang=1
da auf der fraglichen site nur ein client und eine sprache zum einsatz kommen, werden diese beiden query parameter in der RewriteRule einfach fest hinten angehängt (kann man wohl sogar einfach weg lassen)
werden in euren sites mehr parameter in den URLs übergeben, müssen die ersetzungen und RewriteRules entsprechend modifiziert werden.
wer weiterleitungen einsetzt oder neben der Hauptnavigation noch weitere links suchmaschinenfreundlich gestalten möchte, muss dann jeweils im entprechenden modul die instruktion zur erzeugung der URL (oben: $tpl->set('d', 'HREF', ...) ändern und /oder weitere RewriteRules hinzu fügen und/oder diese modifizieren (für mehrere paramter bieten sich virtuelle verzeichnisse an).
Diese könnten dann z.B. so aussehen:
RewriteRule ^([0-9]{1})/([0-9]{1,9}).html$ /cms/front_content.php?idcat=$1&client=1&lang=$2
wenn mehrere sprachen eingesetzt werden und die ersetzung des HREF strings in den templates mittels
$tpl->set('d', 'HREF', $sess->url('/cms/'.$lang.'/'.$data['idcat'].'.html'));
erfolgt (voraus gesetzt, ihr nutzt nicht mehr als 9 sprachen
)
(5) /conlib/session.inc (freiwillig) (
VORSICHT)
die default einstellung in der sesion.inc ist meiner meinung nach zwar news- aber nicht suchmaschinenfreundlich: der inhalt ist laut header seit juli 1997 ungültig, die seite wurde gerade erst modifiziert und darf nicht zwischengespeichert werden.
ändert man in der session.inc die zeilen
var $allowcache = "no";
var $allowcache_expire = 1440;
auf
var $allowcache = "public";
var $allowcache_expire = 129600;
dann haben wir einen gültigkeitsintervall von 90 tagen seit der letzten änderung des artikels, ohne dass ein redakteur dies unter "Eigenschaften" für jeden artikel angeben muss (macht eh keiner) und google braucht keine angst zu haben, schon in der nächsten sekunde veraltete inhalte indiziert zu haben.
das ergebnis ist dann um größenordnungen suchmaschinenfreundlicher als die originalkonfiguration.
ich hoffe, das hilft einigen
rainer
