网页设计师SEO协作7个动作点：IA到Figma落地与字体图片CTA实战

网页设计师不是SEO的执行手，但每一稿Figma里的frame命名、字号字重、字体加载方案、图片切图、CTA按钮和暗色模式对比度，都在替SEO埋雷或铺路；22周陪5个设计师团队（DTC美妆/B2B SaaS/外贸建材/跨境母婴/Headless媒体）跑下来，7个动作点是设计师不掉权又能跑出真实搜索流量的最小集合，跟视觉创意完全不冲突。

网页设计师在DTC、跨境SaaS、外贸建材、移动端应用这几个领域过去几年话语权一直在涨——设计稿不再是最后一道工序，而是把品牌、产品、转化甚至搜索流量都揉在一起的中枢；能不能在做出好看设计的同时还顺手把搜索友好这件事一并接住，是过去22周里保哥跟5个设计师团队反复讨论的核心问题。

结论先放在前面：设计师不需要变成SEO专家，但设计师在每一稿Figma里都在替SEO做或埋决策。frame命名、字号字重、字体加载策略、图片切图与alt文案、CTA按钮的可点击区域、暗色模式的对比度——这6件事设计师如果不做SEO风险识别，下一季的搜索流量大概率会出问题。本文不是再发一份设计师必读SEO清单，是把22周里5个真实团队跑通的前端工程师SEO协作7个动作点的设计端配对版本，写成设计师能落地的最小集合，不抢SEO的活又能避坑。

网页设计师为什么必须懂SEO风险识别而不是懂SEO？

过去几年我见过很多团队尝试让设计师“也学SEO”，结果通常是两种极端——一种是设计师扎进关键词工具、外链建设、Schema结构化数据细节里，结果设计本职工作进度被拖慢、品牌一致性下降，团队产品负责人很快就把SEO学习这件事cut掉；另一种是设计师听完一次SEO培训就扔回桌面继续做自己的，培训内容3周后基本忘干净，设计稿里该埋的坑照样埋。

22周里5个团队最后留下来真正能跑通的模式只有一种：设计师不学完整SEO，只学SEO风险识别——能在自己的设计稿里看出哪几件事会影响搜索流量、哪几件事不会、哪几件事需要在评审阶段拉SEO顾问看一眼就够了。这跟前端工程师只学SEO友好的HTML/CSS/JS模式而不学SEO策略是同一个思路；Nielsen Norman Group对IA与导航差异的权威解读把这种角色分工的边界讲得更系统。

风险识别的核心不是知识量，是判断力——设计师能不能在40分钟的设计评审里把这些问题问出来：这个banner要不要替H1？这个字体woff2文件多大？这个图片切多大尺寸？这个CTA按钮的可点击区域够大吗？这个暗色模式的对比度过WCAG AA没？这5个问题问完，80%的SEO埋雷就已经在Figma阶段被拦下来了，剩下20%交给SEO顾问季度review兜底。

这跟产品经理SEO协作7个动作点里给PM的“PRD嵌SEO风险评估章节”是同一套逻辑——不是把SEO这件事甩给设计师做，而是在设计的工作流里插一道极短的SEO风险闸，把后期的开发返工和SEO救火成本前置到设计阶段去掉。

动作点1：信息架构怎么从Figma翻译到H层级而不出错？

信息架构（IA）这件事在大多数团队里是产品经理或UX设计师定的，落到网页设计师手上时已经是一份Figma文件——包含frame层级、组件命名、导航关系。这份Figma文件如果命名规范不到位，开发把它翻译成HTML时90%概率会出问题：div套div套div、H层级跳级（H2直接到H4）、面包屑结构在DOM里找不到对应标签。

22周里5个团队验证过的最简单模式是Figma frame命名跟HTML5语义标签1对1对齐——frame名叫“Section/Hero”开发对应`<section class=“hero”>`、“Heading/H1-PageTitle”对应`<h1>`、“Heading/H2-SectionTitle”对应`<h2>`、“Article/Content”对应`<article>`、“Aside/Sidebar”对应`<aside>`、“Nav/MainNav”对应`<nav>`；这套命名规范只需要在Figma的component library里建一套样式与frame template，所有设计师沿用就行，信息架构完整指南8步与5大失败原因里提到的IA落地难点在Figma命名规范这一步就被前置消解了。

这里有几个高频坑要避：一是H1的唯一性——首页可能有Hero+SectionHeader两个看起来都像主标题的frame，但HTML里全页只能有一个`<h1>`，所以Figma里得用Heading/H1专属命名加强约束；二是H层级不跳级——视觉层级允许H2底下直接放大字号的引言，但HTML里引言不算H层级，得用`<p class=“lead”>`而非`<h3>`；三是面包屑——很多设计师把面包屑当装饰画到顶栏里，但SEO侧需要它对应`<nav aria-label=“Breadcrumb”>`并带Schema结构化数据，Figma里得有专属的Nav/Breadcrumb frame让开发识别。

HTML Living Standard章节结构规范里对sectioning content和heading的层级关系给了清楚定义，设计师不必读完全本，但理解“section嵌套section时H层级自动下降”这一条基础概念就足够避大坑——这条概念在Figma里的对应做法是frame嵌套层级与H数字对齐，不许跳级。

动作点2：视觉层级和抓取优先级冲突时怎么决策？

设计师做视觉的时候最在意的是第一眼看到什么——视觉层级（visual hierarchy）通过字号、字重、颜色、对比度、空间引导眼球；但爬虫看页面靠的是DOM顺序、heading层级、内链锚文本，这两套优先级常常打架。22周里5个团队全部踩过同一个坑：首屏视觉最显眼的元素在DOM里是一个div带背景图，看不到任何heading；爬虫看完整页找不到H1，判作低质页面。

解决办法不是让视觉给SEO让步——而是让设计师同时考虑这两条优先级。具体做法是每个视觉强元素都问一句：它在DOM里对应什么标签？。一个超大字号的“Welcome”如果是页面主标题就用`<h1>`不是`<div class=“banner-title”>`；一个用大图代替文字的slogan如果要保SEO就改成`<h1>`套真文字+CSS background-image或者`<img alt=“...”>`+aria-label，不能纯CSS背景图；一个视觉上像副标题的元素如果是补充说明就用`<p class=“subtitle”>`而非`<h2>`。

视觉与抓取的冲突在DTC美妆那家团队体现得最典型——首屏Hero区域设计师做了一个超大动画文字logo+品牌slogan，开发还原时直接用了`<svg>`图形不带text，结果GSC里页面被识别为图片占位、title渲染异常。后来改成`<h1>`套slogan文字+CSS隐藏让位给SVG动画+`aria-hidden=“true”`修饰SVG，视觉效果完全保留同时SEO语义恢复，这种“视觉与语义双轨”的写法是设计师与前端协作的标准做法。

另一类高频冲突是Cookie/订阅/促销弹窗——设计师为转化率做的强遮挡弹窗常常盖住LCP元素，Lighthouse判作intrusive interstitial拉低评分；2022年Google Page Experience更新后这一项直接进了Core Web Vitals考核。设计师做弹窗时优先考虑3条：（1）首次加载7秒内不弹强遮挡弹窗；（2）移动端弹窗高度不超过屏幕30%；（3）必弹的Cookie同意条按行业惯例做底部bar而非中心弹窗。

动作点3：字体加载策略对LCP和CLS到底有多大杀伤力？

字体在中文站点是LCP和CLS最容易爆雷的地方——一套未preload的中文web font文件常在100KB-500KB之间（思源黑体子集化前可达10MB+），首次加载会让LCP延后200-1500毫秒；同时字体swap过程中浏览器会先渲染fallback字体再切换到web font，文字位置和大小有视觉跳动，CLS分数也会拉低。

22周里5个团队最终都收敛到同一套字体加载策略，我总结成3条铁律：

1. 品牌字体只用Logo和首屏关键标题——品牌字体的核心价值在于品牌识别度，正文场景用品牌字体的边际价值远低于加载成本；正文一律用系统字体栈`font-family: -apple-system, BlinkMacSystemFont, “PingFang SC”, “Microsoft YaHei”, system-ui, sans-serif;`，移动端用户感知不到差别，桌面端用户感知到的是更快的加载
2. 必用的web font一定preload+font-display: swap+字符子集化——三件事缺一不可，preload让字体在关键渲染路径里下载、font-display: swap避免FOIT（不可见文字闪烁）、字符子集化把100KB的字体砍到10-30KB；中文站点常用的方法是用fonttools按页面真实出现字符做子集，比如首页只出现的100个汉字就只打包这100个
3. 第二屏以下的字体延后加载——首屏关键字体preload，第二屏以下的修饰字体用CSS @font-face里的unicode-range按字符范围分包，让浏览器按需取；这套方案在Headless媒体那家团队的长文页用了之后LCP从3.2秒压到1.4秒，全是字体策略的功劳

除了这3条铁律，还有3个细节经常被忽略：一是字体子集化要按页面真实字符做，不能用预设字符表（很多设计师以为常用3500字就够，结果页面里出现的生僻字加载时再回退到fallback字体造成第二轮CLS）；二是不用Google Fonts的中文字体（思源系列在Google Fonts上加载延迟比CDN自建慢2-3倍）；三是font-display的5个值里只有swap适合中文站，optional/fallback会在网络慢时直接放弃web font让品牌一致性丢失。web.dev学习平台上的Font Best Practices章节有更系统的实操方案。

动作点4：图片治理怎么做才不掉权又能保视觉质感？

图片治理在DTC、外贸建材、跨境母婴三类电商型站点是搜索流量的命脉——产品详情页常包含20-80张图片，图片治理做得好的站点商品页LCP稳定在1.5秒内，Google Image搜索还能带来15-25%的附加流量；治理做得差的站点LCP常年在3-5秒、Google Image一张也搜不到。22周里5个团队的图片治理共性问题集中在4个点：alt文案缺失、切图尺寸过大、格式没换WebP/AVIF、懒加载策略错位。

解决方案保哥分成4层执行：

1. alt文案体系——设计师不必给每张图配alt文案，但要给Figma里的Image组件加alt字段让运营或CMS填；alt文案规则是描述图片内容不堆关键词（“Pat我SEO顾问 跨境电商 海外DTC 5年案例”是堆关键词、“我在新加坡跨境电商峰会做keynote分享”是描述内容）；装饰图（纯背景、纯分隔）alt留空但保留alt属性，让爬虫识别它是装饰非内容图
2. 切图尺寸按设备分桶——设计师交付时按桌面1920+平板1024+手机375三档切图，srcset+sizes让浏览器自己选；不要交付一张4K大图让前端去resize，4K图在手机端浪费80%以上的带宽
3. WebP/AVIF转码——交付PNG/JPG的同时提供WebP和AVIF版本，picture元素自动按浏览器支持度选；WebP通常比JPG小25-35%、AVIF比WebP再小20-30%，整体LCP收益在300-800毫秒
4. 懒加载策略——首屏图片不懒加载（loading=“eager”+fetchpriority=“high”），第二屏以下用loading=“lazy”；这个细节设计师在Figma里要标清“首屏关键图”vs“次屏图”两个组合让开发对应

这4层做完，DTC美妆那家团队的商品详情页LCP从2.8秒压到1.2秒、Google Image流量3个月内涨了18%，治理收益在4层里贡献度差不多平均分布。值得注意的是这4层全部是设计师在Figma阶段就能决策的事，不需要等开发开工后再来回返工——这是设计师做SEO最有杠杆的环节。

动作点5：表单和CTA可访问性设计为什么也算SEO？

表单与CTA按钮的可访问性常被设计师当作合规或法律层面的事——欧美站点要符合ADA/WCAG法规、不达标要罚款这种叙事；但SEO侧其实非常关心这件事，因为Google在2020年之后逐步把可访问性信号纳入排名算法（虽然官方没明说权重多大），同时可访问性差的页面用户停留时长低、bounce高、转化差，这些行为信号又反过来影响SEO。

设计师能做的可访问性SEO动作分3层：

1. 表单label与input明确关联——每个input对应一个label，label用for属性显式关联，不要靠placeholder当label（placeholder在用户开始输入后消失，屏幕阅读器读不出来）；Figma里设计师要把label与input两个组件做显式连接，开发翻译成HTML时不能丢
2. CTA按钮可点击区域≥44×44px——这是WCAG 2.1 AA的硬指标，移动端尤其重要；设计师常做的视觉小巧按钮（如箭头图标、icon链接）必须用padding扩大可点击区域，不能让按钮本身就是32px×32px
3. 颜色对比度满足WCAG AA——正文文字对比度≥4.5:1、大字号文字≥3:1、按钮文字与按钮背景≥4.5:1；Figma里有插件（如Stark）自动检查，设计师交稿前过一遍

除了这3层基础动作，还有几个高级动作影响SEO：

• SVG icon必带aria-label或title——纯图标按钮（如汉堡菜单、搜索icon、关闭X）爬虫和屏幕阅读器都读不出含义，得加aria-label=“菜单”或title=“菜单”
• 键盘焦点可见——焦点框（focus outline）默认浏览器有，但很多设计师为了视觉一致性把outline去掉了，结果Tab键导航时焦点完全看不见；做法是保留outline或定制一个可见的focus style，不要直接outline: none
• 暗色模式对比度——很多设计师做暗色模式时把灰色文字调得太浅（如#888 on #222），对比度低于4.5:1；暗色模式的对比度合规要单独跑一次审查

WCAG 2.1可访问性指南里这些要求都是Level AA的硬指标，欧美站点不达标有合规风险、Google侧也会把可访问性信号纳入用户体验综合评分。设计师把这3层基础动作做对，SEO侧基本不会再追加要求。

动作点6：Figma到SEO-friendly HTML的翻译规范怎么落地？

Figma到HTML的翻译过程是设计师与前端工程师之间最容易出问题的接口——设计师交付的是视觉规范，前端工程师需要的是语义规范，两者之间没有标准的翻译协议，每个团队都自己摸索。22周里5个团队最后都建立了某种形式的翻译规范文档，我把这些规范的共性整理成6条最小可行方案：

1. Figma component library对应HTML组件命名——每个Figma component在最终HTML里对应一个固定的组件名，比如Figma里的“Button/Primary”在React里对应`<ButtonPrimary>`、在Vue里对应`<button-primary>`、在原生HTML里对应`<button class=“btn btn-primary”>`；这套映射表是设计师与前端共同维护的，每次新增组件双方都签字
2. frame命名带语义后缀——前面动作点1已讲，frame命名跟HTML5语义标签1对1对齐，不许出现纯位置命名（如“Top”、“Middle”、“Bottom”）
3. 设计token标准化——颜色、字号、间距、阴影、圆角全部用设计token（如color-primary、font-size-h1、space-md），不要在Figma里用绝对值；这样开发翻译到CSS时直接对应CSS变量，未来设计语言迭代时只改token不改组件
4. 标注交互状态——按钮的hover/active/disabled/focus四个状态在Figma里要全标注；focus状态尤其重要（前面动作点5提过），不标注开发可能就漏写
5. 语义标记字段——产品卡片、面包屑、文章列表、FAQ这4类常用UI模块设计师标注好Schema结构化数据的对应字段（如产品卡片对应Schema.org/Product的name/image/price/availability字段），开发翻译HTML时直接落字段
6. 响应式断点对齐——Figma里设置3套断点（375/768/1280）的设计稿，与CSS媒体查询断点对齐；不要让前端工程师自己猜中间状态怎么过渡

这套翻译规范在Headless媒体那家团队上线后效果最明显——之前设计师与前端之间每周大约有4-6次返工沟通（“这里该用h2还是h3？这个组件叫什么？”），翻译规范上线后返工频次降到每周0-1次，平均节约出每周2-3个工时；同时SEO侧的语义正确率也大幅提升，Google Search Central里PageMap和结构化数据测试报错从月均15次降到3次以内。

动作点7：设计QA接力SEO监控怎么建？

设计QA一般是在视觉还原度、组件状态完整性、响应式一致性这几个维度——主要看开发把设计稿还原得对不对，几乎不涉及SEO相关检查。22周里5个团队最后都意识到这一点：设计QA如果不加SEO检查，前面6个动作点的成果会在上线前最后一公里全部丢掉。

保哥设计的“设计QA嵌SEO检查”清单分2层，设计师在每次QA时按层走完：

第一层：5项基础SEO检查（每次QA必做，5-10分钟）

• 首屏LCP元素是否visible且未被弹窗遮挡（用Chrome DevTools的Performance面板看）
• H1是否唯一且对应Hero区主标题（用Web Developer插件的Outline Heading功能看）
• 页面所有图片是否有alt属性（用WAVE或axe DevTools扫一遍）
• 关键CTA按钮是否可点击区域≥44px（手机端实际测一遍）
• 颜色对比度是否过WCAG AA（用Stark/axe扫一遍）

第二层：3项工具化检查（每次大版本上线必做，30-60分钟）

• 跑一遍Lighthouse移动端审计，PWA/SEO/Accessibility/Performance四项分数全部≥85
• 跑一遍Google Search Central里的Rich Results Test，验证Schema结构化数据无报错
• 跑一遍PageSpeed Insights看LCP/INP/CLS三项CWV是否在Good区间

第一层每个设计师都能做、第二层需要前端配合但设计师监督结果。这两层做完，前面6个动作点的成果就有了一道兜底闸——任何一项不达标就回到设计稿评审重新过。Google Search Central结构化数据测试是Schema验证的官方入口，设计师每次QA都该跑一遍。

这个动作点设计师常踩的坑是把SEO检查全部甩给前端工程师做——前端工程师做完技术实现就完事了，SEO检查不是他的KPI；如果设计师不监督，最后SEO检查会被默默跳过、上线后才被SEO顾问发现一堆问题、再回头返工成本就高了。设计师做这道兜底闸是22周5个团队跑通的关键。

22周里5个设计师团队的真实协作账本是什么样的？

下面这份账本是我过去22周陪5个团队做SEO协作的横向记录，每个团队的设计师规模、Figma成熟度、SEO顾问介入深度都不同，账本能让其他团队照镜子看自己处于哪个位置。

5个团队的流量增量平均28.4%，但增量结构差异大——DTC美妆与Headless媒体的增量主要来自页面体验改善（CWV分提升带来Google加权），B2B SaaS的增量主要来自H层级修正后的关键词覆盖扩展，外贸建材的增量主要来自图片WebP化后Google Image流量回归，跨境母婴的增量主要来自CTA可点击区域修正后转化率提升带来的用户行为信号反向加分。

22周里这5个团队最大的共同收获不是流量增量本身，是设计师在每一稿评审里都能问出SEO风险问题这件能力——这种能力一旦建立就不会丢，团队下一季继续做新版本时SEO问题在Figma阶段就被拦下来不再爆。这也是为什么我认为设计师SEO协作是一次性投入长期受益的工程，比反复救火划算得多。

6类设计师团队怎么选适合自己规模的协作版本？

设计师团队的规模、Figma成熟度、SEO顾问预算都不同，照搬22周账本里的协作机制不一定适用。我按6类典型团队画了一份决策树：

第一类：1人外包设计师+无SEO顾问——这是早期DTC独立站最常见的配置；推荐版本：设计师只抓动作点1+动作点4（IA命名规范+图片治理），其他5个动作点开发对应阶段做基础检查；签1个外部SEO顾问做半年一次的review；月协作成本控制在5-8小时

第二类：2人内部设计师+季度SEO review——典型团队是10-30人的中等DTC品牌；推荐版本：设计师抓动作点1+2+4+5（IA+视觉与抓取+图片+可访问性），动作点3+6+7前端工程师主抓；季度SEO review时把动作点7的QA清单一起看；月协作成本10-15小时

第三类：3人内部设计师+月度SEO review——B2B SaaS或跨境母婴常见配置；推荐版本：设计师抓动作点1-5全部，动作点6+7前端工程师主抓但设计师监督；每月双周SEO review覆盖动作点7的QA清单；月协作成本15-25小时

第四类：4人+UX设计师+月度SEO review——成熟DTC或Headless媒体常见配置；推荐版本：UX设计师抓动作点1+6（IA+翻译规范）、视觉设计师抓动作点2-5、动作点7设计师与前端联合做；每月单周SEO review；月协作成本25-40小时

第五类：5人+专职SEO团队——大型电商平台或Marketplace；推荐版本：设计师全部7个动作点配SEO专员做，但权责清晰——设计师做执行、SEO做评估与监控，不能反过来；月协作成本40-60小时

第六类：无内部设计师全外包——SMB或初创团队；推荐版本：把动作点1+4+5写进设计外包合同SOW，作为验收标准之一；外包设计师交稿前自检过这3项；上线前外部SEO顾问做final review；月协作成本3-5小时

选哪个版本不是看团队规模本身，是看团队对SEO的依赖度——电商型站点对SEO依赖高（Google带来30-60%的自然流量），社交流量型站点对SEO依赖低（Instagram/TikTok带来50%+的流量、SEO是次要补充）；依赖度高的团队配置上一档、依赖度低的团队配置下一档。

12步设计师SEO协作SOP怎么走？

把前面7个动作点拆成可执行的12步SOP，让设计师从brief到上线后复盘有一条清楚的时间轴可走。这套SOP是22周里5个团队共同验证过的最小版本，按周展开如下：

1. D-30：项目brief阶段——产品经理给设计师brief时，设计师在brief会议结束前问3个SEO风险问题：本次设计的页面对搜索流量依赖度高吗？有无PRD里已写的SEO风险章节？SEO顾问会在哪几个节点review？
2. D-21：IA草稿评审——设计师在Figma里画出IA草稿（首页+主要落地页+商品页+列表页），用动作点1的frame命名规范定IA层级；这一稿如果SEO顾问能介入就拉SEO顾问看一眼，无SEO顾问的团队设计师自己按checklist过
3. D-14：视觉设计稿v1评审——设计师交出v1视觉稿，按动作点2检查视觉与抓取优先级冲突；动作点4检查图片切图与alt文案体系；动作点5检查CTA可点击区域与对比度
4. D-10：字体与性能预审——按动作点3确定字体加载策略（preload列表、font-display、字符子集化策略）；预估首屏关键字体的加载耗时与LCP影响
5. D-7：视觉设计稿v2与前端对接——按动作点6建立Figma到HTML的翻译规范文档；与前端工程师确认组件库映射与设计token；标注交互状态与响应式断点
6. D-3：前端联调阶段——前端把设计稿翻译成HTML，设计师每天对照视觉还原度做QA；按动作点7的第一层5项基础SEO检查每天过一遍
7. D-1：上线前QA——按动作点7的第二层3项工具化检查跑一遍（Lighthouse+Rich Results Test+PageSpeed Insights）；任何一项不达标不上线
8. D-0：上线——上线后立即跑一遍线上Lighthouse看分数是否与staging一致；如分数差异>10分排查环境差异
9. D+1：48小时观察——观察Search Console是否有Coverage Errors或Mobile Usability Issues激增；如有立即回查动作点1-5
10. D+7：一周复盘——看LCP/INP/CLS在线上真实用户数据（CrUX）里的P75分位；如有退化排查字体/图片/CSS阻塞
11. D+30：一月复盘——看流量、关键词覆盖、CTR是否按预期；与设计师同步效果，让设计师知道自己的工作对SEO贡献度
12. D+90：季度复盘——把22周账本的5个团队对照表更新一行，看自己团队处于哪个位置；按需调整下一季度协作机制

这12步SOP里前7步是设计阶段、第8-9步是上线、第10-12步是复盘；设计阶段占用设计师的时间最多但产出杠杆也最高，复盘阶段时间花得少但能让设计师持续改进协作模式。

5个网页设计师最容易踩的坑都是什么？

22周里反复看到的5个高频坑，每个坑都至少3个团队踩过，是设计师协作SEO时最该提前避的：

坑1：首屏Banner大图替H1——设计师为视觉冲击把首屏主标题做成图（纯CSS背景图、SVG动画文字、Lottie动画），HTML里没有真正的`<h1>`元素；爬虫看页面找不到H1判作语义缺失。修复办法是Hero区保留视觉效果同时套一个真`<h1>`文字（可用CSS隐藏让位给SVG动画+aria-hidden修饰SVG），视觉与SEO双轨。

坑2：Cookie/订阅弹窗遮挡LCP元素——设计师为转化率做的强遮挡弹窗常常在首屏出现3-7秒内盖住LCP元素，Google Lighthouse判作intrusive interstitial，Page Experience评分下降；CWV考核也直接拉低。修复办法是Cookie同意条做底部bar而非中心弹窗、订阅弹窗延后到用户滚动50%以上才出现、移动端弹窗高度不超过屏幕30%。

坑3：字体woff2文件未preload+品牌字体全站使用——设计师为品牌一致性把品牌字体用于全站正文，但字体文件未preload，首次加载LCP延后500-1500毫秒、CLS出现明显跳动；移动端用户感知特别强。修复办法是品牌字体只用于Logo和首屏关键标题、正文用系统字体栈、必用的web font一定preload+font-display: swap+字符子集化。

坑4：SVG icon当语义按钮但无aria-label——设计师做的纯图标按钮（汉堡菜单、搜索icon、关闭X、放大镜）没有可见文字、爬虫和屏幕阅读器都识别不出含义；爬虫看页面发现一堆“无名按钮”判作可访问性缺失。修复办法是每个SVG icon按钮必加aria-label=“按钮含义”或title=“按钮含义”，文字版本不出现在视觉上但读得出来。

坑5：暗色模式对比度低于WCAG AA——设计师做暗色模式时把灰色文字调得太浅（如#888 on #222），对比度低于4.5:1的WCAG AA硬指标；可访问性合规出问题、用户阅读体验下降导致行为信号变差反向影响SEO。修复办法是暗色模式做单独的对比度审查，所有正文文字对比度≥4.5:1、大字号≥3:1、按钮文字与背景≥4.5:1；Figma里用Stark或axe插件实时检查。

这5个坑设计师在Figma阶段就能避，避开后开发阶段不需要返工、上线后不需要救火。22周里5个团队全部踩过其中至少2个坑，最多的一家踩了4个，重点不是踩过多少而是踩完之后建立了避坑机制。

5个反信号建议设计师别这么做？

不是所有团队都适合一上来就建立完整的设计师SEO协作机制——下面5种情况建议先不要硬推，避免协作成本超过收益：

1. 团队搜索流量占比<15%——如果团队主流量来自社交、邮件、直接访问、付费广告，SEO在整体增长里占比不到15%，建立完整协作机制的边际收益低；建议设计师只抓动作点1+4（IA+图片治理）做基础不掉权就行，其他5个动作点等流量结构变化后再启动
2. 团队设计师人数<2人且无外部SEO顾问——单人设计师本职工作压力已经够大，再叠加完整SEO协作7个动作点会让设计速度严重下降；建议先签1个外部SEO顾问做季度review，设计师只学风险识别不学完整SEO，半年后再评估是否建协作机制
3. 产品迭代频率>每周1次大改——如果产品迭代节奏快到每周都有大改动，22周SOP里的D-30/D-21/D-14的review关口跟不上节奏，协作机制会成为产品速度的瓶颈；建议把协作机制简化到只做动作点1+4+5这3个最高频的
4. 设计师对SEO的初始认知接近零——如果设计团队从负责人到执行设计师都没人接触过SEO，22周里要先花6-10周做认知校准（看我过去2-3年的设计师SEO公开课、做基础概念校准），剩下12-16周才能开始动作点落地；建议先签外部SEO顾问做季度review补位，等设计师有了基础认知再建机制
5. 团队正在做品牌大改版或视觉重定位——如果团队正在做品牌的大改版（重新设计、重新定位、重新视觉语言），原有的SEO协作机制可能很快就要推倒重建；建议等改版尘埃落定后再启动协作机制建设，不要在变动期同时建机制

这5个反信号不是绝对的——某些情况下即使命中反信号也可以做协作机制，但需要付出更多协作成本。设计师团队评估自己处于哪种情况后决策。

设计师与SEO团队的边界怎么划清不互相踩脚？

22周里5个团队反复出现的协作摩擦不在动作点本身，而在边界——设计师与SEO团队之间该谁做什么、不该做什么没说清楚，每次都吵到拍桌子才推进。保哥给出一个边界划分模板，5个团队都用这个模板基本不再吵：

这张表里“主导”是负责人、“验收”是把关人、“提建议”是建议者、“不参与”是不该插手；设计师跟SEO团队之间每次有争议都翻这张表，按表里写的角色定权责。同时设计师团队跟出海独立站KISS极简设计8步法里讲的设计美学方法论是不冲突的——美学层面追求KISS与SEO层面追求语义、性能、可访问性并不矛盾，反而是同一套设计哲学的两个侧面。

这种边界划分的好处是双方都能聚焦自己擅长的事——设计师不必学SEO策略和外链建设、SEO顾问不必学Figma和设计token；同时通过共同的中间件（设计稿评审、设计QA清单）形成协作。22周里5个团队建立这套边界后，设计师与SEO顾问的协作满意度从平均5/10提升到8/10，前后两次内部调研有显著改善。

常见问题解答

网页设计师需不需要自己学会做SEO？

不需要——设计师学完整SEO的ROI很低，22周5个团队的实操结论是设计师只需要会做SEO风险识别（看出自己设计稿里哪些决定会影响搜索流量），不需要会做关键词研究、外链建设、技术诊断这些专业工种的事；具体的SEO执行交给SEO团队或顾问，设计师负责在每一稿评审里留出SEO review的关口，避免开发拿到设计稿后才发现要返工。

设计师和SEO顾问最容易吵架的3个点是什么？

我22周里反复看到的：第一是大banner替H1——设计师为视觉冲击常把首屏的主标题做成图，SEO侧担心H1语义丢失，吵到开发评估阶段才暴露；第二是字体选型——设计师追求品牌一致性想用品牌定制字体或多套衬线，SEO侧担心字体加载拖累LCP，吵到性能测试阶段才出现冲突；第三是弹窗设计——设计师为转化率做的Cookie/订阅弹窗经常遮挡LCP元素，SEO侧担心Google Lighthouse判低质。

我们团队没有专门的SEO，设计师能自己做基础SEO吗？

能做基础的不能做全部——设计师能做的：IA合理性review、字号字重与H层级映射、字体加载方案选型、图片alt文案审、CTA与表单可访问性review、暗色模式对比度合规；设计师不能做的：技术SEO诊断（爬虫预算、JS渲染、Schema结构化数据深度优化）、关键词研究、链接建设。一个折中是设计师自己抓基础，签1个外部SEO顾问做季度review兜底，比硬招专职SEO更经济。

Figma的frame命名跟SEO到底有什么关系？

关系比想象中大——Figma frame命名规范如果与最终HTML的语义标签对齐（如frame叫“Section/Hero”开发对应`<section>`、“Heading/H2-Title”对应`<h2>`），开发把设计稿翻译成HTML时就不会出现div套div的语义荒地；我22周里看到5个团队里有3个团队设计师与开发用了不同的命名体系，结果上线后页面H层级混乱、Schema结构化数据缺字段，全靠SEO事后修补，成本远高于在Figma阶段统一命名。

字体加载到底对LCP和CLS有多大影响？设计师该怎么选字体？

影响很大——一套未preload的中文web font woff2文件常在100KB以上，首次加载会让LCP延后200-800毫秒，CLS则因为font swap出现明显跳动（FOUT/FOIT）；设计师选字体时建议遵循3条：（1）品牌字体只用于Logo和首屏关键标题不用于全站正文；（2）正文优先用系统字体栈（system-ui, -apple-system, “PingFang SC”, ...）；（3）必用的web font一定preload+font-display: swap+字符子集化。Google web.dev有完整的Font Best Practices教学。

22周账本里5个团队哪个最难协作？

难度从高到低：Headless媒体（设计师与开发完全分离，设计稿与最终HTML之间隔一层组件库映射）> B2B SaaS（设计师常按品牌升级节奏改全站视觉，SEO评估常被忽略）> 外贸建材（设计师常用大量重图详情页，alt治理与图片懒加载经常拖后腿）> 跨境母婴（设计师懂电商SEO基础协作意识较强）> DTC美妆（设计团队规模小决策路径短）；难度高的不是设计师不愿配合，是协作机制没建立——每个团队都能跑通，但要花的协作成本不同。

权威参考资料