Modernes WordPress Webhosting

Technisch ist es derselbe Webspace. Der Unterschied liegt darin, dass die Umgebung auf WordPress eingestellt ist und jemand sie auch so betreut.

Ein allgemeiner Webspace muss alles können: WordPress, Joomla, TYPO3, ein paar PHP-Dateien. Die Einstellungen liegen deshalb in der Mitte. Bei WordPress-Hosting sind sie auf diesen einen Fall gelegt: genug Arbeitsspeicher für die Admin-Oberfläche, ein Cache, der die fertige Seite ausliefert, statt sie bei jedem Aufruf neu zu berechnen, und ein Object-Cache für die Datenbankabfragen, die bei eingeloggten Nutzern anfallen.

Dazu kommt, was der Anbieter von sich aus mitbringt. Eine Testumgebung zum Ausprobieren von Updates gehört bei spezialisierten Anbietern dazu, bei einfachem Webspace nicht. Was dahintersteckt, steht im Glossar unter Staging und Managed Hosting.

Der ehrliche Teil: Für eine kleine Seite mit wenigen Besuchern läuft WordPress auch auf günstigem Standard-Webspace. Der Unterschied zeigt sich bei Last, bei vielen eingeloggten Nutzern und dann, wenn etwas kaputtgeht und jemand erreichbar sein soll, der WordPress kennt.

Managed heißt: Der Anbieter kümmert sich um den Server, nicht um deine Webseite. Das ist die Grenze, an der die meisten Missverständnisse entstehen.

Zum Server gehören Betriebssystem, Webserver, PHP-Version, Datenbank, Firewall und die Sicherungen der Serverebene. Der Anbieter spielt dort Updates ein, überwacht die Last und greift ein, wenn etwas ausfällt. Du brauchst dafür keinen Zugriff und musst dich nicht darum kümmern.

Nicht dazu gehören dein WordPress, deine Plugins und dein Theme. Wer „managed" liest und daraus schließt, dass auch die Plugin-Updates jemand übernimmt, wundert sich nach ein paar Monaten über eine Liste mit dreißig offenen Aktualisierungen. Das ist eine eigene Leistung und heißt WordPress-Wartung.

Der Begriff ist nicht geschützt. Zwischen „managed" bei einem Massenanbieter und bei einem Spezialisten liegen Welten, und in beiden Fällen steht dasselbe Wort auf der Seite. Lohnend ist deshalb die Frage, was genau im Leistungsumfang steht: Wer spielt welche Updates ein, wer prüft hinterher, und wen erreichst du am Samstag. Die Begriffe selbst erklärt das Glossar unter Managed Hosting.

Weil er nicht weiß, was auf deiner Seite passieren soll, wenn ein Update etwas verändert. Diese Entscheidung kann er dir nicht abnehmen, ohne Schaden anzurichten.

Ein Plugin-Update kann ein Formular umbauen, ein Layout verschieben oder eine Funktion entfernen. Ob das in Ordnung ist, hängt davon ab, wie deine Seite gebaut ist und worauf es dir ankommt. Spielte der Hoster alle Updates automatisch für alle Kunden ein, wäre bei jeder größeren Version ein Teil der Seiten kaputt, und niemand wüsste vorher, welche.

Es geht außerdem um Haftung. Der Server gehört dem Anbieter, die Inhalte und die installierte Software gehören dir. Greift er dort hinein, trägt er die Folgen für etwas, das er nicht ausgesucht hat.

Was ein Hoster tun kann, ist die Grundlage sauber halten: aktuelle PHP-Version, funktionierende Sicherungen, eine Testumgebung, in der sich ein Update vorher ausprobieren lässt. Das Einspielen und Prüfen selbst ist eine Dienstleistung, die man dazubuchen kann oder selbst übernimmt.

Am zuverlässigsten an der Zeit bis zum ersten Byte. Liegt sie dauerhaft über einer halben Sekunde, obwohl die Seite zwischengespeichert sein müsste, liegt es am Server und nicht an deinen Bildern.

Dieser Wert heißt TTFB und misst, wie lange der Server braucht, bis er mit der Antwort überhaupt anfängt. Bilder, Schriften und Skripte kommen erst danach. Ein hoher Wert bedeutet, dass PHP und Datenbank zu lange rechnen oder der Server überlastet ist.

Der zweite Hinweis ist der Unterschied zwischen ausgeloggt und eingeloggt. Ist die Seite für Besucher flott und im Backend zäh, arbeitet der Cache und der Server dahinter nicht. Genau das fällt bei Shops und Mitgliederbereichen auf, weil dort viele Aufrufe am Cache vorbeilaufen.

Als Maßstab nennt Google für den Largest Contentful Paint 2,5 Sekunden als „gut" und 4,0 Sekunden als „schlecht", gemessen am 75. Perzentil der echten Aufrufe. Ein langsamer Server verbraucht von diesem Budget den ersten Teil, bevor überhaupt etwas zu sehen ist. Mehr dazu im Glossar unter Ladezeit.

Beim Shared Hosting teilen sich viele Kunden einen Server und damit dessen Rechenleistung. Was die Nachbarn tun, kann dich deshalb treffen.

Der klassische Fall ist ein Lastausschlag: Eine andere Seite auf demselben System bekommt viel Besuch oder ein Plugin dort dreht durch, und plötzlich ist deine Seite langsam, ohne dass sich bei dir etwas geändert hat. Das lässt sich von außen nicht erkennen und in der Statistik nur daran ablesen, dass die Antwortzeiten zu unerklärlichen Zeiten einbrechen.

Gute Anbieter begrenzen das technisch, indem jedem Kunden feste Anteile an Prozessor und Arbeitsspeicher zugewiesen werden. Dann kann ein Nachbar sein eigenes Kontingent ausschöpfen, aber nicht deins. Bei FastPress übernimmt das CloudLinux.

Der zweite Punkt ist Sicherheit. Liegen die Kundenverzeichnisse nicht sauber voneinander getrennt, kann eine infizierte Seite auf dem Server zum Problem für die anderen werden. Was die Begriffe bedeuten, steht unter Shared Hosting und vServer.

Weil PHP auf dem Server läuft und nicht in WordPress. Welche Versionen angeboten werden und wie lange, entscheidet der Anbieter.

PHP ist die Programmiersprache, in der WordPress geschrieben ist. Nach den Angaben des PHP-Projekts bekommt jede Version zwei Jahre lang Fehler- und Sicherheitskorrekturen und danach zwei weitere Jahre nur noch Korrekturen für kritische Sicherheitslücken. Danach ist Schluss. Stand Oktober 2026 läuft der Sicherheits-Support für PHP 8.2 Ende 2026 aus, für PHP 8.3 Ende 2027.

Für dich heißt das: Eine Seite, die heute fehlerfrei läuft, muss alle paar Jahre auf eine neuere PHP-Version wechseln, auch wenn an ihr selbst niemand etwas ändert. Bietet dein Hoster nur alte Versionen an, bleibt dir nicht einmal die Wahl.

Der Wechsel selbst ist der heikle Teil, weil ein altes Plugin mit der neuen Version nicht zurechtkommen kann. Deshalb gehört er in eine Testumgebung, nicht ins Live-System. Was PHP genau macht, steht unter PHP.

Aus zwei Gründen, einem rechtlichen und einem technischen. Der rechtliche wiegt schwerer.

Wer eine Webseite mit Besucherdaten betreibt, beauftragt mit dem Hoster einen Auftragsverarbeiter. Dafür verlangt Artikel 28 DSGVO einen Vertrag, der Gegenstand, Dauer, Zweck und die Sicherheitsmaßnahmen festhält. Der Landesbeauftragte für den Datenschutz Baden-Württemberg weist in seiner Darstellung zur Auftragsverarbeitung darauf hin, dass die Verarbeitung nur auf Grundlage eines bindenden Vertrags erfolgen darf. Liegt der Server außerhalb der EU, kommen die Regeln für Drittlandübermittlungen dazu, und der Aufwand steigt deutlich.

Innerhalb der EU schreibt die DSGVO keinen bestimmten Standort vor. Ein Server in Deutschland ist also keine Pflicht, aber er erspart die Prüfung, ob Daten in ein Drittland fließen.

Technisch geht es um Entfernung. Jeder Kilometer zwischen Besucher und Server kostet Zeit, weil die Anfrage hin und zurück muss. Bei überwiegend deutschem Publikum ist ein deutscher Standort deshalb die einfachste Verbesserung. Wo unsere Server stehen, steht im Abschnitt Rechenzentrum, die Begriffe unter Rechenzentrum.

Dass im Jahr rechnerisch bis zu 8 Stunden und 45 Minuten Ausfall erlaubt sind, ohne dass die Zusage gebrochen wäre. Das Jahr hat 8.760 Stunden, ein Promille davon sind knapp neun Stunden.

Die Stelle hinter dem Komma entscheidet also über Größenordnungen. 99 Prozent bedeuten 3,65 Tage Ausfall im Jahr, 99,9 Prozent knapp neun Stunden, 99,99 Prozent noch 53 Minuten. Zwischen der ersten und der letzten Zahl liegt der Unterschied zwischen „die Seite war eine Woche lang immer mal weg" und „kaum jemand hat es bemerkt".

Wichtiger als die Zahl ist, was im Kleingedruckten als Ausfall zählt. Geplante Wartungsfenster sind meist ausgenommen, ebenso Störungen, die beim Kunden oder bei einem Vorlieferanten liegen. Und die Folge eines Verstoßes ist in der Regel eine Gutschrift auf die Monatsgebühr, nicht ein Ersatz für entgangenen Umsatz.

Was die Begriffe bedeuten, steht unter Uptime und SLA.

Weil der niedrige Preis durch Dinge erkauft wird, die erst später auffallen: zu wenig Leistung, fehlende Sicherungen und Support, der nur Formulare kennt.

Die üblichen Stellen sind schnell benannt. Der Einstiegspreis gilt für das erste Jahr und steigt danach. Sicherungen gibt es, aber die Wiederherstellung kostet extra. Der Arbeitsspeicher reicht für die Seite, nicht für das Backend mit einem Seitenbaukasten. Und bei einem Problem schreibt dir jemand zurück, der WordPress nur vom Namen kennt.

Die Monatsgebühr ist dabei der kleinere Posten. Teuer wird es durch die Stunden, die danach anfallen. Ein Shop, der am Wochenende nicht erreichbar ist, kostet Umsatz. Eine Seite, die nach einem Update weiß bleibt und deren letztes brauchbares Backup zwei Wochen alt ist, kostet einen Tag Arbeit.

Das heißt nicht, dass teuer automatisch gut ist. Es heißt, dass sich der Vergleich erst lohnt, wenn man dieselben Dinge vergleicht: Leistung, Sicherungen samt Wiederherstellung, Testumgebung, PHP-Versionen und wer am anderen Ende antwortet. Unsere Tarife stehen offen unter Tarife.

Wenn du mehr Zeit mit dem Hosting verbringst als mit deiner Webseite. Das ist der Punkt, an dem der Umzug billiger ist als das Bleiben.

Konkrete Anlässe gibt es vier. Die Antwortzeit ist dauerhaft hoch, obwohl der Cache arbeitet. Die gewünschte PHP-Version wird nicht angeboten. Es gibt keine Testumgebung, also muss jedes Update live eingespielt werden. Oder der Support antwortet auf eine Frage zu WordPress mit einem Textbaustein.

Gegen den Wechsel spricht vor allem die Angst vor Ausfall, und die ist meist unbegründet. Ein Umzug läuft über eine Kopie: Die Seite wird beim neuen Anbieter aufgebaut und geprüft, erst danach zeigt die Domain dorthin. Für Besucher ändert sich in diesem Moment nichts, abgesehen von der Zeit, die der DNS-Eintrag zum Verbreiten braucht.

Was dabei zu beachten ist, hängt an den E-Mail-Postfächern und bei Shops an den laufenden Bestellungen. Beides lässt sich planen. Bei uns ist der Umzug im Preis enthalten, Fragen dazu klären wir vorher unter Kontakt.

Das sind drei Messwerte, mit denen Google die Ladeerfahrung einer Seite beschreibt: wie lange der Hauptinhalt bis zur Anzeige braucht, wie schnell die Seite auf eine Eingabe reagiert und wie ruhig das Layout dabei bleibt.

Die Grenzwerte stehen fest. Als „gut" gilt ein Largest Contentful Paint von höchstens 2,5 Sekunden, ein Interaction to Next Paint von höchstens 200 Millisekunden und ein Cumulative Layout Shift von höchstens 0,1. Schlecht wird es ab 4,0 Sekunden, 500 Millisekunden und 0,25.

Grundlage ist das 75. Perzentil der echten Seitenaufrufe, getrennt nach Handy und Rechner. Dein eigener Besuch zählt dabei nicht mit. Drei Viertel deiner Besucher müssen den guten Bereich erreichen, damit die Seite als gut gilt. Ein einzelner langsamer Aufruf fällt also nicht ins Gewicht, ein dauerhaft zähes Backend schon.

Was sie zählen, sagt Google selbst zurückhaltend: Man empfehle Betreibern dringend, gute Werte zu erreichen, und diese Werte deckten sich mit dem, was die Ranking-Systeme belohnen. Von einem direkten Ranking-Faktor spricht die Dokumentation nicht. Mehr dazu im Glossar unter Core Web Vitals.

Der Server verantwortet den Anfang, die Seite den Rest. Die Grenze liegt genau beim ersten Byte der Antwort: Alles davor ist Serverarbeit, alles danach sind Bilder, Schriften, Stile und Skripte.

In Zahlen lässt sich das aufteilen. Für die Zeit bis zum ersten Byte nennt web.dev 0,8 Sekunden als guten und 1,8 Sekunden als schlechten Wert. Vom Budget der 2,5 Sekunden für den Largest Contentful Paint verbraucht ein langsamer Server also bis zu zwei Drittel, bevor überhaupt etwas übertragen wird.

Bei den meisten WordPress-Seiten ist der größere Posten trotzdem die Seite selbst. Unkomprimierte Bilder, ein Seitenbaukasten mit viel JavaScript und eine Handvoll Schriftschnitte wiegen zusammen mehr als jede Serveroptimierung ausgleichen kann. Deshalb bringt es wenig, den Hoster zu wechseln und alles andere zu lassen.

Die Reihenfolge ist einfach: zuerst messen, wo die Zeit liegt, dann das Größere zuerst angehen. Für die Seite steht die Anleitung im Ratgeber unter Bilder optimieren und Dateien gezielt laden.

Sie misst, wie lange es vom Abschicken der Anfrage dauert, bis das erste Byte der Antwort beim Browser ankommt. Darin stecken die Namensauflösung, der Verbindungsaufbau, die Verschlüsselung und vor allem die Zeit, die der Server zum Nachdenken braucht.

Der Wert heißt TTFB und ist selbst keiner der Core Web Vitals. Er geht ihnen aber voraus: Was hier verloren geht, fehlt allen folgenden Messwerten. web.dev nennt 0,8 Sekunden als guten und 1,8 Sekunden als schlechten Wert.

Nützlich ist er, weil er die Ursache eingrenzt. Ein hoher Wert bei einer Seite, die aus dem Cache kommen müsste, deutet auf einen überlasteten Server oder einen Cache, der nicht greift. Ein niedriger Wert bei trotzdem langsamer Seite verweist auf Bilder und Skripte.

Eine Einschränkung gehört dazu: Der Wert schwankt mit der Entfernung und der Verbindung des Besuchers. Für einen Vergleich zwischen zwei Anbietern taugt er nur, wenn beide vom selben Ort aus und mehrfach gemessen werden. Was dahintersteckt, steht unter TTFB.

Weil das Werkzeug zwei verschiedene Messungen in einem Bericht zeigt und keine davon deinen Besuch abbildet.

Oben stehen die Felddaten aus dem Chrome User Experience Report. Das sind echte Aufrufe echter Besucher der vergangenen 28 Tage, zusammengefasst als 75. Perzentil. Darunter kommt die Labormessung: ein einziger simulierter Aufruf auf einem gedrosselten Mittelklasse-Handy mit künstlich verlangsamter Verbindung.

Dein eigener Eindruck entsteht unter den besten denkbaren Bedingungen. Du rufst die Seite auf einem schnellen Rechner mit gefülltem Browser-Cache auf, oft noch eingeloggt, meist über eine gute Leitung. Dass sich das flott anfühlt, sagt wenig über jemanden mit drei Jahre altem Telefon im Mobilfunknetz.

Die Felddaten sind der Maßstab, die Labormessung zeigt, woran es liegt. Fehlen die Felddaten ganz, hat die Seite schlicht zu wenig Besucher für die Statistik. Das ist kein Fehler, sondern eine Lücke in der Datenlage.

Ein Cache liefert die fertige Seite aus, statt sie bei jedem Aufruf neu zu berechnen. Damit entfallen PHP und Datenbank, und aus einigen hundert Millisekunden Rechenzeit werden wenige Millisekunden Dateiauslieferung.

Der Gewinn ist bei WordPress groß, weil jede Seite sonst aus Dutzenden Datenbankabfragen zusammengebaut wird. Bei uns übernimmt das der LiteSpeed Webserver mit seinem eingebauten Cache, ohne dass dafür ein zusätzliches Plugin arbeiten muss.

Die Wirkung hört dort auf, wo die Seite für jeden Besucher anders aussehen muss. Ein gefüllter Warenkorb, ein eingeloggter Nutzer, ein Formular mit Sicherheitstoken: In diesen Fällen darf keine gespeicherte Fassung ausgeliefert werden, sonst sieht jemand fremde Daten. Diese Aufrufe laufen am Cache vorbei und treffen den Server mit voller Last.

Deshalb ist der Cache keine Antwort auf einen zu kleinen Tarif. Er verdeckt das Problem für anonyme Besucher und lässt es bei allen anderen stehen. Was die Begriffe bedeuten, steht unter Cache.

Weil für sie der Cache abgeschaltet ist. Jeder Klick erzeugt wieder die volle Arbeit: PHP baut die Seite neu zusammen, die Datenbank liefert die Daten dazu.

Betroffen sind alle, die sich anmelden. Du selbst im Backend, Kunden in einem Mitgliederbereich, Käufer mit gefülltem Warenkorb. Genau deshalb fällt vielen auf, dass die eigene Seite für Besucher flott wirkt und sich im Admin-Bereich zäh anfühlt. Das ist kein Widerspruch, sondern dieselbe Seite ohne Cache.

Dagegen hilft ein Object-Cache. Er speichert nicht die fertige Seite, sondern die einzelnen Datenbankergebnisse im Arbeitsspeicher. Die Seite wird weiterhin neu gebaut, die Zutaten liegen aber schon bereit. Bei uns übernimmt das Redis.

Für Shops und Mitgliederbereiche ist das der entscheidende Punkt bei der Tarifwahl. Dort nützt die beste Cache-Einstellung wenig, es zählen Prozessorleistung und Arbeitsspeicher. Mehr unter Redis und WooCommerce.

Weniger direkt, als oft behauptet wird. In seiner eigenen Dokumentation schreibt Google, man empfehle Betreibern dringend gute Werte, und diese deckten sich mit dem, was die Ranking-Systeme belohnen. Das Wort Ranking-Faktor steht dort nicht.

Der Inhalt bleibt also vorn. Eine langsame Seite, die eine Frage besser beantwortet als alle anderen, steht weiter oben als eine schnelle Seite mit dünnem Text. Umgekehrt entscheidet die Ladeerfahrung dort, wo sich mehrere Ergebnisse inhaltlich wenig nehmen.

Der größere Hebel liegt ohnehin woanders. Wer auf dem Handy drei Sekunden auf das erste Bild wartet, ist oft schon weg, bevor Google überhaupt ins Spiel kommt. Diese Abbrüche kosten unmittelbar Anfragen und Bestellungen, unabhängig von jeder Platzierung.

Ladezeit lohnt sich also vor allem, weil Besucher bleiben. Dass Google es ebenfalls bemerkt, kommt dazu. Mehr unter Ladezeit.

Meistens nicht. Ein Content Delivery Network löst ein Entfernungsproblem, und das hast du bei deutschem Publikum und deutschem Serverstandort nicht.

Das Prinzip: Ein CDN legt Kopien deiner Bilder, Stile und Skripte auf Server in vielen Regionen und liefert sie vom nächstgelegenen aus. Für jemanden in Australien spart das mehrere hundert Millisekunden pro Anfrage, weil das Signal nicht um die halbe Welt muss. Für jemanden in Hamburg, dessen Server in Frankfurt steht, ist der Weg ohnehin kurz.

Es gibt Fälle, in denen es sich trotzdem lohnt. Viel Bildmaterial oder Videomaterial, Besucher aus mehreren Kontinenten, oder der Wunsch, Angriffslast vor dem eigenen Server abzufangen. Letzteres ist eher ein Sicherheitsargument als ein Geschwindigkeitsargument.

Gegen das Weglassen spricht wenig: Ein CDN ist eine zusätzliche Stelle, die ausfallen und falsch zwischenspeichern kann, und bei Anbietern außerhalb der EU kommt die Frage der Datenübermittlung dazu. Was dahintersteckt, steht unter CDN.

Weil Arbeitsspeicher eine Obergrenze ist und kein Tempo. Er legt fest, wie viel eine Seite gleichzeitig bearbeiten darf, nicht wie schnell sie es tut.

Solange genug da ist, ändert mehr davon nichts. Erreicht die Seite die Grenze, fällt es dafür sofort auf: Ein Import bricht mitten im Lauf ab, der Seitenbaukasten lädt nicht fertig, oder WordPress meldet einen kritischen Fehler, weil das Speicherlimit erschöpft ist. In diesen Fällen hilft mehr Arbeitsspeicher sofort und vollständig.

Für die Geschwindigkeit im Alltag sind andere Dinge zuständig. Die Prozessorleistung bestimmt, wie schnell PHP rechnet. Der Speichertyp bestimmt, wie schnell Dateien und Datenbank antworten, und dort liegt zwischen einer normalen Festplatte und NVMe-Speicher ein echter Unterschied.

Beim Tarifvergleich lohnt sich deshalb der Blick auf alle drei Angaben zusammen. Ein großzügiger Arbeitsspeicher neben einem einzelnen Prozessorkern ergibt eine Seite, die nicht abstürzt und trotzdem langsam ist.

In der Regel einen messbaren Gewinn, aber der Hauptgrund für den Wechsel ist ein anderer: die Sicherheitsunterstützung.

Zur Geschwindigkeit: PHP hat mit Version 8.0 einen JIT-Compiler bekommen, und der OPcache hält den übersetzten Code im Arbeitsspeicher, statt jede Datei bei jedem Aufruf neu zu übersetzen. Wie viel das bei deiner Seite ausmacht, hängt stark von Theme und Plugins ab. Verlässliche Prozentzahlen gibt es dafür nicht, nur eigene Messungen vorher und nachher.

Der Pflichtteil steht auf der Seite des PHP-Projekts: Jede Version bekommt zwei Jahre Fehler- und Sicherheitskorrekturen und danach zwei Jahre nur noch Korrekturen für kritische Lücken. Stand Oktober 2026 endet die Unterstützung für PHP 8.2 am 31. Dezember 2026, für PHP 8.3 ein Jahr später.

Der Wechsel selbst gehört in eine Testumgebung, weil ein älteres Plugin mit der neuen Version nicht zurechtkommen kann. Was dahintersteckt, steht unter PHP und OPcache.

Weil niemand sie ausgesucht hat. Angriffe auf WordPress laufen fast immer automatisch: Programme klappern Adressbereiche ab und probieren bei jeder erreichbaren Seite dieselbe Handvoll bekannter Lücken durch.

Für diese Programme ist deine Seite eine Adresse in einer Liste. Ob dahinter ein Konzern oder ein Verein mit vierzig Besuchern im Monat steht, spielt keine Rolle, weil der Versuch nichts kostet. Der Satz „bei uns gibt es nichts zu holen" trifft deshalb am Ziel vorbei.

Geholt wird auch gar nicht dein Inhalt. Eine übernommene Seite ist als Infrastruktur wertvoll: Sie verschickt Werbemails, versteckt Unterseiten für fremde Produkte, leitet Besucher weiter oder dient als Zwischenstation für weitere Angriffe. Je unauffälliger sie bleibt, desto länger ist sie brauchbar.

Daraus folgt der unangenehme Teil: Niemand klopft an. Viele Betreiber merken erst Wochen später etwas, wenn Google die Seite markiert oder der Hoster den Mailversand sperrt. Wie der Schutz auf Serverebene aussieht, steht unter Imunify360.

Über eine bekannte Lücke in einem Plugin, deutlich seltener über das Theme und fast nie über WordPress selbst.

Patchstack zählt im Bericht State of WordPress Security in 2026 für das Jahr 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Umfeld, 42 Prozent mehr als im Vorjahr. Davon entfielen 91 Prozent auf Plugins und 9 Prozent auf Themes. Im WordPress-Kern waren es sechs.

Besonders unangenehm ist eine zweite Zahl aus demselben Bericht: Bei 46 Prozent der Schwachstellen lag zum Zeitpunkt der Veröffentlichung noch kein Update des Entwicklers vor. In diesem Fenster ist die Lücke öffentlich bekannt und nicht zu schließen, auch für jemanden, der sofort aktualisiert.

Hinein kommt man auch über das Passwort, entweder durch Ausprobieren am Login oder weil es aus einem fremden Datenleck stammt und hier noch einmal verwendet wurde.

Daraus ergibt sich die Reihenfolge der Gegenmittel: aktuelle Plugins, möglichst wenige davon, ein eigenes Passwort mit zweitem Faktor, und auf Serverebene ein Filter, der bekannte Angriffsmuster abfängt, bevor sie PHP erreichen.

Der Hoster sichert den Server, du sicherst die Software darauf. Diese Grenze verläuft genau dort, wo auch die Zuständigkeit für Updates endet.

Auf Serverebene gehört dazu: aktuelles Betriebssystem, gepflegte PHP-Versionen, eine Firewall, die bekannte Angriffsmuster erkennt, eine Trennung der Kundenverzeichnisse, damit eine infizierte Seite nicht zur Nachbarin greift, Erkennung von Schadcode in den Dateien und Sicherungen, die außerhalb des Servers liegen.

Nicht dazu gehört deine WordPress-Installation. Welche Plugins du einsetzt, wie alt sie sind, wer ein Administratorkonto hat und wie gut dessen Passwort ist, kann der Hoster weder wissen noch entscheiden. Er sieht nur den Datenverkehr und die Dateien, nicht den Grund dafür.

Die Lücke dazwischen ist genau die Stelle, an der die meisten Seiten übernommen werden: ein seit Monaten offenes Plugin-Update auf einem sauber gewarteten Server. Deshalb ist Hosting mit Schutz auf Serverebene der eine Teil und WordPress-Wartung der andere.

Sie prüft jede Anfrage, bevor PHP sie zu sehen bekommt, und wirft bekannte Angriffsmuster weg. Damit verschafft sie dir Zeit in genau dem Fenster, in dem du sonst wehrlos bist.

Dieses Fenster ist der eigentliche Nutzen. Wird eine Plugin-Lücke öffentlich, beginnen die automatischen Versuche innerhalb von Stunden. Ein Update gibt es zu diesem Zeitpunkt oft noch nicht, laut Patchstack bei 46 Prozent der Fälle. Eine Firewall kann den passenden Angriffsversuch trotzdem erkennen und blockieren, weil sie das Muster kennt und nicht die Lücke. Das nennt sich virtuelles Patchen.

Im Alltag begrenzt sie Anmeldeversuche, erkennt Massenabfragen und sperrt Adressen, die auffällig geworden sind. Bei uns übernimmt das Imunify360.

Eine Firewall ersetzt keine Updates. Sie kennt nur, was schon einmal beschrieben wurde, und ein Angriff über ein gestohlenes Administratorpasswort sieht für sie aus wie eine normale Anmeldung. Was der Begriff bedeutet, steht unter WAF.

Weil es innerhalb dessen läuft, was es schützen soll. Startet WordPress nicht mehr, ist auch das Plugin aus.

Ein Sicherheits-Plugin arbeitet erst, wenn PHP bereits läuft und WordPress geladen ist. Eine Anfrage, die auf eine Lücke zielt, hat zu diesem Zeitpunkt den Weg schon zur Hälfte hinter sich. Ein Filter auf Serverebene greift davor, braucht dafür kein PHP und kostet keine Rechenzeit der Seite.

Beim Aufräumen nach einem Einbruch zeigt sich dasselbe. Hat ein Angreifer Dateien verändert oder ein eigenes Administratorkonto angelegt, prüft sich das Plugin mit denselben Rechten selbst. Eine Erkennung, die außerhalb der Installation auf die Dateien schaut, lässt sich schwerer täuschen.

Solche Plugins haben trotzdem ihren Platz. Sie sind gut bei Dingen, die nur WordPress kennt: Anmeldeversuche zählen, Zwei-Faktor erzwingen, Benutzerrechte prüfen, Dateiänderungen melden. Sinnvoll ist beides übereinander, nicht eines statt des anderen.

Am verlässlichsten am Bericht „Sicherheitsprobleme" in der Google Search Console. Dort meldet Google, wenn bei einer Prüfung Hinweise auf einen Einbruch gefunden wurden, inklusive Beispiel-Adressen.

Die übrigen Anzeichen sind unauffälliger, weil eine übernommene Seite möglichst lange normal aussehen soll. Typisch sind ein Administratorkonto, das niemand angelegt hat, Weiterleitungen, die nur auf dem Handy oder nur bei Besuchern aus der Suche auftreten, fremde Unterseiten im Google-Index, plötzlich steigende Serverlast ohne mehr Besucher und Mails, die als Spam zurückkommen, obwohl du nichts verschickt hast.

Ein Hinweis zum Vorgehen: Die Beispiel-Adressen aus dem Bericht solltest du laut Google nicht einfach im Browser öffnen, weil Schadcode oft über Browser-Lücken verteilt wird. Besser ist das URL-Prüftool der Search Console.

Deshalb lohnt sich die Search Console auch für kleine Seiten. Sie ist kostenlos, und bestätigte Inhaber werden benachrichtigt, statt es durch Zufall zu bemerken. Was Schadcode anrichtet, steht unter Malware.

Dann sehen Besucher statt der Seite eine rote Warnseite, und zwar in Chrome, Firefox und Safari gleichzeitig, weil alle drei dieselbe Liste nutzen. Der Besucherstrom bricht innerhalb von Stunden weg.

Die Markierung erscheint zusätzlich im Suchergebnis als Hinweis, dass die Seite gehackt sein könnte oder dem Rechner schaden kann. Beides lässt sich nicht aussitzen, solange die Ursache besteht.

Der Weg zurück führt über die Search Console. Zuerst muss die Lücke geschlossen und der Schadcode entfernt sein, danach lässt sich im Bericht „Sicherheitsprobleme" eine Überprüfung anfordern. Google nennt dafür bei Schadsoftware einige Tage und bei Spam-Einbrüchen mehrere Wochen. In dieser Zeit bleibt die Warnung stehen.

Wird nur aufgeräumt, ohne die Lücke zu schließen, kommt die Infektion zurück und mit ihr die Warnung. Deshalb gehört zu jeder Bereinigung die Frage, wie jemand hereinkam, und die Antwort steht meist in einem Plugin, das seit Monaten auf ein Update wartet.

Weil er die einzige öffentlich erreichbare Tür ist, die ein Passwort annimmt, und weil bei WordPress jeder weiß, wo sie liegt.

Die Anmeldeseite liegt in der Standardinstallation unter einer festen Adresse. Ein Programm muss also nichts suchen, sondern kann sofort Kombinationen durchprobieren. Dafür braucht es keine Lücke und keine Besonderheit deiner Seite, nur Zeit und Geduld, und beides kostet nichts.

Wirksam wird das durch Passwörter aus fremden Datenlecks. Wurde dieselbe Kombination aus Mailadresse und Passwort schon einmal irgendwo erbeutet, ist der Versuch kein Raten mehr, sondern ein gezielter Treffer beim ersten Anlauf.

Dagegen hilft eine Staffelung. Auf Serverebene werden Versuche gezählt und auffällige Adressen gesperrt, bevor sie WordPress erreichen. In WordPress selbst sorgen ein eigenes, nirgends wiederverwendetes Passwort und ein zweiter Faktor dafür, dass ein erratenes Passwort allein nichts nützt. Zum zweiten Faktor steht mehr in der nächsten Frage.

Sie trennt den Zugang vom Passwort. Wer dein Passwort kennt, kommt damit allein nicht mehr hinein, und das deckt genau den häufigsten Fall ab: ein Passwort aus einem fremden Datenleck.

Das BSI empfiehlt, die Zwei-Faktor-Authentisierung überall einzusetzen, wo ein Dienst sie anbietet, und hält ein starkes Passwort allein für nicht ausreichend, um wichtige Zugänge zu schützen. Für WordPress heißt das: wenigstens für alle Konten mit Administratorrechten.

Die Verfahren sind unterschiedlich gut. Nach der Bewertung des BSI schützen Einmalcodes per SMS, Mail oder App nicht vor Echtzeit-Phishing, bei dem jemand den Code sofort weiterverwendet. Passkeys und Hardwareschlüssel schützen davor, weil sie an die Adresse der Seite gebunden sind.

Zwei Dinge gehören dazu, sonst wird aus dem Schutz ein Problem. Der Wiederherstellungsweg muss gesichert und die Ersatzcodes müssen an einem Ort liegen, den du im Ernstfall erreichst. Und das Mailkonto gehört zuerst abgesichert, weil sich darüber in der Regel alles andere zurücksetzen lässt.

Möglicherweise ja, und zwar schnell. Werden bei einem Einbruch personenbezogene Daten betroffen, verlangt Artikel 33 DSGVO eine Meldung an die Aufsichtsbehörde binnen 72 Stunden, nachdem der Vorfall bekannt wurde.

Die Ausnahme steht im selben Artikel: Die Meldung entfällt, wenn ein Risiko für die Rechte und Freiheiten der Betroffenen voraussichtlich nicht besteht. Diese Einschätzung musst du begründen können, und sie ist bei einer übernommenen Webseite mit Kontaktformular-Daten oder Kundenkonten schwerer zu begründen, als viele annehmen.

Ist das Risiko hoch, kommt Artikel 34 DSGVO dazu: Dann sind auch die betroffenen Personen selbst zu benachrichtigen, in klarer und einfacher Sprache.

Dokumentiere deshalb vom ersten Moment an, was wann aufgefallen ist, welche Daten auf dem System lagen und was du unternommen hast. Diese Dokumentation verlangt die DSGVO ohnehin, und sie ist die Grundlage jeder Einschätzung. Eine Rechtsberatung ist dieser Absatz nicht, bei einem echten Vorfall gehört der Datenschutzbeauftragte oder ein Anwalt dazu.

Weil es für den Ausfall des Servers gebaut ist und für deinen Fall nur nebenbei taugt. Es rettet dich, wenn eine Festplatte stirbt. Es hilft wenig, wenn du am Donnerstag merkst, dass seit Montag Inhalte fehlen.

Drei Punkte entscheiden darüber. Wie weit die Sicherungen zurückreichen, denn sieben Tage sind bei vielen Anbietern das Ende. Ob du selbst zurückspielen kannst oder einen Auftrag erteilen musst. Und ob dabei die ganze Seite kommt oder einzelne Dateien.

Dazu kommt der Fall, an den niemand gern denkt. Liegt die Sicherung auf demselben System wie die Seite, trifft ein erfolgreicher Angriff beides. Deshalb verlangt das BSI in seinen Top-10-Maßnahmen gegen Ransomware ausdrücklich Sicherungen, die nach dem Vorgang vom restlichen Netz getrennt werden.

Was dein Hoster tatsächlich sichert, steht im Leistungsumfang und selten im Werbetext. Bei uns sind es tägliche Sicherungen, die wir auch zurückspielen, und wer mehr Stände und einen geprüften Rückweg braucht, bekommt sie über die WordPress-Wartung.

Weil ohne sie nur eine leere Hülle zurückkommt. In der Datenbank stehen alle Inhalte: Seiten, Beiträge, Menüs, Einstellungen, Benutzer, Kommentare und bei einem Shop die Bestellungen.

Die Dateien auf dem Webspace sind der andere Teil. Dort liegen WordPress selbst, Theme, Plugins und die Bilder aus der Mediathek. Fehlt dieser Teil, zeigt die Datenbank auf Bilder, die es nicht mehr gibt.

Nur beides zusammen ergibt eine Seite. Und beides muss vom selben Zeitpunkt stammen, sonst passen die Verweise nicht mehr zueinander. Ein Plugin, das vor der Sicherung der Dateien aktualisiert wurde und in der Datenbank noch mit alten Einstellungen steht, führt zu Fehlern, die schwer zu finden sind.

Bei Sicherungen auf Serverebene ist das selbstverständlich, weil ein Abbild immer alles mitnimmt. Bei Plugin-Lösungen lohnt der Blick in die Einstellungen, dort lässt sich die Datenbank einzeln abwählen. Was dahintersteckt, steht unter Datenbank und MariaDB.

Mehr als einen, und zwar aus einem Grund, der mit Festplattenausfällen nichts zu tun hat: Nicht jeder Schaden fällt am selben Tag auf.

Das BSI warnt in seinem Maßnahmenkatalog davor, dass Angreifer sich nach der ersten Infektion teilweise mehrere Wochen im Netzwerk bewegen und deshalb längst in den Sicherungen stehen können. Wer nur den Stand von gestern hat, spielt den Angreifer mit zurück. Vor einer Wiederherstellung empfiehlt das BSI daher zu prüfen, ob die Sicherung schon verseucht ist.

Dasselbe gilt ohne Angriff. Ein Fehler im Formular, eine falsch gesetzte Weiterleitung, ein gelöschter Textabschnitt: Solche Dinge bemerkt man oft erst nach Tagen oder Wochen.

Ein brauchbares Muster sind tägliche Stände für die letzte Woche, wöchentliche für den letzten Monat und monatliche darüber hinaus. Im IT-Grundschutz heißt das Generationenkonzept, und das BSI nennt dort selbst die Kosten als Grenze. Für eine normale Unternehmensseite reichen diese drei Stufen.

Weil eine Sicherung auf demselben Server alles mitverliert, was diesen Server trifft. Das gilt für einen Hardwareausfall genauso wie für einen Angreifer, der sich im System umsieht und findet, was er löschen will.

Das BSI formuliert es in seinen Top-10-Maßnahmen deutlich: Sicherungen werden nach dem Vorgang von den übrigen Systemen getrennt und sind dadurch vor Verschlüsselung geschützt. Im Maßnahmenkatalog steht zusätzlich, dass Kopien auf verschiedene geografische Orte verteilt werden sollen.

Die Trennung lässt sich prüfen, und das BSI schlägt den Test selbst vor: Versuche von einem Administratorkonto aus, auf die getrennte Kopie zuzugreifen. Gelingt es, ist sie nicht getrennt.

Für eine Webseite heißt das nicht, dass du Bänder in einen Tresor legen musst. Es genügt, dass die Sicherung auf einem anderen System liegt, zu dem die Webseite selbst keinen Schreibzugriff hat. Genau daran scheitern Plugin-Lösungen, die ihre Sicherungen in den eigenen Uploads-Ordner schreiben.

Indem du es einmal machst. Vorher ist es eine Datei mit unbekanntem Inhalt, nachher eine Sicherung.

Die üblichen Überraschungen sind banal und trotzdem teuer. Die Datei ist unvollständig, weil der Vorgang in ein Zeitlimit gelaufen ist. Die Datenbank fehlt. Der Stand ist älter als angezeigt, weil der letzte Lauf fehlgeschlagen ist und niemand die Meldung gelesen hat. Oder das Zurückspielen funktioniert, braucht aber Zugangsdaten, die niemand mehr hat.

Der Test gehört in eine Kopie, nicht über die laufende Seite. Dafür gibt es die Testumgebung: Dort wird die Sicherung eingespielt, die Seite durchgeklickt und danach alles verworfen. Was dahintersteckt, steht unter Staging.

Wie oft, hängt davon ab, wie oft sich etwas ändert. Einmal nach dem Einrichten und danach bei jedem größeren Umbau ist eine vertretbare Untergrenze. In der WordPress-Wartung gehört die Kontrolle der Sicherungen zum monatlichen Durchgang.

So schnell, dass der Ausfall billiger bleibt als die Vorsorge. Die Zahl dafür musst du selbst setzen, und sie unterscheidet sich stark.

Bei einer Seite, die Anfragen über ein Formular sammelt, sind ein paar Stunden verschmerzbar. Bei einem Shop, der an einem guten Tag vierstellig umsetzt, kostet jede Stunde Geld und Vertrauen. Dieselbe technische Sicherung ist im einen Fall ausreichend und im anderen zu langsam.

Die Zeit setzt sich aus zwei Teilen zusammen, und meistens ist der erste der längere. Erst muss jemand merken, dass etwas kaputt ist, dann muss jemand zurückspielen. Eine Überwachung, die Ausfälle meldet, verkürzt den ersten Teil von Stunden auf Minuten. Was dahintersteckt, steht unter Uptime.

Die ehrliche Frage an den eigenen Anbieter lautet deshalb: Wer spielt zurück, an welchem Tag und in welcher Zeit. Ein Formular mit Bearbeitungszeit ist eine andere Antwort als eine Telefonnummer.

Es bringt dich auf einen sauberen Stand zurück, schließt aber nicht die Lücke, durch die jemand hereinkam. Ohne diesen zweiten Schritt wiederholt sich der Vorgang.

Das erste Problem ist der Zeitpunkt. Niemand weiß zu Beginn, seit wann die Seite betroffen ist. Spielst du den Stand von gestern zurück, kann der Schadcode dort schon enthalten sein. Deshalb sind ältere Stände hier mehr wert als der neueste, und deshalb rät das BSI, Sicherungen vor der Wiederherstellung auf Befall zu prüfen.

Das zweite Problem sind die Inhalte dazwischen. Zwischen dem sauberen Stand und heute liegen vielleicht neue Beiträge, Bestellungen oder Formularnachrichten. Die gehen beim Zurückspielen verloren oder müssen von Hand nachgezogen werden.

Die Reihenfolge, die sich bewährt hat: sauberen Stand finden, Lücke schließen, alle Passwörter und Schlüssel erneuern, erst dann wieder öffentlich schalten. Zu den Anzeichen einer Infektion steht mehr im Themenblock Sicherheit, zu Schadcode allgemein unter Malware.

So oft, wie du bereit bist, Arbeit zu verlieren. Der Abstand zwischen zwei Sicherungen ist genau die Menge, die im Ernstfall weg ist.

Für eine Unternehmensseite, an der alle paar Wochen etwas geändert wird, ist eine tägliche Sicherung reichlich bemessen. Für einen Blog mit mehreren Beiträgen pro Woche ebenfalls. Bei einem Shop sieht es anders aus, weil dort rund um die Uhr Bestellungen eingehen und ein verlorener Tag echte Vorgänge betrifft.

Wichtiger als eine kürzere Taktung ist oft ein zusätzlicher Stand vor jedem Eingriff. Updates, ein neues Plugin, eine geänderte PHP-Version: An diesen Stellen passieren die meisten Schäden, und dort ist eine Sicherung von vor fünf Minuten mehr wert als eine von heute Nacht.

Bei uns läuft die tägliche Sicherung in jedem Tarif. Den Stand unmittelbar vor einem Update legt die WordPress-Wartung zusätzlich an.

Bei einem Shop entstehen rund um die Uhr Daten, die nirgends sonst stehen. Eine Bestellung von 23 Uhr lässt sich nicht aus einem Textdokument wiederherstellen.

Daraus folgt ein praktisches Problem beim Zurückspielen. Setzt du den Stand von gestern Abend ein, verschwinden alle Bestellungen, Zahlungen und Kundenkonten seitdem. Zugleich sind die Zahlungen beim Zahlungsdienstleister weiterhin gebucht. Diese beiden Stände wieder zusammenzubringen ist Handarbeit.

Hinzu kommt die Last. Ein Shop mit vielen Produkten und Bestellungen hat eine große Datenbank, und eine Sicherung im laufenden Betrieb kann die Seite währenddessen ausbremsen. Auf Serverebene lässt sich das abfedern, ein Plugin im selben PHP-Prozess kann es nicht.

WooCommerce läuft bei uns deshalb ausschließlich im Tarif Business PRO, mit Redis für die Datenbankabfragen und entsprechender Leistung. Mehr unter WooCommerce und auf der Seite Tarife.

Sie sind zwangsläufig drin, sobald deine Seite ein Kontaktformular, Kommentare oder Kundenkonten hat. Das ist zulässig, zieht aber zwei Pflichten nach sich.

Die erste betrifft die Sicherheit. Artikel 32 DSGVO verlangt Maßnahmen, die dem Risiko angemessen sind, und nennt die Verschlüsselung ausdrücklich als Beispiel. Eine unverschlüsselte Sicherungsdatei in einem Cloud-Ordner ohne Passwort erfüllt das nicht.

Die zweite betrifft das Löschen. Verlangt jemand nach Artikel 17 DSGVO die Löschung seiner Daten, stellt sich die Frage, was mit den Sicherungen geschieht. In der Praxis wird dort nicht einzeln gelöscht. Üblich ist, die Löschung im Livesystem auszuführen, den Vorgang zu dokumentieren und sicherzustellen, dass die Daten beim nächsten Zurückspielen nicht wieder auftauchen. Dafür braucht es eine Aufbewahrungsfrist, nach der alte Stände von selbst verschwinden.

Eine Rechtsberatung ist dieser Absatz nicht. Er nennt die beiden Stellen, an denen bei einer Prüfung zuerst nachgesehen wird.

Bei einem sauber vorbereiteten Umzug gar nicht. Der Grund ist einfach: Die Seite wird beim neuen Anbieter aufgebaut, während die alte weiterläuft.

Der Ablauf dahinter hat drei Schritte, und Google beschreibt ihn für diesen Fall selbst so. Erst wird die neue Umgebung eingerichtet und geprüft, dann werden die DNS-Einträge umgestellt, danach beobachtet man den Verkehr auf beiden Systemen. Die Umstellung des DNS ist dabei der eigentliche Start.

In der Übergangszeit zeigen manche Besucher noch auf den alten Server und manche schon auf den neuen. Beide Seiten funktionieren, deshalb merkt niemand etwas. Heikel wird es nur bei Inhalten, die in dieser Zeit entstehen: Eine Bestellung oder ein Kommentar landet auf dem System, das der jeweilige Besucher gerade erreicht.

Deshalb lohnt es sich, Redaktionsarbeit für diesen einen Tag zu pausieren und den Termin in eine ruhige Zeit zu legen. Bei uns übernehmen wir den Umzug und sagen dir vorher, wann das Fenster liegt.

Die sind der aufwendigere Teil des Umzugs, nicht die Webseite. Bei den Postfächern kann wirklich etwas verloren gehen.

Der Grund liegt im DNS. Die Einträge für die Webseite und die für den Mailverkehr hängen am selben Namen. Stellst du die Domain auf den neuen Server um, folgt der Mailverkehr mit, und zwar auch dann, wenn dort noch keine Postfächer angelegt sind. Mails, die in diesem Moment ankommen, werden abgewiesen oder landen in einem leeren Postfach.

Vorher gehört deshalb zweierlei geklärt. Welche Postfächer es gibt samt Passwörtern, und ob die alten Nachrichten mitkommen sollen. Letzteres geht über IMAP von Postfach zu Postfach und dauert bei vielen Jahren Archiv seine Zeit.

Es gibt einen Ausweg, der oft übersehen wird: Die Postfächer können beim bisherigen Anbieter bleiben. Dann wandert nur der Webseiten-Eintrag, und der Mail-Eintrag bleibt unverändert stehen. Was die Einträge bedeuten, steht unter MX-Record und DNS.

Nein. Die Domain und der Speicherplatz sind zwei getrennte Dinge, und ein Hosterwechsel verlangt nur, dass die Domain auf den neuen Server zeigt.

Dafür genügt es, beim bisherigen Anbieter die DNS-Einträge zu ändern. Die Domain bleibt, wo sie ist, die Rechnung dafür auch. Das ist der schnellste Weg und der mit den wenigsten beteiligten Stellen.

Der Umzug der Domain selbst lohnt sich, wenn du alles bei einem Anbieter haben willst oder wenn der bisherige nach der Kündigung ohnehin wegfällt. Bei einer .de-Domain läuft er über eine AuthInfo, die du beim alten Anbieter anforderst und beim neuen einreichst. Sie ist nach Angaben der DENIC 8 bis 16 Zeichen lang und 30 Tage gültig.

Eine Reihenfolge hat sich bewährt: zuerst die Seite umziehen und prüfen, danach in Ruhe die Domain. Beides gleichzeitig zu machen, verlängert im Fehlerfall die Suche nach der Ursache. Mehr unter Domain und Auth-Code.

Das DNS übersetzt deinen Domainnamen in die Adresse des Servers. Beim Umzug wird dort die alte Adresse gegen die neue getauscht, und dieser Tausch verbreitet sich nicht überall gleichzeitig.

Der Grund ist die Zwischenspeicherung. Jeder Eintrag trägt eine Gültigkeitsdauer, die TTL. Solange sie läuft, nutzen Server und Browser die gespeicherte alte Adresse weiter, auch wenn längst eine neue hinterlegt ist. Bei einer TTL von vier Stunden dauert es also bis zu vier Stunden, bis alle umgestiegen sind.

Daraus ergibt sich ein Trick, den jeder gute Umzug nutzt: Die TTL wird ein bis zwei Tage vor dem Termin auf einen niedrigen Wert gesetzt, etwa fünf Minuten. Dann ist die Umstellung am Umzugstag binnen Minuten überall angekommen, und danach wird die TTL wieder hochgesetzt.

Was die Begriffe bedeuten, steht unter DNS, TTL und Nameserver.

Bei gleichbleibenden Adressen in aller Regel nicht. Google sieht dieselben URLs mit denselben Inhalten und bemerkt den Serverwechsel kaum.

Google hat für genau diesen Fall eine eigene Anleitung, und sie ist kurz. Zwei Punkte daraus werden oft übersehen. Erstens: Sperren, die man beim Aufbau der Testkopie gesetzt hat, müssen vor dem Umschalten weg. Eine vergessene robots.txt mit Komplettverbot oder ein noindex im Theme kostet Sichtbarkeit, und zwar schnell. Zweitens: Firewall und Angriffsschutz dürfen den Googlebot nicht aussperren.

Riskant wird es, wenn sich beim Umzug zugleich die Adressen ändern, etwa durch einen Wechsel von www auf die Domain ohne www oder eine neue Verzeichnisstruktur. Dann braucht jede alte Adresse eine dauerhafte Weiterleitung. Google hält fest, dass 301-Weiterleitungen keinen Verlust an PageRank verursachen, und für mittelgroße Seiten nennt es einige Wochen, bis der Austausch durch ist.

Was danach zu beobachten ist, steht in der nächsten Antwort zur Erfolgskontrolle.

Dass Bestellungen keine Pause machen. Alles, was während der Umstellung eingeht, muss nachher genau einmal vorhanden sein.

Der kritische Moment ist die Zeitspanne, in der beide Systeme erreichbar sind. Trifft eine Bestellung den alten Server, steht sie in dessen Datenbank und fehlt im neuen. Deshalb wird bei Shops anders vorgegangen: Der Shop geht für ein kurzes Fenster in den Wartungsmodus, die Datenbank wird ein letztes Mal übertragen, dann wird umgeschaltet.

Zwei Dinge gehören auf die Prüfliste. Die Anbindung des Zahlungsdienstleisters, weil dort Schlüssel und manchmal eine Freigabe der Server-Adresse hinterlegt sind. Und der Mailversand für Bestellbestätigungen, der nach einem Serverwechsel oft im Spam landet, solange SPF und DKIM nicht angepasst sind. Mehr dazu im Ratgeber unter E-Mail-Versand optimieren.

Der Termin gehört in die umsatzschwächste Zeit der Woche. Bei den meisten Shops ist das früh am Dienstag oder Mittwoch, nicht das Wochenende.

Das hängt vom Anbieter ab, und die Antwort gehört vor den Vertragsabschluss geklärt. Die Spanne reicht von einer Anleitung im Hilfebereich bis zu einem Umzug, bei dem du nur die Zugangsdaten lieferst.

Bei einem Umzug durch den Anbieter brauchst du drei Dinge: Zugang zum bisherigen Webspace, Zugang zur Datenbank und die Möglichkeit, die DNS-Einträge zu ändern. Letzteres liegt oft beim Domain-Anbieter und damit woanders als der Webspace.

Die Frage nach dem Preis lohnt sich ebenso. Ein kostenloser Umzug ist verbreitet, manchmal aber auf eine Seite begrenzt oder an einen Jahresvertrag gebunden. Bei uns ist er im Preis enthalten, ohne Begrenzung auf eine bestimmte Größe.

Selbst machen ist möglich und für eine kleine Seite überschaubar. Der Aufwand steigt mit der Zahl der Postfächer, nicht mit der Größe der Webseite. Wenn du unsicher bist, frag vorher nach, was alles dazugehört: Kontakt.

Sie bleiben dort, bis der Vertrag endet, und werden danach gelöscht. Wann genau, steht in den Vertragsbedingungen und ist von Anbieter zu Anbieter verschieden.

Für dich folgt daraus eine Empfehlung: Lade vor der Kündigung eine vollständige Kopie herunter und bewahre sie auf. Dateien und Datenbank, dazu die Postfächer, falls dort Archive liegen. Diese Kopie ist dein Rückweg, falls im neuen System etwas fehlt, das vorher niemandem aufgefallen ist.

Verlass dich nicht darauf, nach der Kündigung noch an die Daten zu kommen. Bei vielen Anbietern wird der Zugang zum Vertragsende abgeschaltet, und die Sicherungen verschwinden kurz darauf.

Der datenschutzrechtliche Teil gehört dazu: Hast du mit dem alten Anbieter einen Auftragsverarbeitungsvertrag, regelt der auch, was mit den Daten nach Vertragsende geschieht. Mehr dazu im Themenblock Datenschutz und Serverstandort.

Nach dem Umzug, und erst wenn die neue Seite ein paar Tage sauber läuft. Eine Überschneidung von zwei bis vier Wochen kostet wenig und erspart im Problemfall viel.

Der Grund ist der Rückweg. Solange der alte Vertrag läuft, kannst du die DNS-Einträge im Zweifel zurückstellen und bist in Minuten wieder im alten Zustand. Ist gekündigt und abgeschaltet, gibt es diesen Weg nicht mehr.

Auf die Kündigungsfrist lohnt trotzdem ein früher Blick. Viele Verträge laufen über ein Jahr und verlängern sich automatisch, wenn nicht rechtzeitig gekündigt wird. Wer den Umzugstermin erst plant und dann in den Vertrag schaut, stellt manchmal fest, dass die Frist vor zwei Wochen abgelaufen ist.

Bewährt hat sich diese Abfolge: Frist nachsehen, Umzugstermin davor legen, umziehen, prüfen, dann kündigen.

An vier Prüfungen, die zusammen eine Viertelstunde dauern und die meisten Fehler aufdecken.

Zuerst das Offensichtliche: Startseite, ein paar Unterseiten, das Kontaktformular mit echtem Versand, bei einem Shop eine Testbestellung bis zur Kasse. Dann der Blick in den Quelltext auf noindex und in die robots.txt auf ein vergessenes Komplettverbot, das sind die beiden Fehler mit der größten Wirkung.

Danach die Search Console. Dort zeigt das URL-Prüftool, ob Google die Seite abrufen kann, und der Bericht zur Indexierung meldet neue Fehler meist binnen weniger Tage. Google empfiehlt für diese Phase ausdrücklich, den Verkehr auf altem und neuem System zu beobachten.

Zuletzt die Technik: Läuft HTTPS mit gültigem Zertifikat, kommen Mails aus dem Formular an, stimmt die PHP-Version. Und eine Messung der Ladezeit, damit du schwarz auf weiß hast, was der Wechsel gebracht hat. Was dafür zählt, steht im Themenblock Ladezeit und Core Web Vitals.

Ja, sobald auf deiner Seite personenbezogene Daten anfallen. Das ist schon bei einem Kontaktformular der Fall und erst recht bei Kommentaren, Kundenkonten oder einem Newsletter.

Die Begründung ist schlicht: Dein Hoster speichert diese Daten in deinem Auftrag und ist damit Auftragsverarbeiter. Artikel 28 DSGVO verlangt dafür einen Vertrag, der Gegenstand, Dauer, Art und Zweck der Verarbeitung festhält, dazu die Arten der Daten, die Kategorien der Betroffenen sowie die Rechte und Pflichten beider Seiten.

Der Landesbeauftragte für den Datenschutz Baden-Württemberg hält in seiner Darstellung fest, dass die Auftragsverarbeitung nur auf Grundlage eines bindenden Vertrags erfolgen darf und dass eine bloße Bestätigungsmail dafür nicht genügt. Zwei weitere Punkte stehen dort: Unterauftragnehmer braucht der Hoster genehmigt, und du musst dich laufend davon überzeugen, dass die zugesagten Garantien stimmen.

In der Praxis stellt jeder deutsche Hoster den Vertrag bereit, oft als Dokument im Kundenbereich zum Abrufen. Vorhanden heißt dabei nicht abgeschlossen: Er gehört angesehen, bestätigt und abgelegt.

Nein. Die DSGVO schreibt keinen bestimmten Standort vor, solange er innerhalb der EU liegt.

Ein deutscher Standort erspart dir trotzdem Arbeit. Liegen die Daten außerhalb der EU, greift Kapitel V der DSGVO mit den Regeln für Drittlandübermittlungen, und dann brauchst du eine Rechtsgrundlage dafür, musst sie dokumentieren und in der Datenschutzerklärung nennen. Innerhalb der EU entfällt diese ganze Prüfung.

Vorsicht ist bei der Frage geboten, wo die Daten wirklich liegen. Ein Anbieter mit deutscher Adresse kann Server in einem anderen Land betreiben oder einen Dienstleister außerhalb der EU für Sicherungen, Überwachung oder Support einsetzen. Genau diese Unterauftragnehmer muss der Auftragsverarbeitungsvertrag auflisten, und dort steht es dann auch.

Technisch kommt der kürzere Weg dazu, der bei deutschem Publikum die Antwortzeit senkt. Unsere Server stehen in Frankfurt am Main, dazu steht mehr im Abschnitt Rechenzentrum und unter Rechenzentrum.

Der Hoster gehört als Empfänger der Daten hinein, zusammen mit dem Zweck und der Rechtsgrundlage. Artikel 13 DSGVO verlangt diese Angaben beim Erheben der Daten, also auf der Seite selbst.

Konkret sind das vier Dinge. Wer der Anbieter ist und wo er sitzt. Dass er die Daten im Auftrag verarbeitet und dass dafür ein Vertrag nach Artikel 28 besteht. Welche Daten beim Aufruf anfallen, in der Regel die Server-Protokolle mit IP-Adresse, Zeitpunkt, abgerufener Seite und Browserkennung. Und wie lange diese Protokolle aufbewahrt werden.

Die Rechtsgrundlage für die Protokolle ist üblicherweise das berechtigte Interesse am sicheren Betrieb. Liegen Server außerhalb der EU, kommt die Grundlage für die Drittlandübermittlung dazu.

Ein Muster vom Hoster ist ein guter Anfang und selten das Ende. Es beschreibt dessen Leistung, nicht deine Seite. Was deine Seite darüber hinaus erhebt, etwa über ein Formular oder eine Reichweitenmessung, musst du selbst ergänzen.

So lange, wie es für den sicheren Betrieb nötig ist, und keinen Tag länger. Eine feste Zahl nennt die DSGVO nicht, sie verlangt in Artikel 5 die Begrenzung auf das Erforderliche.

In der Praxis haben sich sieben bis vierzehn Tage eingebürgert. Diese Spanne reicht, um einen Angriff nachzuvollziehen oder einen Fehler zu suchen, und lässt sich mit dem Zweck begründen. Mehrere Monate lassen sich dagegen kaum rechtfertigen, wenn in der Zwischenzeit niemand hineinschaut.

Rechtlich ist das Feld seit Jahren in Bewegung. Der Bundesgerichtshof hat 2017 im Anschluss an das Breyer-Urteil entschieden, dass eine Speicherung erlaubt sein muss, soweit sie der Funktionsfähigkeit des Dienstes dient. Der Bundesdatenschutzbeauftragte hat das begrüßt und zugleich Nachbesserungen beim Gesetzgeber angemahnt.

Wichtig für dich ist die Übereinstimmung: Die Frist in deiner Datenschutzerklärung muss die sein, die dein Hoster tatsächlich einstellt. Steht dort sieben Tage und der Server behält dreißig, stimmt die Erklärung nicht.

In aller Regel ja. Der Europäische Gerichtshof hat das im Verfahren Breyer am 19. Oktober 2016 für dynamische IP-Adressen entschieden.

Die Begründung ist für Betreiber lehrreich. Es genügt, dass du die Person nicht selbst identifizieren kannst, solange rechtliche Mittel bestehen, sie über den Zugangsanbieter bestimmen zu lassen. Nach dem Urteil sind alle Informationen dafür nicht in einer Hand nötig. Der Bundesdatenschutzbeauftragte hat die Entscheidung entsprechend eingeordnet.

Für den Betrieb heißt das: Jede Zeile im Server-Protokoll enthält ein personenbezogenes Datum. Damit gelten Zweckbindung, Speicherbegrenzung und Informationspflicht, und darum steht die Protokollierung in jeder brauchbaren Datenschutzerklärung.

Das Urteil erging noch zur alten Datenschutzrichtlinie. Übernommen wurde die Linie in die DSGVO, die den Personenbezug in Artikel 4 ähnlich weit fasst. Eine Rechtsberatung ist dieser Absatz nicht.

Dann kommt zur Auftragsverarbeitung eine zweite Prüfung hinzu: ob für dieses Land ein angemessenes Datenschutzniveau besteht und worauf sich die Übermittlung stützt.

Betroffen sind mehr Fälle, als die meisten vermuten. Ein Content Delivery Network, ein Dienst für Schadcode-Erkennung, ein Werkzeug zur Reichweitenmessung, ein externer Mailversender: Jeder davon kann Daten außerhalb der EU verarbeiten, auch wenn dein Webspace in Frankfurt steht.

Die Prüfung liegt bei dir, nicht beim Hoster. Der Europäische Datenschutzausschuss hält in seiner Leitlinie 07/2020 fest, dass die Regeln aus Kapitel V für Auftragsverarbeiter wie für Verantwortliche gelten und dass du dich von den zugesagten Garantien laufend überzeugen musst.

Der einfachste Weg ist der, eine solche Verarbeitung zu vermeiden. Bei FastPress liegen Server, Sicherungen und Schutzmechanismen im selben deutschen Rechenzentrum, deshalb stellt sich die Frage für das Hosting selbst nicht. Für alles, was du zusätzlich einbindest, bleibt sie offen.

Beide, jeder für seinen Teil. Nach Artikel 82 DSGVO haftet der Verantwortliche für Schäden aus einer rechtswidrigen Verarbeitung, der Auftragsverarbeiter dagegen nur, wenn er seine eigenen Pflichten verletzt oder gegen rechtmäßige Weisungen gehandelt hat.

Übersetzt auf eine Webseite: Wird deine Seite über ein seit Monaten nicht aktualisiertes Plugin übernommen, liegt das in deinem Verantwortungsbereich. Geht die Datenbank verloren, weil der Hoster seine Sicherungen nicht im Griff hatte, liegt es in seinem.

Nach außen bist du trotzdem die erste Adresse. Betroffene Personen und die Aufsichtsbehörde wenden sich an den Verantwortlichen, und das bist du als Betreiber. Die Meldepflicht aus Artikel 33 triffst ebenfalls du, auch wenn die Ursache beim Dienstleister lag. Mehr dazu im Themenblock Sicherheit.

Vertraglich lässt sich das nicht wegschieben. Artikel 28 verlangt gerade deshalb, dass du nur Auftragsverarbeiter beauftragst, die hinreichende Garantien bieten. Diese Auswahl ist selbst eine deiner Pflichten.

Dass der Betreiber ein geprüftes Managementsystem für Informationssicherheit hat. Eine unabhängige Stelle hat bestätigt, dass Risiken systematisch erfasst, Maßnahmen festgelegt und regelmäßig überprüft werden.

Das ist mehr als ein Aufkleber, weil die Prüfung wiederholt wird und Abweichungen dokumentiert werden müssen. Für dich ist es vor allem ein Beleg, der sich bei einer Datenschutzprüfung vorzeigen lässt: Die Auswahl eines Dienstleisters mit hinreichenden Garantien nach Artikel 28 wird damit nachvollziehbar.

Was die Bescheinigung nicht sagt, gehört zur ehrlichen Einordnung. Sie bewertet Prozesse, keine einzelne Webseite. Dass ein Rechenzentrum zertifiziert ist, macht deine WordPress-Installation nicht sicher, und sie sagt nichts über die Qualität des Supports oder die Geschwindigkeit der Server.

Wichtig ist außerdem, worauf sich die Bescheinigung bezieht. Zertifiziert ist meist der Betreiber des Rechenzentrums, nicht jeder Anbieter, der dort Fläche gemietet hat. Unsere Server stehen im Werkhaus-Rechenzentrum in Frankfurt, Näheres im Abschnitt Rechenzentrum.

Das Hosting selbst setzt keine Cookies. WordPress tut es, und dort liegt auch die Antwort.

Maßgeblich ist § 25 TDDDG. Danach braucht das Speichern von Informationen auf dem Endgerät grundsätzlich eine Einwilligung. Ausgenommen ist, was unbedingt erforderlich ist, damit ein ausdrücklich gewünschter Dienst bereitgestellt werden kann.

In diese Ausnahme fallen die Cookies, die WordPress für Anmeldung und Formularsicherheit setzt, sowie das Sitzungs-Cookie eines Warenkorbs, sobald wirklich etwas darin liegt. Die Aufsichtsbehörden legen das eng aus: Ihre Orientierungshilfe prüft jeden Cookie und jeden Zweck einzeln, und bei mehreren Zwecken muss die Ausnahme für jeden davon gelten.

Nicht ausgenommen ist alles zur Reichweitenmessung. Der Bundesdatenschutzbeauftragte hält selbst Matomo nicht für erforderlich im Sinne der Vorschrift. Ein Sitzungs-Cookie zur Abwehr von Überlastungsangriffen dagegen schon. Eine Rechtsberatung ist dieser Absatz nicht.

Wenn du online Verträge mit Verbrauchern schließt, muss die Seite barrierefrei sein. Reine Darstellungsseiten ohne Bestell- oder Buchungsfunktion sind nach den Leitlinien in der Regel nicht erfasst.

Die wichtigste Ausnahme steht in § 3 Absatz 3 BFSG: Kleinstunternehmen, die Dienstleistungen anbieten, sind von der Pflicht ausgenommen. Als Kleinstunternehmen gilt, wer weniger als zehn Beschäftigte hat und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme. Beide Grenzen zählen, eine davon zu reißen beendet die Ausnahme.

Für Produkte gilt die Ausnahme nicht. Wer Produkte in Verkehr bringt, die unter das Gesetz fallen, ist auch als Kleinstunternehmen betroffen. Die Bundesfachstelle Barrierefreiheit arbeitet diese Abgrenzung mit Beispielen auf und berät Kleinstunternehmen kostenlos.

Mit dem Hosting hat das wenig zu tun, es betrifft Theme und Inhalte. Erwähnt ist es hier, weil die Frage bei jeder Entscheidung über eine neue Webseite auftaucht. Eine Rechtsberatung ist dieser Absatz nicht, für den Einzelfall gehört ein Blick in die Leitlinien dazu.

PHP ist die Programmiersprache, in der WordPress geschrieben ist. Bei jedem Seitenaufruf baut PHP auf dem Server die Seite zusammen, holt die Inhalte aus der Datenbank und schickt fertiges HTML an den Browser.

Neue Versionen gibt es, weil die Sprache gepflegt wird wie jede Software. Nach den Angaben des PHP-Projekts bekommt jeder Versionszweig zwei Jahre lang Fehler- und Sicherheitskorrekturen und danach zwei weitere Jahre nur noch Korrekturen für kritische Lücken. Stand Oktober 2026 endet die Unterstützung für PHP 8.2 am 31. Dezember 2026, für PHP 8.3 ein Jahr später.

WordPress zieht mit. Die offiziellen Anforderungen nennen inzwischen PHP 8.3 oder höher als Empfehlung und halten fest, dass ältere Versionen ab PHP 7.4 zwar noch laufen, aber das Ende ihrer Unterstützung erreicht haben und ein Sicherheitsrisiko darstellen.

Der Wechsel ist der heikle Teil, weil ein älteres Plugin mit einer neuen Version nicht zurechtkommen kann. Deshalb gehört er in eine Testumgebung. Mehr unter PHP und PHP-FPM.

Alle drei sind Webserver, also das Programm, das Anfragen aus dem Internet annimmt und beantwortet. Sie unterscheiden sich darin, wie sie viele gleichzeitige Anfragen verarbeiten.

Apache ist der älteste und arbeitet klassisch mit einem Prozess oder Thread je Verbindung. Das ist robust und flexibel, braucht bei vielen gleichzeitigen Besuchern aber viel Arbeitsspeicher. NGINX dreht das Prinzip um und bedient viele Verbindungen in wenigen Prozessen, was bei Last sparsamer ist.

LiteSpeed arbeitet nach demselben sparsamen Prinzip wie NGINX, versteht aber die Konfigurationsdateien von Apache und bringt einen eigenen Cache mit, der die fertige Seite ohne zusätzliches Plugin ausliefert. Dieser eingebaute Cache ist für WordPress der eigentliche Unterschied im Alltag.

Für dich als Betreiber ist das selten eine Wahl, sondern eine Eigenschaft des Tarifs. Welchen wir einsetzen und warum, steht auf der Seite LiteSpeed Webserver, der direkte Vergleich im Ratgeber unter LiteSpeed gegen Apache.

Für alle Inhalte. Seiten, Beiträge, Menüs, Einstellungen, Benutzer, Kommentare und bei einem Shop die Bestellungen stehen in der Datenbank, nicht in Dateien.

Auf dem Webspace liegen dagegen die Programmdateien von WordPress, Theme und Plugins sowie die Bilder aus der Mediathek. Beim Aufruf einer Seite führt PHP den Code aus, fragt die Inhalte aus der Datenbank ab und setzt beides zu einer Seite zusammen.

Daraus erklären sich zwei Dinge aus dem Alltag. Warum eine Sicherung beide Teile braucht, denn eines ohne das andere ergibt keine Seite. Und warum die Geschwindigkeit der Datenbank bis auf die Seite durchschlägt: Eine typische WordPress-Seite stellt pro Aufruf Dutzende Abfragen, bei einem Shop deutlich mehr.

Als Datenbanksystem kommt MariaDB oder MySQL zum Einsatz, die Anforderungen von WordPress nennen MariaDB 10.11 oder MySQL 8.0 als Mindestversion. Mehr unter Datenbank und MariaDB.

Kürzere Antwortzeiten bei vielen kleinen Zugriffen, und genau die hat WordPress. Eine Seite besteht aus Dutzenden Datenbankabfragen und vielen kleinen Dateien, nicht aus einem großen Datenblock.

Der technische Unterschied liegt im Anschluss. Eine herkömmliche SSD hängt an derselben Schnittstelle wie früher die Festplatte und erbt deren Beschränkungen. NVMe spricht direkt über den PCI-Express-Bus mit dem Prozessor und kann dabei viele Anfragen gleichzeitig abarbeiten statt nacheinander.

Wo es sich bemerkbar macht, ist vorhersehbar: im Backend, bei Shop-Abfragen und bei allem, was am Cache vorbeiläuft. Eine zwischengespeicherte Seite für anonyme Besucher kommt auch von langsamerem Speicher schnell genug.

Der Zahlenvergleich aus Datenblättern taugt dafür wenig, weil dort die Übertragungsrate großer Dateien steht und nicht die Antwortzeit kleiner Zugriffe. Mehr unter NVMe-SSD.

Er speichert Ergebnisse von Datenbankabfragen im Arbeitsspeicher, damit WordPress dieselbe Frage nicht bei jedem Aufruf neu stellen muss.

Der Unterschied zum Seiten-Cache ist wichtig. Ein Seiten-Cache legt die fertige HTML-Seite ab und funktioniert nur für Besucher, die alle dasselbe sehen dürfen. Ein Object-Cache greift eine Ebene tiefer: Die Seite wird weiterhin für jeden einzeln gebaut, die Zutaten liegen aber schon bereit.

Deshalb wirkt er genau dort, wo der Seiten-Cache aufhört. Im Backend, bei eingeloggten Nutzern, im Warenkorb und auf Seiten, die für jeden Besucher anders aussehen. Bei einem Shop mit vielen Produkten ist das der größte einzelne Hebel.

Ohne Object-Cache ist das kein Fehler, sondern eine Grenze. Eine Seite ohne Anmeldung und ohne Shop merkt kaum einen Unterschied. Mehr unter Redis und auf der Seite Redis Object-Cache.

OPcache hält den übersetzten PHP-Code im Arbeitsspeicher, damit PHP die Dateien nicht bei jedem Aufruf neu übersetzen muss. Gemerkt wird er nicht, weil er nichts am Ergebnis ändert, nur am Weg dorthin.

Ohne ihn läuft bei jedem Seitenaufruf derselbe Vorgang: PHP liest die Dateien von WordPress, Theme und Plugins ein, übersetzt sie in eine maschinennahe Form und führt sie aus. Bei einer Installation mit zwanzig Plugins sind das einige tausend Dateien, und der Code darin hat sich seit dem letzten Aufruf nicht geändert.

Das ist eine Einstellung auf Serverebene, kein Plugin. Ein- und ausschalten kannst du ihn in der Regel nicht, dein Anbieter liefert ihn mit oder nicht. Die Dokumentation von PHP beschreibt ihn als Erweiterung, die seit PHP 5.5 mitgeliefert und in der Standardkonfiguration aktiviert wird.

Eine Nebenwirkung gehört dazu: Nach dem Einspielen neuer Dateien kann der alte Code noch kurz im Speicher stehen. Deshalb leeren Hoster und Deploy-Werkzeuge ihn nach Änderungen mit. Mehr unter OPcache.

Diese Frage hat keine seriöse Antwort in Besucherzahlen, und jeder Anbieter, der eine nennt, hat Annahmen getroffen, die er nicht dazuschreibt.

Entscheidend ist, wie viel Arbeit ein Aufruf kostet. Eine zwischengespeicherte Seite ohne Anmeldung verbraucht fast nichts, davon verträgt ein kleiner Tarif sehr viele gleichzeitig. Derselbe Tarif kommt bei fünfzig gleichzeitigen Shop-Besuchern mit gefülltem Warenkorb ins Straucheln, weil jeder davon PHP und Datenbank beschäftigt.

Der zweite Punkt ist die Verteilung. Zehntausend Besucher über den Tag sind unproblematisch. Dieselbe Zahl in zwanzig Minuten nach einem Newsletter ist eine Lastspitze, und genau daran entscheidet sich, ob ein Tarif passt.

Brauchbare Anhaltspunkte sind die Zahl der Prozessorkerne, der Arbeitsspeicher und die Zahl gleichzeitiger PHP-Prozesse. Diese Angaben stehen bei uns in jedem Tarif, nachzulesen unter Tarife. Wenn du unsicher bist, hilft der Konfigurator mit ein paar Fragen weiter.

HTTP/3 ist die aktuelle Fassung des Übertragungsprotokolls zwischen Browser und Server. Der Gewinn zeigt sich bei schlechter Verbindung, also vor allem im Mobilfunk.

Der Unterschied steckt im Unterbau. Die Vorgänger setzen auf TCP, bei dem ein verlorenes Datenpaket alle nachfolgenden aufhält, auch wenn diese längst angekommen sind. HTTP/3 nutzt stattdessen QUIC auf UDP, wo jeder Datenstrom für sich läuft und ein Verlust nur den eigenen Strom bremst.

Dazu kommt der schnellere Verbindungsaufbau, weil Verschlüsselung und Verbindung in einem Schritt ausgehandelt werden. Bei einer stabilen Leitung im Büro ist der Gewinn klein, im Zug mit wechselnder Funkzelle größer.

Zutun hast du damit nichts. Der Server muss es anbieten, der Browser nimmt es dann von selbst. Mehr unter HTTP/3.

Weil ohne Verschlüsselung jeder im selben Netz mitlesen kann, was zwischen Browser und Server läuft, und weil Browser und WordPress es inzwischen voraussetzen.

Die Anforderungen von WordPress nennen HTTPS als für jede Installation erforderlich. Browser markieren unverschlüsselte Formulare als unsicher, und bei einem Kontaktformular ohne Verschlüsselung wandern Name, Mailadresse und Nachricht im Klartext durchs Netz.

Der Datenschutz kommt dazu. Artikel 32 DSGVO verlangt Maßnahmen nach dem Stand der Technik, und Verschlüsselung bei der Übertragung gehört dort seit Jahren zur Grundausstattung.

Kosten sind kein Argument mehr. Über Let’s Encrypt sind Zertifikate kostenlos und erneuern sich automatisch, bei uns in jedem Tarif eingerichtet. Mehr unter SSL, HTTPS und Let’s Encrypt.

Er führt Aufgaben zu festgelegten Zeiten aus: geplante Beiträge veröffentlichen, Sicherungen anstoßen, Updates prüfen, Mails aus der Warteschlange verschicken.

WordPress bringt dafür eine eigene Lösung mit, und die hat eine Eigenart. WP-Cron hängt an den Seitenaufrufen statt an der Uhr. Bei jedem Besuch prüft WordPress, ob etwas fällig ist, und arbeitet es dann ab. Auf einer Seite mit wenig Verkehr verspäten sich Aufgaben deshalb, manchmal um Stunden.

Der umgekehrte Fall tritt bei viel Verkehr ein: Die Prüfung läuft bei jedem einzelnen Aufruf mit und kostet Rechenzeit. Beides lässt sich lösen, indem WP-Cron abgeschaltet und stattdessen ein echter Cronjob auf dem Server eingerichtet wird, der im festen Takt anklopft.

Das ist eine Einstellung auf Serverebene und bei uns in jedem Tarif möglich. Mehr unter Cronjob.

Weil sich rund um die Seite laufend etwas ändert, auch wenn an ihr selbst niemand etwas anfasst. Der Code von gestern ist derselbe wie heute, nur sind inzwischen Lücken darin öffentlich bekannt.

Patchstack zählt für das Jahr 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Umfeld, 91 Prozent davon in Plugins. Jede einzelne betrifft Seiten, die am Tag davor fehlerfrei liefen. Neu ist nur, dass die Schwachstelle jetzt in einer Datenbank steht, die auch Angreifer lesen.

Der zweite Takt kommt vom Server. PHP-Versionen laufen nach vier Jahren aus, und dann muss die Seite auf eine neuere wechseln, ob sie will oder nicht. Ob Theme und Plugins das mitmachen, zeigt sich vorher in einer Testumgebung oder nachher auf der Live-Seite.

Manches sieht man der Seite von außen gar nicht an. Ein Kontaktformular, dessen Nachrichten seit Wochen nirgends ankommen, sieht aus wie eines, das funktioniert. Deshalb gehört zur Wartung die Prüfung nach dem Update und nicht nur das Update.

Vier Dinge, die regelmäßig wiederkehren: sichern, aktualisieren, prüfen, dokumentieren. Alles andere ist Zusatz.

Gesichert wird vor jedem Eingriff, damit es einen Rückweg gibt. Aktualisiert werden WordPress selbst, die Plugins und das Theme, kontrolliert statt blind, weil ein großer Versionssprung anders zu behandeln ist als eine Sicherheitskorrektur. Geprüft werden danach die Stellen, an denen ein Fehler weh tut: Formular, Menü, mobile Ansicht, bei einem Shop Warenkorb und Kasse. Dokumentiert wird, was wann eingespielt wurde.

Dazu kommt die Pflege der Umgebung drumherum. SSL-Zertifikat, PHP-Version, Sicherheitseinstellungen, dazu eine Überwachung, die meldet, wenn die Seite nicht erreichbar ist.

Nicht dazu gehören neue Inhalte und Umbauten. Ein neuer Unterseiten-Bereich oder ein geändertes Layout ist Projektarbeit und wird getrennt gerechnet. Was bei uns in welchem Paket steckt, steht auf der Seite WordPress-Wartung.

Einmal im Monat ist die vertretbare Untergrenze, alle 14 Tage der bessere Takt für Seiten, an denen Umsatz hängt.

Beim kurzen Abstand geht es um die Zuordnung, weniger um die Menge der Updates. Spielst du jede Woche zwei Updates ein und danach klemmt etwas, ist die Ursache in Minuten gefunden. Sammeln sich dreißig Updates über ein halbes Jahr und du spielst sie an einem Nachmittag ein, suchst du einen Tag.

Dazwischen gibt es Anlässe, die keinen Termin abwarten. Eine kritische Sicherheitslücke in einem Plugin, das du einsetzt, gehört am selben Tag geschlossen. Dafür braucht es jemanden, der solche Meldungen überhaupt mitbekommt.

Bei uns läuft die Wartung im Paket Basis monatlich und ab Wartung Plus alle 14 Tage. Welche Taktung zu deiner Seite passt, hängt davon ab, wie viele Plugins im Einsatz sind und was ein Ausfall kostet.

Weil Plugins ineinandergreifen und niemand alle Kombinationen testen kann. Dein Theme, zwanzig Plugins und eine bestimmte PHP-Version ergeben eine Zusammenstellung, die es sonst nirgends gibt.

Die häufigsten Ursachen sind banal. Ein Plugin setzt eine Funktion voraus, die ein anderes in der neuen Version umbenannt hat. Eine Erweiterung passt nicht mehr zum Hauptprodukt, weil sie vom selben Hersteller später aktualisiert wird. Oder der neue Code braucht eine höhere PHP-Version, als auf dem Server läuft.

Das Ergebnis ist dann oft die weiße Seite mit dem Satz über einen kritischen Fehler. Dahinter steckt ein fataler PHP-Fehler, und die Fehlermeldung dazu steht im Protokoll des Servers, nicht auf der Seite.

Verhindern lässt sich das nicht vollständig, abfedern schon: vorher sichern, in einer Kopie testen, danach prüfen. Das WordPress Toolkit im Plesk-Panel kann dafür vorab anzeigen, ob sich die Seite nach dem Update optisch verändert hat. Mehr dazu auf der Seite WordPress Toolkit.

Weil das Zurückspielen eines fünf Minuten alten Standes die schnellste Reparatur überhaupt ist. Jede Fehlersuche dauert länger.

Die tägliche Sicherung von heute Nacht hilft hier nur halb. Zwischen ihr und dem Update liegen vielleicht ein neuer Beitrag, zwei Formularnachrichten und eine Bestellung. Der Stand unmittelbar davor enthält all das.

Wichtig ist, dass Dateien und Datenbank zusammen gesichert werden. Ein Update ändert beides: die Programmdateien auf dem Webspace und oft auch die Struktur der Datenbank. Kommt nur ein Teil zurück, passt es nicht mehr zusammen.

Bei uns legt die Wartung diesen zusätzlichen Stand vor jedem Durchgang an, unabhängig von der täglichen Sicherung des Servers. Mehr zum Thema im Block Backups weiter oben.

Sie läuft, bis sie es nicht mehr tut, und der Übergang kommt ohne Vorwarnung. Meistens über eine Lücke in einem Plugin oder über eine PHP-Version, die der Anbieter abschaltet.

Der Ablauf ist in den Fällen, die uns erreichen, ähnlich. Zuerst fallen Kleinigkeiten aus, die niemand bemerkt: Das Formular verschickt nichts mehr, die Kartendarstellung lädt nicht, ein Zahlungsweg fehlt. Dann kommt der Tag, an dem der Hoster die alte PHP-Version abkündigt, und beim Umstellen zeigt sich, dass ein zentrales Plugin seit vier Jahren kein Update mehr bekommen hat.

An diesem Punkt gibt es selten eine schnelle Lösung. Ein Plugin, das aufgegeben wurde, lässt sich nicht aktualisieren, es muss ersetzt werden, und das kann die halbe Seite betreffen. Was als Wartung ein paar Stunden im Jahr gekostet hätte, wird zum Umbauprojekt.

Der zweite Weg ist der Einbruch. Eine übernommene Seite verschickt Werbemails oder leitet Besucher weiter, Google markiert sie, und der Besucherstrom bricht weg. Mehr dazu im Block Sicherheit.

Ja, und bei einer übersichtlichen Seite ist das gut machbar. Es scheitert selten am Können und meistens an der Regelmäßigkeit.

Was dazugehört, ist überschaubar: einmal im Monat einloggen, vorher sichern, Updates einspielen, danach die wichtigen Funktionen durchklicken. Mit einer Testumgebung lässt sich der riskante Teil vorher ausprobieren, und die gehört bei uns zum Tarif.

Die Stellen, an denen es in der Praxis hakt, sind andere. Im Urlaub und in stressigen Wochen fällt der Termin aus, und aus einem Monat werden sechs. Eine kritische Lücke in einem Plugin bekommt man nur mit, wenn man die Meldungen dazu verfolgt. Und wenn nach dem Update etwas kaputt ist, braucht es jemanden, der die Ursache findet, während die Seite steht.

Die ehrliche Abwägung ist also keine technische, sondern eine über Zeit und Vertretung. Wer sich das zutraut, braucht keine Wartung. Wer es zweimal verschoben hat, sollte sie abgeben.

Weil Entwicklung Geld kostet und viele Plugins von Einzelpersonen in ihrer Freizeit stammen. Wird das Projekt aufgegeben, bleibt der Code stehen, während WordPress und PHP weiterziehen.

Besonders unangenehm ist der Fall, in dem eine Lücke bekannt wird und niemand sie schließt. Patchstack hält für 2025 fest, dass 46 Prozent der Schwachstellen zum Zeitpunkt der Veröffentlichung keinen Patch des Entwicklers hatten. Bei einem aufgegebenen Plugin kommt er auch später nicht.

Erkennen lässt sich das vor der Installation. Im Verzeichnis von WordPress.org steht bei jedem Plugin, wann es zuletzt aktualisiert wurde und mit welcher WordPress-Version es getestet ist. Liegt beides mehr als ein Jahr zurück, ist Vorsicht angebracht.

Bei kostenpflichtigen Plugins ist das Risiko nicht kleiner. Patchstack weist für 2025 darauf hin, dass kostenpflichtige Komponenten dreimal so viele nachweislich ausgenutzte Lücken hatten wie kostenlose. Ein Preis ist keine Zusage auf Pflege, und bei einer unbezahlten Lizenz enden die Updates sowieso.

Das hängt daran, was die Seite leisten soll, nicht an ihrer Größe. Eine Seite mit fünf Unterseiten wird genauso automatisch angegriffen wie ein Shop.

Gegen Wartung spricht wenig bei einer Seite, die reine Visitenkarte ist, keine Daten sammelt und deren Ausfall niemandem auffällt. Dort reicht es, zweimal im Jahr selbst hineinzusehen.

Dafür spricht alles, sobald über die Seite Anfragen oder Termine hereinkommen. Dann ist sie ein Vertriebskanal, und ein stilles Formular kostet Aufträge, von denen du nie erfährst. Dasselbe gilt, wenn personenbezogene Daten anfallen, denn dann hängt an einem Einbruch auch eine Meldepflicht.

Die Rechnung lohnt sich im Einzelfall. Eine Wartung kostet im Jahr weniger als ein Tagessatz für eine Notbereinigung, und die fällt erfahrungsgemäß dann an, wenn gerade niemand Zeit hat. Die Pakete stehen offen auf der Seite WordPress-Wartung.

Nein, und wer das verspricht, verspricht zu viel. Wartung senkt die Wahrscheinlichkeit und verkürzt die Zeit bis zur Wiederherstellung.

Die Lücke, die bleibt, ist beschreibbar. Zwischen dem Bekanntwerden einer Schwachstelle und dem Update des Entwicklers vergeht Zeit, bei 46 Prozent der Fälle im Jahr 2025 gab es zum Veröffentlichungszeitpunkt überhaupt keines. In diesem Fenster hilft kein Update, sondern nur ein Filter auf Serverebene, der das Angriffsmuster erkennt.

Dazu kommen Wege, die mit Software nichts zu tun haben. Ein Administratorpasswort aus einem fremden Datenleck, ein Zugang bei einem ehemaligen Dienstleister, ein unachtsamer Klick auf eine gefälschte Anmeldeseite. Dagegen hilft der zweite Faktor, nicht die Wartung.

Realistisch ist deshalb ein anderer Anspruch: Die wahrscheinlichen Wege schließen, die Überwachung so einrichten, dass ein Vorfall in Stunden auffällt, und eine geprüfte Sicherung bereithalten. Was auf Serverebene dazukommt, steht auf der Seite Imunify360.