Webhosting Pro

Mehrere Projekte brauchen einen geordneten Betriebsrahmen

Wenn eine Agentur mehrere Unternehmensauftritte betreut, verändert sich die Hostingfrage. Nicht allein die Größe einer Website ist entscheidend. Verschiedene Redaktionen, voneinander unabhängige Veröffentlichungen und gemeinsame Wartungstermine müssen zusammenpassen. Ein Paket mit Platz für mehrere Installationen kann diese Arbeit bündeln. Gleichzeitig entsteht ein gemeinsamer Rahmen, in dem Ressourcen, Zugänge und Zuständigkeiten sorgfältig getrennt werden sollten.

Webhosting Pro der webhoster.de AG ist dafür ein möglicher Rechercheeinstieg. Der frisch geprüfte Bestelleinstieg nennt fünf WordPress-Seiten und größere Ressourcenzahlen als Starter. Die redaktionell sinnvolle Frage lautet daher: Welche Projekte sollen sich diesen Rahmen teilen, und welche Abhängigkeiten sind dabei vertretbar? Eine Firmenwebsite, ein Kampagnenauftritt und ein redaktioneller Wissensbereich können technisch ähnlich aussehen, haben aber unterschiedliche Freigaben und Änderungsrhythmen.

Die Tarifbezeichnung entscheidet nicht darüber, ob Kundenprojekte gemeinsam betrieben werden sollten. Zunächst müssen Verträge, Berechtigungen, Übergaben und mögliche spätere Trennungen bedacht werden. Ein Projekt kann nach einem Jahr zu einer anderen Betreuung wechseln. Wenn Dateien, Zugangsdaten und fachliche Zuständigkeiten von Beginn an klar zugeordnet sind, lässt sich eine solche Übergabe besser vorbereiten.

Dieses Dossier ordnet das Angebot für technische Verantwortliche ein. Es enthält keine gemessene Lastgrenze und keine eigene Anbietererfahrung. Die Beispiele dienen der Planung. Wer ein einzelnes, überschaubares Projekt betreut, sollte auch Starter prüfen. Wer größere organisatorische oder dynamische Anforderungen hat, findet bei Business weitere Fragen für den Vergleich.

Der aktuelle Tarifstand gehört in die Projektakte

Am 7. Oktober 2026 nennt der Pro-Shop 75 GB NVMe-Speicher, 8 GB nutzbaren RAM, vier vCore, 40 Prozesse und fünf WordPress-Seiten. Hundert IMAP-Postfächer und eine kostenlose .de- oder .com-Domain stehen ebenfalls in der Produktbeschreibung. Diese Liste bestätigt das öffentliche Angebot am Recherchetag. Sie beschreibt weder eine gemessene Lastreserve noch die Verteilung dieser Werte auf einzelne Installationen.

Die Marketingseite zeigt andere sichtbare Monatsbeträge als der Shop und erklärt enthaltene Umsatzsteuer. Die erste Shopansicht weist den Steuerstatus nicht eindeutig aus. Auch der CPU-Takt unterscheidet sich zwischen Übersicht und Bestellung: mindestens 4,1 gegenüber 4,2 GHz. Ein vollständiges Angebot muss deshalb in der konkreten Bestellkonfiguration oder schriftlich geprüft werden. Der rechnerisch naheliegende Steuerzusammenhang wird hier nicht als bestätigte Checkout-Regel behandelt.

Für eine Agentur empfiehlt sich ein datierter Eintrag im Projektordner. Dort stehen Tarifname, ausgewählte Optionen und die beantworteten Rückfragen. Allgemeine Werbeaussagen zu Verfügbarkeit oder Sicherung bleiben von bestätigten Vertragsbedingungen getrennt. So kann später nachvollzogen werden, welche Entscheidung auf welcher Information beruhte.

Beziehen Sie auch die fachliche Betreuung ein. Eine Redaktion kann beispielsweise einen saisonalen Veröffentlichungstermin kennen, den die technische Planung bisher nicht berücksichtigt. Solche Informationen erklären erwartete Belastung und notwendige Erreichbarkeit besser als eine abstrakte Einstufung als Unternehmenswebsite. Im Projektprotokoll stehen diese Annahmen neben den Tarifwerten, damit spätere Änderungen erneut bewertet werden können.

Ein Paket ist keine automatische Aufteilung pro Website

Mehrere Installationen in einem Tarif bilden zunächst einen gemeinsamen Ressourcenrahmen. Aus der Angabe „fünf WordPress-Seiten“ folgt nicht, dass jede Installation ein Fünftel des Arbeitsspeichers oder einen exklusiven Rechenkern erhält. Für die Planung muss geklärt werden, welche Limits für die Subscription gelten und ob einzelne Bereiche zusätzlich begrenzt werden können. Erst dann wird sichtbar, wie ein aufwendiger Vorgang eines Projekts die übrigen beeinflussen könnte.

Ein typisches Planungsbeispiel sind vier Informationsseiten und ein regelmäßig aktualisierter Produktkatalog. Der Katalog importiert Daten, während die Redaktionen der übrigen Seiten Bilder hochladen. Die durchschnittliche Besuchsmenge erklärt diese gleichzeitige Arbeit kaum. Benötigt werden Informationen über Dauer, Häufigkeit und Ressourcenbedarf der relevanten Tätigkeiten. Solche Beobachtungen müssen aus den Anwendungen stammen; sie lassen sich nicht aus der Zahl der gebuchten Seiten berechnen.

Der Ratgeber zum Ressourcenmodell hilft, Dateispeicher, Arbeitsspeicher und parallele Prozesse voneinander zu unterscheiden. Für Pro kommt eine organisatorische Ebene hinzu: Welche Arbeit darf wann stattfinden? Ein Import lässt sich möglicherweise in ein ruhigeres Zeitfenster legen. Die Bearbeitung einer Kundenwebsite sollte trotzdem nicht davon abhängen, dass niemand eine andere Seite benutzt.

Eine Ressourcentabelle pro Projekt macht die Verteilung nachvollziehbar. Erfassen Sie erwarteten Speicherbedarf, dynamische Funktionen, geplante Aufgaben und verantwortliche Personen. Ein wachsendes Projekt erhält einen eigenen Auszug aus dieser Tabelle. Sobald eine Installation den gemeinsamen Betrieb regelmäßig prägt, sollte ihre Trennung geprüft werden. Ein solcher Schritt kann mehr Klarheit schaffen als das bloße Vergrößern des gemeinsamen Pakets.

Zugänge so anlegen, dass eine Übergabe möglich bleibt

Für technische Teams ist die Zugriffsgestaltung häufig wichtiger als die Zahl verfügbarer Installationen. Kundenredaktionen sollen ihre Inhalte pflegen können, ohne Zugriff auf andere Projekte zu erhalten. Entwickler benötigen nachvollziehbare Zugänge für ihre Aufgaben. Die Person, die den Hostingvertrag verwaltet, hat wiederum eine andere Rolle. Diese Ebenen dürfen in der alltäglichen Arbeit nicht in einem einzigen gemeinsam verwendeten Passwort verschwinden.

Beginnen Sie mit persönlichen WordPress-Konten und passenden Rollen je Installation. Halten Sie fest, welche Funktionen eine Redaktion tatsächlich braucht. Ein Redakteur muss nicht automatisch Erweiterungen installieren können. Vorübergehende Entwicklerzugänge erhalten einen geplanten Endtermin. Die genaue technische Trennung zusätzlicher Hosting-, Datei- und Datenbankkonten ist mit der tatsächlichen Oberfläche zu prüfen. Dieses Dossier behauptet keine hier nicht kontrollierte Berechtigungsfunktion.

Für eine spätere Übergabe sollte jedes Projekt einen eigenen Datenbestand, dokumentierte Anwendungseinstellungen und eindeutig zugehörige externe Dienste besitzen. Gemeinsame Analyse-, Mail- oder Lizenzkonten können die Trennung erschweren. Ob gemeinsame kommerzielle Erweiterungslizenzen zulässig sind, ergibt sich aus deren Bedingungen und nicht aus dem Hostingtarif. Bei dieser Frage sind die jeweiligen Herstellerangaben maßgeblich.

Trennbarkeit ist ein Auswahlkriterium. Stellen Sie sich vor der Einrichtung einen möglichen Wechsel der Betreuung vor. Könnte die betreffende Website mit ihren Daten und Dokumenten an ein neues Team übergeben werden, ohne Informationen anderer Kunden mitzunehmen? Wenn die Antwort unklar ist, sollte die Betriebsstruktur zuerst verbessert werden. Der Leitfaden zu Zuständigkeiten macht aus Rollen konkrete Aufgaben.

Laufzeitumgebungen einzeln prüfen statt pauschal übernehmen

Fünf WordPress-Projekte können unterschiedliche technische Voraussetzungen haben. Eine aktuelle Standardinstallation und ein älteres individuell entwickeltes Theme reagieren möglicherweise verschieden auf denselben PHP-Wechsel. Eine gemeinsame Hostingentscheidung sollte diese Unterschiede offenlegen. Notieren Sie deshalb pro Website die verwendete Laufzeit, wichtige Erweiterungen und besondere Aufgaben. Die Möglichkeit einer Versionsauswahl allein bestätigt noch keine passende Kombination für alle Projekte.

Die Anbieterübersicht nennt einen PHP-Selector mit „8+“. Welche Versionen im konkret eingerichteten Paket auswählbar sind und welche Erweiterungen bereitstehen, ist gesondert zu bestätigen. Der Ratgeber zur Laufzeitumgebung beschreibt eine Bestandsaufnahme. Für Agenturen empfiehlt sich eine kompakte Kompatibilitätsmatrix: Projekt, aktueller Stand, vorgesehener Zielstand, Testergebnis und zuständige Person.

Ein Versionswechsel sollte nicht nur die öffentliche Startseite prüfen. Administrative Abläufe, Dateiimporte, geplante Aufgaben und Anbindungen können eigene Codepfade verwenden. Ein Theme mag sichtbar korrekt aussehen, obwohl ein später aufgerufener Export scheitert. Wählen Sie deshalb repräsentative Tätigkeiten aus dem tatsächlichen Projekt. Automatische Prüfungen können dabei unterstützen, fachliche Abnahmen bleiben eine zusätzliche Aufgabe.

Auch beworbene Git- und SSH-Funktionen benötigen einen definierten Nutzen. Werden nur Theme-Dateien versioniert, oder sollen zusätzliche Werkzeuge laufen? Welche Befehle und Ressourcen sind erlaubt? Ein SSH-Zugang ist kein Nachweis eigener Systemadministration. Für Pro sollten die täglichen Entwicklungsaufgaben innerhalb der bestätigten Umgebung bleiben. Andernfalls muss geprüft werden, ob ein anderes angebotenes Betriebsmodell die Anforderungen besser abdeckt.

Ein wiederkehrender Wartungstermin sollte außerdem selten verwendete Funktionen berücksichtigen. Manche Projekte erzeugen nur einmal im Monat einen Bericht oder aktualisieren einen besonderen Inhaltsbereich. Wenn die Betreuung ausschließlich die Startseite prüft, bleibt dieser Teil unbestätigt. Ergänzen Sie deshalb je Website einen repräsentativen Sondervorgang und dessen fachlich erwartetes Ergebnis. Bei der nächsten Übergabe kann ein neuer Bearbeiter anhand dieser Notiz verstehen, warum gerade dieser Ablauf wichtig ist. Die gemeinsame Umgebung wird so zu einem planbaren Arbeitsrahmen, in dem die Unterschiede der einzelnen Installationen erhalten bleiben. Das erleichtert sowohl die Fehlersuche als auch eine spätere Trennung eines Kundenprojekts.

Staging als Teil einer wiederholbaren Freigabe

Mit mehreren Websites wird die Änderungskontrolle zu einem wiederkehrenden Prozess. Eine Agentur aktualisiert vielleicht denselben Grundbestand an Erweiterungen, muss aber unterschiedliche Inhalte und Funktionen prüfen. Die Anbieterbeschreibung nennt Staging und Aktualisierungswerkzeuge. Der Nutzen entsteht daraus, dass jede relevante Änderung einen nachvollziehbaren Weg von der Vorbereitung zur öffentlichen Anwendung erhält. Ein vorhandener Knopf zum Klonen ist erst der Anfang.

Die Kopie benötigt einen Zweck und eine klare Lebensdauer. Wird ein neues Theme vorbereitet, reicht es nicht, die aktuelle Datenbank später ungeprüft über die öffentliche Installation zu schreiben. Währenddessen könnten dort neue Inhalte entstanden sein. Definieren Sie, welche Dateien, Einstellungen und Daten zurückgespielt werden sollen. Der WordPress-Leitfaden für Staging und Freigabe erklärt die wichtigsten Konflikte.

Schützen Sie Testkopien vor ungewollter Nutzung. Persönliche Daten gehören nur dann hinein, wenn die konkrete Prüfung sie erfordert und der Schutz geregelt ist. Echte Versandwege und externe Schreibaktionen können in einer Kopie unerwünschte Folgen haben. Ob Sie diese deaktivieren oder auf eine Testumgebung umstellen, wird je Anwendung entschieden. Ein Suchmaschinenhinweis ersetzt eine Zugriffssperre dabei nicht.

Für Pro kann ein kurzer Freigabevermerk pro Projekt genügen: Änderung, geprüftes Datum, geprüfte Funktionen und freigebende Person. Bei einer gemeinsamen Wartungsaktion bleiben die Ergebnisse getrennt. Das verhindert, dass der erfolgreiche Test einer Website irrtümlich für die übrigen gilt. Ebenso sollte eine fehlerhafte Änderung eines Projekts den restlichen Wartungsplan nicht automatisch blockieren.

Speicherwachstum und Mailbetrieb getrennt planen

Die genannten 75 GB eröffnen einen größeren Dateirahmen als Starter. Für mehrere Projekte sollten Sie den Platz dennoch nach Nutzung betrachten. Ein fotografischer Auftritt kann mit relativ wenig Inhalt viele große Dateien enthalten. Ein Textportal kann mehr Datenbankeinträge haben, aber weniger Medienvolumen. Lokale Archive und Staging-Kopien verändern das Bild zusätzlich. Eine Zahl für das gesamte Paket ist deshalb nur der Ausgangspunkt.

Legen Sie für jede Installation eine einfache Wachstumsnotiz an. Welche Dateien kommen regelmäßig hinzu? Wer entscheidet, ob alte Inhalte archiviert oder gelöscht werden? Welche Reserve braucht ein größerer Import? Erfassen Sie die tatsächliche Entwicklung nach vereinbarten Intervallen. Daraus entsteht eine begründete Entscheidung, wann ein Projekt zusätzlichen Raum oder einen eigenen Betriebsbereich benötigt. Pauschale Annahmen über durchschnittliche Websitegrößen helfen dabei wenig.

Die hundert genannten Postfächer sind eine Kapazitätsangabe, keine Empfehlung, den Mailbetrieb ohne Planung mitzunehmen. Ein Unternehmen kann bereits einen externen Maildienst verwenden. Dann bleiben MX-Einträge und zugehörige Authentifizierungsrecords in dessen Verantwortungsbereich. Bestehende Postfächer werden beim Websiteumzug nicht automatisch Teil desselben Auftrags. Prüfen Sie die Anrechnung von Maildaten auf den Speicherrahmen schriftlich.

Mailzuständigkeit und Websitebetrieb sollten auch im Supportfall unterscheidbar sein. Wenn ein Formular keine Nachricht erzeugt, sind Anwendungslogik, Versandweg und empfangendes System getrennt zu prüfen. Ein vorhandenes Postfach beweist keine korrekte Zustellung. Für ein Kundenprojekt empfiehlt sich deshalb eine dokumentierte Abnahme des tatsächlich verwendeten Kontaktwegs. Diese Prüfung ist eine Betriebsaufgabe und kein auf dieser Seite behaupteter Anbieterleistungstest.

Sicherungen pro Projekt auffindbar und verwendbar halten

Ein gemeinsames Hostingpaket braucht einen Wiederherstellungsplan, der einzelne Websites klar benennt. Die offiziellen Produktangaben nennen tägliche und anlassbezogene Backups. Für die Praxis müssen Aufbewahrung, Wiederherstellung und Zuständigkeit genauer geklärt werden. Insbesondere ist wichtig, ob ein einzelnes Projekt zurückgesetzt werden kann und welche Daten dabei betroffen sind. Ein Vollrestore des Pakets könnte sonst unabhängige Änderungen anderer Websites zurücknehmen.

Ordnen Sie Sicherungen nach Website, Zeitpunkt und Anlass. Eine Sicherung vor einem Themewechsel hat einen anderen Kontext als eine reguläre nächtliche Kopie. Der zuständige Bearbeiter sollte wissen, welche davon für einen konkreten Fehler geeignet ist. Dabei braucht es keine im öffentlichen Webverzeichnis liegenden Archive. Sicherungsdaten und Zugangsdaten werden geschützt verwahrt und nur dem passenden Projektteam zugänglich gemacht.

Ein Test der Wiederherstellung sollte eine ausgewählte Installation in einer geschützten Umgebung rekonstruieren. Kontrollieren Sie anschließend Dateien, Inhalte, Benutzer und wichtige Funktionen. Ein erfolgreicher Download eines Archivs ist kein vollständiger Test. Wenn das Projekt regelmäßige neue Inhalte erzeugt, muss außerdem der mögliche Datenverlust seit dem Sicherungszeitpunkt verständlich sein. Diese fachliche Entscheidung kann der Betreiber nicht allein an ein Werkzeug delegieren.

Für Agenturen gehört die Sicherungsvereinbarung in die Kundenübergabe. Wer darf einen Restore beauftragen? Wer gibt den gewählten Stand frei? Welche Inhalte müssen danach erneut eingetragen werden? Ohne diese Antworten kann eine technisch funktionierende Wiederherstellung organisatorisch scheitern. Aus der öffentlichen Tarifbeschreibung leiten wir weder eine feste Wiederherstellungszeit noch einen bestimmten Aufbewahrungszeitraum ab.

Mehrere Umzüge als Folge einzelner Abnahmen durchführen

Wenn mehrere Websites auf Pro wechseln sollen, ist eine gestaffelte Übernahme oft leichter zu kontrollieren. Beginnen Sie mit einem repräsentativen Projekt, dessen Funktionen gut bekannt sind. Prüfen Sie dort den Übertragungsweg und die Zielumgebung. Ein erfolgreicher erster Umzug ist wertvoll, bestätigt aber nicht automatisch jedes weitere Projekt. Unterschiede in Dateimengen, Erweiterungen und externen Diensten bleiben sichtbar.

Die Anbieterübersicht bewirbt Unterstützung beim Websiteumzug. Vereinbaren Sie den Umfang für jede Installation. Soll nur die Anwendung übertragen werden, oder gehören Postfächer, DNS und Weiterleitungen dazu? Eine vorhandene Domain kann auf einen externen Maildienst zeigen, während die Website ihren Server wechselt. Der DNS-Leitfaden hilft, diese Wege nicht zu vermischen.

Für jede Website braucht es einen Abnahmekatalog und einen Zeitpunkt der letzten Datenübernahme. Bleiben Redaktionen während des Prozesses aktiv, muss klar sein, auf welcher Umgebung sie arbeiten. Ein Projekt wird erst umgeschaltet, wenn seine Kopie geprüft ist und ein Rückweg besteht. Der Migrationsratgeber erläutert die technischen Bausteine. Die Zeitplanung folgt dem tatsächlichen Umfang und keiner pauschalen Werbeaussage.

Nach der Umschaltung sollten mehrere Beteiligte denselben Stand sehen. Prüfen Sie öffentliche Verbindungen, Zertifikat und wichtige Unterseiten. Kontrollieren Sie anschließend Fehlerprotokolle und die vereinbarten dynamischen Aufgaben. Ein Umzug ist erst abgeschlossen, wenn Betrieb und Zuständigkeit übergeben wurden. Die alte Umgebung wird nach bestätigter Abnahme und vereinbarter Aufbewahrung geordnet stillgelegt.

Pro wählen, wenn Bündelung auch organisatorisch passt

Webhosting Pro kann in die engere Auswahl kommen, wenn mehrere WordPress-Projekte einen gemeinsamen betreuten Rahmen benötigen und dessen belegte Ressourcen ausreichen. Der Mehrwert liegt dann sowohl im Ressourcenangebot als auch in einer gut organisierten Pflege. Das Paket ist jedoch nicht automatisch die richtige Struktur für jedes Agenturportfolio. Besonders vertrauliche, stark wachsende oder vertraglich getrennte Projekte können einen eigenen Bereich benötigen.

Bewerten Sie die Bündelung anhand dreier Fragen. Lassen sich Zugänge sicher zuordnen? Können Wartung und Wiederherstellung je Projekt durchgeführt werden? Ist eine spätere Trennung praktikabel? Dazu kommt die technische Prüfung der aktuellen Last und Umgebung. Eine fehlende Antwort wird als offene Frage dokumentiert, bevor die Bestellung erfolgt. Der Anforderungsleitfaden hilft, aus diesen Fragen eine konkrete Entscheidungsvorlage zu machen.

• Projekte mit eigenem Verantwortlichen und Datenbestand erfassen.
• Gemeinsame Ressourcen und einzelne Engpässe beobachten.
• Zugänge, Sicherungen und Übergaben pro Website abnehmen.

Der Vergleich mit Business sollte sich auf einen belegbaren Bedarf richten. Mehr Installationen oder größere Ressourcenzahlen können relevant sein. Sie sagen jedoch wenig über die passende Trennung unterschiedlicher Kunden aus. Wenn ein einzelnes Projekt ständig die Grenzen des Pakets bestimmt, kann seine Auslagerung sinnvoller sein als ein pauschales Upgrade für alle. Für zusätzliche Systemanforderungen müssen zudem die angebotenen Managed-Server-Produkte geprüft werden.

Nutzen Sie den originalen Pro-Bestelleinstieg der webhoster.de AG erst mit einer vollständigen Projektliste. Prüfen Sie Optionen, Laufzeit und endgültigen Steuerbetrag. Die redaktionelle Einordnung unterstützt diesen Vorgang, bestätigt jedoch weder eine Vertragskonfiguration noch eine erreichbare Leistungsgrenze. Eine gute Auswahl bleibt an den tatsächlichen Anwendungen und einer verständlichen Betriebsorganisation überprüfbar.