SEO / GEO 网站排版设计标准与规范细则（二）：Task-First Layout——为什么网站不能先设计页面，再考虑用户需要什么？

一家工业设备制造企业准备重新设计产品详情页。

设计团队首先制作了页面原型：顶部是全宽产品图片，下面依次排列企业介绍、产品优势、应用场景、技术参数、客户案例与询价表单。

页面视觉统一，模块齐全，也符合企业对品牌形象的要求。

但是，当一名正在进行设备选型的工程师进入这个页面时，他可能仍然无法快速解决最基本的问题：

这台设备究竟能不能用于我的项目？

他可能已经知道设备的基本原理，不需要再阅读大量行业介绍。他真正关心的是工作条件、性能范围、材料适用性、安装要求，以及现有资料能否支持初步技术判断。

如果这些信息被放在页面后半部分，甚至只存在于需要下载的产品手册中，那么页面虽然完成了视觉设计，却没有优先支持用户的实际任务。

更严重的问题是，网站建设团队可能将这种页面视为合格作品。

因为所有预先约定的模块都已经制作完成，设计稿得到了确认，响应式布局也没有明显错误。

然而，用户是否能够完成任务，并没有成为设计和验收的核心依据。

这正是本篇需要解决的问题。

第一篇《Layout as Information Architecture》提出，网站排版应当以用户任务为起点，以内容语义为基础，并通过视觉、交互和技术交付形成完整的信息表达过程。

第二篇进一步回答：

怎样将真实用户任务转换为页面信息优先级、模块顺序、交互方式和可验证的建设要求？

这需要建立一套 Task-First Layout，即用户任务优先的页面设计方法。

一、为什么从页面模块开始设计，容易产生结构性错误？

页面模块是实现方案，不是需求本身

在网站建设中，团队很容易形成一套默认的页面模块清单。

首页需要 Hero、品牌优势、产品分类、案例和联系入口。

产品详情页需要图片、参数、介绍、应用和询价表单。

技术文章需要标题、摘要、目录、正文、图片和相关内容。

这些模块可以提高设计和开发效率，但模块清单不能直接证明页面具有实际价值。

例如，一个产品页面配置了完整的技术参数表，并不意味着它已经解决设备选型问题。

如果表格没有包含用户判断设备适用性所需的关键条件，或者参数名称没有明确对应的测试标准，那么表格只是形式完整。

同样，一篇文章提供了自动生成的目录，并不意味着正文已经按照读者需要解决的问题进行组织。

页面组件的存在，不能替代用户任务被满足的证据。

问题往往发生在设计的起点。

团队先选定模板，再寻找内容填充各个模块。

结果是内容必须适应模板，而不是模板根据任务和内容关系确定结构。

这种方式适合信息结构稳定、任务已经被验证的成熟页面类型，却不适合作为所有页面的默认规划方法。

为什么设计团队容易忽略真实任务？

因为页面需求通常来自企业内部。

管理层希望提升品牌形象，市场部门希望增加产品曝光，销售团队希望增加询盘，SEO 人员希望扩大关键词覆盖。

这些都是合理的业务诉求。

但是，它们描述的主要是企业希望获得什么，而不是用户需要完成什么。

例如：

“让更多客户提交询价表单”是一项企业目标。

“让客户在完成技术评估后，能够提交必要的采购条件”才更接近可设计的用户任务。

两者存在联系，却不能直接等同。

如果只围绕增加询盘设计页面，团队可能在多个位置设置 CTA，缩短表单，增加弹窗，却没有改善用户在提交询盘之前需要完成的技术判断。

最终，页面可能产生更多表单提交，却未必增加真正符合企业供给能力的采购需求。

因此，Task-First Layout 首先要求区分企业目标、用户目标、用户任务和页面功能。

二、Task-First Layout 的定义与适用边界

Task-First Layout 可以理解为一种以用户任务为主要设计约束的页面组织方法。

在这种方法中，页面的信息范围、展示顺序、模块结构和交互行为，需要根据用户在具体场景下准备完成的任务来决定。

它并不意味着所有页面都必须围绕单一操作展开，也不意味着品牌传播、视觉设计和商业目标不再重要。

它要求团队建立一个明确的优先级：

先确定页面需要支持什么任务，再决定需要哪些内容、组件和视觉形式。

用户目标与用户任务不是同一件事

用户目标通常描述希望实现的结果。

用户任务则描述为了达到该结果，需要执行的具体活动或判断。

例如，采购工程师的目标可能是为某个冷却系统选择合适的循环泵。

为了实现这个目标，他需要依次确认系统条件、筛选设备类型、比较关键参数、核实安装约束，最后确定需要进一步咨询的候选设备。

“选择合适的设备”是目标。

“比较流量和扬程条件”“查看介质适用性”“确认安装尺寸”则是任务。

产品参数表、比较组件、资料下载和询盘入口，是为了支持这些任务而采用的功能或内容形式。

Nielsen Norman Group 在《Task Analysis: Support Users in Achieving Their Goals》中，将任务分析描述为研究用户如何通过执行任务达成目标的系统方法，并指出任务分析需要识别任务与子任务的数量、顺序、层级和复杂程度。

这为页面设计提供了重要依据。

用户任务是设计输入，页面模块是设计输出。两者不能倒置。

用户任务也不等于搜索关键词

在 SEO 网站建设中，团队常常通过关键词研究推断用户需求。

这一做法有价值，但存在明显边界。

同一个关键词可能对应不同的用户任务。

例如，“industrial cooling pump”可能来自希望了解产品类型的初学者，也可能来自正在筛选供应商的工程采购人员。

他们输入了相同或相近的查询，却不一定需要相同的信息深度。

反过来，同一项任务也可能由多种不同的搜索表达触发。

用户可能通过设备名称、应用场景、技术参数、故障现象或行业术语寻找同一类解决方案。

因此，关键词不应该直接决定页面模块。

关键词研究主要帮助团队了解用户可能如何表达需求、有哪些相关问题，以及页面可能通过什么入口被发现。

用户任务研究则需要进一步判断：

用户为什么寻找这些信息？需要完成什么判断？当前有哪些前提条件？页面提供什么信息后，任务才能继续？

关键词是需求表达的一种线索，而不是用户任务的完整定义。

三、用户任务研究必须建立在证据之上

Task-First Layout 不能简单依赖团队对用户的想象。

例如，营销人员认为采购客户最关心产品价格，销售人员认为客户最关心交付周期，技术人员认为客户应该首先查看性能参数。

这三种判断可能分别适用于不同的采购阶段。

如果团队没有验证这些判断，就不能直接将某一种观点确定为页面的主要设计原则。

GOV.UK Service Standard 的第一项要求是深入理解用户及其需要解决的问题。其设计指导强调研究完整使用场景，而不是只研究用户与某个界面的接触过程。

对企业独立站而言，可以把这种思想转化为一条研究原则：

优先分析用户已经发生的真实行为和实际问题，再使用团队经验补充尚未得到验证的部分。

企业网站可以从哪些信息来源识别用户任务？

证据来源	能够提供的主要信息	必须注意的局限
客户询盘及邮件	采购客户实际提出的问题、需要的资料与决策条件	存在样本选择偏差，无法代表所有访客
销售与技术沟通记录	常见选型障碍、需要反复解释的信息	企业内部可能已经过滤或重构了客户原意
Google Search Console	用户使用哪些查询找到网站，哪些页面参与搜索曝光	查询和点击无法直接证明用户最终完成了什么任务
GA4 及事件分析	页面访问、导航、下载、表单等可观测行为	事件不等于意图，也不必然等于任务完成
站内搜索记录	用户进入网站后主动寻找的信息	搜索量高可能意味着需求强，也可能意味着导航失败
用户访谈与任务观察	真实判断流程、信息依赖和操作困难	样本较小，需要关注研究对象与任务的代表性
客服与售后资料	用户在购买、安装和维护阶段反复遇到的问题	可能更偏向现有客户，不能直接代表新客户

这些数据来源之间并不存在固定的优先级。

如果正在建设一个没有历史流量的新网站，真实客户沟通记录与行业任务访谈可能比 GA4 更有价值。

如果网站已经运营多年，站内搜索和用户操作记录可以帮助发现既有页面中的信息查找障碍。

关键不是拥有多少数据，而是数据是否能够支持当前设计决策。

应当区分事实、推断和待验证假设

假设某个工业设备网站的技术参数文档下载量很高。

这个现象只能说明相关下载事件发生得较多。

它不能直接证明所有用户都喜欢 PDF，也不能证明应当把所有技术参数继续放在 PDF 中。

另一种可能是网页本身缺少关键参数，用户不得不下载文件查找。

只有结合访谈或任务观察，才能进一步判断具体原因。

因此，建议将用户任务证据分成四种状态：

Observed：已观察。 有直接用户行为或访谈记录支持。

Corroborated：交叉验证。 有不同来源的证据支持同一任务判断。

Inferred：分析推断。 依据间接证据形成解释，但还没有得到直接验证。

Hypothesized：待验证假设。 主要来自团队经验或业务预测。

这一分类属于本专栏提出的内部研究方法，并非官方统一标准。

它的作用是避免将“我们认为客户需要”直接写成“客户实际需要”。

四、如何编写可以用于设计的 User Task Statement？

用户研究的结果必须进入可执行的页面规划过程。

如果最终只得到“用户喜欢简洁页面”“采购人员重视技术参数”这样的泛化结论，仍然无法指导模块设计。

建议为关键任务建立统一的 User Task Statement，即用户任务陈述。

基本格式为：

在什么场景下，某类用户需要利用哪些信息，完成什么判断或操作，以便获得什么结果。

例如：

当采购工程师需要为工业冷却系统选择循环泵时，他需要根据介质特性、设计流量、扬程和安装条件，判断哪些设备能够进入下一轮技术评估。

这个陈述同时描述了使用场景、用户角色、必要信息、目标操作和预期结果。

它能够直接影响页面结构。

如果缺少介质适用性信息，用户无法完成任务。

如果关键参数没有统一单位，比较就会产生困难。

如果设备存在安装限制，页面也需要向用户提供相关信息。

建议建立 Task Card 作为页面设计的输入文件

每个关键任务可以形成一张 Task Card。

字段	示例内容
Task ID	TASK-PUMP-001
用户角色	工程采购人员
任务场景	工业冷却系统的设备初步选型
任务目标	确定值得进一步技术评估的设备型号
必要输入	介质、流量、扬程、温度、安装条件
任务前提	用户已经具备基本工况信息
核心判断	设备是否符合主要技术约束
所需证据	技术规格、适用范围、性能曲线、技术文档
后续行动	保存候选型号、提交工况资料或联系技术人员
成功标准	用户能够正确识别候选设备及尚未确认的条件
证据状态	Observed / Corroborated / Inferred / Hypothesized
任务负责人	产品、内容及网站设计共同确认

Task ID 的意义不只是管理方便。

当任务进入页面模块、内容字段和验收测试后，可以使用相同的标识建立追踪关系。

例如 TASK-PUMP-001 对应产品适用性判断，LAYOUT-PUMP-003 对应页面中的关键参数与适用条件模块，QA-PUMP-008 对应任务完成测试。

一旦测试发现用户不能完成任务，就可以追溯相关信息字段和页面模块，而不是笼统地要求设计师重新调整页面。

五、从用户任务到页面：建立 Task-to-Layout Mapping

完成任务定义之后，需要将任务转换成页面结构。

这一步是 Task-First Layout 的核心。

建议采用以下设计链路：

User Task → Information Need → Content Unit → Layout Component → Interaction → Acceptance Evidence

其含义是：先明确任务，再确定完成任务需要的信息，将信息组织为独立内容单元，选择合适的组件和交互形式，最后定义如何证明任务已经被支持。

以工业冷却循环泵产品页为例，可以建立以下映射。

用户任务	必要信息	页面呈现方式	验收依据
识别设备类型	设备名称、用途、基本特征	产品概览和简明介绍	能够正确识别设备用途
判断技术适用性	流量、扬程、介质、温度和其他关键约束	参数摘要、完整技术规格与适用条件	能够识别主要技术匹配条件
比较候选型号	可比较的型号字段及对应条件	型号比较表或明确的型号链接	能够找出符合指定条件的候选型号
核实安装要求	安装尺寸、连接方式、配套条件	图纸、安装说明及技术文档	能够找到必要的安装资料
评估证据可靠性	数据来源、测试条件、文件版本	技术证据区和文档元信息	能够识别数据的适用范围与来源
发起技术沟通	当前型号、工况信息、联系人信息	与当前产品关联的技术咨询入口	能够提交足够明确的技术需求

这张映射表不规定必须采用多少模块。

同一内容单元可以支持多个任务。

例如，完整的技术规格既能用于型号筛选，也能用于采购技术审查。

同一任务也可能需要多个内容单元共同支持。

例如，判断设备是否适用，可能同时依赖性能曲线、介质限制、环境条件和工程配套要求。

因此，任务与页面模块并不要求建立一对一关系。

真正需要建立的是可追踪的支持关系。

为什么不能直接把任务转换成页面数量？

网站建设中常见一种误区：每识别一个用户任务，就创建一个独立页面。

这会带来新的问题。

例如，设备流量判断、扬程判断和介质适用性判断虽然是不同子任务，但在很多情况下属于同一个产品选型过程。

如果将这些信息拆成大量独立页面，用户可能需要不断跳转才能完成一次完整评估。

这不仅增加阅读和导航成本，也可能造成内容重复及维护负担。

相反，如果任务具有不同目标、不同证据需求和独立的搜索需求，则可能值得建立专门页面。

例如，产品详情与设备故障排查往往属于不同的使用场景。

前者主要支持选型与采购，后者主要支持问题诊断与维护。

它们可以建立内部链接，但不一定适合混合在同一模板中。

判断是否需要独立页面，应综合考察任务差异、信息规模、搜索入口、用户决策阶段和维护成本，而不是单纯根据关键词数量决定。

六、信息优先级不等于模块排列顺序

Task-to-Layout Mapping 确定页面需要哪些信息之后，还必须解决信息应该如何排序的问题。

这里需要避免两个极端。

第一种是所有重要信息都放在页面最前面，导致首屏严重拥挤。

第二种是为了保持视觉简洁，将必要信息过度隐藏，让用户必须经过大量操作才能完成基本判断。

信息优先级决定哪些内容不可缺少；展示顺序决定用户在什么阶段接触这些内容。

二者需要分别设计。

首先区分任务依赖与阅读偏好

如果用户必须先理解某项适用条件，才能正确解释后续的性能数据，那么这两类信息存在依赖关系。

但如果用户只是更习惯先看图片还是先看技术摘要，则不一定存在严格的逻辑依赖。

设计时应优先保证必要的任务依赖关系。

例如，工业泵的性能曲线需要结合对应工况解释。

如果只展示曲线，而将测量条件放在很远的章节中，就可能让用户误读数据。

这类信息应当在内容层面保持紧密关联。

相反，企业发展历史与完整厂区介绍，通常不构成用户阅读产品参数的前提。

它们可以保留，但不应默认占据产品评估之前的大量内容空间。

建立三层信息优先级

建议采用以下分级方式：

Critical：任务关键层。 缺少相关信息会使目标用户无法正确完成核心任务，或容易产生重要误判。

Supporting：任务支持层。 用于补充解释、比较、核验或处理常见疑问，对任务质量具有明显价值。

Supplementary：扩展信息层。 对特定用户或特殊场景有帮助，但不是大多数核心任务的必要前提。

这是一套项目设计优先级，而不是 Google 官方的内容等级。

例如，对于工业设备选型页，关键工况与技术适用性可能属于 Critical；详细维护指导可能属于 Supporting；企业参加展会的历史新闻可能属于 Supplementary。

但在售后维护页面中，维护指导又可能成为 Critical。

同一项信息的优先级，会随着页面任务改变。

为什么不能使用固定的权重公式决定页面顺序？

企业可以通过内部评分辅助排序，但必须注意评分的证据基础。

例如，团队可以考虑任务重要性、出现频率、错误后果、证据可信度和实施成本。

然而，这些维度不能简单相加后，就把一个计算结果当作客观事实。

高频任务不一定最重要。

某些低频任务一旦判断错误，可能产生较高的经济损失或安全风险。

因此，建议先使用任务关键性与风险判断识别不可缺少的信息，再对其他信息进行相对排序。

对于存在争议的模块顺序，应当通过原型测试验证，而不是依赖未经校准的精确评分。

七、Task-First Layout 如何决定首屏设计？

首屏经常成为企业网站设计中争议最大的区域。

市场部门希望品牌形象突出，设计师希望保留视觉空间，销售团队希望用户能够立即询盘。

但是，首屏并不存在一套适用于所有网站的固定组件组合。

对于产品选型任务，首屏的主要作用可能是帮助用户快速确认自己是否进入了正确的页面。

因此，页面需要明确说明产品是什么、适用于哪些主要场景，以及用户可以从哪里进入核心技术信息。

对于企业首页，首屏则可能需要说明企业提供什么业务、服务什么客户，以及用户应如何进入相应的产品或解决方案。

对于深度技术文章，首屏需要帮助读者识别讨论对象、核心问题和内容范围。

这些场景的用户任务不同，首屏的信息结构也应不同。

首屏应当回答哪些问题？

建议首先检查三个方面。

用户能否明确识别当前页面的对象或主题？

用户能否判断当前页面是否与自己的需求有关？

用户能否找到继续完成任务的路径？

如果一个页面无法回答这些问题，那么即使首屏具有精致的动效和复杂的视觉设计，也可能不符合任务优先原则。

但这不是要求在首屏放入所有答案。

首屏的任务是建立方向和必要的初始理解，而不是取代整个页面。

如何处理 Hero Image 与任务信息的关系？

Hero Image 可以帮助用户识别产品、理解应用场景或建立品牌印象。

但图片的视觉面积不应自动决定其信息优先级。

例如，一张大型工业设备图片可以很好地展示设备外观，却通常不足以说明设备是否符合特定工况。

如果主要决策依赖技术参数，就需要确保用户可以方便地找到参数摘要、适用范围或完整技术资料。

图片与文字应相互补充，而不是竞争用户注意力。

八、怎样区分“必要信息前置”与“过度简化”？

有些设计方案认为，页面应该尽可能短，重要信息应当高度压缩。

另一些方案则认为，SEO/GEO 页面应该尽量完整，将所有相关内容直接展示。

这两种观点都过于绝对。

真正的问题是：用户在当前任务阶段需要什么信息，以及什么内容可以在需要时进一步展开。

Nielsen Norman Group 在 Progressive Disclosure（渐进式披露）研究中提出，可以先呈现常用且重要的信息，再让用户根据需要访问高级或次要信息。

这种方法能够用于复杂网站，但前提是初始展示的信息确实能够支持主要任务。

什么信息适合直接展示？

对于产品选型页，能够决定基本适用性的技术条件通常不适合被完全隐藏。

例如，设备不适合某类介质或特定温度范围的限制，如果直接影响用户判断，应当放在容易发现的位置。

完整的安装手册、详细的维护步骤和专用技术文件，则可以通过独立章节或明确的文档入口提供。

但如果用户当前的核心任务就是安装设备，安装步骤便不能继续被当成次要信息处理。

这里需要强调：

渐进式披露的依据是任务相关性，而不是单纯减少页面长度。

折叠组件是否会影响 SEO/GEO？

折叠并不必然意味着内容不适合搜索。

Google 的移动优先索引文档允许移动端通过折叠组件或标签页节省空间，前提是核心内容仍然与桌面端实质等价，并且能够被 Google 访问。

需要避免的是：关键内容必须在用户点击、滑动或输入之后才从服务器加载，而搜索系统无法通过其他方式获取。

此外，折叠组件需要有清楚的名称、正确的语义和可操作的键盘交互。

因此，设计审核不能只问“内容是否折叠”。

更重要的问题是：内容是否存在、是否完整、是否易于发现、是否可访问，以及是否符合当前任务的信息优先级。

九、一个页面怎样同时满足不同角色的任务？

B2B 网站通常面对不止一种用户角色。

对于同一台工业设备，技术工程师、采购负责人和项目管理人员可能具有不同的判断重点。

工程师关注性能和技术约束。

采购负责人关注供应能力、交付安排和采购风险。

项目负责人则可能关注安装条件、实施周期及后续支持。

如果页面只围绕其中一个角色设计，其他用户可能需要寻找额外信息。

但如果把所有角色的内容平均展示，页面又可能失去清楚的主线。

Task-First Layout 的处理方法不是将所有用户要求简单叠加，而是建立主任务与辅助任务之间的关系。

例如，一个产品详情页可以将“判断技术适用性”定义为核心任务，把“核实供应商支持能力”和“发起技术沟通”作为辅助任务。

这样，技术信息决定主要内容结构，而供应商信息和咨询入口在相应位置提供支持。

对于企业采购资格审查，则可以通过专门的企业能力页面承担更完整的任务，并在产品页提供明确入口。

什么时候应该拆分为多个页面？

如果不同任务具有独立的用户目标、不同信息体系和独立的完成标准，就应评估是否使用不同页面。

例如，设备产品详情、选型指南、安装文档和故障诊断虽然涉及同一产品，但支持的任务不同。

将所有信息集中在单页，可能导致页面过度复杂。

将它们拆成相互关联的页面，则能够分别建立更明确的任务路径。

不过，页面拆分之后必须保留必要的上下文与链接关系。

例如，产品页应当能够访问相关技术文档，安装文档应当明确适用的设备型号和版本。

不能为了让每篇文章拥有独立关键词，就把本来需要共同理解的技术信息拆散。

十、完整案例：从工业冷却循环泵采购任务重建设备详情页

假设一家工业泵制造商正在重建英文产品网站。

现有页面的排列方式是：

产品图片、品牌标语、企业优势、设备介绍、行业应用、技术参数、证书、询盘表单。

团队希望新页面能够更好地支持实际设备选型。

重新建立用户任务

通过客户咨询记录和销售技术沟通，团队提出一个需要验证的任务模型：

采购工程师在具备基本工况信息的前提下，需要判断某一系列循环泵是否符合设计要求，并确定需要进一步核实的技术条件。

这里并不假设所有访客都已经准备采购。

对于缺少基础知识的用户，网站仍需要通过分类页、选型指南或基础技术文章提供解释。

但是，当前产品详情页主要围绕设备适用性判断设计。

建立内容需求

完成这个任务需要哪些信息？

首先，用户需要了解设备的类型及用途，以确认进入了正确产品页面。

接着，他需要查看影响基本选型的关键参数。

随后，需要确认介质适用性、工作条件、材料和安装限制。

如果初步匹配，还可能进一步查看性能曲线、技术图纸或相关文档。

最后，如果仍有条件无法从公开信息中确认，页面需要提供与当前设备关联的技术咨询入口。

这些内容构成一条可以验证的任务路径。

重建页面模块

展示顺序	页面模块	对应任务
1	产品身份与用途概览	确认设备类型及主要应用
2	关键技术参数摘要	初步判断是否值得继续评估
3	适用条件与主要限制	排除明显不匹配的工况
4	完整技术规格与性能资料	进行进一步技术评估
5	型号差异与配置选项	比较候选型号
6	安装及技术文件	核实工程实施条件
7	相关支持能力与可靠证据	评估采购和实施风险
8	技术咨询与询盘入口	提交尚未解决的技术需求

这个布局并不是通用工业泵页面的唯一正确答案。

它是根据假设的主要用户任务建立的一版待验证结构。

如果实际研究发现用户通常先依据介质性质排除不适用设备，那么“适用条件”可以提前。

如果用户通常通过产品型号直接进入页面，可能需要优先展示型号对应的具体规格，而不是重复介绍整个产品系列。

页面结构应随着任务证据变化，而不是为了保持模板一致而拒绝调整。

如何证明改版有价值？

可以设计一个真实任务测试：

向具备相关背景的受试者提供一份明确的工业冷却系统工况说明，要求其在网站上找到符合基本技术条件的候选设备，并说明还有哪些条件需要供应商确认。

测试不应只观察受试者是否点击询盘按钮。

更重要的是观察他们能否正确识别参数，是否注意到适用限制，是否能够找到必要文档，以及最终判断是否合理。

如果受试者错误地选择了不适用型号，即使页面获得了较高的互动率，也不能据此判定任务完成良好。

相反，如果用户明确识别了设备限制，并决定暂不询价，这也可能是一项成功的任务结果。

因为页面帮助用户避免了无效采购沟通。

这说明 Task-First Layout 的评价范围必须超出单一转化率。

十一、如何将任务结构落实到 WordPress 页面模板？

在 WordPress 中，Task-First Layout 最适合通过内容模型、页面模板和可复用组件共同实现。

不能只要求编辑人员在每次发布页面时手动遵守任务顺序。

随着页面数量增长，人工管理容易出现结构漂移。

例如，某些产品页展示完整技术参数，另一些只有产品图片；某些页面具有清楚的适用限制，另一些则直接跳到询价表单。

如果网站希望保持稳定的信息质量，就需要让任务要求进入 CMS 结构。

ACF 字段应当服务于任务需要，而不是视觉组件数量

以产品技术页面为例，可以建立以下字段关系。

内容字段	建议用途	约束原则
product_purpose	产品用途与基本说明	必须有明确的产品对象
critical_specs	关键选型参数	根据产品类型确定字段和单位
operating_conditions	适用工况	说明必要的条件与范围
application_limits	主要使用限制	不得为了保持视觉整洁而省略
performance_documents	性能资料和技术文件	应关联文件版本及适用型号
model_variants	型号差异	采用可比较的统一数据字段
technical_inquiry	技术咨询入口	关联当前产品或型号

这些字段名只是工程示例，不能直接当成所有产品类型的通用数据库标准。

真正需要标准化的是字段的业务含义、数据类型、单位、适用范围和缺失值规则。

例如，不同设备的关键参数可能完全不同。

压力容器、工业泵和自动化控制系统不能因为共用同一套视觉模板，就被迫填写相同的技术字段。

如果某项参数不适用，应当具有可区分的“不适用”状态。

如果某项资料尚未取得，应当明确缺失，而不能默认生成空白参数或虚构技术结论。

GeneratePress 与 Gutenberg 的职责划分

GeneratePress 可以负责全站布局、主要容器、标题结构及模板层的样式组织。

Gutenberg 适合承载正文、辅助说明、技术解释和相对灵活的内容模块。

ACF 则可以负责需要稳定字段关系的技术数据。

这一组合的核心不是使用更多插件，而是避免把同一项信息重复输入不同位置。

例如，某产品的关键技术参数已经存在于结构化字段中，那么摘要模块、完整参数表和必要的结构化数据，可以在满足相应条件的情况下引用同一来源。

这样能够降低技术参数更新后出现页面信息不一致的风险。

不应允许视觉模板掩盖数据缺失

企业网站经常使用固定的模块设计。

但是，当某个字段没有真实信息时，系统不应该通过装饰性文字或模板默认值制造内容完整的假象。

例如，产品没有经过某项测试，就不能自动显示“通过全部测试”。

没有真实交付案例，也不应该为了保持版式整齐而生成虚构项目。

任务优先的模板设计应当允许内容模块根据真实数据变化，同时保证核心任务所需的信息不会被无意识删除。

十二、SEO/GEO 网站为什么更需要任务驱动，而不是关键词驱动排版？

传统 SEO 项目容易把页面规划理解为关键词与 URL 的映射关系。

关键词决定标题，标题决定章节，章节决定页面内容。

这种方法可以帮助建立初始主题范围，但不能完整解决内容是否满足用户需求的问题。

例如，搜索“industrial pump selection”的用户，可能真正需要的是一个用于判断设备适用性的过程。

如果页面只是解释设备类型，却没有说明如何根据工况筛选候选产品，那么即使它覆盖了大量相关关键词，也没有完整支持主要任务。

Google 在 Creating Helpful, Reliable, People-First Content 文档中，将用户阅读之后是否获得足够知识、能够帮助其实现目标，作为评估内容是否有帮助的重要思考方向。

这并不是对某种固定排版格式的要求。

它强调的是内容是否真正满足人的需求。

GEO 不意味着必须增加所谓的 AI 答案模块

随着 AI Overviews 和 AI Mode 的发展，一些网站开始在每个页面顶部增加摘要框、Quick Answer 或专门面向 AI 的说明。

这些组件在某些任务下可能有实际价值。

例如，一篇解释技术术语的文章，可以在开头直接给出简明定义，再详细讨论原理、条件和限制。

但是，对于需要根据工况进行复杂判断的产品页面，过度压缩的“最佳答案”可能掩盖必要条件。

如果设备选型取决于多个技术约束，页面就不应该为了形成一句简短答案，而省略这些约束。

Google 官方关于 AI 搜索功能的指导明确指出，参与 AI Overviews 和 AI Mode 并不需要额外的特殊优化或专门的 AI 标记。

因此，Task-First Layout 不应被包装为 AI 引用排名规则。

它首先是一种改善真实用户信息获取和任务完成的设计方法。

在此基础上，清楚的内容关系、明确的技术条件和可靠的证据，也能够改善信息的可理解性。

但页面是否被具体 AI 系统检索、选用或引用，仍然取决于多种因素，不能由布局形式单独决定。

十三、必须保留页面的语义结构和阅读顺序

任务优先并不意味着可以随意修改 HTML 顺序。

某些视觉设计可能通过 CSS Grid、Flexbox 的 order 属性或其他方式调整组件位置。

如果视觉顺序、DOM 顺序和键盘焦点顺序之间存在明显冲突，就可能造成阅读和交互问题。

W3C WCAG 2.2 的 1.3.2 Meaningful Sequence 要求：当内容顺序影响含义时，应当能够通过程序确定正确的阅读顺序。

2.4.3 Focus Order 则要求，当顺序影响含义或操作时，可聚焦组件的顺序必须保持合理的意义和可操作性。

因此，Task-First Layout 的实现需要同时检查三个方面。

首先，页面的视觉顺序是否支持主要任务。

其次，HTML 中的信息关系是否清楚，重要内容在脱离视觉样式后是否仍然能够理解。

最后，键盘导航、屏幕阅读器和移动端重排是否保留合理的操作顺序。

例如，桌面端的技术参数和咨询入口可能采用左右两列布局。

移动端将其改成单列时，应评估阅读顺序是否仍然自然，而不是只检查 CSS 是否产生溢出。

Google 的移动优先索引文档也要求关注移动端与桌面端主要内容的实质等价，以及重要内容能否被抓取和渲染。

这里应明确区分：W3C 可访问性成功准则属于规范性要求；Google 的移动端建议属于搜索技术指导；本系列提出的 Task-to-Layout 映射属于内部工程方法。

三者相互关联，但不是同一套标准。

十四、怎样建立 Task-First Layout 的验收体系？

页面完成之后，不能仅依据“模块已经制作完成”宣布项目合格。

真正需要回答的是：页面是否支持了设计阶段确定的用户任务。

建议将验收拆分成三个层次。

第一层：结构与内容验收

这一层确认页面是否具备支持任务的基本信息。

例如，产品页是否提供必要技术参数，关键限制是否存在，相关文档是否能够访问，不同模块中的数据是否一致。

结构与内容验收可以部分通过字段检查和自动化测试完成。

如果必须存在的技术字段缺失，页面就不应仅仅因为模板能够正常渲染而通过验收。

但自动化工具不能判断所有技术内容是否正确。

实际参数和适用条件仍需由具备相应知识的人员确认。

第二层：任务完成验收

这一层需要模拟真实用户任务。

例如，提供一个具有明确技术约束的设备选型场景，让目标用户使用页面完成判断。

团队应记录用户是否完成任务、判断是否正确、是否忽略关键限制、是否获得必要资料，以及哪些步骤存在障碍。

任务完成率可以定义为：

Task Completion Rate = 成功完成指定任务的有效测试次数 ÷ 有效测试总次数 × 100%

但必须事先定义“成功完成”。

如果任务是判断设备是否适用，那么正确排除不适用设备也属于成功。

如果任务是核实交付条件，找到并理解企业的真实交付能力，比单纯打开联系页面更接近任务完成。

不能将所有用户点击、表单提交或页面滚动直接视为任务成功。

第三层：上线后效果验证

网站正式运行后，可以继续观察与任务相关的行为。

例如，技术文档使用情况、站内搜索问题、产品比较行为、客户咨询内容及有效询盘质量。

但是，不能将某一个事件数量增长直接解释为任务体验改善。

例如，PDF 下载次数减少，可能是因为网页已经提供了足够信息，也可能是因为下载入口变得更难发现。

同样，某页面停留时间缩短，可能意味着用户更快找到了答案，也可能意味着内容不符合预期。

因此，需要结合任务研究和实际运营数据进行判断。

对于页面改版，还应尽可能保证比较期间的用户来源、流量结构和测试条件具有可比性。

如果条件允许，可以使用受控实验或分阶段发布验证效果。

如果没有足够数据，就应明确报告观察结果与不确定性，避免把设计判断描述为已证明的因果关系。

十五、制定 Task-First Layout 的工程验收标准

建议在企业网站项目中建立以下设计验收矩阵。

编号	验收对象	必须回答的问题	验证方法
TFL-01	任务定义	页面是否具有明确的主要用户任务？	Task Card 审查
TFL-02	证据基础	任务判断是否具有可追溯的事实或研究依据？	研究资料与证据状态检查
TFL-03	内容覆盖	页面是否包含完成任务所需的必要信息？	信息需求与字段映射检查
TFL-04	优先级	关键内容是否容易发现，限制条件是否被合理呈现？	原型审查与用户测试
TFL-05	模块映射	每个主要模块是否能够解释其服务的任务？	Task-to-Layout Mapping
TFL-06	多角色支持	辅助任务是否具有明确的内容或导航路径？	多角色场景检查
TFL-07	语义结构	HTML 标题、区域及阅读顺序是否合理？	DOM 与辅助技术检查
TFL-08	移动端一致性	核心任务所需信息是否在移动端保持完整？	响应式与渲染测试
TFL-09	交互可用性	用户能否实际使用必要组件？	键盘及任务操作测试
TFL-10	任务结果	用户能否正确完成预设任务？	用户任务测试
TFL-11	数据治理	页面字段、文档及来源是否可持续维护？	内容模型及责任检查
TFL-12	运营测量	是否可以通过适当指标持续评估效果？	事件定义、数据质量与分析审查

以上 TFL 编号为本系列建议的内部标准标识，并非行业认证或 Google 官方规范。

实际项目可以按照页面风险和复杂程度确定哪些项目需要强制验收。

建立 P0、P1、P2 三类问题级别

P0：任务阻断与重要误判风险。

如果缺少必要信息、页面错误表达关键限制、核心内容不可访问，或者交互故障导致用户无法完成主要任务，应当优先修复。

P1：明显影响任务效率或判断质量。

例如，关键信息难以定位、复杂表格在移动端无法正常阅读、相关文档缺少清楚入口，或页面模块顺序造成不必要的反复跳转。

P2：可持续改善的体验问题。

例如，视觉间距不一致、某些次要内容展示不够紧凑，或者辅助导航仍有优化空间。

这一优先级模型应该结合实际业务风险使用。

影响安全、合规或重要采购判断的信息问题，不能因为发生频率较低而自动降级。

十六、如何建立可复用的 Task-First Layout 工作流程？

为了避免每个页面都重新发明设计方法，可以将 Task-First Layout 纳入标准的网站建设流程。

需求阶段：先确认任务，不急于确定页面组件

在项目启动时，由业务、产品、内容、SEO 和技术人员共同识别核心用户任务。

这一阶段应输出任务陈述、证据状态、成功标准及主要风险。

如果关键任务没有足够证据支持，应当明确安排补充研究，而不是直接认定某个模板能够满足需求。

结构阶段：将任务转换为内容与模块

根据任务所需信息，制定内容字段、模块关系和初步页面结构。

这一阶段需要判断哪些内容必须同时出现，哪些可以分层呈现，哪些任务需要跳转到其他页面继续完成。

同时建立 Task ID 与内容模块之间的映射。

原型阶段：优先验证信息结构

在投入完整视觉设计前，应先通过低保真原型确认页面结构是否合理。

这一阶段不需要大量动效、精细配色和复杂图片。

重点是验证用户能否找到关键内容、理解任务路径，以及是否存在明显的内容缺口。

如果基础结构已经无法支持任务，继续制作高保真设计通常只会提高修改成本。

开发阶段：将任务规则落实到 CMS

开发人员根据经过确认的内容模型与模块规范进行实施。

结构化信息进入明确字段，正文内容保留必要的语义结构，交互组件符合可访问性要求。

对于多语言网站，不能假定翻译后的页面任务与原语言页面完全一致。

语言、市场和采购流程差异可能影响必要资料、单位表达、业务说明及行动入口。

这些变化需要通过业务和用户研究确认。

验收阶段：同时验证页面与任务

最终验收不只检查响应式效果和功能状态，还应检查 Task Card 中定义的成功条件。

只有结构完整、操作正常且主要任务获得合理支持，页面才具备进入正式交付的条件。

上线之后，应通过新的用户证据持续调整任务模型。

标准化的对象应当是决策过程与质量要求，而不是将所有页面固定为完全相同的布局。

十七、Task-First Layout 的边界：它不能解决哪些问题？

Task-First Layout 可以改善页面设计决策，但不能代替所有网站建设工作。

首先，它不能弥补企业产品本身的信息缺失。

如果制造商没有可靠的性能数据，设计师无法通过合理的页面布局创造这些数据。

其次，它不能保证网站一定获得更好的搜索排名。

清楚的信息组织符合用户导向的内容建设原则，但搜索结果仍然受相关性、内容质量、网站技术条件、竞争环境和其他因素影响。

第三，它不能保证商业转化增长。

用户可能通过页面判断某设备并不适合自己的需求。

这属于任务层面的正确结果，却不一定产生询盘。

第四，它不能替代专业领域判断。

设备选型可能涉及技术安全、工程设计和合规要求。

页面能够提供初步评估信息，但不应将有限的公开资料包装为适用于所有情况的完整技术结论。

最后，它也不意味着每个页面都必须进行成本高昂的正式用户研究。

企业可以根据任务重要性、信息风险、现有证据和项目资源选择适当的研究深度。

但团队必须清楚哪些决策已经获得验证，哪些仍属于假设。

结语：从完成页面，转向帮助用户完成任务

传统网站设计流程容易把最终交付对象理解为一张页面。

页面是否上线、模块是否齐全、视觉是否统一，成为衡量项目完成程度的主要标准。

Task-First Layout 改变的是这种评价方式。

页面不再只是视觉组件的集合，而是支持用户完成特定目标的信息与交互系统。

用户任务决定必要信息，内容语义决定表达关系，视觉设计建立识别顺序，交互提供操作路径，技术交付保证页面能够实际使用。

这与第一篇提出的五层模型形成了直接连接。

对于 SEO/GEO 网站建设而言，真正值得标准化的不是某一种流行的页面风格，也不是在所有文章中增加统一的摘要框、目录或 CTA。

而是一套能够持续回答以下问题的设计机制：

这个页面为谁而存在？他们需要完成什么任务？哪些信息是完成任务的必要条件？这些信息如何被组织和呈现？最终通过什么证据证明页面已经发挥作用？

当这些问题能够在设计、开发和验收阶段获得清楚回答，网站排版才真正从视觉制作进入工程化管理。

Task-First Layout 的核心原则是：不以模块齐全证明页面合格，而以信息完整、任务可完成和结果可验证作为设计质量的判断依据。

这将成为本系列第二项基础规范。

---

技术参考资料

以下资料用于支持本文对任务分析、用户需求研究、渐进式披露、HTML 结构、可访问性和 Google 搜索的相关论述。Task Card、Task-to-Layout Mapping、TFL 验收编号及内部优先级分类是本系列提出的工程化方法，不属于上述组织发布的统一标准。

[1] Nielsen Norman Group — Task Analysis: Support Users in Achieving Their Goals
https://www.nngroup.com/articles/task-analysis/

[2] GOV.UK Service Manual — Understand users and their needs
https://www.gov.uk/service-manual/service-standard/point-1-understand-user-needs

[3] GOV.UK Service Manual — Learning about users and their needs
https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs

[4] GOV.UK Service Manual — How to set performance metrics for your service
https://www.gov.uk/service-manual/measuring-success/how-to-set-performance-metrics-for-your-service

[5] Nielsen Norman Group — Progressive Disclosure
https://www.nngroup.com/articles/progressive-disclosure/

[6] W3C WAI — Page Structure Tutorial
https://www.w3.org/WAI/tutorials/page-structure/

[7] W3C WCAG 2.2 — Understanding Meaningful Sequence
https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html

[8] W3C WCAG 2.2 — Understanding Focus Order
https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html

[9] Google Search Central — Creating Helpful, Reliable, People-First Content
https://developers.google.com/search/docs/fundamentals/creating-helpful-content

[10] Google Search Central — Mobile-first Indexing Best Practices
https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing

[11] Google Search Central — AI features and your website
https://developers.google.com/search/docs/appearance/ai-features

---

下一篇：SEO / GEO 网站排版设计标准与规范细则（三）：Visual Hierarchy——为什么用户看到了内容，却没有识别出重点？

下一篇将在 Task-First Layout 所确定的信息优先级基础上，进一步研究视觉层级如何影响用户识别与判断。

重点建立 Typography Scale、Visual Weight、Spacing、Contrast、Grouping 与 Attention Hierarchy 的设计关系，并形成能够应用于文章页、产品页和企业页面的视觉层级规范及验收方法。