WordPress: mehrere Websites betreiben, die in einem Kundenkonto beim Provider liegen
Viele Webworker und Agenturen betreiben selbst mehrere Websites und haben diese in einem Kundenkonto beim Provider liegen. Dagegen ist prinzipiell nichts einzuwenden, allerdings kann das auch sehr leicht im Chaos enden. Daher hier einige Gedanken dazu, aus aktuellem Anlass, nachdem ich gestern bei einem Kunden (stundenlang, aber letztlich erfolgreich) die Verwüstung beseitigt habe, die ein ehemaliger Mitarbeiter dort vor seinem Weggang von der Firma am Server angerichtet hat.
tl;dr: Kundenwebsites gehören nicht in den Account des Webdesigners.
Legt keine Kundenwebsites/Mailkonten in euren Account!
Im konkreten Fall lagen im Agentur-Account auch die Websites der Kunden, denen das Hosting weiterverrechnet wird – gesamt über 50 Stück. Macht das bitte nicht, aus mehreren Gründen: wenn ein Kunde zu einem anderen Dienstleister wechseln mag, dann heißt es für euch, die Website und die Mailkonten manuell aus eurem Account woanders hin zu übersiedeln – denn einfach dem Kunden die Zugangsdaten geben kann man ja nicht, weil der Kunde bzw. der neue Dienstleister sonst Zugriff auf alle eure Kundenkonten hätte. Das bedeutet extra Arbeit, die normalerweise dem Kunden nur schwer zu verrechnen sein wird, denn immerhin ist dieser grade dabei, euch als Dienstleister zu verlassen, also wohl kaum bereit noch Extrakosten zu übernehmen. Und auch aus Sicherheitsüberlegungen ist es keine gute Idee, aber dazu später. Weiters sehen das viele Provider gar nicht gerne, wenn man im eigenen Account auch noch Kunden untergebracht hat und können schon mal mit Kündigung drohen.
Die sauberste Lösung daher: man klickt den Kunden eigene Accounts beim Provider. So braucht man sich um die Technik gar nicht kümmern, auch das Inkasso fällt weg. Bei einfachem Webhosting für Websites mit wenigen Zugriffen ist kaum Geld zu verdienen, das kann man heutzutage gern dem Provider überlassen und sich ggf. für einen Affiliate-Account registrieren. Aber wenn ihr die Websites der Kunden schon selbst hosten wollt, dann leistet euch einen Reseller-Account bei einem Provider, wo es eine klare Trennung der einzelnen Kunden-Accounts gibt. So hat man einerseits einfach Zugriff darauf, aber kann den Kunden getrost die Zugangsdaten zu IHREM Kundenbereich geben, wo diese dann etwa Mailadressen und Weiterleitungen selbst verwalten können – oder auch sogar ein anderer Webdienstleister damit arbeiten kann. Es funktionieren etwa die Reseller-Server von all-inkl.com* sehr gut. Einzige lästige Beschränkung ist die Anzahl der möglichen Datenbanken – wenn man also hauptsächlich WordPress-Websites dort unterbringen mag, dann gehen sich in der Praxis nicht mehr Kundenaccounts aus als Datenbanken zur Verfügung stehen. Dafür ist die Mailverwaltung sehr schön gelöst, inkl. Spamfilter, Virenschutz und einem hübschen Webmail.
Für reines WordPress-Hosting (also ohne E-Mails oder Domainverwaltung) empfehle ich Raidboxes* – dort kann man die Website unter einer temporären Domain am Server entwickeln und danach dem Kunden übergeben, wobei man selbst als Administrator weiterhin Zugriff auf die Administration hat. Das Hosting bezahlen die Kunden direkt an Raidboxes, man kriegt einmalig Provision. Weitere Vorteile: sauschnell selbst ohne Caching-Plugin, sehr viele Sicherheitsfeatures und automatisches Backup sind bereits serienmäßig dabei, automatische Updates von WordPress/Theme/Plugins kann man konfigurieren.
Verwendet nicht für jede Datenbank denselben Table-Prefix und/oder dasselbe Passwort!
Es erspart keine Arbeit, immer dasselbe Datenbankpasswort zu vergeben – also tut das einfach nicht.
Bei WordPress heißen die Datenbanktabellen immer gleichartig, nur die “Vorsilbe” des Tabellennamens kann (und sollte) man unterschiedlich vergeben. Der Standardwert hier ist wp_ – die Tabellen heißen also normalerweise etwa wp_options oder wp_posts. Bei der manuellen Installation von WordPress kann man diesen Wert von wp_ auf etwas anderes ändern, etwa xyz_ oder eine Abkürzung der aktuellen Website. Das erschwert automatisierte Manipulationsversuche per Script, um etwa die Mailadresse des Admins oder die Mailadresse des ersten Benutzerkontos zu ändern. Das ist umso wichtiger, wenn mehrere Websites und damit mehrere Datenbanken im selben Account liegen – wenn jemand die Datenbank-Zugangsdaten hat, ist eine flächendeckende Änderung der Datenbanken mit wenigen Zeilen Code möglich.
Verwendet nicht für jede WordPress-Website denselben Benutzernamen und/oder dasselbe Passwort!
Es erspart auch keine Arbeit, immer denselben Benutzernamen und/oder dasselbe Passwort für alle Kundenwebsites zu verwenden. Es sieht auf den ersten Blick praktisch aus, öffnet aber eine massive Sicherheitslücke – denn wenn die Zugangsdaten einmal in falsche Hände geraten, dann sind dutzende Websites in Gefahr. Verwendet Passwortmanager wie LastPass, um die Zugangsdaten zu verwalten, dann besteht keine Notwendigkeit, immer dieselben Daten zu verwenden.
Gebt Zugangsdaten zur Website nicht an andere Personen weiter!
Wenn entweder die Kunden selbst oder andere Personen an der Website arbeiten sollen, dann legt für diese Personen immer eigene Benutzerkonten an. Diese Benutzerkonten sollten immer nur höchstens die Rolle zugewiesen bekommen, die für die Arbeit unbedingt nötig ist (siehe dazu die Übersicht der Benutzerrollen in WordPress). Erstens kann man so sehr einfach nachvollziehen, wer welche Änderungen an Seiten und Beiträgen durchgeführt hat. Zweitens kann man diese Benutzerkonten einfach löschen oder deaktivieren (Mailadresse UND Passwort ändern!), wenn dieser Mensch nicht mehr an der Website arbeiten können soll. Auch bei Websites von Neukunden, die ich zur Betreuung übernehmen soll, lasse ich mir ein eigenes Benutzerkonto anlegen – so brauchen Kunden nie ihre Zugangsdaten aus der Hand geben und können mir den Zugriff jederzeit wieder entziehen.
Legt für jede WordPress-Instanz eine eigene Datenbank an!
Klingt logisch, aber grade wenn die Zahl der Datenbanken limitiert ist (etwa in einem Resellerkonto, siehe weiter oben), legen manche Branchenkollegen dann tatsächlich mehrere WordPress-Installationen mit unterschiedlichen Table-Prefixes in eine Datenbank zusammen. Das ist keine gute Idee – wenn eine der Installationen gehackt wird, so kann sich Schadcode in allen Datenbanktabellen verbreiten. Man säubert dann also nicht nur eine WordPress-Instanz, sondern ALLE, die sich dieselbe Datenbank teilen. Und auch Plugins wie UpdraftPlus* oder Better Search Replace können natürlich auf alle Datenbanktabellen zugreifen, eine klare Trennung zwischen den Websites ist nicht mehr gegeben.
Weiters kann man dann manche komfortablen Tools wie z.B. Duplicator nicht mehr verwenden, die beim Umzug einer Website immer vor dem Anlegen der Datenbanktabellen die vorliegende Datenbank leeren!
Kundenwebsites gehören nicht in eine WordPress-Multisite!
Man kann ja WordPress recht einfach als Multisite-Installation konfigurieren, damit man mehrere unabhängige Websites mit einer einzigen WordPress-Installation betreiben kann. Es ist sehr verlockend, das für Kundenwebsites zu verwenden – tut das bitte nicht. Erstens zieht es die Performance aller damit betriebenen Websites nach unten, wenn auch nur eine einzige überdurchschnittlich viele Zugriffe bekommt – ohne Chance, das für die anderen Kunden zu verbessern. Und wenn ein Kunde den Dienstleister wechseln will, ist das Herauslösen einer einzelnen Website aus der Multisite-Umgebung in eine eigene WordPress-Instanz eine ziemliche Frickelei und echt pain-in-the-ass. Das will sich niemand freiwillig antun, denn es gibt keinen zuverlässigen automatisierten Weg dafür (auch wenn manche Plugins das versprechen!).
Gebt den Kunden Zugriff auf Theme-Updates!
Ihr habt für den Kunden die Website gebaut, ihr habt für ihn ein Theme gekauft und ihr habt es ihm verrechnet. Gebt dem Kunden auch Zugriff auf Updates! Entweder ihr kauft das Theme mit einem neu angelegten Account beim Theme-Anbieter und gebt dem Kunden die Zugangsdaten (die fairste Variante) oder stellt zumindest sicher, dass man auf der Kundenwebsite die Updates des Themes via API-Code durchführen kann. Diese Methode funktioniert etwa bei Themes von Themeforest gut (in einem anderen Blogpost lest ihr, wie man einen API-Code dafür generiert) oder bei Themes von Elegantthemes* (das populäre “Divi” ist etwa von denen). Wenn der Kunde den Dienstleister wechseln mag, dann lasst ihn doch und macht es ihm nicht unnötig schwer. Ihr kennt die Beweggründe meist nicht und Herumgezicke bringt niemandem etwas.
Natürlich sind das nur einige wenige Punkte, die mir akut gestern abend beim Säubern des Accounts meines Kunden aufgefallen sind, aber selbst damit kann man sich die Arbeit mit Kundenwebsite schon sehr erleichtern und erspart sich viele Troubles, wenn Mitarbeiter im Streit aus der Firma ausscheiden und auf Rache sinnen.
Wenn euch noch weitere Best-Practices im Umgang mit Kundenwebsites einfallen – dann ab damit in die Kommentare!
*Affiliate-Links
- Google Place ID herausfinden – oder: wie man direkt auf die Rezensionen-Eingabemaske verlinken kann! - Sa. 30.3.2024
- Rezension vs. Rezession - Mi. 27.12.2023
- Fröhliche Weihnachten! - So. 24.12.2023
Guter und wichtiger Beitrag! Sollte jeder WP-Neuling lesen und anwenden.