cms-best-practices

CMS 最佳实践

为 Webflow CMS 架构、关系、优化和故障排除提供专业指导。

重要说明

所有操作都必须使用 Webflow MCP 工具：

• 开始前，使用 Webflow MCP 的 webflow_guide_tool 获取最佳实践
• 使用 Webflow MCP 的 data_sites_tool，通过 action list_sites 找出可用站点
• 使用 Webflow MCP 的 data_sites_tool，通过 action get_site 获取站点详情和套餐限制
• 使用 Webflow MCP 的 data_cms_tool，通过 action get_collection_list 分析现有集合
• 使用 Webflow MCP 的 data_cms_tool，通过 action get_collection_details 查看集合架构
• 使用 Webflow MCP 的 data_cms_tool，通过 action list_collection_items 评估内容数量
• 使用 Webflow MCP 的 data_pages_tool，通过 action list_pages 了解页面结构
• 针对具体的 API 问题，使用 Webflow MCP 的 ask_webflow_ai
• Webflow 操作不得使用任何其他工具或方法
• 所有工具调用都必须包含必需的 context 参数（15-25 个词，以第三人称视角编写）

说明

阶段 1：发现与分析

1. 识别请求：判断用户是要：
   • 规划新的 CMS 结构
   • 优化现有集合
   • 排查性能问题
   • 设置关系
   • 寻求架构指导
2. 获取站点信息：使用 Webflow MCP 的 data_sites_tool，通过 actions list_sites 和 get_site 了解套餐限制
3. 分析现有结构：使用 Webflow MCP 的 data_cms_tool，通过 actions get_collection_list 和 get_collection_details 检查当前设置
4. 评估内容数量：使用 Webflow MCP 的 data_cms_tool，通过 action list_collection_items 了解规模
5. 查看页面：使用 Webflow MCP 的 data_pages_tool，通过 action list_pages 查看内容的展示方式

阶段 2：收集需求

6. 了解使用场景：提出澄清问题：
   • 需要管理哪些内容？
   • 谁会更新内容？
   • 内容将如何展示？
   • 需要哪些关系？
   • 预计内容数量是多少？
7. 确定约束条件：考虑套餐限制、技术约束和团队技能
8. 定义成功标准：性能目标、编辑工作流和可扩展性需求

阶段 3：架构规划

9. 设计集合结构：规划集合、字段和关系
10. 选择字段类型：为每个内容元素选择合适的字段类型
11. 规划关系：设计一对多和多对多关联
12. 考虑分类体系：确定类别、标签和组织结构
13. 规划扩展能力：为增长做好设计（分页、性能和限制）
14. 记录决策：说明权衡取舍和理由

阶段 4：提出建议并验证

15. 提出建议：提供具体且可执行的指导
16. 确定变更优先级：按影响排序（快速见效的改进与长期改进）
17. 说明权衡取舍：帮助用户了解限制和变通方案
18. 根据最佳实践验证：检查是否符合 Webflow 限制和惯例
19. 提供替代方案：适用时提供多种方法
20. 制定实施路线图：分阶段规划

阶段 5：实施指导

21. 提供分步说明：给出清晰的实施指导
22. 主动提供协助：建议使用其他技能（cms-collection-setup、bulk-cms-update）
23. 记录结构：建议编写文档供团队参考
24. 建议测试方法：指导如何验证变更
25. 规划迁移：如果需要重构，则提供迁移策略

集合架构

何时使用 CMS 与静态内容

使用 CMS 的情况：

• 内容更新频繁（每周或更频繁）
• 有多个相似条目（博客文章、产品、团队成员、项目）
• 非技术用户需要编辑内容
• 内容需要在前端进行筛选／排序
• 同一内容出现在多个页面上（作者简介、产品特性）
• 各条目的内容遵循一致的结构
• 需要动态生成页面

使用静态内容的情况：

• 内容很少更改（每年更新或更少）
• 独特的一次性版块（关于页面的主视觉区、首页的特别功能）
• 每个条目都有复杂的自定义布局，不遵循固定模式
• 不需要动态筛选或搜索
• 内容高度定制，且结构各异
• 性能至关重要，且内容不会更改
• 需要为每个版块提供完全的设计灵活性

混合方式：

• 静态页面搭配由 CMS 驱动的版块（例如，静态首页搭配 CMS 客户评价）
• 最近的内容使用 CMS，较早的内容使用静态归档
• 静态落地页，子页面使用 CMS

字段类型选择

内容类型	推荐字段	备注	字符限制
短文本	Plain Text	标题、名称、slug	最多 256 个字符
长文本（无格式）	Plain Text (long)	描述、摘要	不限
带格式的内容	Rich Text	博客内容、简介、文章	不限
单张图片	Image	照片、缩略图、页眉	每张图片最多 4MB
多张图片	Multi-image	图库、产品照片	最多 25 张图片
文件下载	File	PDF、文档、下载文件	每个文件最多 4MB
是／否值	Switch	特色标记、可见性开关	布尔值
单选项	Option	状态、类型、类别	选项不限
日期／时间	Date/Time	发布日期、活动、截止日期	ISO 8601 格式
链接到单个条目	Reference	作者 → 文章、类别 → 文章	一个条目
链接到多个条目	Multi-reference	文章 → 标签、文章 → 相关文章	多个条目
外部 URL	Link	社交链接、外部资源	最多 2048 个字符
数值	Number	价格、评分、顺序、计数	整数或小数
电话号码	Phone	联系电话	E.164 格式
电子邮件地址	Email	联系邮箱	有效的电子邮件格式
颜色值	Color	主题色、强调色、品牌色	十六进制格式
视频嵌入	Video	YouTube、Vimeo 嵌入内容	嵌入 URL

字段类型决策树

Need to store:
├── Text?
│   ├── Short (≤256 chars)? → Plain Text
│   ├── Long + Formatting? → Rich Text
│   └── Long + No Formatting? → Plain Text (long)
├── Media?
│   ├── Single image? → Image
│   ├── Multiple images? → Multi-image
│   ├── Video? → Video
│   └── File download? → File
├── Choice/Selection?
│   ├── Yes/No? → Switch
│   ├── One option? → Option
│   └── Link to item? → Reference/Multi-reference
├── Structured data?
│   ├── Number? → Number
│   ├── Date/Time? → Date/Time
│   ├── Phone? → Phone
│   ├── Email? → Email
│   └── URL? → Link
└── Visual?
    └── Color? → Color

关系模式

一对多（Reference 字段）

**示例：**文章 → 作者

Authors Collection:
├── name (Text, required)
├── slug (Text, required)
├── bio (Rich Text)
├── photo (Image)
├── title (Text) - job title
├── email (Email)
└── social-links (Link)

Posts Collection:
├── title (Text, required)
├── slug (Text, required)
├── content (Rich Text)
└── author (Reference → Authors)  ← Each post has ONE author

**显示：**在文章页面上，访问 author.name、author.photo、author.bio

**筛选：**可以按特定作者筛选文章

优点：

• ✅ 作者数据集中管理（更新一次，所有地方都会同步）
• ✅ 易于保持一致性
• ✅ 可以创建作者个人资料页面，展示其所有文章
• ✅ 高效（每篇文章只需一个引用）

使用场景：

• 博客文章 → 作者
• 产品 → 品牌
• 活动 → 场地
• 项目 → 客户
• 客户评价 → 客户

多对多（多重引用）

示例： 帖子 ↔ 标签

Tags Collection:
├── name (Text, required)
├── slug (Text, required)
├── description (Plain Text)
└── color (Color) - optional visual grouping

Posts Collection:
├── title (Text, required)
├── slug (Text, required)
├── content (Rich Text)
└── tags (Multi-Reference → Tags)  ← Each post has MANY tags

显示： 在帖子页面中遍历 tags，显示所有标签

筛选： 可按特定标签筛选帖子

优势：

• ✅ 灵活地组织内容
• ✅ 交叉链接相关内容
• ✅ 改善 SEO（主题聚类）
• ✅ 优化用户导航

限制：

• ⚠️ 每个集合最多可有 5 个多重引用字段
• ⚠️ 在集合列表中一次只能按一个多重引用值筛选
• ⚠️ 无法按引用字段的值排序
• ⚠️ 每个引用都会产生额外查询（影响性能）

多个标签筛选的变通方法：

1. 创建组合标签（例如，“素食-无麸质”）
2. 使用 Finsweet CMS Filter 在客户端进行筛选
3. 为常见组合创建单独的筛选集合列表
4. 使用 Webflow API 编写自定义代码

适用场景：

• 博客帖子 ↔ 标签
• 产品 ↔ 特性
• 项目 ↔ 技术
• 食谱 ↔ 食材
• 课程 ↔ 主题

自引用（嵌套集合）

示例： 带有子类别的类别

Categories Collection:
├── name (Text, required)
├── slug (Text, required)
├── description (Plain Text)
├── parent (Reference → Categories)  ← Self-reference for hierarchy
└── level (Number) - 1, 2, 3 for display logic

适用场景：

• 带有子类别的类别
• 带有子菜单项的菜单项
• 组织层级结构
• 产品分类体系

优势：

• ✅ 层级结构灵活
• ✅ 深度理论上不受限制
• ✅ 易于重新组织

限制：

• ⚠️ 在 Webflow 中显示嵌套层级较复杂
• ⚠️ 实际实施时建议最多 2-3 个层级
• ⚠️ 深层嵌套需要自定义逻辑

替代方案： 使用 Option 字段进行简单的 1-2 级分类

双向关系

示例： 相关文章

Posts Collection:
├── title (Text, required)
├── slug (Text, required)
├── content (Rich Text)
└── related-posts (Multi-Reference → Posts)  ← Self-reference to other posts

显示： 在帖子页面底部显示相关文章

优势：

• ✅ 让用户停留更久
• ✅ 改善 SEO（内部链接）
• ✅ 灵活地关联内容

挑战：

• ⚠️ 并非真正的双向关系（A → B 不会自动创建 B → A）
• ⚠️ 如有需要，必须手动维护两个方向的关系
• ⚠️ 内容编辑人员维护起来可能很耗时

解决方案：

1. 使用标签实现自动的“按标签关联”逻辑
2. 手动整理最重要的关联
3. 混合方式：手动关联 + 基于标签/类别的自动关联

示例

示例 1：规划新的 CMS 结构

用户提示词：

I'm building a recipe site. How should I structure the CMS?

步骤 1：收集需求

📐 CMS Planning: Recipe Site

Let me ask a few questions to design the best structure:

1. **Content Volume**: How many recipes do you plan to have?
   - Small (≤50): Simple structure
   - Medium (50-200): Moderate organization
   - Large (200+): Advanced taxonomy needed

2. **Recipe Attributes**: What information will each recipe have?
   - Basic: Name, ingredients, instructions, image
   - Advanced: Prep time, cook time, difficulty, nutrition, dietary tags

3. **Organization Needs**: How will users find recipes?
   - By meal type (breakfast, lunch, dinner)
   - By cuisine (Italian, Mexican, Asian)
   - By dietary restrictions (vegan, gluten-free, keto)
   - By cooking method (baking, grilling, slow cooker)
   - By ingredients (chicken, pasta, vegetables)

4. **Author Setup**: Single or multiple authors?
   - Single: You manage all content
   - Multiple: Team of recipe creators

5. **User Engagement**: What interactive features?
   - Comments/reviews
   - Ratings
   - Save favorites
   - Print recipe cards

Based on your answers, I'll design the optimal CMS architecture.

步骤 2：用户回复后

📐 Recommended CMS Architecture: Recipe Site

Based on your requirements (Medium volume, Multiple authors, Advanced filtering):

---

## Collections Needed: 4

### 1. Recipes (Main Content)
├── name (Text, required) - "Homemade Pasta Carbonara"
├── slug (Text, required) - "homemade-pasta-carbonara"
├── description (Plain Text, 160 chars) - Brief summary for SEO
├── featured-image (Image) - Hero image for detail page
├── thumbnail-image (Image) - Smaller image for grid cards
├── prep-time (Number, required) - Minutes of prep
├── cook-time (Number, required) - Minutes of cooking
├── total-time (Number) - Auto-calculated or manual
├── servings (Number, required) - Number of servings
├── difficulty (Option: Easy, Medium, Hard)
├── ingredients (Rich Text, required) - Ingredient list with quantities
├── instructions (Rich Text, required) - Step-by-step directions
├── notes (Rich Text) - Cook's notes, tips, substitutions
├── nutrition-info (Plain Text) - Calories, protein, etc.
├── author (Reference → Authors, required)
├── category (Reference → Categories, required) - Primary meal type
├── cuisine (Reference → Cuisines) - Italian, Mexican, etc.
├── dietary-tags (Multi-Reference → Dietary Tags) - Vegan, GF, etc.
├── cooking-methods (Multi-Reference → Methods) - Baking, Grilling, etc.
├── featured (Switch) - Highlight on homepage
├── published-date (Date, required)
└── view-count (Number) - Track popularity

**Total fields:** 22 fields
**Plan required:** CMS plan minimum (20 collections, 2000 items)

### 2. Authors
├── name (Text, required)
├── slug (Text, required)
├── title (Text) - "Head Chef", "Recipe Developer"
├── bio (Rich Text)
├── photo (Image)
├── specialty (Plain Text) - "Italian Cuisine", "Baking"
├── social-instagram (Link)
├── social-website (Link)
└── email (Email)

**Purpose:** Reusable author information across all recipes

### 3. Categories
├── name (Text, required) - "Breakfast", "Lunch", "Dinner", "Desserts"
├── slug (Text, required)
├── description (Plain Text)
├── image (Image) - Category hero image
├── color (Color) - Brand color for UI
└── sort-order (Number) - Control display order

**Purpose:** Primary meal type classification

**Suggested Categories (8):**
- Breakfast & Brunch
- Appetizers & Snacks
- Lunch
- Dinner & Main Courses
- Side Dishes
- Salads
- Desserts & Sweets
- Drinks & Beverages

### 4. Cuisines
├── name (Text, required) - "Italian", "Mexican", "Asian"
├── slug (Text, required)
├── description (Plain Text)
└── flag-icon (Image) - Optional visual

**Purpose:** Filter by cuisine type

**Suggested Cuisines (12):**
- American, Italian, Mexican, Asian, Mediterranean, French, Indian, Thai,
  Chinese, Japanese, Greek, Middle Eastern

### 5. Dietary Tags
├── name (Text, required) - "Vegan", "Gluten-Free", "Keto"
├── slug (Text, required)
├── description (Plain Text)
├── icon (Image) - Badge icon
└── color (Color) - Badge color

**Purpose:** Multi-select dietary filters

**Suggested Tags (10):**
- Vegetarian, Vegan, Gluten-Free, Dairy-Free, Keto, Paleo, Low-Carb,
  High-Protein, Nut-Free, Pescatarian

### 6. Cooking Methods
├── name (Text, required) - "Baking", "Grilling", "Slow Cooker"
├── slug (Text, required)
└── description (Plain Text)

**Purpose:** Filter by cooking technique

**Suggested Methods (8):**
- Baking, Grilling, Slow Cooker, Instant Pot, Stovetop, No-Cook,
  Air Fryer, Sous Vide

---

## Relationship Map

食谱 → 作者（一对多） ↓ 食谱 → 类别（一对多） ↓ 食谱 → 菜系（一对多） ↓ 食谱 → 饮食标签（多对多） ↓ 食谱 → 烹饪方法（多对多）

**Multi-reference count:** 2 fields (within 5-field limit ✅)

---

## Recommended Page Structure

### 1. Homepage (/)
- Hero section with featured recipe
- Category cards (8 categories)
- Latest recipes (collection list, 6 items)
- Popular recipes (sorted by view-count)
- Call-to-action

### 2. Recipes Index (/recipes)
- Collection list showing all recipes
- Filter sidebar:
  - Category (tabs or dropdown)
  - Cuisine (multi-select)
  - Dietary tags (checkboxes)
  - Cooking time (< 30 min, 30-60 min, 60+ min)
  - Difficulty (easy, medium, hard)
- Pagination (12 recipes per page)
- Search bar (Finsweet CMS Filter)

### 3. Recipe Detail (/recipes/[slug])
- Hero image + title
- Prep/cook/total time + servings
- Difficulty badge + dietary badges
- Ingredients list
- Step-by-step instructions
- Author card with bio
- Related recipes (same category or tags)
- Print button

### 4. Category Pages (/category/[slug])
- Category hero image + description
- Filtered recipes by category
- Breadcrumbs: Home > Recipes > [Category]
- Related categories

### 5. Cuisine Pages (/cuisine/[slug])
- Cuisine description + flag
- Filtered recipes by cuisine
- Popular cuisines sidebar

### 6. Author Profiles (/authors/[slug])
- Author photo + bio
- Author's recipes (collection list)
- Social links
- Author stats (total recipes, join date)

### 7. Dietary Filter Pages (/diet/[slug])
- Dietary tag description
- Filtered recipes by tag
- Related dietary tags

---

## SEO Optimization

### Collection Template SEO

食谱详情页（/recipes/[slug]）：

• SEO 标题：{{recipe.name}} | Your Site Name
• Meta 描述：{{recipe.description}}
• OG 图片：{{recipe.featured-image}}
• Schema：食谱结构化数据（JSON-LD）

### Structured Data (Recipe Schema)
```json
{
  "@context": "https://schema.org/",
  "@type": "Recipe",
  "name": "{{recipe.name}}",
  "image": "{{recipe.featured-image}}",
  "author": {
    "@type": "Person",
    "name": "{{recipe.author.name}}"
  },
  "datePublished": "{{recipe.published-date}}",
  "description": "{{recipe.description}}",
  "prepTime": "PT{{recipe.prep-time}}M",
  "cookTime": "PT{{recipe.cook-time}}M",
  "totalTime": "PT{{recipe.total-time}}M",
  "recipeYield": "{{recipe.servings}} servings",
  "recipeIngredient": [...],
  "recipeInstructions": [...]
}

优势：

• 在 Google 搜索中显示丰富摘要
• 提高 CTR（搜索结果中显示图片、评分和烹饪时间）
• 优化语音搜索
• 帮助用户更好地发现食谱

---

性能优化

适用于 50-200 道食谱：

1. 分页策略

Recipes Index page:
- Limit: 12 recipes per page
- Enable Webflow pagination
- "Load More" button for smoother UX

2. 图片优化

Thumbnail: 400x300px (grid cards)
Featured: 1200x800px (detail pages)
Format: WebP when possible
Loading: lazy for below-fold images

3. 引用字段策略

Display only needed fields:
- Author name + photo (don't bind entire author object)
- Category name + color (skip unused fields)
- Each reference = query, so minimize bindings

4. 集合列表限制

Homepage: 6 featured recipes
Category pages: 12 recipes per page
Author pages: 12 recipes per page
Related recipes: 3-4 max

---

内容策略

阶段 1：基础搭建（第 1-2 周）

• 创建作者（3-5 位作者）
• 创建类别（8 个类别）
• 创建菜系（10-12 种菜系）
• 创建饮食标签（8-10 个标签）
• 创建烹饪方法（6-8 种方法）

阶段 2：初始内容（第 3-4 周）

• 添加 20-30 道主打食谱
• 确保各类别内容分布均匀
• 为所有食谱添加高质量照片
• 完成元数据（填写所有字段）

阶段 3：增长（持续进行）

• 每周添加 5-10 道食谱
• 监控热门食谱（view-count）
• 更新季节性食谱
• 保持内容质量

---

实施路线图

第 1 周：设置

• 创建全部 6 个集合及其字段
• 定义关系（引用）
• 设置必填字段
• 为编辑人员添加帮助文本

第 2 周：内容结构

• 填充辅助集合（作者、分类等）
• 创建测试食谱（3-5 个），填写所有字段
• 验证数据结构

第 3 周：页面

• 构建首页布局
• 创建带筛选器的食谱索引页
• 设计食谱详情模板
• 构建分类/菜系/作者页面

第 4 周：完善

• 实施 SEO（标题、描述、架构）
• 添加面包屑和导航
• 优化图片
• 测试分页和筛选器

第 5 周：上线

• 添加 20-30 道初始食谱
• 最终 QA 测试
• 发布网站
• 监控性能

---

快速见效的改进

1. 使用浏览量显示“热门食谱”

• 添加 Number 字段：view-count
• 按 view-count 降序排列集合列表
• 在首页显示“最受欢迎”版块

2. 自动计算总用时

• 选项 1：手动填写（编辑者输入准备时间 + 烹饪时间）
• 选项 2：显示逻辑（在 UI 中显示准备时间 + 烹饪时间的总和）
• 最适合：追求性能（无需额外计算）

3. 适合打印的食谱卡片

• 添加“打印食谱”按钮
• 使用自定义代码设置打印格式
• 包含：食材、说明、图片
• 排除：导航、广告、评论

4. 相关食谱逻辑

自动生成（无需手动筛选）：

• 按相同分类筛选
• 按共同的饮食标签筛选
• 按 published-date 排序（最新优先）
• 限制为 3-4 道食谱

---

准备好开始实施了吗？我可以帮你：

1. 使用 cms-collection-setup skill 创建这些集合
2. 使用 bulk-cms-update skill 添加初始内容
3. 构建页面结构
4. 针对 SEO 和性能进行优化

你想从哪项开始？

### Example 2: Optimizing Existing CMS

**User prompt:**

我的集合列表在包含 500+ 个项目时运行缓慢。如何优化？

**Response:**

⚡ CMS 性能优化

正在分析包含 500+ 个项目的性能问题……

---

当前问题诊断

**问题：**在单个页面上加载 500+ 个项目
影响：

• 页面加载缓慢（5-10 秒或更久）
• 跳出率高
• SEO 排名不佳
• 用户体验差
• 服务器压力大

根本原因：

1. 一次加载的项目过多
2. 可能进行了过多的引用字段查询
3. 图片体积过大且未优化
4. 没有分页或延迟加载
5. 集合列表嵌套过于复杂

---

立即修复（影响大、工作量小）

1. 实施分页 ⚡ 关键

**当前：**加载全部 500+ 个项目
**修复：**每页限制为 12-20 个项目

在 Webflow Designer 中：

1. 选择你的 Collection List
2. Settings > Limit items：20
3. 启用“Paginate items”
4. 设置分页控件样式

**影响：**页面加载速度提升 95% ✅
**实施时间：**5 分钟
**工作量：**低

2. 优化图片加载 🖼️

**当前：**立即加载全分辨率图片
**修复：**使用合适的图片尺寸 + 延迟加载

实施：

Thumbnail images in grid:
- Size: 400x300px (not full resolution)
- Format: WebP (smaller file size)
- Loading: lazy (below fold images)

In Collection List Image settings:
- Set custom size: 400x300
- Enable lazy loading
- Use srcset for responsive images

**影响：**加载速度提升 60-70% ✅
**实施时间：**15 分钟
**工作量：**低

3. 减少显示的引用字段 🔗

**当前：**绑定所有引用字段
**修复：**只显示实际需要的内容

检查你的 Collection List：

❌ Bad: Binding entire author object
{
  author.name,
  author.bio,
  author.photo,
  author.email,
  author.social-links
}

✅ Good: Bind only displayed fields
{
  author.name,
  author.photo
}

**原因：**每个引用字段都会触发一次单独的数据库查询
**影响：**速度提升 30-40% ✅
**实施时间：**10 分钟
**工作量：**低

---

中期解决方案（中等影响、中等工作量）

4. 在集合级别进行筛选

**当前：**加载所有项目，然后通过条件可见性将其隐藏
**修复：**使用集合列表筛选器

示例：

Instead of:
- Load all 500 posts
- Hide if published-date > today (conditional)

Do this:
- Collection List Filter: published-date ≤ today
- Only loads matching items

实施：

1. Collection List Settings
2. 添加筛选条件：[字段] [条件] [值]
3. 使用 AND/OR 组合多个筛选条件

**影响：**速度提升 50%，结构也更简洁 ✅
**实施时间：**30 分钟
**工作量：**中

5. 实现“加载更多”按钮

分页的替代方案： 提供更流畅的用户体验

选项： a) Webflow 原生： 使用“加载更多”样式的分页 b) Finsweet： CMS Load 插件（免费） c) 自定义代码： 通过 AJAX 加载更多内容

优点：

• 用户留在当前页面（无需刷新页面）
• 提供更好的移动端体验
• 滚动体验流畅

影响： 提升用户体验，性能与分页相当 ✅ 实施时间： 1-2 小时 工作量： 中等

6. 创建筛选视图

替代方案： 创建一个庞大的“所有文章”页面 创建： 多个经过筛选的页面

示例：

/blog → Recent posts (20 items)
/blog/featured → Featured posts only (10 items)
/blog/category/tech → Tech category (filtered)
/blog/archive → Older posts with pagination

优点：

• 单个页面加载更快
• SEO 更好（可针对特定主题）
• 导航更轻松
• 减轻认知负担

影响： 显著改善用户体验 ✅ 实施时间： 2-3 小时 工作量： 中等

---

长期解决方案（影响大，工作量大）

7. 归档旧内容

策略： 动态展示近期内容 + 静态归档

实施：

Recent Content (Dynamic CMS):
- Last 50-100 posts
- Full dynamic filtering
- Fast performance

Older Content (Static):
- Archive pages for older posts
- Yearly/quarterly archives
- Still accessible but static HTML
- Rarely updated

适用情况：

• 内容数量超过 1000 项
• 近期内容与旧内容之间有明确区分
• 很少有人访问归档内容

影响： 在大规模内容下仍能保持快速性能 ✅ 实施时间： 1-2 周 工作量： 高

8. 数据反规范化

问题： 引用查找过多 解决方案： 复制经常访问的数据

示例：

Current (Normalized):
Post → Author (reference)
Display: {{post.author.name}}
= 2 queries (post + author)

Denormalized:
Post has author-name field (text)
Display: {{post.author-name}}
= 1 query (just post)

适用情况：

• 引用数据很少变化（如作者姓名）
• 性能至关重要
• 你能够保持数据一致性

权衡： ⚠️ 数据变化时必须在多个位置更新

影响： 引用密集型页面的速度提升 40-50% ✅ 实施时间： 因情况而异（需要迁移数据） 工作量： 高

9. 实现客户端筛选

使用： Finsweet CMS Filter（免费）

优点：

• 加载一次，即时筛选
• 无需刷新页面
• 支持多个筛选条件同时生效
• 支持搜索功能
• 提供更好的用户体验

最适合：

• 100-500 项内容
• 用户需要高级筛选功能
• 以桌面端用户为主的受众

限制： 初始加载时会加载所有内容（请配合分页使用）

影响： 即时筛选 ✅ 实施时间： 2-4 小时 工作量： 中等偏高

---

全面优化清单

立即执行（今天）：

• 将集合列表限制为 20 项
• 启用分页
• 优化图片尺寸（缩略图设为 400x300）
• 为图片启用延迟加载
• 移除未使用的引用字段绑定

本周：

• 为集合列表添加筛选器（日期、类别）
• 创建经过筛选的类别页面
• 在移动设备上测试性能
• 如有需要，实现“加载更多”功能
• 审查网站上的所有集合列表

本月：

• 考虑使用 Finsweet CMS Filter 实现高级筛选
• 如果内容超过 1000 项，创建归档结构
• 优化所有图片（WebP 格式）
• 检查并优化引用关系
• 设置性能监控

---

性能基准

优化前：

• 加载时间：8-12 秒
• 加载项数：500+
• 图片：全分辨率
• 引用：所有字段

快速修复后（分页 + 图片）：

• 加载时间：1-2 秒 ✅
• 加载项数：20
• 图片：经过优化的缩略图
• 引用：仅显示的字段

全面优化后：

• 加载时间：<1 秒 ✅
• Lighthouse 得分：90+ ✅
• 分页流畅
• 客户端筛选即时生效

---

测试更改

部署前：

1. 在预发布环境测试：

   • 先发布到预发布域名
   • 确认分页正常工作
   • 检查图片质量
   • 测试所有筛选器

2. 性能测试：

   • 使用 Google PageSpeed Insights
   • 在移动设备上测试（3G/4G）
   • 检查 Lighthouse 得分
   • 确认 Core Web Vitals

3. 用户测试：

   • 浏览各个页面
   • 测试搜索和筛选
   • 检查移动端体验
   • 确认没有失效链接

4. 上线后监控：

   • 关注分析数据（跳出率、页面停留时间）
   • 检查错误日志
   • 监控加载时间
   • 收集用户反馈

---

快速实施优先级

优先级 1（先做）：

1. 分页（每页 20 项）
2. 优化图片（缩略图）
3. 移除未使用的引用绑定

优先级 2（本周）： 4. 添加延迟加载 5. 创建筛选视图 6. 实现“加载更多”选项

优先级 3（如有需要）： 7. Finsweet CMS Filter 8. 归档旧内容 9. 对关键数据进行反规范化

---

你想让我带你逐步实施其中任何一项优化吗？我可以提供：

• Webflow Designer 分步说明
• 自定义代码片段
• 测试清单
• 性能监控设置

告诉我你想先处理哪项优化！

### Example 3: Troubleshooting Relationships

**User prompt:**

我的引用字段没有显示在页面上。怎么回事？

**Response:**

🔍 故障排除：引用字段未显示

我来帮你诊断并解决这个问题。

---

常见原因与解决方案

问题 1：引用字段未绑定到元素

症状： 应显示数据的位置为空白 诊断： 元素存在，但未绑定数据

修复方法：

1. 选择元素（文本、图片等）
2. 设置面板 > 从 [Collection Item] 获取文本/图片
3. 选择你的引用字段
4. 选择要显示的具体字段

示例：

Element: Text Block
Binding: Blog Post > Author (reference) > Name

Correct path:
Collection Item > author > name

问题 2：引用字段没有值

症状： 部分项目显示数据，其他项目不显示 诊断： 并非所有集合项目都设置了引用

修复方法：

1. 前往 CMS Collections
2. 打开你的集合
3. 检查未显示的项目
4. 确保引用字段已填充

预防措施：

• 如果引用字段很重要，请将其设为“必填”
• 提供默认/备用内容

问题 3：集合上下文错误

症状： 下拉列表中未显示引用字段 诊断： 元素位于集合列表上下文之外

修复方法：

❌ Wrong:
<div>
  <text>Author: {{author.name}}</text> ← No collection context
</div>

✅ Correct:
<Collection List - Posts>
  <Collection Item>
    <text>Author: {{author.name}}</text> ← Inside collection context
  </Collection Item>
</Collection List>

问题 4：多重引用显示错误

症状： 只显示第一项或什么都不显示 诊断： 多重引用需要嵌套集合列表

修复方法：

For Multi-Reference field (Post → Tags):

❌ Wrong: Direct binding
<text>Tags: {{post.tags}}</text>

✅ Correct: Nested collection list
<Collection List - Posts>
  <Collection Item - Post>
    <Collection List - Get Items from Post > Tags>
      <Collection Item - Tag>
        <text>{{tag.name}}</text>
      </Collection Item>
    </Collection List>
  </Collection Item>
</Collection List>

问题 5：被引用的项目已删除

症状： 引用字段已设置，但仍不显示内容 诊断： 被引用的项目已从另一个集合中删除

修复方法：

1. 前往引用方集合
2. 检查引用字段的设置
3. 重新指定现有项目
4. 或重新创建已删除的项目

预防措施：

• 删除被引用的项目时要小心
• 删除前检查“用于 X 个项目”
• 如有可能，归档而非删除

问题 6：集合尚未发布

症状： 在设计器中正常，在线上网站中不显示 诊断： 被引用集合中的项目是草稿

修复方法：

1. 前往被引用的集合（例如 Authors）
2. 找到草稿项目
3. 发布这些项目
4. 重新发布主站点

检查：

CMS Collections > Authors
- Look for "Draft" badge
- Publish all needed items
- Items must be published to display via reference

---

分步诊断

步骤 1：验证集合结构

Check in CMS:
1. Does the reference field exist?
2. Is it configured correctly (Reference or Multi-Reference)?
3. Is it pointing to the right collection?

步骤 2：验证数据是否存在

Check collection items:
1. Open an item that should display
2. Check if reference field is populated
3. Verify referenced item exists and is published

步骤 3：验证页面结构

Check in Designer:
1. Is element inside Collection List?
2. Is Collection List connected to correct collection?
3. Is element binding correct path?

步骤 4：在设计器中测试

In Designer:
1. Click Collection List
2. Set preview mode: "Item 1"
3. Cycle through items
4. Check if data appears

If it works in Designer but not live:
→ Publish issue (republish site)

---

测试引用字段

手动测试清单

• 创建一个已填充引用字段的测试项目
• 在设计器中预览
• 检查元素绑定路径
• 发布并查看线上页面
• 确认所有项目均正确显示
• 检查未设置引用的项目（应能妥善处理）

常见绑定模式

单一引用（作者）：

Collection List: Posts
Collection Item: Post
Element: Text Block
Binding: Get text from Post > author > name

多重引用（标签）：

Collection List: Posts
Collection Item: Post
  Nested Collection List: Get items from Post > tags
  Collection Item: Tag
    Element: Text Block
    Binding: Get text from Tag > name

自引用（相关文章）：

Collection List: Posts
Collection Item: Post (current)
  Nested Collection List: Get items from Post > related-posts
  Collection Item: Post (related)
    Element: Text Block
    Binding: Get text from Post > title

---

预防建议

最佳实践：

1. 将关键引用设为必填

   • 必填：是，作者、分类
   • 可选：是，标签、相关条目

2. 提供默认内容

   • 如果引用为空，则显示“未分类”
   • 对可选引用使用条件可见性

3. 使用不完整数据进行测试

   • 创建缺少引用的测试条目
   • 确保能够优雅回退

4. 记录引用结构

   • 为内容编辑者创建指南
   • 说明哪些字段为必填
   • 展示如何分配引用

5. 使用描述性字段名称

   • ❌ “ref-1”、“link”
   • ✅ “author”、“primary-category”、“related-posts”

---

按症状快速修复

症状	最可能的原因	快速修复
没有任何内容显示	未绑定	将元素绑定到引用字段
某些条目为空	未分配引用	在 CMS 中分配引用
在设计器中正常，线上却不行	条目尚未发布	发布被引用的集合条目
只显示第一个标签	对多重引用使用了文本绑定	使用嵌套集合列表
显示随机数据	集合上下文错误	检查集合列表的嵌套
删除后失效	被引用的条目已删除	重新分配或重新创建条目

---

你希望我检查你的具体设置并诊断确切问题吗？我可以：

• 检查你的集合结构
• 检查你的引用字段配置
• 分析你的页面布局
• 测试你的数据绑定
• 提供定制化故障排查建议

告诉我你希望我检查什么！

## Guidelines

### Phase 1: Discovery Best Practices

**Always Start With:**
1. **Identify plan limits** - Use `data_sites_tool` with action `get_site` to check collection/item limits
2. **Analyze existing structure** - List collections before recommending changes
3. **Understand content volume** - Check item counts to assess scale
4. **Review current pages** - See how content is currently displayed
5. **Ask clarifying questions** - Don't assume requirements

**Plan Limits Reference:**

入门版计划：

• 集合：1
• 每个集合的条目数：50
• CMS 页面：50

基础版计划：

• 集合：2
• 条目总数：200
• CMS 页面：150

CMS 计划：

• 集合：20
• 条目总数：2,000
• CMS 页面：2,000

商业版计划：

• 集合：40
• 条目总数：10,000
• CMS 页面：10,000

企业版计划：

• 自定义限制

**Key Questions to Ask:**
1. "What content needs to be managed?" (identify collections)
2. "Who will update the content?" (determine complexity level)
3. "How will content be displayed?" (affects fields and relationships)
4. "What's the expected content volume?" (plan for scale)
5. "Are there any special requirements?" (unique features, integrations)

### Phase 2: Field Selection Best Practices

**Field Type Selection Matrix:**

**For Text Content:**
- **<50 characters:** Plain Text (single line)
- **50-256 characters:** Plain Text (multi-line)
- **Need formatting:** Rich Text
- **Pure data (no display):** Plain Text (validation enabled)

**For Relationships:**
- **One parent:** Reference (e.g., Post → Author)
- **Multiple parents:** Multi-Reference (e.g., Post → Tags)
- **Self-referencing:** Reference to same collection (e.g., Category → Parent Category)

**For Media:**
- **Hero images:** Image field (1 image)
- **Galleries:** Multi-image field (up to 25 images)
- **Documents:** File field (PDFs, docs)
- **Videos:** Video field (YouTube/Vimeo embeds)

**For Metadata:**
- **Dates:** Date/Time field
- **Numbers:** Number field (prices, counts, ratings)
- **Colors:** Color field (brand colors, theme colors)
- **Switches:** Boolean field (featured, published, active)

**Field Naming Conventions:**

✅ 好的名称：

• published-date（描述明确，使用连字符）
• author（用途清晰）
• main-image（明确指出是哪张图片）
• post-summary（说明使用场景）

❌ 不好的名称：

• date1（不清楚指的是哪个日期）
• img（是哪张图片？）
• text（是哪种文本？）
• field1（没有含义）

**Required vs Optional:**

设为必填：

• name（唯一标识符）
• slug（用于生成 URL）
• 主要关联（作者、分类）
• 发布日期（用于排序）

设为可选：

• 标签（不一定适用）
• 次要图片
• 高级元数据
• 相关条目

### Phase 3: Relationship Design Best Practices

**One-to-Many Guidelines:**

适用于：

• 每个条目恰好有一个父级
• 父级数据会在多个条目中重复使用
• 希望集中管理数据

示例： ✅ 文章 → 作者（每篇文章有一位作者） ✅ 产品 → 品牌（每个产品有一个品牌） ✅ 活动 → 场地（每场活动有一个场地）

不适用于： ❌ 条目可以有多个父级（请使用多重引用） ❌ 关联是临时的（可以考虑选项字段） ❌ 数据简单且很少变动（请改用选项字段）

**Many-to-Many Guidelines:**

适用于：

• 条目可以有多个关联
• 关联需要单独管理
• 希望灵活地交叉链接

示例： ✅ 文章 ↔ 标签（文章可以有多个标签，一个标签也可用于多篇文章） ✅ 产品 ↔ 功能（产品可以有多项功能，一项功能也可用于多个产品） ✅ 课程 ↔ 主题（课程涵盖多个主题，一个主题也可出现在多门课程中）

请记住： ⚠️ 每个集合最多可有 5 个多重引用字段 ⚠️ 一次只能按一个多重引用进行筛选 ⚠️ 无法按被引用字段的值排序 ⚠️ 会影响性能（需要更多查询）

**Self-Reference Guidelines:**

适用于：

• 构建层级结构（分类、菜单结构）
• 关联同一集合中的条目
• 构建组织树

实现方式：

• 添加指向同一集合的引用字段
• 使用清晰的名称：parent-category、related-posts
• 将层级深度限制为 2–3 层，以便实际展示
• 考虑添加“level”数字字段，以便更轻松地筛选 示例结构： 分类： ├── Web 开发（级别 1，父级：null） │ ├── 前端（级别 2，父级：Web 开发） │ └── 后端（级别 2，父级：Web 开发） └── 设计（级别 1，父级：null）

### Phase 4: Architecture Patterns

**Common Collection Patterns:**

**1. Blog Architecture:**

精简版（1 个集合）：

• 博客文章

标准版（3 个集合）：

• 博客文章
• 作者
• 分类

高级版（5 个或更多集合）：

• 博客文章
• 作者
• 分类
• 标签
• 主题/系列

**2. E-commerce Architecture:**

精简版（1 个集合）：

• 产品

标准版（4 个集合）：

• 产品
• 分类
• 品牌
• 特性/规格

高级版（7 个或更多集合）：

• 产品
• 分类
• 品牌
• 特性
• 评价
• 合集（精选产品分组）
• 相关产品

**3. Portfolio Architecture:**

精简版（1 个集合）：

• 项目

标准版（3 个集合）：

• 项目
• 客户
• 服务/分类

高级版（5 个或更多集合）：

• 项目
• 客户
• 服务
• 团队成员
• 使用的技术

**4. Directory Architecture:**

精简版（1 个集合）：

• 房源

标准版（4 个集合）：

• 房源
• 分类
• 地点
• 业主/经理

高级版（6 个或更多集合）：

• 房源
• 分类
• 子分类
• 地点（分层级）
• 配套设施/特性
• 评价/评分

### Phase 5: Performance Optimization

**Pagination Strategy:**

内容量 → 每页条目数：

• 0-50 个条目：无需分页
• 50-100 个条目：每页 20 个条目
• 100-500 个条目：每页 15-20 个条目
• 500-1000 个条目：每页 12-15 个条目
• 1000 个以上条目：每页 10-12 个条目 + 高级筛选

**Image Optimization:**

用途 → 建议尺寸：

• 缩略图（网格卡片）：400x300px
• 特色图片（主视觉）：1200x800px
• 图库图片：800x600px
• 背景图片：1920x1080px

格式优先级：

1. WebP（压缩效果最佳，适用于现代浏览器）
2. JPEG（照片、复杂图像）
3. PNG（需要透明背景、简单图形）
4. SVG（徽标、图标、简单图形）

**Reference Field Strategy:**

优化级别：

级别 1 - 只显示需要的内容： ❌ 绑定整个作者对象：{{author}} ✅ 绑定特定字段：{{author.name}}、{{author.photo}}

级别 2 - 对关键数据进行反规范化： 替代方案：Post → Author.name（2 次查询） 存储为：Post.author-name（1 次查询） 适用场景：性能至关重要且数据很少变化时

级别 3 - 延迟加载相关内容： 立即显示主要内容 在交互时加载相关条目（点击、滚动） 减少初始页面加载量

**Collection List Optimization:**

最佳实践：

1. 在集合级别筛选： ✅ 使用原生集合列表筛选器 ❌ 加载所有条目后再用条件隐藏

2. 限制条目数量： ✅ 设置合理的上限（12-20 个条目） ❌ 加载无限数量的条目

3. 优化嵌套列表： ✅ 将嵌套集合列表限制为 3-5 个条目 ❌ 嵌套多个无限列表

4. 使用条件加载： ✅ 根据视口加载内容 ❌ 一次性加载所有内容

5. 实现分页： ✅ 启用 Webflow 分页或“加载更多” ❌ 使用包含所有条目的无限滚动

### Phase 6: SEO Best Practices

**Collection Template SEO:**

必填字段：

1. SEO 标题（根据条目名称动态生成）
2. Meta 描述（根据摘要/描述动态生成）
3. OG 图片（根据特色图片动态生成）
4. Canonical URL（自动生成）

建议： 5. Schema.org 结构化数据（JSON-LD） 6. Open Graph 标签（Facebook/LinkedIn） 7. Twitter Card 标签 8. 所有图片的替代文本

**Slug Best Practices:**

✅ 良好的 Slug：

• webflow-cms-best-practices
• ultimate-guide-to-seo
• 2026-web-design-trends

❌ 不良的 Slug：

• Post1
• new-post-copy-3
• untitled-entry

规则：

• 仅使用小写字母
• 使用连字符（不要使用下划线）
• 不含特殊字符
• 描述清晰（包含关键词）
• 最多 50-60 个字符

**Structured Data Implementation:**

常见类型：

博客文章（Article schema）：

• headline、author、datePublished、image
• 用途：博客文章、新闻报道

产品（Product schema）：

• name、description、price、availability、image
• 用途：电商产品

活动（Event schema）：

• name、startDate、location、organizer
• 用途：活动、网络研讨会、会议

食谱（Recipe schema）：

• name、ingredients、instructions、cookTime
• 用途：食谱网站、美食博客 本地商家（LocalBusiness 架构）：
• 名称、地址、电话、营业时间
• 用于：目录、商家列表

### Phase 7: Editorial Workflow

**Content Editor Guidelines:**

**Field Usage Documentation:**

为每个集合创建指南：

示例 - 博客文章集合：

1. 名称*（必填）

   • 文章标题
   • 控制在 60 个字符以内，以利于 SEO
   • 让标题引人注目且描述清晰

2. Slug*（必填）

   • 根据名称自动生成
   • 可以编辑以优化 SEO
   • 仅使用连字符和小写字母

3. 文章摘要

   • 简短描述（最多 160 个字符）
   • 用于：网格卡片、元描述、社交分享
   • 撰写引人入胜的内容——这是用户首先看到的内容

4. 特色图片*

   • 文章的主图
   • 最小尺寸：1200x800px
   • 务必添加替代文本以提升无障碍性

5. 作者*

   • 从作者列表中选择
   • 找不到作者？请联系管理员在作者集合中创建

...（记录所有字段）

**Required Field Checklist:**

发布前： □ 已填写名称 □ 已设置 Slug（避免使用“untitled”等通用 Slug） □ 已撰写摘要（引人入胜，160 个字符以内） □ 已上传带替代文本的特色图片 □ 已指定作者 □ 已选择类别 □ 已设置发布日期 □ 已校对内容 □ 已测试链接 □ 已优化图片 □ 已检查 SEO

**Draft → Published Workflow:**

1. 创建为草稿：

   • 至少填写必填字段
   • 保存以保留工作内容

2. 完善内容：

   • 撰写或上传所有内容
   • 添加带替代文本的图片
   • 设置元数据

3. 内部审核：

   • 校对
   • 检查格式
   • 测试链接
   • 核对引用

4. 发布：

   • 设置发布日期
   • 将状态从草稿改为已发布
   • 在正式网站上确认
   • 分享/推广

5. 后续工作：

   • 根据需要更新
   • 监控表现
   • 更新过时内容
   • 不再相关时归档

### Phase 8: Migration Strategy

**When Refactoring Existing CMS:**

**Assessment Phase:**

1. 审核当前结构：

   • 列出所有集合
   • 统计每个集合中的项目数量
   • 梳理关系
   • 找出问题

2. 设计新结构：

   • 规划改进
   • 设计新集合
   • 定义新关系
   • 制定迁移计划

3. 验证方案：

   • 使用示例数据进行测试
   • 确认关系正常
   • 检查性能
   • 获得利益相关方批准

**Migration Approaches:**

**Approach 1: Parallel Build (Safest)**

1. 在旧集合旁创建新集合
2. 逐步迁移内容
3. 彻底测试
4. 将页面切换到新集合
5. 归档旧集合

优点： ✅ 无停机时间 ✅ 易于回滚 ✅ 在完全切换前进行测试

缺点： ❌ 内容暂时重复 ❌ 时间线更长 ❌ 暂时需要同时管理两套系统

**Approach 2: Direct Migration (Faster)**

1. 创建新集合
2. 从旧集合导出数据
3. 转换数据格式
4. 导入到新集合
5. 更新页面以使用新集合
6. 删除旧集合

优点： ✅ 完成速度更快 ✅ 平滑切换 ✅ 不会出现重复内容

缺点： ❌ 风险更高 ❌ 可能出现停机时间 ❌ 更难回滚

**Approach 3: Hybrid (Recommended)**

1. 创建新结构
2. 分批迁移（每批 50-100 个项目）
3. 测试每一批
4. 逐步更新页面
5. 监控问题
6. 完成全部迁移

优点： ✅ 风险与速度较为平衡 ✅ 可以及早发现问题 ✅ 逐步测试

缺点： ❌ 需要谨慎规划 ❌ 执行更复杂

### Phase 9: Troubleshooting Common Issues

**Issue: "Collection won't save"**

可能原因：

1. 必填字段为空
2. Slug 冲突（重复）
3. Slug 中包含无效字符
4. 引用指向已删除的项目
5. 字段验证失败

诊断：

• 检查是否有红色高亮字段
• 确认 Slug 唯一
• 尝试不填写可选字段
• 检查浏览器控制台中的错误

解决方法：

• 填写所有必填字段
• 修改 Slug，使其保持唯一
• 删除特殊字符
• 重新指定引用
• 如果问题仍然存在，请联系 Webflow 支持

**Issue: "Reference field not showing options"**

可能原因：

1. 被引用的集合中没有项目
2. 被引用集合中的项目尚未发布
3. 在引用设置中选择了错误的集合
4. 浏览器缓存问题 修复：
5. 先在引用的集合中创建项目
6. 发布引用集合中的所有项目
7. 仔细检查引用字段配置
8. 清除缓存并刷新

**Issue: "Collection list showing wrong items"**

可能原因：

1. 选择了错误的集合
2. 筛选器配置错误
3. 限制数量设置过低
4. 项目尚未发布
5. 选择了错误的 CMS 区域设置

诊断：

• 检查集合列表设置
• 检查筛选条件
• 检查项目发布状态
• 确认区域设置是否正确

修复：

• 选择正确的集合
• 调整或移除筛选器
• 增加限制数量
• 发布项目
• 切换到正确的区域设置

**Issue: "Pagination not working"**

可能原因：

1. 未启用分页
2. 限制数量大于或等于项目总数
3. JavaScript 冲突
4. 自定义代码造成干扰

修复：

1. 在集合列表设置中启用分页
2. 将限制数量设为小于项目总数（例如，20）
3. 禁用所有自定义代码进行测试
4. 检查控制台中的 JavaScript 错误

**Issue: "Multi-reference only showing first item"**

原因：显示方式错误

修复： 必须使用嵌套集合列表： ❌ 直接绑定文本 ✅ Collection List > Get items from [field] > Collection Item > Display

示例： <Collection List - Posts> <Collection Item - Post> 标签： <Collection List - Get items from Post > tags> <Collection Item - Tag> {{tag.name}} </Collection Item> </Collection List> </Collection Item> </Collection List>

### Phase 10: Advanced Techniques

**Conditional Display Based on References:**

用例：根据类别显示不同的布局

实现：

1. 为元素添加条件可见性
2. 条件：Category = "视频文章"
3. 显示视频播放器布局
4. 条件：Category = "图片文章"
5. 显示图片库布局

限制：一次只能检查一个值 替代方案：使用选项字段设置类名，并动态应用类

**Scheduled Publishing:**

实现：

1. 添加“发布日期”字段（日期/时间）
2. 在集合列表设置中：
   • 添加筛选条件：发布日期 ≤ 当前日期
3. 为项目设置未来日期以安排发布

优点：

• 无需插件
• Webflow 原生功能
• 项目会在设定日期自动显示

限制：项目仍然存在，只是被筛选掉，并非真正取消发布

**Dynamic Sorting:**

选项 1：手动排序

• 添加“排序顺序”数字字段
• 手动分配：1、2、3、4……
• 按“排序顺序”对集合列表排序（升序）

选项 2：按互动数据自动排序

• 添加“浏览量”数字字段
• 在页面浏览时递增（需要自定义代码）
• 按“浏览量”排序（降序），用于“热门”列表

选项 3：按日期排序

• 按发布日期排序（降序），用于“最新”
• 按创建日期排序，用于“时间顺序”
• 与筛选器结合，用于“本月热门文章”

**Multi-Lingual Content:**

方案 1：每种语言使用独立集合

• 英文博客文章
• 西班牙文博客文章
• 法文博客文章

优点：简单，使用 Webflow 原生功能 缺点：必须重复创建结构，维护难度更高

方案 2：语言字段 + 筛选器

• 添加“语言”选项字段（EN、ES、FR）
• 按语言筛选集合列表
• 使用 URL 参数或 Cookie 切换语言

优点：使用单一结构，更易维护 缺点：所有内容都在同一个集合中

方案 3：Webflow Localization（CMS Plan+）

• 使用 Webflow 原生本地化功能
• 创建次要区域设置
• 按区域设置翻译 CMS 内容

优点：官方方案，SEO 效果最佳 缺点：需要 CMS plan+，设置较复杂

**Search Functionality:**

选项 1：原生功能（有限）

• 在集合列表中使用筛选输入框
• 仅支持基础关键词匹配
• 不支持模糊搜索或相关性排序

选项 2：Finsweet CMS Filter（免费）

• 在客户端进行搜索和筛选
• 可与现有集合列表配合使用
• 支持同时应用多个筛选条件
• 需要 JavaScript

选项 3：Algolia/自定义方案（高级）

• 使用 AI 进行服务端搜索
• 支持拼写容错和同义词
• 快速且可扩展
• 需要集成，且需要付费

建议：

• 少于 100 个项目：原生功能或 Finsweet
• 100–1000 个项目：Finsweet
• 1000 个以上项目：考虑使用 Algolia

## Production Checklist

Before launching CMS-driven site:

**Structure:**
- [ ] All collections created with proper field types
- [ ] Required fields set appropriately
- [ ] Help text added for content editors
- [ ] Relationships configured correctly
- [ ] Self-references working properly
- [ ] Validation rules set on text fields

**Content:**
- [ ] Test items created for all collections
- [ ] All reference fields populated in test items
- [ ] Images optimized (size, format, alt text)
- [ ] Slugs follow naming conventions
- [ ] Published dates set on items
- [ ] Draft items clearly marked

**Pages:**
- [ ] Collection lists limited appropriately (12-20 items)
- [ ] Pagination enabled on large lists
- [ ] Filters configured correctly
- [ ] Multi-reference fields use nested collection lists
- [ ] Conditional visibility works as expected
- [ ] Empty states handled gracefully

**SEO:**
- [ ] Collection template has SEO title binding
- [ ] Meta descriptions bound to summary fields
- [ ] OG images bound to featured images
- [ ] Structured data implemented (if applicable)
- [ ] Alt text present on all images
- [ ] Slugs are SEO-friendly

**Performance:**
- [ ] Images lazy loading enabled
- [ ] Only displayed reference fields bound
- [ ] Collection lists use filters (not conditional hiding)
- [ ] Pagination prevents loading too many items
- [ ] Performance tested on mobile
- [ ] Lighthouse score >80

**Documentation:**
- [ ] Field usage guide created for editors
- [ ] Collection structure documented
- [ ] Relationship map created
- [ ] Publishing workflow defined
- [ ] Troubleshooting guide available
- [ ] Contact for technical support identified

**Testing:**
- [ ] All collection lists display correctly
- [ ] Pagination works
- [ ] Filters work
- [ ] Search works (if implemented)
- [ ] Reference fields display data
- [ ] Multi-reference lists show all items
- [ ] Empty states handled
- [ ] Mobile experience tested
- [ ] Cross-browser tested
- [ ] Performance benchmarked

**Launch:**
- [ ] Content editors trained
- [ ] Editorial calendar established
- [ ] Publishing workflow in place
- [ ] Monitoring setup (analytics, errors)
- [ ] Backup strategy defined
- [ ] Support plan in place