Wenn Sie einen Food-Blog auf WordPress betreiben, kennen Sie das Procedere bereits. Sie haben Mediavine- oder AdThrive-Anzeigen, ein Rezeptkarten-Plugin wie WP Recipe Maker oder Tasty Recipes, vielleicht 800+ Posts mit strukturierten Daten, und eine Website, die trotz Ihrer besten Bemühungen mit Caching-Plugins nur 34 Punkte bei Mobile PageSpeed Insights erreicht. Ihnen wurde etwa fünfzig Mal gesagt, Sie sollten "einfach Ihre Bilder optimieren". Unterdessen sabotieren Ihre Core Web Vitals Ihre Suchplatzierungen, und jedes neue Plugin-Update fühlt sich wie Roulette mit Ihrem Layout an.

Ich habe in den letzten zwei Jahren mehrere Rezeptblogs von WordPress zu Next.js migriert, und die Ergebnisse waren durchweg dramatisch: 2-3x schnellere Seitenladezeiten, perfekte Lighthouse-Scores und – was am wichtigsten ist – Traffic, der tatsächlich wächst, weil Google die Leistung belohnt. Aber die Migration ist nicht trivial. Rezeptblogs haben einzigartige Herausforderungen, die ein Standard-WordPress-zu-Next.js-Migrationsleitfaden nicht abdeckt. Dieser Artikel führt Sie durch den gesamten Prozess, von der Datenextraktion bis zum Rezept-Schema bis zur Anzeigenintegration.

Inhaltsverzeichnis

Migrieren Sie Ihren WordPress-Rezeptblog zu Next.js: Ein praktischer Leitfaden

Warum Food-Blogger WordPress verlassen

Seien wir ehrlich darüber, was passiert. WordPress selbst ist nicht das Problem – es ist das, was Rezeptblogging auf WordPress geworden ist. Eine typische Food-Blog-WordPress-Installation sieht etwa so aus:

  • Ein Premium-Theme (oft Flavor, Flavor Pro oder ein auf Flavor basierendes Child Theme)
  • WP Recipe Maker oder Tasty Recipes für Rezeptkarten
  • Ein Anzeigenverwaltungs-Plugin (oder Mediavine/AdThrive Script-Injection)
  • Ein Caching-Plugin (WP Rocket, W3 Total Cache oder LiteSpeed)
  • Ein Bildoptimierungs-Plugin (ShortPixel, Imagify oder EWWW)
  • Yoast SEO oder Rank Math
  • Social-Sharing-Plugins
  • Ein E-Mail-Opt-in-Plugin
  • Jump-to-Recipe-Button-Plugin
  • Druckerfreundliches Rezept-Plugin

Das sind mehr als 10 Plugins, bevor Sie überhaupt anfangen zu schreiben. Jedes fügt JavaScript, CSS, Datenbankabfragen und mögliche Konflikte hinzu. Das Ergebnis? Eine Seite, die 3-4 MB Assets lädt und auf Mobilgeräten 6-8 Sekunden benötigt, um interaktiv zu werden.

Google hat seit den Core Updates 2024 unmissverständlich gemacht, dass Page Experience wichtiger ist denn je. Rezeptsuchen sind extrem umkämpft – Sie konkurrieren mit Hunderten von anderen Blogs um Featured Snippets und Rezept-Karusselle. Wenn Ihre Website langsam ist, verlieren Sie.

Die echten Kosten der Plugin-Abhängigkeit

Hier ist etwas, das nicht genug diskutiert wird: Sie besitzen nicht das Rezeptdatenformat. Wenn Sie WP Recipe Maker verwenden, werden Ihre Rezepte in benutzerdefinierten Post-Typen und benutzerdefinierten Feldern gespeichert, die proprietär für das Plugin sind. Wenn das Plugin aufgegeben, erworben oder mit Breaking Changes aktualisiert wird, sind Sie festgefahren. Ich habe gesehen, dass das passiert ist. Tasty Recipes wurde von WP Tasty erworben, die Preise änderten sich, Features verschoben sich. Ihr Inhalt ist in der Datenstruktur von jemandem anderem eingesperrt.

Bei einem Headless-Ansatz lebt Ihre Rezeptdatei in einem strukturierten, tragbaren Format, das Sie kontrollieren.

Was Sie tatsächlich migrieren

Bevor Sie Code anfassen, benötigen Sie einen Bestand. Rezeptblog-Migrationen sind komplexer als Standard-Blog-Migrationen wegen der beteiligten Daten:

Inhaltstyp WordPress-Quelle Migrations-Komplexität
Blog-Beiträge (Erzählung) wp_posts Niedrig
Rezeptdaten (Zutaten, Schritte, Zeiten) Plugin benutzerdefinierte Felder Hoch
Rezeptbilder (Hero, Schritt-für-Schritt) wp_uploads + postmeta Mittel
Strukturierte Daten (JSON-LD) Plugin-generiert Hoch (muss neu erstellt werden)
Kategorien/Tags wp_terms Niedrig
Kommentare wp_comments Mittel
Interne Links Post-Inhalt Mittel
URL-Struktur Permalinks Kritisch
Anzeigenplatzierungen Plugin/Theme-Hooks Mittel
E-Mail-Anmelde-Formulare Plugin-Shortcodes Niedrig

Die Rezeptdaten sind der schwierige Teil. Alles andere ist Standard-WordPress-Migrations-Territorium.

Architektur wählen

Sie haben hier ein paar Pfade, und der richtige hängt von Ihrem technischen Komfort und Budget ab.

Option A: Next.js + Headless WordPress

Behalten Sie WordPress als Ihr CMS, nutzen Sie es aber rein als Content-Backend über die REST API oder WPGraphQL. Ihr Next.js-Frontend ruft Daten von WordPress zur Build-Zeit oder bei Anforderung ab.

Vorteile: Sie behalten den WordPress-Editor. Ihre Autoren müssen nichts Neues lernen. WP Recipe Maker-Daten sind über API zugänglich.

Nachteile: Sie müssen immer noch eine WordPress-Installation pflegen. Sie zahlen immer noch für das Hosting. Die REST API kann bei komplexen Rezeptabfragen langsam sein.

Option B: Next.js + Modernes Headless CMS

Migrieren Sie alles aus WordPress in ein zweckgerichtetes Headless CMS wie Sanity, Contentful oder Payload CMS. Erstellen Sie Ihr Frontend in Next.js.

Vorteile: Sauberer Bruch. Bessere Content-Modellierung für Rezepte. Keine WordPress-Wartung. Schnellere API-Antworten.

Nachteile: Größere anfängliche Migrationsanstrengung. Content-Editoren müssen ein neues CMS lernen. Die Kosten variieren je nach CMS-Wahl.

Option C: Next.js + Markdown/MDX

Für kleinere Blogs (unter 200 Beiträgen) können Sie alles in MDX-Dateien exportieren und vollständig statisch werden.

Vorteile: Null CMS-Kosten. Blitzschnell. Alles in der Versionskontrolle.

Nachteile: Skaliert nicht gut. Nicht-technische Editoren können es nicht verwenden. Keine Echtzeit-Vorschau.

Für die meisten Food-Blogger mit 200+ Rezepten empfehle ich Option B mit Sanity als CMS. Die Content-Modellierungs-Flexibilität ist perfekt für Rezepte, die Bearbeitungserfahrung ist großartig für Nicht-Entwickler, und die Preisgestaltung ist angemessen (kostenlos Tier deckt die meisten Food-Blogs ab). Wir haben mehrere solcher Setups durch unsere Headless-CMS-Entwicklung erstellt, und die Ergebnisse sprechen für sich.

Migrieren Sie Ihren WordPress-Rezeptblog zu Next.js: Ein praktischer Leitfaden - Architektur

Rezeptdaten aus WordPress extrahieren

Hier wird es interessant. Rezept-Plugins speichern Daten unterschiedlich, daher müssen Sie genau wissen, womit Sie arbeiten.

WP Recipe Maker Export

WP Recipe Maker speichert Rezepte als benutzerdefinierten Post-Typ (wprm_recipe) mit Daten in wp_postmeta. Sie können exportieren über:

  1. WP Recipe Makers integrierter Export – gibt Ihnen eine JSON-Datei, aber in ihrem proprietären Format
  2. WPGraphQL + WP Recipe Maker-Erweiterung – Rezeptdaten über GraphQL abfragen
  3. Direkter Datenbankexport – schreiben Sie ein benutzerdefiniertes Skript, das die Datenbank direkt abfragt

Hier ist ein Node.js-Skript, das ich verwende, um WP Recipe Maker JSON-Exporte in ein sauberes Format zu transformieren:

const fs = require('fs');
const wprmData = JSON.parse(fs.readFileSync('./wprm-export.json', 'utf8'));

const recipes = wprmData.map((recipe) => ({
  title: recipe.name,
  slug: recipe.slug,
  summary: recipe.summary,
  prepTime: recipe.prep_time, // in Minuten
  cookTime: recipe.cook_time,
  totalTime: recipe.total_time,
  servings: recipe.servings,
  servingsUnit: recipe.servings_unit,
  ingredients: recipe.ingredients.map((group) => ({
    groupName: group.name || 'Main',
    items: group.ingredients.map((ing) => ({
      amount: ing.amount,
      unit: ing.unit,
      name: ing.name,
      notes: ing.notes,
    })),
  })),
  instructions: recipe.instructions.map((group) => ({
    groupName: group.name || 'Anweisungen',
    steps: group.instructions.map((step) => ({
      text: step.text,
      image: step.image ? extractImageUrl(step.image) : null,
    })),
  })),
  nutrition: recipe.nutrition,
  notes: recipe.notes,
  video: recipe.video,
}));

fs.writeFileSync(
  './recipes-clean.json',
  JSON.stringify(recipes, null, 2)
);

Tasty Recipes Export

Tasty Recipes speichert Daten anders – es verwendet eine benutzerdefinierte Tabelle (wp_tasty_recipes) statt postmeta. Sie benötigen direkten Datenbankzugriff:

SELECT
  r.id,
  r.post_id,
  r.title,
  r.description,
  r.prep_time,
  r.cook_time,
  r.total_time,
  r.yield,
  r.ingredients,
  r.instructions,
  r.notes,
  r.nutrition
FROM wp_tasty_recipes r
JOIN wp_posts p ON r.post_id = p.ID
WHERE p.post_status = 'publish';

Die ingredients- und instructions-Felder werden als HTML-Strings gespeichert, daher müssen Sie sie in strukturierte Daten analysieren. Ich verwende cheerio dafür:

const cheerio = require('cheerio');

function parseIngredients(html) {
  const $ = cheerio.load(html);
  const groups = [];
  let currentGroup = { name: 'Main', items: [] };

  $('li, h4, strong').each((_, el) => {
    if (el.tagName === 'h4' || (el.tagName === 'strong' && $(el).parent().is('p'))) {
      if (currentGroup.items.length > 0) groups.push(currentGroup);
      currentGroup = { name: $(el).text().trim(), items: [] };
    } else if (el.tagName === 'li') {
      currentGroup.items.push(parseIngredientLine($(el).text().trim()));
    }
  });

  if (currentGroup.items.length > 0) groups.push(currentGroup);
  return groups;
}

Next.js-Rezeptblog einrichten

Mit Next.js 15 (der aktuellen stabilen Version im Jahr 2026) haben Sie hervorragende Optionen für Rendering-Strategien. Für einen Rezeptblog empfehle ich einen hybriden Ansatz:

  • Statische Generierung (SSG) für alle Rezeptseiten – sie ändern sich nicht oft
  • ISR (Inkrementelle Statische Regeneration) mit 1-Stunden-Revalidierung für Kategorie-/Tag-Seiten
  • Server Components für das Layout und die Navigation
npx create-next-app@latest my-recipe-blog --typescript --tailwind --app

Hier ist eine grundlegende Rezeptseiten-Struktur:

// app/recipes/[slug]/page.tsx
import { getRecipeBySlug, getAllRecipeSlugs } from '@/lib/recipes';
import { RecipeCard } from '@/components/RecipeCard';
import { RecipeJsonLd } from '@/components/RecipeJsonLd';
import { notFound } from 'next/navigation';

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

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const recipe = await getRecipeBySlug(params.slug);
  if (!recipe) return {};

  return {
    title: `${recipe.title} | Mein Rezeptblog`,
    description: recipe.summary.slice(0, 155),
    openGraph: {
      images: [{ url: recipe.heroImage.url, width: 1200, height: 630 }],
    },
  };
}

export default async function RecipePage({ params }: { params: { slug: string } }) {
  const recipe = await getRecipeBySlug(params.slug);
  if (!recipe) notFound();

  return (
    <article>
      <RecipeJsonLd recipe={recipe} />
      {/* Narrative-Inhalt (der Blog-Post-Teil) */}
      <div className="prose lg:prose-xl" dangerouslySetInnerHTML={{ __html: recipe.narrativeContent }} />
      {/* Die tatsächliche Rezeptkarte */}
      <RecipeCard recipe={recipe} />
    </article>
  );
}

Wenn Sie neu in Next.js-Entwicklung sind oder professionelle Hilfe bei der Migration benötigen, schauen Sie sich unsere Next.js-Entwicklungsfähigkeiten an.

Rezept-Komponenten mit strukturierten Daten erstellen

Strukturierte Daten sind für Rezeptblogs unverzichtbar. Ohne gültiges Recipe-Schema-Markup erscheinen Sie nicht in Googles Rezept-Karussell, Rich Snippets oder Google Discover. Hier gehen viele Migrationen schief – Menschen vergessen, die strukturierten Daten, die WP Recipe Maker automatisch generiert hat, neu zu erstellen.

Hier ist eine Komponente, die gültiges JSON-LD für Rezepte generiert:

// components/RecipeJsonLd.tsx
import type { Recipe } from '@/types/recipe';

export function RecipeJsonLd({ recipe }: { recipe: Recipe }) {
  const jsonLd = {
    '@context': 'https://schema.org/',
    '@type': 'Recipe',
    name: recipe.title,
    image: recipe.images.map((img) => img.url),
    author: {
      '@type': 'Person',
      name: recipe.author.name,
    },
    datePublished: recipe.publishedAt,
    description: recipe.summary,
    prepTime: `PT${recipe.prepTime}M`,
    cookTime: `PT${recipe.cookTime}M`,
    totalTime: `PT${recipe.totalTime}M`,
    recipeYield: `${recipe.servings} ${recipe.servingsUnit}`,
    recipeCategory: recipe.category,
    recipeCuisine: recipe.cuisine,
    recipeIngredient: recipe.ingredients.flatMap((group) =>
      group.items.map((ing) =>
        `${ing.amount} ${ing.unit} ${ing.name}${ing.notes ? ` (${ing.notes})` : ''}`
      )
    ),
    recipeInstructions: recipe.instructions.flatMap((group) =>
      group.steps.map((step, i) => ({
        '@type': 'HowToStep',
        name: `Schritt ${i + 1}`,
        text: step.text,
        ...(step.image && { image: step.image.url }),
      }))
    ),
    ...(recipe.nutrition && {
      nutrition: {
        '@type': 'NutritionInformation',
        calories: recipe.nutrition.calories,
        fatContent: recipe.nutrition.fat,
        proteinContent: recipe.nutrition.protein,
        carbohydrateContent: recipe.nutrition.carbs,
      },
    }),
    ...(recipe.video && {
      video: {
        '@type': 'VideoObject',
        name: recipe.video.title,
        description: recipe.video.description,
        thumbnailUrl: recipe.video.thumbnail,
        contentUrl: recipe.video.url,
        uploadDate: recipe.video.uploadDate,
      },
    }),
  };

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

Validieren Sie Ihre strukturierten Daten mit Google's Rich Results Test nach jeder Änderung. Nehmen Sie nicht an, dass es korrekt ist, weil es richtig aussieht.

Bilder und Medien verwalten

Food-Blogs sind bildintensiv. Ein einzelner Rezeptbeitrag könnte 15-25 Bilder haben. Dies ist eigentlich der Bereich, in dem Next.js am hellsten glänzt – die integrierte next/image-Komponente behandelt responsive Größenänderung, Formatkonvertierung (WebP/AVIF) und Lazy Loading automatisch.

Aber Sie benötigen eine Strategie für Ihre bestehenden Bilder:

  1. Exportieren Sie alle Bilder aus wp-content/uploads/ – normalerweise organisiert nach Jahr/Monat
  2. Laden Sie in ein CDN oder Cloud-Speicher hoch – Cloudinary, Vercel Blob Storage oder AWS S3 + CloudFront
  3. Aktualisieren Sie alle Bildreferenzen in Ihrem Inhalt, um auf die neuen URLs zu zeigen

Ich empfehle Cloudinary dringend für Food-Blogs. Die Transformations-API ermöglicht es Ihnen, optimierte Bilder im Handumdrehen bereitzustellen, und sie haben einen großzügigen kostenlosen Tier (25 Credits/Monat, was die meisten Food-Blogs abdeckt). Außerdem ist ihr Auto-Cropping intelligent genug, um das Essen zentriert zu halten – was wichtiger ist, als Sie denken.

// lib/cloudinary.ts
export function getRecipeImageUrl(
  publicId: string,
  width: number = 800,
  height: number = 600
) {
  return `https://res.cloudinary.com/${process.env.CLOUDINARY_CLOUD}/image/upload/c_fill,w_${width},h_${height},f_auto,q_auto/${publicId}`;
}

SEO-Migrations-Checkliste

Dies ist der Teil, der Food-Blogger nachts wach hält, und das ist zu Recht. Eine verpfuschte Migration kann Ihren organischen Traffic für Monate sabotieren. Folgen Sie dieser Checkliste religiös:

Aufgabe Priorität Details
URL-Zuordnung Kritisch Erstellen Sie eine vollständige 1:1-Zuordnung alter URLs zu neuen URLs
301 Weiterleitungen Kritisch Leiten Sie jede alte URL weiter. Jede. Einzelne.
XML-Sitemap Kritisch Generieren Sie und reichen Sie sie bei Google Search Console ein
Validierung strukturierter Daten Kritisch Testen Sie jede Rezeptseite mit Rich Results Test
Canonical-Tags Hoch Stellen Sie sicher, dass jede Seite ein selbstreferenzierendes Canonical hat
Audit interner Links Hoch Aktualisieren Sie alle internen Links im Post-Inhalt
Bild-Alt-Text Hoch Bewahren Sie den gesamten vorhandenen Alt-Text während der Migration
Meta-Beschreibungen Mittel Migrieren oder verbessern Sie vorhandene Meta-Beschreibungen
robots.txt Mittel Aktualisieren Sie und verifizieren Sie
Social-Meta-Tags Mittel OpenGraph und Twitter-Karten für jedes Rezept
Google Search Console Hoch Verifizieren Sie die neue Eigenschaft, reichen Sie die Sitemap ein, überwachen Sie
Analytik Hoch Richten Sie GA4 mit richtigem Event-Tracking ein

Das URL-Problem

WordPress Food-Blogs verwenden normalerweise Strukturen wie /recipe-name/ oder /category/recipe-name/. Wie immer Ihre aktuelle Struktur auch ist, behalten Sie sie. Werden Sie nicht clever und ändern Sie URL-Muster während der Migration. Wenn Ihre URLs derzeit wie example.com/easy-chicken-tikka-masala/ aussehen, sollten Ihre neuen Next.js-URLs identisch sein.

In Ihrem next.config.js richten Sie Umleitungen für beliebige URLs ein, die sich ändern müssen:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Beispiel: Kategorie-Seiten-URL-Änderung
      {
        source: '/category/:slug',
        destination: '/recipes/:slug',
        permanent: true,
      },
      // WordPress-Paginierung
      {
        source: '/page/:num',
        destination: '/?page=:num',
        permanent: true,
      },
    ];
  },
};

Anzeigennetzwerk-Integration

Lassen Sie uns über den Elefanten im Zimmer sprechen. Die meisten Food-Blogger verdienen ihr Geld mit Display-Anzeigen von Mediavine, Raptive (ehemals AdThrive) oder ähnlichen Netzwerken. Diese Ad-Netzwerke wurden für WordPress entwickelt, und die Migration zu einem JavaScript-Framework fügt Komplexität hinzu.

Mediavine auf Next.js

Mediavine veröffentlichte ihren Universal Player und unterstützt Non-WordPress-Sites, aber Sie müssen:

  1. Kontaktieren Sie Ihren Mediavine-Vertreter vor der Migration, um ihn zu informieren
  2. Fügen Sie das Mediavine-Skript-Wrapper zu Ihrem app/layout.tsx hinzu
  3. Erstellen Sie Anzeigenplatzierungs-Komponenten, die ihre Anforderungen beachten
  4. Testen Sie ausgiebig in ihrer Staging-Umgebung
// components/AdPlacement.tsx
'use client';

import { useEffect, useRef } from 'react';

export function AdPlacement({ id }: { id: string }) {
  const adRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    // Mediavine füllt diese divs dynamisch auf
    if (window.__mediavine_ad_settings) {
      window.__mediavine_ad_settings.refreshAd(id);
    }
  }, [id]);

  return <div ref={adRef} id={id} data-mediavine-ad="" />;
}

Wichtig: Sprechen Sie mit Ihrem Ad-Netzwerk. Einige haben spezifische technische Anforderungen für SPAs (Single-Page Applications). Das Mediavine-Team war in meiner Erfahrung hilfreich, aber Sie müssen kommunizieren, was Sie tun.

Raptive (AdThrive) Überlegungen

Raptive war langsamer, Headless-Setups zu unterstützen. Ab Anfang 2026 unterstützen sie benutzerdefinierte Implementierungen, erfordern aber eine technische Überprüfung. Budget 2-4 Wochen für ihren Genehmigungsprozess.

Performance-Benchmarks: Vorher und Nachher

Hier sind echte Daten aus drei Rezeptblog-Migrationen, die ich zwischen 2025 und 2026 durchgeführt habe:

Metrik WordPress (Durchschn.) Next.js (Durchschn.) Verbesserung
Lighthouse Performance (Mobil) 31 94 +203%
Größtes zufriedenstellendes Gemälde 4,8s 1,2s -75%
Gesamte blockierende Zeit 1.850ms 45ms -97%
Kumulativer Layout-Shift 0,35 0,02 -94%
Seitengröße 3,8 MB 420 KB -89%
Zeit zum Interaktiv 8,2s 1,8s -78%
Core Web Vitals Pass-Rate 22% der Seiten 98% der Seiten +345%

Diese Zahlen sind nicht handverlesen. Sie sind Durchschnittswerte über Blogs mit 400-1200 veröffentlichten Rezepten, beide Versionen mit Mediavine-Anzeigen laufend. Die Next.js-Versionen wurden auf Vercel bereitgestellt.

Die Traffic-Auswirkung? Ein Blog sah innerhalb von 3 Monaten nach der Migration eine 47%ige Steigerung des organischen Such-Traffics, hauptsächlich durch verbesserte Rezept-Karussell-Erscheinungen und bessere mobile Rankings.

Headless CMS für Rezeptinhalte wählen

Wenn Sie die Headless-CMS-Route (Option B von früher) gehen, ist Ihre CMS-Wahl für Rezeptinhalte sehr wichtig.

CMS Rezept-Content-Modellierung Editor-Erfahrung Preisgestaltung (2026) Am besten für
Sanity Ausgezeichnet (benutzerdefinierte Schemas) Großartig Kostenlos bis zu 100K API-Anfragen Vollständige Kontrolle über Rezeptstruktur
Contentful Gut (strukturierte Content-Typen) Gut Kostenlos bis zu 1M API-Aufrufe Etablierte Workflows
Payload CMS Ausgezeichnet (selbstgehostet) Großartig Kostenlos (Open Source) Entwickler, die vollständiges Eigentum wollen
Strapi Gut (benutzerdefinierte Content-Typen) Anständig Kostenlos (selbstgehostet) / Cloud ab $29/Mo Budget-bewusste Migrationen
WordPress (Headless) Erbt bestehende Vertraut Bestehende Hosting-Kosten Minimale Editor-Disruption

Sanity ist meine Top-Wahl für Rezeptblogs. Das benutzerdefinierte Schema-System ermöglicht es Ihnen, Rezepte genau so zu modellieren, wie Sie möchten, einschließlich Zutatensgruppen, Schritt-Fotos, Nährwertdaten und Ausrüstungslisten. Der Portable Text Editor ist flexibel genug für den narrativen Blog-Post-Inhalt, und die Bild-Pipeline verarbeitet Transformationen nativ.

Wir haben ziemlich viele Sanity-betriebene Rezeptsites eingerichtet. Wenn Sie diese Route erkunden möchten, schauen Sie sich unsere Headless-CMS-Entwicklungsdienste an oder kontaktieren Sie uns, um Ihre spezifische Situation zu diskutieren.

Häufig gestellte Fragen

Werde ich meine Google-Rankings verlieren, wenn ich von WordPress zu Next.js migriere? Nein, wenn Sie es richtig machen. Der Schlüssel ist die Aufrechterhaltung der URL-Parität (gleiche URLs), die Implementierung geeigneter 301-Umleitungen für beliebige URLs, die sich ändern müssen, und die Bewahrung Ihrer strukturierten Daten. John Mueller von Google hat wiederholt gesagt, dass der Wechsel Ihres CMS Ihre Rankings nicht beeinflussen sollte, wenn der Inhalt und die URLs gleich bleiben. In der Praxis habe ich vorübergehende Schwankungen (1-2 Wochen) gesehen, gefolgt von Verbesserungen aufgrund besserer Core Web Vitals.

Kann ich WP Recipe Maker immer noch mit einer Headless-WordPress-Einrichtung verwenden? Ja. WP Recipe Maker stellt Rezeptdaten über die WordPress REST API bereit. Sie greifen auf Rezeptfelder als Teil des Post-Objekts zu. Allerdings sind Sie immer noch dafür verantwortlich, die Rezeptkarte zu rendern und strukturierte Daten auf der Next.js-Seite zu generieren – das Plugin bietet nur die Rohdaten, nicht die Frontend-Ausgabe.

Wie viel kostet es, einen Rezeptblog von WordPress zu Next.js zu migrieren? Es variiert wild je nach Komplexität. Ein 200-Rezept-Blog mit einfachem Design könnte $5.000-$10.000 für eine professionelle Migration kosten. Ein 1000+ Rezept-Blog mit benutzerdefinierten Funktionen, Ad-Integration und komplexem Design könnte $15.000-$30.000+ laufen. Schauen Sie sich unsere Preisseite für Besonderheiten zu Headless-Migrationsprojekten an. DIY ist möglich, wenn Sie technisch versiert sind, aber budget 2-4 Monate Teilzeitarbeit.

Was ist mit meinen WordPress-Kommentaren? Kann ich die migrieren? Sie können. Exportieren Sie sie über die WordPress REST API oder WP-CLI, und importieren Sie sie dann entweder in Ihr Headless CMS oder wechseln Sie zu einem Drittanbieter-Kommentarsystem wie Disqus, Commento oder Giscus. Ehrlich gesagt nutzen die meisten Food-Blogger, mit denen ich gearbeitet habe, die Migration als Gelegenheit, Kommentare ganz zu lassen oder zu einem einfacheren System zu wechseln. Kommentarabschnitte auf Rezeptblogs sind meistens "Kann ich X durch Y ersetzen?", was besser durch einen strukturierten FAQ-Bereich auf jedem Rezept bedient werden könnte.

Funktioniert Mediavine und Raptive mit Next.js? Mediavine unterstützt offiziell Non-WordPress-Sites und hat Dokumentation für JavaScript-Framework-Integration. Raptive unterstützt benutzerdefinierte Implementierungen, erfordert aber eine technische Überprüfung. Beide benötigen benutzerdefinierte Integrationsarbeit – Sie können einfach kein Plugin installieren. Kontaktieren Sie Ihren Ad-Network-Vertreter, bevor Sie die Migration starten, damit er Sie zu Anforderungen führen kann.

Sollte ich Next.js oder Astro für meinen Rezeptblog verwenden? Beide sind großartige Wahlen. Astro ist möglicherweise eine bessere Passung für inhaltsreiche Websites, die nicht viel Interaktivität benötigen – es versendet standardmäßig null JavaScript. Next.js gibt Ihnen mehr Flexibilität für interaktive Funktionen (Rezeptskalierung, Einheitskonvertierung, Einkaufslistengenerierung) und hat ein größeres Ökosystem. Wenn Ihr Blog hauptsächlich statischer Inhalt mit Rezepten ist, ist Astro es wert, in Betracht gezogen zu werden. Wir bieten auch Astro-Entwicklung an, wenn Sie diese Route erkunden möchten.

Wie behandle ich Rezept-Druckfunktionalität ohne ein WordPress-Plugin? Erstellen Sie ein Print-Stylesheet und eine Print-spezifische Komponente. Es ist eigentlich einfacher, als Sie denken würden, in Next.js, weil Sie vollständige Kontrolle über das Markup haben. Verwenden Sie CSS @media print-Regeln, um Navigation, Anzeigen und Narrative-Inhalte auszublenden, die nur die Rezeptkarte zeigen. Sie können auch eine dedizierte /recipes/[slug]/print-Route erstellen, die eine saubere, druckoptimierte Version rendert.

Was ist mit Rezept-Skalierung und Einheitskonvertierungs-Funktionen? Dies ist, wo Next.js wirklich gegenüber WordPress glänzt. Erstellen Sie eine Client-Komponente, die die Basis-Zutatengaben nimmt und sie basierend auf einem Portionen-Selektor multipliziert. Für die Einheitskonvertierung (US bis Metrik) erstellen Sie eine Utility-Funktion, die gängige Kochmaße zuordnet. Diese interaktiven Funktionen sind in React trivial, erforderten aber umfangreiche jQuery-Plugins auf WordPress. Speichern Sie Zutatengaben als strukturierte Daten (separate amount-, unit- und name-Felder) statt einfache Textzeichenfolgen – dies macht programmgesteuerte Bearbeitung möglich.