SEO Landing — PageSpeed 100 + 結構化資料收官

SEO Landing Generator

建立一個針對 100/100 PageSpeed 和最大化 SEO 進行優化的靜態單頁 HTML 登陸頁：關鍵 CSS、AVIF 圖片、完整的 JSON-LD 結構化資料、僅原生互動、首次載入時零第三方請求。

使用時機

• 使用者要求針對速度和 SEO 的登陸頁/單頁式網站 → generate 模式
• 使用者提供簡報 (ТЗ) 並想要一個可直接上線的靜態頁面 → generate 模式
• 使用者要求根據檢查清單審核現有登陸頁，但不進行任何修改 → audit-only 模式 (§0b，唯讀，不建立專案檔案)
• 使用者要求修正/改善現有登陸頁 → fix-existing 模式 (§0c)

程序

0. 首先將請求導向一個模式

此技能提供三種模式——根據請求選擇一個（若不明確則提問），因為每種模式收集不同的輸入並產生不同的輸出：

• generate — 根據簡報建立新的登陸頁（「建立/製作/產生一個登陸頁…」）。執行以下完整程序。
• audit-only — 對現有頁面進行唯讀檢查（「審計/檢查/審查這個登陸頁是否符合檢查清單…」，不要求修改）。執行 §0b。絕不寫入專案檔案。
• fix-existing — 對現有頁面進行有針對性的修正（「修正/改善/優化這個頁面…」）。執行 §0c。

代表性路由：

• 「根據這份簡報為一家牙科診所建立一個登陸頁」 → generate。
• 「根據效能檢查清單審計 https://example.com/ 並報告問題」 → audit-only。
• 「這個登陸頁的主圖在載入時會偏移——修正它」 → fix-existing。

僅限於 generate 模式的簡報欄位（目標關鍵字、業務類型、CTA、媒體事實）僅在 generate 和 rebuild 工作中收集。審計或有針對性的修正不應因缺少生成輸入而被阻塞或延遲，且 audit-only 模式不得建立或修改任何專案檔案。

0a. 收集簡報 (generate 模式；若缺少則提問)

在生成任何內容之前必須收集：

• 域名/最終 URL — 用於 canonical、og:url、絕對路徑、JSON-LD @id。
• 網站身份（用於 WebSite 標記，僅在頁面是域名/子域名首頁時）：偏好的網站名稱、可選的別名以及規範的首頁 URL——與登陸頁 URL 分開收集。
• 麵包屑路徑（用於 BreadcrumbList 標記，僅在存在真實網站層級結構時）：可見的麵包屑路徑和規範的父級 URL。
• 頁面語言、基礎方向以及 Open Graph 地區設定——三個獨立的輸入，不能將一個值複製到不同格式：<html lang> 的 BCP-47 語言標籤（例如 en-US、ar-SA）、基礎方向（ltr/rtl——RTL 文件在 <html> 上設定 dir="rtl"，而 lang 本身不設定方向性），以及以 language_TERRITORY 格式用於 og:locale 的 Open Graph 地區設定（例如 en_GB）。對於具有 RTL 能力的語言，若方向未知則提問（技術規範 §2）。
• 主題 + 1–3 個目標關鍵字 — 用於 H1、標題、描述。
• 業務類型：Organization 或 LocalBusiness。對於 LocalBusiness，收集經過驗證的公開/法定企業名稱和完整的結構化郵寄地址（街道、地區、區域、郵遞區號、國家/地區），以及電話和地理座標。同時根據實際業務收集經過驗證的 schema.org 子類型（例如 Restaurant、Dentist、HardwareStore）——絕不從目標關鍵字中選擇。切勿憑空編造缺失的身份事實：在無法提供事實之前，退回使用 Organization 標記或省略實體標記。
• CTA 和聯絡方式（電話、表單、即時通訊軟體）。當要求使用表單時，同時收集其提交目標和方法（第一方端點或有文件記載的表單服務——絕不憑空發明）、收集個人資料所需的同意/隱私文字，以及提交內容的儲存位置和擁有者；若無目標，則省略表單或明確地將其設為存根（技術規範 §10 表單提交約定）。
• 品牌認可的 favicon 或明確的建立許可——切勿在未告知的情況下憑空發明品牌標記。
• 對於客觀行銷事實（數字、價格、資格、保證、比較、案例研究）的核准來源資料和主張所有者——若無此類資料，則省略此類主張，絕不憑空發明。
• 是否提供圖片；是否需要 FAQ / 評論 / 影片區塊。對於影片區塊，收集有來源依據的事實：影片 URL/ID、標題、描述、準確的首次發布日期/時間（含時區），以及一個獨特的可爬取縮圖（若適用則加上 contentUrl）。切勿憑空編造缺失的媒體事實。同時收集影片模式並說明其權衡：僅點擊的預製介面（預設——隱私/效能；頁面將無法滿足 Google 影片發現要求，且不聲稱任何影片搜尋效益）或 SEO 可發現（自託管 <video> 或有文件記載的直接嵌入——當影片搜尋流量很重要時需要）（技術規範 §9）。

如果缺少域名或關鍵字——首先提問，不要憑空發明。

0b. 僅審計模式 (唯讀)

審計現有頁面而不產生替代頁面。在此模式下不建立或修改任何專案檔案——交付物是一份報告。

1. 識別目標：一個已部署的 URL（優先——讓每個檢查都能針對實際情況執行）或本機 HTML 檔案。若兩者均未提供，則提問；切勿猜測目標。
2. 針對目標原樣執行 §5 中的適用檢查：W3C 有效性、本機資產存在性（針對本機檔案）、透過 schema.org 驗證器驗證 JSON-LD、針對已部署/提供的 URL 執行 Lighthouse、可爬取性約定（已部署主機上的 robots.txt + sitemap.xml），以及技術規範 §8 中的手動可及性檢查。
3. 針對每項檢查報告證據：通過/失敗並附上測量值或觀察到的標記，以及使用的確切命令/工具。如果某項檢查無法執行（沒有已部署的 URL 無法執行 Lighthouse，主機上沒有 robots.txt），則報告該檢查的阻塞項——不要進行估算、推斷或默默地省略它。
4. 區分語法有效性和 Google 功能資格（FAQPage、VideoObject、豐富結果）：有效的標記應報告為有效的標記，切勿將其報告為已達到的搜尋功能。
5. 可選擇以優先修復清單結束。套用修復是單獨的 fix-existing 請求——在沒有它的情況下不要開始編輯。

0c. 修復現有模式

對現有頁面進行有針對性的修復，而無需全面重建。

1. 識別頁面/檔案以及要修復的具體問題；僅收集這些修復所需的輸入（絕不收集完整的生成簡報）。
2. 根據相關的技術規範章節套用每項修復，保留不相關的標記和內容。
3. 停止點 (§4) 適用：在驗證之前顯示更改後的頁面。如果修復改變了使用者先前核准的內容，則在報告之前獲得重新核准。
4. 驗證更改後的頁面 (§5) 並僅報告測量到的證據。

生成工作流程 (generate 模式)

1. 建立專案資料夾

每個專案都存在於工作區內自己的資料夾中 — 絕不寫入工作區根目錄。輸出是一個多檔案專案：HTML 引用的每個本機資源都必須作為實際檔案存在。

<workspace>/<project-slug>/
  index.html        # 產生的登陸頁
  styles.css        # 僅在折疊線以下的 CSS 被延遲時使用 (§1)；當所有 CSS 都已內嵌時不存在
  script.js         # 僅在頁面使用 JS 時存在 (§10)；單一檔案，defer
  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 中跳脫 <，並驗證結構化 ID（例如 YouTube ^[A-Za-z0-9_-]{11}$），然後再將其用於任何 URL（技術規範 §13）。

對於嵌入式 YouTube 影片，預設使用預製介面模式；SEO 可發現模式（自託管 <video> 或有文件記載的直接嵌入）是明確的簡報選擇，並附有揭露的權衡，絕非無聲的切換——規則和 Google 發現要求請參閱技術規範 §9，預製介面參考實作請參閱 references/video-facade.md。地圖僅遵循預製介面規則（技術規範 §10）：初始 DOM 中的本機螢幕截圖，僅在明確啟用時才插入 iframe——絕非原生的 loading="lazy" 地圖 iframe。參考資料：references/map-facade.md。

3. 產生配套檔案

• robots.txt 位於網站根目錄，包含完全限定的 Sitemap: 行，絕不封鎖規範頁面或所需的媒體。
• sitemap.xml 包含 XML 跳脫的絕對規範 <loc> URL，與 HTML canonical 相符；lastmod 僅來自可驗證的重大內容更改時間戳記（未知時省略——絕不使用生成時間）。
• 主機設定說明，來自 references/server-config.md：快取、Brotli/gzip、安全標頭。

4. 停止點 — 使用者核准

向使用者顯示產生的頁面，並明確詢問 HTML 版本是否可以。在使用者確認之前，請勿繼續進行驗證和最終報告。 如果有意見——修正並再次詢問。

5. 驗證

執行來自技術規範 §7 的可執行驗證契約——針對已服務頁面的固定命令，僅測量結果，當閘道無法執行時明確標示 BLOCKER：

• W3C HTML 有效性 (Nu 驗證器，JSON 輸出；零錯誤)。
• 本機資產/連結存在性：提取輸出中引用的每個本機 URL（img src/srcset、<source> srcset、preload href/imagesrcset、favicon、OG/Twitter 圖片、CSS url()、script 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 canonical 進行比較，檢查 robots.txt 中的 Sitemap: URL，並成功請求這兩個已部署的檔案 (HTTP 200)。

在報告之前修復發現的任何違規。誠實地揭露證據：每個報告的數字都附帶產生它的確切命令和工件路徑；無法執行的閘道應報告為 BLOCKER: <原因>，而不是一個數字。切勿輸出未實際測量的 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、canonical 和 OG 標籤中的絕對 URL。
• 總 JS 預算 ≤ 15 KB，單一檔案，defer 放在 </body> 之前。