Wenn man eine Webseite aufbaut, stellt man unwillkürlich früher oder später fest, dass das Internet nicht etwa am Ortseingang endet. Und so stellt sich früher oder später die Frage, ob man die eigene Webseite nicht zumindest teilweise auch in anderen Sprachen bereitstellt. Auch kann dies wichtig für google und Co sein: Hat man viele Seitenbesucher aus Regionen, die die eigene Sprache nicht verstehen, mündet dies zwangsläufig in vielen Seitenabbrüchen – für google und Co. kann das so wirken, als wäre die eigene Webseite für Suchende nicht so interessant! Nutzt man für die Webseite das bekannte CMS WordPress, stellt sich dann aber die Frage, wie man mehrere Sprachen bereitstellen kann.
Für fast alle Content Management Systeme gibt es in der Regel zahlreiche Plugins, die die Koordination abnehmen. Da wir für eproi allerdings WordPress verwenden, geht dieser Artikel vor allem auf die Möglichkeiten dieses CMS ein.
Grundsätzlich gibt es für WordPress so ziemlich genau 3 praktikable Lösungen, wie man den Seiteninhalt in einer anderen Sprache bereitstellen kann:
- Über ein Plugin, dass entweder den Inhalt der Seite übersetzt und in geeigneter Weise einbindet
- Über mehrere WordPress-Installationen (jeweils eine je Sprache) und dem (manuellen) Anlegen der entsprechenden Inhalte
- Über die Möglichkeit WordPress als Multisite einzustellen und damit innerhalb einer Installation mehrere Seiten anzulegen (idealerweise eine pro Sprache).
Alle Varianten haben ihre Vor- und Nachteile, die wir im Schnelldurchlauf auch gleich betrachten werden. Vorweg aber schon mal so viel: Für eproi haben wir nach zahlreichen Versuchen die dritte Variante umgesetzt.
Warum?
Weil sich die anderen beiden Varianten entweder als zu unpraktikabel für unser Szenario erwiesen haben oder schlichtweg nicht funktioniert haben, wie wir es gern wollten bzw. gebraucht haben. Aber von vorn!
Variante 1: Nutzen eines Plugins
Dies ist wahrscheinlich die einfachste Variante. Sie kommt vor allem dann in Betracht, wenn man auf dem Server keine passenden Einstellungsmöglichkeiten (root) hat, aber immerhin Plugins (nach)installieren kann.
Neben diesem Vorteil und der Tatsache, dass man wenig Ahnung von Programmierung etc. haben muss, gibt es noch einen Vorteil: Ein Plugin orientiert sich an der vorhandenen Seite. D.h. als Seitenadministrator braucht man nicht mehr darauf zu achten, Seiten neu anzulegen oder zu verschieben etc. Manche Plugins bieten zudem gleich die Möglichkeit, die für den Besucher bestgeeignete Zielsprache anzusteuern und falls keine Übersetzung vorhanden ist, als „Fallback“ einen vorher definierten Inhalt (zumeist die Standardsprache der WordPressseite) anzuzeigen.
Allerdings haben die meisten Plugins auch zwei bis drei große Nachteile. I.d.R. wird die vorhandene Seitenstruktur mehr oder minder 1:1 abgebildet – manchmal sogar als eine Art wörtliche Übersetzung. Die Präsentation der Daten wirkt in verschiedenen Sprachen aber ganz unterschiedlich, so dass eine wörtliche Übersetzung meist eher etwas unbeholfen wirkt. Und will man nur einen Teil der Seiten übersetzt anbieten, bekommt man am Ende vielleicht so eine „denglisch“-Seite, bei der dann die andere Hälfte doch wieder auf Deutsch angezeigt wird.
Serverlast im Auge behalten
Der zweite große Nachteil: Jedes Plugin, dass man auf seine WordPress-Seite lädt, vergrößert die Serverlast. Bringt ein Plugin sagen wir 30 Dateien mit, müssen auch alle 30 Dateien mitverarbeitet werden, um die Seite zu generieren und auszuliefern. Je weniger Plugins also benötigt werden, desto kleiner die Serverlast und desto schneller kann die Webseite bereitgestellt werden (bzw. desto schonender die Serverumgebung für den Geldbeutel ????).
Auch die Clientlast beachten
Eventuell der dritte große Nachteil: Einige Plugins stellen die Übersetzung zusammengefasst auf einer Seite dar und switchen per CSS dann nur den sichtbaren Inhalt, je nachdem welche Sprache angezeigt werden soll. Das klingt natürlich großartig, weil so die Webseite nicht neu vom Server geladen wird, nur weil der Besucher die Seite dann doch lieber auf Englisch als Deutsch lesen möchte. Das heißt aber auch, dass zu Beginn – also beim „Erstabruf“ der Seite – sehr viel größere Dateien übertragen werden müssen.
Hat eine Seite in der Ursprungssprache sagen wir mal 50 kB Textinhalt, werden daraus mit nur einer weiteren Sprache bereits weitere 50 kB – also insgesamt 100 kB zum Übertragen. Hat man also viel Text und/oder mehrere Sprachen, die man bedient, erhöht sich die zu übertragende Größe ganz rapide. Und gerade auch für das eigene SEO der Webseite wird es hier spannend: Jedes kB mehr an Übertragung bedeutet eine langsamere Webseite und damit die Gefahr, dass der Besucher dann doch wieder abspringt, weil das Downloaden und Rendern für ihn zu lange dauert.
Eine weitere Problematik aus SEO-Sicht: das hreflang-Tag bzw. die Sprachangabe im <html>-Tag lässt sich in den meisten Fällen nicht setzen. Auch ist es schwierig, evtl. andere Canonical-URLs auszugeben, gerade wenn der fremdsprachige Content nur über „unsichtbar“ geschaltete Inhalte realisiert wird und nicht als eigenständige Seite. Google könnte so sehr schnell auch zu der Annahme „duplicate Content“ kommen und somit ggf. die Relevanz der Webseite herabstufen. Eigentlich will man ja aber dem SEO mit weniger Seitenabbrüchen was Gutes tun – und nicht darüber dann das eigentlich Gute einbüßen…
Fazit für Variante 1
Für uns hat diese Variante nicht so gut funktioniert: Entweder waren die englischen Inhalte gar nicht erst sichtbar oder die Usability auf der Webseite litt erheblich, so dass wir unseren Webseitenbesuchern nicht zumuten wollten, sich da „durchzuwurschteln“ (uns übrigens auch nicht, denn wir hätten das Ganze ja anlegen und testen müssen ????).
Variante 2: Mehrere WordPress-Installationen
Diese Variante hilft schon mal dagegen, dass man alles in ein WordPress „pressen“ muss. Die Vorteile sind also abgeleitet aus Variante 1:
- Die zu übertragende Datenmenge bleibt klein, da jede Installation nur eine Sprache ausliefert
- Man ist sehr flexibel was die Gestaltung und Menge an Seiten angeht: Soll auf Englisch nur ein one-pager realisiert werden, der einfach kurz „über uns“ informiert, ist das problemlos möglich: Die einzelnen Seiten hängen ja nicht aneinander.
- Man spart sich zumindest schon mal das Plugin für die Übersetzung 😉
- Man kann unterschiedliche Themes und Bilder einbringen und so die Präsentation der Daten ganz auf den „Geschmack“ des jeweiligen Ziellandes abstimmen.
Subfolder oder Subdomain?
Allerdings gibt es auch ein paar Nachteile. Kann man z.B. keine Subdomains anlegen, bleibt hier nur die Variante über die Einrichtung per Subfolder. Oder man legt gleich für jede Sprache eine eigene Domain an. Das kann aber natürlich mitunter teuer werden – denn nicht alle Toplevel-Domains sind kostengünstig und vor allem einfach zu haben. Einige spezielle Domains haben z.B. als Voraussetzung, dass der Inhalt bzw. genauer gesagt der Inhaber der Domain irgendetwas mit dem Land zu tun haben muss – und meistens ist allein das Argument „wir wollen unseren Inhalt in der Sprache anbieten“ nur bedingt gewichtig genug.
Der Aufwand ist außerdem bei dieser Variante wohl am größten. Es müssen jeweils einzelne WordPress-Installationen aufgebaut werden und alle Inhalte und Seiten jeweils entsprechend angelegt werden. Soll für jede Sprache ein eigener Server (oder virtueller Server) bereit gestellt werden, muss zudem jeder Server erst mal eingerichtet werden. Ebenso spielt der Aufwand evtl. eine Rolle, wenn es um die Wartung und das einspielen von Updates geht oder neue Seiteninhalte angelegt werden soll.
Schon allein deshalb kam diese Variante für uns nicht in Frage. Der Aufwand für das Bereitstellen und Warten der Installationen ist vor allem mit kleineren Unternehmungen nicht zu stemmen. Selbst große Firmen würden sich vermutlich mindestens zweimal überlegen, ob diese Variante wirklich sinnvoll ist.
Einziges „Totschlagargument“ für diese Variante: Bei einzelnen Installationen (und ggf. auch noch auf einzelnen Servern) führt der Ausfall einer Sprachvariante nicht gleich zum Ausfall für alles. Zerschießt also der übereifrige Praktikant die Englische Version, ist zumindest für die deutschen Kunden die Seite noch erreichbar.
Variante 3: WordPress Multisites
WordPress wird von Hause aus nicht dafür ausgeliefert, mehrere Seiten mit einer Installation bereitzustellen. Und de facto teilt sich eine Installation dann auch nur alles, was nicht Datenbank ist. Denn jede „extra-Seite“ bekommt dann jeweils mit anderem Tabellenpräfix eine eigene Kopie der Datenbank (bitte bedenken, wenn es um die Sicherung der Datenbank geht!). Man kann es aber aktivieren und auf uns hat diese Variante bereits direkt nach dem Anlegen auf unserem Testserver einen sehr positiven Eindruck gemacht.
Durch die Wahl zwischen Subdomain und Subfolder-Variante ist es schon mal möglich, alles kostengünstig über eine Domain laufen zu lassen. Da wir aktuell andere Sprachvarianten vor allem mit dem Hintergrund anlegen, weniger Abbruchraten zu erhalten, soll das Ganze natürlich bestenfalls kostenneutral für uns laufen. Die Variante über Subdomains war daher auch eher suboptimal, da dies bedeutet hätte, weitere SSL-Zertifikate direkt für diese Subdomains zu kaufen oder alternativ ein Wildcard-Zertifikat – was aber eben für den jetzigen Stand der Dinge auch zu „oversized“ gewesen wäre.
Wir haben daher das Ganze über Subfolder realisiert.
Alles HSTS oder was?
Zu beachten ist hierbei auch: Hat man bereits ein SSL-Zertifikat installiert und zudem HSTS auf dem Server aktiviert, darf die Einstellung Subdomain-Betrieb nur sehr vorsichtig angewendet werden. Da in den meisten Fällen kein Wildcard-Zertifikat Anwendung findet und vermutlich auch nicht „vorausschauend“ gleich die Subdomain ins Zertifikat mit eingebaut wurde, könnte es sein, dass der Browser die Darstellung der Webseite eben wegen Verstoßes gegen HSTS (Zertifikat passt nicht zur HSTS-Einstellung bzw. Domain) verweigert. Chrome beispielsweise lässt in dem Fall auch keine Ausnahme zu! Wer dann keinen root-Zugang via SSH für den Server hat oder zumindest per FTP Einträge in einer .htaccess ändern kann, sitzt dann womöglich erst mal auf dem Trockenen.
Nachteil ist hier ansonsten wie in Variante 2 auch schon, dass für jede Sprache jede Seite nochmal extra angelegt werden muss. Das kann aber wie gesagt auch ein Vorteil sein, weil jede Sprache grundsätzlich auch mit eigenem Satz an Seiten aufgebaut werden kann, eigene Bilder und Themes auch entsprechend angewendet werden können.
Multisites bieten dennoch charmante Vorteile
Im Gegensatz zur Installation mehrerer Seiten auf ggf. auch mehreren Servern bietet sich hier aber ein entscheidender Vorteil: Es gibt ein übergeordnetes Dashbord. D.h. das Update der WordPress-Version braucht nur einmal darüber gemacht zu werden. Auch können alle Plugins und Themes zentral darüber geupdated werden. Besonders charmant ist dann auch noch die Variante, dass Plugins gleich „netzwerkweit“ aktiv geschalten werden, aber natürlich für jede einzelne Sprachvariante – sprich jede einzelne „Version“ der Seite auch deaktiviert werden können. Dies ist vor allem für Plugins interessant, die aus rechtlichen Gründen vielleicht im einen oder anderen Land (und damit für die eine oder andere Sprache) problematisch sind. Und natürlich bei grundsätzlich verschiedenen Inhalten, um das Laden unnötiger Plugins für die eine oder andere Variante zu vermeiden und somit auch im Sinne des SEO und der Ladezeiten die Seite möglichst klein zu halten.
Wichtig ist für das dezentrale Steuern der Plugins erst mal, dass man in der Netzwerk-Haupteinstellung die Administration von Plugins aktiviert (s. Screenshot). Und dann geht das auch nur für alle Plugins, die man nicht zentral für das gesamte Netzwerk (netzwerkweit) aktiviert hat. Im Zweifelsfall müsste man für eine Umstellung also alle Plugins netzwerkweit „deaktivieren“ und könnte sie dann zielgerichtet pro Seite wieder einschalten.
Dennoch muss auch diese Variante ein bisschen feingetuned werden, damit es für’s SEO dann passt.
Was es bei der Variante nämlich nicht gibt, ist die Möglichkeit, die Sprachangabe im <html>-Tag jeweils anzupassen. Und was ebenfalls nicht automatisch geht: Eine direkte Weiterleitung auf die Sprachversion, die der Browser bzw. Besucher über den Browser als bevorzugt mitteilt. Beides ist wohl aber dem geschuldet, dass WordPress ursprünglich eben nicht für die Benutzung als Multisite-CMS konzipiert wurde. Beides ist aber relativ einfach mit nur zwei kleinen Funktionen hinzubekommen.
So geht’s weiter
Die beiden Funktionen inkl. Erläuterungen, was da genau passiert und wie diese eingebaut werden können, gibt es dann aber ausführlich im nächsten Post..