WordPress 自定义文章类型规划清单：主题开发前先做

自定义文章类型可以让 WordPress 网站更容易维护，也可能做成一个只有原开发者看得懂的 CMS。差别在于规划。主题开发开始前，团队应该知道哪些内容需要自己的类型，哪些内容应该保留为页面，以及编辑如何创建、关联、翻译、归档和停用这些内容。

这份清单适合正在规划 WordPress 改版或定制主题的服务型企业、B2B 团队、内容团队和电商周边品牌。建议在 wireframe 定稿前、字段组开发前、内容迁移开始前使用。

先列出业务需要反复发布的内容。常见例子包括案例、服务、团队成员、资源、地点、活动、职位、合作伙伴、产品、文档、FAQ 和客户评价。不要因为一个页面设计会重复，就创建自定义文章类型。只有当内容有重复结构、独立归档、明确负责人，并且需要被查询或复用时，才适合做成 CPT。

每个候选内容都要记录负责人、更新频率、是否需要被搜索收录、会出现在网站哪些位置，以及过期后如何处理。这样 CMS 模型会服务运营，而不是只服务设计偏好。

• 列出每组可重复内容，并标记为可发布、可复用、私有或临时。
• 记录业务负责人、编辑负责人、更新频率和复查周期。
• 确认内容是否需要归档页、站内搜索、feed、重定向或翻译。

很多 WordPress 规划问题来自内容结构选错。自定义文章类型适合需要独立 URL、模板、归档、权限、元数据和关联关系的条目。分类法适合分组或筛选条目。字段适合属于某个条目的具体值。普通页面适合独立且很少复用的内容。

这些决定要在开发前完成，因为后期修改会影响 URL、迁移、模板、查询、重定向、分析追踪和 SEO 报告。一个清晰的模型应该很容易解释。如果团队需要一张复杂图才能记住内容应该放哪里，就应该简化。

• 重复条目有自己的详情模板和生命周期时，使用 CPT。
• 需要分组、筛选、导航或交叉链接时，使用分类法。
• 客户名称、项目年份、阅读时间、CTA 或头图等值，使用字段。
• 关于我们、联系页、隐私政策和活动落地页等一次性内容，使用页面。

自定义文章类型也是一个 URL 决策。需要定义 slug、归档页 URL、详情页 URL、分页、面包屑路径、canonical 规则，以及分类 term 页是否应该被索引。这些选择会影响技术 SEO、sitemap 规则、重定向表、内部链接和内容迁移。

不要把 URL 决策留到开发最后。如果案例从 /work/project-name 改到 /case-studies/project-name，重定向表、模板、分析备注和内部链接都要知道。如果某个 CPT 是私有内容或只用于嵌入卡片，它可能根本不需要公开 URL。

• 定义详情页 URL、归档页 URL、分类 URL 和 canonical 规则。
• 决定哪些归档页和 term 页应该可索引、noindex 或隐藏。
• 迁移开始前先映射旧 URL 和内容 ID。
• 确认面包屑和内部链接与最终 URL 模型一致。

编辑看到的自定义文章类型，是字段、标签、帮助说明、预览、默认值和校验。如果字段模糊，前端会越来越不一致。如果字段过于僵硬，每个正常变化都会需要开发支持。请把每个 CPT 编辑界面当作给内容团队使用的小产品来设计。

每个字段都要定义标签、预期格式、是否必填、字符建议、图片比例、空值处理，以及字段会出现在前端哪里。编辑不应该通过查看线上主题来猜一个字段控制什么。

• 使用清楚字段名，例如客户、行业、结果、CTA 文案和特色图片。
• 只有缺失会破坏模板或 SEO 时，才把字段设为必填。
• 为图片裁切、摘要长度、链接格式和可选模块添加帮助说明。
• 记录空字段、缺失图片和未发布关联内容的 fallback 行为。

真正好用的 WordPress 网站会连接内容。服务关联案例，资源关联作者和主题，地点关联团队和服务。如果这些关系规划得太晚，开发者通常会把它们硬编码进模板，之后编辑就会变慢、变脆弱。

需要定义哪些关联由编辑手动选择，哪些自动生成，哪些基于分类法。手动关联给编辑更多控制，自动关联减少维护，分类法关联适合内容量大且标签规则清楚的场景。不要没有规则地混用三种方式。

• 列出每个相关内容模块，并决定是否由编辑手动选择条目。
• 用分类法做大范围分组，用字段做精选关联。
• 设置数量限制，例如 3 篇相关资源或 4 个精选案例。
• 定义关联条目处于草稿、未发布或缺失时页面显示什么。

自定义文章类型在迁移第一条内容之前，就需要 SEO 规则。每种类型的 title tag、meta description、Open Graph 图片、Schema、面包屑、XML sitemap、canonical 和 noindex 规则都要明确。博客文章的默认规则，通常不适合案例、服务、地点、活动或资源库。

这一步也要决定哪些字段会用于结构化数据。案例可能需要客户、行业、结果、日期和服务字段。活动可能需要开始时间、地点、主办方和状态。如果 CMS 没有收集这些数据，主题就无法稳定输出 Schema。

• 为每个 CPT 写出默认 title 和 meta description 规则。
• 字段组定稿前，先确定 Schema 类型和必需字段。
• 检查 sitemap 收录、canonical、noindex 和归档分页规则。
• 为没有自定义图片的条目设置社交分享图 fallback。

如果改版包含旧内容，迁移规划必须基于 CPT 模型。把旧内容类型、表格列、CMS 导出、媒体文件、作者、分类、标签、重定向和内部链接映射到新结构。每个必填字段都需要来源、默认值或人工清理负责人。

QA 不应该只用新的示例内容，也要测试真实迁移条目。请选择边界情况：长标题、缺失图片、旧 URL、重复 slug、已停用服务、翻译条目、异常分类、没有关联内容的条目。这些情况能暴露模型是否经得起上线。

• 导入工作开始前，为每个 CPT 创建字段映射表。
• 用长文本、缺失媒体、重复 slug 和历史重定向测试迁移条目。
• 迁移后检查正文内部链接，避免旧路径继续留在内容里。
• 为无法干净迁移的条目保留清理队列。