Webhosting Pro: mehrere Websites mit klaren Betriebsregeln

Aus mehreren Websites wird ein betreuter Bestand

Die Herausforderung eines kleinen Websitebestands liegt häufig in der Gleichzeitigkeit. Die Hauptwebsite wird redaktionell erweitert, eine Kampagnenseite erhält neue Bilder, ein drittes Projekt läuft mit älteren Erweiterungen und ein viertes braucht einen Export. Keines dieser Projekte ist für sich riesig. Zusammen entsteht dennoch ein Betrieb, in dem Änderungen, Laufzeiten und Ansprechpartner auseinanderlaufen können. Pro sollte deshalb anhand einer Bestandsliste bewertet werden. Sie enthält je Installation ihre Aufgabe, verantwortliche Person, externe Dienste und besonderen Schutzbedarf. Der Tarifrahmen ist erst dann sinnvoll vergleichbar, wenn diese Unterschiede sichtbar sind.

Ein Unternehmen mit mehreren Marken kann dieselbe technische Verwaltung nutzen und trotzdem getrennte redaktionelle Freigaben benötigen. Eine kleine Agentur muss zusätzlich klären, ob Kunden eigene Zugriffe erhalten dürfen und wie diese begrenzt werden. Eine Forschungseinrichtung kann Projekte mit unterschiedlicher Laufzeit haben, die zu verschiedenen Zeitpunkten archiviert werden. Gemeinsames Hosting schafft gemeinsame Betriebsaufgaben. Es hebt die fachlichen Grenzen zwischen den Websites nicht auf. In diesem Artikel betrachten wir deshalb den Bestand als Gruppe von Anwendungen mit konkreten Abhängigkeiten und nicht als Stapel austauschbarer WordPress-Kopien.

Der belegte Ressourcenrahmen

Auf der Originalbestellseite für Pro stehen fünf WordPress-Seiten, 75 GB NVMe-Speicher, 8 GB nutzbarer RAM, vier vCore und 40 Prozesse. Genannt werden außerdem hundert IMAP-Postfächer und eine kostenlose .de- oder .com-Domain. Das Angebot führt Verwaltungsfunktionen wie Toolkit, Staging, Git und SSH sowie Backups und Smart WordPress Updates auf. Diese Angaben beschreiben den angebotenen Umfang. Ob ein Limit je Installation, Konto oder anderer Einheit gilt, ist aus der kurzen Auflistung nicht vollständig ersichtlich und gehört in die konkrete Abnahme.

Die Webhostingübersicht des Anbieters nennt zum Teil andere CPU-Frequenzen als das Bestellsystem. Wir verwenden deshalb keine Frequenz als Prognose für die Performance einer Website. Auch ein daraus errechnetes Vielfaches gegenüber Starter wäre fachlich zu grob. Ein Cachetreffer, eine Anmeldung und ein Import stellen verschiedene Anforderungen. Für Preise müssen Steuerdarstellung, Monats- oder Jahreswahl, Mindestlaufzeit und Verlängerung in der endgültigen Bestellung geprüft werden. Hier verzichten wir auf einen Betrag, solange diese Kombination nicht eindeutig für das konkrete Angebot vorliegt. Auf diese Weise bleibt der Artikel eine Einordnung mit überprüfbaren Daten statt eines scheinbar verbindlichen Preisblatts.

Ein Inventar pro Installation verhindert blinde Flecken

Ein Bestandsinventar braucht keine komplizierte Software. Eine kleine Tabelle mit Domain, WordPress-Instanz, Hauptverantwortlichem, kritischer Funktion und letzten Änderungen reicht für den Anfang. Ergänzen Sie externe Mail-, Analyse-, Zahlungs- oder Identitätsdienste. Ein Link zum technischen Ansprechpartner ist hilfreicher als ein unkommentierter Pluginname. Die Tabelle sollte außerdem festhalten, welche Installation aktiv genutzt wird und welche nur als Archiv besteht. Unbenutzte Projekte erzeugen weiter Angriffsfläche und Pflegeaufwand. Entscheiden Sie bewusst über ihre Stilllegung, statt die erlaubte Zahl von Websites allein deshalb auszuschöpfen, weil der Tarif sie hergibt.

Unterscheiden Sie gemeinsame Standards von begründeten Ausnahmen. Vielleicht können alle Projekte dasselbe sichere Loginverfahren verwenden, während nur eine Anwendung eine besondere PHP-Version benötigt. Diese Ausnahme muss sichtbar werden, weil sie spätere Wartung beeinflusst. Eine neue Website erhält vor dem Start ihren eigenen Abnahmesatz. Kopieren Sie nicht ungeprüft Einstellungen eines alten Projekts mit falschen Absendern oder externen Schlüsseln. Die Verantwortung für den Bestand sollte bei einer Person liegen, die Projektgrenzen kennt und Entscheidungen dokumentiert. So lässt sich Pro als verwaltbarer Rahmen nutzen, auch wenn mehrere Redakteure und Entwickler beteiligt sind.

Gemeinsame Kapazität ohne Rechenillusion planen

Die Ressourcen des Angebots sollten nicht einfach durch fünf geteilt werden. Websites haben unterschiedliche Lastprofile, und ihre Spitzen treten nicht notwendigerweise zur selben Zeit auf. Eine kampagnengetriebene Website kann tagsüber stark nachgefragt werden, ein Import läuft nachts und eine interne Anmeldung benötigt vor allem verlässliche dynamische Antworten. Prüfen Sie am tatsächlichen Konto, wie Ressourcen zugeordnet und begrenzt werden. Fragen Sie nach Messmöglichkeiten, bevor Sie eine Überschreitung als Ursache behaupten. Die Gesamtzahl erlaubter Installationen ist keine Aussage darüber, ob jede beliebige Kombination von Anwendungen innerhalb des Tarifs zuverlässig arbeitet.

Eine brauchbare Planung beschreibt Lastarten statt erfundener Besucherzahlen. Dazu gehören öffentliche cachebare Seiten, nicht cachebare Nutzeraktionen, Hintergrundjobs und Verwaltungsarbeiten. Legen Sie große Jobs möglichst so, dass ihre fachlichen Fristen erfüllt werden und unnötige Überlagerungen vermieden werden. Eine zeitliche Trennung ist allerdings nur sinnvoll, wenn das Ergebnis überwacht wird. Verschieben Sie einen fehlgeschlagenen Import nicht einfach auf einen anderen Zeitpunkt und erklären ihn damit als behoben. Im Ratgeber Serverkapazität einordnen wird gezeigt, wie eine Beobachtung zur Entscheidung führt. Für Pro gilt dieselbe Sorgfalt, selbst wenn kein eigener Server verwaltet wird.

Änderungen am Bestand koordinieren

Wenn fünf Projekte unterschiedliche Plugins verwenden, ist ein gemeinsamer Updateknopf kein ausreichender Betriebsplan. Gruppieren Sie Änderungen nach Risiko und Abhängigkeit. Öffentliche Inhaltswebsites können einen einfachen Wartungssatz erhalten, während ein Projekt mit Anmeldung oder externen Formularen zusätzliche Prüfungen braucht. Notieren Sie vor einer Änderung den Ausgangszustand und den möglichen Rückweg. Mehrere gleichzeitige Änderungen erschweren die Ursache einer Störung. Deshalb empfiehlt sich für einen überschaubaren Bestand, Änderungen bewusst in Gruppen durchzuführen und dazwischen Ergebnisse zu prüfen. Das ist eine organisatorische Entscheidung, kein im Tarif behauptetes automatisches Verhalten.

Die Plesk-Dokumentation zum WP Toolkit erläutert Klonen und Updateprüfungen. Für Pro sollten Sie klären, welche Werkzeuge am Konto für jede Installation verfügbar sind und wie Lizenz- oder Installationsgrenzen wirken. Ein automatisch erzeugter Bericht lässt sich in den eigenen Prüfablauf aufnehmen. Danach folgen die fachlichen Aktionen: Anmeldung, Formular, Suche oder Download. Eine sichtbare Startseite kann korrekt sein, obwohl eine Hintergrundfunktion scheitert. Halten Sie deshalb pro Projekt wenige entscheidende Ergebnisse fest. Der Artikel WordPress-Updates sicher ausführen ergänzt diesen Ablauf um konkrete Abnahme- und Rückkehrpunkte.

Staging mit getrennten Daten und Empfängern

Eine Testkopie kann wertvoll sein, wenn mehrere Verantwortliche eine Änderung prüfen müssen. Sie ist aber eine eigene Installation mit eigenen Risiken. Schützen Sie ihren Zugriff vollständig, einschließlich Medien und Schnittstellen, und verhindern Sie ungewollte Nachrichten an echte Kunden. Wenn Produktionsdaten kopiert werden, legen Sie vorher fest, welche davon für den Test überhaupt nötig sind. Eine geschützte Kopie ist kein Freibrief für unbegrenzte Datenweitergabe. Auch externe Schnittstellen müssen im Testmodus stehen oder bewusst deaktiviert sein. Dokumentieren Sie, wer Zugriff erhält und wann die Kopie wieder gelöscht wird.

Im Pro-Bestand gibt es zwei besonders wichtige Fragen: Zählt die Testkopie zur erlaubten Installationsmenge, und welcher zusätzliche Speicherbedarf entsteht? Diese Punkte sollten vor einem größeren Update geklärt werden. Zudem darf eine alte Kopie nicht versehentlich zur späteren Quelle für aktuelle Produktionsdaten werden. Redaktionelle Änderungen, Bestellungen und Nutzereinträge können nach dem Klon weiterlaufen. Ein Rückspielen braucht daher einen klaren Umfang und eine Freigabe. Für reine Themeänderungen kann eine gezielte Übernahme sinnvoll sein; bei Datenbankänderungen ist die Situation genauer zu beurteilen. Entscheiden Sie anhand des Projekts und halten Sie den tatsächlich gewählten Weg fest.

Backupziele nach Projekten unterscheiden

Fünf Websites können unterschiedliche Wiederherstellungsziele haben. Ein öffentliches Archiv verträgt möglicherweise einen älteren Stand, eine Website mit neuen Anmeldungen braucht eine engere Datenbetrachtung. Fragen Sie beim Anbieter, welche Sicherungen für einzelne Installationen und welche für den gesamten Kontobestand verfügbar sind. Aus der Angebotsangabe täglicher Backups folgt weder eine bestimmte Aufbewahrungsfrist noch eine garantierte Rücksicherungszeit. Die benötigte Frist richtet sich auch danach, wann Fehler entdeckt werden. Ein durch ein Update beschädigter Download kann Tage unbemerkt bleiben, während ein Loginfehler sofort auffällt.

Planen Sie einen Restoretest für eine repräsentative Installation und beschreiben Sie dessen Reichweite. Werden Dateien und Datenbank zusammen geprüft, welche externen Daten bleiben außerhalb und wie wird ein wiederhergestellter Stand freigegeben? Die WordPress-Dokumentation zu Backups erinnert daran, dass beide Datenbereiche benötigt werden. Für Ihren Bestand zählt außerdem, dass eine Rücksicherung von Projekt A Projekt B nicht ungeprüft verändert. Falls das Verfahren eine gemeinsame Einheit betrifft, muss die Folge vorher bekannt sein. Unser Leitfaden RPO und RTO planen unterstützt dabei, gewünschte Ziele und tatsächlich vereinbarte Leistungen auseinanderzuhalten.

Zugriffe nach Arbeit statt nach Bequemlichkeit vergeben

Mehrere Websites führen leicht zu vielen geteilten Passwörtern. Ein Entwickler bekommt einmal einen Vollzugang, und Monate später ist unklar, ob er noch arbeitet. Richten Sie Rechte deshalb entlang der Aufgaben ein. Redakteure benötigen keine Verwaltung des gesamten Hostingbestands, und ein Auftragnehmer für eine einzelne Website soll nicht automatisch alle anderen sehen. Prüfen Sie, welche Trennung das konkrete Konto erlaubt. Die im Angebot genannten Zugänge beweisen noch nicht die gewünschte Isolation zwischen Projekten oder Benutzern. Wenn die Verwaltung diese Trennung nicht abbildet, ist die passende Struktur mit dem Anbieter zu klären.

Ein sinnvoller Zugangsplan enthält auch das Ende eines Auftrags. Welche Schlüssel und Konten werden entfernt, wer bestätigt die Übergabe und wo bleiben Quellcode und Dokumentation? Ein persönlicher Zugang verbessert die Zuordnung von Arbeiten, ersetzt aber keinen Freigabeprozess. Bei einer Notfallvertretung sollten die nötigen Informationen erreichbar sein, ohne Kennwörter in redaktionellen Dokumenten zu verteilen. Verwenden Sie einen geeigneten geschützten Aufbewahrungsweg. Die Rollenplanung nach dem Least-Privilege-Prinzip zeigt, wie sich Rechte klein halten lassen. Im Pro-Bestand verhindert dies vor allem, dass eine bequeme gemeinsame Verwaltung zu einer unkontrollierten gemeinsamen Veränderungsbefugnis wird.

Maildienste und Domains als eigenen Bestand führen

Die hundert genannten Postfächer wirken großzügig, sind aber keine Einladung zur unkoordinierten Kontoanlage. Halten Sie pro Domain fest, wo Mail empfangen und versendet wird, welche Konten aktiv sind und wer die Zustellregeln pflegt. Ein Projekt kann externen Mailbetrieb behalten, während eine zweite Domain die im Angebot genannten Postfächer verwendet. Ein Websiteumzug ändert diese Entscheidung nicht automatisch. Besonders bei mehreren Marken sollte eine Migration nicht versehentlich dieselben Absender, Antwortadressen oder Weiterleitungen übernehmen. Eine Kontoanlage braucht einen wirklichen Zweck und einen verantwortlichen Ansprechpartner.

DNS-Änderungen sollten die anderen Dienste einer Domain berücksichtigen. Prüfen Sie bestehende Einträge und dokumentieren Sie, welche davon für den Websitewechsel verändert werden. Wer nur die Website abnimmt, kann eine versehentlich unterbrochene Mailzustellung übersehen. Eine separate Testnachricht und ein kontrollierter Formularvorgang gehören daher in einen passenden Migrationsplan. Der Ratgeber DNS mit A und AAAA prüfen erklärt die Sicht auf die Webadressierung; Mailziele bleiben eigenständig zu untersuchen. In diesem Produkttext gibt es keine Zusage, dass jede vorhandene Versandkonfiguration automatisch übernommen oder jeder externe Dienst im Tarif betreut wird.

Störungen mit dem betroffenen Projekt benennen

Wenn ein Projekt nicht erreichbar ist, prüfen Sie zuerst die Reichweite. Sind alle Websites betroffen, nur eine Domain oder nur eine bestimmte Aktion? Ein gemeinsamer Hostingrahmen kann eine gemeinsame Ursache haben, muss es aber nicht. Das Pro-Inventar hilft, betroffene Installationen schnell zu benennen. Der Bericht an den Anbieter enthält URL, Zeitpunkt, Status oder Fehlertext und den letzten bekannten funktionierenden Zustand. Eine Meldung wie „alles langsam“ genügt selten für eine reproduzierbare Diagnose. Wenn nur ein Import scheitert, sollte dessen Verlauf getrennt von den öffentlichen Seiten beschrieben werden.

Benennen Sie außerdem die nächste Entscheidung. Kann eine geplante Änderung pausiert werden, gibt es einen brauchbaren vorherigen Stand oder wird der technische Ansprechpartner benötigt? Sammeln Sie vorhandene Hinweise, bevor ein Neustart oder ein erneutes Update die Situation verändert. Aus einem danach erfolgreichen Aufruf folgt noch keine bestätigte Ursache. Unser Incident-Runbook unterstützt einen nachvollziehbaren Ablauf. Für Pro ist besonders nützlich, Erreichbarkeit und wichtige Funktionen aller Projekte nach einer Maßnahme kurz erneut zu prüfen. Dadurch fällt auf, wenn die Wiederherstellung einer Website eine andere unbeabsichtigt beeinflusst hat.

Ein Praxisfall mit fünf unterschiedlichen Aufgaben

Stellen wir uns ein Unternehmen mit Hauptwebsite, Karriereportal, Veranstaltungsseite, Fachblog und regionalem Projekt vor. Pro ist durch die angebotene Installationszahl eine mögliche Auswahl, sofern der tatsächliche Ressourcenbedarf und die Betriebsgrenzen passen. Jede Website bekommt jedoch ihren eigenen Zweck und Kontakt. Das Karriereportal braucht funktionierende Bewerbungswege, die Veranstaltungsseite eine kontrollierte Aktualisierung und der Fachblog gepflegte Redaktion. Eine gemeinsame Grundlage für Updates ist sinnvoll, aber die Abnahmen unterscheiden sich. Den ungenutzten regionalen Entwurf sollte das Team nicht auf Dauer liegen lassen, sondern abschließen oder geschützt archivieren.

Der Betreiber plant Änderungsfenster, speichert Prüfberichte und dokumentiert die Zustellung der kritischen Formulare. Er legt fest, wie ein einzelnes Projekt zurückgesichert wird und welche Rechte externe Entwickler besitzen. Nach einem erfolgreichen Wartungslauf werden die Ergebnisse je Website eingetragen. Dieses Beispiel beweist keine Eignung des Tarifs für jede solche Kombination. Es zeigt, wie die angebotenen Ressourcen und die benötigten Leistungen getrennt geprüft werden können. Wenn eine tatsächliche Grenze entsteht, lässt sich ein Vergleich mit Webhosting Business anhand des Bedarfs durchführen, ohne die größeren Zahlen als automatischen Ersatz für organisatorische Qualität zu behandeln.

Vor der Bestellung eine konkrete Übergabe vereinbaren

Pro sollte mit einem vollständigen Fragenkatalog bestellt werden. Dazu gehören Zählweise der Installationen, Geltung der Ressourcen, Trennung der Zugänge und Restoreumfang pro Projekt. Klären Sie außerdem, wie Unterstützung bei einer Migration abläuft und welche Anwendungsprüfungen enthalten sind. Halten Sie Antworten nicht nur mündlich fest, wenn sie für die Auswahl entscheidend sind. Für Uptime und Support interessieren Messbedingungen, Wartung, Reaktion und Eskalation. Aus einer allgemeinen Werbeaussage lässt sich keine individuelle Wiederherstellungszusage für den gesamten Websitebestand ableiten. Ein nachvollziehbarer Betrieb braucht solche Angaben an der Stelle, an der Verantwortung übernommen wird.

Sie können Webhosting Pro im Originalbestellsystem konfigurieren. Prüfen Sie dort den vollständigen Endpreis mit Steuer, Zahlungsintervall, Mindestlaufzeit und Verlängerung. Nach der Bereitstellung folgt eine technische Abnahme des tatsächlichen Kontos; erst dann ist die Umgebung für Ihre Projekte verifiziert. Die Produktvorstellung liefert dafür eine Struktur und konkrete Entscheidungsfragen. Ihr Wert liegt im Zusammenhang zwischen Angebot, Bestandsführung und sichtbarem Ergebnis. Fünf Websites bleiben beherrschbar, wenn gemeinsame Ressourcen bewusst genutzt werden und jedes Projekt seine Zuständigkeiten, Prüfungen und Rückwege behält.

Hintergrundjobs als Bestandteil des Bestands dokumentieren

Ein kleiner Websitebestand sammelt häufig Aufgaben, die im Browser unsichtbar bleiben. Ein Projekt importiert Termine, ein anderes erstellt einen Suchindex und ein drittes löscht abgelaufene temporäre Daten. Notieren Sie solche Jobs im gleichen Inventar wie die Websites. Jede Aufgabe erhält einen Zweck, ein vorgesehenes Intervall und ein erkennbares Ergebnis. Die Zahl der Aufgaben allein sagt wenig über ihre Wirkung aus. Ein selten ausgeführter aufwendiger Export kann den gemeinsamen Ressourcenrahmen stärker beanspruchen als viele kurze Routinen. Eine Verschiebung des Zeitplans braucht deshalb eine bewusste fachliche Begründung und eine anschließende Prüfung.

Klären Sie die verwendete Laufzeit und die Rechte des ausführenden Kontos. Eine Aufgabe kann im Scheduler mit einer anderen PHP-Konfiguration laufen als ein normaler Seitenaufruf. Verwenden Sie vollständige, dokumentierte Pfade und prüfen Sie die Zeitzone. Die Plesk-Dokumentation für geplante Aufgaben beschreibt unterschiedliche Ausführungstypen. Der verfügbare Scheduler ist allerdings nur das Werkzeug. Ob die Aufgabe ihre Daten verarbeitet und kontrolliert beendet wird, muss der Betreiber anhand der eigenen Anwendung erkennen. Ein Eintrag mit erfolgreichem Start ist dafür noch kein vollständiger Nachweis.

Bei parallelen Aufgaben lohnt ein eigener Ausführungsplan. Verhindern Sie, dass eine lange Aufgabe erneut startet, obwohl der vorherige Lauf noch arbeitet. Der geeignete Schutz hängt von der Anwendung ab und sollte durch deren Verantwortlichen festgelegt werden. Bei einem Umzug werden Jobs zunächst bewusst geprüft und anschließend aktiviert. Eine alte Umgebung darf denselben produktiven Import nicht weiter auslösen. Halten Sie auch den Weg zur Abschaltung fest, falls ein Job unerwartet Daten verändert oder Speicher füllt. Für die WordPress-Seite dieser Arbeit steht unser Ratgeber Cron im Betrieb zur Verfügung. Die Dokumentation macht aus Hintergrundarbeit eine übergebbare Aufgabe und hilft, den tatsächlichen Bedarf des Pro-Tarifs zu beurteilen.