llms.txt 能被 AI 推薦嗎？破解檔案迷思

說不定你也曾在某個行銷 Line 群組看過這段話：「聽說在網站根目錄放一個 llms.txt，ChatGPT、Gemini 就會優先推薦你的網站，這是 AI 搜尋時代的新藍海，現在還沒什麼人做。」每當有人拋出這段話，不妨先深呼吸，然後反問一句：你能不能說出「那個聽說」到底是從哪裡來的？十次有九次，對方是一片沉默。

先說結論：llms.txt 是可放在網站根目錄或子路徑、以 Markdown 整理網站資訊的實驗性提案（見 llmstxt.org 提案），Google 搜尋明確不使用它作為能見度或排名依據；其他系統是否讀取，應依各自文件與實測判斷。可依網站需求評估是否建立，但不應取代可抓取內容、清楚架構、來源與品牌資訊等基本工作；GEO 的整體檢查可參考GEO 五大原則。

接下來把 llms.txt 從頭拆到尾：它從哪裡來、跟 robots.txt 差在哪、格式長怎樣、誰真的會去讀它、業界在吵什麼、以及從白帽 SEO 實務的角度，會怎麼建議你配置有限的時間。如果你還在摸索 AI 搜尋整體長什麼樣，可以先翻一下 AI 搜尋時代的 SEO 全攻略，把大局觀建立起來，再回來看這個單一檔案。

在動手之前，得先點破一個心理陷阱。為什麼「放一個檔案就能被 AI 推薦」這種說法這麼有市場？因為它打中了兩個軟肋。第一個是焦慮：AI 搜尋崛起太快，每個站長都怕被時代拋下，急著找一個「現在立刻能做」的動作來安撫自己。第二個是惰性：比起老老實實寫十年第一手經驗內容、把結構化資料補到滴水不漏、把品牌經營成實體，放一個根目錄檔案簡直是天上掉下來的捷徑。行銷話術最厲害的地方，從來不是騙你，而是精準餵養你心裡早就想相信的事。所以當你聽到「放個檔案就好」這類保證時，請先把這段話在腦海裡重播一次。話先說在前面：這篇文章不會給你捷徑，僅會給你一份誠實的地圖，讓你自己決定要走多遠。

llms.txt 是什麼：一份寫給 AI 的網站說明書

llms.txt 這個名字，明顯是抄自 robots.txt。但兩者其實是完全不同的東西，把它們混為一談，是一切誤解的起點。

用最白話的方式講：robots.txt 是你貼在大門口的「爬蟲請勿走這些路徑」告示牌，用來管理遵守規則的爬蟲流量，但不是存取控制或保密機制。llms.txt 則是一張放在大廳接待桌上的「導覽簡介」，告訴每一位上門的 AI 訪客：「這個網站最重要的內容是這些，你想快速理解我們在做什麼，從這幾個連結開始讀就對了。」

它由 Jeremy Howard 提出。如果你接觸過機器學習，多半聽過 fast.ai，他就是共同創辦人；他同時也是 Answer.AI 的創辦人。提案的初衷很單純。啟用網頁檢索或瀏覽工具的 Agent 讀取網站時，常須從含導覽列、側邊欄等介面元素的 HTML 找出所需內容；並非每次模型回答都會即時造訪網站。模型要花掉大量 token，才能從這堆雜訊裡扒出真正有用的內容。llms.txt 的想法是：網站主動提供一份「已經幫你過濾好、純文字、重點導向」的精簡版，省得模型在雜訊裡自己摸索，讓它用最低成本抓到你的核心價值，完整構想收在 llmstxt.org 官方提案。

這個提案會在這個時間點冒出來，並不意外。AI 在行銷工作裡的滲透速度，這兩年快得嚇人，各種〈State of Marketing〉類型的年度報告都把「行銷人日常使用 AI」列為最顯著的趨勢之一，例如 HubSpot 的 State of Marketing Report。當 AI 從「寫文案的工具」升級成「幫使用者做決策的代理人」，網站能不能被 AI 順利讀懂，就從冷門的技術議題變成生存議題。llms.txt 正是這股壓力下冒出來的其中一個答案。

但請注意這裡用的詞：實驗性提案。它不是 W3C 標準、不是 IETF 草案、也沒有任何一家主要搜尋引擎公開背書說「我們會讀這個檔案，而且讀了會影響你的 AI 引用排名」。它就是一個社群發起的約定，目前還在「看大家要不要跟」的階段。這個定位非常重要，後面會一再回到這一點，因為九成的錯誤期待，都來自沒搞清楚 llms.txt 目前僅是個提案。

從 meta keywords 到 llms.txt：根目錄「魔法檔案」的演化簡史

要真正看懂 llms.txt，最好把它放回 SEO 演化的時間軸上。在 SEO 領域裡，同一種幻想反覆出現：僅需在根目錄放對一個檔案、加對一段標籤，排名就會自動變好。這種「一檔定生死」的誘惑從來沒斷過，差別僅在於每次的主角不同。

這條演化線對照如下：

看出規律了嗎？這條線上有兩種截然不同的結局。一種是像 robots.txt、sitemap.xml、結構化資料這一類，它們解決的是真實存在的工程問題：爬蟲可爬哪些路徑、網站有哪些頁面、內容屬於什麼類型。因為問題是真的、答案是有用的，後來被搜尋引擎採納為基礎建設。sitemap.xml 對台灣很多站長來說仍是實用設定，如果你沒做過，可以從 XML Sitemap 介紹 開始。

另一種結局是像 meta keywords。它本來想走捷徑、用一個標籤代替真正的內容工程，結果因為太好灌水，所有人都把競爭對手的品牌名、不相關的熱門字塞進去，最終被搜尋引擎整個拔掉，連根拔起。一個曾經「人人都說要做」的東西，變成今天新手根本沒聽過的名詞。

llms.txt 會走向哪一邊？判斷如下：它想回應的問題有其實務場景（Agent 讀取網站時的導覽與上下文成本），但它的命運取決於兩件事。第一，有沒有夠多、夠有分量的 AI 系統願意正式消費它。第二，它會不會重蹈 meta keywords 的覆轍，被當成下一個關鍵字堆砌的戰場。現在斷言「它一定會變成新的 robots.txt」或「它一定會變成新的 meta keywords」，都太早。把這個不確定性放在心裡，你就不會做出失衡的決策。

llms.txt 跟 robots.txt 差在哪？六個維度一次看懂

很多人把這兩個檔案當成同一類，這是圈外人最常犯的錯。以下用六個維度直接把它們對比清楚：

這張表裡最關鍵的一格是「強制力」。robots.txt 有重量，是因為主要搜尋引擎的合作型爬蟲普遍遵守它（見 Google 的 robots.txt 說明）；但它是公開的自願規則，不會阻止不合作的爬蟲，也不能拿來保護私密內容。llms.txt 更像你在門口擺了一張「歡迎光臨，本店招牌是這幾道」的推薦菜單，客人（AI）要不要看、看了要不要信，全憑它自己。

這裡要插一句實務上的提醒：一行 Disallow 寫錯，可能阻止搜尋引擎爬取重要頁面，連帶影響內容更新與索引判讀；但這不等於網址必然立刻從索引消失。robots.txt 是會「咬人」的檔案，改它要戰戰兢兢。llms.txt 的直接風險較低，常見問題是沒人讀、連結失效或內容過時。如果你對 robots.txt 的細節還不熟，建議先讀 robots.txt 介紹，把爬蟲管理用途搞懂，再來談 AI 導覽。很多人也會混淆 robots.txt 跟 noindex，可以搭配 robots.txt 與 noindex 為什麼不能同時用 一起看。

llms.txt 的格式解剖：它裡面到底裝了什麼

講完定位，來拆解它的長相。llms.txt 的格式其實很樸素，就是一份 Markdown 文件，可先用 H1 命名網站或專案，再按需要補摘要與連結；v2 提案沒有必填的四層。

依 2026 年 8 月更新的 v2 提案，唯一必填區塊是網站或專案名稱的 H1。後面可放摘要 blockquote、補充段落，再用 H2 分組列出 Markdown 連結；連結後的冒號與說明也是選用。檔案可位於根目錄或子路徑，涵蓋所在路徑下的內容，若有多份適用檔案則採最具體的那份。這是提案格式，不是搜尋引擎的排名要求。

把它具象化，一份陽春的 llms.txt 大概像這樣：

# 你的網站名稱

> 一句話講清楚這個網站是做什麼的、服務誰。

## 核心服務
- [服務介紹](https://你的網域/service): 我們的主力服務與報價邏輯
- [關於我們](https://你的網域/about): 團隊背景與過去案例

## 深度文章
- [入門指南](https://你的網域/guide): 給新手的完整觀念建立
- [進階教學](https://你的網域/advanced): 給已上手的讀者的優化技巧

換句話說，它不是把整個網站的內容一股腦倒進去，而是一份「精選導讀」。你挑出網站裡最重要的幾個入口，給每個入口一句話的註解。這個設計本身就是一種編輯判斷：你必須很清楚哪些頁面才真正代表你這個網站的核心價值；把導覽列上二十個連結全塞進去，僅會模糊焦點。挑選本身就是價值，懂得刪減才顯得出你作為網站主人的判斷力。

正因為它考驗編輯判斷，好 llms.txt 跟爛 llms.txt 的差距非常大。下面用一張表把兩者對比出來，你照著右邊那一欄避雷就對了：

這張表裡最容易被輕忽的是「誠實度」。llms.txt 若塞入無法由頁面驗證的宣稱，就會增加資訊不一致與維護成本。把它當成網站導覽，具體說明每個連結提供什麼即可；目前沒有證據顯示 AI 系統會替單一網站的 llms.txt 建立公開的信任分數。

早期提案曾介紹將連結內容展開成 llms-ctx.txt 等檔案的工具；2026 年 8 月的 v2 已把這類展開工具移出提案，改為由 Agent 查看導覽、再跟隨所需連結。v2 也允許用 HTML link 或 HTTP Link 標頭指出 Markdown 替代版與適用的 llms.txt。llms-full.txt 並不是每個網站必須提供的固定搭配檔案。

這裡藏著一個多數人沒想過的陷阱：llms.txt 是另一份需要維護的內容摘要。網站改版、頁面更名、連結搬移之後，它就可能跟現實脫鉤。一份過時的導覽會把讀取它的工具帶到不存在的頁面，產生斷連結；問題在維護漂移，不是 Google 所說的「重複內容處罰」。這點在後面的爭議段落會再展開。

誰真的在讀 llms.txt？把傳聞和事實分開

這大概是大家最想知道、也最多謠言的一段。這裡直接把目前能查到的事實攤開，不加油添醋。

第一個事實。Chrome 的 Lighthouse 團隊，已經在「agentic browsing」（代理人瀏覽）這組稽核項目裡，加入對 llms.txt 的檢查。這項稽核檢查讀取檔案時是否發生伺服器錯誤；若檔案不存在而回傳 404，結果是 N/A，因為提供檔案仍屬選用。它不是 Google 搜尋排名或 AI 引用測試，可見 Chrome Lighthouse 的 llms.txt audit。Lighthouse 的 agentic browsing 類別仍屬實驗性稽核；通過 llms.txt 項目只代表檔案請求未發生伺服器錯誤，不能推論任何 Agent 已讀取或採用它。想理解這個大趨勢，可以讀 Agentic Browsing 介紹。

第二個事實。Yoast SEO 這個 WordPress 生態最普及的 SEO 外掛，已經發布了〈Yoast SEO llms.txt functional specification〉功能規格，並提供自動產生器。這代表主流的 SEO 工具鏈，開始把它當成一個正式功能來支援，不再放任站長各自手刻。用 WordPress 架站的人，若目標工具確實會使用 llms.txt，可把產生器納入選用的導覽維護流程；它不屬於 Google 搜尋必做設定；若使用 WordPress，可另參考 WordPress SEO 必做設定。

第三個事實。有些文件平台會產生 llms.txt，個別 Agent 也可能在任務中讀取；但 MCP 協定本身未要求伺服器抓取 llms.txt，兩者不能畫上等號。MCP 是讓 AI 模型跟外部資料源、工具對接的協定，被很多人視為 Agent 時代的「通用插頭」。想搞懂它在 AI 搜尋裡的位置，可以看 MCP 入門指南。較具體的情境是文件工具或 Agent 明確支援這份導覽，例如 API 文件站；是否有用仍要看目標工具的文件、請求紀錄與實際任務測試，不能因採用 MCP 就推定會讀。

第四個事實。第三方 SEO 媒體 SE Ranking 在 2025 年做過專題分析，結論傾向「它是一個低成本、低風險、但效果尚未被驗證的實驗」，並建議站長可以順手做、但別過度期待。

Google 在現行生成式搜尋指南更明確說明：Google Search 不使用 llms.txt 或特殊 AI 標記，維護這類檔案不會幫助或損害 Google 搜尋能見度與排名。其他 Agent 或文件工具可以有自己的使用情境，應與 Google AI Overviews、AI Mode 的搜尋成效分開判讀。

至於傳聞區，網路上流傳「ChatGPT 會優先推薦有 llms.txt 的網站」「放上去 AI 引用率翻倍」這類說法。原則很簡單：講的人若拿不出可查證的來源、給不出測試方法，就不該當真。把這些話當行銷話術看待，遠比當技術事實看待安全。

把上面整理成一句話：llms.txt 已經被部分開發工具與 Agent 框架消費，這是真的；但它還沒有得到主流搜尋引擎作為能見度訊號的官方背書。它的「存在」是真的，它的「影響力」仍是一個問號。一個有意思的類比：robots.txt 處理的是合作型爬蟲可爬取哪些路徑，連帶牽涉傳統 SEO 的爬取預算問題；llms.txt 想處理的則是「AI 的理解成本」。差別在於，爬取預算背後有 Google 公開說明的機制，理解成本目前仍停留在「網站單方面遞名片」的階段。

llms.txt 的四個爭議：為什麼連專家都還沒共識

正因為 llms.txt 處於實驗階段，業界對它的看法分歧很大，不是一邊倒的支持或反對。以下把最核心的四個爭議拆出來，讓你自己判斷。

第一個爭議，是否採用取決於使用它的系統。robots.txt 是合作型爬蟲普遍採用的流量管理規則，也不是強制存取控制；llms.txt 則是選用導覽。網站發布檔案，不表示任何模型必然讀取或採信，更不能把它當成存取授權或排名承諾。

第二個爭議，維護負擔與內容漂移。對一個持續更新的網站來說，每多一份人工維護的摘要，就多一份「跟現實脫節」的風險。想像你三個月前寫了 llms.txt，這三個月裡你改了五個頁面的網址、新增了兩個服務、下架了一個產品線。如果沒有同步更新，你的 llms.txt 現在是一張過期菜單，把讀取它的工具帶到一堆 404。可行做法是用內容管理系統的產生器，或把檔案納入定期連結檢查，避免手刻之後就忘了更新。

第三個爭議，操縱風險。回想 meta keywords 是怎麼死的：因為它太好灌水，所有人都把競爭對手的品牌名、各種不相關的熱門字塞進去，最終搜尋引擎整個不採信。llms.txt 如果被當成「給 AI 看的關鍵字堆砌區」，把毫無事實根據的自吹自擂寫滿，同樣的劇本很可能重演。一旦大量網站開始在裡面塞誇大不實的描述，AI 系統很快就會學會「不信任這份檔案」。換句話說，少數人誠實地做，它有價值；一旦變成全民運動、人人灌水，它就會迅速貶值。這是一個典型的公共財悲劇：誠實的人補貼了投機的人，最終大家一起失去這個工具。

第四個爭議，標準未定。llms.txt 不是市場上唯一的這類提案，一直有人在各種場合討論「給 AI 讀的網站描述」應該長怎樣、該放哪、由誰來定。誰會勝出、會不會被合併、會不會被某個大廠的官方格式直接取代，目前完全沒有定論。在一個標準還沒收斂的賽道裡押重注，從來都不是明智之舉。聰明的做法是「輕量參與、持續觀察」，現在還不到把整個資源押下去的時候。等局勢稍微明朗，再把投入往上調，這才是面對實驗性標準該有的節奏。

這四個爭議疊在一起，就是為什麼連第一線的 SEO 與 GEO 實務工作者都還拿不定主意。負責任的顧問不會給你一個「做就對了」或「別浪費時間」的二選一，而是會告訴你：在什麼前提之下做、做到什麼程度、把期待校準在哪裡。

llms.txt 在「AI 友善化」這盤棋裡的真正位置

很多人一聽到 llms.txt，就以為它是「讓網站變得 AI 友善」的萬靈丹，以為做完了這一份就等於跟上 AI 搜尋潮流。這個誤會大得很。換句話說，llms.txt 僅是讓網站變得「好讀」的其中一個手段，而且還是裡面最薄、最容易被略過的那一層。要真正看懂它的分量，最好把「AI 友善化」想成一座五層的積木塔。

看清楚這張表，你就會明白一個關鍵：llms.txt 位在最頂端的「提示層」，而底下四層沒有一層靠它撐著。地基不穩，重要內容無法被爬取或解析，你給它再精美的 llms.txt 也救不回來，這就是為什麼 JavaScript SEO 跟 頁面速度 應排在前面。語意層可使用與頁面內容相符、且受搜尋引擎支援的結構化資料；它有助機器理解並取得部分搜尋結果資格，但不保證 AI 引用，也沒有 AI Overview 專用 Schema。分享預覽則可參考 Open Graph 標籤。機器可讀檔案家族裡還有 A2A 協定的 Agent Card，它服務的是代理程式對服務端點的發現與連線，與 llms.txt 的內容導覽分屬不同用途。

再往下看內容層，這才是網站能否提供可靠答案的地方。llms.txt 不能代替第一手資料、清楚來源與完整脈絡；可參考 資訊增益，檢查內容是否真的補上讀者在其他頁面找不到的資訊。導覽層則靠 sitemap.xml、清楚的 網站架構 與健康的 內部連結，幫爬蟲與讀者找到相關頁面。

這五層是本文整理工作的框架，不是公開的 AI 排名權重。先處理讀者需求、存取與內容錯誤，再視目標 Agent 是否實際使用 llms.txt，決定是否投入維護；不能推論完成其他四層後，llms.txt 就會產生搜尋加乘效果。

另一個常見問題是：llms.txt 會不會跟結構化資料打架、或功能重複？兩者用途不同。結構化資料是在單一頁面上，以標準詞彙描述內容；搜尋引擎會自行決定是否採用，標記正確也不保證豐富結果。llms.txt 則是全站自由格式導讀，讀取它的系統也不一定採信。如果資源有限，應先完成搜尋引擎明確支援、且與頁面內容相符的結構化資料，再把 llms.txt 當低成本實驗。

整體判斷與三十分鐘務實做法

講了這麼多，你一定想問：那到底要不要做？這裡給你一個不拐彎的答案。

可以做，但要正確地期待它。 把 llms.txt 定位成低優先級實驗，它的身分是配角，主角仍是可爬取、可理解且有用的內容。檔案本身不複雜，但仍有維護成本：內容改版後若沒有同步更新，便可能留下失效連結或過時描述。沒有明確使用情境時，不必為了跟風先做。

但有一種情況，會明確建議你「先別碰 llms.txt」。如果你的網站連下列這些基本功都還沒到位，llms.txt 對你來說就是純粹的分心：Google Search Console 裡還有一堆收錄錯誤沒處理（先把 收錄查詢 跑一遍）；適用的結構化資料尚未核對；頁面速度已影響使用者；內容有明顯錯誤或缺乏可查證的經驗；內部連結亂成一團、網站架構像迷宮。這些是更值得先檢查的問題，實際優先順序仍須依網站用途與已觀察到的障礙決定。若有明確會讀取 llms.txt 的目標工具，再評估是否值得花時間建立與維護；不必把它列成每個網站的下一步。不知道從哪裡補起的人，可以跟著30 天 AI 搜尋健檢計畫逐項檢查，把基礎一次補齊。

但請千萬、千萬不要掉進「做了 llms.txt 就等於做了 AI SEO」這個陷阱。Ahrefs 的〈搜尋流量研究〉分析的是自家 Content Explorer 樣本的估算流量，不能外推成全網收錄率，更不能用來證明 AI 引用的因果。評估 llms.txt 時，仍要先看目標工具是否讀取，以及網站內容是否準確、有用。

如果你決定動手，下面是建議走的三十分鐘流程，每一步都給你具體動作：

1. 盤點（十分鐘）： 挑出你網站裡最重要的五到十個頁面。標準很簡單：如果一個完全陌生的 AI 訪客僅能讀你網站的五個頁面，你會希望是哪五個？通常是首頁、核心服務頁、最重要的兩三篇深度文章、加上定價或關於我。把導覽列上那二十個連結全塞進去，等於沒有重點，AI 讀完還是不知道你是誰。
2. 撰寫（十分鐘）： 用 Markdown 寫。H1 寫網站名，一行 blockquote 寫你這個網站的一句話定位，然後一兩個 H2 分類，每個分類底下把那幾個頁面用連結加一句話描述列出來。描述要誠實、要具體，不要灌形容詞，不要寫「業界領先、品質保證」這種 AI 一看就知道是廢話的字。
3. 上線與驗證（十分鐘）： 可先放在 https://你的網域/llms.txt；若只描述特定路徑，也可依 v2 提案放在對應子路徑，用瀏覽器打開確認能正常存取、內容是純文字 Markdown。若使用 WordPress 且確有目標工具需要，可評估官方支援的產生器與維護流程。可再用 Lighthouse 的 agentic browsing 稽核確認沒有伺服器錯誤；404 會是 N/A。這一步不代表任何 AI 服務已讀取或引用。
4. 排程維護（零分鐘，但要做）： 在你的季度 SEO 檢查清單裡加一行「檢查 llms.txt 連結是否還有效」。過時的導覽比沒有導覽更糟，這句話值得再講一次。把這件事跟你的 sitemap 檢查、結構化資料驗證排在同一個巡檢流程裡，每季跑一次，幾乎不用花腦力。

評估投入時，可優先檢查下列三項能改善網站使用與內容可信度的工作。它們沒有通用的投資報酬率，也不能保證 AI 引用；成效需要由自己的流量、使用者回饋與商業結果驗證。

第一，可爬取的語意 HTML，加上與頁面內容相符且受支援的結構化資料。這是讓機器讀取內容的地基；結構化資料能取得特定搜尋功能的顯示資格，但不保證豐富結果，也不是每個網站都需要把產品、文章、FAQ、組織類型全部標上。想深入做，可以從 結構化資料完整教學 開始，依實際頁面類型選擇標記。

第二，能證明的第一手經驗內容。測試條件、操作步驟、原始資料與限制，能補足通用整理文缺少的判斷材料，也方便讀者查證；但 AI 系統沒有公布「永遠偏好第一手經驗」的規則，具體內容也不保證被引用。經驗如何呈現，可參考 E-E-A-T 完全指南。

第三，把自己的品牌與主題經營成一個「實體」（Entity），讓讀者與系統較容易辨識你的品牌、服務與責任歸屬。跨平台資料一致與可信來源有助於查證，但提及次數不是公開的引用保證，也不應製造虛假提及。這不是靠一個檔案就能達成的，它靠的是長期、一致、跨平台的內容與引用累積。詳見 Entity SEO。想知道 AI 偏好什麼樣的內容結構，還可以搭配 AI 偏好內容規劃術，把內容生產端也對齊；想從更高層級理解生成式搜尋的布局邏輯，可以再讀 生成式搜尋優化。

這三件事，沒有一件是三十分鐘搞定的，但每一件都是會複利的長期資產。llms.txt 做完就把它放下，把絕大部分的心力留在這裡。

最終講一個很多人沒想到的現實問題：你要怎麼知道 llms.txt 到底有沒有發揮作用？老實說，目前沒有任何工具能精準告訴你「因為你放了 llms.txt，所以被 AI 多引用了幾次」。你能做的，是間接觀察。第一，用瀏覽器、伺服器記錄或 Lighthouse 確認檔案可正常取得；這仍不代表 Agent 已採用。第二，若有明確支援 llms.txt 的目標工具，記錄它的實際請求與任務表現。第三，可另看 GA4 的可辨識 AI 引薦流量，但不能把流量變化歸因於這個檔案。把它跟 AI 偏好內容、結構化資料、實體經營放在同一張計分卡上，你才會得到一個合理的全貌。只看 llms.txt 的檔案請求數，無法判定內容是否被採用；若目標工具提供可重複的任務測試，才有機會進一步觀察作用。

AI 搜尋的規則還在劇烈變動，llms.txt 可能是未來基礎建設的雛形，也可能是下一個被悄悄遺忘的實驗。你能做的，是讓自己隨時看懂這類新東西的真實分量，不被群組裡的話術牽著鼻子走。工具會換，檔案會被淘汰，但你判斷「這東西到底值多少」的能力，永遠不會貶值。下一個像 llms.txt 這樣的「根目錄新魔法」遲早會再出現，到時候你能不能一眼看穿它的本質，靠的就是今天這種把事實、傳聞、爭議分開來看的習慣。現在，就從打開你網站的根目錄、清點那五個最重要的頁面開始吧。