Extension html statt php

Die schlechte Nachricht gleich vorab: Suchmaschinen werden von der Extension ".html" nicht in den Bann gezogen. Schließlich wird jeder Netzwerkvorgang im Web vom http-Header begleitet, der unabhängig von der Extension dem Empfänger sagt, was das ist. Und bei einer php-Seite ist das schlichtweg Typ: php, unabhängig von deren Extension .html.

In den Foren der Suchmaschinen-Optimierer tauchen zwar immer wieder Überlegungen auf, wie man Google hierbei übers Ohr hauen könnte; in der Praxis ist das aber sehr schwierig und von vielen Faktoren abhängig. Und schon allein, dass es offen diskutiert wird, zeigt dass die möglichen Vorteile für gering gehalten werden - die wirklich guten Tricks verrät man nicht in Foren.

Was gibt es also für Gründe, .html statt .php zu verwenden:
a) Eitelkeit
b) Tradition
c) technische Gründe

Eitelkeit

Ist zwar ein Grund, aber kein guter: Die lustige Extensions-Verbiegung WAR mal in Mode, heute lockt das keinen Hund mehr hinter dem Ofen hervor. Möglicherweise kann man noch mit Fantasie-Extensions jemanden beeindrucken, das schulterklopfende Aha! ist aber in jedem Fall kürzer als die Arbeit, die man sich macht.

Tradition

Der Umstieg auf dieses "Serverzeugs" fällt nicht jedem leicht und ein .html trägt noch ein bissel den Geist der alten Zeit in sich, als man seinen Seiten noch mit Frontpage4 zusammenschraubte. Im Ernst: Ich verstehe das. Aber: Es wird Zeit.

Technische Gründe

Ein manchmal genannter Grund ist: Man will eine statische Site auf WBCE umstellen, aber die URLs beibehalten: In der Praxis funktioniert das gut wie nie, man muss mit Weiterleitungen arbeiten, also ist es schon wieder egal.
Ein weiterer möglicher Grund: Ich neige zB. dazu, ganze Domains  in Form von statischen Seiten zu cachen. Dabei ist es recht nützlich, wenn im Menü schon überall die Links "richtig" stehen.

Konkret: so geht:

.htaccess

Die .htaccess ist eine Datei, in der bestimmte Einstellungen am Server vorgenommen werden können. Sie gilt für das Verzeichnis, in dem sie ist und alles unterhalb. Mit ihrer Hilfe kann der Server (uA):
a) Jeden Zugriff auf eine html-Datei auf eine php-Datei umleiten
b) html-Dateien wie php-Dateien behandeln.

Variante a: Umleitung von html auf php

RewriteEngine on
RewriteRule ^(.*).html$ $1.php [L]

Klingt zunächst verlockend, weil sie alle Schwierigkeiten mit einem Schlag zu lösen scheint. Tatsächlich gibt es gleich einmal Ärger: Da alle neuen Access-Files als .html angelegt werden, gibt es keine .php-Äquivalente dazu, die Umleitung läuft ins Leere und führt zu einem Fehler. Dasselbe gilt für diverse Hilfe- oder Musterseiten, die sich in den Modulen finden. Zb das Code-Modul funktioniert im Backend nicht mehr, viele weitere ebenso nicht oder sind zumindest beeinträchtigt. Wer will das schon alles überprüfen...
Zusätzlich gibt es noch ein Problem mit "Duplicate Content", es ist ja jede Seite unter 2 URLs erreichbar: --.php UND --.html – aber das ist angesichts oben genannter Probleme schon ein Klacks.

Variante b) .html-Seiten wie .php behandeln

AddType application/x-httpd-php .html

Das heißt: ALLE html (aber zb nicht .htm) Seiten werden durch das php-Werkel gejagt. Das kann Ärger machen, wenn eine html-Seite zB eine korrekte DocType-Definition, beginnend mit <?xml hat, weil hier der Parser gleich mal einen Fehler finden könnte. Abgesehen davon sollte es zwar keinen gröberen Ärger geben, aber eventuell einige Ärgernisse:
Wenn neben der WebsiteBaker-Installation noch größere Bereiche von statischen Seiten existieren, würden diese ebenso wie php ausgeliefert. Hier kommt wieder der oben genannte http-Header ins Spiel: Die bisher statischen Seiten sind plötzlich dynamisch und haben damit zB kein Änderungsdatum mehr. Die Folge: Viel mehr Traffic durch Suchmaschinen-Bots, die ja jetzt am Änderungsdatum nicht mehr erkennen, ob sich die Seite geändert hat, sondern sie immer wieder ganz laden müssen, um das festzustellen. Die Serverlast vervielfacht sich dadurch also: Mehr ausliefern und das auch vorher noch parsen.
Normalerweise wird das kein Drama sein, aber: Viele Seiten +  schwacher Server = Bitte Warten.
Sollte html statt php  bei Suchmaschinen auch keinen Vorteil haben: Wenn es einen gäbe ist er weg. Sollte es einen Nachteil geben: Der ist jetzt da, und zwar auch für die früheren statischen Seiten.

Klartext: Auf jedem Fall also Variante b, bleibt aber die Frage:

Wohin mit der .htaccess?

Die einfachste Variante: Ins Root (Startverzeichnis) der Domain, also gleich neben config.php und index.php. Damit gilt die Einstellung aber auch für alle (Unter)verzeichnisse, in denen sich ja auch html-Seiten befinden können - und alle parallelen html-Seiten. Eine mögliche, aber nicht immer die beste Wahl.

Falls also nicht gleich im Root, gäbe es mehrere Orte:
Mit Sicherheit einmal ins CMS-Verzeichnis. Ob man die Datei auch im Modules-Verzeichnis braucht, hängt davon ab, welche Module man verwendet. Da man wahrscheinlich lieber gleich testet als nach Monaten zu rätseln – ja.

Für .htaccess-Neulinge:

Die .htaccess ist eine ganz normale txt-Datei und lässt sich mit jedem Editor, der reinen Text speichern kann (also NICHT Word!) bearbeiten. Der Punkt am Anfang sagt, dass die Datei unter Linux versteckt sein soll. Dadurch – und weil sie keine Extension hat – gibt es auf Windows-Computern und mit gängigen FTP-Programmen gelegentlich mal Ärger damit. Der einfachste Weg: Zum Bearbeiten umbenennen in htaccess.txt, unmittelbar vorm Hochladen wieder zurück zu .htaccess. Die meisten  FTP-Programme bieten die Möglichkeit, versteckte Dateien anzuzeigen.

Zur Sicherheit sollte vor der ersten Änderung eine eventuell bereits existierende .htaccess heruntergeladen werden; möglicherweise hat der Provider damit schon Einstellungen gemacht. Kleiner Trick: Falls du dir nicht sicher bist, ob es keine .htaccess gibt – oder ob du sie nur nicht siehst: Lade eine Datei .htaccess2 hoch. Starte den FTP-Client neu: Siehst du diese? Wenn nein: Suche eine Einstellung "Versteckte Dateien anzeigen" Siehst du sie jetzt – aber keine .htaccess? – OK, dann gibt es auch keine. Lösche den 2er einfach. (Wenn das FTP-Programm jetzt meckert gibt’s doch eine :)