Natürlich: In den erweiterten Optionen kann man problemlos das Seitenverzeichnis: "/pages" umbenennen – und auch löschen. Ob WebsiteBaker dann noch funktioniert ist eine andere Frage. Herr, führe uns nicht in Versuchung.
Kein Pages-Verzeichnis – geht das?
Standardmäßig legt WebsiteBaker alle Seiten in das "mitgelieferte" Verzeichnis /pages. Ändert man die Einstellung: Erweiterte Optionen -> Seitenverzeichnis: "/pages" etwa zu "/cms" funktioniert zunächst einmal nur die Startseite. Zusätzlich muss man nämlich noch das Verzeichnis "pages" von Hand umbenennen.
Wenn nur ein anderer Name – zb "/cms" angegeben wurde, funktioniert das normalerweise problemlos. Eventuell könnten einige ältere oder schlampig gestrickte Module oder Templates Ärger machen, die irgendwo /pages/ fest im Code stehen haben. Das sollte aber mittlerweile eine seltene Ausnahme sein.
Zur Erinnerung: Es muss die Konstante PAGES_DIRECTORY verwendet werden.
WebsiteBaker tiefer gelegt
Entfernt man hingegen /pages komplett, bekommt die Sache eine andere Tragweite: Alle Seiten werden eine Ebene höher angelegt. Häufig ist es dann nicht mehr möglich, Seiten anzulegen oder zu löschen, weil man auf das Root der Domain oft die Rechte nicht setzen kann. Folglich kann WB hier auch keine Seiten anlegen. Abhilfe schafft, die Seiten von Hand anzulegen – was sehr heikel werden kann und nur bei kleinen Seiten möglich ist.
Selbst wenn die Rechte kein Problem machen, ist man noch lange nicht auf der Sieger-Seite: Hat man zB einen Menüpunkt "Templates", birgt das reichlich Konfliktstoff. Tatsächlich murrt WB ein wenig, legt aber brav die Access-Files rein – und sie funktionieren auch. Kommt man aber dann auf die Idee, den Menüpunkt zu ändern ist es vorbei: Das Templates-Verzeichnis wird umbenannt und – aus: PHP Fehler. Nichts mehr geht, Handarbeit ist angesagt.
Ein weiteres Risiko liegt in möglichen Updates: Zwar testet das WB-Team natürlich, ob eine neue Version auch unter diesen Umständen läuft, aber der Teufel schläft nicht und kleine Ursachen können große Wirkung zeigen.
Sinnfrage
Das Pages-Verzeichnis einfach nur umbenennen kann sehr wohl Sinn machen: Die Bezeichnung "pages" wirkt etwas altbacken, während zb cms schon gleich mal zeigt, dass diese Site jetzt modern ist.
Deutlich heikler ist es, das pages-Verzeichnis ganz zu entfernen: Bei mehrsprachigen Seiten - die in der obersten Ebene nur 2 Dummy-Seiten brauchen, werden die URLs damit kürzer und solange die Namen der Verzeichnisse nicht mit den WB-Verzeichnissen kollidieren, ist die Gefahr gering. Ebenso nachdenken kann man darüber, wenn man von Haus aus weiß, dass es nur sehr wenig Seiten in Ebene 0 geben wird.
Ansonsten wird der Ärger, den man sich möglicherweise einhandelt, die Freude über die gekürzten URLs schnell trüben, speziell wenn ein WB-Update ansteht.
Ältere Kommentare:
25.08.2008
Ich habe schon öfter vorgehabt, WB "tiefer zu legen", doch aus den oben genannten Gründen habe ich stets brav die Finger davon gelassen.
Dabei frage ich mich, ob es nicht eine geschickte Lösung über eine .htaccess Datei gibt, um das zu überschreiben.
Sodass aus:
www.meinedomain.tld/pages/about.php
dieses wird:
www.meinedomain.tld/about.php
Wird wahrscheinlich auch nicht überall funktionieren, aber wäre es sinnvoll und machbar.
Wenn ja, wie geht man dabei vor?
MfG,
Stefek
28.01.2009
Also ich finde diese Regelung mit dem "Pages"-Ordner mächtig lästig. Stört ohne Ende. Kann man zwar umbenennen, aber der Weisheit letzer Schluss ist es wahrlich nicht.
12.02.2009
WebBird
Zur .htaccess:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ pages/$1 [L,QSA]
Bedeutung:
* Existiert eine solche Datei, abbrechen.
* Existiert ein solches Verzeichnis, abbrechen.
* Handelt es sich um das favicon, abbrechen.
* Wurde bis hier nicht abgebrochen, auf pages-Verzeichnis weiterleiten.
17.03.2009
Der Grund, das Verzeichnis /pages/ liegt mit in der Suchmaschinenoptimierung. Viele Quellen meinen, dass eine niedrige Verzeichnistiefe besser wäre. Zudem sind die Seiten ohne /pages/ kürzer und somit auch besser zu merken.
Daher wollte auch ich für meine Seite den Ordner gerne weglassen.
Schade, dass es keine saubere und vernünftige Lösung bisher gibt.
17.03.2009
Chio
Websitebaker will ein "einfaches CMS" sein. Das heißt: keine Basteleien in der htaccess.
Von diesem Prinzip ausgehend, müssen die Seiten in ein Verzeichnis abgelegt werden - und das heißt eben "pages". Ich benenne es meist um in "cms", aus optischen Gründen, bleibt aber letztlich das selbe.
Ob das pages-Verzeichnis (oder nicht) eine Rolle spielt, kann ich nicht eindeutig sagen, mit Sicherheit ist der Effekt gering - oder null.
Es halten sich allerhand Gerüchte um Google, die häufig eine etwas "menschliche Sichtweise" als Basis haben. Zur Erinnerung: Google ist eine Maschine. Die Merkfähigkeit von Maschinen funktioniert anders als die von Menschen.
30.06.2009
Wer auf SEO aus ist, ist mit Websitebaker zwar nicht schlecht beraten, allerdings gibt es hierfür mächtigere CMS-Systeme. Entweder einfach gehalten und jeder kann es bedienen oder nicht ganz so seooptimiert.
Neuere Themen:
Die Startseite nicht ins Menü Alles unterordnen oder mit mehreren Menüs arbeiten
Ältere Themen:
Kommentare:
24.11.2009
Jens
Ich mache aus der Not eine Tugend und benenne das Pages Verzeichnis gleich in einen suchmaschinenfreundlichen Begriff um, zB haben wir eine Firma deren Domain aus dem Firmennamen-Stadtname.de besteht, daraus geht noch nicht hervor, dass die Firma Schmuck verkauft, also habe ich pages zu schmuck umbenannt. Ich weiß nicht ob es daran lag (vielleicht wenigstens zum Teil), aber wenn man Schmuck und den Stadtnamen eingibt ist die Domain bei google auf Platz 1.
10.03.2010
Ich habe eine etablierte Website. Mit Umswitchen auf WB will ich die bei Google gelisteten URLs nicht riskieren, indem auf Schlag neue Pfade entstehen. Deswegen ohne /pages bisher. Das muss doch das System aushalten?
Meine handgecodete Ausgangssite mit Unterseiten ist auf oberster Ebene verstreut.
Zum Glück werden die Unterseiten wiederum in Ordnern gestored, also wirds nicht allzu wild auf dem Server.
22.03.2011
Aus SEO Sicht ist das Pages Verzeichnis tatsächlich störend - Redirect per htaccess wie von WebBird vorgeschlagen scheint mir die beste Möglichkeit.Das bdeutet aber alle Module und Snippets wegen der Pfade ordentlich zu prüfen und evtl. noch ein paar Ausnahmen per Hand einzufügen...
@chio - der Effekt ist immens. Wer sich ein bischen mit URL Shaping befasst, wird wissen, dass kleine Änderungen in der URL teilweise erheblich Auswirkungen auf das Ranking haben
22.03.2011
Ich habe im letzten Jahr gut 10 Websites von statisch auf WB umgestellt - und mich um das pages-Verzeichnis nicht weiter gekümmert. Auch nicht um die URLs, das ist sowieso vergebens. Ich mache einfach eine lange Liste an 301-Weiterleitungen, das ist weit einfacher.
Fazit: Wenn sich der Inhalt wenig ändert, ändert sich auch das Ranking kaum.
Zumal Google ohnehin viel Wert auf die eingehenden Links legt - und die ändern sich ja nicht.
In der Praxis gab es natürlich Änderungen; wer macht schon einen Relaunch, ohne die Inhalte durchzuputzen. Mehr als 10% Änderung der Besucherzahlen hatte ich aber bei keiner Site bisher; kann man ja mit Analytics gut vergleichen.
30.03.2011
Ich lege gerne bei den ein oder anderen escpro-projekt die seite "tiefer" - Vorteile im Hinblick SEO möchte ich jedoch nicht behaupten.
11.06.2011
Wenn man obige .htaccess in den Domain-Root letzt und in der index.php die Zeile
echo $output;
gegen
echo str_replace(PAGES_DIRECTORY.'/','/',$output);
austauscht (also CORE-Änderung), ist der /pages/-Ordner für den Browser und die Suchmaschinen weg. Er bleibt jedoch real bestehen, der WB arbeitet damit ganz normal weiter und alles funktioniert wie gehabt - nur ohne /pages/...
