WordPress Custom Post Types zu Webflow CMS: Ein Mapping-Leitfaden

Einführung in WordPress Custom Post Types für Webflow CMS

Die Migration von WordPress Custom Post Types zu Webflow ist keine Drag-and-Drop-Operation. Für Teams, die inhaltsreiche Websites betreiben, die auf Advanced Custom Fields, benutzerdefinierten Taxonomien oder relationalen CPT-Strukturen basieren, erfordert die Migration eine sorgfältige strukturelle Zuordnungsübung, bevor ein einziges Element exportiert wird. Dieser Leitfaden erklärt, wie CPT-Architekturen in Webflow CMS Collections übersetzt werden, wie Referenz- und Multi-Referenzfelder gehandhabt werden, welche Feldtypen sauber übernommen werden und welche eine Umstrukturierung erfordern. Er behandelt auch die Risiken des Datenverlusts, denen die meisten Teams zu spät begegnen, und den Validierungsprozess, den Sie vor dem DNS-Wechsel abschließen müssen.

‍

Was sind WordPress Custom Post Types?

WordPress Custom Post Types (CPTs) sind Inhaltsstrukturen, die über die standardmäßigen Beitrags- und Seitentypen der Plattform hinausgehen. Entwickler registrieren sie mithilfe von register_post_type() (entweder direkt in der functions.php Datei eines Themes oder über ein Plugin wie Custom Post Type UI), um eigenständige Inhaltseinheiten zu erstellen: Fallstudien, Teammitglieder, Stellenangebote, Testimonials, Veranstaltungen, Produkte und mehr.

In den meisten Produktionsumgebungen werden CPTs mit Advanced Custom Fields (ACF), das strukturierte, typisierte Felddaten auf jeden Beitragstyp legt. Ein ACF-gestützter Fallstudien-CPT könnte Felder für Kundennamen, Branche, Ergebniskennzahl, Hero-Bild, eine Video-Einbettungs-URL und ein Beziehungsfeld enthalten, das auf einen separaten Teammitglieder-CPT verweist. Diese relationale, strukturierte Inhaltsarchitektur macht die Migration nicht trivial.‍

Was sind WordPress Custom Post Types und wie beeinflussen sie die Migrationsplanung? WordPress Custom Post Types sind benutzerdefinierte Inhaltsstrukturen, die in PHP über die Standardbeiträge und -seiten hinaus registriert werden. In Verbindung mit Advanced Custom Fields bilden sie relationale, strukturierte Inhaltsarchitekturen, die Feldschemata, Taxonomien und Beziehungen zwischen Beiträgen umfassen. Während der Migration muss jeder CPT einzeln einer entsprechenden Webflow CMS Collection zugeordnet werden; es gibt keinen automatisierten Weg, das vollständige Schema ohne vorherige Planung der Feldübersetzung zu übertragen.

Diese strukturelle Komplexität ist der Grund, warum jede WordPress-zu-Webflow-Migration, die CPTs beinhaltet, ein dokumentiertes Inhaltsschema erfordert, bevor Export- oder Importarbeiten beginnen.

‍

Wie Webflow CMS-Sammlungen funktionieren

Webflow CMS organisiert Inhalte in Sammlungen, von denen jede ähnlich funktioniert wie eine Datenbanktabelle oder ein CPT. Jede Sammlung enthält Elemente, und jedes Element enthält Felder definierter Typen. Zu verstehen, welche Feldtypen das sind, ist die Grundlage des Mapping-Prozesses.

Die CMS-Feldtypen von Webflow umfassen:

• Klartext: einzeilige Zeichenketten (256-Zeichen-Limit)
• Rich Text: formatierte Inhalte mit Überschriften, Listen und eingebetteten Elementen
• Bild: einzelnes Bild mit Alt-Text
• Mehrfachbild: Bildergalerie
• Video-Link: YouTube- oder Vimeo-URL
• Zahl: Ganzzahl oder Dezimalwert
• Datum/Uhrzeit: strukturierte Datumsauswahl
• Schalter: Boolescher True/False-Schalter
• Farbe: Hex-Farbauswahl
• Datei: hochladbare Datei
• E-Mail: validierte E-Mail-Adresse
• Option: Dropdown-Menü mit vordefinierten, statischen Auswahlmöglichkeiten
• Referenz: Verknüpfung zu einem einzelnen Element in einer anderen Sammlung
• Mehrfachreferenz: Verknüpfung zu mehreren Elementen in einer anderen Sammlung

Jedes WordPress- und ACF-Feld muss einem dieser Typen zugeordnet werden. Wo keine direkte Übereinstimmung besteht, ist vor Beginn der Migration eine strukturelle Umgehung oder eine architektonische Neugestaltung erforderlich.

‍

Abbildung von WordPress Custom Post Types auf Webflow CMS

Der Prozess der Abbildung von WordPress Custom Post Types auf Webflow beginnt mit einem Audit des Inhaltsschemas: Dokumentieren Sie jeden CPT, jede damit verbundene ACF-Feldgruppe, jede Taxonomie und jede relationale Abhängigkeit auf der aktuellen Website. Dieses Audit wird zur Blaupause für die gesamte Webflow Collection-Architektur.

Abbildung der Kernfeldtypen

Die meisten Standard-WordPress- und ACF-Feldtypen lassen sich direkt auf Webflow-Äquivalente abbilden. Die folgende Tabelle stellt die primäre Abbildungsebene dar.

Tabelle: WordPress / ACF Feldtypen vs. Webflow CMS Feldtypen

‍

‍

Umgang mit Advanced Custom Fields-Gruppen

ACF-Feldgruppen, die an einen CPT angehängt sind, sollten als Feldschema für eine Webflow Collection behandelt werden. Jede Gruppe wird Teil der Felddefinition dieser Collection. Der empfohlene Prozess:

1. Exportieren Sie ACF-Feldgruppen-JSON aus WordPress (ACF > Tools > Feldgruppen exportieren)
2. Überprüfen Sie den Typ, die Bezeichnung jedes Feldes und jegliche angewandte bedingte Logik
3. Bilden Sie jedes Feld mithilfe der obigen Tabelle seinem Webflow-Äquivalent ab
4. Markieren Sie jedes Feld, das eine Umstrukturierung erfordert, bevor Sie die Collection in Webflow erstellen

Ein Punkt, den Teams häufig unterschätzen, ist ACF-Bedingungslogik. ACF ermöglicht es, Felder basierend auf den Werten anderer Felder ein- oder auszublenden. Webflow unterstützt keine native bedingte Feldlogik im CMS-Editor; alle Felder sind in der Redaktionsoberfläche immer sichtbar. Dies beeinflusst den redaktionellen Workflow nach der Migration, beeinträchtigt jedoch nicht die Datenintegrität. Es ist ratsam, dies den Content-Teams vor dem Go-Live mitzuteilen.

Die ACF-Dokumentation bietet eine vollständige Referenz für Feldtypen und Exportformate, was beim Erstellen Ihrer Tabelle zur Schema-Abbildung nützlich ist.

Taxonomien und Kategoriestrukturen verwalten

WordPress-Taxonomien, integrierte (category, post_tag) und benutzerdefinierte (register_taxonomy()), gehören zu den strukturell anspruchsvolleren Aspekten bei der Migration von WordPress Custom Post Types zu Webflow.

In WordPress kann ein CPT-Element direkt mehrere Taxonomie-Begriffe zugewiesen bekommen. In Webflow muss diese Beziehung mithilfe eines Reference -Feldes (für eine Einzelbegriffsbeziehung) oder eines Multi-Reference -Feldes (für mehrere Begriffe) dargestellt werden.

Die Taxonomie selbst wird zu einer separaten Webflow Collection. Wenn ein CPT namens „Fallstudien“ eine benutzerdefinierte Taxonomie namens „Branche“ verwendet, erfordert die Migration Folgendes:

1. Erstellung einer Webflow Collection namens „Branchen“ mit einem Namensfeld und zusätzlichen Metadaten
2. Befüllen dieser Collection, wobei jeder Taxonomie-Begriff als individuelles Element hinzugefügt wird
3. Hinzufügen eines Multi-Reference-Feldes zur Collection „Fallstudien“, das auf „Branchen“ verweist
4. Befüllen dieses Multi-Reference-Feldes während des CSV- oder API-Imports von Fallstudien-Elementen

Dies ist eine erhebliche strukturelle Abweichung vom WordPress-Taxonomie-Verhalten und muss architektonisch gelöst werden, bevor Importarbeiten beginnen.

‍

Reference Fields and Multi-Reference Handling

Relational content is where most CPT migrations become complicated. Understanding how Webflow handles reference data is essential to avoiding data loss and import failures.

Single Reference Fields

A Webflow Reference field links one Collection Item to exactly one Item in another Collection. This is the direct equivalent of an ACF Post Object field configured to return a single post.

The constraint: a Reference field can only point to one Collection. If a WordPress CPT uses a Post Object field that can pull from multiple post types (for example, both "Team Members" and "Partners") it cannot be mapped to a single Reference field in Webflow. This requires either splitting the relationship into separate Reference fields or consolidating the source content into a single unified Collection.

Multi-Reference Fields

A Webflow Multi-Reference field links one Collection Item to multiple Items in another Collection. This maps to ACF's Relationship field (configured for multiple selections) and to WordPress taxonomies with multiple terms assigned.

How do you handle Multi-Reference fields when migrating WordPress CPTs to Webflow? Webflow Multi-Reference fields link a single Collection Item to multiple Items in another Collection, the equivalent of ACF's Relationship field or WordPress taxonomy assignments with multiple terms. During migration, each unique taxonomy or relational data set must become its own Webflow Collection. The source CPT then references those Collections via Multi-Reference fields. The referenced Collections must be imported before the Collection containing the Multi-Reference field, and during CSV import, Multi-Reference values are passed as comma-separated item slugs.

Import sequence is critical. Whether importing via Webflow's CSV tool or the Webflow API, any Collection being referenced must be fully populated before you can reference its items. The correct order is:

1. Import all standalone Collections first, taxonomies, reference entities with no outbound relationships
2. Import Collections with single Reference fields second
3. Import Collections with Multi-Reference fields last

For CSV imports, Multi-Reference fields are populated using comma-separated item slugs. If an item's slug in the referenced Collection is enterprise-saas, and a Case Study references three industries, the corresponding CSV cell value would be: enterprise-saas,fintech,devtools.

‍

Common Data Loss Risks When Migrating CPTs to Webflow

Data loss in CPT migrations rarely results from corruption. It comes from fields that have no Webflow equivalent, content that exceeds field character limits, or relational structures that were not mapped before import began. Identifying these risks early is the difference between a clean migration and a recovery project.

Fields Without a Webflow Equivalent

Several ACF and WordPress field types do not have native equivalents in Webflow CMS:

• ACF Repeater fields: These create a sub-table of repeating field groups under a single post. Webflow has no repeater. The closest architectural solution is a dedicated Collection that references the parent item via a Reference field. An ACF repeater storing "timeline events" attached to a case study becomes a "Timeline Events" Collection with a Reference back to the parent Case Study item.
• ACF Flexible Content fields: These allow editors to assemble content using modular, block-based layouts. Webflow's CMS does not support this pattern. Flexible content layouts must either be migrated into Rich Text fields (losing structured field-level control) or restructured into multiple specialized Collections with display logic handled at the template level.
• WordPress User reference fields: ACF User fields that link to WordPress user accounts have no direct Webflow equivalent. These are typically converted to Plain Text (storing a name string) or mapped to a Reference pointing to an "Authors" or "Team Members" Collection.
• Google Maps / Address fields: Webflow has no native geolocation or map field type. These require a Plain Text field for address data, with a custom embed or third-party script used to render the map on the front end.

Repeater and Flexible Content Fields

These two field types require early architectural decisions that cannot easily be reversed once migration is underway. Before the migration begins, document every repeater and flexible content field in use. For each:

• Determine the maximum number of sub-items in active use (to size the nested Collection correctly)
• Determine whether repeater data is editorial (belongs in Webflow CMS) or presentational (can be moved to static HTML or JavaScript components)
• Decide whether flexible content modules will be rebuilt as Rich Text blocks or as design-system components with CMS-bound bindings

Teams that skip this step frequently discover mid-migration that a significant portion of their CPT content cannot be imported in the first pass, extending timelines and introducing post-launch content gaps.

Character Limits and Content Truncation

Webflow enforces field-level character limits that directly affect import success. Key limits:

• Plain Text fields: 256 characters
• Option field labels: Limited string length
• Rich Text fields: No hard character cap, but performance degrades with very large content blocks

If WordPress text fields contain data exceeding 256 characters, mapping them to Plain Text in Webflow will truncate that content silently during import. Before generating your mapping spreadsheet, audit field content lengths in WordPress, any field with content regularly exceeding 256 characters should be mapped to Rich Text.

‍

How to Validate Your Migration Before Go-Live

Validation is the phase most migration teams compress, and the source of the majority of post-launch issues. A structured pre-go-live process must cover content integrity, relationship accuracy, URL continuity, and rendering correctness across all Collection page templates.

How do you validate a WordPress CPT to Webflow CMS migration before go-live? Validating a CPT migration to Webflow requires checking content integrity (all items imported, all fields populated), relationship accuracy (Reference and Multi-Reference fields link to the correct items), slug continuity (CMS item slugs match the WordPress URL structure for redirect mapping), and render testing (all dynamic bindings on Collection page templates display correctly). A baseline content count audit comparing WordPress item totals to Webflow Collection totals is the minimum validation step before any DNS change.

Pre-Migration Audit Checklist

Complete every step on this list before exporting or importing any data:

1. Export the full CPT schema: Document all CPTs, attached ACF field groups, field types, and custom taxonomies in a structured spreadsheet.
2. Count all CPT items per post type: These item counts become the validation baseline for post-import verification.
3. Identify all relational fields: Map every ACF Post Object, Relationship, and Taxonomy field to its Webflow Reference or Multi-Reference equivalent.
4. Flag Repeater and Flexible Content fields: Document the restructuring plan for each before building any Collections.
5. Audit field content lengths: Identify any text data exceeding 256 characters that must be mapped to Rich Text.
6. Define the import sequence: List all Collections in correct dependency order: standalone Collections first, relational Collections last.
7. Document all current CPT URLs: These become the 301 redirect map for Webflow's redirect manager.
8. Prepare the redirect file: Map every WordPress CPT URL (/case-studies/example-slug/) to its corresponding Webflow Collection page URL before DNS change.

Post-Migration QA Testing

After import, validate against the following:

• Item count parity: Total items in each Webflow Collection matches the source CPT item count
• Required field completeness: No required fields are empty or defaulted to placeholder values
• Reference field accuracy: Spot-check 10–20% of items to confirm Reference and Multi-Reference fields link to the correct Collection items
• Slug accuracy: CMS item slugs match the planned redirect map precisely
• Rich Text rendering: Check Rich Text fields for encoding artifacts, broken embeds, or formatting loss
• Image and file hosting: Confirm all images and files are hosted on Webflow's asset CDN, not still pointing to WordPress media URLs
• Template rendering: Confirm all dynamic field bindings on Collection page templates display the correct content for a representative sample of items

In a recent WordPress-to-Webflow migration for a B2B SaaS client, Broworks reduced crawl errors by 80% and preserved full SEO equity by running this exact validation sequence before the DNS switch, including a complete slug audit and redirect file covering 340 CPT items across four post types. The Webflow development process treats validation as a first-class deliverable in every migration engagement, not a final-day checklist.

For teams planning a migration to Webflow in 2026 Bei komplexen CPT-Architekturen ist dieser strukturierte Validierungsansatz der Unterschied zwischen einem reibungslosen Start und einem Rettungsprojekt.

‍

WordPress CPT vs. Webflow CMS: Wichtige strukturelle Unterschiede, die man kennen sollte

Über das Feld-Mapping hinaus gibt es architektonische Unterschiede auf Plattformebene zwischen WordPress und Webflow, die die Planung und Durchführung der Migration beeinflussen. Diese vorab zu verstehen, verhindert strukturelle Überraschungen während des Imports.

• Sammlungen sind flach, nicht hierarchisch: Webflow CMS unterstützt nativ keine verschachtelten oder über- und untergeordneten Sammlungen. Hierarchische WordPress-Beitragstypen, bei denen über- und untergeordnete Beitragsbeziehungen bestehen, müssen abgeflacht oder mithilfe von Referenzfeldern umstrukturiert werden, um diese Hierarchie darzustellen.
• Keine Autorenschaft auf Benutzerebene per CMS-Feld: Webflow Collection Items verfügen nicht über ein natives Autorenfeld, das mit einem Webflow-Benutzerkonto verknüpft ist, wie es bei WordPress-Beiträgen der Fall ist. Die Autorenzuweisung muss als Referenz zu einer separaten „Team“- oder „Autoren“-Sammlung gespeichert werden.
• Optionsfelder sind statisch: Im Gegensatz zu ACF-Auswahlfeldern, die Optionen dynamisch aus einer PHP-Funktion abrufen können, erfordern Webflow-Optionsfelder statisch definierte Auswahlmöglichkeiten, die auf Feldebenen konfiguriert werden. Dynamische oder API-gesteuerte Optionssätze erfordern eine Umstrukturierung als Referenz zu einer eigenständigen Sammlung.
• Keine native Revisionshistorie für CMS-Elemente: Webflow pflegt keine redaktionelle Revisionshistorie für Sammlungselemente, wie es WordPress mit Beitragsrevisionen tut. Dies ist eine Workflow-Überlegung für Content-Teams, die es gewohnt sind, Änderungen rückgängig zu machen.
• Grenzwerte für Sammlungselemente gelten pro Plan: Der CMS-Plan von Webflow unterstützt bis zu 10.000 Elemente pro Sammlung. Websites mit sehr großen CPT-Archiven sollten die Elementanzahl vor Beginn der Migration mit ihrem Ziel-Webflow-Plan abgleichen.

Diese Unterschiede spiegeln Webflows architektonische Priorität wider, die auf strukturiertes, designsystemorientiertes Content-Management abzielt, anstatt auf offene Datenbankflexibilität. Sie erfordern Planung, machen Webflow aber nicht zu einem schlechteren System für inhaltsreiche Websites. Sie bedeuten lediglich, dass die Migrationsarbeit das strukturelle Denken vorverlagert, das WordPress oft aufschiebt.

Für einen umfassenderen Überblick darüber, was eine vollständige WordPress-zu-Webflow-Migration beinhaltet, werden die strukturellen Unterschiede zwischen den beiden CMS-Plattformen in jeder Discovery-Phase behandelt, bevor technische Arbeiten beginnen. Zusätzliche Ressourcen zur Migrationsplanung finden Sie in der Broworks Ressourcenbibliothek.