Ich habe die Anleitung verloren, wie oft ich das gehört habe: "WordPress war am Anfang in Ordnung, aber jetzt..." Und dann kommt die Liste. Die Website braucht 6 Sekunden zum Laden. Das Kontaktformular-Plugin ist nach dem letzten Update kaputt gegangen. Es gibt eine kritische Sicherheitslücke in einem Plugin, das seit 2022 nicht mehr gepflegt wird. Der Entwickler, der das ursprüngliche Theme gebaut hat, ist abgehauen. Kommt dir das bekannt vor?

Hier ist das Problem -- WordPress betreibt über 40% des Internets, und das aus gutem Grund. Es ist zugänglich, es hat ein riesiges Ökosystem, und es hat viele Unternehmen schnell online gebracht. Aber es gibt einen Unterschied zwischen einem Tool, das dir den Anfang ermöglicht, und einem Tool, das mit dir wächst. Wenn du das hier liest, bist du wahrscheinlich auf diese Mauer gestoßen. Lasse mich dich durchführen, wie eine echte Migration von WordPress zu einer Headless-Next.js-+-Supabase-Architektur aussieht -- nicht die Marketing-Version, sondern das echte Engineering-Playbook.

Inhaltsverzeichnis

Entwachsen WordPress? Ein Migrations-Playbook für Next.js + Supabase

Anzeichen, dass du WordPress wirklich entwachsen bist

Nicht jeder muss WordPress verlassen. Ich möchte da upfront sein. Wenn du einen persönlichen Blog oder eine Broschüren-Website für ein lokales Unternehmen betreibst, ist WordPress mit einem anständigen Theme und einer Handvoll Plugins wahrscheinlich immer noch der richtige Weg. Aber es gibt klare Signale, dass du es entwachsen bist:

Plugin-Konflikte brechen jeden Monat Dinge

Du aktualisierst WooCommerce, und dein Page Builder funktioniert nicht mehr. Du aktualisierst deinen Page Builder, und dein SEO-Plugin wirft Warnungen. Du aktualisierst PHP auf 8.2, weil dein Host es verlangt, und drei Plugins funktionieren überhaupt nicht mehr. Das ist kein Bug -- das ist die Architektur. WordPress-Plugins teilen alle denselben globalen Geltungsbereich, die gleichen Hooks, die gleiche Datenbank. Jedes Plugin ist ein potenzieller Konflikt mit jedem anderen Plugin.

Ich habe WordPress-Sites mit 30, 40, sogar 60+ aktiven Plugins geprüft. An diesem Punkt wartest du nicht mehr eine Website. Du wartest einen Jenga-Turm.

Performance ist ein Vollzeitjob geworden

Dein PageSpeed-Score liegt in den 30ern. Du hast ein Caching-Plugin, ein Bildoptimierungs-Plugin, ein Minifizierungs-Plugin und ein CDN-Plugin installiert -- alles um Performance-Probleme zu beheben, die von den anderen 25 Plugins verursacht werden. Die Ironie ist dick.

WordPress generiert auf jeder Anfrage dynamisch Seiten (falls nicht gecacht). Jedes Plugin kann seine eigenen CSS- und JavaScript-Dateien injizieren. Eine typische WordPress-Seite mit beliebten Plugins lädt 15-30 separate Render-Blocking-Ressourcen. Googles 2024 Core Web Vitals-Daten zeigen, dass WordPress-Sites eine 33%-Quote auf allen drei CWV-Metriken haben, im Vergleich zu 52% für Sites, die mit modernen JavaScript-Frameworks gebaut wurden.

Sicherheitslücken halten dich wach

WPScans 2024 Sicherheitslücken-Datenbank verfolgte über 7.000 neue WordPress-Sicherheitslücken in diesem Jahr allein -- die überwiegende Mehrheit in Plugins und Themes. Wenn du eine Site betreibst, die Benutzerdaten, Zahlungen oder irgendwelche sensiblen Informationen handhabt, ist jedes Plugin eine Angriffsfläche. Patchstack berichtete, dass 97% der WordPress-Sicherheitslücken 2024 von Plugins kamen.

Du vertraust im Grunde Dutzenden unabhängiger Entwickler -- viele davon pflegen Plugins als Nebenprojekte -- mit deiner Sicherheitslage an.

Dein Dev-Team hasst es, daran zu arbeiten

Dieser wird unterbewertet. Gute Entwickler wollen nicht mehr an WordPress arbeiten. Der PHP-Template-Spaghetti-mit-ACF-Fields-Workflow ist schmerzhaft im Vergleich zu moderner komponentenbasierter Entwicklung. Wenn du versuchen möchtest, Engineering-Talente anzuziehen und zu halten, ist dein Tech Stack wichtig.

Die WordPress-Steuer: Was Plugin-Hölle wirklich kostet

Lass mich einige Zahlen dazu geben. Für eine mittelgroße WordPress-Site (sagen wir eine E-Commerce-Site oder eine SaaS-Marketing-Site mit Blog, Benutzerkonten und benutzerdefinierten Funktionen), sieht die jährliche "WordPress-Steuer" typischerweise so aus:

Kostenkategorie Jährliche Schätzung
Premium Plugin-Lizenzen (15-20 Plugins) $1.500 - $4.000
Verwaltetes WordPress-Hosting (WP Engine, Kinsta) $1.200 - $6.000
Sicherheitsüberwachung + Bereinigung (Sucuri, Wordfence) $300 - $500
Performance-Optimierungszeit (Developer-Stunden) $3.000 - $8.000
Plugin-Konflikt-Debugging (Developer-Stunden) $2.000 - $6.000
Notfallbehebungen von Updates, die Dinge brechen $1.000 - $4.000
Gesamte jährliche WordPress-Steuer $9.000 - $28.500

Das ist, bevor du eine einzige neue Funktion baust. Das ist die Kosten, um nur die Lichter anzulassen.

Warum Next.js + Supabase der Stack ist, der Sinn macht

Es gibt ein Dutzend Möglichkeiten, Headless zu gehen. Du könntest Gatsby verwenden (obwohl es seit der Übernahme durch Netlify im Wesentlichen im Wartungsmodus ist). Du könntest Remix, Astro oder SvelteKit verwenden. Für das Backend könntest du Firebase, PlanetScale oder eine benutzerdefinierte API verwenden.

Aber für Teams, die 2025 von WordPress migrieren, trifft Next.js + Supabase einen süßen Punkt, der schwer zu schlagen ist. Hier ist warum.

Next.js: Das Frontend, das alles macht

Next.js 15 (stabil seit Oktober 2024) gibt dir Server Components standardmäßig, was bedeutet, dass du die Performance statischer Sites mit der Flexibilität dynamischer Sites bekommst. Du kannst deine Blog-Posts zur Build-Zeit statisch generieren, deine dynamischen Seiten server-rendern und interaktive Komponenten client-rendern -- alles in derselben App.

Für Teams, die von WordPress kommen, sind die wichtigsten Vorteile:

  • Eingebaute Bildoptimierung -- ersetzt 2-3 WordPress Plugins
  • Automatisches Code-Splitting -- jede Seite lädt nur das JS, das sie braucht
  • Edge Middleware -- Umgang mit Umleitungen, Auth und A/B-Tests auf der CDN-Ebene
  • Inkrementelle Statische Regeneration (ISR) -- einzelne Seiten neu aufbauen ohne vollständige Bereitstellungen
  • App Router mit React Server Components -- reduziert dramatisch JavaScript auf der Client-Seite

Wir bauen viele Next.js-Projekte bei Social Animal (schau dir unsere Next.js-Entwicklungsfähigkeiten an), und der Performance-Unterschied zu WordPress ist konstant dramatisch.

Supabase: Das Backend, das WordPress sich gewünscht hat

Supabase ist eine Open-Source-Firebase-Alternative, die auf PostgreSQL gebaut ist. Es gibt dir:

  • Eine vollständige Postgres-Datenbank mit einer REST und GraphQL API, die automatisch aus deinem Schema generiert wird
  • Eingebaute Authentifizierung (Email, OAuth, Magic Links, SSO)
  • Row-Level-Security-Richtlinien für detaillierte Zugriffskontrolle
  • Echtzeit-Abonnements via WebSockets
  • Edge Functions für serverless Backend-Logik
  • Speicher für Datei-Uploads mit CDN-Zustellung

Für WordPress-Migrationen speziell ist Supabase brilliant, weil WordPress MySQL verwendet, und dein Datenmodell kartiert überraschend gut zu PostgreSQL. Benutzerdefinierte Post Types werden zu Tabellen. Post Meta wird zu JSONB-Spalten. Benutzerdaten kartieren fast 1:1.

Supabase Free Tier enthält 500MB Datenbank, 1GB Speicher und 50.000 monatlich aktive Benutzer auf Auth. Ihr Pro Plan bei $25/Monat deckt die meisten Production Sites. Vergleich das mit den $30-$100/Monat, die du allein für verwaltetes WordPress-Hosting zahlst.

Entwachsen WordPress? Ein Migrations-Playbook für Next.js + Supabase - Architektur

Das Migrations-Playbook: Phase für Phase

Hier ist der Ansatz, den ich über Dutzende WordPress-Migrationen verfeinert habe. Das ist kein Wochenend-Projekt -- budget 4-12 Wochen je nach Site-Komplexität -- aber es ist vorhersehbar und risikofrei, wenn du die Phasen befolgst.

Phase 1: Audit und Architektur (Woche 1)

Bevor du eine einzige Codezeile schreibst:

  1. Exportiere eine vollständige Plugin-Liste mit wp plugin list --status=active (WP-CLI)
  2. Kartiere jeden Plugin zu seinem Ersatz im neuen Stack
  3. Exportiere deine gesamte URL-Struktur einschließlich aller Posts, Seiten, Taxonomien und benutzerdefinierten Post Types
  4. Dokumentiere alle Formulare, Integrationen und Drittanbieter-Verbindungen
  5. Identifiziere benutzerdefinierte Funktionalität, die in deinem Thema functions.php lebt

Die Plugin-Mapping-Übung ist kritisch. Hier ist, wie gängige Ersätze aussehen:

WordPress Plugin Headless Ersatz
Yoast SEO Next.js eingebaute Metadata API + generateMetadata()
WP Super Cache / W3 Total Cache Nicht benötigt (standardmäßig statisch)
Wordfence / Sucuri Supabase RLS + Vercels eingebauter DDoS-Schutz
Contact Form 7 / Gravity Forms React Hook Form + Supabase Edge Function
WooCommerce Saleor, Medusa.js oder Shopify Storefront API
ACF / Custom Fields Supabase-Tabellen mit typisierten Schemas
WP Migrate DB One-Time Supabase-Migrations-Script
Smush / ShortPixel Next.js Image Component (eingebaut)
Elementor / WPBakery React Components (du wirst sie nicht vermissen)

Phase 2: Einrichtung des neuen Stacks (Woche 2)

# Erstelle dein Next.js-Projekt
npx create-next-app@latest my-site --typescript --tailwind --app --src-dir

# Installiere Supabase
npm install @supabase/supabase-js @supabase/ssr

# Richte Umgebungsvariablen ein
cp .env.example .env.local

Deine .env.local:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

Bereitstellung auf Vercel sofort. Ja, bevor du etwas Bedeutungsvolles gebaut hast. Eine Live-Preview-URL von Tag eins zu haben ändert, wie du arbeitest -- Stakeholder können Fortschritt sehen, und du fängst Bereitstellungsprobleme früh.

Datenmigration: Deine Inhalte aus WordPress holen

Hier ist, wo die meisten Migrations-Guides vage werden. Lass mich konkret sein.

Schritt 1: WordPress-Daten exportieren

Verwende nicht den eingebauten WordPress XML Export. Er ist unvollständig und schlecht strukturiert. Stattdessen verwende WP-CLI und direkte Datenbankabfragen:

# Exportiere Posts als JSON
wp post list --post_type=post --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > posts.json

# Exportiere Seiten
wp post list --post_type=page --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > pages.json

# Exportiere benutzerdefinierte Post Types
wp post list --post_type=your_cpt --format=json > cpt.json

# Exportiere Post Meta (ACF Felder, etc.)
wp eval 'global $wpdb; $results = $wpdb->get_results("SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key NOT LIKE \"_%\""); echo json_encode($results);' > postmeta.json

Schritt 2: Transformiere und lade in Supabase

Schreibe ein Migrations-Script. Ich bevorzuge TypeScript dafür:

import { createClient } from '@supabase/supabase-js'
import posts from './exports/posts.json'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

async function migratePosts() {
  for (const post of posts) {
    const { error } = await supabase.from('posts').insert({
      wp_id: post.ID,
      title: post.post_title,
      slug: post.post_name,
      content: convertWpContentToMdx(post.post_content),
      excerpt: post.post_excerpt,
      published_at: post.post_date,
      status: post.post_status === 'publish' ? 'published' : 'draft',
    })
    
    if (error) console.error(`Failed to migrate post ${post.ID}:`, error)
  }
}

function convertWpContentToMdx(html: string): string {
  // Verwende turndown oder rehype um WordPress HTML zu MDX zu konvertieren
  // Behandle Shortcodes, Embeds und Gutenberg Blocks
  // Das ist, wo 80% der Migrations-Komplexität lebt
}

Die convertWpContentToMdx Funktion ist, wo du die meiste Zeit verbringst. WordPress-Inhalte sind ein Chaos aus HTML, Shortcodes, Gutenberg-Block-Kommentaren und eingebetteten oEmbed URLs. Bibliotheken wie turndown handhaben einfache HTML-zu-Markdown Konvertierung, aber du wirst benutzerdefinierte Regeln für Shortcodes und Blöcke brauchen.

Schritt 3: Migriere Medien

import { createClient } from '@supabase/supabase-js'
import fetch from 'node-fetch'

async function migrateMedia(mediaItems: any[]) {
  for (const item of mediaItems) {
    const response = await fetch(item.source_url)
    const buffer = await response.buffer()
    
    const { error } = await supabase.storage
      .from('media')
      .upload(`uploads/${item.slug}.${item.mime_type.split('/')[1]}`, buffer, {
        contentType: item.mime_type,
      })
    
    if (error) console.error(`Failed to upload ${item.slug}:`, error)
  }
}

Bau des neuen Frontends mit Next.js

Mit deinen Daten in Supabase ist das Bauen des Frontends der unterhaltsame Teil. Hier ist eine typische Blog-Post-Seite mit Next.js App Router:

// src/app/blog/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'
import { notFound } from 'next/navigation'
import { MDXRemote } from 'next-mdx-remote/rsc'

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('title, excerpt, og_image')
    .eq('slug', params.slug)
    .single()

  if (!post) return {}

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: { images: [post.og_image] },
  }
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('*')
    .eq('slug', params.slug)
    .eq('status', 'published')
    .single()

  if (!post) notFound()

  return (
    <article className="prose lg:prose-xl mx-auto">
      <h1>{post.title}</h1>
      <time dateTime={post.published_at}>
        {new Date(post.published_at).toLocaleDateString()}
      </time>
      <MDXRemote source={post.content} />
    </article>
  )
}

Beachte, dass es kein Caching Plugin gibt, kein Performance Plugin, kein SEO Plugin. Die Metadata API handhabt SEO. Server Components handhaben Performance. Das CDN handhabt Caching. Das ist alles eingebaut.

Einrichtung von Supabase als dein Backend

Dein Supabase Schema sollte rund um deine tatsächlichen Datenbedürfnisse entworfen sein, nicht um Wordpresses generische wp_posts / wp_postmeta Struktur. Hier ist ein saubereres Schema:

-- Posts Tabelle
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')),
  author_id uuid references auth.users(id),
  published_at timestamptz,
  created_at timestamptz default now(),
  updated_at timestamptz default now(),
  metadata jsonb default '{}'
);

-- Kategorien
create table categories (
  id uuid default gen_random_uuid() primary key,
  name text not null,
  slug text unique not null,
  description text
);

-- Row Level Security
alter table posts enable row level security;

create policy "Published posts are viewable by everyone"
  on posts for select
  using (status = 'published');

create policy "Authors can manage their own posts"
  on posts for all
  using (auth.uid() = author_id);

Die metadata jsonb Spalte ist dein Fluchtweg. Jedes benutzerdefinierte Feld, das nicht seine eigene Spalte verdient, kann dort leben. Es ist indexiert, abfragbar und unendlich flexibel -- wie ACF Felder aber ohne das Plugin.

Umgang mit Authentifizierung und Benutzerdaten

Wenn deine WordPress-Site Benutzerkonten hat, handhabt Supabase Auth die Migration sauber. Du kannst keine Password Hashes migrieren (WordPress verwendet phpass, Supabase verwendet bcrypt), aber du kannst:

  1. Benutzer-Emails und Profile in Supabase importieren
  2. Beim ersten Login einen "Setze dein Passwort zurück" Flow für alle Benutzer auslösen
  3. Oder verwende Magic Link Authentifizierung, damit Passwörter überhaupt nicht benötigt werden

Supabase unterstützt Email/Passwort, Google, GitHub, Apple und Dutzende anderer OAuth-Provider sofort. Kein Plugin benötigt.

SEO-Erhaltung: Verliere nicht, was du aufgebaut hast

Das ist unverhandelbar. Eine vermurkste Migration kann jahrelange SEO-Ausstattung über Nacht zerstören. Hier ist die Checkliste:

  1. Kartiere jede alte URL zu ihrer neuen URL. WordPress verwendet standardmäßig /2024/01/post-title/. Deine neue Site könnte /blog/post-title verwenden. Jede einzelne alte URL braucht eine 301 Umleitung.

  2. Implementiere Umleitungen in Next.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Datumsbasierte WordPress URLs zu sauberen Slugs
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Kategorieseiten
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
    ]
  },
}
  1. Bewahre alle Meta Titles, Descriptions und strukturierten Daten. Exportiere sie von Yoast vor der Migration.
  2. Reiche die neue Sitemap in Google Search Console sofort nach dem Start ein.
  3. Halte die alte Site auf einer Subdomain (old.yoursite.com) für 30 Tage als Fallback laufen.

Performance-Benchmarks: Vorher und Nachher

Hier sind echte Zahlen aus Migrationen, die wir bei Social Animal gemacht haben (das sind Durchschnitte über 12 Migrations-Projekte in 2024-2025):

Metrik WordPress (Vorher) Next.js + Supabase (Nachher) Verbesserung
Lighthouse Performance Score 38 94 +147%
Largest Contentful Paint (LCP) 4,2s 0,9s -79%
First Input Delay (FID) 180ms 12ms -93%
Cumulative Layout Shift (CLS) 0,25 0,02 -92%
Time to First Byte (TTFB) 1,8s 0,15s -92%
Gesamtgewicht der Seite 3,2MB 420KB -87%
HTTP Anfragen 47 8 -83%

Das sind nicht ausgewählte. Sie sind konsistent. Wenn du 30+ Plugins elimierst, von denen jeder seine eigenen CSS und JS injiziert, und dynamisches PHP-Rendering durch statisches/server-gerendetes React Components auf einem globalen CDN ersetzt, sind die Ergebnisse vorhersehbar.

Wenn du neugierig bist, wie diese Art von Ergebnissen für dein Projekt aussehen könnte, erklärt unsere Preis-Seite die typischen Kosten für Headless-Migrations-Projekte.

Kostenvergleich: WordPress vs Headless Stack

WordPress (Jährlich) Next.js + Supabase (Jährlich)
Hosting $1.200 - $6.000 (WP Engine/Kinsta) $0 - $240 (Vercel Pro)
Datenbank/Backend Enthalten im Hosting $0 - $300 (Supabase Pro)
Plugin-Lizenzen $1.500 - $4.000 $0
Sicherheits-Tools $300 - $500 $0 (eingebaut)
CDN $0 - $600 $0 (enthalten in Vercel)
Wartungs-Developer-Stunden $6.000 - $18.000 $1.000 - $4.000
Gesamtkosten $9.000 - $29.100 $1.000 - $4.540

Der Headless Stack ist 70-85% billiger zu betreiben jährlich. Die Migration selbst hat offensichtlich Vorlaufkosten -- typischerweise $15.000-$60.000 je nach Komplexität für einen professionellen Build (siehe unsere Headless CMS Entwicklungsservices für Details). Aber es zahlt sich selbst innerhalb von 6-18 Monaten durch reduzierte operative Kosten, bevor du sogar die Umsatzauswirkung besserer Performance und SEO einrechnet.

FAQ

Muss ich React/Next.js lernen um meine Inhalte nach der Migration zu verwalten?

Nein. Die meisten Teams verbinden Next.js mit einem Headless CMS wie Sanity, Contentful oder sogar WordPress, das nur als ein Headless CMS verwendet wird (über seine REST API). Content Editoren berühren niemals Code. Sie bekommen eine saubere Bearbeitungs-Schnittstelle, und das Frontend zieht Inhalte über API. Wenn du den WordPress Editor behalten möchtest, den dein Team bereits kennt, kannst du das absolut -- entferne einfach das WordPress Frontend und benutze es als ein Content Backend.

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

Für eine inhalts-fokussierte Site mit Blog und Standard-Seiten: 4-6 Wochen. Für eine Site mit E-Commerce, Benutzerkonten, benutzerdefinierten Post Types und komplexer Funktionalität: 8-14 Wochen. Die größte Variable ist Inhalts-Komplexität -- Sites mit stark Shortcode-abhängigen Inhalten oder tiefgreifend angepassten Gutenberg Blocks nehmen länger um sauber zu migrieren.

Verliere ich meine Google Rankings während der Migration?

Nein, wenn du die Umleitungen richtig handhabst. 301 Umleitungen bewahren ~90-99% der Link-Ausstattung. Wir sehen typischerweise einen kleinen Rückgang in den ersten 1-2 Wochen nach der Migration (Google muss neu crawlen), gefolgt von verbesserten Rankings aufgrund besserer Core Web Vitals Scores. Der Schlüssel ist das Kartieren jeder einzelnen URL und das Nicht-Starten bis deine Umleitungs-Karte vollständig ist.

Ist Supabase produktionsreif für hochfrequente Sites?

Ja. Supabase läuft auf AWS-Infrastruktur und wurde in Production von Unternehmen verwendet, die Millionen von Anfragen handhaben. Ihre Datenbank ist nur PostgreSQL -- argumentativ die am meisten battle-getestete Datenbank in der Existenz. Seit 2025 bedient Supabase über 1 Million Datenbanken und verarbeitet Milliarden API-Anfragen täglich. Für zusätzliche Skalierung beinhalten ihre Pro ($25/Mo) und Team ($599/Mo) Pläne dedizierte Ressourcen und Prioritäts-Support.

Kann ich WooCommerce zu diesem Stack migrieren?

Du kannst, aber E-Commerce addiert erhebliche Komplexität. Die meisten Teams, die von WooCommerce migrieren, gehen zu entweder Shopify (mit der Storefront API mit einem Next.js Frontend) oder einer Open-Source-Lösung wie Medusa.js oder Saleor. Supabase kann Produkt-Kataloge und Order-Verwaltung handhaben, aber du müsstest selbst Checkout, Zahlungsverarbeitung, Inventar-Verwaltung und Steuerberechnung bauen. Für die meisten Unternehmen macht die Verwendung eines dedizierten E-Commerce Backends und die Verbindung mit Next.js mehr Sinn.

Was ist mit WordPress Multisite -- kann dieser Stack es ersetzen?

Absolut. Next.js hat ausgezeichnete Unterstützung für Multi-Tenant-Architekturen mit Middleware und dynamischem Routing. Supabase Row Level Security macht es einfach, Daten nach Tenant zu partitionieren. Wir haben WordPress Multisite Netzwerke mit 50+ Sites zu einer einzigen Next.js Anwendung mit Tenant-spezifischem Routing migriert, und die operative Vereinfachung war riesig.

Brauche ich immer noch ein CMS, oder kann ich nur Supabase direkt verwenden?

Supabase gibt dir einen Tabellen-Editor, der für Entwickler funktioniert, aber Content Editoren wollen typischerweise etwas Poliertes. Die häufigsten Ansätze sind: (1) verwende ein dediziertes Headless CMS wie Sanity oder Storyblok für Inhalte und Supabase für Applikationsdaten, (2) baue eine einfache Admin-UI mit etwas wie Next.js + Supabase Auth oder (3) halte WordPress als ein Headless CMS Backend. Option 1 ist beliebtesten für inhaltsreiche Sites. Wenn du Optionen erkundest, erkläre ich die Tradeoffs auf unserer Astro Entwicklungs und Headless CMS Seite.

Was wenn die Migration schief geht -- kann ich zu WordPress zurückrollen?

Ja, und du solltest dafür planen. Halte deine WordPress-Site auf einer Subdomain während des gesamten Migrations-Prozesses laufen. Verwende DNS-Level-Umschalten (ändere deinen A Record oder CNAME), so dass du dich innerhalb von Minuten zurückrollen kannst. Wir empfehlen, die alte WordPress-Instanz für mindestens 30 Tage nach dem Start laufen zu lassen. Deaktiviere sie nur, nachdem du bestätigt hast, dass alle Umleitungen funktionieren, Such-Rankings stabil sind und alle Funktionalität bestätigt wurde. Wenn du Hilfe bei der Planung einer Migration mit angemessenen Rollback-Prozeduren möchtest, kontaktiere unser Team -- wir haben das oft genug gemacht um zu wissen, wo die Fallstricke sind.