旧官网迁移到 AI 建站时，最大的浪费不是重建成本，而是把低价值旧页面原样搬进新站。本文给出一套市场、产品、设计三方共用的页面审计方法：用统一数据口径打分、按决策清单把页面分成保留、合并、重写、下线四类，并给出重定向映射、URL 与 TDK 保留、内容补齐和上线验证的具体步骤，最...
把老站换成 AI 建站，技术上并不难：描述需求、生成页面、调整样式、绑定域名，几个小时就能跑通一条链路。真正拖住项目的是另一步——原来那几百个页面，哪些留下、哪些合成一个、哪些推倒重写？
常见的两种失败方式截然相反。一种是把旧站整站搬过去，结果新站刚上线就背着一批三年没更新、没有流量、也没人负责的页面；另一种是借迁移之机"清爽重做"，只留十几个主页面，把多年积累的收录和长尾入口一并清空。
这两种结果都不是技术问题，而是决策机制问题。市场、产品、设计三个团队各自掌握一部分信息：市场知道哪些页面带来线索，产品知道哪些内容已经过时，设计知道哪些页面在新框架下无法维持。缺了共同口径，页面取舍就变成嗓门大小的比拼。下面这套流程的目的，就是让三方在半天到一天的会议里得出可执行、可回溯的结论。
决策卡住，往往是因为大家在讨论"这页好不好看""这页重不重要"这类无法收敛的问题。把问题换成三个可量化维度，讨论立刻变得可操作。
| 维度 | 判断问题 | 数据来源 | 谁负责给结论 |
|---|---|---|---|
| 需求价值 | 是否有稳定搜索需求或明确的用户任务 | 搜索词报告、站内搜索、客服高频问题 | 市场 |
| 业务价值 | 是否直接支撑线索、试用、询盘或成交 | 表单来源、转化路径、销售反馈 | 市场 + 产品 |
| 资产质量 | 内容是否仍准确、结构是否可复用 | 最近更新时间、负责人、内容完整度 | 产品 + 设计 |
三个维度各自打分（例如 1-5 分），不要一开始就纠结权重。先各自打分，再一起看分布：三项都低的是下线候选，单项突出的是重写或保留候选，分数接近且主题重叠的是合并候选。
这里有一个容易被忽略的前提：AI 建站适合承接的是展示型网站——产品官网、内容页面、活动页、作品集这类结构清晰、以信息和转化为核心的站点。判断页面去留时，也应该按这套逻辑判断，而不是按"旧站有没有这个栏目"来判断。
把三个维度压缩成"需求 + 业务价值"与"资产质量"两条轴，就得到一张可以直接开会用的四象限表。每个象限对应的动作不同，负责人也不同。
| 象限 | 页面特征 | 建议去向 | 主要执行方 |
|---|---|---|---|
| 高价值 + 高质量 | 有搜索需求、有转化、内容仍准确 | 保留，迁移时保持 URL 与核心文案 | 市场 |
| 高价值 + 低质量 | 有需求但内容陈旧、结构混乱 | 重写，沿用原主题与关键词 | 产品 + 市场 |
| 低价值 + 高质量 | 内容扎实但无需求、无转化 | 合并到相关主题页，或转为站内支撑内容 | 产品 |
| 低价值 + 低质量 | 无需求、无转化、无人维护 | 下线，并配置 301 指向最相关页面 | 设计 + 市场 |
这张表最大的价值是消除"凭印象保页面"。谁想保留一个页面，就要指出它在哪个象限、依据是什么数据。反过来，想删页面的同事也必须说明 301 指向哪里。
一个务实做法是：先给每个页面标注唯一的"责任人"。没有责任人的页面，本身就是下线或合并的信号。
三方共同决策不等于三方共同拍板每一页。把边界划清楚，会议效率会明显提升。
市场团队负责"这页还有没有需求"。 提供搜索词、落地页来源、表单归因，并对 URL 与 TDK（标题、描述、关键词）的保留负责。迁移过程中最容易造成排名波动的，就是主题没变但 URL 全变、标题重写。
产品团队负责"这页讲的内容是否还成立"。 判断产品能力、定价、功能描述是否已经过时，决定哪些内容需要重写，哪些需要合并成一个更完整的主题页。
设计团队负责"这页在新框架下能不能成立"。 判断旧页面结构能否复用到新模板，哪些页面需要新的信息层级。设计的职责不是把旧页面"美化"，而是判断它在新的站点结构里是否还有位置。
遇到僵持时，用一个简单规则收口：能带来需求或转化的页面，默认保留或重写；两项都没有的页面，默认合并或下线。 这条规则把讨论从审美拉回业务。
合并是四类动作里最容易做坏的。把三篇内容拼成一篇超长页面，通常既损失原有长尾入口，也让新页面主题变得模糊。
正确的做法是先定合并后的主题，再决定吸收哪些内容：
判断标准很直接：合并后如果某个用户原本能一眼找到答案，现在需要滚动很久才能找到，这次合并就是失败的。
重写不等于从零开始。旧页面已经沉淀了搜索需求和用户语言，这些是最值得保留的部分。
必须保留的： 页面主题与核心关键词、被验证过的用户提问方式、原有 URL（能保留就保留）、指向该页的内链与外链。
必须重做的： 过时的产品能力描述、失效的截图与联系方式、混乱的信息层级、与新站视觉体系不一致的组件。
建议新增的： 结构化的问答段落、清晰的定义句、可被直接引用的数据与结论。企业官网正在越来越多地被 AI 搜索和对话式助手读取，页面能否用一段话把"这是什么、适合谁、解决什么问题"讲清楚，直接影响它能否被引用。这也是把 SEO 与 GEO 优化放在同一张页面清单里一起考虑的原因。
重写后的页面应当能回答三个问题：用户搜什么词能到这里、到这里之后看到的第一句结论是什么、下一步该点哪里。
页面清单定了之后，迁移本身需要一份可执行的对照表。下面是一份可以直接复用的迁移检查清单：
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
验证阶段要有明确的观察窗口和责任人，否则"上线后再说"会变成没人再看。
旧流程里，设计往往在页面结构确定之后才介入，负责把内容装进视觉稿。在 AI 建站流程中，页面结构可以在对话和可视画布中快速生成和调整，设计介入的时机随之前移。
这意味着设计团队的产出从"若干张页面稿"变成"一套可复用的页面规则"：哪些区块是通用组件、哪些页面需要独立结构、合并后的长页面如何保持阅读节奏、移动端如何重排。市场团队则从"上线后做优化"前移到"决定哪些页面值得被优化"，产品团队从"写功能说明"扩展到"维护内容的准确性"。
三方协作的真正变化，是页面取舍有了共同语言：数据负责判断价值，结构负责判断可行性，视觉负责判断可读性。
把这套流程压缩成一场 2-3 小时的评审会，节奏大致如下：
会议的唯一产出物是那张映射表。没有映射表，就等于没有结论。
对需要快速上线展示型网站的团队来说，We0 是一个面向 AI 建站的网站生成与发布平台，覆盖从自然语言描述需求、多智能体协作生成页面，到 CMS 后台管理内容、多语言站点、域名部署，以及 SEO 与 GEO 优化的完整链路。它在这套迁移流程中的价值，主要体现在两处：
一是新结构与内容承载。页面取舍结论出来后，新站需要一套能持续增改内容的结构。CMS 后台让非技术成员也能更新页面和文案，减少"改一句话要找开发"的摩擦——这恰好对应前面提到的"站建完不会改"问题。
二是上线后的可见性维护。页面迁移完成后，真正决定效果的是后续的标题描述校对、内容补齐和搜索表现观察。把建站、内容管理和 SEO/GEO 放在同一条链路上，能减少工具之间的信息丢失。
需要说明的是，页面取舍的结论仍然来自团队自己的数据与业务判断，工具负责承接和执行，不会替团队决定哪一页该删。
先做全量清单，再做分层审计。清单可以自动化导出，成本低；分层时优先审计有搜索流量、有转化或有外链的页面，其余页面按象限规则批量归类。全量清单的意义在于不漏页，避免出现"上线后才发现某个页面没处理"。
回到数据。有需求或有转化的页面默认保留或重写；两项都没有的页面默认合并或下线。如果数据本身缺失，就把判断周期设为上线后 30-60 天观察，先按"保留 URL、重写内容"处理，观察期结束再决定是否下线。
影响排名的主要变量是 URL 是否保留、标题与描述是否被大幅改写、跳转是否配置正确、内容是否出现大面积缺失，而不是建站方式本身。把这几件事在切换前处理好，风险是可控的。
在合并后的目标页面里补齐对应的问答小节，让原有问题仍有明确答案；同时确保旧 URL 301 到该页面。如果某个长尾主题内容量足够大、且与主页面意图明显不同，就应该单独保留，而不是硬合并。
越早越好，但介入方式是参与页面结构判断，而不是等结构定稿后做视觉稿。设计与产品共同确认哪些页面在新框架下成立、哪些需要独立结构，可以把返工成本降到最低。
需要，但可以简化。把三个维度压缩成"有需求吗、还准确吗"两个问题，用一张表格过一遍即可。流程的价值在于让决定有依据、有责任人，而不在于表格有多复杂。
旧官网迁移到 AI 建站，真正的难点是页面取舍而不是页面生成。让市场、产品、设计三方各管一段：市场判断需求与转化是否成立，产品判断内容是否仍然准确，设计判断页面在新框架下有没有位置。用"需求价值、业务价值、资产质量"三个维度打分，用一张四象限表把页面分流到保留、合并、重写、下线四条路径，再把结论固化成 URL 映射表与迁移清单，在切换前完成跳转配置、在切换后完成验证。合并要先定主题再吸收内容，重写要保留主题与 URL、重做过时信息。流程落地后，新站承接的不只是一次改版，而是一套可以被持续维护和优化的内容资产。
从一句话开始，几分钟内拿到完整网站。
