/pages/ aus url ausblenden

[Smax]

Hallo,

ich weiß dass es oft diskutiert und nachgefragt wird und ich habe mir dazu auch schon den ein oder anderen Thread angesehen konnte aber bisher keine, mich zufriedenstellende Antwort finden.

Mein Problem ist, dass ich das Verzeichnis pages in der url nicht anzeigen möchte um diese weiter zu optimieren und den besucher damit nicht zu verwirren. Wie ich anderen Threads entnehmen konnte, wäre eine Lösung, das Verzeichnis via FTP umzubennenen und das auch unter Optionen im WB-Backend zu machen. Funktioniert super, löst aber mein Problem einer kürzeren url nicht.
Ich möchte vermeiden, dass pages oder ein anderer Name für das Verzeichnis angezeigt wird.
Klappt das via modrewrite oder geht das mit WB tatsächlich nicht?
Wer kann helfen?

Vielen Dank

[Waldschwein]

Hallo!

Es gibt viele Möglichkeiten, das zu realisieren.

1.) Die Holzhammermethode.
Man löscht aus den Optionen "/pages" ganz heraus, und legt die (Placebo)-Dateien und Ordner im Root-Verzeichnis an.
Das Ganze wurde so auf der websitebaker2.org Seite realisiert - aber man sollte das nicht machen, wenn man Unterseiten von Seiten erstellt, die templates, modules usw. heißen. Sprich: Niemals auf einer Seite einsetzen, wo man keine Kontrolle drüber hat.

2.) Die mod_rewrite.

RewriteEngine On
RewriteBase /
RewriteRule ^pages/(.*)$ $1 [R=301,L]

Kann gehen, aber mod_rewrite alleine ist häufig problematisch.

3.) Die Elegante.
Ist hier (in Englisch) beschrieben: http://short.allwww.nl/
Letztendlich eine Kombination aus mod_rewrite, Droplet und PHP. Dabei verliert man aber auch die .php.

Aus Suchmaschinensicht ist es völlig schnuppe, ob html / php / gar nichts / pages...

Gruß Michael

[chio]

ich weiß dass es oft diskutiert und nachgefragt wird und ich habe mir dazu auch schon den ein oder anderen Thread angesehen konnte aber bisher keine, mich zufriedenstellende Antwort finden.

Dass du keine zufriedenstellende Antwort gefunden hast, liegt daran, dass die einzige zufriedenstellende Antwort für dich lauten würde: So gehts und es ist ganz einfach.
Ist es aber nicht.

Je nach Servereinstellungen gehts mal so, mal anders, mal gar nicht. Egal wie, es ist ein Konstrukt, über das du früher oder später fällst.
Und dann ist die Frage: Wozu? Für Suchmaschinen ist es egal. Besucher interessiert das überhaupt nicht. Es interessiert nur dich, weils dir gerade eingeschossen ist.

Ich nenne das /pages-Verzeichnis gerne mal /de oder /cms oder /wien oder sonstwas. Niemals /pages. Das reicht völlig.

[swurr]

Vielleicht eine Naive Frage am Rande:
Wieso stört dich das "page" ind der ULR?

Mit sonnigen Grüssen von der Kieler Förde
Sönke

[Smax]

Hallo,

vielen Dank für die zahlreichen Antworten, hätte nicht geacht, dass das Forum hier so belebt ist und auch so gut funktioniert.
Ich habe mehrere Seiten mittels WB realisiert und hatte am Wochenende eine SEO-Schulung in der es hieß, dass das keyword, auf das die einzelne Seite optimiert wird im besten fall auf in der url stehen sollte.
Allegemein finde ich eine zu lange URL nicht gerade schön, stelle aber eben auch fest, dass eine perfekte bzw. stabile Lösung des Problems nicht vorhanden ist denn wenn ich die files in das root-Verzeichnis schiebe, was passiert wenn ich eine neue Unterseite anlege? Wo wird diese dann angelegt?

Die Umbennenung des Verzeichnisses /pages in bspw. /cms oder vielleicht sogar in eine keywor wäre da besser?

Viele Dank nochmals

[chio]

Naja.
Eine Site, bei der das /pages Verzeichnis in /zelte umbenannt wurde, ist zumindest bei google.at mit diesem Begriff auf Platz 1.
Man muss aber sagen: Die Site war auch vor dem Relaunch mit WB gut aufgestellt; ein Wort allein reicht _nicht_.

[Waldschwein]

Hallo!

Also eine Umbenennung von /pages in /cms ist ziemlich sinnlos, weil Google cms aus einer URL noch eher rauslöscht (oder besser: nicht beachtet) als pages.
Du hast aber doch einen Suchbegriff in der URL - einfach einen sinnvollen Seitentitel wählen. Alternativ wäre eben Option 3 von Ruud ganz sinnvoll ( http://short.allwww.nl/ ).
Letztendlich gibt es aber nur drei Sachen, die für SEO wirklich Sinn machen: Inhalt, Inhalt und noch Links. Frage 9 Leute und bekomme 10 Meinungen, aber grundsätzlich habe ich hier einiges dazu geschrieben.
Interessant ist auch, dass z.B. gerade SEO-URL optimierte Foren (also forum.xyz/der-threadtitel anstatt forum.xyz/index.php?t=12345) in Suchmaschinen generell nach meiner Einschätzung auf hintereren Plätzen zu finden sind als die "kryptischen URLs".

Gruß Michael

[erpe]

stabile Lösung des Problems nicht vorhanden ist denn wenn ich die files in das root-Verzeichnis schiebe, was passiert wenn ich eine neue Unterseite anlege? Wo wird diese dann angelegt?

Das ist doch Unsinn.
So wie es oben beschrieben ist es stabil. Die neuen Seiten werden dann im WB_Root_Verzeichjni s angelegt. Deswegen ist die einzige "Schwäche" dieser Lösung, wenn du eine Seite (mit Unterseiten) anlegen willst, die so heisst wie ein vorhandener Ordner, z.B. Media, Admin, Templates etc...

hätte nicht geacht, dass das Forum hier so belebt ist und auch so gut funktioniert.

Bei deiner Anzahl an Posts hättest du das aber wissen können.

Gruss

erpe

[chio]

Also eine Umbenennung von /pages in /cms ist ziemlich sinnlos, weil Google cms aus einer URL noch eher rauslöscht (oder besser: nicht beachtet) als pages.

Naja - wenn ich auf das Wort "Pages" oder "CMS" optimiere
SO wahnsinnig wird aber keiner sein.

zu "ohne" /pages, also im Root: Das hängt vom Server ab, muss man einfach probieren. Oft geht es, sehr oft aber auch nicht. Wenn du eine größere Site betreibst, womöglich mit DAU-Kunden, dann kannst du dir irgendwann Ärger einhandeln. zB dann, wenn du den Provider wechselst, oder (gabs schon) der Provider schraubt nachträglich herum. Oder, oder...
In einem Jahr hast du plötzlich unerklärliche Effekte, und weißt gar nicht mehr, dass du das Verzeichnis entfernt hast. Dann such mal.
Mit /pages (oÄ) geht IMMER.
Du hast also keine/kaum Vorteile, aber eventuell ganz schön Probleme. Und wozu?

Ich habe EINIGE Sites ohne /pages, ein halbwegs guter Grund ist, dass bestehende Strukturen bei einem Relaunch bestehen bleiben sollen, weil ich sonst 1000e Redirects machen müsste.

Ein kleines Beispiel, wo es Ärger geben kann: Nach dem Login wird man auf /pages/index.php weitergeleitet. Ohne /pages ist das aber die Startseite. Das ist zunächst mal nicht schlimm, aber man kann mit der /pages/index.php allerhand basteln, was in der /index.php nicht ganz so easy ist. Oder die Startseite ist "anders", zb handgestrickt. Klar - auch das kann man alles in den Griff kriegen, aber: wofür?

Wenn ich keinen echten Grund habe (und die Länge der URLs ist KEIN Grund), dann lass ich WB so laufen, wie es gedacht ist und bastle nicht blöd herum.

[ChrusR]

Vorgeschichte: Hab bisher (seit 1996) die meisten selbstständig gemachten Webpages mit .shtml (d.h. Includes für Navi usw.) gemacht, und einige dynamische Bereiche per installierbarer PHP/mySQL-Skripts. An CMS's hat mich bis jetzt immer gestört, dass ich meine Sitemaps/Konzepte nicht 1 zu 1 übernehmen konnte und sie im erlernen bzw. auch im Bedienen für Dritte (Sinn eines CMS) zu aufwändig wurden. Bei WSB reizt es mich nun wirklich einen produktiven Test zu machen; ich bin schon stark in der Beta-phase für meine Bedürfnisse.

Ich bin a) ein Fan kurzer URLs für Menschen (Ansagen am Telefon, senden per Messenger/Handy, usw. - weinkeller.com/cabernet/) und b) muss ich einige gut eingeführte Seiten übernehmen (d.h. die URL's der Seiten sollen sich nicht ändern). Deshalb ist für mich eine dementsprechende Lösung für WSB fast schon ein Killerkriterium, obwohl mir alles andere sehr gut gefallen würde. Die Option 3 von Ruud funktioniert sehr gut (Danke Waldschwein). Sie wandelt die WSB-Systematik von z.B. "www.domain.de/pages/neue-seite.php" zu  "www.domain.de/neue-seite"; aber integriert leider nicht zusätzlich auch die Simulation eines Verzeichnisses "www.domain.de/neue-seite/". Dies wäre für mich nun sehr wichtig. Ich habe letzte Woche versucht den Autor Ruud zu kontakieren und hoffe noch auf Antwort. Vielleicht kann hier jemand einen Tipp geben oder ist in PHP derart bewandert, um mir bei einer Code-Änderung von "ShortUrl" weiterzuhelfen.

[chio]

Wenn es nur darum geht, kurze urls für den Einstieg anzubieten, kannst du ganz normal mit Weiterleitungen in der .htaccess arbeiten:
redirect 302 /e http://meinedomain/pages/irgendwas.php (in dem fall 302, weil ja "e" die richtige Seite ist)

Sobald jemand mal "drin" ist, setzt er sich ein Bookmark und fertig.

Du kannst auch mit einer str_replace-Orgie in der Index.php alle Links umbiegen.
Den access-files ist es egal, wo sie sind und wie sie heißen - solange der Pfad zur config.php stimmt. Du kannst sie auch kopieren und mehrfach haben. Du kannst sicher auch den server dazu bringen, Dateien ohne extension zu parsen bzw per modrewrite so zu tun als ob.  geht alles.

Dann hättest du am ende URLs wie domain.de/a (usw)
Jetzt noch eine 3-Buchstaben-Domain, kürzer gehts nicht. (könnte ich bei meiner ute.at mal probieren

Dann wäre es aber gleich besser, du machst das Menü fix ins Template; ändern kannst du sowieso nichts mehr.

[chio]

Ahja - noch eine möglichkeit, die geht sogar leichter:

Du nimmst einfach die page_id:
domain.de/12 per modrewrite umbiegen zu /index.php?page_id=12
Die index so ändern, dass die Page_id per GET akzeptiert wird.

Die Ausgabe von show_menu2 lässt sich problemlos so anpassen; wb->preprocess musst du im Core ändern.

Mit News/Bakery/Topics/diversen Bildergalerien funktionirt das so nicht mehr, da musst du halt verzichten oder weiterbasteln.

[ChrusR]

Danke für die Hinweise chio. Bei den bestehenden Web-Seiten (alle Seiten-URLs auf Directorys gelegt) wird wohl nur die Methode über .htaccess sinnvoll sein.
Ansonsten funktioniert "ShortUrl" von Autor Ruud eigentlich sehr gut. Dieser hat mir mittlerweile auch geantwortet und mitgeteilt, dass ich ev. Droplet-Änderungen usw. selbst integrieren muss (was ich mir nicht zutraue), da er ansonsten Probleme mit Admin-Verzeichnis usw. befürchtet.
Nunja: schade dass WSB mit seinem derzeitigen Seitenaufbau-Konzept hier an eine Grenze stosst. Aber es ist nunmal so und ich werde mich wohl entscheiden müssen.