Webmaster-Ressourcen, WordPress HowTo

WordPress Multisite mit Domain-Mapping auf Plesk Server mit Letsencrypt SSL versorgen

Die Aufgabenstellung: Auf einer WP Multisite Installation mit Domain-Mapping (d.h. alle Domains haben eigene TLD), die auf einem Plesk 12.5 Server läuft soll für jede Site ein SSL von Letsencrypt installiert werden.

Auf den ersten Blick einfach: SAN Zertifikat holen, das alle Domains beinhaltet und auf der Hauptseite installieren. Und nicht vergessen, das SAN Zertifikat muss spätestens alle 3 Monate wieder manuell erneuert werden. Das alles geht im Terminal mit den Command Line Tools, muss man sich aber erst anlesen und ist mir zu kompliziert gewesen… auch die Aussicht auf Wiederholung im 3-Monats Rhythmus passt mir nicht.

Einfacher gehts mit einem kleinen Umweg: Für Plesk (ab 12.5) gibt es seit kurzem die?tolle Letsencrypt-Extension, die allerdings noch keine SAN Zertifikate holen und installieren kann. Letsencrypt unterstützt darüber hinaus auch keine Alias-Domains.
Daher muss man auf dem Plesk Server alle Domains für die Multisite als eigene Domain einrichten und dabei darauf achten, dass man als Speicherort das bestehende Abo der WP-Hauptseite einträgt und dass auch der Dokumentenstamm gleich lautet wie für die Hauptseite (normalerweise /httpdocs).
Plesk meckert beim Anlegen darüber, dass die Logfiles nicht korrekt erstellt werden künnen – klar, die liegen ja alle im gleichen Verzeichnis, da gibts also Kollisionen.
Abgesehen davon ist die Domain aber funktionsf?hig und zeigt auch auf unsere WP Multisite Installation.

Jetzt kann man für jede Domain mit der Letsencrypt-Extension ein (kostenloses) SSL Zertifikat holen, das auch gleich automatisch installiert wird. Die Extension sorgt auch dafür, dass das Zertifikat jeden Monat automatisch erneuert wird. Kein manueller Eingriff mehr nütig.

Im WP muss man schliesslich noch die nütigen Anpassungen (Site-url und Site-home) so vornehmen, dass die Seiten über https:// laufen und auch htaccess sollte so angepasst werden, dass der Seitenzugriff automatisch auf https:// umgeleitet wird. In Google findet man die passenden Hinweise dafür.

Zu guter Letzt noch ein bisschen Speed-Tuning mit Plesk-Mitteln: im Seitenhosting kann mit ein paar Klicks nginx als Reverse Proxy aktiviert werden, damit werden Bilder, Skripte und Styles viel schneller geliefert. Die Aktivierung von CloudFlare für jede Domain (auch nur ein Klick im Plesk) reduziert die Ladezeiten weiter und schützt darüberhinaus die Seiten vor DDoS-Angriffen. Das Ergebnis: bei einer Multisite mit 10 verschiedenen Domains liegen die Seiten-Ladezeiten (GTmetrix) jetzt bei 1 – 2 Sekunden und die Performance scores so um die 90, das auf einem „ganz normalen“ VPS, d.h. ohne Hardware-Overkill…

Das Tuning geht weiter, da liegt sicher noch mehr drin…

​Read More
Webmaster-Ressourcen, Website-Marketing, WordPress HowTo

Doppelter Content und der non-www Redirect

Jerry West schreibt in seinem aktuellen Post: Fixing Internal Duplicate Content with a Non-www Site Redirect wieder mal über ein altbekanntes Thema, das ich aus aktuellem Anlass nochmal aufgreifen will, weil viele Webmaster sich immer noch diese Nachlässigkeit leisten; Sie führt zu der Duplicate Content Abstrafung durch Google mit reduziertem PageRank und damit schlechteren Listings für die eigenen Seiten. Folge ist weniger Suchmaschinentraffic – ein böser Fehler für jeden Webmaster, nicht nur für die, die mit Ihrer Site Geld verdienen wollen.
Dabei ist der Duplicate Content Fix sehr einfach über die .htaccess im root-Verzeichnis der Site zu erledigen. Noch einfacher geht’s mit der neuesten WordPress-Version: stellt man WordPress-Adresse und Blog-Adresse korrekt mit „http://www.“ ein, erledigt WordPress das von ganz alleine.

​Read More