面向开发者的网站 SEO 技术清单：按发现、抓取、索引分层检查
技术 SEO 清单不应按标签名平铺，而应按可发现、可抓取、可理解、可索引、可展示五层检查，每层都能用请求或日志验证。本文给出分层检查项、一个占位示例与执行顺序，并说明在缺少可核验搜索引擎文档与站点日志时，具体阈值、支持范围与抓取规则均待核实。
面向开发者的 SEO 技术优化清单，重点通常不在“多加几个 meta 标签”，而在保证一条链路成立：爬虫能发现 URL、能抓到内容、能理解页面、能决定是否索引，最后能在结果页正确展示。本文按这五层组织检查项，并明确哪些结论需要站点自身数据或搜索引擎官方文档才能确认。本次没有可核验的正文素材，因此不给出排名效果、阈值数字或“最新规则”判断。
为什么先分层，再列检查项#
按标签名罗列的清单容易漏掉因果关系。例如页面没被索引，可能是 robots.txt 挡住了抓取，也可能是返回了 noindex，还可能是内容只靠客户端渲染而未被取到。分层之后，每一层都可以用一次请求或一段日志来验证，问题就能落到具体环节，而不是笼统地归为“SEO 没做好”。
第一层：可发现#
- 站点地图：只放希望被索引的规范 URL，避免把参数页、搜索结果页、重复列表页大量写入。
- 站内链接：导航与正文链接使用可被抓取的
<a href>；仅靠 JavaScript 点击事件跳转的入口，抓取表现需按目标搜索引擎实测确认。 - robots.txt 的职责边界：它用于控制抓取，不适合承担“禁止索引”的职责。常见做法是用
noindex控制索引、用 robots.txt 控制抓取，但具体行为应以搜索引擎文档为准，本文未核验。
第二层：可抓取#
检查服务端返回的原始响应，而不是只看浏览器渲染后的页面。重点看三件事：状态码是否表达真实语义、重定向是否形成链条、主要内容是否出现在初始 HTML 中。
# 占位示例，域名 example.com 为演示用途；本文未实际执行
curl -sI https://example.com/page
curl -s https://example.com/page | head -n 40上面两条命令仅用于说明检查方式，预期输出不作为实际结果。实际排查时建议记录请求时间、User-Agent、状态码与响应体长度，形成可复现的记录。
第三层：可理解与可索引#
- 标题与结构：每页一个主要
h1，标题层级反映内容结构，而不是用来堆关键词。 - canonical：重复内容页面指向同一个规范 URL；canonical 与
noindex、robots.txt 之间不要互相矛盾。 - 结构化数据：用 JSON-LD 描述页面实体，字段与页面可见内容一致。支持的类型与富结果展示条件随搜索引擎而异，需待核实。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "示例标题",
"url": "https://example.com/page"
}
</script>这是占位示例，example.com 与字段值均为演示，未部署也未用任何校验工具验证。
第四层：可展示#
预览卡片依赖 Open Graph 等元数据，性能指标依赖真实用户测量。两者的具体字段要求与评分阈值会变化，本文不引用未核验数值。可做的稳定检查是：分享链接时标题、描述、图片是否与页面一致；图片是否有明确尺寸与替代文本。
建议的执行顺序#
- 抽取 10 至 20 个代表 URL，覆盖首页、栏目页、详情页、分页与参数页。
- 对每个 URL 记录状态码、重定向链、canonical、robots 元标签与初始 HTML 是否含正文。
- 核对 robots.txt 与 sitemap 是否互相矛盾。
- 从服务器日志抽查抓取频率与返回码分布，与上面的抽样结果对照。
- 上线结构化数据与预览元数据后，用对应平台的校验工具复核，而不是仅凭页面源码判断。
边界说明#
本文未联网核验，未附搜索引擎官方文档链接；涉及抓取配额、渲染能力、结构化数据支持范围与性能阈值的结论，均需以官方文档和站点自身日志为准，当前标为待核实。技术清单能提高可验证性，但不能承诺搜索排名或 AI 引用结果。
