Dein Klient ruft an: Sein WooCommerce-Store wurde erneut gehackt. Du hast ihn letzten Monat bereinigt – Backdoor entfernt, dreiundzwanzig Plugins gepatcht, Anmeldedaten rotiert. Aber heute Morgen hat sein Zahlungsabwickler verdächtige Kartentransaktionen gekennzeichnet. Du verbindest dich via SSH und findest es: Ein Kreditkarten-Skimmer versteckt in einem legitim aussehenden Analytics-Plugin, das sich Dienstagabend automatisch aktualisiert hat. Die gleiche Geschichte, ein anderes Plugin. Die Angriffsfläche ist kein Bug im WordPress-Kern – es sind die siebenunddreißig Drittanbieter-Plugins, auf die ihre Site angewiesen ist. Jeder ist eine Tür. Die meisten werden langsam gepatcht. Manche werden nie gepatcht. Eine Migration zu Next.js + Supabase räumt nicht nur die Infektion auf – sie entfernt die gesamte Plugin-Schicht, aus der 90 % aller WordPress-Brachen stammen.

Dieser Artikel handelt nicht davon, WordPress zu kritisieren. Es betrieb eine große Portion des Webs aus gutem Grund. Aber die Architektur, die es 2005 zugänglich machte, ist die gleiche Architektur, die es 2026 zu einem Magneten für automatisierte Angriffe macht. Wenn du gehackt wurdest – oder du es leid bist, Geld für Security-Plugins auszugeben, die selbst Angriffsvektoren sind – das ist dein Spielplan zum Umstieg auf etwas grundlegend Sichereres.

Inhaltsverzeichnis

WordPress Hacked? Why Migration to Next.js + Supabase Is Your Best Fix

Das WordPress-Sicherheitsproblem ist architektonisch

Lass mich etwas klarstellen: Das WordPress-Kern-Team leistet solide Sicherheitsarbeit. WordPress-Kern, aktuell gehalten, ist relativ sicher. Aber niemand betreibt nur WordPress-Kern. Die durchschnittliche WordPress-Site hat 20-30 Plugins installiert. Jeder ist eine Abhängigkeit, die du nicht geschrieben hast, gepflegt von jemandem, den du nicht kennst, mit Zugriff auf deine Datenbank, dein Dateisystem und die Daten deiner Benutzer.

Hier ist das, was in "WordPress-Sicherheitsbestpraxen"-Artikeln immer übersehen wird: Das Problem ist nicht, dass WordPress-Site-Besitzer fahrlässig sind. Das Problem ist, dass die WordPress-Architektur erfordert, dass du PHP-Code von Drittanbietern direkt auf deinem Server installierst, um grundlegende Funktionalität zu erreichen. Das ist gleichbedeutend damit, jedem Auftragnehmer, der an deinem Haus arbeitet, einen Schlüssel zu deinem Haus zu geben – dauerhaft.

WPScans Sicherheitsdatenbank verfolgten über 7.900 neue WordPress-Sicherheitslücken im Jahr 2024, wobei Plugins etwa 96 % davon ausmachten. Suculis Bedrohungsbericht von 2024 stellte fest, dass WordPress etwa 95 % aller CMS-Infektionen ausmachte, die sie bereinigten. Und Patchstack berichtete, dass 33 % der kritischen WordPress-Sicherheitslücken 2024 zum Zeitpunkt der Offenlegung keinen verfügbaren Patch hatten.

Dies sind keine Fehler, die durch bessere Coding-Praktiken behoben werden können. Sie sind emergente Eigenschaften der Architektur selbst.

Häufige WordPress-Angriffsvektoren 2026

Bevor wir über die Lösung sprechen, katalogisieren wir, wogegen du tatsächlich verteidigst. Ich habe persönlich Dutzende von gehackten WordPress-Sites triagiert, und die Angriffe fallen in vorhersehbare Muster.

SQL-Injection über Plugins

WordPress verwendet eine MySQL-Datenbank mit einem gut dokumentierten Schema. Jedes Plugin, das Benutzereingaben akzeptiert und die Datenbank berührt, ist eine potenzielle SQL-Injection-Stelle. Die Funktion $wpdb->prepare() existiert, aber sie ist optional. Plugin-Entwickler vergessen sie, missbrauchen sie oder überspringen sie ganz für "einfache" Abfragen.

Ich habe einmal eine Injection auf ein Contact-Form-Plugin zurückgeführt, das seit 18 Monaten aufgegeben worden war, aber auf über 200.000 Sites installiert war. Der Angreifer verwendete eine UNION-basierte Injection, um die Tabelle wp_users zu dumpen, Admin-Passwort-Hashes zu greifen und die schwachen offline zu knacken.

-- Wie eine typische WordPress SQL-Injection in Logs aussieht
GET /wp-content/plugins/vulnerable-plugin/ajax.php?id=1%20UNION%20SELECT%201,user_login,user_pass,4,5%20FROM%20wp_users--

PHP-Objekt-Injection und Remote-Code-Ausführung

WordPress' intensive Nutzung von serialize() und unserialize() schafft Gelegenheiten für PHP-Objekt-Injektionen. Wenn ein Plugin benutzergesteuerte Daten entserialisiert (und viele tun das), kann ein Angreifer Payloads erstellen, die während des Entserialisierungsprozesses beliebigen Code ausführen.

Im Jahr 2024 war eine kritische RCE-Sicherheitslücke in einem beliebten Backup-Plugin (auf 5 Millionen+ Sites installiert) erlaubt unauthentifizierten Angreifern, beliebigen PHP-Code auszuführen. Der Fix dauerte 11 Tage zum Versand. Elf Tage, in denen jede Site mit diesem Plugin ein leichtes Ziel war.

Plugin-Supply-Chain-Angriffe

Dies ist derjenige, der mich am meisten verängstigt. Angreifer kaufen aufgegebene Plugins mit großen Installationsbasen, pushen ein "Sicherheitsupdate", das eine Backdoor enthält, und WordPress-Auto-Update-Mechanismen verteilen die Malware an jede Site, die dieses Plugin ausführt. Dies geschah mit Display Widgets (300.000 Installationen) und Social Warfare (70.000 Installationen), und das sind nur die, die erwischt wurden.

Brute-Force-Angriffe auf wp-login.php

Jede WordPress-Site stellt /wp-login.php und /xmlrpc.php standardmäßig zur Verfügung. Automatisierte Botnets treffen diese Endpunkte ständig. Wordfence berichtete, dass sie im Jahr 2024 durchschnittlich 3 Milliarden böswillige Anfragen pro Monat in ihrem Netzwerk blockierten. Selbst mit Rate-Limiting und Zwei-Faktor-Auth verschwendest du Serverressourcen bei der Verarbeitung dieser Angriffe.

Cross-Site-Scripting (XSS) über Themes und Plugins

Gespeichertes XSS in WordPress ist besonders gefährlich, da das Admin-Dashboard und die öffentlich zugängliche Site denselben Session-Kontext teilen. Eine XSS-Payload, die über einen Kommentar, eine Formularübermittlung oder eine verwundbare Plugin-Einstellung injiziert wird, kann zu vollständigem Admin-Zugriff eskalieren.

Warum Headless-Architektur ganze Angriffskategorien eliminiert

Hier wird es interessant. Eine Headless-Architektur reduziert nicht nur deine Angriffsfläche – sie eliminiert ganze Angriffskategorien, indem sie die Bedingungen entfernt, die sie möglich machen.

In einem traditionellen WordPress-Setup macht der gleiche Server, der dein HTML rendert, auch:

  • Führt PHP-Code aus 20+ Drittanbieter-Plugins aus
  • Verwaltet Benutzer-Authentifizierung
  • Verbindet sich mit der Datenbank
  • Serviert das Admin-Interface
  • Verarbeitet Datei-Uploads
  • Verarbeitet Formularübermittlungen

Das ist viel Verantwortung für eine einzelne Anwendung. In einem Headless-Setup mit Next.js und Supabase werden diese Verantwortungen über isolierte Dienste verteilt:

  • Frontend (Next.js auf Vercel/Netlify): Statisches HTML/JS serviert von einem CDN. Kein Server-seitiger Runtime, der dem öffentlichen Internet ausgesetzt ist, in den meisten Fällen.
  • Datenbank + Auth (Supabase): Verwaltetes Postgres mit Row Level Security, niemals direkt für Endbenutzer freigegeben.
  • API-Schicht: Serverlose Funktionen mit expliziten, minimalen Endpunkten.
  • CMS (falls benötigt): Headless-CMS läuft auf eigener isolierter Infrastruktur.

Es gibt kein PHP zum Injizieren. Es gibt kein Plugin-Verzeichnis mit Schreibzugriff. Es gibt keine gemeinsame Session zwischen Admin und öffentlicher Site. Es gibt kein wp-login.php für Bots zum Bombardieren.

Du brauchst keine WAF, um eine Angriffsfläche zu schützen, die nicht existiert.

WordPress Hacked? Why Migration to Next.js + Supabase Is Your Best Fix - architecture

Next.js + Supabase: Ein sicherheitsorientierter Stack

Lass uns spezifisch werden, warum diese bestimmte Kombination aus Sicherheitssicht so gut funktioniert.

Next.js: Das Frontend, das keinen Code ausführt

Wenn du eine Next.js-Site mit statischer Generierung (SSG) oder inkrementeller statischer Regeneration (ISR) erstellst, werden HTML-, CSS- und JavaScript-Dateien auf einem CDN bereitgestellt. Es gibt keinen Application-Server, der Anfragen in Echtzeit verarbeitet. Du kannst ein CDN nicht SQL-injizieren.

Für dynamische Funktionalität werden Next.js Server Actions und Route Handlers als serverlose Funktionen ausgeführt. Jede Funktion ist:

  • Isoliert in seinem eigenen Ausführungskontext
  • Zustandslos (kein gemeinsamer Speicher zwischen Anfragen)
  • Kurzlebig (Cold Start, Execute, Beenden)
  • Explizit definiert (keine Auto-Discovery von Endpunkten)
// Next.js Route Handler -- explizit, typisiert, minimal
import { createClient } from '@/lib/supabase/server'
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

const ContactSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
})

export async function POST(request: NextRequest) {
  const body = await request.json()
  const parsed = ContactSchema.safeParse(body)
  
  if (!parsed.success) {
    return NextResponse.json({ error: 'Invalid input' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: 'Submission failed' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

Vergleiche das mit einem WordPress-Contact-Form-Plugin, das sich in das Action-System von WordPress einbinden muss, seinen eigenen AJAX-Handler einbinden, seine eigene Nonce-Verifizierung verwalten und seine eigenen SQL-Queries bauen muss. Die Next.js-Version hat weniger bewegliche Teile, validierte Eingabe über Zod und parametrisierte Queries über den Supabase-Client.

Supabase: Postgres mit Row Level Security

Supabase gibt dir eine verwaltete PostgreSQL-Datenbank mit einem Killer-Sicherheitsmerkmal: Row Level Security (RLS). Anstatt deinem Anwendungscode zu vertrauen, dass er die Zugriffskontrolle durchsetzt (das WordPress-Modell), definierst du Sicherheitsrichtlinien auf der Datenbankebene.

-- Nur authentifizierte Benutzer können ihre eigenen Daten lesen
CREATE POLICY "Users can view own profile"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Öffentlichkeit kann das Kontaktformular einreichen, aber nicht lesen
CREATE POLICY "Anyone can submit contact form"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "Only admins can read submissions"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

Selbst wenn ein Angreifer einen Weg findet, beliebige Supabase-Abfragen zu machen (was ohnehin viel schwieriger ist ohne PHP-Ausführungskontext), verhindern RLS-Richtlinien, dass er auf Daten zugreift, die er nicht sehen sollte. Das ist Defense in Depth, das WordPress grundlegend nicht bieten kann, da sein Berechtigungssystem in PHP-Code implementiert ist, nicht auf der Datenbankebene.

Supabase verarbeitet auch die Authentifizierung mit integrierter Unterstützung für E-Mail/Passwort, Magic Links, OAuth-Provider und Multi-Faktor-Auth. Kein Plugin erforderlich. Kein Drittanbieter-Code auf deinem Server.

Angriffsfläche-Vergleich: WordPress vs Headless

Lass uns das nebeneinander stellen.

Angriffsvektor WordPress Next.js + Supabase
SQL-Injection Hohes Risiko – Plugins bauen Raw-Queries Nahe Null – Parametrisierte Queries über Supabase-Client, RLS als Backup
PHP/Remote Code Execution Hohes Risiko – Plugins führen Server-seitiges PHP aus Nicht zutreffend – Keine PHP-Runtime
Plugin Supply Chain Kritisches Risiko – Auto-Updates verteilen Malware Nicht zutreffend – Kein Plugin-Ökosystem
Brute Force (Login) Immer exponiert (wp-login.php, xmlrpc.php) Admin-Zugriff über Supabase Auth oder separates Dashboard, keine öffentliche Login-Seite erforderlich
XSS (Gespeichert) Hohes Risiko – Gemeinsamer Admin/Public-Kontext Hohes Risiko – React escaped Output standardmäßig, Admin und Public sind separate Apps
Datei-Upload-Exploitation Hohes Risiko – Hochgeladene PHP-Dateien können ausgeführt werden Hohes Risiko – Uploads gehen zum Object Storage (Supabase Storage/S3), niemals als Code ausgeführt
Datenbankexposition Direkter MySQL-Zugriff, wenn Server kompromittiert wird Datenbank hinter Supabase-Infrastruktur, RLS-Richtlinien als letzte Verteidigungslinie
DDoS auf Origin Server muss jede Anfrage verarbeiten Statische Assets auf CDN, Origin wird selten getroffen
Bekannte Pfad-Aufzählung wp-admin, wp-content, wp-includes alle scanbar Keine vorhersehbaren Pfade, keine exponierten Admin-Routen

Der Migrations-Spielplan: WordPress zu Next.js + Supabase

Also, du bist überzeugt (oder deine gehackte Site hat dich überzeugt). Hier ist, wie man das tatsächlich macht. Wir haben diese Migration bei Social Animal genug oft durchgeführt, um einen wiederholbaren Prozess zu haben.

Phase 1: Triage und Inhaltsaudit (Woche 1)

Bevor du Code anfasst, musst du verstehen, was du tatsächlich hast.

  1. Exportiere alle WordPress-Inhalte über WP-CLI oder die REST API. Verlasse dich nicht auf XML-Exporte – sie verpassen Meta-Felder und benutzerdefinierte Post-Typen.
  2. Katalogisiere alle Funktionalität von Plugins. Erstelle eine Tabelle: Plugin-Name, was es tut, ob du es wirklich brauchst und was es ersetzt.
  3. Map URL-Strukturen für SEO-Erhaltung. Jede vorhandene URL braucht eine Umleitung oder eine entsprechende Route in Next.js.
  4. Identifiziere dynamische Funktionen – Formulare, Suche, Benutzerkonten, E-Commerce – die API-Endpunkte benötigen.
# Exportiere WordPress-Inhalte über REST API
curl -s "https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1" | jq '.' > posts_page1.json
curl -s "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" | jq '.' > pages.json
curl -s "https://yoursite.com/wp-json/wp/v2/media?per_page=100" | jq '.' > media.json

Phase 2: Supabase-Schema und Datenmigration (Woche 2)

Designe dein Supabase-Datenbankschema basierend auf dem Inhaltsaudit. Repliziere nicht einfach das WordPress-Schema – es ist aufgebläht mit Metadaten-Tabellen und serialisierten Daten-Blobs.

-- Sauberes, zweckgerichtetes Schema
CREATE TABLE posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  excerpt TEXT,
  featured_image TEXT,
  status TEXT DEFAULT 'draft' CHECK (status IN ('draft', 'published', 'archived')),
  published_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  author_id UUID REFERENCES auth.users(id)
);

-- Aktiviere RLS sofort
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Published posts are public"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "Authors can manage own posts"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

Schreibe ein Migrations-Script (Node.js oder Python), das WordPress-JSON-Exporte in dein neues Schema transformiert und in Supabase einfügt.

Phase 3: Next.js Build (Wochen 3-5)

Erbaue dein Next.js Frontend. Wenn du mit einem Team arbeitest, das den Stack kennt, geht dies schnell. Falls du Hilfe brauchst, hat unser Next.js-Entwicklungsteam diese Migration oft genug durchgeführt, um starke Meinungen zu den richtigen Mustern zu haben.

Wichtige architektonische Entscheidungen:

  • Statische Generierung für Inhaltsseiten – Blog-Posts, Landingpages, About-Pages. Diese werden zu HTML-Dateien auf einem CDN.
  • Server-Komponenten für dynamische Daten – Fetch von Supabase zur Anfrage-Zeit mit Caching.
  • Route Handler für Formularübermittlungen – Kontaktformulare, Newsletter-Anmeldungen usw.
  • Middleware für Umleitungen – Verarbeite alle deine alten WordPress-URLs.
// next.config.ts -- WordPress-URL-Umleitungen verarbeiten
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // wp-login.php -- Sende Bots zu 410
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

Phase 4: Testing und SEO-Validierung (Woche 6)

  • Führe Screaming Frog gegen die neue Site aus, um zu überprüfen, dass jede alte URL entweder aufgelöst wird oder umgeleitet wird.
  • Validiere, dass strukturierte Daten (JSON-LD) auf allen Seiten vorhanden sind.
  • Teste alle Formulare und dynamische Funktionen.
  • Führe Lighthouse und Core Web Vitals Checks aus – du wirst fast sicher Verbesserungen sehen, da du jetzt von einem CDN servierst.
  • Richte Überwachung mit Vercel Analytics oder deinem bevorzugten Tool ein.

Phase 5: Launch und DNS-Cutover (Wochen 6-7)

Stelle zu Vercel oder Netlify bereit, aktualisiere DNS und richte Überwachung ein. Halte die alte WordPress-Instanz 30 Tage offline aber zugänglich, falls du etwas nachschlagen musst.

Wenn deine Site erhebliche Netzwerk- oder E-Commerce-Funktionalität hat, erwäge eine Headless-CMS-Integration für die Inhaltsverwaltung und sprich mit uns über Astro als alternatives Frontend für inhaltsorientierte Sites, wo Build-Performance wichtig ist.

Sicherheitshärtung nach der Migration

Sobald du im neuen Stack bist, hier ist deine Sicherheits-Checkliste:

  1. Aktiviere Supabase RLS auf jeder Tabelle. Keine Ausnahmen. Wenn eine Tabelle keine Richtlinien hat, ist sie entweder nicht zugänglich (gut, Standard) oder weit offen (schlecht).
  2. Verwende Umgebungsvariablen für alle Geheimnisse. Vercel und Netlify behandeln dies gut. Committe niemals API-Keys.
  3. Richte Supabase-Datenbankbackups ein. Point-in-Time Recovery ist auf Pro-Plänen ($25/Monat) verfügbar.
  4. Konfiguriere Content Security Policy-Header in deiner Next.js-Middleware.
  5. Aktiviere Vercel's DDoS-Schutz (auf allen Plänen enthalten).
  6. Richte Uptime-Überwachung ein – wir verwenden Better Uptime, aber Checkly und Vercel's integrierte Überwachung funktionieren auch.
  7. Überprüfe deine Supabase RLS-Richtlinien vierteljährlich. Verwende Supabase's SQL-Editor, um Richtlinien mit verschiedenen Benutzerkontexten zu testen.
// middleware.ts -- Sicherheits-Header
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()
  
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  )
  response.headers.set(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=()'
  )
  
  return response
}

Echte Kosten von WordPress-Sicherheit vs Migration

Lass uns über Geld sprechen, da das tatsächlich Entscheidungen treibt.

Kostenkategorie WordPress (Jährlich) Next.js + Supabase (Jährlich)
Hosting $300-1.200 (verwaltetes WP) $0-240 (Vercel Pro)
Security-Plugins (Wordfence/Sucuri) $200-500 $0 (nicht erforderlich)
SSL/CDN $0-200 $0 (enthalten)
Malware-Bereinigung (falls gehackt) $500-2.500 pro Vorfall N/A
Entwickler-Zeit auf Sicherheits-Patches $2.000-5.000 $500-1.000
Datenbank (Supabase) Im Hosting enthalten $0-300 (kostenlos bis Pro)
Gesamt $3.000-9.400 $500-1.540

Und das ist noch vor der Berücksichtigung der Kosten von Ausfallzeiten, verlorenem Kundenvertrauen und möglichen regulatorischen Strafen, wenn Kundendaten kompromittiert werden. Ein einzelner GDPR-zu-meldender Verstoß kann Zehntausende in rechtlicher und Compliance-Überwachung kosten.

Die Migration selbst kostet typischerweise zwischen $10.000-40.000, abhängig von der Site-Komplexität. Für die meisten Unternehmen bezahlt sich das innerhalb von 1-2 Jahren allein bei reduzierten Sicherheitsausgaben – und du bekommst eine schnellere, wartbarere Site obendrein. Schau dir unsere Preisseite für spezifische Details zu Migrationsprojekten an.

FAQ

Ist WordPress wirklich so unsicher, oder ist das übertrieben?

WordPress-Kern wird gut gepflegt. Das Problem ist, dass praktisch niemand nur den Kern betreibt. Das Plugin-Ökosystem ist, wo 96 % der Sicherheitslücken existieren, und du kannst keine nützliche WordPress-Site ohne Plugins betreiben. Das ist nicht übertrieben – Sucuri reinigte 2024 Malware von über 60.000 WordPress-Sites. Die Architektur erfordert, dass du Drittanbieter-PHP-Code auf deinem Server vertraust, und dieses Vertrauen wird ständig ausgenutzt.

Kann ich nicht einfach bessere Security-Plugins verwenden, anstatt zu migrieren?

Security-Plugins sind selbst PHP-Code, der auf deinem Server mit tiefem Systemzugriff läuft. Wordfence und Sucuri sind gut gepflegt, aber sie sind Pflaster auf einem architektonischen Problem. Sie fügen auch Server-Last hinzu, können mit anderen Plugins in Konflikt geraten und hatten im Laufe der Jahre ihre eigenen Sicherheitslücken. Du addierst Komplexität, um ein Komplexitätsproblem zu lösen.

Wie lange dauert eine WordPress zu Next.js Migration typischerweise?

Für eine Standard-Business-Site (10-50 Seiten, Blog, Kontaktformulare) vollziehen wir Migrationen typischerweise in 5-7 Wochen. E-Commerce-Sites mit WooCommerce sind komplexer und können 8-14 Wochen dauern, abhängig von Produktkatalog-Größe und benutzerdefinierter Funktionalität. Wenn du eine einfachere Site hast, kontaktiere uns und wir können dir eine spezifischere Timeline geben.

Verliere ich meine SEO-Rankings beim Migrieren von WordPress?

Nicht, wenn du es richtig machst. Die kritischen Schritte sind: Behalte alle URL-Strukturen bei oder richte richtige 301-Umleitungen ein, behalte dein strukturiertes Daten-Markup, behalte deinen Inhalt intakt und sende aktualisierte Sitemaps an Google Search Console. Die meisten unserer Migrations-Kunden sehen Ranking-Verbesserungen innerhalb von 2-3 Monaten, weil Core Web Vitals-Scores dramatisch verbessert werden, wenn du zu einer CDN-bedienten statischen Site umziehtst.

Wie ist es mit Content-Bearbeitung? WordPress ist einfach für nicht-technische Benutzer.

Das ist eine legitime Sorge. Du hast Optionen: Supabase mit einem benutzerdefinierten Admin-Dashboard oder ein Headless-CMS wie Sanity, Contentful oder Payload CMS, das Content-Editoren ein visuelles Bearbeitungserlebnis ähnlich wie WordPress bietet. Wir verarbeiten Headless-CMS-Integrationen regelmäßig und können die richtige Anpassung für dein Team-Anforderungen empfehlen.

Ist Supabase sicher genug für die Produktionsnutzung?

Supabase läuft auf AWS-Infrastruktur mit SOC 2 Type II-Konformität. Die zugrunde liegende Datenbank ist PostgreSQL, die eine starke Sicherheitserfolgsbilanz hat. Row Level Security-Richtlinien erzwingen Zugriffskontrolle auf der Datenbankebene, was tatsächlich sicherer ist als Wordpress's PHP-basiertes Berechtigungssystem. Supabase bietet auch Point-in-Time Recovery, verschlüsselte Verbindungen und Netzwerk-Beschränkungen auf bezahlten Plänen.

Was ist, wenn meine WordPress-Site gehackt wurde und ich sofortige Hilfe brauche?

Erstens, nehme die Site sofort offline, um weiteren Schaden und Datenlecks zu verhindern. Zweitens, konserviere forensische Beweise (Datenbank-Dumps, Access-Logs, Dateisystem-Snapshots). Drittens, räume es nicht einfach auf und stelle es wieder online – du wirst wahrscheinlich innerhalb von Wochen wieder infiziert. Nutze den Vorfall als Katalysator zum Migrieren. Kontaktiere unser Team und wir können bei sofortiger Triage und Migrations-Planung helfen.

Muss ich alles auf einmal migrieren, oder kann ich es schrittweise tun?

Inkrementelle Migration ist möglich, aber fügt Komplexität hinzu. Du kannst Next.js als Frontend betreiben, während du WordPress temporär als Headless-CMS-Backend hältst, dann WordPress vollständig abschaffen. Aber das bedeutet, dass WordPress immer noch läuft und immer noch Sicherheitswartung während des Übergangs braucht. Für die meisten Sites ist ein sauberes Cutover schneller, billiger und eliminiert Sicherheitsrisiko früher.