robots.txt 合規說明
了解 robots.txt 如何影響網站的搜尋發現度、頁面渲染完整性、內容開放策略,
以及 AI 系統對網站內容的理解方式。
對 Aulait GEO Scorecard 而言,robots.txt 不是一個附屬技術檔案,而是網站對搜尋引擎、
AI crawler 與外部代理公開說明抓取邊界的第一層入口。它會影響網站能不能被抓、能不能被完整渲染、
以及外部系統是否能穩定理解你的內容開放方式。
我們將 robots.txt 納入評分,不是因為「有檔案就加分」,而是因為它會直接影響三件事情:
網站是否能被正常抓取、搜尋引擎是否能取得渲染頁面所需的關鍵資源,以及網站是否清楚表達自己對不同類型 bot 的開放邊界。
換句話說,這不是一個只屬於 SEO 顧問或工程師的技術細節,而是網站對外部系統的第一份規則說明書。 如果這裡缺失、混亂或衝突,後面的 HTML、JSON-LD、Meta Tag 即使做得不差,也可能因為入口規則寫錯而無法正常發揮。
它決定 crawler 能不能進站、哪些路徑能讀、哪些資源可渲染,直接影響內容發現度與索引效率。
它影響 AI 搜尋、引用型產品與訓練型 crawler 對內容的取用邊界,會影響理解、引用與收錄方式。
robots.txt 是放在網站根目錄的純文字檔案,用來告訴 crawler 哪些路徑可以抓、哪些路徑不建議抓。
它是 Robots Exclusion Protocol 的實作入口,Google 會先抓取並解析這份檔案,再決定後續抓取方式;RFC 9309 也已將這套協議標準化。
一份最基本的寫法通常包含下列欄位:
User-agent:規則對哪一類 crawler 生效。Allow:允許抓取的路徑。Disallow:不允許抓取的路徑。Sitemap:提供 sitemap 的完整位置。User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml
上面的意思很簡單:對所有 crawler 沒有額外封鎖,並且主動提供 sitemap 位置。對陌生網站來說, 這是一種可預測的公開姿態。你不是要外部系統自己猜網站結構,而是主動把抓取邊界講清楚。
如果網站沒有這份檔案,部分 crawler 仍可能按照預設方式抓取公開內容,但你就失去了主動定義規則的機會。 對商業網站而言,這通常不是最理想的做法,因為它讓抓取政策回到「默認狀態」,而不是你的明確策略。
下列來源可作為這個評分面向的外部依據。這些連結讓使用者理解:這不是主觀評論,而是建立在正式規範、 搜尋引擎文件與 AI 平台官方文件上的整理。
對 Aulait GEO Scorecard 而言,sitemap.xml 不只是技術清單,而是網站對搜尋引擎與 AI 系統提交的正式公開頁面目錄。
它會影響內容發現效率、更新訊號可信度,以及外部系統能否快速掌握整站內容範圍。
sitemap.xml 是一種 XML 格式的網站地圖檔案,用來列出網站希望搜尋引擎理解與抓取的 URL。
它通常位於網站根目錄,最常見的路徑包含 /sitemap.xml、/sitemap_index.xml、
與 /sitemap-index.xml。
依照 sitemap protocol 的標準格式,
一筆基本項目至少會包含 <loc> 與 <lastmod>。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/about</loc>
<lastmod>2026-04-16</lastmod>
</url>
</urlset>
如果網站規模較大,也可以使用 sitemap index 來分拆多份 sitemap,讓頁面、文章、商品或多語內容分別管理。 從產品角度看,這份檔案就是網站的公開頁面目錄,讓搜尋引擎與 AI 系統不需要只靠首頁與內部連結慢慢摸索整站結構。
很多人會把 sitemap 想成「有做就加分」的技術項目,但真正重要的不是有沒有這個檔案,而是它裡面的內容是否可信、 是否健康、是否有助於搜尋系統理解網站。
一份高品質的 sitemap 至少應該回答這些問題:
lastmod。它是一份經整理的內容清單,能幫助搜尋系統更有效率地發現、抓取與更新網站頁面。
它提供整站內容盤點入口,讓 AI 搜尋、RAG 與引用型系統更容易快速掌握正式公開內容範圍。
下列來源可作為這個評分面向的外部依據。這些連結讓使用者理解:這不是主觀評論,而是建立在正式規範、 搜尋引擎文件與內容發現最佳實務上的整理。
對 Aulait GEO Scorecard 而言,JSON-LD 不只是多一層標記,而是網站主動把頁面類型、實體、發布資訊與站內關係整理成 外部系統可直接解析的格式。這會直接影響搜尋引擎與 AI 系統的頁型判讀與語意理解品質。
JSON-LD 是一種用 JSON 表示 Linked Data 的格式,常用來描述頁面類型、品牌、作者、Breadcrumb、FAQ、文章欄位與其他可結構化資訊。 Google 在 structured data 文件中明確建議,若網站環境允許,應優先使用 JSON-LD。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "AI 驅動的網站 SEO 健檢",
"author": {
"@type": "Organization",
"name": "Aulait GEO Scorecard"
},
"datePublished": "2026-04-16"
}
</script>
若用更產品化的方式來說,JSON-LD 就像是網站提供給搜尋與 AI 系統的一張結構化說明卡: 正文仍然很重要,但重要語意會被整理成更容易直接處理的欄位。
JSON-LD 會被納入評分,不是因為掛上一個 <script type="application/ld+json"> 就值得加分,
而是因為它反映網站是否具備把內容「結構化表達」的能力。
一份品質良好的 JSON-LD,至少應該回答這些問題:
它能幫助頁面類型辨識與部分rich result理解,讓單頁內容不只是文字,而是有類型與欄位的資料單位。
它能降低頁型、實體與關係判讀成本,讓外部系統更快建立頁面框架與站點身份。
下列來源可作為這個評分面向的外部依據。這些連結讓使用者理解:這不是主觀評論,而是建立在搜尋引擎文件、Schema.org 與 JSON-LD 規範上的整理。
對 Aulait GEO Scorecard 而言,HTML 結構不是在評前端寫法漂不漂亮,而是在看內容是否被整理成 對人可讀、對搜尋引擎與 AI 系統也可推論的骨架。
HTML 結構指的是頁面如何用標記語言把內容組織起來。這不只是有沒有標籤,而是主標、章節、主內容區、導覽、側欄、列表、表格、圖說與連結是否用合理方式表達。
這個面向最關鍵的不是畫面效果,而是下列問題:
若頁面視覺上很完整,但底層 HTML 幾乎沒有語意,外部系統在理解時就得花更多成本猜測什麼是主題、什麼是主內容、什麼只是模板。
HTML 結構會成為評分依據,是因為搜尋引擎與 AI 系統在理解網頁時,不是只讀一串文字,而是讀一個有主次、區塊與層級關係的文件。
一個品質良好的 HTML 結構,至少應該回答這些問題:
它會影響頁面主標、內部連結、主內容區與內容型態如何被辨識。
它會影響主內容抽取、段落切分、重點歸納與頁面主次判斷的穩定度。
下列來源可作為這個評分面向的外部依據。這些連結讓使用者理解:這不是前端潔癖,而是建立在搜尋引擎、W3C 與 MDN 文件上的內容骨架判讀。
對 Aulait GEO Scorecard 而言,OpenAPI 不是只給工程師看的補充文件,而是網站是否有把服務能力、輸入輸出格式與高價值內容出口講清楚的能力訊號。
OpenAPI 是描述 HTTP API 的標準格式。它把 API 的版本、入口、路徑、參數、請求格式、回應格式、授權方式與共用資料模型整理成外部系統可直接解析的文件。
對這個評分面向來說,重點不只在文件內容,也在於它是否能被穩定找到。
/.well-known/openapi.json/openapi.json/swagger.json/openapi.yaml / /openapi.yml/docs/openapi.json/api/openapi.json/v3/api-docs當網站把文件放在這些常見入口時,搜尋系統、文件工具、整合平台與 AI 助理就更容易辨識:這個網站除了有內容頁,也有可被理解與使用的服務能力。
如果 \`robots.txt\` 在講抓取邊界、\`sitemap.xml\` 在講內容盤點、Meta Tags 在講頁面摘要,那 OpenAPI 講的就是網站的能力邊界。
一份品質良好的 OpenAPI 至少應該回答這些問題:
它能把查詢、交易、預約、登入、訂單、報價等能力整理成可被整合的使用格式。
它也能把 FAQ、活動、條款、隱私、價格與門市資訊整理成結構化內容出口。
下列來源可作為這個評分面向的外部依據。這些連結讓使用者理解:這不是主觀評論,而是建立在 OpenAPI Initiative 正式規範與 learn 文件上的整理。