Automatisch von Wordpresse erzeugte Seiten und interne Links

[Martinus33]

Hallo,
eine statische Firmen-Website soll in Wordpress als CMS ein Relaunch erfahren. Die Unterseiten der Site haben URLs mit .html hinten dran, also z.B. site.de/page1.html. Im WP-Relaunch soll das exakt wieder so sein, völlig unveränderte URLs.

Leider erlaubt Wordpress .html-URLs nur für posts, nicht für pages, die ich in meinem FAll brauche. Ich muss also die Seiten in WP mit URLS ohne .html anlegen und für das .html per URL-Rewrite in der .htaccess sorgen:
#internes rewrite .html --> "ohne .html-seiten"
RewriteRule ^((verzeichnis1|verzeichnis2|verzeichnis3)/\w+)\.html /index.php?$1 [L]

Die .html-Anfragen an die neue WP-Installation von außen (Browser, Bots) sind damit abgedeckt.

Doch es gibt auch dynamische Seiten und interne Links,d ie WP danach von selbst erstellt. Haben diese dann .html oder nicht? Die URLs der WP-Navi kann ich manuell frei bestimmen, auch mit .html, also kein Problem. Aber andere Sachen wie z.B. Sitemap oder Suchenfunktion? Auf welche URLs greift WP da zu? Später soll mal ein kleiner blog als Subdomain ergänzt werden auf dieser Site.

 

[Daaron]

Simple Lösung, die auch die gravierenden Sicherheitsprobleme von WP umgeht: Verwende Contao, kein WP. Das hat als Standard .html als Endung.

WP sollte man nicht für Firmenseiten verwenden, da zwar der Core durch die Auto-Updates halbwegs sauber ist, >20% aller beliebten Plugins aber schwere Sicherheitslücken aufweisen... Außerdem ist WP nicht performant und oftmals schlichtweg dumm.

 

[Martinus33]

Die Entscheidung zugunsten WP ist schon vor längerer Zeit gefallen. Selbst wenn ich wollte, es gibt kein Zurück mehr.

 

[MaverickM]

Vielleicht sollte man einfach das .html endlich über Board werfen? Wenn es nur darum geht, dass Besucher weiterhin beim Linkaufruf auch dort rauskommen, wo sie hinwollten, dann wäre es deutlich sinnvoller, die alten Adresse auf die neue Struktur umzuleiten, anstatt die Canonical URLs umzubiegen.

WP sollte man nicht für Firmenseiten verwenden, ...

Dem kann ich nur zustimmen. WP ist ein Blog CMS. Nichts für Firmenseiten.

 

[Martinus33]

Du meinst per 301, ähnlich einem richtigen Domainumzug, nur dass es bei mir nicht die Domain betrifft, sondern ein technisches Problem beim DAtei-Anhang?

301 bedeutet, dass auf Dauer und quasi öffentlich alle Unterseiten-URLs verbindlich das .html verlieren. Eine URL-Änderung bzw. "Umzug" ohne echte Not.

Die von WP automatisch erzeugten internen Links werden - genau wie bei mir schon jetzt - immer absolute Pfade haben und sozusagen von außen bei der htaccess mit dem URL-Rewrite ankommen. Wenn ich ggf. neue pages/posts konsequent ohne .html anlege und die schon jetzt bestehenden pages in WP in der Navi mit als absolue Pfade mit .html anlege, sollte es keinerlei Probleme geben. Die alten Sachen erfahren wie gewünscht das Rewrite, die neuen wie gewünscht keines.
Duplicate content durch die neuen Seiten lässt sich per noindex oder canonical vermeiden.

Ich könnte grundsätzlich auf die extensions durchaus verzichten. Sie bringen nichts, sie schaden nicht (bez. Besucher und Sumas).

Aber was explizit bringt es mir, diese jetzt aufzugeben und langfristig keine mehr zu haben?

301 ist gut, aber warum den falschen Eindruck einer "echten, beabsichtigten" URL-Veränderung erwecken und ein paar kleinere Nachteile in Kauf nehmen, wenn es eine mind. gleichwertige Lösung gibt?

Ist es nicht am besten, wenn alles genau so bleiben kann wie es ist, was ja inhaltlich der Realität entspricht? Wegen mir soll sich nichts außer der Software ändern.

 

[MaverickM]

Ich habe die Praxiserfahrung gemacht, dass solche Umgebogenen Lösungen gerne mal einen Schuss in den Ofen sind, sobald sich etwas am Grundgerüst, sprich hier WordPress, in dieser Richtung ändert. Ein sauberer Schnitt und "Umstieg" auf die bessere Lösung ist in meinen Augen sinnvoller. Keiner kann Dir garantieren, dass Dir Deine Lösung bei der nächsten größeren WordPress Version nicht um die Ohren fliegt.

 

[Martinus33]

Das ist ein sehr vorrausschauender, guter Gedanke. Kannst du ein Beispiel nennen?

Genau dieser Gedanke hat mich nämlich statt eines plugins die htaccess wählen lassen. Damit bin ich langfristig unabhängig von WP- und Plugin-Updates. Die htaccess wird es immer geben und ist mit all ihren Möglichkeiten in meiner Hand. Sie schafft auch keine ggf. schwer änderbaren "Tatsachen" in der Datenbank bzw. WP. Sie ist schnell und sicher.

Damit bin ich doch bestens für mögliche WP-Änderungen gerüstet. Mit 301 zwar auch, aber ein Zurück auf .htm - aus welchen Gründen auch immer - gibt es dann nicht mehr.

 

[Daaron]

Die htaccess wird es immer geben...

Falsch! Falsch! Falsch!
Es gibt nur EINEN EINZIGEN Webserver, der .htaccess verwendet.... und dessen Fanbasis schwindet zunehmend, da immer mehr "Junge Wilde" auf den Markt drängen, die so einiges besser machen.

 

[Martinus33]

Also DAS Risiko nehme ich in Kauf.

Schade, dass sich Falcon nicht mehr meldet, aber wenn sonst keine nennenswerten langfristigen Wordpress-Änderungs-Risiken bestehen durch ein internes URL-Rewrite in der .htaccess....

 

[MaverickM]

Da ich keine Einsicht in die Entwicklung von WordPress habe, kann ich Dir nicht sagen, ob/wie Änderungen in der Richtung geplant sind, oder nicht.
Zumindest im Zusammenhang mit Joomla haben mir die größeren Sprünge in der Architektur (1.5 Core => 1.6-2.5 => 3.0-X.X) zum Teil größeres Kopfzerbrechen beschert, im Bezug auf die Canonical URLs. In 1.5 gab es hier in den Core-Elementen keine Funktionalität, mit 1.6-2.5 wurde die Funktion dann eingeführt. Und die Migration von Plug-Ins auf die Core-Funktionalität war nicht unbedingt als Reibungslos zu bezeichen.

Mein Einwand war einfach nur, es kann zukünftig Probleme geben. Und aus meiner Erfahrung heraus, macht man es am besten gleich richtig, das erspart einem später potentielle Arbeit. Selbst wenn der Fall nie eintritt, ist es in meinen Augen besser, auf Nummer sicher zu gehen.

 

[Martinus33]

Schon klar, es sind spekulative Fantasie-Spiele, aber ich denke ja auch gern langfristig und "gleich richtig". Von daher finde ich den Einwand durchaus interessant.

Im Moment kann ich mir halt nicht so recht vorstellen, welche grundsätzlichen Änderungen das sein könnten im WP-Core, die das Behalten von .html per internen URL-Rewrite zum Problem machen, aber bei einem Wegfall von .html per 301 nicht.

Es müsste etwas "URL-Spezifisches" sein, wobei die Anhänge wie .html bei WP für posts momentan nativ möglich sind.

In WP selbst wären bei der geplanten Umstellung die Seiten ja ganz normal ohne .html angelegt und die zukünftigen pages und posts sowieso. Innerhalb von WP gibt es also gar kein .html.

Mir fehlt da einfach die WP-Kompetenz, um die Wahrscheinlichkeit solcher Veränderungen einzuschätzen.

 

[Daaron]

Die WP-Entwickler schätze ich nicht als sehr veränderungsfreudig ein, sonst hätten sie sich schon längst von ihrer rotzigen API getrennt und das Projekt mal auf eine saubere Codebasis gestellt. Sie hätten sich sicher auch von MD5 als Password-Hash getrennt...

 

[Midnight Sun]

Die Frage bleibt bestehen, warum du hier dann nicht einfach einen sauberen Schnitt machen möchtest.
Wo genau liegt hierbei das eigentliche Problem?

 

[Martinus33]

Ich wechsle 1:1 mit allen URLs und Inhalten auf ein CMS, nämlich WP.

Warum einen "Schnitt" machen und per 301 die URLs der Unterseiten langfristig und für die Besucher/Google ändern, sprich, .html fallen zu lassen?

Für dich scheint ganz selbstverständlich zu sein, einen Schnitt zu machen und die URLs zu ändern und fragst mich, warum ich es nicht mache.
Mir geht es genau umgekehrt: Ich sehe keinen Grund, die URLs per 301 zu ändern und frage mich bzw. dich, warum das gut wäre?

Wäre meine Site ein Blog oder WP könnte auch bei pages URLs mit Anhängen ermöglichen, würde wahrscheinlich jeder einfach wieder die Seiten mit den bisherigen URLs (mit .html) anlegen. Keiner würde einen Gedanken an was anderes verschwenden.
Nur weil WP keine pages mit .html ermöglicht, muss jetzt eine 301 mit neuen URLs (ohne .html") eine gute Idee sein?

Wenn es einen guten Grund gibt, mache ich es.

 

[Midnight Sun]

Meine eigentliche Frage war, warum du zwingend an der HTML-Endung festhalten möchtest?


Ich entscheide sowas generell von Projekt zu Projekt oder von Kunde zu Kunde neu und individuell.

Wenn es einen Relaunch geben soll, die Seite aber nur sehr klein, wenig bekannt oder eh schon bei Google (sagen wir ab Seite 3-5) gelistet wird, dann gibt es bei mir einen sauberen Schnitt.

Wenn die Seite etwas größer und bekannter ist und weiter oben bei Google zu finden ist, dann muss man dieses vorab mit dem Kunden besprechen und gucken welche Lösung es dafür gibt.


Persönlich finde ich WP auch für eine kleine Firmenwebseite ganz in Ordnung und würde das System auch weiterhin bei größeren einsetzen.


Wenn du die Endungen weiter behalten möchtest, würde das in etwas so aussehen: url: .../unternehmen.html
Wenn du jetzt die Permalinkstuktur anpasst, schaut das so aus url: .../unternehmen
Es ändert sich also nicht sonderlich viel und mit deiner 301 kannst du die Besucher dann auch weiterleiten...

Unterseiten sind bei WP eigentlich nicht mehr zwingend notwenig.
Ich verwenden sie intern eigentlich nur noch der Übersicht halber bzw. dann wenn ich diese Struktur auch in der Adresszeile sichtbar haben möchte. url: ...unternehmen/ueberuns

Da man die Naviagtionen sehr gut anpassen und individuell zusammenstellen kann, macht das für mich so auch kein Sinn mehr.

Generell könntest du die gesamte Page auch aus einzelnen Artikeln zusammensetzen...

 

[Daaron]

Meine eigentliche Frage war, warum du zwingend an der HTML-Endung festhalten möchtest?

Manche CMS, z.B. Contao, packen sie halt dran. Is so weil is so. Warum soll man sich die Mühe machen und sie entfernen?

Persönlich finde ich WP auch für eine kleine Firmenwebseite ganz in Ordnung und würde das System auch weiterhin bei größeren einsetzen.

WP hat kein LTS, WP hat permanent Sicherheitsprobleme, WP hat keine anständige API, WP ist insgesamt lahmarschig programmiert.
Das alles spricht dagegen, es auch nur für ne Ferienwohnung einzusetzen.

 

[WhiteShark]

Wp hat im Prinzip LTS. Und zwar deutlich länger als die anderen CMS.
Das ist ja der große Vorteil an WordPress. Bei anderen CMS kommt eine neue Hauptversion und alles wird inkompatibel.
Bei WordPress passiert das nicht.

Und die Behauptung WordPress sein nur ein Blog CMS ist schon lange überholt. Es ist mittlerweile ein vollwertiges CMS.
Das es permanent Sicherheitsprobleme hätte ist auch ziemlich übertrieben.

Das einzige was man zugeben muss, ist das WordPress langsamer ist als die meisten anderen Systeme. Das ist aber nur bei größeren Seiten spürbar.

 

[Midnight Sun]

Die abgesprochenen Probleme (welche überhaupt genau) beziehen sich meiner Kenntniss nach auf die verwendeten Plugins,
die dann zu einen unsicheren System führen.

Durch die Regelmäßigkeit, der kleinen Updates werden die vorhandenen Sicherheitslücken so gut es geht geschlossen.
Für weiterer, die durch den Benutzer herbeigeführt werden, können die Entwickler nichts.

Generell gibt es viel zu viele WP-Installationen, wo die Beteriber nicht einmal die Basics an Sicherheit nach der Installation durchgeführt haben und sich dann wundern, wenn bei ihnen etwas passiert.

Das immer wieder etwas passiert steht ausser Frage, ist aber wohl auch bei anderen Systemen und/oder deren Erweiterungen der Fall.


Was die Trägheit von WP angeht, ja das System ist im laufe der Zeit langsamer geworden.
Ich finde aber, dass ich das bisher noch in Grenzen hält. Ich habe derzeit habe auch mit keinem anderen CMS zu tun, daher fehlt mir da ein direkter Vergleich.

 

[Martinus33]

@Dragon Sun: Ich sagte doch bereits, dass ich nicht zwingend daran festhalte. Aber grundsätzlich gibt es keinen Grund bei mir zu Änderungen, die über die verwendete Software hinausgehen, also warum bei einer so wichtigen Sache wie den URLs ohne Not und Vorteile rumschrauben?

Solche Anhänge bringen nichts und schaden nicht. Bei einer neuen Site würde ich wahrscheinlich darauf verzichten. Aber eine echte Änderung und neue URLs per 301 haben Auswirkungen, die bei mir weder nötig noch sinnvoll sind.


Ich bin nicht generell einem solchen Schnitt abgeneigt, aber ich würde gerne Gründe für ein eigentlich überflüssiges 301/neue URL sehen und du hast noch immer keine genannt.
Gäbe es z.B. gute Indizien dafür, dass .html-Seiten z.B. bei den Sumas in deren Serps eine schlechtere CTR haben oder dass solche Anhänge in spät. 10 Jahren kein CMS technisch mehr unterstützen will, dann würde ich bei der Gelegenheit eines Umstieges auf WP einen Schnitt überlegen.

301 ist "gut", aber birgt dennoch ein kleines Risiko, siehe http://www.sistrix.de/news/risiko-domainumzug-und-rankings-bei-google/ und es geht etwas PR verloren. Deine Seiten werden von den Sumas komplett neu bewertet und es dauert länger bis du wieder die alten Rankings hast. Wenn WP die Anhänge irgendwann auch für pages unterstützen sollte, kann ich nach 301 nicht mehr zurück, bei internen Rewrite nehme ich das einfach raus aus der htaccess. Alles nur Kleinigkeiten, aber warum das in der Summe zumindest "kleine Manko" angestrengt herbeiführen, wenn ich gleichzeitig keine größeren Vorteile gewinne?

 

[Daaron]

Wp hat im Prinzip LTS. Und zwar deutlich länger als die anderen CMS.

Das ist kein echtes LTS, das ist nur der Unwille, mal notwendige Einschnitte zu machen.
TYPO3, Contao,... die haben alle echten Long Term Support, der nicht purer Faulheit oder Unfähigkeit geschuldet ist.

Für weiterer, die durch den Benutzer herbeigeführt werden, können die Entwickler nichts.

Die hundsmiserable API ist dafür maßgeblich mit verantwortlich. Natürlich kann ein mieser Entwickler, der eine gute API umgeht, immer noch Schaden anrichten... Das kannst du nie verhindern. Bei einer räudigen API kann aber sogar ein guter Entwickler sich einen groben Schnitzer leisten.

http://www.heise.de/newsticker/meldung/Sicherheitsluecke-in-vielen-WordPress-Themes-2390055.html

Da die Lücke den Angreifern Zugriff auf die Konfigurationsdateien des CMS gewährt,...

Sorry, aber hier muss das CMS zwingend regulierend eingreifen, und wenn es das per .htaccess tut.

Das MINDESTE, was ich hier erwarte, ist You don't have permission to access /system/config/localconfig.php on this server.