wordpress

Rezeptmigration konkret: Was bei einer Rezept-Migration wirklich passiert

Du denkst über eine Rezept-Migration nach. Vielleicht stecken deine 200 Rezepte in WP Recipe Maker, und du willst weg vom Plugin. Vielleicht hat Tasty Recipes mal wieder sein Preismodell geändert, und du fragst dich, ob das so weitergehen soll. Oder du planst den Wechsel auf eine komplett andere Plattform.

Die Frage, die alle umtreibt: Was passiert da eigentlich? Wie aufwendig ist das? Und was kann schiefgehen?

Wir migrieren Rezept-Blogs. Das ist ein wesentlicher Teil unserer Arbeit. Und weil „wir kümmern uns um alles” als Antwort unbefriedigend ist, legen wir den Prozess offen. Sechs Phasen, jede mit einem konkreten Ergebnis.

Warum Rezepte keine normalen Blogposts sind

Ein Reisebericht ist ein Textblock mit Bildern. Ein Rezept ist ein Datensatz.

Zutaten mit Mengenangaben und Einheiten. Zubereitungsschritte in fester Reihenfolge. Zeiten — Vorbereitung, Kochen, Gesamt. Portionsgrößen. Nährwertangaben. Schwierigkeitsgrad. Küche. Ernährungsform. Und dann: Schrittfotos, Galeriebilder, ein Hauptbild fürs Schema-Markup.

Dazu kommen die Dinge, die man leicht vergisst: Kommentare, die Leser über Jahre zu den Rezepten hinterlassen haben — Fragen, Tipps, Variationen. Und Bewertungen — die Sternchen, die dein Rezept in den Google-Suchergebnissen so gut aussehen lassen.

Das alles steckt bei den meisten Foodblogs nicht in WordPress-Standard-Tabellen, sondern in proprietären Plugin-Datenbanken. wp_wprm_recipes, wp_wprm_ingredients, wp_wprm_ratings — Tabellen, die es nur gibt, weil WP Recipe Maker sie angelegt hat. Deaktivierst du das Plugin, sind die Daten unsichtbar. Nicht weg, aber unsichtbar.

Eine Migration muss all das extrahieren, transformieren und in ein neues Format überführen. Das ist kein Copy-Paste-Job. Das ist ein Datenprojekt.

Phase 1: Entscheidung und Ziele

Bevor irgendjemand irgendwas exportiert, klären wir drei Fragen.

Wohin soll es gehen? Plugin-Wechsel innerhalb von WordPress? Von einem Plugin zu nativen Theme-Feldern? Oder komplett raus aus WordPress — zu einem statischen Setup, Next.js oder einem anderen System?

Was ist der Bestand? Welches Plugin ist aktuell im Einsatz? Wie viele Rezepte existieren? Welche Felder sind tatsächlich befüllt — und welche stehen leer? Wie viele Kommentare und Bewertungen gibt es, und wo genau liegen die Daten?

Was ist das Ziel? Sollen alle Rezepte übernommen werden oder nur die mit Traffic? Sollen Kommentare komplett mit, oder reicht eine bereinigte Auswahl? Müssen alle alten URLs erhalten bleiben?

Am Ende dieser Phase liegt ein Migrationsplan auf dem Tisch. Umfang, Prioritäten, erwartete Stolperstellen — alles dokumentiert, bevor die erste Zeile Code geschrieben wird.

Phase 2: Content Download

Jetzt wird es technisch. Wir extrahieren alles, was dein Blog an Rezeptdaten enthält.

Rezeptdaten. Standard-Exports der Plugins reichen fast nie. WP Recipe Maker exportiert zwar ein JSON, aber ohne Bilder, ohne Kommentar-Zuordnungen und ohne die Verknüpfung Rezept-zu-Beitrag. Also schreiben wir eigene Export-Skripte, die direkt auf die Datenbank zugreifen.

Zutaten-Parsing. „200g Mehl” klingt simpel, aber die Plugins speichern das unterschiedlich. Manche trennen Menge, Einheit und Zutat sauber in drei Felder. Andere packen alles in einen String. Wir parsen das so, dass am Ende strukturierte Daten rauskommen — egal wie das Quell-Plugin die Daten intern organisiert.

Bilder. Hauptbilder, Schrittfotos, Galeriebilder. Wir sichern nicht nur die Dateien, sondern auch die Zuordnung: Welches Bild gehört zu welchem Schritt, welches ist das Featured Image, welches wird fürs Schema-Markup verwendet.

Kommentare. WordPress speichert Kommentare standardmäßig in wp_comments — die gehören nicht dem Plugin. Aber die Zuordnung zum richtigen Rezept und die Thread-Struktur (wer hat auf wen geantwortet) müssen erhalten bleiben. Bei manchen Setups liegen auch Kommentare in Plugin-Tabellen, etwa wenn ein Rezept-spezifisches Kommentarfeld verwendet wurde.

Bewertungen. Die Sterne, die Leser deinen Rezepten geben, liegen fast nie in WordPress-Standard-Tabellen. WP Recipe Maker hat wp_wprm_ratings, Tasty Recipes speichert Bewertungen in Post-Meta-Feldern, andere Plugins haben eigene Lösungen. Wir extrahieren sowohl die Einzelbewertungen als auch die aggregierten Durchschnittswerte.

Phase 3: Content-Aufbereitung

Rohdaten sind noch keine fertigen Inhalte. In dieser Phase transformieren wir alles fürs Zielsystem.

Feld-Mapping. Jedes Plugin hat ein anderes Datenmodell. WP Recipe Maker strukturiert Zutaten in Gruppen mit Untergruppen. Tasty Recipes macht das anders. Wir mappen jedes Quell-Feld auf die Zielstruktur — ob das ein anderes Plugin ist, native Theme-Felder oder ein komplett anderes System.

Zutaten normalisieren. „Tomaten”, „Tomate”, „frische Tomaten”, „Tomaten (geschält)” — vier Einträge, die dasselbe meinen. Für eine saubere Filterung und Suche auf der neuen Plattform braucht es einheitliche Schreibweisen.

Bilder optimieren. Neue Formate (WebP), passende Größen für responsive Darstellung, fehlende Alt-Texte ergänzen. Bilder machen oft 80 Prozent des Transfervolumens aus — hier lohnt sich Sorgfalt.

Kommentare bereinigen. Spam rausfiltern, Kommentar-Autor-Zuordnungen prüfen, die Thread-Struktur (Antworten auf Antworten) korrekt ins Zielformat übertragen. Ein Kommentar-Thread mit 30 Beiträgen, bei dem die Hälfte Spam ist und die Einrückungen nicht stimmen, schadet mehr als er nutzt.

Bewertungen aggregieren. Einzelbewertungen und Durchschnittswerte ins Zielformat überführen. Besonders wichtig: das Schema.org-AggregateRating korrekt aufbauen, damit Google die Sterne weiterhin in den Suchergebnissen anzeigt. 4,7 Sterne bei 89 Bewertungen — das muss nach der Migration exakt stimmen.

Schema.org-Markup. JSON-LD für jedes Rezept vorbereiten — mit allen Pflichtfeldern (name, image, recipeIngredient, recipeInstructions) und den Bewertungsdaten. Das Markup entscheidet, ob Google dein Rezept als Rich Result anzeigt oder als normalen Link.

URL-Mapping. Alte URLs zu neuen URLs zuordnen, damit wir in Phase 6 saubere 301-Redirects setzen können.

Rezeptdaten-Fluss: Vom Plugin zum neuen System

1
Rezept-Plugin
Proprietäre Datenbank
  • WP Recipe Maker
  • Tasty Recipes
  • Recipe Card Blocks
2
Export
Eigene Skripte + API
  • Rezeptdaten
  • Bilder + Zuordnung
  • Kommentare + Bewertungen
3
Zwischenformat
Normalisierte Struktur
  • Einheitliche Felder
  • Bereinigte Zutaten
  • Schema.org-Markup
4
Neues System
Natives Format
  • Theme-eigene Felder
  • Optimierte Bilder
  • Saubere Bewertungen

Phase 4: Content Upload

Die aufbereiteten Daten gehen in die Staging-Umgebung — eine Kopie der Zielplattform, die noch nicht öffentlich ist.

Import. Jedes Rezept wird an den richtigen Beitrag gehängt. Die Verknüpfung Rezept-zu-Post muss stimmen, sonst erscheint das Lasagne-Rezept plötzlich unter dem Bananenbrot-Artikel. Das klingt trivial, ist es bei 200+ Rezepten aber nicht.

Taxonomien. Küche, Gang, Ernährungsform, Schwierigkeitsgrad — alle Zuordnungen werden im neuen System angelegt und den Rezepten zugewiesen.

Kommentare einspielen. Die bereinigten Kommentare werden mit korrekter Thread-Struktur und Zeitstempeln importiert. Wer auf wessen Kommentar geantwortet hat, muss auch nach der Migration sichtbar sein.

Bewertungen zuweisen. Einzelbewertungen werden den Rezepten zugeordnet, Durchschnittswerte geprüft. Das AggregateRating im Schema-Markup muss mit den tatsächlich importierten Bewertungen übereinstimmen.

Erste Sichtkontrolle. Sehen die Rezepte richtig aus? Stimmen die Bilder? Sind die Zutaten vollständig?

Phase 5: Content Test

Die Staging-Umgebung steht. Jetzt wird geprüft.

Schema.org-Validierung. Jedes Rezept durchläuft den Rich Results Test. Fehlt ein Pflichtfeld, erscheint das Rezept nicht als Rich Result bei Google — und damit verschwinden Sterne, Zubereitungszeit und Bild aus den Suchergebnissen.

Bewertungen prüfen. Stimmen die Durchschnittswerte? Wenn ein Rezept vorher 4,7 Sterne bei 89 Bewertungen hatte, muss das nach der Migration identisch sein. Google merkt Diskrepanzen zwischen angezeigten Sternen und Schema-Markup — und straft das ab.

Kommentare prüfen. Thread-Struktur intakt? Antworten richtig eingerückt? Kein Spam durchgerutscht? Bei einem Foodblog mit aktiver Community sind Kommentare echte Inhalte — Leser fragen nach Alternativen, teilen Variationen, geben Tipps. Das darf nicht verloren gehen.

Bilder und Schrittfotos. Korrekte Zuordnung, Qualität, Ladezeit. Ein Rezept mit vertauschten Schrittfotos ist schlimmer als eins ohne.

Staging-Zugang. Du bekommst Zugang zur Staging-Umgebung und prüfst deine Rezepte selbst. Niemand kennt deinen Content besser als du — wenn die Lasagne deiner Oma zwei Zutaten zu wenig hat, fällt dir das schneller auf als uns.

Phase 6: Live setzen und Babysitting

Alles geprüft, alles freigegeben. Jetzt wird umgeschaltet.

DNS und Redirects. Die neue Plattform geht live, alle alten URLs werden per 301-Redirect auf die neuen umgeleitet. Das ist nicht optional — ohne Redirects verlierst du deine Google-Rankings von heute auf morgen.

Google informieren. Neue Sitemap in der Search Console einreichen, Indexierung beantragen. Google braucht ein paar Tage, um die Änderungen zu verarbeiten.

30-Tage-Monitoring. Wir beobachten Rankings, Rich Snippets, Traffic. Erscheinen die Sterne noch? Werden die neuen URLs indexiert? Gibt es 404-Fehler, die wir übersehen haben?

Nacharbeit. Einzelne Rezepte, bei denen ein Bild fehlt oder eine Zutat falsch formatiert ist. Kommentare, die nach dem Stichtag noch auf der alten Plattform eingegangen sind. Bewertungen, die nachgereicht werden müssen. Diese Phase ist Pflicht, kein Nice-to-have.

Vorher vs. Nachher: Plugin-abhängig vs. nativ

Vorher: Plugin-abhängig
Rezepteinbindung
Shortcode im Beitrag
[wprm-recipe id="123"]
Datenspeicherung
Proprietäre Plugin-Tabellen
wp_wprm_recipes
wp_wprm_ingredients
Bewertungen
Plugin-eigene Rating-Tabelle
wp_wprm_ratings
Kommentare
Teils in wp_comments, teils im Plugin — fragmentiert
Risiko
Plugin-Update oder Deaktivierung = Rezepte unsichtbar
Nachher: Nativ
Rezepteinbindung
Eigener Post-Type oder strukturierte Felder im Theme
Datenspeicherung
WordPress-Standard
wp_posts + wp_postmeta
oder statische Dateien
Bewertungen
Schema.org AggregateRating in JSON-LD — unabhängig von Plugins
Kommentare
Sauber in wp_comments, bereinigt, korrekte Thread-Struktur
Risiko
Keine Plugin-Abhängigkeit — Daten gehören dir

Was eine Rezept-Migration nicht ist

Kein „Export klicken, Import klicken, fertig”. Das funktioniert bei einem WordPress-Blogpost mit Text und Bildern. Bei Rezepten mit strukturierten Daten, Bewertungen, Kommentaren und Schema-Markup reicht das nicht.

Aber auch kein monatelanges Mammutprojekt. Die sechs Phasen sind ein erprobter Ablauf, den wir für jeden Foodblog anpassen. Die meiste Arbeit steckt in Phase 2 und 3 — Export und Aufbereitung. Der Rest ist methodisch, aber planbar.

Die ehrliche Aussage: Je sauberer das Quell-Plugin die Daten gespeichert hat, desto reibungsloser läuft die Migration. Ein Blog mit 150 Rezepten in WP Recipe Maker, wo jedes Feld sauber befüllt ist, migriert sich deutlich einfacher als einer mit 300 Rezepten, verteilt auf drei verschiedene Plugins über acht Jahre.

Du planst eine Rezept-Migration? Lass uns die Ausgangslage zusammen anschauen. Oder lies zuerst den breiteren Guide zur Rezept-Migration, wenn du erstmal verstehen willst, wo die Stolperstellen liegen.

Mehr über unseren Migrations-Service: Migration.

Katharina Schneider

Katharina Schneider

Gründerin von blogsandpages.com – Expertin für Blogs, Unternehmenswebseiten und individuelle Publishing-Lösungen.

Bereit für Ihr nächstes Projekt?

Ob Blog, Unternehmenswebseite oder individuelle Plattform – lassen Sie uns gemeinsam bauen. Professionell, SEO-optimiert und auf Ihre Bedürfnisse zugeschnitten.

Projekt starten