需要纳入，但不应把所有新增问题直接塞进原项目尾项，而要按业务价值、页面影响和证据成本重新排入迭代队列。只要新增问题对应真实业务、能落到页面或内容调整，并且有记录可追踪，就适合进入后续迭代；成本、周期和效果无法通用判断，需用自家数据验证。
验收通过后，什么问题值得继续做
新增业务问题如果只是换一种问法，先判断它是否带来新的用户意图。比如原页面回答产品功能，新问题却询问适用限制、办理条件或售后边界，这就不只是改几个词，而是需要补充独立内容块。
如果问题能对应到具体页面、服务实体、产品实体或业务流程，并能由业务人员提供准确答案，就可以进入迭代池。没有稳定答案、没有负责部门或无法判断页面归属的问题，应先标注为待定事项，避免内容团队凭空补写。
真正影响排期的是页面哪一层
新增问题先看它影响的是内容表达，还是页面基础。只改标题、问答段落和内部链接，处理方式与页面无法访问、被限制抓取、状态码异常、站点地图缺失并不相同，排期也不应混在一张轻重不分的清单里。
根据 Google Search Central《搜索抓取和索引编制概览》，页面能否被访问、抓取与进入搜索系统，属于不同环节。这里能确认的是技术状态，不是被 AI 回答引用的结果；引用、点击和线索仍要分别记录，不能把抓取次数当成业务效果。
新增问题要不要单独建页面
同一主题下的补充问法，适合先放入已有页面，前提是页面主标题、正文结构和实体指向仍然一致。若新增问题服务的是另一类人、另一种流程，或需要单独展示条件与限制，再考虑新建页面。
一个实用判断是：用户看完原页面后，是否还必须跳到另一页才能完成理解。如果答案是“需要”，新页面的必要性就更高；如果只是补充一个定义或办理条件，直接在原页面增加短段落，并从相关页面建立清晰链接，可能更省维护成本。
结构化数据别因为新增问法就乱改
结构化数据要服务页面中真实可见的内容，不能为了覆盖新增问题而堆入页面没有呈现的字段。Schema.org《Schema.org语汇表》可以帮助团队理解类型与属性的含义，但它本身不代表页面一定获得展示、引用或转化。
新增业务涉及产品、组织、服务或问答内容时，应让页面正文、标题、结构化数据和站内链接使用同一套名称。某个名称只在结构化数据里出现、正文却没有对应解释，后续维护时容易造成实体表达不一致，应回到页面内容一起调整。
验收后的确认清单，按这个顺序做
- 记录新增问题的原始问法、出现日期、业务归属和对应页面，不要只保留改写后的关键词。
- 打开页面检查访问状态、正文是否完整、内部链接是否可用，并查看 robots.txt 与站点地图是否存在冲突。
- 把页面名称、组织名称、产品名称和服务名称放在同一张记录表里，逐项比对标题、正文、结构化数据和链接锚文本。
- 在目标搜索引擎与相关 AI 产品中做固定问法测试，记录回答是否出现、是否引用页面、是否产生点击；展示不等于点击，点击也不等于订单。
- 将引荐来源、落地页、有效表单、成交状态和记录日期放入同一条数据链，主转化事件只选一个，归因窗口按销售周期设定。
- 完成一个完整记录周期后，按有效线索率、订单成本或页面问题数量判断下一步；结果不理想时，回到抓取状态、内容匹配和实体一致性排查。
迭代优先级，别只看问题数量
问题数量多，不代表处理价值就高。更值得排在前面的，往往是同时影响核心业务页面、多个用户问法和销售沟通的问题；只在单个边缘页面出现、且没有业务负责人确认的问题，可以暂缓。
排期时可给每条问题补上四个判断：影响哪个业务目标、涉及哪类页面、改动是否会影响既有内容、结果能否被记录。这样做的好处是，验收后的新增需求不再靠谁催得急来排序，而是能说明为什么做、做完看什么。
版本记录要留下什么才有用
每次迭代至少记录变更前页面、变更内容、负责人、上线日期和对应问题。页面改版、链接调整、结构化数据更新与抓取规则变化，尽量分开记，否则后面看到数据变化时，很难判断是哪次改动带来的影响。
查询测试也要固定问法、设备环境和记录方式。AI回答会随时间、地区、上下文和产品版本变化，单次出现或没有出现都不能直接当成稳定结论；需要把多次记录与引荐点击、表单及成交状态放在一起观察。
验收边界要写进后续协作规则
项目验收主要说明约定范围内的工作已经完成，不等于未来业务问题自动归入原交付内容。合同、项目说明或内部流程里，应写清新增问题的进入条件、评估方式、排期规则、交付物和数据配合责任。
若新增问题涉及业务口径变化，内容团队不能单独决定答案；若涉及页面模板、服务器、站点地图或结构化数据，也要让技术负责人参与。这样既能避免内容改了但页面基础没变，也能减少同一问题被不同团队重复处理。