Schema結構化數據與robots.txt抓取規則驗收

頁面裏的 Schema 標記通過校驗，robots.txt 也沒有報錯，能不能上線？

還不能。

這裏所説的 Schema，是按照 Schema.org 詞表編寫的結構化數據標記，用來説明頁面中的人物、組織、產品等主體，以及它們的屬性和關係。robots.txt 則是放在網站根目錄下的公開文本文件，用來規定搜尋抓取器可以訪問哪些路徑。搜尋抓取器，就是搜尋系統自動訪問網頁的程序。

兩者解決的問題不同：Schema 幫助搜尋系統理解頁面內容，robots.txt 管理抓取範圍。即使它們分別通過了語法檢查，也不能證明頁面內容與代碼一致，更不能保證頁面會獲得富結果展示，或被生成式答案引用。

富結果，是搜尋結果中比普通連結更豐富的展示形式；生成式答案，是搜尋或人工智能系統根據已有資訊自動組織的回答。

上線驗收的重點，不是收集幾個“檢測通過”的結果，而是確認每項結論都有對應證據。

為什麼一個“一鍵工具”不能完成驗收？

Schema 需要回答三個問題：頁面主要描述什麼，主體有哪些屬性，不同主體之間是什麼關係。

robots.txt 需要回答另三個問題：面對不同的抓取器身份標識（User-agent），哪些路徑允許抓取，哪些路徑禁止抓取。

如果把兩項工作交給一個按鈕，常見結果是：

• 結構化數據代碼已經生成，字段卻與頁面實際內容不一致；
• robots.txt 沒有語法錯誤，卻誤攔截了正文頁、腳本、樣式文件或圖片。

因此，上線前至少要準備五類材料：

• 一份結構化數據代碼；
• 一份 Schema 語法校驗結果；
• 一份目標搜尋功能測試結果；
• 一份 robots.txt 文件；
• 一組使用真實網址（URL）完成的允許與禁止測試記錄。

這些材料的檢查範圍不同。任何一項“通過”，都不能代替完整驗收。

第一步：先確認頁面事實，再選擇Schema類型

不要打開 Schema 生成器後才臨時填寫字段。先查看真實頁面，把用戶能夠直接看到的資訊列出來，包括：

• 主體名稱；
• 頁面標題；
• 作者；
• 發佈日期和更新時間；
• 產品或服務屬性；
• 地址和聯繫方式；
• 常見問答內容。

頁面沒有展示的資訊，不應只出現在結構化數據中。

字段清單確定後，再根據頁面的主要內容選擇 Schema 類型：

• 企業主頁重點描述組織主體；
• 文章頁重點描述文章、作者和日期；
• 本地門店頁面重點核對地址和營業資訊；
• 產品頁重點核對名稱、價格和庫存等實際資訊。

一個頁面可以描述多個實體。實體，是能夠被單獨識別的人、組織、產品或頁面。但頁面必須説明這些實體之間的關係，不能為了增加字段而隨意添加類型，也不能把沒有關係的實體寫在一起。

常見的結構化數據格式有三種：

• JSON-LD：用獨立代碼塊表達結構化數據；
• Microdata：把結構化數據寫進網頁標籤；
• RDFa：通過網頁屬性表達結構化數據。

在網站條件允許時，Google Search Central，也就是 Google 面向網站管理者的官方搜尋文檔平台，通常建議優先使用 JSON-LD。它更容易維護，也較少因為頁面模板變化產生標記錯誤。

但這不代表 JSON-LD 天然具有排名優勢。真正需要關注的是，團隊能否長期保持頁面內容和結構化數據一致。

用於正式生產的生成器，至少應支持：

• 固定模板；
• 字段校驗；
• 測試環境與正式環境區分；
• 歷史版本保存。

只能逐頁複製粘貼、不能複用模板的工具，適合臨時試驗，不適合批量維護。

第二步：分別檢查語法、實體關係和頁面事實

第一輪檢查，可以使用 Schema.org Markup Validator，也就是 Schema.org 官方標記校驗器。它能夠提取並檢查 JSON-LD、Microdata 和 RDFa，主要核對：

• JSON 這種數據格式的代碼是否完整閉合；
• 屬性名稱是否存在；
• 字段的數據類型是否正確；
• 同一個實體是否被重複創建；
• 實體標識字段 @id 是否始終指向同一個主體。

這個工具檢查的是 Schema.org 標記本身。即使通過，也不代表頁面符合某個搜尋功能的展示要求。

第二輪必須由人工對照真實頁面，逐項核對名稱、作者、日期、價格、圖片和網址。

結構化數據中的內容，應當與用戶在頁面上看到的內容一致。如果代碼裏出現隱藏內容、過期價格、不存在的評價或錯誤的作者資訊，即使語法完全正確，也不能通過驗收。

JSON-LD 可以與頁面模板分開維護，修改比較方便，但也容易出現不同步：頁面已經更新，代碼裏仍保留舊值。

因此，生成過程應當連接真實的內容字段，或者納入版本管理，不能長期依賴人工複製的一段靜態代碼。

第三步：確認目標搜尋功能是否支持

Schema.org 詞表包含很多類型，但搜尋引擎真正支持的增強展示類型只是其中一部分。

通過語法校驗後，還要使用目標搜尋引擎提供的工具，檢查對應功能的必填字段、推薦字段和政策要求。

以 Google 為例：

• Rich Results Test，即富結果測試工具，用於檢查頁面是否具備 Google 支持的富結果資格；
• URL Inspection，即網址檢查工具，用於查看線上頁面的實際抓取、渲染和讀取情況。渲染，是搜尋系統執行頁面代碼後得到最終頁面內容的過程。

這兩項測試不能互相替代。前者檢查代碼是否符合某類搜尋功能的要求，後者檢查搜尋系統實際讀取到了哪個線上版本。

驗收時，必須明確區分四種狀態：

1. Schema 標記有效；
2. 頁面具備某類富結果資格；
3. 頁面實際獲得富結果展示；
4. 頁面被生成式答案引用。

這四種狀態不是同一個結論。

結構化數據可以幫助搜尋系統理解實體關係，但官方文檔並未承諾它會直接帶來排名、富結果展示或生成式引用。把“標記有效”寫成“必然展示”，屬於錯誤驗收。

第四步：檢查robots.txt的位置和返回狀態

robots.txt 的標準依據是編號為 9309 的互聯網技術規範（RFC 9309）。文件由不同的 User-agent 分組，以及允許規則（Allow）、禁止規則（Disallow）等記錄組成。它用於管理抓取請求，但不是訪問權限控制工具。

檢查時，應訪問每個站點根路徑下的 /robots.txt，並記錄：

• 最終訪問網址；
• 網頁請求返回狀態，也就是 HTTP 狀態；
• 伺服器聲明的文件類型；
• 是否跳轉到其他網址。

robots.txt 只對對應的訪問協議、主機名和端口生效。訪問協議就是網址開頭的 http 或 https；主機名包括主域名和不同子域名；端口是伺服器用於區分不同服務的編號。

例如，https://www.example.com/robots.txt 不會自動控制 http://example.com/，也不會自動控制其他子域名。

如果網站同時使用主域、www、移動子域或圖片子域，就要根據實際部署情況分別檢查。

正常情況下，robots.txt 應當是可以讀取的純文本。沒有 robots.txt 不一定代表配置錯誤，但伺服器持續返回 5xx 伺服器錯誤、請求超時或跳轉循環，會影響抓取器讀取規則。

驗收記錄必須區分兩種情況：

• 文件不存在；
• 文件暫時無法讀取。

兩者的原因和處理方式不同，不能統一寫成“robots.txt 異常”。

還要注意，robots.txt 不是保密工具。文件內容公開，而且是否遵守規則取決於抓取器。後台、客戶資料和內部文件必須使用登錄驗證、權限設置或網絡層訪問控制，不能依靠一行 Disallow 保護。

第五步：用真實URL檢查規則是否符合預期

robots.txt 校驗工具至少應當支持：

• User-agent 分組；
• Allow 與 Disallow 規則；
• 英文字母大小寫判斷；
• 通配符，也就是用一個符號匹配多個路徑的寫法；
• 多條路徑規則同時命中時的優先級。

按照 RFC 9309，路徑匹配採用最具體的規則。當 Allow 和 Disallow 的匹配長度相同，並且都能匹配當前網址時，應採用 Allow。

驗收不能只看文件有沒有紅色報錯。更重要的是，把規則應用到真實頁面後，結果是否符合業務預期。

測試網址至少應覆蓋：

• 首頁；
• 文章頁；
• 分類頁；
• 參數頁，也就是網址中帶查詢參數的頁面；
• 後台頁；
• 腳本文件；
• 樣式文件；
• 圖片；
• 站點地圖，也就是向搜尋系統提供站內網址資訊的文件。

測試前，先為每個 User-agent 寫明預期結果；測試後，再把工具返回的允許或禁止結果逐條核對。這樣才能發現規則與業務目標不一致的問題。

頁面顯示所依賴的腳本、樣式和圖片也要納入檢查。如果正文頁允許抓取，但關鍵腳本或樣式文件被禁止，抓取器可能無法正確理解頁面。

robots.txt 必須根據站點的真實路徑設計，不能直接複製網上的通用模板上線。

第六步：檢查robots.txt與索引指令是否衝突

抓取和索引不是一回事。抓取，是搜尋系統訪問頁面；索引，是搜尋系統保存頁面資訊，並可能把網址顯示在搜尋結果中。

robots.txt 控制抓取，禁止索引指令（noindex）控制頁面是否進入索引。兩者不能混用。

使用 robots.txt 禁止抓取，並不能保證網址不會被索引。如果搜尋系統通過其他頁面上的連結發現了這個網址，它仍可能出現在搜尋結果中。

反過來，如果頁面被 robots.txt 禁止抓取，抓取器也可能無法讀取頁面裏的 noindex 指令。

因此，當目標是阻止索引，或者把頁面從搜尋結果中移除時，應根據目標搜尋引擎的文檔，選擇 noindex、刪除、登錄保護或其他合適的方法，不能只添加 Disallow。

對於需要參與搜尋和生成式檢索的公開頁面，至少要同時確認：

1. robots.txt 允許抓取；
2. 頁面沒有誤加 noindex；
3. 規範網址和站點地圖指向正確版本。

規範網址用於聲明頁面的首選版本，站點地圖用於向搜尋系統提供站內網址資訊。任何一項配置錯誤，都不能由完整的 Schema 標記來彌補。

規則修改後，應先完成本地規則測試，再查看目標搜尋引擎的 robots.txt 報告，確認抓取狀態和解析問題，最後使用線上網址檢查工具抽查關鍵頁面。

緊急放開某個路徑時，可以請求搜尋系統重新抓取規則文件，但這不保證相關頁面會立即被重新抓取。

七類工具分別檢查什麼？

工具類別	主要任務	合格輸出	不能替代什麼
頁面字段清單	收集頁面可見事實	字段表與負責人	Schema 語法校驗
Schema 生成器	生成可複用的 JSON-LD	代碼與版本記錄	頁面事實核驗
Schema.org 標記校驗器	檢查詞表與語法	錯誤、警告及實體關係	搜尋功能資格檢查
搜尋功能測試	檢查支持類型與必填項	測試結果	實際展示保證
robots.txt 解析器	解析抓取器分組和路徑規則	真實網址的允許或禁止結果	線上抓取狀態
線上檢查工具	查看抓取、渲染和索引狀態	實時檢查記錄	全站批量複查
自動迴歸腳本	在頁面或規則修改後批量重做測試	帶版本的測試報告	人工判斷頁面事實

採購或自建工具時，應優先確認它能否：

• 導出原始代碼；
• 保存歷史版本；
• 批量執行網址測試用例；
• 記錄測試時間和結果。

只能在線點擊、無法留下可複查記錄的工具，不適合作為正式發佈驗收工具。

上線前的最小驗收清單

一套可以執行、也便於複查的最小流程如下：

1. 根據頁面可見內容建立字段清單，確定 Schema 類型和實體關係。
2. 生成 JSON-LD，並使用 Schema.org 標記校驗器消除語法錯誤。
3. 使用目標搜尋功能測試檢查必填字段，再由人工核對頁面事實。
4. 檢查每個協議和主機根路徑下的 robots.txt 返回狀態。
5. 使用真實網址樣本，驗證各 User-agent 的 Allow 和 Disallow 結果。
6. 抽查關鍵頁面的抓取、渲染、noindex、規範網址和站點地圖狀態。
7. 保存代碼、規則文件、測試結果、負責人和上線時間，作為後續複查依據。

驗收表必須記錄實際文件和實際網址，不能只寫“Schema 已做”或“robots.txt 已配置”。只要頁面模板、路徑結構、字段來源或發佈系統發生變化，就應重新執行相關檢查。

常見問題

Schema是不是越多越好？

不是。類型和字段應當對應頁面真實可見的內容。字段較少但準確、完整，比大量不準確或無法維護的字段更可靠。

校驗器沒有報錯，頁面就能上線嗎？

不能。還要核對頁面事實、目標搜尋功能要求和線上抓取版本。語法正確只完成了其中一項檢查。

JSON-LD一定比Microdata效果好嗎？

不一定。Google 通常建議使用 JSON-LD，主要因為它更便於實現和維護。這不代表三種受支持格式在語法有效時存在固定的排名差異。選擇團隊能夠長期維護的格式更重要。

robots.txt能保護後台和客戶資料嗎？

不能。robots.txt 不是訪問權限控制工具，而且文件本身公開。私密內容必須使用登錄驗證、權限設置或網絡層訪問控制。

設置Disallow後，頁面為什麼還可能被搜到？

因為 robots.txt 禁止的是抓取，不等於保證不索引。其他頁面上的連結仍可能讓搜尋系統發現這個網址。需要阻止索引時，應採用合適的索引控制方式。

robots.txt允許抓取，頁面為什麼仍沒有被引用？

允許抓取只説明頁面沒有被這組規則攔截。伺服器狀態、noindex、規範網址、內容質量、來源可信度、頁面結構以及搜尋系統自身的選擇，都會影響後續處理。

“允許抓取”不等於“已經收錄”，也不等於“已經引用”。

官方核驗入口

• RFC 9309：Robots Exclusion Protocol
• Google Search Central：robots.txt 介紹
• Google Search Central：結構化數據入門
• Google Search Central：結構化數據通用規範
• Schema.org Markup Validator 説明