Webhosting-Vergleich für Unternehmen: die Kriterien statt der Bestenliste

Ein Webhosting-Vergleich für Unternehmen entscheidet sich nicht am Monatspreis, sondern am Betriebsmodell: Shared Hosting, VPS oder Root-Server, Managed Hosting und Cloud unterscheiden sich vor allem darin, wer das System patcht und wer bei einem Ausfall gerade steht. Die zweite Prüfung gilt den Anforderungen Ihres Shopsystems — und der Frage, wie schnell ein Backup wieder eingespielt ist.

1. Warum die üblichen Webhosting-Vergleiche für Unternehmen nichts taugen

Wer heute nach einem Webhosting-Vergleich sucht, landet auf Bestenlisten. Wir haben uns die ersten zwanzig Google-Ergebnisse zu diesem Suchbegriff am 4. September 2026 angesehen: Es sind ausnahmslos Anbieter-Rankings, Preisvergleichsportale mit Sternebewertung oder Anbieterseiten, die sich selbst mit anderen vergleichen. Das ist kein Vorwurf — es ist ein Geschäftsmodell. Nur passt es nicht zu Ihrer Frage.

Der Grund liegt im Vergleichsmaßstab. Diese Listen vergleichen, was sich tabellarisch nebeneinanderstellen lässt: Preis pro Monat, Speicherplatz, Anzahl Domains, Anzahl Postfächer. Das sind die Kriterien für eine private Website oder ein kleines Projekt. Für einen Shop mit Warenwirtschaft entscheidet aber etwas anderes:

• Was verglichen wird: Einstiegspreis, Webspace in Gigabyte, Domain-Anzahl, ein Sternewert, gelegentlich eine Ladezeit-Messung des Anbieters selbst.
• Was nicht verglichen wird: ob das Shopsystem seine Mindestversionen überhaupt vorfindet, wer Betriebssystem und Dienste patcht, wie schnell ein Backup zurückgespielt ist, ob Cronjobs im nötigen Takt laufen, ob ausgehende Mails ankommen, ob es eine Staging-Umgebung gibt und wer bei einem Ausfall haftet.

Deshalb finden Sie hier keine Empfehlungsliste, keinen Testsieger und keine Sternebewertung. Wir nennen auch keine Preise, weil sie sich laufend ändern und ohne Vertragslaufzeit und Leistungsumfang nichts aussagen. Stattdessen bekommen Sie die Kriterien, mit denen Sie zwei Angebote selbst gegeneinanderhalten können — und die Sie als Anforderungsliste in ein Anbietergespräch mitnehmen können.

Ein Hinweis noch, damit die Erwartung stimmt: Eine allgemeingültige Antwort auf „Welcher Anbieter ist der beste?" gibt es nicht, weil die Frage die falsche ist. Sinnvoll wird sie erst als „Welches Betriebsmodell passt zu meiner Aufgabe und zu dem, was mein Team leisten kann?". Genau dort fangen wir an.

• Für wen dieser Beitrag geschrieben ist: Unternehmen mit Onlineshop, Warenwirtschaft und Prozessen, die vom Hosting abhängen.
• Was Sie am Ende haben: eine Anforderungsliste und die Fragen, die ein Angebot beantworten muss, bevor Sie unterschreiben.
• Was Sie nicht bekommen: ein Ranking, eine Kaufempfehlung oder einen Link, an dem wir verdienen.

2. Die vier Betriebsmodelle: Shared, VPS, Managed und Cloud

Hosting-Angebote lassen sich auf vier Betriebsmodelle zurückführen. Sie unterscheiden sich nicht in erster Linie durch Leistung oder Preis, sondern durch die Verteilung der Verantwortung. Die beiden rechten Spalten der folgenden Tabelle sind deshalb die wichtigsten: Wer hält das System aktuell, und wer ist zuständig, wenn es steht?

Zwei Beobachtungen aus unseren Projekten, die in keiner Tarifübersicht stehen. Die erste betrifft den VPS: Er wird oft gewählt, weil er günstiger wirkt als Managed Hosting und mehr Freiheit verspricht als ein Shared-Paket. Beides stimmt. Was dabei untergeht, ist die Betriebsverantwortung, die damit im Haus landet. Ein Root-Server ohne benannte zuständige Person ist kein Sparmodell, sondern eine offene Flanke — Sicherheitsaktualisierungen erscheinen unabhängig davon, ob gerade jemand Zeit hat.

Die zweite betrifft das Wort „managed". Es ist nicht geschützt und bedeutet bei jedem Anbieter etwas anderes. Bei dem einen umfasst es Betriebssystem, Serverdienste, Monitoring und Backups; bei dem anderen nur die Basisinstallation. Lassen Sie sich in der Leistungsbeschreibung zeigen, bis wohin der Anbieter zuständig ist und ab wo Ihre Anwendung beginnt — diese Grenze ist der eigentliche Vertragsgegenstand.

Cloud beziehungsweise IaaS schließlich löst ein Problem, das viele Mittelständler gar nicht haben. Elastische Skalierung lohnt sich, wenn die Last stark und unregelmäßig schwankt. Bei planbaren Spitzen wie einer Aktionswoche ist ein größerer Tarif für diesen Zeitraum meist einfacher und billiger. Und Elastizität wirkt in beide Richtungen: ohne Kostenwarnung wird die Monatsrechnung zum Zufallsprodukt.

3. Was Ihr Shopsystem wirklich vom Server verlangt

Bevor Sie Tarife vergleichen, holen Sie die Systemanforderungen Ihres Shopsystems aus der Hersteller-Dokumentation. Das ist der Schritt, der in Vergleichsportalen fehlt — und der die Auswahl am stärksten einschränkt. Die folgenden Angaben stammen aus der jeweiligen Hersteller-Dokumentation, abgerufen am 4. September 2026. Prüfen Sie sie zum Zeitpunkt Ihrer Auswahl erneut, weil Mindestversionen mit jedem größeren Release nachziehen.

Die Tabelle zeigt, warum „PHP 8.3 wird unterstützt" im Tarifblatt keine Aussage ist. Für JTL-Shop verlangt die Hersteller-Dokumentation zusätzlich, dass der Webserver das Überschreiben von Standardregeln erlaubt — also aktivierte .htaccess-Overrides. Genau das ist auf günstigen Paketen gelegentlich eingeschränkt, und man merkt es erst, wenn der Verzeichnisschutz nicht greift. Dazu kommen konkrete PHP-Grenzwerte: mindestens 128 MB Speicherlimit, mindestens 120 Sekunden Ausführungszeit sowie die Erweiterungen SimpleXML, Imagick, Curl, Iconv, MBString, Tokenizer, Intl und PDO für MySQL.

Für Shopware 6 liegt die Latte an anderer Stelle. Das Speicherlimit beginnt laut Dokumentation bei 512 MB, und der Aufbau des Storefront-Themes braucht Node ab Version 20 sowie Composer ab 2.2 — also eine Kommandozeile. Für den Produktivbetrieb empfiehlt der Hersteller außerdem ausdrücklich ein eigenes Queue-System statt der Datenbank-Warteschlange; Suchindex und Cache-Speicher sind als optional gekennzeichnet, werden mit wachsendem Katalog aber zum Thema. Ein reines Klick-Paket ohne Konsolenzugang scheidet damit praktisch aus.

Bei Shopify entfällt die Frage vollständig: Laut Preisübersicht des Anbieters enthalten alle Tarife „Unbegrenztes Webhosting" und ein kostenloses SSL-Zertifikat. Sie tauschen die Serverfrage gegen die Frage, wie weit sich die Plattform an Ihre Prozesse anpassen lässt. Das ist eine Plattformentscheidung, keine Hosting-Entscheidung — und gehört an eine andere Stelle des Auswahlprozesses.

Ob ein Server im Alltag schnell genug antwortet, zeigt sich später an einem Messwert: der Time to First Byte, also der Zeit bis zum ersten Byte der Seite. Sie ist selbst kein Core Web Vital, steckt aber in jedem Wert für den Largest Contentful Paint. Welchen Richtwert Google dafür nennt und wie Sie Serverzeit, Bild und Darstellung auseinanderhalten, erklärt unser Beitrag zu Core Web Vitals im Onlineshop.

4. Die Kennzahl, die zählt: nicht das Backup, sondern die Wiederherstellungszeit

„Tägliche Backups inklusive" steht in fast jedem Tarif. Die Angabe beantwortet aber die unwichtigere Hälfte der Frage. Entscheidend ist nicht, wie oft gesichert wird, sondern wie lange es dauert, bis Ihr Shop nach einem Ausfall wieder Bestellungen annimmt — und ob das jemals jemand ausprobiert hat.

Aus diesem Grund gehört zu jedem Hosting-Angebot ein Probelauf. Ein Backup, das noch nie zurückgespielt wurde, ist keine Sicherung, sondern eine Vermutung. Wir haben in Projekten schon Sicherungen gesehen, die vollständig waren, sich aber nicht einspielen ließen, weil die Datenbankversion auf dem Zielsystem eine andere war. Aufgefallen ist das im Ernstfall.

Diese vier Fragen klären Sie deshalb schriftlich, bevor Sie unterschreiben: Wie lange dauert die Wiederherstellung des kompletten Systems erfahrungsgemäß? Können Sie eine einzelne Datei oder Tabelle zurückholen, ohne den Rest zu überschreiben? Wie viele Tage reicht die Aufbewahrung zurück — reicht sie über den Zeitraum hinaus, in dem ein Problem üblicherweise unbemerkt bleibt? Und ist die Rückspielung im Preis enthalten oder eine kostenpflichtige Zusatzleistung?

Ein Punkt wird dabei fast immer übersehen: Ein Backup, das ausschließlich beim selben Anbieter im selben Rechenzentrum liegt, schützt gegen Bedienfehler und Softwareprobleme, nicht aber gegen den Ausfall dieses Anbieters. Wie sich das in ein Gesamtbild einordnet, beschreiben wir im Beitrag zur IT-Sicherheit im Mittelstand.

5. Die Betriebsanforderungen, die kein Vergleichsportal listet

Die folgenden acht Punkte tauchen in keiner Tarifübersicht auf, entscheiden im Betrieb aber häufiger über Ärger als Speicherplatz und Preis zusammen. Nehmen Sie die Liste als Fragenkatalog in ein Angebotsgespräch mit — die Antworten trennen ernsthafte Angebote schnell von Werbeblättern.

Zwei dieser Punkte verdienen einen Zusatz. Beim Mailversand ist die technische Zustellbarkeit ein Hosting-Merkmal, das erst auffällt, wenn Kunden Bestellbestätigungen vermissen — die Ursache liegt dann oft in fehlenden Authentifizierungs-Einträgen oder einer belasteten Absender-Adresse. Und bei der Zertifikatserneuerung lohnt der Blick auf den Fehlerfall: Automatik ist der Normalfall, aber Sie sollten wissen, ob Sie beim Scheitern eine Warnung bekommen oder erst der Browser Ihrer Kunden Alarm schlägt.

Eine Betriebsanforderung ist seit 2026 neu dazugekommen: die Zertifikatserneuerung. Seit dem 15. März 2026 darf ein öffentlich vertrauenswürdiges TLS-Zertifikat höchstens 200 Tage gelten, ab dem 15. März 2027 nur noch 100 Tage — aus zwei Erneuerungen im Jahr werden also vier, ab 2029 acht. Fragen Sie deshalb bei jedem Anbieter konkret nach, ob er die Erneuerung selbst übernimmt oder nur die Möglichkeit dazu bereitstellt; im ersten Fall ist es sein Betriebsrisiko, im zweiten Ihres. Welche Stichtage gelten und woran manuelle Pflege scheitert, haben wir im Beitrag zu den sinkenden SSL-Zertifikatslaufzeiten aufgeschlüsselt.

6. Der Sonderfall, den kein Vergleichsportal kennt: JTL-Wawi

Wer einen Onlineshop betreibt, betreibt in der Regel auch eine Warenwirtschaft. Und hier endet die Zuständigkeit jedes Webhosting-Vergleichs abrupt: JTL-Wawi ist eine Windows-Anwendung mit einer Microsoft-SQL-Datenbank. Sie läuft nicht auf einem Linux-Webspace, und kein Hosting-Tarif der Welt ändert daran etwas.

Praktisch heißt das: Sie treffen zwei Entscheidungen, nicht eine. Für den Shop wählen Sie ein Webhosting nach den Kriterien dieses Beitrags. Für die Warenwirtschaft brauchen Sie eine Windows-Umgebung, auf die Ihr Team per Remote-Desktop zugreift — ein Terminalserver im eigenen Haus oder gemietet in einem Rechenzentrum. Die Auswahlkriterien dort sind andere: Anzahl gleichzeitiger Sitzungen, Leistung des Datenbankservers, Latenz der Verbindung, Lizenzierung.

Wir behandeln dieses Thema deshalb bewusst getrennt. Wie Cloud-Betrieb und lokaler Server für die Warenwirtschaft gegeneinander stehen, welche Anforderungen der Datenbankserver stellt und wie die Umstellung abläuft, steht im Beitrag zum JTL-Wawi Cloud-Hosting. Wenn Sie den Betrieb nicht selbst aufbauen möchten, ist unsere Seite zum JTL-Wawi Cloud Hosting mit RDP-Zugriff der passende Einstieg.

Der praktische Grund, beides trotzdem zusammen zu denken: Shop und Warenwirtschaft tauschen laufend Daten aus. Artikel, Bestände, Preise und Bestellungen laufen zwischen beiden Systemen hin und her. Wenn Sie eine Seite umziehen, prüfen Sie deshalb immer die Verbindung zur anderen mit — Firewall-Freigaben und fest hinterlegte IP-Adressen sind die häufigste Stolperstelle nach einem Wechsel.

Innerhalb dieses Sonderfalls entscheidet dann noch die Edition. Die kostenlose Express-Variante deckelt jede Datenbank bei 10 GB und den Pufferpool bei 1.410 MB; Azure SQL und Instanzen von Shared Microsoft SQL Server schließt JTL ausdrücklich aus, ein günstiges Datenbankpaket beim Webhoster fällt damit aus. Welche Grenzen im Betrieb wirklich beißen und woran Sie sie früh erkennen, zeigt unser Beitrag zu SQL Server Express für JTL-Wawi.

7. NGINX oder Apache: der Architekturunterschied und die .htaccess-Falle

Die Frage taucht in jedem Hosting-Gespräch auf, meistens als Glaubensfrage. Sachlich betrachtet sind es zwei unterschiedliche Antworten auf dasselbe Problem — und der relevante Unterschied für Sie liegt weniger in der Geschwindigkeit als im Konfigurationsmodell.

Die eigentliche Migrationsfalle heißt .htaccess. Viele Anwendungen liefern eine solche Datei mit, in der Weiterleitungen, sprechende URLs, Verzeichnisschutz und Sicherheits-Kopfzeilen stehen. Auf einem NGINX-Server wird diese Datei schlicht ignoriert — nicht mit einer Fehlermeldung, sondern lautlos. Die Seite läuft, aber Regeln, die niemand vermisst hat, greifen plötzlich nicht mehr.

JTL formuliert das für den eigenen Shop ungewöhnlich deutlich. In den Systemvoraussetzungen heißt es, der Betrieb auf alternativen HTTP-Servern wie NGINX sei generell möglich, aber ohne Support — und weiter, dass die .htaccess-Regeln „unter anderem zum Verzeichnisschutz" bei diesen Servern manuell durch entsprechende Regeln nachgetragen werden müssen. Wer diesen Satz überliest und migriert, hat im schlimmsten Fall Verzeichnisse offen, die geschützt sein sollten.

Für die Praxis folgt daraus eine unspektakuläre Empfehlung: Läuft Ihre Anwendung heute auf Apache und bringt eigene .htaccess-Regeln mit, ist ein Wechsel des Webservers kein Nebenschauplatz einer Migration, sondern ein eigener Arbeitsschritt mit eigener Abnahme. Die in der Praxis häufigste Lösung umgeht die Entscheidung: NGINX nimmt vorn die Verbindungen an und liefert statische Dateien aus, Apache bearbeitet dahinter die dynamischen Anfragen samt seinen Verzeichnisregeln. Welche Aufteilung für Ihr System sinnvoll ist, sortieren wir in der Webhosting-Beratung anhand Ihrer bestehenden Konfiguration.

8. Serverstandort, Auftragsverarbeitung und Drittstaaten

„Server in Deutschland" ist ein beliebtes Werbeargument, beantwortet aber nur eine von drei Fragen. Die Datenschutz-Grundverordnung schreibt keinen bestimmten Standort vor. Sie stellt Anforderungen an das Verhältnis zwischen Ihnen und Ihrem Hoster — denn beim Hosting verarbeitet ein Dienstleister personenbezogene Daten in Ihrem Auftrag.

Der erste Punkt ist der Auftragsverarbeitungsvertrag. Artikel 28 Absatz 3 Satz 1 DSGVO verlangt für die Verarbeitung im Auftrag einen Vertrag oder ein anderes Rechtsinstrument; Absatz 1 fordert, dass Sie nur mit Auftragsverarbeitern arbeiten, die hinreichende Garantien für geeignete technische und organisatorische Maßnahmen bieten (Quelle: Art. 28 DSGVO). Ein seriöser Anbieter hat diesen Vertrag als Standarddokument griffbereit — muss er lange danach suchen, ist das bereits eine Antwort.

Wie dieser Vertrag zustande kommt, unterscheidet sich je Anbieter erheblich. Von acht geprüften Dienstleistern band nur ein einziger ihn nicht automatisch ein: Hetzner schreibt das sogar ausdrücklich und lässt stattdessen eine Checkbox im Kundenkonto genügen — wer sie nie gesetzt hat, betreibt seine Server ohne den Vertrag, den Artikel 28 verlangt. Welche Angaben Sie vor dem Abschluss festlegen müssen und wie die übrigen Anbieter es handhaben, steht im Beitrag zum Auftragsverarbeitungsvertrag.

Der zweite Punkt sind die Unterauftragnehmer. Artikel 28 Absatz 2 ist an dieser Stelle unmissverständlich: „Der Auftragsverarbeiter nimmt keinen weiteren Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen in Anspruch." Praktisch heißt das: Lassen Sie sich die Liste der eingesetzten Unterauftragnehmer geben. Rechenzentrum, Backup-Dienst, Monitoring und Support können bei drei verschiedenen Unternehmen liegen — und der Serverstandort sagt darüber nichts.

Der dritte Punkt ist die Übermittlung in Drittländer. Serverstandort und Konzernsitz sind zwei verschiedene Fragen: Ein Rechenzentrum in Frankfurt gehört möglicherweise zu einem Unternehmen außerhalb der EU, dessen Beschäftigte für Wartung und Support auf die Systeme zugreifen. Auch ein solcher Zugriff kann eine Übermittlung sein. Artikel 44 DSGVO lässt sie nur zu, wenn die Bedingungen des Kapitels V eingehalten werden. Fragen Sie deshalb konkret: Wer greift von wo aus auf die Systeme zu, und auf welcher Grundlage?

Hinweis: Dieser Abschnitt ist allgemeine Information und ersetzt keine Rechtsberatung. Ob und auf welcher Grundlage eine Übermittlung in Ihrem Fall zulässig ist, hängt von der konkreten Vertragsgestaltung ab und ändert sich mit der Rechtsprechung. Ziehen Sie dafür bitte die verlinkten Normtexte oder anwaltliche Beratung heran. Stand: 4. September 2026.

9. Verfügbarkeitszusagen richtig lesen

Verfügbarkeitszahlen sind das Werbeargument mit dem größten Abstand zwischen Wirkung und Aussage. Rechnerisch ist die Sache eindeutig: Ein Jahr hat 525.600 Minuten. Eine Zusage von 99,9 Prozent erlaubt davon rund 526 Minuten Ausfall, also knapp neun Stunden; 99,99 Prozent entsprechen rund 53 Minuten im Jahr. Diese Werte sind reine Arithmetik aus dem Prozentsatz, keine Messwerte eines Anbieters.

Interessant wird es beim Kleingedruckten, und dort stehen regelmäßig drei Einschränkungen. Erstens sind geplante Wartungsfenster meist ausgenommen — eine angekündigte Wartung zählt dann nicht als Ausfall, egal wie lange sie dauert. Zweitens ist definiert, was überhaupt gemessen wird: häufig nur die Erreichbarkeit des Servers auf Netzwerkebene. Ein Shop, der antwortet, aber keine Bestellung mehr abschließt, gilt nach dieser Definition als verfügbar.

Drittens, und das ist der wichtigste Punkt: Eine Zusage ohne Rechtsfolge ist ein Werbeversprechen. Prüfen Sie, was passiert, wenn der Wert unterschritten wird. Steht eine Gutschrift im Vertrag, muss sie beantragt werden, und in welcher Höhe? Ohne diese Klausel unterscheidet sich eine Zusage von 99,99 Prozent von einer über 99,9 Prozent im Ernstfall in nichts.

Deshalb ist die nützlichere Frage nicht „Wie hoch ist die zugesicherte Verfügbarkeit?", sondern „Wie schnell ist jemand erreichbar, der etwas ändern kann, und wie schnell sind wir im Zweifel wieder online?". Diese beiden Werte — Reaktionszeit und Wiederherstellungszeit — beschreiben Ihren tatsächlichen Ausfallschaden deutlich besser als eine Nachkommastelle.

Eine Ausfallursache fällt dabei regelmäßig durch das Raster der Verfügbarkeitszusage: Angriffe und Bot-Wellen. Ein Server, der unter einer DDoS-Attacke oder unter Tausenden automatisierten Filteraufrufen zusammenbricht, gilt für viele Hoster nicht als Ausfall der Infrastruktur, sondern als Problem der Anwendung. Prüfen Sie deshalb, welchen Schutz das Paket tatsächlich enthält — und ob Sie eine vorgeschaltete Schutzschicht brauchen. Für Shopsysteme haben wir das am Beispiel Cloudflare für JTL-Shop beschrieben, inklusive der Frage, welcher Cloudflare-Plan wofür reicht. Was ein solcher Reverse Proxy grundsätzlich leistet und welche Abhängigkeit Sie sich damit einhandeln, erklärt der Beitrag Was ist Cloudflare? Erklärt für Shop-Betreiber; für den Ernstfall gibt es den Notfallplan bei einem DDoS-Angriff auf den Onlineshop.

10. Kostenstruktur statt Preisliste

Wir nennen hier bewusst keine Preise. Sie ändern sich laufend, unterscheiden sich nach Vertragslaufzeit und sind ohne den zugehörigen Leistungsumfang nicht vergleichbar. Was sich dagegen sehr wohl vergleichen lässt, ist die Struktur eines Angebots — also die Frage, aus welchen Positionen der Preis entsteht und welche davon erst später sichtbar werden.

Ein Wort zu „unlimited". Unbegrenzter Traffic oder unbegrenzter Speicher bedeutet in der Praxis fast immer: unbegrenzt im Rahmen einer fairen Nutzung, deren Grenze in den Vertragsbedingungen steht. Das ist nicht unseriös, solange die Grenze benannt und die Folge geregelt ist. Unseriös wird es, wenn beides fehlt — dann ist „unbegrenzt" eine Formulierung, die erst im Konfliktfall ihren Inhalt bekommt.

Rechnen Sie deshalb nicht in Monatspreisen, sondern in Gesamtkosten über die geplante Laufzeit: Grundpreis nach Ablauf der Aktion, absehbarer Zusatzbedarf, Staging, Backup-Aufbewahrung, und der Aufwand, den Sie selbst investieren. Bei einem VPS ist der letzte Posten der größte — und der einzige, der auf keiner Rechnung erscheint.

Ein Teil der Last lässt sich abgeben, ohne den Server zu vergrößern: die Auslieferung von Bildern, Skripten und Schriften. Ein CDN hält diese Dateien in Rechenzentren nahe bei Ihren Kunden vor, sodass Ihr Server mehr Luft für Suche, Warenkorb und Checkout hat. Das Hosting ersetzt es aber nicht. Wie CDNs abrechnen und was in den Cache darf, zeigt unser Beitrag CDN erklärt: Preismodelle und Cache-Regeln für Shops.

11. Wechsel und Migration: Ablauf, DNS und der SEO-Teil

Ein Hosting-Wechsel ist beherrschbar, wenn er in dieser Reihenfolge abläuft. Der häufigste Fehler ist nicht ein technischer, sondern ein zeitlicher: umschalten, bevor getestet wurde, und danach unter Druck reparieren.

Zwei Punkte zur DNS-Laufzeit, weil sie regelmäßig unterschätzt wird. Der Wert legt fest, wie lange ein Auflöser im Netz eine Antwort zwischenspeichert, bevor er neu nachfragt. Steht er auf 24 Stunden und Sie senken ihn erst am Umstellungstag, greift die Absenkung selbst erst nach 24 Stunden — sie muss also vorher passieren. Und heben Sie den Wert nach dem Umzug wieder an: dauerhaft kurze Laufzeiten erzeugen unnötig viele Abfragen.

Bleibt der Teil, der über Sichtbarkeit entscheidet. Solange nur der Server wechselt und alle URLs identisch bleiben, ist ein Hosting-Umzug aus Sicht der Suchmaschinen ein Nicht-Ereignis. Kritisch wird es, sobald sich gleichzeitig etwas an Adressen, Struktur oder Zertifikat ändert — dann brauchen Sie dauerhafte Weiterleitungen ohne Ketten, eine erreichbare Sitemap und einen Blick auf die Indexierung. Wer den Wechsel mit einem Relaunch verbindet, findet die vollständige Reihenfolge in unserer Checkliste für den Website-Relaunch ohne SEO-Verlust.

Angaben zu Systemanforderungen aus der JTL-Dokumentation und der Shopware-Dokumentation (öffnen in neuem Tab), abgerufen am 4. September 2026. Herstellerangaben ändern sich mit neuen Releases — bitte zum Zeitpunkt Ihrer Auswahl erneut prüfen. Die vollständige Quellenliste finden Sie am Ende des Beitrags.

12. Fazit: die Fragen, die Ihre Auswahl entscheiden

Ein Punkt, der bei der Anbieterwahl neuerdings mitspielt: Hosting-Anbieter zählen ausdrücklich zu den Diensteanbietern der E-Evidence-Verordnung und müssen seit August 2026 einen Adressaten für behördliche Anordnungen vorhalten. Für Sie als Kunde ändert das nichts an der eigenen Einordnung, ist aber ein Hinweis darauf, wie professionell ein Anbieter aufgestellt ist — Einzelheiten im Beitrag zur E-Evidence-Verordnung.

Die Bestenlisten zu diesem Suchbegriff sind nicht falsch, sie beantworten nur eine andere Frage. Sie sagen, welcher Tarif für eine private Website preislich günstig aussieht. Für ein Unternehmen mit Shop und Warenwirtschaft ist der Preis dagegen die letzte Größe, die zählt — und sie steht erst fest, wenn die Anforderungen stehen.

Die Reihenfolge, die sich bewährt hat, ist deshalb simpel: Zuerst die Systemanforderungen Ihres Shopsystems aus der Hersteller-Dokumentation ziehen. Dann ehrlich klären, wie viel Serverbetrieb Ihr Team wirklich übernehmen kann und will — das entscheidet zwischen Shared, VPS, Managed und Cloud. Anschließend die acht Betriebspunkte aus Abschnitt fünf abfragen, mit besonderem Gewicht auf der Wiederherstellungszeit. Und erst danach Angebote vergleichen, und zwar über die gesamte Laufzeit statt im Monatspreis.

Wenn Sie diese Sortierung nicht allein vornehmen möchten: Wir schauen uns Ihre bestehende Umgebung an, gleichen sie gegen die Anforderungen Ihres Shopsystems ab und sagen Ihnen, welches Betriebsmodell dazu passt — anbieterneutral, weil wir keine Hosting-Marke verkaufen müssen. Der Einstieg ist unsere Webhosting-Beratung; wenn die Warenwirtschaft mitwandert, kommt der Wawi-Betrieb per Remote-Desktop als zweiter Baustein dazu.

Hinweis: Dieser Beitrag ist allgemeine Information und ersetzt keine Rechtsberatung. Die genannten Systemanforderungen entsprechen der jeweiligen Hersteller-Dokumentation mit Stand vom 4. September 2026 und ändern sich mit neuen Programmversionen. Die genannten Ausfallzeiten sind rechnerische Ableitungen aus dem jeweiligen Prozentsatz, keine Messwerte. Es werden bewusst keine Anbieter empfohlen, bewertet oder mit Preisen genannt.

13. Häufige Fragen zum Webhosting-Vergleich

Welches Webhosting passt zu einem Onlineshop?

Das entscheidet das Betriebsmodell, nicht der Anbietername. Shared Hosting stößt an Grenzen, sobald der Shop eigene Cronjobs, ein höheres Speicherlimit oder einen Konsolenzugang braucht. Shopsysteme mit Composer- und Node-Buildkette laufen realistisch auf Managed Hosting oder einem VPS. Prüfen Sie zuerst die Herstelleranforderungen, danach die Tarife.

Was ist der Unterschied zwischen Webhosting und Domain?

Die Domain ist die Adresse, das Hosting der Ort. Die Domain sorgt dafür, dass Ihr Name im Netz auf eine bestimmte Nummer zeigt; das Hosting stellt den Speicherplatz und die Rechenleistung dahinter. Beides lässt sich getrennt bei verschiedenen Anbietern führen, was einen Hosting-Wechsel deutlich erleichtert.

Was kostet Webhosting für ein Unternehmen?

Seriös lässt sich das nur mit Ihren Anforderungen beantworten. Der Grundpreis ist selten der Endpreis: Traffic über dem Inklusivvolumen, zusätzlicher Speicher, längere Backup-Aufbewahrung, eine Staging-Umgebung und garantierte Support-Reaktionszeiten werden häufig separat berechnet. Vergleichen Sie deshalb die Gesamtkosten über die Vertragslaufzeit, nicht den Monatspreis des Einstiegstarifs.

Kann ich JTL-Wawi auf einem Webhosting-Paket betreiben?

Nein. JTL-Wawi ist eine Windows-Anwendung mit Microsoft-SQL-Datenbank und läuft nicht auf einem Linux-Webspace. JTL unterstützt den SQL Server ausschließlich unter Windows; Azure-SQL-Datenbanken und geteilte SQL-Server sind laut Hersteller nicht unterstützt. Wawi-Hosting ist deshalb ein eigenes Thema mit Terminalserver oder Remote-Desktop-Zugriff. Stand: 4. September 2026.

Ist NGINX besser als Apache?

Keiner der beiden ist grundsätzlich besser. NGINX arbeitet mit wenigen Worker-Prozessen und kommt bei vielen gleichzeitigen Verbindungen mit wenig Arbeitsspeicher aus. Apache ist flexibler, weil sich Regeln pro Verzeichnis über .htaccess ablegen lassen — genau das erwartet zum Beispiel JTL-Shop. Häufig läuft NGINX als Reverse Proxy vor Apache.

Muss der Server in Deutschland stehen?

Die Datenschutz-Grundverordnung schreibt keinen deutschen Serverstandort vor. Sie verlangt einen Auftragsverarbeitungsvertrag nach Artikel 28, geeignete technische Maßnahmen nach Artikel 32 und für Übermittlungen in Drittländer eine Grundlage nach Kapitel V. Ein Standort in Deutschland vereinfacht diese Prüfung, ersetzt sie aber nicht. Keine Rechtsberatung.

Was bedeutet eine Verfügbarkeit von 99,9 Prozent?

Rein rechnerisch erlaubt eine Zusage von 99,9 Prozent rund 526 Ausfallminuten im Jahr, also knapp neun Stunden. Entscheidend ist aber das Kleingedruckte: Geplante Wartungsfenster sind meist ausgenommen, gemessen wird oft nur die Erreichbarkeit des Servers, und ohne vereinbarte Rechtsfolge bleibt die Zahl ein Werbeversprechen.

Wie lange dauert ein Hosting-Wechsel?

Die technische Umstellung ist selten das Problem, die Vorbereitung schon. Rechnen Sie mit einem Testlauf auf der neuen Umgebung, einer abgesenkten DNS-Laufzeit vor dem Umschalten und einem Zeitfenster mit wenig Bestellungen. Halten Sie die alte Umgebung noch einige Tage betriebsbereit, damit ein Rückfall möglich bleibt.

14. Quellen & offizielle Informationen

Die Angaben in diesem Beitrag stützen sich auf die folgenden Quellen, die alle am 4. September 2026 abgerufen und im Wortlaut gegengelesen wurden. Externe Quellen öffnen in einem neuen Tab.

• JTL-Software — Systemvoraussetzungen aller JTL-Produkte — Hersteller-Dokumentation: JTL-Shop 5 ab Version 5.7 mindestens PHP 8.3, Datenbank- und Modulanforderungen, Grenzwerte für Speicherlimit und Ausführungszeit, 64-bit-Apache 2.2 oder 2.4 mit mod_rewrite und erlaubten .htaccess-Overrides, Hinweis zum nicht supporteten NGINX-Betrieb; für JTL-Wawi Microsoft SQL Server ausschließlich unter Windows, keine Unterstützung für Azure-SQL und geteilte SQL-Server (Primärquelle).
• Shopware Documentation — Hosting: Recommended stack and supported versions — Hersteller-Dokumentation: PHP ab 8.2 (empfohlen 8.4), memory_limit ab 512 MB, Erweiterungsliste, MariaDB ab 10.11.6 oder MySQL ab 8.0.22, Node ab 20, Composer ab 2.2, Webserver „Any", Suchindex, Cache und Queue als optionale beziehungsweise für den Produktivbetrieb empfohlene Bausteine (Primärquelle).
• Shopify — Preise und Tarife — Anbieterangabe: „Unbegrenztes Webhosting" und „Kostenloses SSL-Zertifikat" als Bestandteil der Tarife (Primärquelle).
• nginx.org — Projektseite — Master- und Worker-Prozess-Modell, unterstützte Ereignisschnittstellen wie epoll und kqueue, Speicherangabe für 10.000 untätige Keep-alive-Verbindungen (Primärquelle).
• Apache HTTP Server — Multi-Processing Modules — Aufgabe der MPMs, die Module prefork, worker und event, Auswahlhinweis für Skalierung gegenüber Kompatibilität, „one and only one MPM must be loaded into the server at any time" (Primärquelle).
• Apache HTTP Server — .htaccess files — Standardwert von AllowOverride ist None; Performance-Nachteil aktivierter .htaccess-Dateien und die zusätzlichen Verzeichnis-Zugriffe je Anfrage (Primärquelle).
• Art. 28 DSGVO — Auftragsverarbeiter — Absatz 1 hinreichende Garantien, Absatz 2 keine weiteren Auftragsverarbeiter ohne vorherige schriftliche Genehmigung, Absatz 3 Vertrag oder anderes Rechtsinstrument (Normtext).
• Art. 32 DSGVO — Sicherheit der Verarbeitung — Absatz 1 Buchstabe b Verfügbarkeit und Belastbarkeit, Buchstabe c rasche Wiederherstellung nach einem Zwischenfall, Buchstabe d regelmäßige Überprüfung der Wirksamkeit (Normtext).
• Art. 44 DSGVO — Allgemeine Grundsätze der Datenübermittlung — Übermittlung in Drittländer nur unter den Bedingungen des Kapitels V (Normtext).
• EUR-Lex — Verordnung (EU) 2016/679 (DSGVO) — amtliche Fundstelle der Verordnung im Volltext (Primärquelle).
• Let’s Encrypt — Häufige Fragen — Standardlaufzeit der Zertifikate von 90 Tagen, Empfehlung zur Erneuerung nach 60 Tagen, optionale Zertifikate mit sechs Tagen Laufzeit (Primärquelle).