Communitygithub.com

網站上線檢查工具

在小型企業網站上線前，依據 15 點啟動檢查清單進行審核。當使用者要求稽核、檢查、審閱或啟動網站，或詢問網站是否準備好發布時使用。提供網站網址、網站檔案資料夾或線上展示連結，即可產出附有證據與修復建議的通過/失敗報告。

網站上線檢查工具 是什麼？

這個「網站上線檢查工具」技能專為小型企業網站設計，能在網站正式發布前進行全面檢查，避免尷尬的問題流向公開環境。它不重新設計網站，而是針對啟動準備度進行審核，報告遺漏項目並提供具體修復指引。技能支援即時網址、網站檔案資料夾或演示/暫存連結三種輸入方式，適用於 Claude Code、Cursor 等開發代理平台。檢查清單涵蓋 15 個關鍵項目，包括自訂 404 頁面、唯一頁面標題、Meta 描述、社交預覽圖片、圖片替代文字、內部連結、Sitemap 與 Google Search Console、robots.txt、HTTPS 部署、表單垃圾防護、感謝頁面、Google Analytics、隱私政策與 Cookie 聲明、FAQ 以及真實客戶見證。報告產出嚴格要求附上證據，並區分「通過」、「失敗」、「需客戶確認」、「暫不適用」與「遺漏」等狀態。此外，技能還包含設計方面的額外檢查，並設有嚴格規則禁止使用預設資料或捏造數據，確保報告的誠實與可靠性。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mmsample97/website-launch-checker/tree/HEAD
查看原文→瀏覽所有技能

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

說明文件

網站上線檢查工具 是做什麼的？

目的

在網站上線前進行檢查，以避免尷尬內容發布。 檢查工具不會重新設計網站。它會檢查網站的準備就緒程度， 報告缺少的項目，並明確指出需要修正的內容。

此工具專為小型企業網站設計：單一商家、少量頁面、 一個聯絡或潛在客戶表單，以及可能以英語為第二語言的訪客。

使用方式

  1. 向使用者索取以下其中一項資料：
    • 即時網址
    • 網站檔案資料夾
    • 展示或暫存連結
  2. 如果使用者只提供網址，需清楚說明哪些項目無法從外部檢查。 不要猜測這些項目。將它們標記為「需客戶確認」而非通過。
  3. 依序檢查下方清單中的所有項目。
  4. 為每個項目記錄證據：您看到該項目的頁面、檔案、行數、標籤或 螢幕截圖。沒有證據就表示不通過。
  5. 最後以此檔案結尾的報告格式產出結果。

15 點啟動檢查清單

檢查全部 15 點。不要因為看起來不重要而跳過任何一點。

1. 自訂 404 頁面

  • 輸入錯誤網址的訪客會看到有品牌標示的 404 頁面， 而非伺服器預設頁面或空白頁面。
  • 404 頁面需包含返回首頁和連絡我們的連結。
  • 如果沒有 404 頁面，或使用的是預設頁面，則判定為失敗。

2. 唯一的頁面標題

  • 每個頁面都有自己獨立的 <title>。
  • 沒有任何兩個頁面共用相同的標題。
  • 沒有空白標題，且標題不能在所有頁面上都僅是商家名稱。
  • 標題應以淺顯易懂的文字描述該頁面。

3. Meta 描述

  • 每個主要頁面都有一個 meta 描述。
  • 每個 meta 描述對該頁面都是獨一無二的。
  • 每個 meta 描述都應是該頁面內容的簡短、淺顯摘要， 而非關鍵字堆砌。
  • 如果主要頁面沒有 meta 描述，則判定為失敗。

4. 社交預覽圖片

  • 當網站連結在 WhatsApp、Facebook 或其他應用程式中分享時， 會顯示正確的預覽圖片、標題和描述。
  • 檢查 Open Graph 標籤（og:title、og:description、 og:image），並確認圖片檔案確實存在。
  • 如果預覽圖片遺失、失效或為佔位符，則判定為失敗。

5. 圖片替代文字

  • 每張有意義的圖片都應有以淺顯文字描述圖片的替代文字。
  • 裝飾性圖片可以使用空的替代文字，但需明確說明。
  • 如果主要圖片、產品照片或團隊照片沒有替代文字，則判定為失敗。

6. 內部連結

  • 頁面之間應以合理的方式互相連結：首頁、服務、關於我們、 連絡我們以及任何關鍵服務頁面。
  • 點擊或檢查每個內部連結。沒有任何連結指向遺失的頁面、 404 頁面或像 # 這樣的佔位符。
  • 任何損壞的內部連結都判定為失敗。

7. Sitemap 與 Google Search Console

  • 應存在 sitemap.xml 檔案，並列出真實的頁面。
  • 網站已提交至 Google Search Console， 或已告知網站擁有者仍需執行此步驟。
  • 僅從網址無法證明已提交 Search Console。 在這種情況下，將其標記為「需客戶確認」並列為擁有者步驟。 不要僅憑猜測就標記為通過。

8. robots.txt

  • 網站根目錄下存在 robots.txt 檔案。
  • 它允許應被搜尋引擎找到的頁面，且不會意外地封鎖整個網站。
  • 如果檔案遺失或封鎖了所有內容，則判定為失敗。

9. 全面 HTTPS

  • 每個頁面都應透過 HTTPS（而非 HTTP）載入。
  • 沒有混合內容警告：圖片、腳本和表單也必須透過 HTTPS 載入。
  • 任何 HTTP 頁面或混合內容都判定為失敗。

10. 表單垃圾郵件防護

  • 每個表單都有垃圾郵件防護機制，例如驗證碼、 隱藏欄位或具有垃圾郵件過濾功能的表單服務。
  • 如果聯絡或潛在客戶表單完全沒有防護，則判定為失敗。
  • 如果網站完全沒有表單，請將其標記為「暫不適用」 並將其添加到修正清單中，內容為： 「新增真實表單時需要。」不要因為不存在的表單而標記為失敗。
  • 除非使用者允許，否則不要提交真實表單來測試此項。 請改為檢查程式碼或表單設定。

11. 提交後的感謝頁面

  • 訪客提交表單後，會看到一個感謝頁面或明確的感謝訊息。
  • 感謝頁面應確認後續步驟， 例如「我們將在一個工作日內透過 WhatsApp 回覆。」
  • 如果表單只是重新載入、清空或沒有顯示確認訊息，則判定為失敗。
  • 如果網站完全沒有表單，請將其標記為「暫不適用」 並將其添加到修正清單中，內容為： 「新增真實表單時需要。」不要因為不存在的表單而標記為失敗。

12. Google Analytics

  • Google Analytics 或網站擁有者選擇的同等分析工具， 應安裝在每個頁面上。
  • 僅從網址無法證明網站擁有者能夠看到數據。如果您無法驗證存取權限， 請將其標記為「需客戶確認」並列為擁有者步驟。
  • 分析工具需要客戶的 Google 帳戶。請明確說明這一點。 如果沒有該帳戶，不要聲稱已經完成設定。

13. 隱私政策，附帶 Cookie 聲明

  • 網站應有隱私政策頁面。
  • 政策應是真實的：需說明網站實際收集哪些資料， 例如表單詳細資訊，以及這些資料的使用方式。
  • 如果使用 Cookie 或分析工具，則需包含 Cookie 聲明。
  • 如果政策是通用的樣板文字，與此網站不符， 或是複製的文字中包含其他商家名稱，則判定為失敗。

14. FAQ

  • 網站應有 FAQ 區塊或頁面。
  • 問題應是真實客戶實際會問的：價格範圍、地點、時間、 如何預約、需要攜帶什麼。
  • 如果沒有 FAQ，或答案只是含糊的填充內容而無實際資訊， 則判定為失敗。

15. 僅限真實客戶見證

  • 網站上的每則客戶見證都必須是真實的。
  • 沒有佔位符名稱、沒有捏造的評論、沒有「張三」、 沒有以客戶身份呈現的庫存引述。
  • 如果無法驗證某則見證，請將其標記為失敗並說明： 移除它，或在取得許可後以真實見證取代。
  • 如果網站完全沒有客戶見證，請將其標記為「遺漏」 並說明：未找到任何見證，但也未發現虛假姓名。 不要將其稱為「虛假」。缺少見證區塊是需要填補的缺口， 而非虛假見證。
  • 帶有虛假客戶見證的網站是嚴重失敗。 即使其他項目全部通過，該網站也尚未準備好上線。

額外的設計檢查

這些不屬於上述 15 點，但應作為「設計備註」單獨報告。 請勿將其混入 15 點的評分中。

  • 無 AI 劣質內容：沒有紫色漸層、沒有置中標題加上三個 完全相同的卡片作為整個設計、沒有在每個區塊重複的通用版面配置。
  • 優質、精緻、宜居的版面配置：清晰的層級結構、 可讀性高的字體、可能的話使用真實照片或真實專案細節。
  • 全站數字格式一致：採用同一種格式與尺寸系統。 不要在同類價格中混用「AED 500」、「500 AED」和「500」。
  • 如果使用了專案細節，應以統計數據呈現，而非模糊的宣稱。
  • 關鍵資訊應易於英語能力較弱的讀者理解： 使用簡短的句子、清晰的標題，以及易於找到的聯絡方式。

嚴格規則

  • 沒有證據，絕不標記為通過。
  • 絕不捏造客戶見證、統計數據、客戶數量或評論。
  • 在沒有客戶提供 Google 帳戶步驟的情況下，絕不聲稱 Search Console 或 Analytics 已完成。
  • 如果表單沒有垃圾郵件防護、沒有感謝確認，或存在虛假客戶見證， 絕不宣布網站已準備就緒。這些都是阻礙因素。 完全沒有表單的網站則不同：對於檢查項目 10 和 11， 請使用「暫不適用」，而非失敗。
  • 絕不使用佔位符來填補缺口。請報告缺口。
  • 報告應使用簡短、淺顯的句子。網站擁有者可能不具備技術背景。

報告格式

始終以此格式結尾，並保持此順序：

啟動報告：[網站名稱或網址]

判定結果：已就緒 / 未就緒 / 未就緒 - 發現阻礙因素

僅在沒有任何失敗項目，或者僅有的未解決項目是客戶已確認將在 上線當天完成的擁有者步驟時，才使用「已就緒」。「暫不適用」和 「遺漏」本身不會阻擋「已就緒」的判定，但需將其列為缺口。 否則請使用「未就緒」。

結果

#檢查項目結果證據
1自訂 404通過 / 失敗 / 需客戶確認 / 暫不適用 / 遺漏頁面或檔案
2唯一的頁面標題......
3Meta 描述......
4社交預覽圖片......
5圖片替代文字......
6內部連結......
7Sitemap 與 Search Console......
8robots.txt......
9全面 HTTPS......
10表單垃圾郵件防護......
11提交後的感謝頁面......
12Google Analytics......
13附帶 Cookie 聲明的隱私政策......
14FAQ......
15僅限真實客戶見證......

修正項目，依優先順序排列

  1. 首先處理阻礙因素：[需要修正什麼、在哪個頁面，以淺顯文字說明]
  2. 下一個修正：...
  3. ...

擁有者步驟 - 需要客戶處理

  • [例如：提供 Google 帳戶存取權限給 Search Console]
  • [例如：確認客戶見證為真實，並給予展示許可]
  • [例如：撰寫真實的隱私政策文字]

設計備註

  • [來自「額外的設計檢查」區塊的任何備註，或「無」。]

未檢查的項目及其原因

  • [例如：無法僅從網址驗證 Search Console 提交狀態。]

相關技能

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community