企业官网建站前的需求梳理：栏目、内容清单与功能边界

引言：做了三分之二才想起来问「这个网站用来干嘛」

典型的企业建站项目是这样的：老板说「做个官网」，设计师出首页稿，前端照着做，做到产品页时才发现没人说得清有多少个产品、每个产品要展示哪些参数；做到案例页时发现素材全在市场部同事的手机里；上线前一周才有人提出「要能按城市看分公司」，而这时候菜单结构和 URL 已经定了。

这类返工的根因，是把「建站」当成了设计任务而不是信息工程任务。设计解决的是「好不好看」，建站首先要解决的是「有什么、给谁看、看完做什么」。后者不先定清楚，页面做得再漂亮，也会在内容填充阶段卡住。

需求梳理的目标不是写一份漂亮的文档，而是把三件事钉死：栏目树（有多少个页面、层级怎么排）、内容清单（每个页面的内容由谁在什么时间提供）、功能边界（做什么、明确不做什么）。这三件事定完，工期和风险才谈得上可控。

原理分析：为什么需求会反复变

需求变更有三个高频来源，提前识别就能预防：

第一条最关键。一个企业站不可能同时最大化品牌调性与线索转化，两者在首页布局上的取舍是冲突的：形象导向要大图、留白、慢节奏；转化导向要表单、证据、明确的行动按钮。立项时必须选一个主目标，另一个作为次目标。

信息架构上有个实用原则：栏目树的深度不超过三层，顶部一级栏目不超过七个。超过七个访客记不住，超过三层内容就难以被找到。这个约束能强迫业务方做取舍，是梳理过程中最好用的工具。

保姆级实操

步骤 1：定义目标、受众与转化动作

用一张表把话说清楚，写在需求文档第一页：

## 1. 项目目标

- 主要目标（唯一）：获取销售线索（表单提交 + 电话拨打）
- 次要目标：支撑销售在外拜访时展示产品资料
- 本期不做：在线支付、会员中心、多语言、分销系统

## 2. 目标访客

| 访客类型 | 关心什么 | 期望动作 |
|---|---|---|
| 采购/技术选型 | 参数、认证、交付周期 | 下载规格书 / 提交询价 |
| 老板/决策者 | 行业案例、公司实力 | 查看案例 / 预约参观 |
| 求职者 | 岗位、环境 | 查看招聘 / 投递简历 |

## 3. 成功指标

- 三个月内月均有效表单 ≥ 30 条
- 移动端平均停留时长 ≥ 60 秒
- 主要产品页被搜索引擎收录并进入前两页

「本期不做」这一栏必须有，它是后期抵御需求蔓延的唯一凭证。

步骤 2：规划栏目树

按「访客任务」而不是「公司部门」来组织，这是最常犯的错——按部门分（研发部、市场部、生产部）访客根本找不到东西。

首页
├── 产品中心
│   ├── 产品分类 A
│   ├── 产品分类 B
│   └── 单个产品页（参数 / 图纸下载 / 相关案例）
├── 解决方案（按行业分）
├── 客户案例
│   └── 案例详情（背景 / 方案 / 成效）
├── 关于我们
│   ├── 公司简介
│   ├── 资质荣誉
│   ├── 生产实力
│   └── 招聘
├── 新闻资讯
└── 联系我们（总机 / 分公司 / 表单 / 地图）

规划时用一句话检验每个栏目：这个栏目能不能对应到一个明确的访客问题？对应不上就合并或删除。

步骤 3：把内容清单逐项落实

栏目树确定后，立刻做内容清单，每一项都要有责任人和交付时间：

| 页面 | 内容项 | 数量 | 责任人 | 状态 | 到位时间 |
|---|---|---|---|---|---|
| 产品中心 | 产品主图 | 42 张 | 产品部-李 | 待拍 | 10-15 |
| 产品中心 | 参数表 | 42 份 | 技术部-王 | 已有 Excel | 10-12 |
| 客户案例 | 案例图文 | 12 篇 | 市场部-张 | 草稿 5 篇 | 10-20 |
| 关于我们 | 资质证书扫描件 | 9 份 | 行政-陈 | 已有 | 10-10 |
| 首页 | 主视觉文案 | 1 套 | 市场部-张 | 待定 | 10-18 |

没有这份表，项目一定会在「等内容」上浪费一半工期。经验做法是：内容到位率不到 60% 不开工做页面，先做结构与样式。

步骤 4：盘点已有内容，避免重复劳动

老站点或旧资料里有可复用内容时，先量化再决定：

# 老站点按类型统计内容量
wp post list --post_type=post --post_status=publish --format=count
wp post list --post_type=page  --post_status=publish --format=count

# 导出清单用于内容清单核对
wp post list --post_type=any --post_status=publish \
  --fields=ID,post_title,post_type,post_date,post_modified \
  --format=csv > /tmp/old-content-inventory.csv

# 统计媒体库
wp post list --post_type=attachment --post_status=inherit --format=count

再抽查内容质量：有多少是三年前写的、有多少缺图、有多少标题重复。这一步的输出直接决定「迁移」还是「重写」。

步骤 5：划功能边界

每个功能需求都要回答「用什么实现、谁维护、要不要付费」：

| 需求 | 实现方式 | 依赖 | 维护方 | 备注 |
|---|---|---|---|---|
| 产品库 | 自定义文章类型 + 分类法 | 功能插件 | 我方 | 换主题不受影响 |
| 询价表单 | 表单插件 + 邮件通知 | 插件 | 客户 | 需配 SMTP |
| 案例筛选 | 分类法归档 + 前端筛选 | 主题模板 | 我方 | 不用 ajax，用链接过滤 |
| 地图 | 静态图 + 文字地址 | 无 | 客户 | 不接入第三方 JS SDK |
| 多语言 | 本期不做 | — | — | 留 URL 结构余量 |

「实现方式」一栏要写清是主题层还是插件层。凡是换主题后仍需保留的，一律插件层实现。

步骤 6：确定非功能需求

容易被忽略但会返工的四项：

• 性能目标：移动端 Lighthouse 性能分 ≥ 75，LCP ≤ 2.5s；
• 浏览器与设备：至少覆盖 iOS Safari 15+、Android Chrome 100+、微信内置浏览器；
• 维护能力：客户是否有人会更新内容？决定后台要不要做简化；
• 合规：ICP 备案、隐私政策、表单收集的个人信息声明。

微信内置浏览器这一项国内项目必须单列，它对部分新 CSS 特性支持滞后，且视频自动播放策略特殊。

步骤 7：把需求文档结构化存档

用 YAML 存一份机器可读的版本，方便后续生成站点结构和验收清单：

site:
  name: 某某科技
  primary_goal: lead_generation
  locale: zh_CN
  timezone: Asia/Shanghai

structure:
  - name: 首页
    slug: home
    children: []
  - name: 产品中心
    slug: products
    taxonomy: product_cat
    children:
      - { name: 工业控制器, slug: controller }
      - { name: 传感器, slug: sensor }
  - name: 客户案例
    slug: cases
    taxonomy: case_industry
  - name: 关于我们
    slug: about
  - name: 联系我们
    slug: contact

not_in_scope:
  - 在线支付
  - 会员系统
  - 多语言

常见踩坑

1. 先出首页稿再定栏目：视觉定稿会反过来绑架结构，后期加栏目就要改设计。顺序必须是结构 → 内容 → 视觉。
2. 只写「做什么」不写「不做什么」：需求蔓延没有刹车，工期拖延后还无法归因。
3. 内容清单没有责任人：变成「大家都有份」，结果谁都没做。
4. 把分公司、组织架构当栏目：访客不关心你的部门设置，只关心自己要解决的问题。
5. 案例： 某制造企业建站时栏目按四个事业部划分，上线后销售反馈客户找不到产品——客户是按应用场景找的，不知道产品属于哪个事业部。三个月后推倒重做栏目结构，URL 全部变化，之前积累的收录全部失效，排名从首页掉到第三页。教训：栏目要按访客的心智模型组织，且在上线前用 5 个真实客户做「找东西」测试。
6. 忽略维护人力：客户方没有专职运营，却做了每天需要更新的新闻模块，三个月后首页最新资讯还停在上线那天。
7. 没留扩展余量：本期不做多语言，但 URL 结构如果写成硬编码中文路径，将来加多语言要全站改。

总结

需求梳理的产出物就三份：一张栏目树（深度 ≤3、一级 ≤7）、一份带责任人和时间的内容清单、一张划清「本期不做」的功能边界表。这三份齐了，项目才算具备开工条件。

判断梳理是否到位的标准：随机挑一个栏目，能否在 30 秒内说出它对应的访客问题、内容来源和责任人；说不出就说明还没想清楚。栏目结构的具体组织方式可参考 企业官网标准栏目结构设计，梳理完成后再进入选型环节，按 用WordPress做企业站的主题与插件组合 决定技术栈。