webflow/webflow-skills

CMS Best Practices

Bieten Sie Expertenwissen zur Webflow CMS-Architektur, Beziehungen, Optimierung und Fehlerbehebung.

Wichtiger Hinweis

Verwenden Sie IMMER Webflow MCP-Tools für alle Operationen:

• Verwenden Sie das Webflow MCP webflow_guide_tool, um Best Practices vor Beginn zu erhalten
• Verwenden Sie das Webflow MCP data_sites_tool mit der Aktion list_sites, um verfügbare Sites zu identifizieren
• Verwenden Sie das Webflow MCP data_sites_tool mit der Aktion get_site, um Site-Details und Planlimits abzurufen
• Verwenden Sie das Webflow MCP data_cms_tool mit der Aktion get_collection_list, um vorhandene Collections zu analysieren
• Verwenden Sie das Webflow MCP data_cms_tool mit der Aktion get_collection_details, um Collection-Schemata zu untersuchen
• Verwenden Sie das Webflow MCP data_cms_tool mit der Aktion list_collection_items, um das Inhaltsvolumen zu bewerten
• Verwenden Sie das Webflow MCP data_pages_tool mit der Aktion list_pages, um die Seitenstruktur zu verstehen
• Verwenden Sie das Webflow MCP ask_webflow_ai für spezifische API-Fragen
• Verwenden Sie KEINE anderen Tools oder Methoden für Webflow-Operationen
• Alle Tool-Aufrufe müssen den erforderlichen context-Parameter enthalten (15–25 Wörter, Perspektive der dritten Person)

Anleitung

Phase 1: Erkennung & Analyse

1. Anfrage identifizieren: Bestimmen Sie, ob der Benutzer:
   • Eine neue CMS-Struktur plant
   • Bestehende Collections optimiert
   • Leistungsprobleme behebt
   • Beziehungen einrichtet
   • Architekturberatung sucht
2. Site-Informationen abrufen: Verwenden Sie das Webflow MCP data_sites_tool mit den Aktionen list_sites und get_site, um Planlimits zu verstehen
3. Vorhandene Struktur analysieren: Verwenden Sie das Webflow MCP data_cms_tool mit den Aktionen get_collection_list und get_collection_details, um die aktuelle Einrichtung zu untersuchen
4. Inhaltsvolumen bewerten: Verwenden Sie das Webflow MCP data_cms_tool mit der Aktion list_collection_items, um den Umfang zu verstehen
5. Seiten überprüfen: Verwenden Sie das Webflow MCP data_pages_tool mit der Aktion list_pages, um zu sehen, wie Inhalte angezeigt werden

Phase 2: Anforderungserfassung

6. Anwendungsfall verstehen: Stellen Sie klärende Fragen:
   • Welche Inhalte müssen verwaltet werden?
   • Wer wird die Inhalte aktualisieren?
   • Wie werden die Inhalte angezeigt?
   • Welche Beziehungen werden benötigt?
   • Erwartetes Inhaltsvolumen?
7. Einschränkungen identifizieren: Berücksichtigen Sie Planlimits, technische Einschränkungen, Teamfähigkeiten
8. Erfolgskriterien definieren: Leistungsziele, Redaktionsworkflow, Skalierbarkeitsanforderungen

Phase 3: Architekturplanung

9. Collection-Struktur entwerfen: Planen Sie Collections, Felder und Beziehungen
10. Feldtypen auswählen: Wählen Sie geeignete Feldtypen für jedes Inhaltselement
11. Beziehungen planen: Entwerfen Sie Ein-zu-Viele- und Viele-zu-Viele-Verbindungen
12. Taxonomie berücksichtigen: Bestimmen Sie Kategorien, Tags und organisatorische Struktur
13. Skalierung planen: Entwerfen Sie für Wachstum (Paginierung, Leistung, Grenzen)
14. Entscheidungen dokumentieren: Erklären Sie Kompromisse und Gründe

Phase 4: Empfehlungen & Validierung

15. Empfehlungen generieren: Geben Sie spezifische, umsetzbare Anleitungen
16. Änderungen priorisieren: Nach Auswirkung organisieren (schnelle Erfolge vs. langfristig)
17. Kompromisse erklären: Helfen Sie Benutzern, Einschränkungen und Workarounds zu verstehen
18. Gegen Best Practices validieren: Überprüfen Sie Webflow-Einschränkungen und -Muster
19. Alternativen anbieten: Bieten Sie mehrere Ansätze an, wenn anwendbar
20. Implementierungsfahrplan erstellen: Unterteilen Sie in Phasen

Phase 5: Implementierungsunterstützung

21. Schritt-für-Schritt-Anleitung geben: Klare Anleitung zur Implementierung
22. Unterstützung anbieten: Vorschlagen, andere Skills zu verwenden (cms-collection-setup, bulk-cms-update)
23. Struktur dokumentieren: Dokumentation für das Team empfehlen
24. Testansatz vorschlagen: Anleitung zur Validierung von Änderungen
25. Migration planen: Bei Refactoring eine Migrationsstrategie bereitstellen

Collection-Architektur

Wann CMS vs. statisch verwenden

CMS verwenden, wenn:

• Inhalte häufig aktualisiert werden (wöchentlich oder öfter)
• Mehrere ähnliche Elemente (Blogbeiträge, Produkte, Teammitglieder, Projekte)
• Nicht-technische Benutzer Inhalte bearbeiten müssen
• Inhalte Filterung/Sortierung im Frontend benötigen
• Gleiche Inhalte auf mehreren Seiten erscheinen (Autoren-Bios, Produktfunktionen)
• Inhalte eine konsistente Struktur über Elemente hinweg haben
• Sie Seiten dynamisch generieren müssen

Statisch verwenden, wenn:

• Inhalte sich selten ändern (jährliche Aktualisierungen oder seltener)
• Einmalige, individuelle Abschnitte (Über-uns-Hero, Homepage-Sonderfunktionen)
• Komplexe benutzerdefinierte Layouts pro Element, die keinen Mustern folgen
• Keine dynamische Filterung oder Suche erforderlich
• Inhalte stark angepasst sind und keine gemeinsame Struktur haben
• Leistung entscheidend ist und sich Inhalte nicht ändern
• Sie vollständige Designflexibilität pro Abschnitt benötigen

Hybrider Ansatz:

• Statische Seiten mit CMS-gesteuerten Abschnitten (z. B. statische Homepage mit CMS-Referenzen)
• CMS für aktuelle Inhalte, statische Archive für alte Inhalte
• Statische Landingpages, CMS für Unterseiten

Feldtypenauswahl

Inhaltstyp	Empfohlener Feldtyp	Notizen	Zeichenbegrenzung
Kurzer Text	Plain Text	Titel, Namen, Slugs	Max. 256 Zeichen
Langer Text (ohne Formatierung)	Plain Text (long)	Beschreibungen, Auszüge	Unbegrenzt
Formatierter Inhalt	Rich Text	Blog-Inhalte, Bios, Artikel	Unbegrenzt
Einzelnes Bild	Image	Fotos, Thumbnails, Header	Max. 4 MB pro Bild
Mehrere Bilder	Multi-image	Galerien, Produktfotos	Bis zu 25 Bilder
Datei-Downloads	File	PDFs, Dokumente, Downloads	Max. 4 MB pro Datei
Ja/Nein-Werte	Switch	Hervorhebungsflags, Sichtbarkeitsumschalter	Boolean
Einzelauswahl	Option	Status, Typ, Kategorie	Unbegrenzte Optionen
Datum/Uhrzeit	Date/Time	Veröffentlichungsdaten, Ereignisse, Fristen	ISO 8601 Format
Link zu einem Element	Reference	Autor → Beitrag, Kategorie → Beitrag	Ein Element
Link zu mehreren Elementen	Multi-reference	Beitrag → Tags, Beitrag → Verwandte Beiträge	Mehrere Elemente
Externe URL	Link	Social-Links, externe Ressourcen	Max. 2048 Zeichen
Numerische Werte	Number	Preise, Bewertungen, Reihenfolge, Anzahl	Ganzzahl oder Dezimal
Telefonnummern	Phone	Kontaktnummern	E.164 Format
E-Mail-Adressen	Email	Kontakt-E-Mails	Gültiges E-Mail-Format
Farbwerte	Color	Designfarben, Akzente, Markenfarben	Hex-Format
Video-Einbettungen	Video	YouTube, Vimeo-Einbettungen	Embed-URL

Entscheidungsbaum für Feldtypen

Möchten Sie speichern:
├── Text?
│   ├── Kurz (≤256 Zeichen)? → Plain Text
│   ├── Lang + Formatierung? → Rich Text
│   └── Lang + Keine Formatierung? → Plain Text (long)
├── Medien?
│   ├── Einzelnes Bild? → Image
│   ├── Mehrere Bilder? → Multi-image
│   ├── Video? → Video
│   └── Datei-Download? → File
├── Auswahl/Selection?
│   ├── Ja/Nein? → Switch
│   ├── Eine Option? → Option
│   └── Link zu Element? → Reference/Multi-reference
├── Strukturierte Daten?
│   ├── Nummer? → Number
│   ├── Datum/Uhrzeit? → Date/Time
│   ├── Telefon? → Phone
│   ├── E-Mail? → Email
│   └── URL? → Link
└── Visuell?
    └── Farbe? → Color

Beziehungsmuster

Eins-zu-Viele (Reference-Feld)

Beispiel: Beiträge → Autor

Autoren-Collection:
├── name (Text, erforderlich)
├── slug (Text, erforderlich)
├── bio (Rich Text)
├── photo (Image)
├── title (Text) - Jobtitel
├── email (Email)
└── social-links (Link)

Beiträge-Collection:
├── title (Text, erforderlich)
├── slug (Text, erforderlich)
├── content (Rich Text)
└── author (Reference → Autoren)  ← Jeder Beitrag hat EINEN Autor

Anzeige: Auf der Beitragsseite zugreifen auf author.name, author.photo, author.bio

Filterung: Kann Beiträge nach bestimmten Autoren filtern

Vorteile:

• ✅ Zentrale Autorendaten (einmal aktualisieren, überall reflektiert)
• ✅ Leicht Konsistenz zu wahren
• ✅ Kann Autorenprofilseiten mit allen ihren Beiträgen erstellen
• ✅ Effizient (eine Referenz pro Beitrag)

Anwendungsfälle:

• Blogbeiträge → Autor
• Produkte → Marke
• Ereignisse → Veranstaltungsort
• Projekte → Kunde
• Referenzen → Kunde

Viele-zu-Viele (Multi-Reference)

Beispiel: Beiträge ↔ Tags

Tags-Collection:
├── name (Text, erforderlich)
├── slug (Text, erforderlich)
├── description (Plain Text)
└── color (Color) - optionale visuelle Gruppierung

Beiträge-Collection:
├── title (Text, erforderlich)
├── slug (Text, erforderlich)
├── content (Rich Text)
└── tags (Multi-Reference → Tags)  ← Jeder Beitrag hat VIELE Tags

Anzeige: Auf der Beitragsseite durch tags schleifen, um alle Tags anzuzeigen

Filterung: Kann Beiträge nach bestimmten Tags filtern

Vorteile:

• ✅ Flexible Inhaltsorganisation
• ✅ Verknüpfung verwandter Inhalte
• ✅ Besseres SEO (Themen-Clustering)
• ✅ Verbesserte Benutzernavigation

Einschränkungen:

• ⚠️ Max. 5 Multi-Reference-Felder pro Collection
• ⚠️ Kann in Collection-Listen nur nach EINEM Multi-Reference-Wert gleichzeitig filtern
• ⚠️ Kann nicht nach Werten referenzierter Felder sortieren
• ⚠️ Jede Referenz = zusätzliche Abfrage (beeinträchtigt Leistung)

Workarounds für Mehrfach-Tag-Filterung:

1. Kombinierte Tags erstellen (z. B. „vegan-glutenfrei“)
2. Finsweet CMS-Filter für clientseitige Filterung verwenden
3. Separate gefilterte Collection-Listen für häufige Kombinationen erstellen
4. Benutzerdefinierten Code mit Webflow-API verwenden

Anwendungsfälle:

• Blogbeiträge ↔ Tags
• Produkte ↔ Funktionen
• Projekte ↔ Technologien
• Rezepte ↔ Zutaten
• Kurse ↔ Themen

Selbstreferenz (Verschachtelte Collections)

Beispiel: Kategorien mit Unterkategorien

Kategorien-Collection:
├── name (Text, erforderlich)
├── slug (Text, erforderlich)
├── description (Plain Text)
├── parent (Reference → Kategorien)  ← Selbstreferenz für Hierarchie
└── level (Number) - 1, 2, 3 für Anzeigelogik

Anwendungsfälle:

• Kategorien mit Unterkategorien
• Menüpunkte mit Untermenüpunkten
• Organisationshierarchie
• Produkttaxonomie

Vorteile:

• ✅ Flexible Hierarchie
• ✅ Unbegrenzte Tiefe (theoretisch)
• ✅ Einfach umzuorganisieren

Einschränkungen:

• ⚠️ Komplexe Darstellung verschachtelter Ebenen in Webflow
• ⚠️ Max. 2–3 Ebenen für praktische Implementierung empfohlen
• ⚠️ Erfordert benutzerdefinierte Logik für tiefe Verschachtelung

Alternative: Option-Feld für einfache 1–2-Ebenen-Kategorisierung verwenden

Bidirektionale Beziehungen

Beispiel: Verwandte Beiträge

Beiträge-Collection:
├── title (Text, erforderlich)
├── slug (Text, erforderlich)
├── content (Rich Text)
└── related-posts (Multi-Reference → Beiträge)  ← Selbstreferenz zu anderen Beiträgen

Anzeige: Verwandte Beiträge am Ende der Beitragsseite anzeigen

Vorteile:

• ✅ Hält Benutzer länger engagiert
• ✅ Besseres SEO (interne Verlinkung)
• ✅ Flexible Inhaltsverbindungen

Herausforderungen:

• ⚠️ Nicht wirklich bidirektional (A → B erstellt nicht automatisch B → A)
• ⚠️ Muss beide Richtungen manuell pflegen, falls erforderlich
• ⚠️ Kann zeitaufwändig für Content-Redakteure sein

Lösungen:

1. Tags für automatische „nach Tag verwandte“ Logik verwenden
2. Manuelle Kuratierung für die wichtigsten Verbindungen
3. Hybrid: Manuell + automatisiert basierend auf Tags/Kategorie

Beispiele

Beispiel 1: Planung einer neuen CMS-Struktur

Benutzeraufforderung:

Ich erstelle eine Rezeptseite. Wie sollte ich das CMS strukturieren?

Schritt 1: Anforderungserfassung

📐 CMS-Planung: Rezeptseite

Lassen Sie mich ein paar Fragen stellen, um die beste Struktur zu entwerfen:

1. **Inhaltsvolumen**: Wie viele Rezepte planen Sie?
   - Klein (≤50): Einfache Struktur
   - Mittel (50–200): Moderate Organisation
   - Groß (200+): Fortgeschrittene Taxonomie erforderlich

2. **Rezeptattribute**: Welche Informationen wird jedes Rezept haben?
   - Basis: Name, Zutaten, Anleitung, Bild
   - Erweitert: Vorbereitungszeit, Kochzeit, Schwierigkeit, Ernährung, Diät-Tags

3. **Organisationsbedarf**: Wie werden Benutzer Rezepte finden?
   - Nach Mahlzeitentyp (Frühstück, Mittagessen, Abendessen)
   - Nach Küche (Italienisch, Mexikanisch, Asiatisch)
   - Nach Ernährungseinschränkungen (vegan, glutenfrei, keto)
   - Nach Kochmethode (Backen, Grillen, Schongarer)
   - Nach Zutaten (Hühnchen, Pasta, Gemüse)

4. **Autoren-Setup**: Ein oder mehrere Autoren?
   - Einzeln: Sie verwalten alle Inhalte
   - Mehrere: Team von Rezeptentwicklern

5. **Benutzerinteraktion**: Welche interaktiven Funktionen?
   - Kommentare/Bewertungen
   - Bewertungen
   - Favoriten speichern
   - Rezeptkarten drucken

Basierend auf Ihren Antworten werde ich die optimale CMS-Architektur entwerfen.

Schritt 2: Nach Benutzerantwort

📐 Empfohlene CMS-Architektur: Rezeptseite

Basierend auf Ihren Anforderungen (Mittleres Volumen, Mehrere Autoren, Erweiterte Filterung):

---

## Benötigte Collections: 4

### 1. Rezepte (Hauptinhalt)
├── name (Text, erforderlich) - „Hausgemachte Pasta Carbonara“
├── slug (Text, erforderlich) - „hausgemachte-pasta-carbonara“
├── description (Plain Text, 160 Zeichen) - Kurze Zusammenfassung für SEO
├── featured-image (Image) - Hero-Bild für Detailseite
├── thumbnail-image (Image) - Kleineres Bild für Grid-Karten
├── prep-time (Number, erforderlich) - Vorbereitungszeit in Minuten
├── cook-time (Number, erforderlich) - Kochzeit in Minuten
├── total-time (Number) - Automatisch berechnet oder manuell
├── servings (Number, erforderlich) - Anzahl Portionen
├── difficulty (Option: Einfach, Mittel, Schwer)
├── ingredients (Rich Text, erforderlich) - Zutatenliste mit Mengen
├── instructions (Rich Text, erforderlich) - Schritt-für-Schritt-Anleitung
├── notes (Rich Text) - Kochhinweise, Tipps, Ersatzstoffe
├── nutrition-info (Plain Text) - Kalorien, Protein usw.
├── author (Reference → Autoren, erforderlich)
├── category (Reference → Kategorien, erforderlich) - Primärer Mahlzeitentyp
├── cuisine (Reference → Küchen) - Italienisch, Mexikanisch usw.
├── dietary-tags (Multi-Reference → Diät-Tags) - Vegan, GF usw.
├── cooking-methods (Multi-Reference → Methoden) - Backen, Grillen usw.
├── featured (Switch) - Auf der Startseite hervorheben
├── published-date (Date, erforderlich)
└── view-count (Number) - Beliebtheit verfolgen

**Gesamtfelder:** 22 Felder
**Erforderlicher Plan:** CMS-Plan mindestens (20 Collections, 2000 Elemente)

### 2. Autoren
├── name (Text, erforderlich)
├── slug (Text, erforderlich)
├── title (Text) - „Chefkoch“, „Rezeptentwickler“
├── bio (Rich Text)
├── photo (Image)
├── specialty (Plain Text) - „Italienische Küche“, „Backen“
├── social-instagram (Link)
├── social-website (Link)
└── email (Email)

**Zweck:** Wiederverwendbare Autoreninformationen für alle Rezepte

### 3. Kategorien
├── name (Text, erforderlich) - „Frühstück“, „Mittagessen“, „Abendessen“, „Desserts“
├── slug (Text, erforderlich)
├── description (Plain Text)
├── image (Image) - Kategorie-Hero-Bild
├── color (Color) - Optionale visuelle Kennzeichnung
└── featured (Switch) - Auf der Startseite hervorheben

**Zweck:** Primäre Rezeptorganisation

**Wichtig:** Verwenden Sie KEINE Hierarchie; halten Sie es flach mit 10–15 Hauptkategorien

### 4. Diät-Tags
├── name (Text, erforderlich) - „Vegan“, „Glutenfrei", „Keto"
├── slug (Text, erforderlich)
├── description (Plain Text, 160 Zeichen)
└── color (Color)

**Zweck:** Ernährungsfilterung und -kennzeichnung

---

## Wichtige Überlegungen

### 1. Leistung
- Multi-Reference-Felder auf 3–4 pro Collection beschränken
- Erwägen Sie die Common-Tag-Strategie für häufige Kombinationen
- Bildoptimierung für schnelle Ladezeiten

### 2. Redaktionsworkflow
- Autoren verwalten nur Rezepte; Administratoren verwalten Referenzdaten
- Planlimits überprüfen: Stellen Sie sicher, dass der ausgewählte Plan das erwartete Volumen unterstützt
- Entwurfs-Workflow für die Inhaltsfreigabe einrichten

### 3. Zukunftsskalierung
- Zu Beginn zusätzliche Felder für erweiterte Funktionen wie Zutaten-Multi-Reference
- API-First-Ansatz für zukünftige mobile App-Integration
- Übersetzungen für mehrsprachige Rezepte (falls erforderlich)

Möchten Sie, dass ich eine dieser Collections konfiguriere, Felder optimiere oder andere Einschränkungen bespreche?