先给结论:字段取舍不能按“旧系统里有什么”决定,而应按“这个字段在新站上会不会产生可被用户看到、可被链接指向、可被后续维护的独立价值”来决定。假设你从一个旧CMS迁到新CMS,旧库有120个字段,新库只支持40个,其中一部分字段还改了类型。此时正确的动作不是把120个字段硬塞进富文本,而是先做字段分级,再决定哪些保留、哪些合并、哪些只留历史备份。
旧系统字段看起来都是“内容”,实际上承担的角色不同。迁移时先给每个字段贴标签,能避免把结构化数据降级成不可维护的文本块。
假设旧站有一个“产地”字段,前台只在部分产品页显示,同时后台用它做筛选。新系统没有独立产地字段,只有标签和自定义字段两种容器。此时产地应优先进入自定义字段,而不是写进正文,因为正文里的“产地:某地”无法被模板统一调用,后续批量改版时只能逐页查找。
面对无法完整迁入的字段,可以按顺序问四个问题。只要前两问有一个答案是“是”,就应进入保留候选;如果后两问都是“否”,可以只留备份,不进入新站前台。
这里的实际动作是:把旧字段逐个填入这四问,得到“保留、合并、归档”三类结果。这个动作的结果会直接影响下一步的数据清洗范围——只有进入“保留”的字段才需要做类型转换和空值检查,“合并”的字段要写清合并规则,“归档”的字段则不再进入新站导入脚本。
假设某旧站有120个字段,新系统只支持40个。直接按前40个字段迁移,会丢掉后80个字段中可能包含的路由信息;直接全部转成正文,又会让新站模板无法调用。更稳妥的做法是分三层处理。
第一层,保留字段。包括页面标题、URL别名、栏目ID、发布时间、更新时间、主图、摘要。这些字段与链接、列表和模板直接相关,应优先映射到新系统的同义字段。若新系统字段类型不同,例如旧站发布时间是纯文本,新站要求日期格式,就必须在导入前统一格式,而不是导入后逐条修改。
第二层,合并字段。例如旧站有“规格1、规格2、规格3”三个独立字段,新站只有一个“规格说明”富文本字段。此时可以按固定分隔符合并,并在合并前确认三个字段不会同时为空。合并后要在新站模板中保留可读的分段,不要让所有规格挤成一段。
第三层,归档字段。例如旧站有“内部审核备注”“临时活动标记”等管理字段,前台从不展示,新站也没有对应后台。这类字段可以导出为备份文件,不进入新站数据库。归档不等于删除,它的作用是保留历史可查,但不增加新站维护负担。
个别样本成立,不代表规模化后仍然成立。一个字段在10条记录里都有值,迁到10万条记录时可能出现大量空值、格式冲突或重复值。判断边界时,重点看三类例外。
这里要说明一个常见误判:旧站某字段的抓取量或请求量归零,并不能单独证明该字段没有保留价值。它可能只是没有被当前模板调用,或旧链接已经不再被访问,但仍可能影响历史页面的完整性。更可靠的依据是字段是否参与前台展示、路由和编辑流程,而不是单一统计数字。
字段分级完成后,先不要急着全量导入。建议先选一个包含各类字段的小样本,按新系统字段类型导入,检查三件事:页面是否还能正常展示、旧链接是否还能对应到新页面、后台是否还能按预期筛选。这个动作的结果会决定你是继续全量迁移,还是先调整字段映射规则。
如果样本导入后发现某个保留字段在新模板中无法调用,应回到分级表,把它改为合并或归档,而不是在模板里临时写死。字段取舍的目标不是把旧系统原样搬过来,而是让新站的内容结构可展示、可链接、可维护。只有这三项同时成立,迁移后的站点才具备继续做SEO友好建站的基础。