Suchmaschinen-Freundlichkeit

[cmsdau]

Hallo zusammen,

ich stehe vor der Überlegung meine webseite auf ein CMS umzustellen.
Ich habe keinen root-Server, sondern nutze den Hoster Bytecamp(.net).

Wenn der Einsatz von Contenido bedeuten würde, dass ich z.B. bei Google nicht mehr gefunden werden (bzw. nicht mehr alle Seiten indiziert werden) ohne dass ich für jede Seite (ungenutzte) Metatags generieren muss, dann möchte ich doch lieber bei statischen Webseiten bleiben.

Ich habe einige Diskussionen gelesen, konnte einigen Code-Diskussionen nicht ganz folgen.

Wie ist denn der Stand der Lösungen für dieses Problem?

Schönen Gruß,

Axel

p.s. ich nutze das aktuelle 4.4 (?)

[timo]

Bisher leider gar keiner - ähnliche Probleme gibt es allerdings auch bei anderen Systemen.

Grüße,
Timo

[cmsdau]

Tja,
warum sollte man dann ein CMS wie Contenido einsetzen?
Selbst eure eigene Seite wird ja bei Google nur einmal gefunden ...
Was bringt die schönste Seite, wenn man keine Besucher hat? OK, wenn man die Popularität von Amazon oder ebay erreicht hat, kann man vermutlich auf Google verzichten, aber dann benutzt man wohl ebenfalls kein Contenido?!

Naja, schade, es hätte mir das doofe HTML-coden erspart, aber auf Besucher möchte ich dann doch nicht verzichten.

Axel

[timo]

Ich sagte ja lediglich, daß derzeit keine Möglichkeit existiert. In Zukunft soll das aber anders werden; bleib auf jeden Fall mal dran.

[MichaGue]

Es gibt ja verschiedene Ansätze diesem Übel entgegenzuwirken, z.B. der Einsatz von Brückenseiten oder ähnlich.

Welche Erfahrungen habt ihre denn damit, oder besser gesagt, was macht ihr um trotz cms in den Suchmaschinen zu landen?

Gruss Michael

[MakD42]

@timo

was bedeutet

bleib auf jeden Fall mal dran

- seid Ihr schon dran? - oder andere?
- habt ihr wie in versch. Posting unter 4.2.. angesprochen schon die Weichen dafür in der db von 4.4.X gestellt?
und
- wird dieses Feature auch für V. 4.3.2... verfügbar sein?

Grüße aus Marburg

[cmsdau]

Hallo zusammen,

offenbar habe ich da ein Thema gefunden, was nicht nur mich interessiert.
Glücklicherweise hat mir bytecamp (mein Hoster) mitgeteilt, dass mod_rewrite bei denen im Einsatz ist und daher muss ich jetzt "nur" noch herausfinden, wie man mit Contenido und mod_rewrite arbeitet.

Schönen Gruß

Axel

[laurisilva]

Hallo,
wenn Du rausgefunden hast, wie das mit mod_rewrite bei Contenido funktioniert, dann poste das bitte hier. Mich würde das auch brennend interessieren. Ich glaub nur das das nicht so einfach ist durch die verschiedenen Endungen, die Contenido verwendet. Ich denke da z.B. an die in andere Kategorien kopierten Artikel mit dem subid Zusatz. Aber die sollen ja laut timo eh wieder verschwinden.

Gruss
Laurisilva

[rbickel]

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

[rbickel]

google verarbeitet AFAIN durchaus query strings. allerdings nur mit einem parameter. die standardeinstellung bei contenido erzeugt aber URLs mit drei parametern (zumindest in der Hauptnavigation). z.B.:
/cms/front_content.php?idcat=58&client=1&lang=1

alle, die nur eine site (einen client) und eine sprache verwalten, können zwei davon entfernen.
dazu müsst ihr unter "Style" -> "Module" in das modul "Hauptnavigation" gehen und 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('front_content.php?idcat='.$data['idcat'].));
ersetzen.

bei mir funktioniert die site danach immer noch und ihr habt nur einen parameter im query string und google freut sich.


punkt (1) meines obigen exkurses hat nichts mit mod_rewrite zu tun und dürfte somit auch denjenigen helfen, die kein mod_rewrite zur Verfügung haben.

rainer

[timo]

Ich habe bei mir auf der Website mit "statischen" Rewrite-Rules gearbeitet (d.h. die Parameter-Anzahl und deren Reihenfolge ist fest). Beispiel Rewrite-Rule:

RewriteRule ^idcat-([0-9]*).html$ front_content.php?idcat=$1 [PT]
RewriteRule ^idcat-([0-9]*)-idart-([0-9]*).html$ front_content.php?idcat=$1&idart=$2 [PT]

idcat-20.html verweist dann auf Kategorie 20, idcat-20-idart-19.html auf Kategorie 20 mit Artikel 19.

Natürlich muß man die Module anpassen und für jede Parameterkombination eine Rewrite-Rule bauen, was aber bei einer handvoll Modulen nicht sonderlich schwierig sein sollte.

[hankwatson]

@rainer:

Verfasst am: Sa Dez 06, 2003 1:03 pm Titel: ein einfaches Beispiel

--------------------------------------------------------------------------------

(5) /conlib/session.inc (freiwillig)
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;
--------------------------------------------------------------------------------

...hat bei mir bewirkt, dass im Administrationsbereich vieles nicht mehr funktioniert hat.

Für den Rest vielen Dank!
Martin

[OAA]

Hallo,

ich habe meine Seite www.abeltshauser.net wie folgt gebaut:

Ein statisches Template (sprich die Navigation wird vorher festgelegt, auf contenido verlinkt, und nicht dynamisch erzeugt)

ich bin bei google durch angabe von abeltshauser oder oliver abeltshauser zu finden.

ich weiß nicht, warum die anderen da jammern, ich bin drin.

aber warum? das verstehe ich nämlich nicht...

hat jemand von Euch eine Erklärung?

mfg

OA

[rbickel]

@hankwatson

...hat bei mir bewirkt, dass im Administrationsbereich vieles nicht mehr funktioniert hat.

Da hast Du Recht. Von dieser Änderung sollte man wohl doch lieber Abstand nehmen.
Wenn Du im Internetexplorer unter "Extras" -> "Internetoptionen" -> "Allgemein" -> "Temporäre Internetdateien" -> "Einstellungen" den Standardwert für "Neuere Versionen der gespeicherten Seiten suchen:" nicht geändert hast und dieser also auf "Automatisch" steht, wird dieser nach erstmaligem Aufruf einer Seite für die nächsten 90 Tage die Seite aus dem Cache holen. Dies gilt auch für den Adminbereich und für andere Browser deren Cachefunktion aktiv ist.

Also Vorsicht bei Modifikationen der session.inc!

[rbickel]

@OAA

...
aber warum? das verstehe ich nämlich nicht...

hat jemand von Euch eine Erklärung?

Ja, klar:

google verarbeitet AFAIN durchaus query strings. allerdings nur mit einem parameter. die standardeinstellung bei contenido erzeugt aber URLs mit drei parametern (zumindest in der Hauptnavigation). z.B.: /cms/front_content.php?idcat=58&client=1&lang=1

Deine URLs haben nur einen Parameter im Query-String: "?idcat=xx".
Somit bist Du unterhalb der Grenze (2), ab der Google dicht macht. Ich weiß nicht, welche Version von Contenido Du einsetzt oder ob Du unter "Style" -> "Module" das modul "Hauptnavigation" modifiziert hast oder dieses garnicht benutzt. Auf jeden Fall wird man mit einem Parameter an der URL immer noch locker gegooglet.

RB