# Schema結構化數據與robots.txt抓取規則驗收 > 頁面裏的 Schema 標記通過校驗，robots.txt 也沒有報錯，能不能上線？ 來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo105/（星盒AI 知識中心，更新於 2026-09-30） 頁面裏的 Schema 標記通過校驗，robots.txt 也沒有報錯，能不能上線？ 還不能。 這裏所説的 Schema，是按照 Schema.org 詞表編寫的結構化數據標記，用來説明頁面中的人物、組織、產品等主體，以及它們的屬性和關係。robots.txt 則是放在網站根目錄下的公開文本文件，用來規定搜尋抓取器可以訪問哪些路徑。搜尋抓取器，就是搜尋系統自動訪問網頁的程序。 兩者解決的問題不同：Schema 幫助搜尋系統理解頁面內容，robots.txt 管理抓取範圍。即使它們分別通過了語法檢查，也不能證明頁面內容與代碼一致，更不能保證頁面會獲得富結果展示，或被生成式答案引用。 富結果，是搜尋結果中比普通連結更豐富的展示形式；生成式答案，是搜尋或人工智能系統根據已有資訊自動組織的回答。 上線驗收的重點，不是收集幾個“檢測通過”的結果，而是確認每項結論都有對應證據。 ## 為什麼一個“一鍵工具”不能完成驗收？ Schema 需要回答三個問題：頁面主要描述什麼，主體有哪些屬性，不同主體之間是什麼關係。 robots.txt 需要回答另三個問題：面對不同的抓取器身份標識（User-agent），哪些路徑允許抓取，哪些路徑禁止抓取。 如果把兩項工作交給一個按鈕，常見結果是： - 結構化數據代碼已經生成，字段卻與頁面實際內容不一致； - robots.txt 沒有語法錯誤，卻誤攔截了正文頁、腳本、樣式文件或圖片。 因此，上線前至少要準備五類材料： - 一份結構化數據代碼； - 一份 Schema 語法校驗結果； - 一份目標搜尋功能測試結果； - 一份 robots.txt 文件； - 一組使用真實網址（URL）完成的允許與禁止測試記錄。 這些材料的檢查範圍不同。任何一項“通過”，都不能代替完整驗收。 ![Schema結構化數據與robots.txt抓取規則驗收](/static/img/insights/geo-guide/geo105-2.jpg) ## 第一步：先確認頁面事實，再選擇Schema類型 不要打開 Schema 生成器後才臨時填寫字段。先查看真實頁面，把用戶能夠直接看到的資訊列出來，包括： - 主體名稱； - 頁面標題； - 作者； - 發佈日期和更新時間； - 產品或服務屬性； - 地址和聯繫方式； - 常見問答內容。 頁面沒有展示的資訊，不應只出現在結構化數據中。 字段清單確定後，再根據頁面的主要內容選擇 Schema 類型： - 企業主頁重點描述組織主體； - 文章頁重點描述文章、作者和日期； - 本地門店頁面重點核對地址和營業資訊； - 產品頁重點核對名稱、價格和庫存等實際資訊。 一個頁面可以描述多個實體。實體，是能夠被單獨識別的人、組織、產品或頁面。但頁面必須説明這些實體之間的關係，不能為了增加字段而隨意添加類型，也不能把沒有關係的實體寫在一起。 常見的結構化數據格式有三種： - JSON-LD：用獨立代碼塊表達結構化數據； - Microdata：把結構化數據寫進網頁標籤； - RDFa：通過網頁屬性表達結構化數據。 在網站條件允許時，Google Search Central，也就是 Google 面向網站管理者的官方搜尋文檔平台，通常建議優先使用 JSON-LD。它更容易維護，也較少因為頁面模板變化產生標記錯誤。 但這不代表 JSON-LD 天然具有排名優勢。真正需要關注的是，團隊能否長期保持頁面內容和結構化數據一致。 用於正式生產的生成器，至少應支持： - 固定模板； - 字段校驗； - 測試環境與正式環境區分； - 歷史版本保存。 只能逐頁複製粘貼、不能複用模板的工具，適合臨時試驗，不適合批量維護。 ![Schema結構化數據與robots.txt抓取規則驗收](/static/img/insights/geo-guide/geo105-3.jpg) ## 第二步：分別檢查語法、實體關係和頁面事實 第一輪檢查，可以使用 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](https://www.rfc-editor.org/rfc/rfc9309.html) - [Google Search Central：robots.txt 介紹](https://developers.google.com/search/docs/crawling-indexing/robots/intro) - [Google Search Central：結構化數據入門](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - [Google Search Central：結構化數據通用規範](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) - [Schema.org Markup Validator 説明](https://schema.org/docs/validator.html)