SEO Landing 页面生成器

构建一个针对 100/100 PageSpeed 和最大化 SEO 优化的静态单页 HTML 落地页：关键 CSS、AVIF 图片、完整的 JSON-LD 结构化数据、仅原生交互、首次加载时零第三方请求。

何时使用

用户要求构建一个专注于速度和 SEO 的落地页/单页 → 生成模式。
用户提供了简要需求（ТЗ）并希望得到一个可用于生产的静态页面 → 生成模式。
用户要求根据清单审核现有落地页但无需修改 → 仅审核模式（§0b，只读，不涉及项目文件）。
用户要求修复/改进现有落地页 → 修复现有模式（§0c）。

流程

0. 首先将请求路由到相应模式

该技能提供三种模式——根据请求选择一个（如果不明确则询问），因为每种模式收集不同的输入并产生不同的输出：

生成——根据简要需求构建新的落地页（“构建/创建/生成一个落地页...”）。执行下面的完整流程。
仅审核——对现有页面进行只读检查（“审核/检查/对照清单检查此落地页...”，不要求修改）。执行 §0b。从不写入项目文件。
修复现有——对现有页面进行针对性修复（“修复/改进/优化此页面...”）。执行 §0c。

代表性路由：

“根据此简要需求为牙科诊所构建落地页” → 生成。
“审核 https://example.com/ 对照性能清单并报告问题” → 仅审核。
“此落地页的英雄图片在加载时偏移——修复它” → 修复现有。

仅生成模式的简要需求字段（目标关键词、业务类型、行动号召、媒体事实）仅用于生成和重建工作。审核或针对性修复不得因缺少生成输入而受阻或延迟，并且仅审核模式不得创建或修改任何项目文件。

0a. 收集简要需求（生成模式；如果缺失则询问）

在生成任何内容之前所需：

域名/最终 URL——用于规范链接、og:url、绝对路径、JSON-LD @id。
站点标识（用于 WebSite 标记，仅当页面是域名/子域名首页时）：首选站点名称、可选别名以及规范首页 URL——与落地页 URL 分开收集。
面包屑导航（用于 BreadcrumbList 标记，仅当存在真实站点层级时）：可见的面包屑导航和规范父级 URL。
页面语言、基本方向、Open Graph 区域设置——三个独立的输入，绝不要将一个值复制到不同格式：BCP-47 语言标签用于 <html lang>（例如 en-US、ar-SA），基本方向（ltr/rtl——RTL 文档在 <html> 上使用 dir="rtl"，仅 lang 不设置方向性），以及用于 og:locale 的 language_TERRITORY 格式（例如 en_GB）。当方向对于支持 RTL 的语言未知时询问（技术规范 §2）。
主题 + 1-3 个目标关键词——用于 H1、标题、描述。
业务类型：组织或本地企业。对于本地企业，收集经过验证的公开/法律业务名称和完整的结构化邮政地址（街道、地区、省、邮政编码、国家），以及电话和地理坐标。同时根据实际业务收集经过验证的 schema.org 子类型（例如 Restaurant、Dentist、HardwareStore）——绝不要从目标关键词中选择。绝不要虚构缺失的身份信息：如果没有提供事实，则回退到 Organization 标记或省略实体标记。
行动号召和联系方式（电话、表单、即时通讯工具）。当要求表单时，同时收集其提交目标和方式（第一方端点或记录在案的表单服务——绝不要虚构）、所收集个人数据所需的同意/隐私文本，以及提交内容的存储位置和所有者；若没有目标，则省略表单或明确标记为存根（技术规范 §10 表单提交合同）。
品牌认可的 favicon 或明确允许创建一个——绝不要默默虚构品牌标识。
对于客观营销事实（数字、价格、资质、保证、比较、案例研究）的已批准来源材料和权利声明所有者——如果没有这些，则省略此类主张，绝不要虚构。
是否提供图片；是否需要常见问题/评论/视频块。对于视频块，收集来源支持的事实：视频 URL/ID、标题、描述、准确的首次发布日期/时间（带时区）和独特的可抓取缩略图（并在适用时提供 contentUrl）。绝不要虚构缺失的媒体事实。同时收集视频模式及其权衡声明：仅点击模式（默认——隐私/性能；页面将无法满足 Google 视频发现要求，并且不会声称视频搜索收益）或 SEO 可发现（自托管 <video> 或记录在案的直接嵌入——当视频搜索流量重要时需要）（技术规范 §9）。

如果域名或关键词缺失——先询问，绝不要虚构它们。

0b. 仅审核模式（只读）

审核现有页面而不生成替换页面。此模式下不创建或修改任何项目文件——交付物是一份报告。

确定目标：已部署的 URL（首选——让所有检查都针对实际情况运行）或本地 HTML 文件。如果两者都未提供，询问；绝不要猜测目标。
针对目标照原样执行 §5 中的适用检查：W3C 有效性、本地资产存在性（对于本地文件）、通过 schema.org 验证器校验 JSON-LD、针对已部署/服务的 URL 进行 Lighthouse 测试、可抓取性合同（已部署主机上的 robots.txt + sitemap.xml），以及技术规范 §8 中的手动可访问性检查。
每项检查报告证据：通过/失败，附带测量到的值或观察到的标记，以及使用的确切命令/工具。如果某项检查无法运行（没有已部署的 URL 无法进行 Lighthouse 测试，主机上没有 robots.txt），则报告该检查的阻塞项——不要估算、推断或默默省略它。
区分语法有效性与 Google 功能资格（FAQPage、VideoObject、丰富搜索结果）：有效标记报告为有效标记，绝不要报告为已实现的搜索功能。
可选地以优先修复列表结束。应用修复是单独的修复现有请求——没有该请求就不要开始编辑。

0c. 修复现有模式

对现有页面应用针对性修复而不进行完全重建。

确定页面/文件以及要修复的具体问题；仅收集这些修复所需的输入（永远不要完整的生成简要需求）。
根据相关技术规范章节应用每个修复，保留无关标记和内容。
停止点（§4）适用：在验证之前向用户展示更改后的页面。如果修复更改了用户先前批准的内容，则在报告之前获得重新批准。
验证更改后的页面（§5）并仅报告测量到的证据。

生成工作流（生成模式）

1. 创建项目文件夹

每个项目都位于工作区内的自己的文件夹中——永远不要写入工作区根目录。输出是一个多文件项目：HTML 引用的每个本地资源都必须作为实际文件存在。

<workspace>/<project-slug>/
  index.html        # 生成的落地页
  styles.css        # 仅当首屏以下 CSS 被延迟时（§1）；如果所有 CSS 都内联则不存在
  script.js         # 仅当页面使用 JS 时（§10）；单个文件，延迟加载
  images/           # src/srcset/preload/OG 标签中引用的每个图片变体（AVIF/WebP/JPEG，所有断点）
  favicon.png       # 稳定的方形品牌图标，≥48×48
  ASSETS.md         # 每个资产的权利和来源记录
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # 托管说明

图片分支：

简要需求中提供了图片 → 从中生成所有所需变体（srcset 中命名的每个断点的 AVIF/WebP/JPEG）。
没有可用图片 → 向用户请求它们或省略图片/块。永远不要发出成功外观的资产 URL 而不生成文件或明确请求它——引用但缺失的文件是生成失败，而不是占位符。

2. 生成页面

严格按照 references/tech-spec.md 构建 index.html——13 个需求部分（性能、HTML 结构、SEO、安全性、CSS/字体、禁止列表、测试、可访问性、嵌入式视频、典型块、延迟小部件、内容真实性和出处、输入消毒和输出编码）。

将每个简要需求值视为不受信任：为其确切输出上下文（HTML 文本、属性、URL、JSON-LD）进行编码，白名单 URL 方案（拒绝 javascript:/意外的 data:），转义序列化 JSON-LD 中的 <，并在它们到达任何 URL 之前验证结构化 ID（例如 YouTube ^[A-Za-z0-9_-]{11}$）（技术规范 §13）。

对于嵌入式 YouTube 视频，默认使用外观模式；SEO 可发现模式（自托管 <video> 或记录在案的直接嵌入）是明确的简要需求选择并附带披露的权衡，绝不是静默切换——规则和在技术规范 §9 中的 Google 发现要求，外观参考实现见 references/video-facade.md。地图仅遵循外观规则（技术规范 §10）：初始 DOM 中的本地截图，仅在明确激活后才插入 iframe——绝不要使用原生的 loading="lazy" 地图 iframe。参考：references/map-facade.md。

3. 生成配套文件

robots.txt 位于站点根目录，带有完全限定的 Sitemap: 行，绝不阻止规范页面或所需媒体。
sitemap.xml 包含 XML 转义的绝对规范 <loc> URL，匹配 HTML 规范；lastmod 仅来自可验证的重大内容更改时间戳（当未知时省略——绝不要盲目使用生成时间）。
来自 references/server-config.md 的托管说明：缓存、Brotli/gzip、安全标头。

4. 停止点——用户批准

向用户展示生成的页面，并明确询问 HTML 版本是否 OK。在用户确认之前不要进行验证和最终报告。 如果有意见——修复并再次询问。

5. 验证

执行技术规范 §7 中的可执行验证合同——针对服务页面的固定命令，仅测量结果，当门无法运行时明确标记为 BLOCKER：

W3C HTML 有效性（Nu 验证器，JSON 输出；零错误）。
本地资产/链接存在性：提取输出引用的每个本地 URL（img src/srcset、<source> srcset、预加载 href/imagesrcset、favicon、OG/Twitter 图片、CSS url()、脚本 src）并验证每个文件在项目文件夹中存在。任何缺失的引用的本地资源都是硬性失败——生成文件或移除引用；绝不要发布指向从未创建文件的 HTML。
JSON-LD 语法（JSON 解析）——与 Google 丰富结果资格分开，后者在部署的页面上使用丰富结果测试进行检查。
在 320/768/1280/1920px 下的响应式截图，检查溢出和重排。
Lighthouse：固定版本/配置文件，3 次运行，每个类别的中位数，阈值 ≥ 90，构件保留在项目的 reports/ 中——仅实验室证据，绝不要现场 Core Web Vitals，也绝不要 WCAG 认证。
手动可访问性检查（技术规范 §8）——没有自动化工具能单独确定 WCAG 符合性：键盘导航、焦点顺序/可见性、对话框焦点流、缩放/重排、减少动效、语义名称-角色-值、替代文本质量以及所有交互式视觉状态。针对每个适用的 WCAG 2.1 AA 准则记录通过/失败证据；报告未解决的项目而不是默默认证它们。
可抓取性合同：解析 sitemap.xml，将每个 <loc> 与 HTML 规范链接比较，检查 robots.txt 中的 Sitemap: URL，并成功请求两个部署的文件（HTTP 200）。

在报告之前修复发现的任何违规。诚实地披露证据：每个报告的数字都附有产生它的确切命令和构件路径；无法运行的门报告为 BLOCKER: <reason> 而不是数字。绝不要输出未被实际测量的 PageSpeed/LCP 分数。

6. 最终报告

简要列出：

LCP 参数
PageSpeed 分数
代码中使用的 schema.org 类型

主要陷阱

绝不要使用外部 JS/CSS 库、外部字体或 SVG 图片（技术规范 §6）。
绝不要引用从未创建的本地资产：每个 src/srcset/preload/OG URL 必须解析为项目文件夹中的实际文件；缺失的源图片向用户请求，而不是虚构（OUTPUT 合同）。
绝不要将原始简要需求值直接输出到标记中：对所有内容进行上下文编码，拒绝 javascript:/意外的 data: URL，并使用恶意值（引号、</script>、事件处理程序负载）进行自测生成（技术规范 §13）。
绝不要在首次加载时加载 YouTube iframe、地图、聊天、订阅弹窗或 Cookie 横幅（技术规范 §9、§10、§11）——唯一记录的例外是简要需求选择的 SEO 可发现视频模式，带有记录为首次加载依赖项的直接嵌入（技术规范 §9 模式 S）。
所有内容必须存在于原始 HTML 中——没有仅由 JS 渲染的内容。
JSON-LD、规范链接和 OG 标签中的绝对 URL。
总 JS 预算 ≤ 15 KB，一个文件，在 </body> 之前使用 defer。

SEO Landing — PageSpeed 100 + 结构化数据收官