Böse Schöne URLs

Anders als die ungeliebten Parameter -  index.php?id=23&t=10k=137 - sind SEF (Search Engine Friendly) URLs lesbar und bilden einen typischen Pfad ab: /obst/birne/gelb/bebus.html

Die Suchmaschine bekommt nicht nur die formale, nackte Nummer, sondern die ganze - vor allem unvertauschbare - Ordnung serviert.

Aber nicht nur für Suchmaschinen sind SEF-URLs wichtig: Viele Leute trauen den Ziffernkolonnen nicht so ganz und klicken solche Links – zb in Foren, aber auch in SERPs (Suchmaschinen-Ergebnisseiten) nicht so gerne an. Bei einem Pfad ist schlichtweg sofort erahnbar, wie der Zusammenhang ist, während Parameter nichts aussagen.

Die Kehrseite der Medaille

Wird im obigen Beispiel zb die Seite "Obst" umbenannt, etwa zu "Früchte", ändern sich alle URLs der untergeordneten Seiten. Je nachdem, wie viele Seiten es gibt, kann das zum Fiasko führen: Links – auch aus Suchmaschinenseiten -  laufen ins Leere, das Suchmaschinen-Ranking könnte leiden. Bookmarks sind ungültig.

Bei bloßen Parametern würde das nicht passieren. Auch wenn das CMS intern eine hierarchische Struktur wie zb WB hat, würden durch verschieben/ändern von Seiten deren Pfad nicht beeinflusst.

Klarer Fall also: Wenn sich auf einer Site häufig Namen oder Zuordnungen ändern, sind SEF-URLs nicht mehr so ganz optimal. Hier könnte man gleich zu Beginn überlegen, ob man das WB-System nicht vielleicht aushebeln sollte.

Möglichkeiten:

1.) /index.php?pageid=12

Der Klassiker. Google hat übrigens keine Probleme mit solchen URLs, es heißt, dass Google erst ab 6 Parametern die Nase rümpft, neuerdings angeblich erst ab 9. Es gibt aber nicht nur Google, sondern auch Menschen, und die zählen die Parameter nicht ab; oft ist schon einer zuviel.

Die Implementierung scheint  einfach: Man bringt der index.php bei, auf den Parameter pageid zu hören und gibt  in showmenu2 statt [a] an: <a href="/index.php?pageid=[page_id]" ... >

Das funktioniert solange, bis kein Modul im Spiel ist, das selbst Seiten anlegt (News, Topics, Bakery), und: das selbst keine Parameter angibt, wie manche Bildergalerien.
In der Praxis ist also von dieser Variante nur abzuraten. Sie macht irgendwann Ärger.

2.) /seite-12.html

Ab hier ist URL-Rewiting mit der .htaccess angesagt.
"/seite-" und ".html" ist immer gleich, dazwischen steckt die Page-ID als Zahl. Mit dieser Regel konvertiert das gängige Servermodul "mod_rewrite" die eingehende Anfrage genau zu obigem Fall "/index.php?pageid=12", mit dem feinen Unterschied, dass allfällige weitere Parameter schlichtweg angehängt werden.

.htaccess-Regel:
RewriteEngine on
RewriteRule ^seite-([^/]+)\.html$ /index.php?pageid=$1 [L,QSA]

und in Showmenu2:
<a href="/seite-[page_id].html" ...> 

Allerdings ist die Variante nur halbherzig: Ein Blinder mit Krückstock erkennt, dass "12" hier die Seitennummer ist. Fraglich aber, wie schwer das wiegt, in der Praxis ist das wohl kaum ein Nachteil. 
 

3.) /bebus.html

Hier kommt keine Seitennummer mehr vor. Das Wort "bebus" könnte der nackte Filename der Seite sein, allerdings dürfen dann keine 2 Seiten gleich heißen. In meiner Template-Suche ist es zb schlichtweg der Name des Templates. In WB2.8 wird es wahrscheinlich frei verwendbare Felder für jede Seite geben, eines davon  kann natürlich ebenfalls verwendet werden.
Die entsprechende Regel in der .htaccess lautet (ungetestet):

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)\.html$ /index.php?name=$1 [L,QSA]

Dazu kommt in der index php eine Abfrage, ob eine Seite auf diesen Namen hört. Spätestens hier sind Sicherheitsaspekte zu beachten; vor allem auf SQL-Injection.

Schwierig wird hier die Anpassung des Menüs. Wer es wagt, kann direkt in Showmenu2 herumfrickeln und am besten ein eigenes Modul daraus machen, um sich spätere Verwechslungskomödien zu ersparen. Möglich - aber gefährlich - ist auch die Verwendung der Felder Menue-Title, Keywords usw.
Sicherer, aber stark  bremsend: im Template etwas wie
Ob_start() //Puffer ein
ShowMenu mit <a href="/XXX[page_id]XXX"> augeben.
Puffer in Variable
Alle page_ids und gewollten Dateinamen aus der Datenbank abfragen, XXX12XXX durch "richtige" Dateinamen ersetzen.

Ungelöst: Module

Im Prinzip verlassen sich alle Module darauf, dass WB wie gewohnt arbeitet. Wird am Gewohnten herumgebastelt, könnte sich Gemecker einstellen. Jedes neue Modul könnte eine Fehlerquelle darstellen, das Eis wird dünn. Ob man auch in einem Jahr noch so wachsam sein will?

Mischformen

Für .htaccess-Künstler bieten sich Varianten an, die mehrstufig arbeiten: Ist das Verzeichnis, die Datei vorhanden? Gilt eine weitere Regel?
Sowas kann schnell dazu führen, dass man mehr Zeit in die htaccess-Pflege investieren muss als in die eigentliche Seiten-Pflege. In jedem Fall gilt: Einen Spider verwenden und die Site immer wieder durcharbeiten lassen. Schnell ergibt sich irgendwo ein Loch, durch das Google oder andere die selbe Seite unter verschiedenen Namen finden: Der gefürchtete Duplicate Content.

In der Praxis

Normalerweise wird man die eingebauten "SEF"s von WebsiteBaker gerne und dankend annehmen und eben nicht allzu viel Namen ändern. Nur in bestimmten – überschaubaren – Fällen macht das Aushebeln Sinn: Wenn sich die Struktur oft und schnell ändern lassen soll, ohne die Links zu verlieren.
Dabei wird wohl die o.g. Variante 2: "/seite-12.html" die sinnvollste sein. Variante 3: "/bebus.html" macht nur Sinn, wenn a) das Feld bereits vorhanden ist und b) der Name eine Bedeutung hat, die in Suchmaschinen/von Menschen gefragt wird.

Case Studies:

Die Template-Suche

Bei websitebaker.at/templates wird der größte Teil über ein einziges Modul, nämlich die Template-Verwaltung gesteuert. Intern sind die Templates in Gruppen aufgeteilt, ich wollte diese Gruppe aber nicht im Dateinamen haben, um flexibel zu bleiben. Im Nachhinein eine richtige Entscheidung.
Da es kein klassisches Menü zu den Templates gibt, konnte ich also getrost und ohne Basteleien Variante 3 verwenden: /template-XXX.html – wobei XXX der Verzeichnisname des Templates ist. Das Feld ist also bereits vorhanden UND hat Bedeutung.

Das AMASP

Das AMASP wäre ebenso ein klassischer Fall. Die Module, die dort gelistet sind, sind oft nicht so eindeutig zuzuordnen: Listing, Gallerys,... viele Module sind Zwitter. Aber da aus den WB-Forum und von anderen Seiten sehr, sehr häufig auf das AMASP verlinkt wird, dürfen sich URLs insgesamt nicht ändern. Weiterleitungen für verschobene Seiten sind bei dieser Masse nicht machbar.
Wie bei den Templates wäre der gesuchte Name bereits vorhanden. Aber: Das AMASP hat ein Drop-Down Menü. Um dessen Funktionalität aufrecht zu erhalten, wäre ein neues Menü-Modul zwingend; die str_replace-Orgie im Template würde viel zu stark bremsen.
Ohne Menü-Basteleien bliebe also Variante 2: "/modul-12.html". Akzeptabel, aber nicht allzu knackig.

Hier sieht man bereits: SO klar ist die Entscheidung nicht, die Vor- und Nachteile halten sich selbst bei einer – auf den ersten Blick klaren – Situation die Waage. Bei allem Spass am Basteln: Die klassische Lösung ist meistens besser und macht weit weniger Stress.

Zurück

---

Kommentare:

01.09.2011

Stefek

Hallo Chio,
sehr interessanter Artikel.

Die Lösung 3.) /bebus.html gefällt mir natürlich am besten.
Eine Frage habe ich zu der Problematik mit Modulen:
sind es hier auch hauptsächlich die Module die ihrerseits /pages/ anlegen oder können bei allen möglichen Modulen Schwierigkeiten auftreten, wenn ja, wo sind die gröbsten Fallstricke?
Ich weiß, dieser Artikel ist bereits älter, aber grade jetzt brauche ich eine Lösung dieser Art.

Gruß,
Stefek

02.09.2011

Chio

Hallo Stefek,
Da gibt es im Forum glaube ich 1000e Threads dazu - wie man das Pages-Verzeichnis loswird.
Jeweils mit Vor- und Nachteilen.

Ich mache es meistens so, dass ich das pages-Verzeichnis auf leer setze, und ggf die obersten Ebenen von Hand anlege. Für diese Seiten bekommen die User dann eben keine Rechte.

02.09.2011

Stefek

Hallo Chio,

mir geht es viel mehr darum, die Seitenverzeichnisstruktur komplett los zu werden.
Also anstatt:
WB_URL.PAGES_DIRECTORY.'/ebene1/ebene2/ebene3.php
einfach nur:
WB_URL.'/der-seiten-titel-wie-in-der-db-geschrieben.php

Die Level komplett weg.

Wenn ich es richtig verstehe, tut 3.) /bebus.html genau das, theoretisch.

Dass keine doppelten Seitennamen entstehen, kann man beim Anlegen der Seite bzw. beim setzen des Dokumentnamens über eine Abfrage checken und notfalls ein pre-/suffix anhängen, bevor es ab in die DB geht.

Notfalls checke ich das mit den Modulen.
Hatte ich gestern einfach keine Zeit gehabt.

Weitere Hinweise zu der Modulproblematik sind willkommen.
Wenn ich das hier irgendwie hardgecodet hinkriege, mache ich auch gerne ein Admin Tool, um das ganze später einfacher zu verwalten.
Denn die Zusatzfelder wurden im 2.8.0 und auch bis heute leider nicht umgesetzt.

An sich habe ich kein Problem mit den extra angelegten Seiten im /pages Ordner.
Doch diese Struktur ist grade aus den in diesem Artikel beschriebenen gründen oft nicht empfehlenswert.

Gruß,
Stefek

03.09.2011

Stefek

Ruud made my day!

Eine sehr gute Lösung vom Miturheber der Droplets:
http://short.allwww.nl/

WB Intern fehlt nur noch die Möglichkeit, dass ein Feld bereitgestellt wird, dessen eingaben auf Einmalichkeit hin geprüft werden.
Wird mal Zeit, dass ich da selbst was für baue. °°