Deine WordPress-Installation lädt bei jedem Seitenaufruf 487 Kilobyte — Theme-Assets, Plugin-Skripte, jQuery-Abhängigkeiten in drei Schichten gestapelt. Du beobachtest, wie deine Lighthouse-Performance-Scores in den 40ern stagnieren, während die Next.js-Sites deiner Konkurrenten mit identischem Inhalt über dir ranken. Die Migration zu Next.js und Vercel klingt in der Theorie sauber: Inhalte exportieren, ein Headless-CMS konfigurieren, deployen. In der Praxis habe ich zwölf dieser Migrationen über drei Jahre hinweg beobachtet. Vier wurden in unter zwei Wochen ausgeliefert. Acht standen monatelang still, weil Teams übersehen haben, was WordPress stillschweigend für deine Website erledigt hat — Weiterleitungen, Bildoptimierung, XML-Sitemaps, Meta-Injection — bevor sie es rausgerissen haben. Der Unterschied zwischen einem reibungslosen Cutover und einem 2-Uhr-Rollback kommt fast immer auf eines an: Eine Audit durchzuführen, was WordPress tatsächlich für deine Website tut, bevor du die Installation abschaltest.

Dieser Leitfaden ist alles, das mir jemand vor meiner ersten Migration hätte geben sollen. Wir behandeln die gesamte Reise: Evaluierung, ob du überhaupt migrieren solltest, Auswahl deines Headless-CMS, Content-Migration, Template-Rebuild, SEO-Handling ohne Ranking-Verlust und Deployment auf Vercel mit einem Setup, das nicht zusammenbricht, wenn der Traffic ansteigt.

Lasst uns einsteigen.

WordPress zu Next.js-Migration auf Vercel: Ein 2026-Leitfaden

Inhaltsverzeichnis

Warum 2026 von WordPress zu Next.js migrieren?

Sei ehrlich — WordPress betreibt immer noch etwa 40 % des Webs im Jahr 2026. Es geht nirgendwohin. Aber die Gründe, es zu verlassen, sind überzeugender geworden:

Performance-Decke. Auch mit aggressiven Caching-Plugins (WP Rocket, W3 Total Cache) stoßen die meisten WordPress-Sites bei etwa 70-80 auf der Lighthouse-Performance-Skala an eine Wand. Plugin-Bloat, Render-blockierendes PHP und Datenbankabfragen bei jedem Seitenaufruf erzeugen Overhead, den keine Menge Optimierung vollständig beseitigen kann.

Sicherheits-Oberflächenbereich. WordPress hatte 2025 149 dokumentierte Sicherheitslücken in Core und beliebten Plugins. Jedes Plugin ist ein Angriffsvektor. Jedes Theme-Update ist ein potenzieller Bruch. Wenn du WooCommerce laufen lässt, verdoppelt sich die Oberflächenbereich.

Entwickler-Erfahrung. Wenn dein Team React kennt, fühlt sich das Schreiben in PHP-Templates an wie mit deiner nicht dominanten Hand schreiben. Next.js 15s App Router, Server Components und eingebautes Caching bieten dir einen modernen Entwicklungs-Workflow, den WordPress nicht erreichen kann.

Kosten bei Skalierung. Managed WordPress Hosting (WP Engine, Kinsta) kostet $30-$300/Monat für anständige Performance. Verels Pro-Plan mit $20/Benutzer/Monat mit Edge Functions und automatischer Skalierung kostet oft weniger, während er bessere Performance bietet.

Das gesagt — migriere nicht nur, weil es trendy ist. Wenn deine Website ein einfacher Blog mit 50 Beiträgen ist und dein Client ihn wöchentlich über das WordPress-Admin-Panel aktualisiert, könnte eine Migration mehr Probleme schaffen als sie löst. Die besten Kandidaten für Migration sind:

  • Websites mit 500+ Seiten, die bessere Performance benötigen
  • Teams, die component-basierte Entwicklung wollen
  • Websites, bei denen Plugin-Konflikte Wartungsnachtmare verursachen
  • E-Commerce-Websites, die WooCommerce-Performance-Grenzen erreichen
  • Marketing-Websites, die A/B-Tests und Personalisierung im Edge benötigen

Pre-Migration-Audit: Was WordPress tatsächlich tut

Hier gehen die meisten Migrationen schief. Menschen denken, sie migrieren einen Blog, aber WordPress behandelt tatsächlich Kontaktformulare, Weiterleitungen, Bildoptimierung, Suche, Kommentare, Authentifizierung, Cron-Jobs und fünfzehn andere Dinge, die in Plugin-Konfigurationen vergraben sind.

Bevor du eine einzige Zeile Next.js-Code schreibst, dokumentiere alles:

Plugin-Bestand

Exportiere deine Plugin-Liste und kategorisiere jedes:

wp plugin list --status=active --format=csv > active-plugins.csv

Für jedes Plugin antwortet: Was macht das, und was ersetzt es im Next.js-Ökosystem?

WordPress-Plugin Funktion Next.js-Ersatz
Yoast SEO Meta-Tags, Sitemaps, Schema next-seo + Custom sitemap.xml Route
WP Rocket Caching, Minifizierung Vercel Edge Cache + Next.js eingebaut
Contact Form 7 Formularverarbeitung React Hook Form + API Route oder Formspree
Wordfence Sicherheit Nicht nötig (keine Admin-Oberfläche)
WPML Mehrsprachig next-intl oder eingebautes i18n-Routing
WooCommerce E-Commerce Shopify Storefront API oder Saleor
Advanced Custom Fields Custom Content-Modelle Dein Headless-CMS Content-Modeling
Redirection URL-Weiterleitungen next.config.js Weiterleitungen oder Vercel Config
WP Cron Geplante Tasks Vercel Cron Jobs oder separater Service
Imagify Bildoptimierung next/image mit Vercel Image Optimization

Content-Bestand

Zähle und kategorisiere deinen Content:

SELECT post_type, post_status, COUNT(*) 
FROM wp_posts 
GROUP BY post_type, post_status;

Vergess nicht: Custom Post Types, Taxonomy-Terms, Benutzerprofile, Menüstrukturen, Widget-Konfigurationen und Optionswerte. Diese "einfache" WordPress-Website hat wahrscheinlich mehr Content-Typen als du denkst.

URL-Zuordnung

Exportiere jede URL. Wirklich jede. Nutze Screaming Frog oder einen einfachen Sitemap-Crawl:

curl -s https://yoursite.com/sitemap_index.xml | \
grep -oP '<loc>\K[^<]+' | \
xargs -I {} curl -s {} | \
grep -oP '<loc>\K[^<]+' > all-urls.txt

Diese Datei ist Gold. Du wirst sie für Weiterleitungs-Zuordnung, SEO-Erhaltung und QA-Tests nach der Migration verwenden.

WordPress zu Next.js-Migration auf Vercel: Ein 2026-Leitfaden - Architektur

Auswahl deines Headless-CMS-Backends

Du brauchst irgendwo, um Content zu speichern und zu verwalten. Die drei häufigsten Pfade im Jahr 2026:

Option 1: WordPress als Headless CMS

Ja, du kannst WordPress als Backend behalten und Next.js als Frontend nutzen. WPGraphQL (jetzt bei v2.1) macht dies überraschend praktikabel. Deine Editoren behalten die vertraute Admin-Oberfläche. Du bekommst ein modernes Frontend.

// lib/wordpress.js
const API_URL = process.env.WORDPRESS_GRAPHQL_URL;

export async function getPostBySlug(slug) {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `
        query PostBySlug($slug: ID!) {
          post(id: $slug, idType: SLUG) {
            title
            content
            date
            featuredImage {
              node {
                sourceUrl
                altText
              }
            }
            seo {
              title
              metaDesc
              opengraphImage {
                sourceUrl
              }
            }
          }
        }
      `,
      variables: { slug },
    }),
    next: { revalidate: 60 },
  });
  const json = await res.json();
  return json.data.post;
}

Der Nachteil? Du wartest immer noch eine WordPress-Installation. Sicherheits-Updates, PHP-Versionsverwaltung, Datenbank-Backups — alles bleibt auf deiner Liste. Und du zahlst immer noch für WordPress-Hosting.

Option 2: Purpose-Built Headless CMS

Das empfehle ich für die meisten Migrationen. Verschiebe deinen Content in ein CMS, das von Grund auf für API-First-Delivery gebaut wurde.

CMS Preisgestaltung (2026) Beste für Content-Modellierung API-Typ
Sanity Kostenlos, $15/Benutzer/Mo Pro Komplexer Content, Zusammenarbeit in Echtzeit Ausgezeichnet, Code-definiert GROQ + GraphQL
Contentful Kostenlos, $300/Mo Team Enterprise, große Teams Gut, UI-definiert REST + GraphQL
Storyblok Kostenlos, €106/Mo Business Visuelles Editing, Komponenten Großartig, visuell REST + GraphQL
Strapi v5 Kostenlos (selbst gehostet), Cloud ab $29/Mo Volle Kontrolle, Open Source Flexibel, UI-definiert REST + GraphQL
Payload CMS 3.0 Kostenlos (selbst gehostet) Entwickler, die Code-First wollen Ausgezeichnet, Code-definiert REST + GraphQL

Wenn dein Team bei Social Animal die Migration behandelt, empfehlen wir typischerweise Sanity oder Payload für Headless-CMS-Entwicklung — sie geben Entwicklern die meiste Kontrolle über Content-Modellierung, während Editoren glücklich sind.

Option 3: Markdown/MDX im Repository

Für Entwickler-Blogs und Dokumentations-Websites ist das Speichern von Content als MDX-Dateien in deinem Git-Repo der einfachste Ansatz. Kein CMS zu verwalten, keine API-Aufrufe, Content wird zusammen mit Code versioniert. Aber das funktioniert nur, wenn deine Content-Editoren mit Git-Workflows vertraut sind.

Content-Migrationsstrategie

Export aus WordPress

Der eingebaute WordPress-Export (Tools → Export) gibt dir eine XML-Datei. Es ist ein Anfang, aber es ist ungeordnet. Für strukturierte Migration nutze ich ein Custom WP-CLI-Skript:

// export-content.php
<?php
$posts = get_posts([
    'post_type' => ['post', 'page', 'your_custom_type'],
    'posts_per_page' => -1,
    'post_status' => 'publish',
]);

$export = [];
foreach ($posts as $post) {
    $export[] = [
        'id' => $post->ID,
        'title' => $post->post_title,
        'slug' => $post->post_name,
        'content' => apply_filters('the_content', $post->post_content),
        'excerpt' => $post->post_excerpt,
        'date' => $post->post_date,
        'modified' => $post->post_modified,
        'author' => get_the_author_meta('display_name', $post->post_author),
        'categories' => wp_get_post_categories($post->ID, ['fields' => 'names']),
        'tags' => wp_get_post_tags($post->ID, ['fields' => 'names']),
        'featured_image' => get_the_post_thumbnail_url($post->ID, 'full'),
        'acf' => function_exists('get_fields') ? get_fields($post->ID) : [],
        'yoast' => [
            'title' => get_post_meta($post->ID, '_yoast_wpseo_title', true),
            'description' => get_post_meta($post->ID, '_yoast_wpseo_metadesc', true),
        ],
    ];
}

file_put_contents('export.json', json_encode($export, JSON_PRETTY_PRINT));

Content-Transformation

WordPress-Content wird als HTML mit Gutenberg-Block-Markup gespeichert. Du musst entscheiden: HTML behalten und rendern oder in das strukturierte Format deines CMS konvertieren?

Für Sanity nutze ich @sanity/block-tools, um HTML in Portable Text zu konvertieren. Für Contentful behandelt ihre Migration CLI Rich-Text-Konvertierung. Auf jeden Fall solltest du Zeit für Content-Cleanup einplanen — WordPress-Content ist voll mit [shortcodes], Inline-Styles und brochenem HTML, das bereinigt werden muss.

// migrate-to-sanity.js
import { htmlToBlocks } from '@sanity/block-tools';
import { JSDOM } from 'jsdom';
import { Schema } from '@sanity/schema';

const schema = Schema.compile({ /* dein Schema */ });
const blockContentType = schema.get('post')
  .fields.find(f => f.name === 'body').type;

function convertPost(wpPost) {
  return {
    _type: 'post',
    title: wpPost.title,
    slug: { current: wpPost.slug },
    publishedAt: wpPost.date,
    body: htmlToBlocks(
      wpPost.content,
      blockContentType,
      { parseHtml: (html) => new JSDOM(html).window.document }
    ),
  };
}

Bild-Migration

Übersehe das nicht. Lade jedes Bild von wp-content/uploads herunter, lade neu in dein CMS oder CDN (Cloudinary, Vercel Blob Storage, S3) und aktualisiere alle Content-Referenzen. Ich schreibe typischerweise ein Skript, das:

  1. Die Export-JSON nach Bild-URLs durchsucht
  2. Jedes Bild herunterlädt
  3. Zu neuem Storage hochlädt
  4. Eine URL-Zuordnungsdatei erstellt
  5. Find-and-Replace über alle Content laufen lässt

Frontend in Next.js 15 neu aufbauen

Next.js 15 (seit Ende 2024 stabil, mit 15.2 aktuell im Jahr 2026) nutzt standardmäßig den App Router. Hier ist die Struktur, die ich für Content-intensive Websites nutze:

app/
├── layout.tsx          # Root Layout mit Fonts, Analytics
├── page.tsx            # Homepage
├── blog/
│   ├── page.tsx        # Blog-Listing mit Pagination
│   └── [slug]/
│       └── page.tsx    # Individuelle Blog-Beiträge
├── [slug]/
│   └── page.tsx        # Generische Seiten
├── sitemap.ts          # Dynamische Sitemap-Generierung
├── robots.ts           # robots.txt
└── not-found.tsx       # Custom 404

Statische Generierung mit ISR

Für die meisten Content-Seiten ist Incremental Static Regeneration der süße Punkt — statische Performance mit dynamischer Frische:

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPostSlugs } from '@/lib/cms';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const slugs = await getAllPostSlugs();
  return slugs.map((slug) => ({ slug }));
}

export async function generateMetadata({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) return {};
  return {
    title: post.seo?.title || post.title,
    description: post.seo?.description || post.excerpt,
    openGraph: {
      images: [post.featuredImage?.url],
    },
  };
}

export const revalidate = 3600; // Revalidate alle Stunde

export default async function BlogPost({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) notFound();

  return (
    <article className="prose lg:prose-xl">
      <h1>{post.title}</h1>
      <time dateTime={post.date}>{formatDate(post.date)}</time>
      <PostBody content={post.body} />
    </article>
  );
}

Für Websites, die Echtzeit-Updates benötigen (Nachrichten, Live-Content), nutze On-Demand-Revalidation via Webhooks von deinem CMS. Die meisten Headless-CMS-Plattformen unterstützen Webhook-Trigger beim Content-Publish.

Wenn du dich bei Next.js-Entwicklung ansiehst und mehr über die Rendering-Trade-Offs verstehen möchtest, haben wir das separat geschrieben.

URL-Struktur und SEO-Erhaltung

Das ist nicht verhandelbar. Wenn du deine URL-Struktur verlierst, verlierst du deine Suchplatzierungen. Punkt.

Weiterleitungs-Zuordnung

WordPress nutzt URL-Muster wie /2024/03/post-slug/ oder /category/term/. Deine Next.js-Website nutzt wahrscheinlich /blog/post-slug. Erstelle eine Weiterleitungs-Zuordnung:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Datums-basierte URLs zu sauberen Slugs
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Kategorie-Archive
      {
        source: '/category/:slug',
        destination: '/blog?category=:slug',
        permanent: true,
      },
      // Pagination
      {
        source: '/page/:num',
        destination: '/blog?page=:num',
        permanent: true,
      },
      // Feed-URLs
      {
        source: '/feed',
        destination: '/rss.xml',
        permanent: true,
      },
    ];
  },
};

Für große Websites (1000+ Weiterleitungen) nutze Verels vercel.json-Konfiguration oder Middleware statt — next.config.js Weiterleitungen haben ein weiches Limit von etwa 1024 Einträgen, bevor Build-Zeiten anfangen zu leiden.

Strukturierte Daten

WordPress-Plugins wie Yoast generieren auto-JSON-LD. Du musst das replizieren:

// components/structured-data.tsx
export function ArticleSchema({ post }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    datePublished: post.date,
    dateModified: post.modified,
    author: {
      '@type': 'Person',
      name: post.author,
    },
    image: post.featuredImage?.url,
    publisher: {
      '@type': 'Organization',
      name: 'Your Site Name',
      logo: { '@type': 'ImageObject', url: '/logo.png' },
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

XML-Sitemap

Next.js 15 macht dynamische Sitemaps unkompliziert:

// app/sitemap.ts
import { getAllPosts, getAllPages } from '@/lib/cms';

export default async function sitemap() {
  const posts = await getAllPosts();
  const pages = await getAllPages();

  return [
    { url: 'https://yoursite.com', lastModified: new Date() },
    ...pages.map((page) => ({
      url: `https://yoursite.com/${page.slug}`,
      lastModified: page.modified,
    })),
    ...posts.map((post) => ({
      url: `https://yoursite.com/blog/${post.slug}`,
      lastModified: post.modified,
    })),
  ];
}

Deployment auf Vercel: Konfiguration, die tatsächlich funktioniert

Projekt-Setup

npx create-next-app@latest my-migrated-site --typescript --tailwind --app
cd my-migrated-site
vercel link

Umgebungsvariablen

Stelle diese im Vercel-Dashboard ein, nicht in .env-Dateien, die in Git committed werden:

CMS_API_URL=https://your-cms-api-endpoint
CMS_API_TOKEN=your-read-only-token
REVALIDATION_SECRET=a-random-string-for-webhook-auth
SITE_URL=https://yoursite.com

Vercel-Konfiguration

// vercel.json
{
  "crons": [
    {
      "path": "/api/revalidate-sitemap",
      "schedule": "0 */6 * * *"
    }
  ],
  "headers": [
    {
      "source": "/fonts/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

On-Demand Revalidation Webhook

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ error: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const { slug, type } = body;

  if (type === 'post') {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Auch das Listing revalidieren
  } else {
    revalidatePath(`/${slug}`);
  }

  return NextResponse.json({ revalidated: true });
}

Weisen Sie dein CMS-Webhook auf https://yoursite.com/api/revalidate mit dem Secret-Header hin. Jetzt erscheinen Content-Updates innerhalb von Sekunden ohne vollständige Rebuilds.

Performance-Benchmarks: Vorher und nachher

Das sind echte Zahlen von Migrationen, die wir bei Social Animal 2025-2026 abgeschlossen haben:

Metrik WordPress (WP Engine) Next.js (Vercel) Verbesserung
Lighthouse Performance 62-78 95-100 +30-40%
Largest Contentful Paint 2.8-4.2s 0.8-1.4s 60-70% schneller
Time to First Byte 800ms-1.5s 50-120ms 90%+ schneller
Cumulative Layout Shift 0.12-0.25 0.01-0.05 ~80% Reduktion
Monatliche Hosting-Kosten $115/Mo Durchschnitt $20-40/Mo 60-80% Ersparnis
Build-Zeit (500 Seiten) N/A (dynamisch) 45-90 Sekunden N/A
Seiten/Sekunde (ISR) 15-30 req/s 10,000+ von Edge Größenordnungen

Die TTFB-Verbesserung allein ist die Migration wert. WordPress generiert jede Seite durch PHP und MySQL. Vercel bedient vorgerenderte Seiten von Edge-Nodes an 300+ Standorten weltweit.

Häufige Migrations-Fallstricke

Fallstrick 1: WordPress RSS-Feeds vergessen. Wenn Menschen deinen Feed abonnieren, leite /feed/ und /rss/ auf einen neuen RSS-Endpoint um. Next.js generiert Feeds nicht standardmäßig — du brauchst eine benutzerdefinierte Route.

Fallstrick 2: WordPress-Shortcodes vermisst. Content, der aus WordPress exportiert wird, ist voller [gallery], [embed] und Plugin-spezifischen Shortcodes. Wenn du diese nicht parsst und konvertierst, rendern sie als Klartext. Schreibe Transformer für jeden Shortcode-Typ, den dein Content nutzt.

Fallstrick 3: WordPress-Kommentardaten ignoriert. Wenn du wertvolle Kommentar-Threads hast, migriere sie zu einem Service wie Disqus oder baue ein benutzerdefiniertes Kommentar-System. Die meisten Menschen lassen Kommentare einfach fallen, aber überprüfe mit Stakeholdern zuerst.

Fallstrick 4: Interne Links nicht getestet. WordPress-Content ist voller interner Links, die absolute URLs nutzen (https://yoursite.com/old-path/). Diese müssen zu relativen Pfaden oder deiner neuen URL-Struktur aktualisiert werden. Ein einfacher Regex Find-and-Replace während der Migration behandelt die meisten Fälle.

Fallstrick 5: wp-content/uploads-Referenzen vergessen. Auch nach der Bild-Migration kann alter Content /wp-content/uploads/2024/03/image.jpg-Pfade referenzieren. Richte eine Catch-all-Weiterleitung oder einen Proxy zu deinem neuen Bild-CDN ein.

Wenn das überwältigend wirkt, ist das ehrlich gesagt normal. Eine richtige Migration dauert 4-12 Wochen, je nach Website-Komplexität. Überprüfe unsere Preisgestaltung oder kontaktiere uns direkt, wenn du erfahrene Hände am Projekt möchtest.

Häufig gestellte Fragen

Wie lange dauert eine WordPress-zu-Next.js-Migration? Für eine Website mit 100-500 Seiten, rechne mit 4-8 Wochen mit einem engagierten Entwickler. Größere Websites mit Custom Post Types, E-Commerce oder mehrsprachigen Inhalten können 8-16 Wochen dauern. Die Content-Migration selbst ist normalerweise 20% der Arbeit — die anderen 80% sind Templates neu aufbauen, Edge-Cases behandeln und QA-Tests jeder URL.

Werde ich meine Google-Rankings während der Migration verlieren? Nicht, wenn du Weiterleitungen richtig behandelst. Implementiere 301-Weiterleitungen für jede URL, die sich ändert, bewahre deine Meta-Titel und Beschreibungen auf, sende deine neue Sitemap an Google Search Console und nutze das Change of Address-Tool, wenn sich deine Domain ändert. Erwarte eine kleine Ranking-Fluktuation für 2-4 Wochen, dann Wiederherstellung oder Verbesserung, während Google bessere Core Web Vitals erkennt.

Kann ich WordPress als mein CMS mit Next.js behalten? Absolut. Das nennt sich "Headless WordPress" und ist ein beliebter Ansatz. Nutze WPGraphQL, um deinen Content als API bereitzustellen, dann konsumiere ihn aus Next.js. Deine Editoren behalten das WordPress-Admin, das sie kennen. Der Hauptnachteil ist, dass du immer noch eine WordPress-Installation wartest — Sicherheits-Updates, Hosting, der ganze Stack.

Wie viel kostet es, von WordPress zu Next.js zu migrieren? Eigene Migration mit einem Entwickler: 100-300 Stunden Arbeit. Agentur-Migration: typischerweise $15,000-$75,000 je nach Komplexität. Die laufenden Hosting-Kosten sinken normalerweise — Vercel Pro mit $20/Benutzer/Monat gegenüber Managed WordPress Hosting mit $50-$300/Monat. Der ROI kommt aus reduzierten Hosting-Kosten, besserer Performance (die Umwandlungsraten verbessert) und niedrigerem Wartungs-Overhead.

Sollte ich den Pages Router oder App Router in Next.js 15 nutzen? App Router, vollkommen. Im Jahr 2026 ist der App Router der stabile Standard mit Server Components, Streaming und parallelen Routes. Der Pages Router funktioniert immer noch und ist nicht veraltet, aber neue Features und Optimierungen sind App-Router-erste. Jede Migration, die wir bei Social Animal machen, nutzt ausschließlich den App Router. Überprüfe unsere Next.js-Entwicklungs-Fähigkeiten für mehr zu unserem Ansatz.

Was ist mit Formularen und dynamischer Funktionalität? Next.js API-Routes (oder Server Actions im App Router) handhaben Formular-Einsendungen, Suche, Authentifizierung und jede serverseitige Logik. Für Kontaktformulare kannst du Server Actions mit einem Service wie Resend für E-Mail-Zustellung nutzen. Für Suche, betrachte Algolia oder Meilisearch. Für Authentifizierung, NextAuth.js (jetzt Auth.js v5) deckt die meisten Anwendungsfälle ab.

Ist Vercel die einzige Option für das Hosting von Next.js? Nein. Du kannst Next.js auf Netlify, AWS Amplify, Cloudflare Pages bereitstellen oder selbst hosten mit Node.js. Jedoch ist Vercel vom Next.js-Team gebaut, und die Integration zeigt sich — ISR, Edge Middleware, Bildoptimierung und Analytics funktionieren alle am besten auf Vercel. Der DX-Abstand zwischen Vercel und Alternativen hat sich 2026 verringert, aber Vercel bleibt der Weg des geringsten Widerstands.

Was ist, wenn ich einen WooCommerce-Store migrieren muss? Das ist ein größeres Projekt. Die meisten Teams migrieren die Storefront zu Next.js, während sie das Commerce-Backend zu Shopify (mit Storefront API), Medusa.js oder Saleor verschieben. Das Hydrogen-Framework von Shopify ist eine weitere Option, aber wenn du volle Kontrolle über das Frontend möchtest, ist Next.js mit Shopifys API der bewährtest Pfad. Erwarte, dass die E-Commerce-Migration 4-8 Wochen zu deiner Timeline hinzufügt.