Website im Notfall wiederherstellen und so neu bauen, dass sie online bleibt.

Was umfasst die Notfallreparatur einer Website?

Eine Notfallreparatur umfasst vier Schritte: Stellen Sie fest, was defekt ist, verhindern Sie weitere Schäden, stellen Sie eine einwandfreie Kopie wieder her und schließen Sie die Sicherheitslücke, durch die der Angreifer eindringen konnte. Rufen Sie zunächst Ihre Startseite, eine Unterseite und Ihren Admin-Login-Bereich auf. Halten Sie fest, welche Seiten Fehlermeldungen zeigen, welche seltsame Inhalte ausliefern und welche weiterhin funktionieren. Schreiben Sie das auf: Unter Stress lässt das Gedächtnis nach, und an einer schriftlichen Liste erkennen Sie, welche Art von Reparatur nötig ist.

Wurde Ihre Website gehackt? Beginnen Sie mit einer Bestandsaufnahme des Schadens. Google empfiehlt in seinen Anleitungen, Ihre Website auf veränderte Dateien und verdächtige Aktivitäten auf Ihrem Server zu prüfen und sich umgehend an Ihren Hosting-Anbieter zu wenden. Führen Sie dieselben Prüfungen auch auf Ihrem eigenen Server durch. Möglicherweise hat stattdessen ein Update Ihre Website lahmgelegt. Dann suchen Sie die Änderung und machen sie rückgängig. Ist Ihre Website verschwunden, brauchen Sie eine Quelle für ihre Inhalte, sei es Ihr Backup, Ihre Datenbank oder eine archivierte Kopie. Die kostenlose Analyse hilft Ihnen dabei. Auch wenn Ihre Live-Website nicht erreichbar ist, liest sie für Sie den öffentlichen Index der Wayback Machine aus. Eine nicht erreichbare Website ist also keine Sackgasse: Sie haben weiterhin Material, mit dem Sie arbeiten können.

Was sollten Sie in der ersten Stunde tun, nachdem Ihre Website ausgefallen ist oder gehackt wurde??

Prüfen Sie in der ersten Stunde, welche Bereiche ausgefallen sind. Rufen Sie dazu Ihre Startseite, eine Unterseite und Ihren Admin-Login von einem anderen Netzwerk aus auf: So sehen Sie, ob die gesamte Website ausgefallen ist oder nur ein Teil davon. Laden Sie die Protokolle des Servers und Ihre neuesten Sicherungskopien herunter, bevor jemand den Server anfasst. Kopieren Sie beides an einen sicheren Ort. Eine Neuinstallation, die die Beweismittel überschreibt, führen Sie nicht durch. Wie Google empfiehlt, wenden Sie sich umgehend an Ihren Hosting-Anbieter. Ändern Sie danach alle Ihre Zugangsdaten, also die Passwörter für Hosting, Admin-Bereich, Datenbank und FTP.

Wurde Ihre Website gehackt, nehmen Sie sie vom Netz oder geben Sie einen 503-Statuscode aus. Google erklärt, das sei besser, als das Crawling mit der robots.txt-Datei zu blockieren, weil so keine Malware zu Ihren Besuchern gelangt. Kopieren Sie Ihre Dateien und Protokolle, bevor Sie irgendetwas neu installieren. Die meisten Nutzer löschen diese Kopien. Dabei zeigen gerade sie, wie der Angreifer eindringen konnte. Für die Wiederherstellung Ihres Servers empfiehlt Google, das Betriebssystem vollständig aus einer vertrauenswürdigen Quelle neu zu installieren und danach Ihr sauberes Backup einzuspielen. Ist die Website wieder online, beantragen Sie eine Überprüfung. Behalten Sie die Lage weiter im Auge.

Kann man eine Website aus der Wayback Machine wiederherstellen?

Ja, den sichtbaren Frontend-Bereich Ihrer Website können Sie oft über die Wayback Machine wiederherstellen, allerdings nur mit den Seiten, Bildern und Dateien, die deren Crawler erfasst hat. Öffnen Sie den Snapshot Ihrer Startseite. Hinter web.archive.org/web/ steht ein 14-stelliger Zeitstempel (JJJJMMTThhmmss). Fügen Sie dort einen Modifikator hinzu. Damit rufen Sie die Rohdatei (id_), einen Screenshot (im_), das JavaScript (js_) oder das CSS (cs_) ab.

Ihre Snapshots stehen im öffentlichen CDX-Index. Er listet Zeitstempel, Original-URL, MIME-Typ, Statuscode, Digest und Länge auf. Die Auswertung liest diesen Index für Sie aus. Sie sehen, für wie viele Monate ein Homepage-Snapshot vorliegt, wann Ihr erster und Ihr letzter fehlerfreier Snapshot entstanden sind und wie viele eindeutige Seiten, Bilder und PDF-Dateien archiviert sind. Der Abruf funktioniert, ob Ihre Live-Website antwortet oder nicht. Ist sie nicht erreichbar, sehen Sie statt einer Bewertung den Archivdatensatz. Prüfen Sie Ihre Erfassungen, bevor Sie die Website neu erstellen: Dann wissen Sie genau, was Ihnen noch zur Verfügung steht.

Was lässt sich aus einer archivierten Kopie wiederherstellen, und was ist endgültig verloren?

Eine archivierte Kopie Ihrer Website stellt wieder her, was Ihre Besucher gesehen haben: gerenderten HTML-Code, Bilder und Dateien. Verloren gehen Ihre Datenbank, Ihre Benutzerkonten, Ihre Formularverarbeitung und Ihr Servercode. Öffnen Sie eine archivierte Unterseite und zeigen Sie deren Quellcode an. Sie finden den fertigen Markup-Code, aber nicht die Vorlagen oder Abfragen, mit denen die Seite erstellt wurde. Öffentliche Erfassungen enthalten ausschließlich Frontend-Code. Stellen Sie sich ein Foto des Gebäudes vor: schön anzusehen, aber unbewohnbar. Das Gebäude, das Sie betrieben haben, ist es nicht.

Rechnen Sie mit Lücken in Ihrer Kopie. Hat der Crawler eine CSS-Datei oder eine Unterseite übersehen, kann sie niemand nachgenerieren, und nicht jede Seite und nicht jede Aktualisierung steckt in der gespeicherten Kopie. Dynamische Inhalte fehlen häufig. Videos, Skripte und interaktive Inhalte werden möglicherweise nicht geladen, und in einigen Momentaufnahmen fehlen Bilder. Eine blockierte Archivierung oder restriktive „robots.txt“-Regeln führen zu Lücken. War Ihre Website eine React-, Vue- oder Angular-Anwendung, ist Ihre Erfassung womöglich unvollständig. Momentaufnahmen aus einer Zeit, in der Ihre Website serverseitig gerendert wurde, können dagegen besser ausfallen.

Sollten Sie die alte Website reparieren oder neu bauen?

Überarbeiten Sie Ihre alte Website, wenn Sie eine kleine Broschüren-Website betreiben und das Problem auf eine einzelne, identifizierbare Änderung zurückgeht. Bauen Sie sie neu, wenn derselbe Fehler immer wieder auftritt oder das Support-Ende Ihrer Software schon verstrichen ist. Prüfen Sie zuerst Ihre Version. Drupal 7 hat am 5. Januar 2025 das Ende der Lebensdauer erreicht. Für Ihren Kern, die Module von Drittanbietern und die Designs erhalten Sie damit keine Sicherheitshinweise mehr. Adobe Commerce 2.3? Der reguläre Support dafür endete am 8. September 2022. Nutzen Sie heute noch eine dieser Versionen? Dann passt niemand mehr auf Ihre Sicherheit auf.

Die Option „Reparieren“ passt, wenn Ihre Website bis zu einem bestimmten Update oder bis zum Passwortdiebstahl einwandfrei lief. Dann besteht die Behebung womöglich nur aus einer sauberen Sicherung, einem Patch und neuen Passwörtern, und dabei können Sie es belassen. Ein „Neuaufbau“ passt, wenn Sie die Website schon mehr als einmal wiederhergestellt haben oder ein Archiv die einzige Kopie Ihrer Inhalte enthält. Und welcher Fall bei Ihnen vorliegt, zeigen die Belege hinter jeder Säule Ihrer Bewertung. Ihre Aufgabe ist es, Ihre Frage zu klären (und nicht, sie in die Länge zu ziehen).

Warum gehen Plugin-basierte Websites immer wieder kaputt?

Ihre auf Plugins basierende Website stürzt immer wieder ab, weil jedes Plugin Code eines Drittanbieters in Ihrem Aufrufpfad ist, der nach dem Zeitplan eines anderen aktualisiert wird und nicht nach Ihrem eigenen. Öffnen Sie Ihre Plugin-Liste und zählen Sie die Autoren: Jedem Einzelnen haben Sie Einfluss auf Ihre Website gewährt. Und jedes beliebige Paar von Plugins kann nach einem Update in Konflikt geraten. Der Bericht von Patchstack aus dem Jahr 2026 führt 91 % der neuen Sicherheitslücken auf Plugins zurück, 9 % auf Themes und nur 6 % auf den WordPress-Kern, alle mit niedriger Priorität. Ihr Kern ist selten die Schwachstelle, Ihre Plugins und Themes sind es. Ihre Plugins, Ihr Risiko.

Patchstack berichtet, dass für 46 % der Sicherheitslücken zum Zeitpunkt der öffentlichen Bekanntgabe noch kein Patch des Entwicklers vorlag. Auf Plugin-Updates als Schutzmaßnahme können Sie sich daher nicht verlassen. Wenn Sie WordPress betreiben, hatten Sie es 2025 mit 11.334 neuen Sicherheitslücken zu tun, 42 % mehr als die 7.966 im Jahr 2024. Bei den am häufigsten ausgenutzten Lücken vergehen im Mittel 5 Stunden bis zur massenhaften Ausnutzung. Das ist kürzer als Ihr Arbeitstag. Und Ihr Patching muss schneller sein.

Wie vermeiden Next.js, Astro, Sanity und Supabase dieselben Fehler?

Ihre Besucher erhalten vorgefertigte Seiten, ohne dass Datenbank oder PHP in Ihrem Anforderungspfad liegen. Ihre Bearbeitungsfunktionen und Ihre Daten liegen in separaten gehosteten Diensten. Astro rendert den Großteil Ihrer Seite in statisches HTML und entfernt standardmäßig clientseitiges JavaScript, sodass Sie dieses nur für interaktive Komponenten hinzufügen. Mit der inkrementellen statischen Neugenerierung von Next.js werden Ihre Inhalte aktualisiert, ohne dass die ganze Website neu erstellt werden muss. Schlägt die Neugenerierung im Hintergrund fehl, liefert Ihre Seite einfach die alte Version weiter aus (unverändert). Und Sanity speichert Ihre Inhalte als strukturierte JSON-Dokumente mit Revisionsverlauf, die über eine CDN-verteilte API bereitgestellt werden.

Supabase schützt Ihre Daten und Ihre Anmeldedaten durch Sicherheit auf Zeilenebene. Ohne diese Funktion kann jede Rolle mit passender Berechtigung eine Tabelle in einem öffentlich zugänglichen Schema lesen und schreiben, prüfen Sie daher bitte Ihre Richtlinien. Auf Ihrem Host bemerken Sie eine Änderung in der Vorschau-Bereitstellung, bevor sie veröffentlicht wird. Vercel Instant Rollback setzt Sie innerhalb von Sekunden auf eine frühere Produktionsbereitstellung zurück. Abhängigkeiten müssen weiterhin aktualisiert werden, und Ihre Builds können nach wie vor fehlschlagen. Was Sie gewinnen, ist ein geringerer Auswirkungsbereich. Wartungsfrei wird Ihr System dadurch nicht.

Ist es möglich, eine WordPress-, Drupal-, Magento- oder Wix-Website auf einen modernen Headless-Stack zu migrieren??

Ja. Läuft Ihre Website auf WordPress, Drupal, Magento, Wix, Squarespace oder Joomla, kann ich sie auf einen modernen Headless-Stack umstellen. Ich repariere defekte Websites und baue sie auf diesem Stack neu auf, sodass Ihre Website mit Ihren Inhalten aus Ihrer Live-Datenbank oder, falls diese nicht mehr vorhanden ist, aus dem Archiv Ihrer Website neu erstellt wird. Bei der Neugestaltung kommen keinerlei CMS-Plugins zum Einsatz. Und jede Funktion, die Sie wünschen, liegt als geprüfter, versionierter Code im eigenen Repository Ihrer Website. Auf Ihren Seiten bleibt kein Drittanbieter-Code zurück, der veralten, Konflikte verursachen oder eine Sicherheitslücke darstellen könnte.

Keine dieser Plattformen ist für Sie das Problem. Das Problem liegt meist im zugehörigen Code, und den können Sie auf Ihrer Website überprüfen. Bei Wix ist es anders, denn dort erstellen Sie Ihr Layout von Grund auf neu. Ihre Website muss auf den Servern von Wix gehostet sein. Kontakte und Produktinformationen können Sie exportieren, wobei der Produktexport von Wix Stores auf 5.000 Zeilen pro CSV-Datei begrenzt ist und keine digitalen Produkte unterstützt. Ist Ihre Website schon nicht mehr erreichbar, führen Sie zuerst die kostenlose Bestandsaufnahme durch (sie dauert zwei Minuten). Sie sehen dann, wie viele Seiten, Bilder und PDF-Dateien das Archiv Ihrer Website enthält. Und danach entscheiden Sie, wie es weitergeht.

Fragen und Antworten.

Weiterlesen.

1. 01SEO beim RelaunchVorher Ausgangswerte sichern, danach abgleichen.
2. 02Legacy-CMS-BeraterWas ein Berater bei einer alternden Plattform zuerst prüft.
3. 03Headless-CMS-SEO-AuditRendering, Canonicals, Vorschauen, strukturierte Daten aus dem Template.
4. 04Sicherheit bei der Vibe-Codierung: Welche Informationen geben bereits veröffentlichte KI-Websites preis, und wie lässt sich dies von außen erkennen?What Ships · Sicherheit