Ich habe die Anzahl der Male verloren, in denen ein Kunde zu uns kam mit einer Variation der gleichen Geschichte: "Unsere WordPress-Site wurde gehackt. Wir haben sie bereinigt. Sie wurde wieder gehackt. Damit sind wir fertig." Die letzte war ein mittelständisches E-Commerce-Unternehmen, dessen WooCommerce-Shop mit einem Kreditkartendieb injiziert wurde, der in einem legitim aussehenden Plugin-Update versteckt war. Sie hatten drei Wochen lang Kundenzahlungsdaten geleakt, bevor jemand es bemerkte. Das ist kein Sonderfall. Das ist ein normaler Dienstag im WordPress-Ökosystem.

Dieser Artikel ist nicht dazu da, WordPress zu kritisieren. Es betrieb aus gutem Grund einen großen Teil des Webs. Aber die Architektur, die es 2005 zugänglich machte, ist die gleiche Architektur, die es 2025 zu einem Magneten für automatisierte Angriffe macht. Wenn Sie gehackt wurden – oder wenn Sie es satt haben, Geld für Security-Plugins auszugeben, die selbst Angriffsvektoren sind – das ist Ihr Leitfaden für den Umstieg auf etwas grundlegend Sichereres.

Inhaltsverzeichnis

WordPress gehackt? Warum Migration zu Next.js + Supabase Ihre beste Lösung ist

Das WordPress-Sicherheitsproblem ist architektonisch

Lassen Sie mich etwas klarstellen: Das WordPress-Core-Team leistet solide Sicherheitsarbeit. WordPress Core, auf dem neuesten Stand gehalten, ist relativ sicher. Aber niemand führt nur WordPress Core aus. Die durchschnittliche WordPress-Site hat 20-30 installierte Plugins. Jedes ist eine Abhängigkeit, die Sie nicht geschrieben haben, die von jemandem gepflegt wird, den Sie nicht kennen, mit Zugriff auf Ihre Datenbank, Ihr Dateisystem und die Daten Ihrer Benutzer.

Hier ist das, was in Artikeln zu „WordPress-Sicherheitsrichtlinien" immer übersehen wird: Das Problem ist nicht, dass WordPress-Site-Besitzer nachlässig sind. Das Problem ist, dass die Architektur von WordPress von Ihnen verlangt, ausführbaren PHP-Code von Drittanbietern direkt auf Ihrem Server zu installieren, um grundlegende Funktionalität zu erhalten. Das ist gleichbedeutend damit, jeden Auftragnehmer, der an Ihrem Haus arbeitet, dauerhaft mit einer Kopie Ihres Hausschlüssels auszustatten.

Die Anfälligkeitsdatenbank von WPScan verzeichnete 2024 über 7.900 neue WordPress-Anfälligkeiten, wobei Plugins etwa 96 % davon ausmachten. Sucuris Bedrohungsbericht von 2024 stellte fest, dass WordPress etwa 95 % aller CMS-Infektionen ausmachte, die sie bereinigten. Und Patchstack berichtete, dass 33 % der kritischen WordPress-Anfälligkeiten 2024 zum Zeitpunkt der Offenlegung keinen verfügbaren Patch hatten.

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

Gängige WordPress-Angriffsvektoren 2025

Bevor wir über die Lösung sprechen, katalogisieren wir, gegen was Sie tatsächlich verteidigen. Ich habe persönlich Dutzende kompromittierter WordPress-Sites triagiert, und die Angriffe folgen vorhersehbaren Mustern.

SQL-Injection durch Plugins

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

Ich habe eine Injection einmal zu einem Contact-Form-Plugin zurückverfolgt, das seit 18 Monaten nicht mehr gepflegt wurde, aber auf über 200.000+ Websites noch installiert war. Der Angreifer verwendete eine UNION-basierte Injection, um die wp_users-Tabelle zu dumpen, Admin-Password-Hashes zu ergreifen und schwache offline zu knacken.

-- Was 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-Objektinjection und Remote-Code-Ausführung

Worppress' starke Nutzung von serialize() und unserialize() schafft Möglichkeiten für PHP-Objektinjection. Wenn ein Plugin Benutzerdaten unserialisiert (und viele tun das), kann ein Angreifer Payloads basteln, die während des Unserialisierungsprozesses beliebigen Code ausführen.

2024 erlaubte eine kritische RCE-Anfälligkeit in einem beliebten Backup-Plugin (installiert auf 5 Millionen+ Sites) unauthentifizierten Angreifern, beliebigen PHP-Code auszuführen. Die Behebung dauerte 11 Tage. Elf Tage, in denen jede Site mit diesem Plugin ein leichtes Ziel war.

Plugin-Supply-Chain-Angriffe

Das ist der, der mir am meisten Angst macht. Angreifer kaufen verlassene Plugins mit großen Installationsbasen, pushen eine „Sicherheitsaktualisierung" mit einem Hintertür-Backdoor drin, und die WordPress-Auto-Update-Mechanismen verteilen die Malware an jede Site, auf der dieses Plugin läuft. Es passierte 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 exponiert /wp-login.php und /xmlrpc.php standardmäßig. Automatisierte Botnets bombardieren diese Endpoints ständig. Wordfence berichtete von durchschnittlich 3 Milliarden böswilligen Anfragen pro Monat blockiert über ihr Netzwerk im Jahr 2024. Selbst mit Rate Limiting und Zwei-Faktor-Authentifizierung geben Sie Serverressourcen für die Verarbeitung dieser Angriffe aus.

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

Gespeichertes XSS in WordPress ist besonders gefährlich, da das Admin-Dashboard und die öffentliche Site den gleichen Sitzungskontext teilen. Ein XSS-Payload, der über einen Kommentar, eine Formularübermittlung oder eine anfällige Plugin-Einstellung injiziert wird, kann sich auf Vollzugriff auf Admin eskalieren.

Warum Headless-Architektur ganze Angriffskategorien eliminiert

Hier wird es interessant. Eine Headless-Architektur reduziert nicht nur Ihre 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 Ihr HTML rendert, auch:

  • Führt PHP-Code von 20+ Drittanbieter-Plugins aus
  • Verwaltet Benutzerauthentifizierung
  • Verbindet sich mit der Datenbank
  • Bedient die Admin-Schnittstelle
  • Handhabt Datei-Uploads
  • Verarbeitet Formularübermittlungen

Das ist eine Menge Verantwortung für eine einzelne Anwendung. In einem Headless-Setup mit Next.js und Supabase sind diese Verantwortungen auf isolierte Services verteilt:

  • Frontend (Next.js auf Vercel/Netlify): Statisches HTML/JS von einem CDN bedient. Keine Server-Laufzeit, die öffentlich im Internet exponiert ist, in den meisten Fällen.
  • Datenbank + Auth (Supabase): Verwaltetes Postgres mit Row Level Security, niemals direkt Endbenutzer exponiert.
  • API-Schicht: Serverlose Funktionen mit expliziten, minimalen Endpoints.
  • CMS (falls benötigt): Headless-CMS, das auf seiner eigenen isolierten Infrastruktur läuft.

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

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

WordPress gehackt? Warum Migration zu Next.js + Supabase Ihre beste Lösung ist - Architektur

Next.js + Supabase: Ein sicherheitsorientierter Stack

Lassen Sie uns spezifisch werden, warum diese besondere Kombination aus Sicherheitssicht so gut funktioniert.

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

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

Für dynamische Funktionalität laufen Next.js Server Actions und Route Handler als serverlose Funktionen. Jede Funktion ist:

  • Isoliert in ihrem eigenen Ausführungskontext
  • Zustandslos (kein gemeinsamer Speicher zwischen Anfragen)
  • Kurzlebig (Kaltstart, Ausführung, Beendigung)
  • Explizit definiert (keine Auto-Erkennung von Endpoints)
// 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 })
}

Vergleichen Sie das mit einem WordPress-Contact-Form-Plugin, das in das Action-System von WordPress hooken muss, seinen eigenen AJAX-Handler einzubinden hat, seine eigene Nonce-Verifizierung verwaltet und seine eigenen SQL-Abfragen erstellt. Die Next.js-Version hat weniger bewegliche Teile, validierte Eingabe über Zod und parametrisierte Abfragen über den Supabase-Client.

Supabase: Postgres mit Row Level Security

Supabase gibt Ihnen eine verwaltete PostgreSQL-Datenbank mit einem Killer-Sicherheitsfeature: Row Level Security (RLS). Anstatt darauf zu vertrauen, dass Ihr Anwendungscode die Zugriffskontrolle durchsetzt (das WordPress-Modell), definieren Sie Sicherheitsrichtlinien auf 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);

-- Die Öffentlichkeit kann in contact_submissions einfügen, 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 bereits viel schwieriger ist ohne einen PHP-Ausführungskontext), verhindern RLS-Richtlinien sie vor dem Zugriff auf Daten, die sie nicht sehen sollten. Das ist vertiefte Verteidigung, die WordPress grundlegend nicht bieten kann, weil sein Berechtigungssystem in PHP-Code implementiert ist, nicht auf Datenbankebene.

Supabase handhabt auch Authentifizierung mit integrierter Unterstützung für E-Mail/Passwort, Magic Links, OAuth-Provider und Multi-Faktor-Authentifizierung. Kein Plugin erforderlich. Kein Drittanbieter-Code, der auf Ihrem Server läuft.

Angriffsflächen-Vergleich: WordPress vs Headless

Lassen Sie uns das nebeneinander legen.

Angriffvektor WordPress Next.js + Supabase
SQL-Injection Hohes Risiko – Plugins erstellen rohe Abfragen Nahezu null – parametrisierte Abfragen über Supabase-Client, RLS als Backup
PHP/Remote-Code-Ausführung Hohes Risiko – Plugins führen serverseitiges PHP aus Nicht anwendbar – keine PHP-Laufzeit
Plugin Supply Chain Kritisches Risiko – Auto-Updates verteilen Malware Nicht anwendbar – kein Plugin-Ökosystem
Brute Force (Login) Immer exponiert (wp-login.php, xmlrpc.php) Admin-Zugriff über Supabase Auth oder separates Dashboard, kein öffentlicher Login-Endpoint erforderlich
XSS (Gespeichert) Hohes Risiko – gemeinsamer Admin/öffentlicher Kontext Niedriges Risiko – React escaped Output standardmäßig, Admin und öffentlich sind separate Apps
Datei-Upload-Ausnutzung Hohes Risiko – hochgeladene PHP-Dateien können ausgeführt werden Niedriges Risiko – Uploads gehen in Objektspeicher (Supabase Storage/S3), niemals als Code ausgeführt
Datenbank-Exposition Direkter MySQL-Zugriff, wenn Server kompromittiert ist Datenbank hinter Supabase-Infrastruktur, RLS-Richtlinien als letzte Schutzmauer
DDoS auf Origin Server muss jede Anfrage verarbeiten Statische Assets auf CDN, Origin wird selten getroffen
Bekannte Pfad-Enumeration wp-admin, wp-content, wp-includes alle scanbar Keine vorhersehbaren Pfade, keine exponierten Admin-Routes

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

Alles klar, Sie sind überzeugt (oder Ihre gehackte Site hat Sie überzeugt). So machen Sie das tatsächlich. Wir haben diese Migration bei Social Animal genug Male durchgeführt, um einen wiederholbaren Prozess zu haben.

Phase 1: Triage und Content-Audit (Woche 1)

Bevor Sie Code anfassen, müssen Sie verstehen, was Sie tatsächlich haben.

  1. Exportieren Sie alle WordPress-Inhalte mit WP-CLI oder der REST API. Verlassen Sie sich nicht auf XML-Exporte – sie verpassen Meta-Felder und benutzerdefinierte Post-Typen.
  2. Katalogisieren Sie alle Funktionalität von Plugins. Erstellen Sie eine Tabellenkalkulation: Plugin-Name, was es tut, ob Sie es tatsächlich brauchen, und was es ersetzt.
  3. Ordnen Sie URL-Strukturen für SEO-Schutz zu. Jede existierende URL benötigt eine Umleitung oder eine übereinstimmende Route in Next.js.
  4. Identifizieren Sie dynamische Features – Formulare, Suche, Benutzerkonten, E-Commerce – die API-Endpoints benötigen.
# WordPress-Inhalte über REST API exportieren
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)

Entwerfen Sie Ihr Supabase-Datenbankschema basierend auf dem Content-Audit. Replizieren Sie nicht einfach das WordPress-Schema – es ist voll mit Metadaten-Tabellen und serialisierten Datenblöcken.

-- Sauberes, zweckbestimmtes 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)
);

-- RLS sofort aktivieren
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);

Schreiben Sie ein Migrationsskript (Node.js oder Python), das WordPress-JSON-Exporte in Ihr neues Schema transformiert und sie in Supabase einfügt.

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

Bauen Sie Ihr Next.js-Frontend. Wenn Sie mit einem Team arbeiten, das den Stack kennt, geht das schnell. Wenn Sie Hilfe brauchen, hat unser Next.js-Entwicklungsteam diese Migration genug Male durchgeführt, um starke Meinungen über die richtigen Muster zu haben.

Wichtige architektonische Entscheidungen:

  • Statische Generierung für Content-Seiten – Blog-Beiträge, Landing Pages, About-Seiten. Diese werden HTML-Dateien auf einem CDN.
  • Server-Komponenten für dynamische Daten – Abruf von Supabase zur Anforderungszeit mit Caching.
  • Route Handler für Formularübermittlungen – Contact Forms, Newsletter-Anmeldungen, etc.
  • Middleware für Umleitungen – Handhabt alle Ihre alten WordPress-URLs.
// next.config.ts -- handle WordPress URL redirects
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 -- send bots to a 410
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

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

  • Führen Sie Screaming Frog gegen die neue Site, um zu überprüfen, dass jede alte URL entweder aufgelöst wird oder umgeleitet wird.
  • Validieren Sie strukturierte Daten (JSON-LD) auf allen Seiten vorhanden.
  • Testen Sie alle Formulare und dynamische Features.
  • Führen Sie Lighthouse- und Core Web Vitals-Checks aus – Sie werden fast sicher Verbesserungen sehen, da Sie jetzt von einem CDN servieren.
  • Richten Sie Monitoring mit Vercel Analytics oder Ihrem bevorzugten Tool ein.

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

Stellen Sie auf Vercel oder Netlify bereit, aktualisieren Sie DNS, und richten Sie Monitoring ein. Halten Sie die alte WordPress-Instanz offline, aber 30 Tage lang zugänglich, falls Sie auf etwas verweisen müssen.

Wenn Ihre Site erheblichen Traffic oder E-Commerce-Funktionalität hat, erwägen Sie eine Headless-CMS-Integration zur Content-Verwaltung und sprechen Sie mit uns über Astro als alternativen Frontend für inhaltsreiche Sites, bei denen Build-Performance wichtig ist.

Sicherheitshärtung nach der Migration

Sobald Sie auf dem neuen Stack sind, hier ist Ihre Sicherheitscheckliste:

  1. Aktivieren Sie Supabase RLS auf jeder Tabelle. Keine Ausnahmen. Wenn eine Tabelle keine Richtlinien hat, ist sie entweder unzugänglich (gute Voreinstellung) oder weit offen (schlecht).
  2. Verwenden Sie Umgebungsvariablen für alle Geheimnisse. Vercel und Netlify handhaben das gut. Committen Sie niemals API-Schlüssel.
  3. Richten Sie Supabase-Datenbank-Backups ein. Point-in-Time-Wiederherstellung ist auf Pro-Plänen ($25/Monat) verfügbar.
  4. Konfigurieren Sie Content Security Policy-Header in Ihrer Next.js-Middleware.
  5. Aktivieren Sie Vercel's DDoS-Schutz (auf allen Plänen enthalten).
  6. Richten Sie Uptime-Monitoring ein – wir verwenden Better Uptime, aber Checkly und Vercel's integriertes Monitoring funktionieren auch.
  7. Auditieren Sie Ihre Supabase-RLS-Richtlinien vierteljährlich. Verwenden Sie Supabase's SQL-Editor, um Richtlinien mit verschiedenen Benutzer-Kontexten zu testen.
// middleware.ts -- security headers
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 der WordPress-Sicherheit vs Migration

Lassen Sie uns über Geld sprechen, denn das ist, was tatsächlich Entscheidungen antreibt.

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 Incident N/A
Entwicklerzeit für Sicherheitspatches $2.000-5.000 $500-1.000
Datenbank (Supabase) Enthalten in Hosting $0-300 (Free-Plan bis Pro)
Gesamt $3.000-9.400 $500-1.540

Und das ist, bevor Sie die Kosten für Ausfallzeiten, verlorenes Kundenvertrauen und potenzielle regulatorische Strafen einkalkulieren, falls Kundendaten kompromittiert werden. Ein einzelner DSGVO-meldepflichtiger Verstoß kann zehntausende in Rechts- und Compliance-Overhead kosten.

Die Migration selbst kostet typischerweise $10.000-40.000, je nach Website-Komplexität. Für die meisten Unternehmen bezahlt sich das in 1-2 Jahren durch reduzierte Sicherheitsausgaben allein – und Sie bekommen eine schnellere, wartbarere Site dabei. Schauen Sie sich unsere Preisseite für spezifische Migrations-Projektpreise an.

FAQ

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

WordPress Core wird gut gepflegt. Das Problem ist, dass praktisch niemand nur Core betreibt. Das Plugin-Ökosystem ist, wo 96 % der Anfälligkeiten leben, und Sie können keine nützliche WordPress-Site ohne Plugins betreiben. Es ist nicht übertrieben – Sucuri bereinigte Malware von über 60.000 WordPress-Sites allein 2024. Die Architektur verlangt von Ihnen, Drittanbieter-PHP-Code auf Ihrem Server zu vertrauen, und dieses Vertrauen wird ständig ausgenutzt.

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

Security-Plugins sind selbst PHP-Code, der auf Ihrem Server mit tiefem Systemzugriff läuft. Wordfence und Sucuri sind gut gepflegt, aber sie sind Pflaster auf ein architektonisches Problem. Sie fügen auch Serverlast hinzu, können mit anderen Plugins in Konflikt geraten, und haben über die Jahre ihre eigenen Anfälligkeiten gehabt. Sie addieren 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, Contact Forms) vervollständigen wir Migrationen typischerweise in 5-7 Wochen. E-Commerce-Sites mit WooCommerce sind komplexer und können 8-14 Wochen dauern, abhängig von der Produktkatalog-Größe und benutzerdefinierter Funktionalität. Wenn Sie eine einfachere Site haben, kontaktieren Sie uns und wir können Ihnen einen spezifischeren Zeitrahmen geben.

Verliere ich meine SEO-Rankings beim Migrieren von WordPress?

Nein, wenn Sie es richtig machen. Die kritischen Schritte sind: Alle URL-Strukturen bewahren oder richtige 301-Umleitungen einrichten, Ihr strukturiertes Datenmarkup beibehalten, Ihre Inhalte intakt halten, und aktualisierte Sitemaps in Google Search Console einreichen. Die meisten unserer Migrations-Kunden sehen Ranking-Verbesserungen innerhalb von 2-3 Monaten, weil Core Web Vitals-Werte sich dramatisch verbessern, wenn Sie zu einer CDN-basierten statischen Site wechseln.

Was ist mit Content-Editieren? WordPress ist einfach für nicht-technische Benutzer.

Das ist ein berechtigtes Anliegen. Sie haben Optionen: Supabase mit einem benutzerdefinierten Admin-Dashboard, oder ein Headless-CMS wie Sanity, Contentful oder Payload CMS, das Content-Editoren ein visuelles Editing-Erlebnis ähnlich WordPress gibt. Wir handhaben Headless-CMS-Integrationen regelmäßig und können die richtige Lösung für die Anforderungen Ihres Teams empfehlen.

Ist Supabase sicher genug für Produktionsgebrauch?

Supabase läuft auf AWS-Infrastruktur mit SOC 2 Type II Compliance. Die zugrunde liegende Datenbank ist PostgreSQL, das einen starken Sicherheitsverlauf hat. Row Level Security Policies erzwingen Zugriffskontrolle auf Datenbankebene, was eigentlich sicherer ist als das PHP-basierte Berechtigungssystem von WordPress. Supabase bietet auch Point-in-Time-Wiederherstellung, verschlüsselte Verbindungen und Netzwerkeinschränkungen auf bezahlten Plänen.

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

Schalten Sie die Site sofort offline, um weiteren Schaden und Datalecks zu stoppen. Zweite, bewahren Sie forensische Beweise (Datenbankdumps, Zugangslogs, Dateisystem-Snapshots). Dritte, bereinigie sie nicht einfach und stellen Sie sie wieder rein – Sie werden wahrscheinlich in Wochen reinfiziert. Nutzen Sie das Incident als Katalysator zum Migrieren. Kontaktieren Sie unser Team und wir können bei sofortiger Triage und Migrationsplanung helfen.

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

Schrittweise Migration ist möglich, fügt aber Komplexität hinzu. Sie können Next.js als Frontend ausführen, während Sie WordPress temporär als Headless-CMS-Backend behalten, dann WordPress vollständig auslaufen lassen. Aber das bedeutet, WordPress läuft noch und braucht weiterhin Sicherheitswartung während des Übergangs. Für die meisten Sites ist ein sauberer Cutover schneller, billiger und eliminiert Sicherheitsrisiko schneller.