先定义访客要完成的判断
页面结构的起点不是“公司有几个部门”，而是访客在决定是否继续了解时需要哪些信息。
企业内部习惯按部门整理资料，访客却通常带着一个具体问题进入网站：你们是否处理这一类需求、是否适合我的规模或市场、有没有可信依据、下一步要准备什么。网站应顺着这些问题组织内容。
在画 Sitemap 之前，先写清主要受众、他们进入网站时已知道什么、最担心什么，以及网站希望他们完成的核心行动。若一个页面无法推动任何理解或行动，它可能只是内部资料的存放位置。
业务目标
明确网站优先支持咨询、销售前教育、招聘、渠道合作，还是多语言市场进入。目标可以不止一个，但必须有优先级。
主要受众
区分决策者、实际使用者、采购或技术评估者。不同角色需要的证据与细节不同。
核心行动
为每类关键页面指定一个自然的下一步，例如查看服务、阅读案例、提交项目背景或访问生产产品。
让六类页面各自承担责任
页面越多不代表结构越完整；关键是每类页面回答一个明确问题，并能把读者送到下一步。
多数服务型企业可以从一组稳定的页面职责开始。它不是固定模板，而是一张检查表：缺少某类页面时，要确认相应问题是否已经在其他位置被完整回答。
首页：建立全局认知
用清楚的价值主张、能力范围、代表证据和行动入口回答“这是谁、做什么、为什么值得继续看”。
服务总览与详情：判断适配
总览帮助选择方向；详情说明适用场景、方法、交付范围、边界和常见问题，避免只列技术名词。
案例：验证能力
说明真实问题、已经实现的范围、方法和限制。没有确认的数据就不写增长数字，也不把原型包装成客户成果。
洞察：回答具体问题
围绕客户会在项目开始前提出的疑问，解释选择、步骤和边界，并链接到对应服务与案例。
工作室：交代合作主体
如实说明谁负责、如何协作、采用什么流程。不用虚构团队规模来制造可信度。
联系：降低行动成本
告诉访客需要提供哪些背景、会如何回复、哪些信息不要发送；表单只收集判断项目所需的字段。
把服务、案例和文章分开写
三类页面可以讨论同一主题，但必须提供不同价值，避免复制同一段营销文案。
服务页回答“你们可以如何处理这类问题”，案例页回答“已经做过什么、证据在哪里”，文章回答“我该如何理解或选择”。当三者分工清楚，站内链接才不是为了 SEO 强行添加，而是自然延伸读者的判断。
例如，一篇架构选择文章可以解释静态、Headless 与 WordPress 的取舍；企业网站服务页则说明实际项目会交付哪些工作；案例页只展示已经确认的实施范围。三者不能互相冒充。
- 服务页包含适用与不适用、过程、交付和边界
- 案例页区分事实、方法、推断和尚未实现的内容
- 文章先回答问题，再链接到最相关的服务与案例
- 每个关键声明都能找到负责人、来源或可核对页面
上线前确认内容责任与维护方式
一个结构能否长期工作，取决于更新责任，而不只是上线当天是否完整。
为每类页面指定内容负责人、事实来源和复核时机。服务范围、团队信息、案例状态、联系方式和法律信息变化时，应有明确更新路径。多语言网站还要决定哪些页面同步、哪些内容允许因市场而不同。
技术层面需要同时检查 Metadata、Canonical、Sitemap、重定向、表单、分析事件、移动端、键盘操作和减少动态偏好。动效不能成为正文、链接或主要行动出现的前提。
- Sitemap 与主要用户路径已由业务负责人确认
- 旧 URL 的保留、合并和重定向已有清单
- 每个页面有明确标题、描述和唯一主要目的
- 联系动作、表单反馈和隐私说明可实际使用
- 移动端、键盘、弱网与减少动态模式仍能完成核心任务
- 上线后更新人员知道内容在哪里、如何发布和如何回退
带走这四点。
- 01
企业官网应按访客的决策路径组织，而不是照搬公司部门。
- 02
首页、服务、案例、洞察、工作室和联系页需要明确分工。
- 03
内部链接应连接问题、能力、证据与行动，而不是堆关键词。
- 04
上线前就要确定内容负责人、重定向和长期维护方式。