nicht angemeldet
Rewrite Rule: Umleitung von .html/.htm auf .php
Hallo!
ich habe öfter Requests von alten Suchmaschineneinträgen auf meine index.html - Dateien, die inzwischen alles .php Dateien sind.
Da ich eine Rewrite Lösung mit Statuscode 301, also permanet verzogen, was die meisten Suchmaschienn verstehen sollten und Ihre Einträge daraufhin anpassen.
Die Frage jetzt wie ich das mache, ich dachte am besten über die .htaccess
ich würde am liebsten alle .htm und alle .html Dateien auf die index.php im Hauptverzeichnis umleiten. aber wie mache ich das?
RewriteEngine On
RewriteBase /
RewriteRule ^.*.html? /index.php [R=301,L]
Das funktioniert zwar oberflächlich, ich frager mich nur ob das auch optimal ist, da ich ja so auch einige 404er Fehler vereitele, und wie ist das mit Unterverzeichnissen? Bräuchte ich keine Rewrite Cond?
Viele Grüße
Andreas
-
Hi,
ich würde am liebsten alle .htm und alle .html Dateien auf die index.php im Hauptverzeichnis umleiten. aber wie mache ich das?
ähm, erlaube mir eine Frage: Warum willst Du, wenn der User HTML erwartet, ihn in die Irre führen und plötzlich behaupten, Du liefertest PHP-Code? Sprich: Warum konfigurierst Du Deinen Server nicht sinnvollerweise so, dass *.html nach PHP geparst wird, und benennst Deine Dateien entsprechend?
Das funktioniert zwar oberflächlich, ich frager mich nur ob das auch optimal ist, da ich ja so auch einige 404er Fehler vereitele, und wie ist das mit Unterverzeichnissen? Bräuchte ich keine Rewrite Cond?
Unter http://httpd.apache.org/docs/mod/mod_rewrite.html erfährst Du, wie man z.B. auf existierende Dateien prüft. Du solltest Dir aber dringend überlegen, ob Dein Vorhaben überhaupt Sinn macht.
Cheatah
-
Hallo Cheatah!
ähm, erlaube mir eine Frage: Warum willst Du, wenn der User HTML erwartet, ihn in die Irre führen und plötzlich behaupten, Du liefertest PHP-Code? Sprich: Warum konfigurierst Du Deinen Server nicht sinnvollerweise so, dass *.html nach PHP geparst wird, und benennst Deine Dateien entsprechend?
Also erstend will ich niemanden in dei Irre führen, ich will 2 Sachen erreichen:
1. Das user die über einen alten suchmaschienen-Eintrag kommen nicht auf eine 404er Seite landen,
2. das die Suchmaschinen Ihre Einträge aktualisieren.
Was mienst Du mit "nach PHP geparst"? meinst Du das ich html-Dateien parsen soll? Wäre kein Thema, aber das halte ich wiederum für den falschen weg. Außerdem existieren nunmal keine html-Dateien mehr, nur noch ein paar Einträge in Suchmaschinen auf die alte index.htmlm die es wie gesagt nicht mehr gibt, jetzt habe ich eine index.php als Startseite.Außerdem wird die Adresse ja auch umgeschrieben, halt mit der Angabe moved permanently.
Das funktioniert zwar oberflächlich, ich frager mich nur ob das auch optimal ist, da ich ja so auch einige 404er Fehler vereitele, und wie ist das mit Unterverzeichnissen? Bräuchte ich keine Rewrite Cond?
Unter http://httpd.apache.org/docs/mod/mod_rewrite.html erfährst Du, wie man z.B. auf existierende Dateien prüft. Du solltest Dir aber dringend überlegen, ob Dein Vorhaben überhaupt Sinn macht.
Aber was bring mir das? Ich habe definitiv kein einzige .htm oder .html-Datei mehr! Warum soll ich da noch prüfen?
Viele Grüße
Andreas-
Hi,
Also erstend will ich niemanden in dei Irre führen,
ich glaube Dir, dass Du diesen Fehler nicht vorsätzlich begehst, sondern einfach aus Unwissenheit.
Was mienst Du mit "nach PHP geparst"? meinst Du das ich html-Dateien parsen soll?
Das ist der einfachste Weg um zu erreichen, dass PHP-Dateien trotzdem über einen auf ".html" endenden Localpart in der URL erreichbar sind. Natürlich kannst Du serverseitig die Dateien weiterhin auf ".php" enden lassen, wenn es Deiner Organisation hilft, und den Server so konfigurieren, dass er diese Änderung selbsttätig findet.
Wäre kein Thema, aber das halte ich wiederum für den falschen weg.
Kommt darauf an, was Du als Ziel ansiehst.
Außerdem existieren nunmal keine html-Dateien mehr,
Das mag sein, allerdings sind es noch immer HTML-Ressourcen. Ich nehme zumindest nicht an, dass der User Deinen PHP-Code zu Gesicht bekommen soll, oder? :-)
nur noch ein paar Einträge in Suchmaschinen auf die alte index.htmlm die es wie gesagt nicht mehr gibt, jetzt habe ich eine index.php als Startseite.
Der Name ist falsch gewählt, ganz einfach. Wenn die Startseite - mindestens nach außen hin - noch immer index.html heißt, haben Du und Deine Besucher eigentlich nur gewonnen: die Suchmaschinen sind noch aktuell, HTML-Ressourcen werden nicht falsch benannt, alle Links bleiben korrekt usw.
Außerdem wird die Adresse ja auch umgeschrieben, halt mit der Angabe moved permanently.
Genau das ist es, was Du nicht tun sollst. "Good URIs don't change. People change them." (Tim Berners-Lee)
Insbesondere ist es sinnfrei, Anfragen auf _existierende_ Ressourcen (egal wie sie lokal heißen mögen) auf die Startseite umzulenken.
Ich habe definitiv kein einzige .htm oder .html-Datei mehr! Warum soll ich da noch prüfen?
Dann habe ich den Teil Deiner Frage, in dem es um 404er ging, missverstanden. Sorry.
Cheatah
-
Hi Cheatah!
Also erstend will ich niemanden in dei Irre führen,
ich glaube Dir, dass Du diesen Fehler nicht vorsätzlich begehst, sondern einfach aus Unwissenheit.Das weiß ich nicht. Daher auch dieser Thread um zu hinterfragen _ob_ meine Idee richtig war.
Was mienst Du mit "nach PHP geparst"? meinst Du das ich html-Dateien parsen soll?
Das ist der einfachste Weg um zu erreichen, dass PHP-Dateien trotzdem über einen auf ".html" endenden Localpart in der URL erreichbar sind. Natürlich kannst Du serverseitig die Dateien weiterhin auf ".php" enden lassen, wenn es Deiner Organisation hilft, und den Server so konfigurieren, dass er diese Änderung selbsttätig findet.
Also Du sagst ich soll nach außen hin gar kein .php ausgeben, sondern alles nur .htm? Serverseitig ist mir total wurst, da ich einfach auch .htm parsen kann, halt mit
AddType application/x-httpd-php .htm
Aber wie genau soll ich das Deiner Meinung nach machen?
RewriteRule ^(\w+).html? /$1.php [L]
sowas in der Art? Aber warum? Außerdem habe ich ja alle internen Links auf .php! Verstehe nicht ganz was das bringen soll?!
Außerdem existieren nunmal keine html-Dateien mehr,
Das mag sein, allerdings sind es noch immer HTML-Ressourcen. Ich nehme zumindest nicht an, dass der User Deinen PHP-Code zu Gesicht bekommen soll, oder? :-)
PHP gibt nunmal normalerweise HTML-Code aus, dafür ist es gemacht und das kann es gut und schnell. Natürlich bekommen die Leute den PHP-Code nicht zu Gesicht, aber ich verwende ein eArt eigene Templates, ich binde Navigation, Header, Footer und globale Varoablem/Funktionen in alle Seiten ein, so dass ich bestimmte Dinge zentral verändern kann, ich verstehe nicht ganz den Sinn das ich aus dynamischen Seiten statische Seiren vortäuschen soll?!
nur noch ein paar Einträge in Suchmaschinen auf die alte index.htmlm die es wie gesagt nicht mehr gibt, jetzt habe ich eine index.php als Startseite.
Der Name ist falsch gewählt, ganz einfach. Wenn die Startseite - mindestens nach außen hin - noch immer index.html heißt, haben Du und Deine Besucher eigentlich nur gewonnen: die Suchmaschinen sind noch aktuell, HTML-Ressourcen werden nicht falsch benannt, alle Links bleiben korrekt usw.
Also mit anderen Worten, in die htaccess ein
RewriteRule ^index.html? /index.php [L]Außerdem wird die Adresse ja auch umgeschrieben, halt mit der Angabe moved permanently.
Genau das ist es, was Du nicht tun sollst. "Good URIs don't change. People change them." (Tim Berners-Lee)
Naja, zumindest steht das so bei google: http://www.google.de/intl/de/remove.html#change_url
Insbesondere ist es sinnfrei, Anfragen auf _existierende_ Ressourcen (egal wie sie lokal heißen mögen) auf die Startseite umzulenken.
Das mache ich ja nicht! Die Seite ist komplett neu, alle Einträge ausser der Startseite haben keinen Sinn! Die verlinkten Recourcen existieren schlichtweg nicht mehr, und die ganzen Links von Suchmschinen, Katalogen, Foren... landen im leeren!
Viele Grüße
Andreas-
Aloha!
Insbesondere ist es sinnfrei, Anfragen auf _existierende_ Ressourcen (egal wie sie lokal heißen mögen) auf die Startseite umzulenken.
Das mache ich ja nicht! Die Seite ist komplett neu, alle Einträge ausser der Startseite haben keinen Sinn! Die verlinkten Recourcen existieren schlichtweg nicht mehr, und die ganzen Links von Suchmschinen, Katalogen, Foren... landen im leeren!Dann ist es rein logisch besser, den Besucher auf eine 404-Seite laufen zu lassen, die wie eine Content-Seite aussieht, den Benutzer darüber informiert, dass die Seite nicht mehr existiert, und empfiehlt, die Navigation zu benutzen, um zu den derzeit angebotenen Inhalten zu gelangen. Wenn der alte Inhalt nicht mehr existiert, dann wäre 301 logisch falsch und bringt den Besuchern nichts.
Wenn du 404 nicht willst, dann nimm 410 "Gone" als Rückmeldung für Anfragen auf alte, nicht mehr existierende URLs.
- Sven Rautenberg
-
Hi Sven!
Aloha!
bist Du immer noch im Urlaub, oder nur noch in Urlaubsstimmung? *g*
Insbesondere ist es sinnfrei, Anfragen auf _existierende_ Ressourcen (egal wie sie lokal heißen mögen) auf die Startseite umzulenken.
Das mache ich ja nicht! Die Seite ist komplett neu, alle Einträge ausser der Startseite haben keinen Sinn! Die verlinkten Recourcen existieren schlichtweg nicht mehr, und die ganzen Links von Suchmschinen, Katalogen, Foren... landen im leeren!Dann ist es rein logisch besser, den Besucher auf eine 404-Seite laufen zu lassen, die wie eine Content-Seite aussieht, den Benutzer darüber informiert, dass die Seite nicht mehr existiert, und empfiehlt, die Navigation zu benutzen, um zu den derzeit angebotenen Inhalten zu gelangen. Wenn der alte Inhalt nicht mehr existiert, dann wäre 301 logisch falsch und bringt den Besuchern nichts.
Ja, das sehe ich genau so, ich sagte ja das meien Lösung noch nicht das Optimum ist. Aber ich rede hauptsäcjhlich von der Startseite, und die Startseite ist zwar komplett neu, aber es ist im Prinzip noch derselbe Inhalt, halt aktualisiert und neu designt. Die Restliche Struktur der Seite ist komplett anders, daher sollte man in dem Fall auf eine Erklährende 404 Seite verweisen, mal schaun wie ich das genau mache.
Wenn du 404 nicht willst, dann nimm 410 "Gone" als Rückmeldung für Anfragen auf alte, nicht mehr existierende URLs.
Ich hab nichts gegen 404, im Gegenteil, ich will nur nicht das Leute von der Suchmaschine anstatt auf der Startseite auf der 404er Seite landen, auch wenn das nicht 100% logisch korrekt ist, da sehe ich eher meine Schwerpunkt bei der Usability! Was habe ich von der super-Logik wenn 20% der Besucher von Suchmschine XY nur eine Fehler sehen, nicht lesen... und weiter suchen...!
Grüße
Andreas-
Hi,
Die Seite ist komplett neu, alle Einträge ausser der Startseite haben keinen Sinn! Die verlinkten Recourcen existieren schlichtweg nicht mehr, und die ganzen Links von Suchmschinen, Katalogen, Foren... landen im leeren!
dazu ist 404 erfunden worden.
Aber ich rede hauptsäcjhlich von der Startseite, und die Startseite ist zwar komplett neu, aber es ist im Prinzip noch derselbe Inhalt, halt aktualisiert und neu designt.
Demnach ist es sinnvoll, die bisherige URL beizubehalten.
Wenn du 404 nicht willst, dann nimm 410 "Gone" als Rückmeldung für Anfragen auf alte, nicht mehr existierende URLs.
Ich hab nichts gegen 404, im Gegenteil, ich will nur nicht das Leute von der Suchmaschine anstatt auf der Startseite auf der 404er Seite landen,Das ist ein Widerspruch. Wenn der User eine bestimmte Ressource anfordert - und genau das passiert über Suchmaschinen - und diese existiert nicht mehr, dann ist ein 404 mehr als nur legitim. Es ist hingegen Unsinn, ihm statt dessen etwas völlig anderes zu präsentieren, was er gar nicht haben wollte - Deine Startseite beispielsweise. Idealerweise kannst Du eine _ähnliche_ andere Seite anbieten, aber keine willkürlich gewählte.
da sehe ich eher meine Schwerpunkt bei der Usability!
Und die liegt immer in der Antwort auf die Frage, was der User erwartet.
Was habe ich von der super-Logik wenn 20% der Besucher von Suchmschine XY nur eine Fehler sehen,
404-Seiten müssen nicht nach Fehler aussehen.
nicht lesen... und weiter suchen...!
Was hast Du davon, wenn sie auf Deiner Startseite nicht das finden, was sie gesucht haben, und frustriert von dannen ziehen?
Cheatah
-
Hallo!
Liest Du eigentlich das was ich schreibe? Du mischst hier 2 Themen!
Thema 1: Ich habe eine komplette Internetpräsenz von statischem .html auf dynamisches .php umgestellt, läuft jetzt Datenbankbasiert... die Struktur ist volkommen anders.
Thema 2: der Inhalt der Internetpräsenz ist im Prinzip derselbe gelblieben, halt ein paar Neuerungen, wie das nunmal auf Homepages so ist, oder sein sollte.
Ich sehe ein das es Schwachsinn ist alle Anfragen an eine .htm Datei auf die Startseite umzulenken, da wäre ein 404 mit entsprechender Meldung angebracht.
ABER:
Die Startseite, die von index.html auf index.php geändert wurde, einfach damit ich auch die global mit warten kann, warum soll ich jemanden die nicht mehr Aktuelle Seite vorgenen, wenn ich eine neue Version dieser Seite habe? Derjenige der auf index.html will will auf die Startseite, und die ist nunmal "moved permanently" auf index.php.Das finde ich sogar sehr viel logischer als 404! Wozu ist 302(oder wars 301?) sonst gedacht?
Wenn Leute über index.html über einen alten Suchmacheinen-Eintrag kommen wollen die auf meien Startseite, und nicht auf eine index.html
könnte auch eine dumme_startseite.asp sein, ist doch total egal, hauptsache die Leute landen wie geünscht auf der Startseite. Und wenn ich das der Suchmascheoin mit der hierfür vorhgesehenen Statuscode mitteile, ist doch alles OK, oder?
Gut, Du sagst da kommt html also muß es auch .html heißen. Es ist Ansichtssache. Außerdem kann ich Dir nicht zustimmen, dass es so wichtig für den Besucher ist, damit er sich die Adresse besser merken kann - ich habe mir noch nie eine komplette URL gemerkt habe, immer nur Domains, für den Rest gibt es ja Bookmarks!Die Seite ist komplett neu, alle Einträge ausser der Startseite haben keinen Sinn! Die verlinkten Recourcen existieren schlichtweg nicht mehr, und die ganzen Links von Suchmschinen, Katalogen, Foren... landen im leeren!
dazu ist 404 erfunden worden.
nein! 404 ist dazu da wenn eine Seite gar nicht mehr existiert, bei mir ist nur das umbenennen mit einem Update zusammengefallen, wenn ich das getrennt gemacht hätte hättest Du dann bei einem reinen umbenennen einem 302 zugestimmt?
Aber ich rede hauptsäcjhlich von der Startseite, und die Startseite ist zwar komplett neu, aber es ist im Prinzip noch derselbe Inhalt, halt aktualisiert und neu designt.
Das ist ein Widerspruch. Wenn der User eine bestimmte Ressource anfordert - und genau das passiert über Suchmaschinen - und diese existiert nicht mehr, dann ist ein 404 mehr als nur legitim. Es ist hingegen Unsinn, ihm statt dessen etwas völlig anderes zu präsentieren, was er gar nicht haben wollte - Deine Startseite beispielsweise. Idealerweise kannst Du eine _ähnliche_ andere Seite anbieten, aber keine willkürlich gewählte.
da sehe ich eher meine Schwerpunkt bei der Usability!
Und die liegt immer in der Antwort auf die Frage, was der User erwartet.
Wenigstens auf der index.html erwartet er eine Startseite! Und dann soll er doch lieber auf dee neue Startseite geleitet weren, also auf eine 404er Seite "Hallo! es gibt jetzt einen neue Startseite..." welchen informationsgehalt hat das für einen Besucher der über ein Suchmaschine kommt?
Was habe ich von der super-Logik wenn 20% der Besucher von Suchmschine XY nur eine Fehler sehen,
404-Seiten müssen nicht nach Fehler aussehen.
nicht lesen... und weiter suchen...!
Was hast Du davon, wenn sie auf Deiner Startseite nicht das finden, was sie gesucht haben, und frustriert von dannen ziehen?
Meine Güte, hast DU noch nie ein Update Deienr Seir gemacht? Das wäre so als wenn jemadn noch einen Alten Link auf Selfhtml7 hätte, sieht dann selfhtml8 und denkt sich: Schade, gibts wohl nicht mehr, muß ich wohl weiter mit Frontpage arbeiten...
Grüße
Andreas-
Moin!
Was hast Du davon, wenn sie auf Deiner Startseite nicht das finden, was sie gesucht haben, und frustriert von dannen ziehen?
Meine Güte, hast DU noch nie ein Update Deienr Seir gemacht? Das wäre so als wenn jemadn noch einen Alten Link auf Selfhtml7 hätte, sieht dann selfhtml8 und denkt sich: Schade, gibts wohl nicht mehr, muß ich wohl weiter mit Frontpage arbeiten...Schlechtes Beispiel, denn: Gerade im Self-Raum ist eine große Anstrengung gemacht worden, Links auf die alten SelfHTML7-Seiten per Redirect auf die inhaltlich identischen (oder annähernd identischen) SelfHTML8-Seiten umzuleiten. Dies ist außerdem mit einer Umstrukturierung des Servers zusammengefallen, so dass SelfHTML jetzt nicht mehr unter http://www.teamone.de/selfhtml/ liegt, sondern unter http://selfhtml.teamone.de/ - der Redirect funktioniert aber noch, die alten Links sind weiterhin funktionsfähig. Gleiches ist auch mit allen anderen Bereichen (SelfAktuell etc.) geschehen.
Mit anderen Worten: Die alten URLs sind erhalten geblieben.
Dasselbe solltest du versuchen: Wenn die Inhalte geblieben sind, dann musst du eben ein Schema zusammenstellen, welches alte und neue URLs gegenüberstellt und die alten URLs direkt auf die neuen URLs umleitet. Das kann wahlweise mit Redirects geschehen (bei SelfHTML war's nicht anders möglich, da die Subdomain wechselt - und als Zukunftsplanung bei noch mehr Traffic und Andrang durch die Subdomains leichter ein Server pro Subdomain eingesetzt werden kann), oder durch URL-Rewriting (d.h. dein URL-Schema bleibt bestehen, deine Links (auch auf deinen eigenen Seiten) bleiben bestehen, aber durch Rewriting wird statt statischer Seiten ein PHP-Skript angesprochen, welches die gewünschten Inhalte aus der Datenbank holt.
Letzere Vorgehensweise ist ideal, solange die Struktur der angebotenen Informationen sich nicht ändert. Sie bietet sogar große Vorteile: Es werden nur ganz normale URLs ohne Parameter verwenden, welche von allen Suchmaschinen indiziert werden. Parameter in URLs hingegen werden nicht von allen Suchmaschinen akzeptiert. Durch die unterschiedlichen Schemata URL (nach außen) und Parameter (nach innen) kann man wieder ein Stückchen weiter Content von Technik trennen. HTML hat sich zu HTML+CSS entwickelt, um Content von Technik zu trennen. Die Trennung von URL und Skript ist ein weiterer, konsequenter Schritt. Die URL beschreibt den logischen Ort der Information - ihr logischer Inhalt ist in (X)HTML beschrieben. URL-Rewriting macht aus dem logischen Ort einen physikalischen (Skript und Datenbankparameter), und CSS macht aus den logischen Inhalten physikalische Darstellung (Schriftart, -formatierung, Sprachausgabe, etc.).
- Sven Rautenberg
-
Hi Sven!
Naja, hast es wohl doch wieder geschafft mich zu überzeugen ;-)
Vorab: Das mit "ohne Endung" finde ich im Prinzip gut, aber was sagst Du dazu das das einioge user als Verzeichnis ansehen könnten und einen / dahinter setzen?Dasselbe solltest du versuchen: Wenn die Inhalte geblieben sind, dann musst du eben ein Schema zusammenstellen, welches alte und neue URLs gegenüberstellt und die alten URLs direkt auf die neuen URLs umleitet. Das kann wahlweise mit Redirects geschehen (bei SelfHTML war's nicht anders möglich, da die Subdomain wechselt - und als Zukunftsplanung bei noch mehr Traffic und Andrang durch die Subdomains leichter ein Server pro Subdomain eingesetzt werden kann), oder durch URL-Rewriting (d.h. dein URL-Schema bleibt bestehen, deine Links (auch auf deinen eigenen Seiten) bleiben bestehen, aber durch Rewriting wird statt statischer Seiten ein PHP-Skript angesprochen, welches die gewünschten Inhalte aus der Datenbank holt.
Aber wie soll ich denn die Parameter verstecken? Zum einen verwende ich die SessionID als Parameter in der URL, keine Cookies, und auch die anderen Parameter, wenn ich eine Seite produkt_details.php habe, auf der 1000de verschiedene Produkte mit Parameter ?id=12345 angezeigt werden, wie soll ich dann diesen Parameter übergeben? Ich bräucte ja einn Link auf produkt_details.html, aber wie soll dann das richtige Produkt angezeigt werden, wenn ich keinen Parameter übergebe?
Was hälst Du davon tatsächlich statische html-Seiten zu generieren, mit der Ausgabesteuerung in php, halt sowas der Art, prüfen ob die .html neuer ist als die entsprechende .php dann die .html ausgeben, sonst eben ein PERL-Script starten welches diese Datei neu erstellt. Vielleicht dazu noch dasselbe mit gzip, und entsprechend wenn möglich gz, sonst html, und wenn zu alt einfach die Ausgabe des PHP-Scriptes schicken, und gleichzeitig die html und gz erstellen. Bleibt aber das Problem mit den notwendigen Parametern. Oder ich bringe die PArameter als Verzeichnisse in der URL unter, aber dann habe uich das Problem mit relativen Links, heißt ich muß überall aabsolute Lonks verwenden, naja, mal schaun
Grüße
Andreas-
Moin!
Naja, hast es wohl doch wieder geschafft mich zu überzeugen ;-)
Vorab: Das mit "ohne Endung" finde ich im Prinzip gut, aber was sagst Du dazu das das einioge user als Verzeichnis ansehen könnten und einen / dahinter setzen?Die sind dann doof. Aber mal ehrlich: Wie häufig gibst du direkte Deep-Links in die URL-Zeile ein? Dumme User geben die Domain ein und klicken sich durch. :)
Aber wie soll ich denn die Parameter verstecken? Zum einen verwende ich die SessionID als Parameter in der URL, keine Cookies, und auch die anderen Parameter, wenn ich eine Seite produkt_details.php habe, auf der 1000de verschiedene Produkte mit Parameter ?id=12345 angezeigt werden, wie soll ich dann diesen Parameter übergeben? Ich bräucte ja einn Link auf produkt_details.html, aber wie soll dann das richtige Produkt angezeigt werden, wenn ich keinen Parameter übergebe?
Mit URL-Rewriting ist viel möglich. Überlege dir zunächst, welche URL-Struktur ohne Parameter du haben willst. Die Session-ID läßt sich dabei durchaus als Parameter mitschleifen (und sollte primär als Cookie gespeichert werden, da sie nicht in die Pfadbezeichnung gehört).
Was hälst Du davon tatsächlich statische html-Seiten zu generieren, mit der Ausgabesteuerung in php, halt sowas der Art, prüfen ob die .html neuer ist als die entsprechende .php dann die .html ausgeben, sonst eben ein PERL-Script starten welches diese Datei neu erstellt. Vielleicht dazu noch dasselbe mit gzip, und entsprechend wenn möglich gz, sonst html, und wenn zu alt einfach die Ausgabe des PHP-Scriptes schicken, und gleichzeitig die html und gz erstellen.
Eine gute Idee, die ziemlich viel Server-Last einsparen kann, wenn man sie korrekt durchführt. Die Prüfung auf Aktualität sollte nicht allzu aufwendig sein - eventuell werden die HTML-Seiten gleich dann generiert, wenn Veränderungen in den Daten auftreten.
Bleibt aber das Problem mit den notwendigen Parametern. Oder ich bringe die PArameter als Verzeichnisse in der URL unter, aber dann habe uich das Problem mit relativen Links, heißt ich muß überall aabsolute Lonks verwenden, naja, mal schaun
Absolute Links sind durchaus nicht böse, sondern manchmal (z.B. Hintergrundbildeinbindung in einer externen CSS-Datei) zwingend notwendig. Und auch bei der Nutzung von Templates sind sie sehr erleichternd.
- Sven Rautenberg
-
-
-
-
-
-
-
-
-
-
Hallo Cheatah,
ähm, erlaube mir eine Frage: Warum willst Du, wenn der User HTML erwartet, ihn in die Irre führen und plötzlich behaupten, Du liefertest PHP-Code? Sprich: Warum konfigurierst Du Deinen Server nicht sinnvollerweise so, dass *.html nach PHP geparst wird, und benennst Deine Dateien entsprechend?
Wir hatten das vor ein paar Tagen ja schon mal, und ich dachte, die Antwort von Michael Schröpl wäre befriedigend gewesen. Aber nachdem das jetzt wieder auftaucht: warum bestehst Du bitte darauf, daß Dateien mit dem Mime-Type html auch die Endung .html haben müssen? Für die Darstellung von php-source (in der besten aller Welten)ist .phps vorgesehen, .php wäre nach Deiner Argumentation schlicht überflüssig. Schließlich gibt es den "Content-Type"-header, die Dateiendung ist da einfach irrelevant.
Wenn man Apache so konfiguriert, daß er .html Dateien grundsätzlich durch den php-parser schickt, was macht man nach diesem Schema bitte z.B. mit .pl, .asp usw. Seiten, auch in .html umbennen? Den Apache die Dateien dann durch alle Interpreter nacheinander schicken lassen? (Geht normalerweise leider nicht wirklicht gut...)Wäre es nicht sinnvoller, den Dateien ihre Endung zu belassen, die dem Server sagt, durch welches Programm er die Dateien zu interpretieren hat, und mit mod_rewrite "normale" urls zu erzeugen (auf die auch verlinkt wird), z.B. so:
RewriteEngine On
RewriteRule ^page_(.*).html$ index.php?content=$1 [T=application/x-httpd-php,QSA]Viele Grüße
Stephan-
Aloha!
Wäre es nicht sinnvoller, den Dateien ihre Endung zu belassen, die dem Server sagt, durch welches Programm er die Dateien zu interpretieren hat, und mit mod_rewrite "normale" urls zu erzeugen (auf die auch verlinkt wird), z.B. so:
RewriteEngine On
RewriteRule ^page_(.*).html$ index.php?content=$1 [T=application/x-httpd-php,QSA]Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Derzeit ist HTML noch "in". Demnächst haben wir XHTML. Gemäß der Prämisse "Content-Type steht in der Dateiendung" müßte man dann alle URLs wieder umstellen, wenn man seine Seiten auf XHTML umstellt - und alle URLs ändern sich wieder.
Warum nicht einfach auf "http://www.example.com/index" verlinken, und dann den Server entscheiden lassen, welche der möglicherweise mehreren Index-Seiten er ausliefert? Dann kann man ganz einfach wahlweise index.html, index.xhtml oder index.php auf dem Server ablegen, und es wird mit Content-Negotiation immer die richtige Seite ausgeliefert. Das System läßt sich noch ausbauen, indem man auch .gz-Dateien (um komprimierte Dateiversionen auszuliefern) auf den Server packt, oder ".de", ".en" und ".ru"-Dateien, um mehrere Sprachversionen je nach Browsereinstellung auszuliefern.
Auf die Spitze getrieben:
index.de.html
index.de.html.gz
index.en.xhtml
index.en.html.gz
index.ru.php
index.ru.html.gz
-> Je nach Browser-Request wird die richtige Datei ausgeliefert. :)- Sven Rautenberg
-
Hi!
Wäre es nicht sinnvoller, den Dateien ihre Endung zu belassen, die dem Server sagt, durch welches Programm er die Dateien zu interpretieren hat, und mit mod_rewrite "normale" urls zu erzeugen (auf die auch verlinkt wird), z.B. so:
RewriteEngine On
RewriteRule ^page_(.*).html$ index.php?content=$1 [T=application/x-httpd-php,QSA]Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Und das gibt auch keine Probleme? ich meine weil win normaler ein großer Fan der Endungen ist!
Derzeit ist HTML noch "in". Demnächst haben wir XHTML. Gemäß der Prämisse "Content-Type steht in der Dateiendung" müßte man dann alle URLs wieder umstellen, wenn man seine Seiten auf XHTML umstellt - und alle URLs ändern sich wieder.
Haben wir dann kein selfhtml mehr sondern nur noch selfxhtml? ich weiß nicht ob der Einfluß von Xhtml so weit geht. Es reicht doch der doctype, oder? Die Endung ist doch egal, und es ist und bleibt html!
Warum nicht einfach auf "http://www.example.com/index" verlinken, und dann den Server entscheiden lassen, welche der möglicherweise mehreren Index-Seiten er ausliefert?
Nun, das setzt einiges an serverseitiger Technologie und Wissen voraus! Außerdem dürfte das einiges an Recourcen fressen - und wofür?
Dann kann man ganz einfach wahlweise index.html, index.xhtml oder index.php auf dem Server ablegen, und es wird mit Content-Negotiation immer die richtige Seite ausgeliefert.
Was hat das für einen Sinn??? Sicher, technisch eine Meisterleistung - aber wofür? Um ein paar Freaks zu beeindrucken?
Was bitte hat der Browser damit zu tun ob der Server .html oder .php auslieferst? Den interessiert doch eh nur die Ausgabe! Und auch xhtml/html, xhtml wird doch in allen Browsern angezeigt, wozu dann noch html? für die paar NN4.7er? und dafür so viel Aufwand? Danke nein - für sowas bestimmt nicht!Das System läßt sich noch ausbauen,
man sollte nur nicht mit Kanonen auf Spatzen schießen!
indem man auch .gz-Dateien (um komprimierte Dateiversionen auszuliefern) auf den Server packt,
OK, das ist wirklich sinnvoll!
oder ".de", ".en" und ".ru"-Dateien, um mehrere Sprachversionen je nach Browsereinstellung auszuliefern.
Das ist wieder so eine Sache, was wenn jemand eine andere Sprache will, z.B. in seinem Browser englisch eingestellt und will deutsch - mmuß er erst seine Browsereinstellungen ändern um die Seite in deutsch zu sehen, das nenne ich mal benutzerfreundlich - lernt er direkt was bei, zumindest 1 von 100, die anderen sind weg!
Die Sprache muß entweder über session, cookie oder url übergeben werden, jede andere Lösung ist Quatsch. Stellt sich die Frage an welcher Stelle man das dann prüft? Session ginge wohl nur in PHP etc., URL ginge noch über htaccess, cookies - auch glaube ich. Die Browser-Einstellung hat evtl. Sinn für die default Einstellung!Auf die Spitze getrieben:
index.de.html
index.de.html.gz
index.en.xhtml
index.en.html.gz
index.ru.php
index.ru.html.gz
-> Je nach Browser-Request wird die richtige Datei ausgeliefert. :)Im Prinzip hast Du schon Recht, aber praktisch?
Grüße
Andreas-
Hi,
Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Und das gibt auch keine Probleme? ich meine weil win normaler ein großer Fan der Endungen ist!der Browser ist, trotz anderslautender Meinungen, nicht Windows. Im Gegenteil ist es sogar _wegen_ dieses Umstandes sinnvoll, auf Dateiendungen zu verzichten: damit wird nämlich wenigstens eine Quelle des IE-Fehlverhaltens in HTTP eliminiert.
Haben wir dann kein selfhtml mehr sondern nur noch selfxhtml?
Ich glaube, SelfHTML ist mittlerweile mehr als nur die Summe seiner Buchstaben :-)
ich weiß nicht ob der Einfluß von Xhtml so weit geht. Es reicht doch der doctype, oder?
Der Doctype gibt an, welche Ausprägung des im Content-Type gelieferten Typs vorliegt. Aus Browsersicht sollte in allererster Linie der Content-Type reichen - ob HTML oder XHTML kann er dann prinzipiell raten. Zumindest momentan, denn mit wachsender XML-Relevanz steigt auch die Bedeutung des Doctypes allgemein.
Die Endung ist doch egal, und es ist und bleibt html!
Ja, die Endung ist egal. Sie ist nur für den Menschen interessant, der vor dem Rechner sitzt, sich die URL merken will, sie in seiner Location-Zeile wiedererkennen will usw. Insbesondere heißt das, dass ein Mensch von der Endung auf das schließen können soll, was ihn erwartet - und überstrapazieren sollte man sein Gedächtnis auch nicht, indem man unterschiedlichste Endungen für die selbe Art der Daten wählt.
Warum nicht einfach auf "http://www.example.com/index" verlinken, und dann den Server entscheiden lassen, welche der möglicherweise mehreren Index-Seiten er ausliefert?
Nun, das setzt einiges an serverseitiger Technologie und Wissen voraus!Und?
Ich halte es hier eher für ungünstig, dass es wie ein Verzeichnis aussieht, aber keine ist - ich würde instinktiv einen Slash dahintersetzen, um einen Roundtrip vorwegzunehmen.
Außerdem dürfte das einiges an Recourcen fressen - und wofür?
Nö, wieso sollte es? Content-Negotiation ist ein sehr effizienter Vorgang; und wenn man das nicht braucht, kann man genauso gut seine "index.html" oder "index.php" schlicht und ergreifend in "index" umbenennen. Den richtigen Type hierfür zu definieren sollte nicht das Thema sein.
Dann kann man ganz einfach wahlweise index.html, index.xhtml oder index.php auf dem Server ablegen, und es wird mit Content-Negotiation immer die richtige Seite ausgeliefert.
Was hat das für einen Sinn???Organisation. Es gibt zwei Seiten: Besitzer und Nutzer.
Sicher, technisch eine Meisterleistung - aber wofür? Um ein paar Freaks zu beeindrucken?
Die Freaks wären die Benutzer, und die kriegen davon gar nichts mit. Der Besitzer ist es, der die Dateien editiert, und für den eine solche Endung eher eine Bedeutung hat. Deswegen spricht auch nichts dagegen, eine Datei "bla.php" zu nennen, sofern die von ihr erzeugte Ressource in der URL "bla.html" (oder "bla") heißt; text/html als Rückgabe mal vorausgesetzt.
Was bitte hat der Browser damit zu tun ob der Server .html oder .php auslieferst?
Nichts. Warum will man dem Browser also eben diese Angabe aufzwingen?
xhtml wird doch in allen Browsern angezeigt, wozu dann noch html?
Man kann, wenn man will, XHTML als XML-kompatible Variante von HTML ansehen. Ich halte es nicht für falsch, XHTML-Ressourcen auf ".html" zu benamsen - eben _weil_ jeder HTML-Client damit zurechtkommen sollte.
Das System läßt sich noch ausbauen,
man sollte nur nicht mit Kanonen auf Spatzen schießen!Da ist keine Kanone. Im Gegenteil - das n-schneideige Messer, welches Du bisher kanntest, wird sogar entfernt.
indem man auch .gz-Dateien (um komprimierte Dateiversionen auszuliefern) auf den Server packt,
OK, das ist wirklich sinnvoll!Naja, das würde ich eigentlich über mod_gzip handhaben, nicht über zusätzliche Dateien.
oder ".de", ".en" und ".ru"-Dateien, um mehrere Sprachversionen je nach Browsereinstellung auszuliefern.
Das ist wieder so eine Sache, was wenn jemand eine andere Sprache will, z.B. in seinem Browser englisch eingestellt und will deutsch - mmuß er erst seine Browsereinstellungen ändern um die Seite in deutsch zu sehen, das nenne ich mal benutzerfreundlich - lernt er direkt was bei, zumindest 1 von 100, die anderen sind weg!Ähm, ich glaube, Du hast Content-Negotiation noch nicht wirklich verstanden. Es ist ein leichtes, von der englischen auf die deutsche Variante zu verlinken. Die Negotiation dient dazu, eine sinnvolle Vorauswahl zu treffen.
Die Sprache muß entweder über session, cookie oder url übergeben werden,
Unsinn. Das sind ziemlich genau die übelsten Workarounds, die von Leuten gebaut werden, welche den Begriff "Serverkonfiguration" entweder nicht kennen oder für etwas böses[tm] halten.
Stellt sich die Frage an welcher Stelle man das dann prüft?
Der Server macht das. Ganz nebenbei. Du brauchst es nur einmal einzustellen, und es läuft auf ewig von allein, ohne Dein Zutun, ohne dass Du etwas merkst, ohne dass Du neben den richtig gewählten Dateinamen noch etwas zu beachten hast. Ohne Programmcode. Ohne Ressourcenfresser. Ohne dem Client noch irgendwas zusätzliches abzuverlangen.
Die Browser-Einstellung hat evtl. Sinn für die default Einstellung!
Exakt. Und um die zu umgehen, braucht es _keinen_ Aufwand, wenn du Content-Negotiation einsetzt.
-> Je nach Browser-Request wird die richtige Datei ausgeliefert. :)
Im Prinzip hast Du schon Recht, aber praktisch?Praktisch wird das sehr häufig so gemacht.
Cheatah
-
Aloha!
Fein, eine Grundsatzdiskussion über URLs entsteht. :)
Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Und das gibt auch keine Probleme? ich meine weil win normaler ein großer Fan der Endungen ist!Nein, das gibt keine Probleme. Im Internet sind die Mime-Typen entscheidend für die Bedeutung einer Ressource, nicht irgendwelche Endungen. Deshalb kann man z.B. dynamisch CSS-Dateien mit PHP generieren, die man mit <link href="dyncss.php" rel="stylesheet"...> einbindet - solange der Mime-Typ stimmt, ist alles in Butter.
Derzeit ist HTML noch "in". Demnächst haben wir XHTML. Gemäß der Prämisse "Content-Type steht in der Dateiendung" müßte man dann alle URLs wieder umstellen, wenn man seine Seiten auf XHTML umstellt - und alle URLs ändern sich wieder.
Haben wir dann kein selfhtml mehr sondern nur noch selfxhtml? ich weiß nicht ob der Einfluß von Xhtml so weit geht. Es reicht doch der doctype, oder? Die Endung ist doch egal, und es ist und bleibt html!Eben: Die Endung ist egal - deshalb kann man in der _URL_ ganz auf sie verzichten und den Server automatisch die derzeit vorhandene Ressource ausliefern lassen, die zum Request paßt. Wird "index" angefordert, und existiert "index.html", dann kriegt man die statische Index-Seite. Wird "impressum" angefordert, und existiert "impressum.php", wird eine generierte Seite ausgeliefert. Fordert man "news" an, und existiert news.jsp, läuft es ganz genauso.
Wird in einer neuen Seitenversion von PHP auf JSP umgestiegen, ändern sich die URLs _nicht_. Das bedeutet: Alle Suchmaschineneinträge sind weiterhin gültig, alle Bookmarks (ziemlich wichtig, weil die nicht automatisch auf Aktualität geprüft werden) sind weiterhin gültig, alle Links auf anderen Seiten bleiben gültig - und dennoch kann man die zugrundeliegende Technik ganz den eigenen Erfordernissen anpassen.
Warum nicht einfach auf "http://www.example.com/index" verlinken, und dann den Server entscheiden lassen, welche der möglicherweise mehreren Index-Seiten er ausliefert?
Nun, das setzt einiges an serverseitiger Technologie und Wissen voraus! Außerdem dürfte das einiges an Recourcen fressen - und wofür?Ja, das Wissen ist erforderlich - beim Admin und Webmaster des Servers. Das sollten aber Fachleute sein, und sie sollten wissen, was sie tun. Es ist unter anderem Aufgabe dieses Forums, das Wissen breiter zu streuen und den Menschen die Möglchkeiten ihres Servers näherzubringen.
Was die Performance angeht: Puretec hat mod_speling aktiv - damit wird _ein_ Tippfehler in der URL korrigiert. Das kostet mit Sicherheit mehr Performance (weil eben alle Möglichkeiten ausprobiert werden müssen: Ist ein Buchstabe zuviel oder zuwenig, ist einer groß statt klein oder umgekehrt, wo in der URL ist er falsch?) als das Durchsuchen eines konkret benannten Verzeichnisses nach passenden Dateien.
Dann kann man ganz einfach wahlweise index.html, index.xhtml oder index.php auf dem Server ablegen, und es wird mit Content-Negotiation immer die richtige Seite ausgeliefert.
Was hat das für einen Sinn??? Sicher, technisch eine Meisterleistung - aber wofür? Um ein paar Freaks zu beeindrucken?Es macht natürlich keinen Sinn, diese Seiten _gleichzeitig_ auf dem Server zu haben. Aber wenn man ohne Konsequenzen für die Außenwelt von .html zu .xhtml oder zu .php wechseln kann, und sich auch intern die Links _nicht_ ändern, dann ist damit sehr viel gewonnen! Denn gerade bei umfangreichen Projekten mit vielen Seiten ist es eher möglich, schrittweise eine Technik umzustellen, als es auf einen Schlag zu tun. Bzw. es ist manchmal gar nicht wünschenswert, gewisse Teilprojekte umzustellen - aber die dort verwendeten Links zu anderen Teilprojekten bleiben ein Serverleben lang gültig - egal, was sich ändert. So sollte es jedenfalls sein.
Was bitte hat der Browser damit zu tun ob der Server .html oder .php auslieferst? Den interessiert doch eh nur die Ausgabe! Und auch xhtml/html, xhtml wird doch in allen Browsern angezeigt, wozu dann noch html? für die paar NN4.7er? und dafür so viel Aufwand? Danke nein - für sowas bestimmt nicht!
Eben: Den Browser interessiert die Dateiendung nicht, den (und seinen Benutzer) interessiert nur, dass die URL gefunden wird.
Das System läßt sich noch ausbauen,
man sollte nur nicht mit Kanonen auf Spatzen schießen!indem man auch .gz-Dateien (um komprimierte Dateiversionen auszuliefern) auf den Server packt,
OK, das ist wirklich sinnvoll!Eben. Reduziere das System nicht auf einen kleinen Teilaspekt.
oder ".de", ".en" und ".ru"-Dateien, um mehrere Sprachversionen je nach Browsereinstellung auszuliefern.
Das ist wieder so eine Sache, was wenn jemand eine andere Sprache will, z.B. in seinem Browser englisch eingestellt und will deutsch - mmuß er erst seine Browsereinstellungen ändern um die Seite in deutsch zu sehen, das nenne ich mal benutzerfreundlich - lernt er direkt was bei, zumindest 1 von 100, die anderen sind weg!
Die Sprache muß entweder über session, cookie oder url übergeben werden, jede andere Lösung ist Quatsch. Stellt sich die Frage an welcher Stelle man das dann prüft? Session ginge wohl nur in PHP etc., URL ginge noch über htaccess, cookies - auch glaube ich. Die Browser-Einstellung hat evtl. Sinn für die default Einstellung!Nein, diese Variante ist keinesfalls Quatsch. Was ist denn mit der ersten Seite, die abgerufen wird? Die hat eine Standard-Sprache - warum nicht durch Content-Negotiation gleich die vom Browser präferierte Sprache ausliefern? Ok, damit kann man falsch liegen, aber diese Vorauswahl läßt sich durchaus rückgängig machen.
Es stimmt: Wenn man die Sprache auf jeder Seite nur mit Content-Negotiation ausliefert, kann der Benutzer nicht frei wählen. Meine bevorzugte Vorgehensweise ist, die Startseite aushandeln zu lassen, alle Links auf weitere Seiten in einem Sprachunterverzeichnis zeigen zu lassen und die Sprachauswahl-Links auf die anderen angebotenen Sprachen zu setzen. So liefert man für viele Benutzer die richtige Seite aus, und die paar Benutzer, die gerne chinesisch hätten, aber in Italien an einem englischen Browser sitzen, der zuletzt deutsche Sprache eingestellt bekommen hat, werden eben auch glücklich. In der Summe werden aber mehr Benutzer sofort glücklich.
Auf die Spitze getrieben:
index.de.html
index.de.html.gz
index.en.xhtml
index.en.html.gz
index.ru.php
index.ru.html.gz
-> Je nach Browser-Request wird die richtige Datei ausgeliefert. :)
Im Prinzip hast Du schon Recht, aber praktisch?Praktisch habe ich auch Recht. ;)
- Sven Rautenberg
-
-
Hallo Sven,
Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Das geht aber leider (falls man mehr als eine Seite haben will ;-)), nur, indem man Unterseiten als Verzeichnisbaum abbildet, also http://www.irgendwas.de/bereich1/unterbereich2/. Rein theoretisch hätte ich damit auch kein Problem, bzw. bisher habe ich das für die betreffende Site auch so gemacht.
Leider scheint es aber so zu sein, daß z.B. Google für die Relevanz der Seite die Links verschieden gewichtet, d.h. wenn x Links auf die Domain bestehen, die das richtige Keyword enthalten, bekommen Unterseiten, die von der Hauptseite aus verlinkt sind, einen Malus, wenn sie ein Verzeichnis tiefer sind (was insofern Sinn macht, als z.B. irgendwelche Homepages auf Geocities nicht den Pagerank von Geocities selbst bekommen sollten).
Ich kann das leider nicht mit einer Anleitungsseite von Google beweisen (die halten sich verständlicherweise recht bedeckt, was ihren Algorithmus betrifft), aber aus dem, was ich so in Foren gelesen habe, würde ich sagen, es ist besser, wenn alle Seiten im root der Domain liegen, und dann geht es nicht ohne Dateiendungen (bzw. mit mod_rewrite geht natürlich so ziemlich alles, die Frage ist dann nur noch, was ich dem User/Robot ausliefere, und da ist .html doch eine recht naheliegende Wahl, wenn die eigentliche Datei neuerdings hansdampf.xhmtl heißen soll, na gut, dann wird das halt entsprechend umgeschrieben).
Man kann sich natürlich fragen, ob es sinnvoll ist, die Struktur seiner Seiten nach solchen technischen Zufälligkeiten auszurichten, aber die betreffende Seite ist kommerzieller Natur, insofern...Viele Grüße
Stephan-
Hallo Sven,
Es ist sinnvoll, überhaupt keine Dateiendungen zu verwenden.
Das geht aber leider (falls man mehr als eine Seite haben will ;-)), nur, indem man Unterseiten als Verzeichnisbaum abbildet, also http://www.irgendwas.de/bereich1/unterbereich2/. Rein theoretisch hätte ich damit auch kein Problem, bzw. bisher habe ich das für die betreffende Site auch so gemacht.
Er meint vermutlich keine Verzeichnisse sondern Verweise ohne Endungen und der Server entscheidet welche Datei für einen Request ausgeliefert wird.
Leider scheint es aber so zu sein, daß z.B. Google für die Relevanz der Seite die Links verschieden gewichtet, d.h. wenn x Links auf die Domain bestehen, die das richtige Keyword enthalten, bekommen Unterseiten, die von der Hauptseite aus verlinkt sind, einen Malus, wenn sie ein Verzeichnis tiefer sind (was insofern Sinn macht, als z.B. irgendwelche Homepages auf Geocities nicht den Pagerank von Geocities selbst bekommen sollten).
Das weiß ih nicht, aber allgemein würde ich mich auch fragen ob den Suchmaschinen das so gut gefällt wenn gar keine Dateiendungen mehr da sind. Es gab ja mal Probleme mit dyn. Dateiendungen, das ist IMHO inzwischen nicht mehr so, aber wie das ist weiß ich nicht.
Ich kann das leider nicht mit einer Anleitungsseite von Google beweisen (die halten sich verständlicherweise recht bedeckt, was ihren Algorithmus betrifft), aber aus dem, was ich so in Foren gelesen habe, würde ich sagen, es ist besser, wenn alle Seiten im root der Domain liegen, und dann geht es nicht ohne Dateiendungen (bzw. mit mod_rewrite geht natürlich so ziemlich alles, die Frage ist dann nur noch, was ich dem User/Robot ausliefere, und da ist .html doch eine recht naheliegende Wahl, wenn die eigentliche Datei neuerdings hansdampf.xhmtl heißen soll, na gut, dann wird das halt entsprechend umgeschrieben).
Ich finde man sollte es mit der Umschreiberei auch nicht übertreiben, man macht dadurch das Webprojekt sehr viel komplizierter, verschlechtert die Performance und wofür?
Grüße
Andreas-
Hallo Andreas,
Er meint vermutlich keine Verzeichnisse sondern Verweise ohne Endungen und der Server entscheidet welche Datei für einen Request ausgeliefert wird.
Ja, das ist mir nach dem Abschicken der Antwort auch eingefallen, man sollte halt nicht immer nachts arbeiten ;-). Aber wenn man die Adresse irgendwo in Print o.ä. veröffentlicht, werden sicher einige einen "/" dahinter machen, weil sie es (wie ich) instinktiv für ein Verzeichnis halten, deswegen kann ich mich für diese Lösung nicht wirklich begeistern.
Ich finde man sollte es mit der Umschreiberei auch nicht übertreiben, man macht dadurch das Webprojekt sehr viel komplizierter, verschlechtert die Performance und wofür?
Für einen vorderen Platz bei Google beim richtigen Suchbegriff :-). Zumindest ist es der Firma so wichtig, daß sie notfalls lieber mehr in den Server investieren, als einen Malus von Google hinzunehmen, und ich denke, das ist auch gerechtfertigt, da mittlerweile 70% des Traffic von Google, bzw. aus deren Datenbank (z.B. bei Yahoo-Suche) kommt. Außerdem habe ich bei so simplen Regeln bis jetzt keinen meßbaren Performanceunterschied festgestellt.
Ich finde auch nicht, daß das Ganze dadurch komplizierter wird, im Gegenteil, ich finde es sehr viel einfacher, da ich ohne schlechtes Gewissen alle Seiten mit einer index.php, die die entsprechenden Parameter bekommt, erzeugen kann, und der User bekommt eine "nette", einprägsame url.Viele Grüße
Stephan
-
-
-
-
-