核心结论：SEO网站设计不是上线后的补丁
SEO网站设计的目标不是堆关键词，而是让网站在可抓取、可理解、可访问和可维护的前提下，服务真实用户的搜索任务。Google官方文档将SEO描述为帮助搜索引擎理解页面内容，并帮助用户找到内容与完成目标的过程，因此设计阶段就应处理信息架构、URL、导航、性能与索引基础。
一个可执行的判断标准是：页面上线前，设计、前端和SEO团队能否回答四个问题——页面为什么存在、由谁维护、如何被抓取、如何验证效果。如果这些问题在上线后才讨论，返工成本通常更高。
先定义信息架构与URL，再画页面
信息架构决定分类、层级、导航和页面关系。建议先列出用户任务与内容类型，再决定哪些页面需要独立URL、哪些应合并、哪些只作为筛选状态。URL应稳定、可读、层级清晰，避免把日期、会话ID或无关参数写入永久路径。
URL变更应使用301重定向，并同步更新内部链接、规范URL和sitemap。HTTP状态码的含义可参考MDN HTTP状态码文档。规范URL（canonical URL）用于提示搜索引擎多个重复版本中哪个是首选版本；Google官方文档说明canonical属于提示而非强制指令，因此不能只设置canonical而忽略重定向、内链和内容重复问题，参见Google Search Central：规范URL。
移动优先索引下的页面设计
Google官方文档指出，移动优先索引意味着Google主要使用页面的移动版本进行索引和排名，参见Google移动优先索引文档。因此移动端不能只做“缩小版桌面页”，而应保证主要内容、结构化数据、内部链接和元数据在移动版本中同样可访问。
设计时建议检查：视口设置是否正确、点击目标是否过密、隐藏内容是否影响核心信息、图片与字体是否按需加载、导航在窄屏下是否仍可抓取。响应式设计通常比独立移动站更易维护，但无论采用哪种方案，移动版与桌面版的核心内容应保持一致。
Core Web Vitals与网站性能预算
网站性能应作为设计约束，而不是上线后的优化项。Google将页面体验描述为多项信号的组合，并指出Core Web Vitals是其中的重要组成部分，参见Google页面体验文档。Core Web Vitals关注加载、交互和视觉稳定性，具体指标与测量方法可参考web.dev Core Web Vitals。
建议在设计和开发阶段设定性能预算：首屏关键内容优先、限制首屏大图、延迟非关键脚本、为图片和视频设置尺寸、避免布局抖动。性能预算不是一次性任务，应在上线前用PageSpeed Insights和Lighthouse验证，并在上线后通过Search Console和真实用户数据持续观察。
结构化数据：让页面可理解
结构化数据帮助搜索引擎理解页面实体与内容关系。Google官方文档说明，结构化数据可使页面有资格显示富媒体搜索结果，但它不应被理解为通用的排名提升手段，参见Google结构化数据简介。实施时应选择与页面内容真实匹配的类型，避免标记不可见或不存在的属性。
Schema.org提供词汇表，参见Schema.org。部署后应使用富媒体搜索结果测试验证，并在Search Console中检查增强功能报告。结构化数据不是“加得越多越好”，错误标记可能造成误导或失去资格。
内部链接与规范URL的协同
内部链接帮助搜索引擎发现页面，也帮助用户理解页面关系。Google官方文档说明，可抓取的链接有助于搜索引擎发现新页面，参见Google内部链接文档。设计导航、面包屑、相关推荐和分页时，应确保链接使用标准a标签，而不是依赖JavaScript点击事件。
内部链接、sitemap、canonical和重定向应指向同一套首选URL。如果多个URL同时返回200状态码，且内链分散到不同版本，规范URL的提示效果会被削弱。建议建立URL规则表：哪些参数可索引、哪些只用于筛选、哪些应重定向、哪些应返回404或410。
抓取与索引基础：robots.txt、sitemap与JavaScript
robots.txt主要用于管理抓取，不应被当作阻止索引的主要工具。Google官方文档说明robots.txt是抓取管理机制，参见Google robots.txt文档。如果页面不应出现在搜索结果中，通常应结合noindex、权限控制或移除内容。
XML sitemap是帮助搜索引擎发现URL的提示，不保证抓取或索引，参见Google sitemap文档。JavaScript渲染方面，Google可以处理JavaScript，但渲染存在排队和限制；关键内容、标题和链接最好在初始HTML中可访问，或确保渲染后稳定输出，参见Google JavaScript SEO基础。
验证与排错清单
- 用Search Console URL检查工具确认抓取、索引和规范化状态。
- 用PageSpeed Insights和Lighthouse检查Core Web Vitals与资源加载。
- 用富媒体搜索结果测试验证结构化数据，并检查Search Console增强功能报告。
- 抽查移动版与桌面版的核心内容、内链和元数据是否一致。
- 检查robots.txt、sitemap、canonical、重定向和404页面是否互相冲突。
- 检查导航与关键内容是否依赖必须点击后才加载的脚本。
常见误区
误区一：把canonical当成强制索引指令。误区二：认为sitemap提交后页面一定被索引。误区三：用robots.txt阻止页面出现在搜索结果。误区四：移动端隐藏大量桌面端内容。误区五：结构化数据标记与可见内容不一致。误区六：只关注首页性能，忽略模板页和分类页。上述做法通常会增加排错成本，而不是解决搜索需求。
假设示例：电商分类页设计检查
以下为假设场景，不代表真实项目数据。假设一个电商网站要改版分类页：设计稿包含筛选参数、瀑布流加载和相关推荐。上线前应确认筛选参数是否产生可索引URL、分页是否可抓取、相关推荐是否使用标准链接、移动端是否保留分类说明、图片是否设置尺寸、结构化数据是否与可见商品一致。该示例用于说明检查顺序，不证明任何排名结果。
FAQ
SEO网站设计需要设计师懂代码吗？不必。设计师需要理解URL、导航、移动优先索引和内容优先级，技术实现由前端与SEO共同确认。
Core Web Vitals是排名因素吗？Google将页面体验描述为信号组合，并指出Core Web Vitals是其中一部分；不应简化为“分数高就一定排名高”。
结构化数据能提升排名吗？结构化数据主要用于帮助搜索引擎理解内容并使页面有资格显示富媒体结果，不应被理解为通用排名提升手段。
改版后最重要的验证是什么？优先检查旧URL重定向、canonical、内链、sitemap和Search Console覆盖率，再观察性能与富媒体结果报告。