讓 AI 讀得懂你的網站:AEO 技術實作手冊

「我們官網做得很漂亮,為什麼買家去問 ChatGPT『台灣有哪些做這個的供應商』,答案裡完全沒有我們?」這是 HappyCXO Studio 最常被台灣外銷製造業問到的一句話。多數情況下,問題不在內容不夠好,而在 AI 根本讀不到你的網站:爬蟲被擋在 robots.txt 外面、頁面要跑完 JavaScript 才長出內容、產品規格全部躺在一張 JPG 裡、整站找不到一行結構化資料。策略層的「為什麼要做 GEO」我們在 GEO 時代 B2B SEO 生存指南 談過,全站的健檢清單在 製造業官網 SEO checklist。這一篇不談策略、不談寫法,只做一件事:把 AEO 的技術設定,按照正確順序一步一步做完,並且教你怎麼驗證自己真的做對了。內容適用於任何 CMS——WordPress、Shopify、Wix,或自製的 Next.js 網站都一樣。

AI 讀不到你的網站,通常卡在這三件事

先給答案:AI 讀不到你的網站,九成卡在三個技術關卡——第一,robots.txt 沒有明確允許 AI 爬蟲;第二,頁面內容要靠瀏覽器端 JavaScript 才長出來;第三,沒有結構化資料,AI 只能用猜的判斷你是誰、賣什麼、可不可信。 這三件事都是純技術動作,不需要多寫任何一個字的內容,通常半天到兩天就能做完。

理解這件事最好的方式,是把 AI 讀你的網站想成一個三層漏斗:抓取(crawl)→ 解析(render)→ 理解(understand)。第一層被擋住,後面兩層再完美都是零。第二層拿到空殼 HTML,再豐富的內容也等於沒寫。第三層沒有結構化資料,AI 拿到一堆文字卻拼不出「這家公司叫什麼、在哪裡、做什麼、誰寫的、什麼時候更新的」——它可以引用你,但它更可能引用一個把這些講清楚的競爭對手。

這個漏斗有個殘酷的特性:它是相乘的,不是相加的。任何一層是零,整體就是零。所以順序很重要:先修 robots.txt(最便宜、最快、影響最大),再修算繪(最貴、但決定天花板),最後補結構化資料(工作量中等、可以逐頁補)。很多公司順序做反了——花三個月請人做 schema,結果 robots.txt 裡還躺著一行從測試站帶過來的 Disallow: /。

要破除一個很常見的迷思:很多老闆以為「AEO = 多寫文章」,所以第一步就開始請人寫部落格。 事實正好相反——在技術地基沒鋪好之前寫的每一篇文章,對 AI 來說都是寫在一張看不見的紙上。內容當然重要,但它是乘數,不是基數;基數是零的時候,乘再多也是零。先花兩天把地基做完,再開始寫,同樣的內容預算能拿到完全不同的結果。

還有一個時間差要有心理準備:技術改動不會立刻生效。以 robots.txt 為例,Google 一般會快取內容最多 24 小時,遇到逾時或 5xx 錯誤還可能快取更久(見 Google robots.txt 說明文件)。其他 AI 爬蟲的快取與回訪週期各家不同,而且大多沒有公開。所以合理的期待是:改完之後,以「週」為單位觀察,不是以「小時」為單位刷新。

最後提醒一個容易被忽略的組織現實:這一整套動作,通常橫跨行銷、資訊、以及外包的網站廠商三方。行銷知道要做但不會改;資訊會改但不知道為什麼要改;外包廠商合約裡沒寫這項所以不動。最有效的做法是把本文的第七節那張檢查表直接丟給廠商當驗收條件,而不是用「請幫我們做 AEO」這種對方無法報價的說法。

robots.txt:明確歡迎 GPTBot、ClaudeBot、PerplexityBot 等 AI 爬蟲

先給答案:在網站根目錄的 robots.txt 裡,用「具名 User-agent 區塊」逐一 Allow 你要歡迎的 AI 爬蟲,而不是只留一行 User-agent: ,因為多數爬蟲只遵守最符合自己名字的那一組規則。 這是整份技術設定裡投報率最高的一步,通常十分鐘就能改完。

先講一個很多人不知道的背景:robots 排除協定用了快三十年,卻到 2022 年才由 IETF 正式標準化為 RFC 9309。標準化之後仍然只是「自願遵守」的君子協定——它擋不住惡意爬蟲,但主流 AI 供應商都公開承諾遵守。這代表:你在 robots.txt 寫的東西,對想引用你的 AI 是真的有效的。

目前值得你逐一具名處理的爬蟲,大致分成三種用途:

• OpenAI:GPTBot(模型訓練)、OAI-SearchBot(ChatGPT 搜尋索引)、ChatGPT-User(使用者當下問問題時的即時抓取)。三者用途不同,可以分開決定,見 OpenAI 官方 bots 說明。
• Anthropic:ClaudeBot、Claude-User、Claude-SearchBot,說明見 Anthropic 的爬蟲說明。
• Perplexity:PerplexityBot(索引)與 Perplexity-User(使用者觸發),見 Perplexity bots 文件。
• Google:Googlebot 負責一般搜尋;Google-Extended 是一個獨立的控制項,用來決定內容是否用於 Gemini 等生成式產品,它不影響搜尋排名,詳見 Google 爬蟲總覽。
• 其他值得放行的:Bingbot(Microsoft Copilot 走 Bing 索引)、Applebot 與 Applebot-Extended、Amazonbot、meta-externalagent、CCBot(Common Crawl,很多開源模型的資料來源)。

一份可以直接抄的最小範例:

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /studio

Sitemap: https://www.example.com/sitemap.xml

爬蟲名單會變動,不要一次寫完就當作永久有效。開源專案 ai.robots.txt 持續維護一份最新的 AI 爬蟲清單,可以每季對照一次。在 HappyCXO Studio 自己的網站上,我們在 robots 設定裡明列了 13 個 AI 爬蟲的 allow 規則,只把 /studio 後台整個擋掉。

最常見的四個錯誤,每一個我們都在客戶站上實際看過:第一,robots.txt 允許了,但 Cloudflare 或其他 WAF 的「一鍵封鎖 AI 爬蟲」開關開著——兩邊互打,結果以防火牆為準,你等於白改。第二,測試站的 Disallow: / 隨著上線一起搬過去,整站對所有爬蟲關門。第三,robots.txt 回傳 404 沒事,但持續回 5xx 有事——Google 在連續錯誤超過 30 天後可能改用「整站不可抓」的解讀。第四,規則寫在 User-agent: 底下,卻以為具名爬蟲會繼承;實際上爬蟲只讀最具體的那一組,你在通用組裡寫的 Allow 它不會拿來用。

要不要讓「訓練型」爬蟲抓,是一個真正需要老闆決策的商業判斷,不是技術問題。分界線很清楚:檢索型爬蟲(OAI-SearchBot、PerplexityBot、Claude-SearchBot)是你被引用的管道,幾乎沒有理由擋;訓練型爬蟲(GPTBot、Google-Extended、CCBot)則是「用我的內容養模型」。 對外銷製造業來說,我們的一般建議是兩者都開:你的規格表與應用案例不是版權作品,被模型學走的邊際損失極小,但被 AI 記得你的品牌與型號,價值極大。真正需要保護的是報價、客戶名單與圖檔原稿,那些本來就不該公開在網站上。

改完之後怎麼確認?最直接的方式是模擬爬蟲身分打一次你的頁面:

curl -s -A "GPTBot" -o /dev/null -w "%{http_code}\n" https://www.example.com/
curl -s https://www.example.com/robots.txt | head -40

如果第一行回 200 就通過;回 403 幾乎都代表 CDN 或 WAF 在擋,要去防火牆設定裡放行,而不是再改 robots.txt。

llms.txt 是什麼?該放哪些內容

先給答案:llms.txt 是放在網站根目錄的一份 Markdown 檔(網址就是 /llms.txt),用結構化的清單告訴語言模型「這個網站是誰、最重要的頁面有哪些、去哪裡拿全文」。 它由 Jeremy Howard 在 2024 年 9 月提出,規格公開在 llmstxt.org,目的是解決「模型的上下文有限,而 HTML 充滿導覽列、廣告與腳本雜訊」這個問題。

它的格式刻意極簡,只有四個元素:一個 H1 寫網站或公司名稱;一段引言(blockquote)用一兩句話講清楚你是誰、做什麼;若干個 H2 分區,每區底下是「連結 + 一句說明」的清單;以及一個選擇性的 Optional 區塊,放次要資源。整份檔案通常一百行以內。

# Example Precision Co., Ltd.

> Taiwan-based manufacturer of CNC-machined components for
> medical and semiconductor equipment. Founded 1998. ISO 13485.

## Core pages
- [Capabilities](https://www.example.com/en/capabilities): equipment list, tolerances, materials
- [Quality](https://www.example.com/en/quality): certifications, inspection process
- [Contact](https://www.example.com/en/contact): RFQ form, lead times

## Guides
- [Material selection guide](https://www.example.com/en/blog/material-guide): stainless vs titanium

## Optional
- [Full text export](https://www.example.com/llms-full.txt)

實務上會做成兩個檔案:/llms.txt 是策展地圖(只放你最想被引用的頁面,依重要性與新鮮度排序),/llms-full.txt 是全文匯出(把主要頁面的純文字接在一起,讓模型一次拿完)。HappyCXO Studio 的網站兩個都有,而且 /llms.txt 的排序原則是「實體事實在前、時效性內容在後」。

這裡必須誠實講一句,因為網路上太多把 llms.txt 講成萬靈丹的內容:目前沒有任何一家主流 AI 供應商公開承諾會讀取 llms.txt,Google 也明確表示過不使用它。 它是一個社群提案,不是搜尋引擎標準。那為什麼還要做?三個理由:成本極低(一小時內可以生出來)、對人類與內部工具也有用(業務要找連結時它就是一份目錄)、以及如果未來任何一家開始讀它,你已經在名單上。把它定位成「便宜的保險」,而不是地基——地基永遠是 robots.txt、伺服器端算繪與結構化資料。

維護紀律比一次生成更重要。一份過期的 llms.txt 比沒有更糟:它會把模型導向已經下架的產品線或改過網址的頁面,反而製造錯誤資訊。實際做法是把「更新 llms.txt」寫進發布流程——每次新增服務頁或重要文章,同步加一行。如果你的網站是動態產生的,更好的做法是讓 llms.txt 由程式從 CMS 自動渲染,這樣它永遠不會過期。

最後一個常見錯誤:把 sitemap.xml 改個副檔名就當成 llms.txt。兩者目的完全不同——sitemap 是給爬蟲的完整 URL 清單,追求覆蓋率;llms.txt 是給模型的策展導覽,追求訊噪比。把三百個 URL 全部倒進 llms.txt,等於什麼都沒說。控制在二十到四十個連結,每個都附一句話說明,效果遠好過一份完整但無重點的清單。

結構化資料:Organization、Article、FAQPage 該怎麼標

先給答案:用 JSON-LD 標三層就夠了——全站一份 Organization(你是誰)、每篇文章一份 Article 或 BlogPosting(這頁在講什麼、誰寫的、何時更新)、有問答區的頁面加一份 FAQPage(問題與答案的配對)。 Google 明確建議使用 JSON-LD 格式,而不是散在 HTML 標籤裡的 microdata,詳見 Google 結構化資料說明。

Organization 是最重要卻最常被做壞的一份。它應該放在全站共用的版型裡,只出現一份,包含 name、url、logo、description、address、contactPoint,以及最關鍵的 sameAs——把你的 LinkedIn、Facebook、YouTube、甚至 Alibaba 商鋪網址列進去。sameAs 是實體消歧(entity disambiguation)的核心:它告訴 AI「網路上這幾個帳號是同一家公司」,讓分散在各處的訊號能被拼成同一個實體。完整的屬性清單在 schema.org 的 Organization 型別頁。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Precision Co., Ltd.",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "description": "CNC-machined components for medical and semiconductor equipment.",
  "sameAs": [
    "https://www.linkedin.com/company/example-precision",
    "https://www.youtube.com/@exampleprecision"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "sales@example.com",
    "availableLanguage": ["en", "zh-Hant"]
  }
}

Article / BlogPosting 用在每一篇內容頁,必填的是 headline、image、datePublished、dateModified、author 與 publisher。兩個實務重點:第一,author 用 Person 型別、寫真實的人名與職稱,比掛公司名更能支撐 E-E-A-T;第二,dateModified 要真的會動——很多網站的 dateModified 永遠等於發佈日,等於主動告訴 AI「這篇從沒更新過」。新鮮度是生成式引擎挑選來源時的重要訊號,一篇 2023 年寫的技術文章如果 2026 年還有效,你該做的是更新它並讓 dateModified 反映真實日期。

FAQPage 這裡有一個必須講清楚的細節:2023 年 8 月起,Google 大幅限縮了 FAQ 複合式搜尋結果的顯示範圍,實務上只保留給權威政府與衛生單位(Google 官方公告)。很多人因此得出「FAQPage 沒用了」的結論,這是錯的:Google 收回的是「在搜尋結果頁上展示成 rich result」的權利,而不是刪掉這份資料。生成式引擎解析的是頁面上實際存在的結構化資料,一組乾淨的「問題—答案」配對,仍然是最容易被擷取成答案的格式。用買家真正會打的問句當 question,答案自成一段、四到八題,是目前投報率最好的標記之一。

製造業還有幾個特別值得加的型別:Product 或 ProductGroup(把規格變成機器可讀的欄位)、BreadcrumbList(讓 AI 理解站內層級)、ItemList(產品列表頁)、以及 DefinedTermSet(術語表——我們把 HappyCXO 的行銷術語表 就是用這個型別標記的,它的 AI 引用價值意外地高,因為模型很喜歡引用定義)。schema.org 的詞彙表有數百種型別,不要全部上;挑「Google 有支援 + 對買家有意義」的那幾個就好,判斷標準可以參考 Moz 的結構化資料指南。

四個最常見的標記錯誤:一,標記的內容頁面上看不到——Google 的結構化資料政策明文禁止,嚴重時會被人工處罰;二,每一頁都放一份 Organization 而且內容互相矛盾(有的寫舊地址、有的寫舊電話),AI 拼不出一致實體;三,從別人的網站複製 JSON-LD 忘了改 URL 與公司名,結果幫競爭對手做標記;四,同一頁同時用 microdata 與 JSON-LD 標記同一件事,互相打架。這四個錯誤都不需要工程能力就能檢查出來,方法在最後一節。

伺服器端渲染 vs 純 JS:為什麼爬蟲看到空白頁

先給答案:如果你的產品規格是「頁面載入後,再用 JavaScript 打 API 抓資料填進去」,那麼不執行 JavaScript 的 AI 爬蟲看到的就是一個空殼。Googlebot 會執行 JavaScript,但必須排進二次「算繪佇列」處理;多數 AI 爬蟲則完全不執行。 這是三層漏斗裡最貴、也最決定天花板的一層。

Google 自己在 JavaScript SEO 基礎文件 裡把流程講得很清楚:抓取與算繪是分開的兩個階段,中間隔著一個佇列。對 Google 來說這只是延遲;對絕大多數 AI 爬蟲來說,這是直接失明——它們拿原始 HTML 就走,不會等你的 React 掛載完成。

三十秒就能自我診斷,不需要任何工具:

curl -s https://www.example.com/products/model-a | grep -c "型號"
curl -s https://www.example.com/products/model-a | wc -c

如果 grep 數到 0,或整份 HTML 只有兩三千個位元組(通常就是一個空的 div 加幾支 script),那你的內容對爬蟲而言就是不存在的。這個測試比任何 SEO 工具都準,因為它就是爬蟲實際拿到的東西。

解法依照成本由低到高:最理想是 SSR 或 SSG——Next.js、Nuxt、Astro 這類框架天生輸出完整 HTML;WordPress、Shopify、Wix 這些平台預設就是伺服器端輸出,反而通常沒問題。風險最高的是自製的 React/Vue 單頁應用(SPA),尤其是三五年前用 create-react-app 做的網站。如果整站重做不現實,退而求其次的做法是針對關鍵頁面(首頁、產品頁、能力頁)做預先算繪(prerender),把靜態 HTML 直接吐給爬蟲,其他頁面維持原狀。這件事的架構選型,我們在 外銷網站架設指南 有更完整的討論。

有幾個常被忽略的變形,一樣會造成內容看不見:客戶端分頁與無限捲動(第二頁以後的產品爬蟲永遠看不到,要補上真實的 URL 分頁連結)、tab 切換內容(如果三個 tab 的內容都在 HTML 裡、只是用 CSS 隱藏,沒問題;如果切換時才 fetch,就有問題)、以及彈窗式的規格表(點擊後才載入的內容等於不存在)。判斷原則永遠一樣:HTML 原始碼裡有沒有?沒有就是沒有。

還有一個相關但不同的問題:伺服器回應速度。爬蟲對每個網站的抓取都有預算,伺服器慢會直接壓低單位時間內被抓的頁數。如果你的產品頁首位元組時間(TTFB)動輒兩三秒,即使 HTML 是完整的,深層頁面也可能長期抓不完。這在把整份型錄放上網、頁數上千的製造業網站特別明顯。

規格藏在圖片裡 = AI 眼中不存在的內容

先給答案:規格表、認證編號、尺寸圖如果只存在於 JPG 或掃描版 PDF 裡,對文字型爬蟲而言等同不存在。把規格從圖片搬成 HTML 表格,是這整份清單裡投報率最高的單一動作。 它不需要改架構、不需要工程師,行銷或業務助理就能做。

台灣外銷製造業官網最常見的三種「內容黑洞」,我們幾乎每一次網站健檢都會遇到:第一,把整份規格表做成一張圖——三十個型號、十二個欄位,全部塞進一張 1200 像素寬的 JPG,人類要放大才看得清,爬蟲則什麼都拿不到。第二,型錄只提供 PDF 下載,而且是掃描版沒有文字層,連 PDF 本身都無法被檢索。第三,認證證書只有掃描圖檔,ISO 編號、有效期限、發證機構全都變成像素。

修法很直接:

• 規格改成 HTML 表格:每一列是一個型號,每一欄是一個參數(尺寸、材質、公差、扭力、認證)。表格的文字是可複製的,才是可被引用的。
• 圖片保留但補上有意義的 alt:alt 是寫給看不見畫面的人與機器的描述,不是關鍵字倉庫。「不鏽鋼六角螺栓 M8 x 40,DIN 933,A2-70」是好的 alt;「螺絲 螺栓 台灣製造 工廠 供應商」是壞的。
• PDF 至少要有文字層:用原生匯出取代掃描;更好的做法是在 HTML 頁面上重述 PDF 的重點,PDF 當作下載附件而不是唯一載體。
• 檔名語意化:model-a-spec-sheet.pdf 勝過 20240612_final_v3.pdf。

還有一個高階但影響很大的問題:型號命名的一致性。同一顆產品,官網寫「A-100」、型錄寫「A100」、Alibaba 商鋪寫「Model A 100 series」,對人來說沒差,對 AI 來說可能是三個不同的東西。實體(entity)要能被拼起來,命名必須一致——這和上一節 Organization schema 的 sameAs 是同一個道理:你要主動幫 AI 把分散的線索連成一條線,而不是期待它自己猜對。

再補一個第二層效應,很多人沒想到:把規格從圖片搬到 HTML,受益的不只是 AI,還有你的業務。規格變成文字之後,站內搜尋找得到、業務可以直接複製貼進報價信、客戶可以用 Ctrl+F 在頁面上找型號、翻譯成英文時不用重打一遍。我們看過最直接的效果是,規格表 HTML 化之後,詢盤裡「請問有沒有 XX 尺寸」這類本來就寫在圖上的問題明顯減少——因為買家自己找得到了。這是一個技術動作帶來的營運改善,不需要等 AI 引用才回本。

技術檢查表:做對 vs 常見錯誤(比較表)

先給答案:下面這張表把前面所有內容壓縮成可驗收的十二項。建議的用法是直接丟給你的網站廠商當驗收條件,或當成內部季度自檢的清單。 每一項都可以在十分鐘內驗證,不需要付費工具。

如果十二項一次做不完,優先序是:robots.txt 與 WAF(第一、二、三項)→ 算繪(第五、六項)→ 產品規格 HTML 化(第七項)→ Organization 與 Article schema(第九、十項)→ llms.txt 與其餘(第四項與後段)。理由回到那個相乘漏斗:前面幾項是零,後面做再多都乘不出東西來。

一個關於成本的重新框定:這張表上的十二項,沒有一項需要重做網站。多數是設定檔或版型層級的修改,估算下來大約是一到三個工作天的工程時間,加上規格 HTML 化的資料整理工時(視型號數量,通常是行銷或業務助理兩到五天)。相較於「重做一個網站」動輒六位數的報價,這是完全不同量級的投資——而且它是重做網站的前置條件,不是替代品。真的需要重做時,這十二項也應該直接寫進新網站的規格書。

怎麼驗證你做對了

先給答案:四個免費工具、十五分鐘就能驗完整輪——curl 模擬爬蟲身分、Google Rich Results Test 驗結構化資料、Schema Markup Validator 驗完整 JSON-LD、Search Console 的網址檢查看 Google 實際拿到的 HTML。 再加上伺服器日誌,你就有了唯一一組能證明「AI 爬蟲真的抓得到」的一手證據。

第一步,curl 模擬爬蟲。 這是最誠實的測試,因為它就是爬蟲拿到的原始回應:

curl -s -A "GPTBot" -o /dev/null -w "%{http_code}\n" https://www.example.com/
curl -s -A "ClaudeBot" https://www.example.com/products/model-a | wc -c
curl -s https://www.example.com/llms.txt | head -20
curl -s https://www.example.com/ | grep -c "application/ld+json"

四行分別驗:AI 爬蟲能不能拿到 200、頁面 HTML 有沒有實質內容、llms.txt 存不存在、頁面上有幾份 JSON-LD。任何一行結果不對,問題就在那一層。

第二步,Google Rich Results Test。 貼上網址,它會告訴你 Google 認得出哪些結構化資料型別、有沒有必填欄位缺漏。要注意它只驗 Google 有支援的型別,所以測不出的東西不代表錯,只代表 Google 不用它做 rich result。

第三步,Schema Markup Validator。 這支補上第二步的缺口:它驗的是完整的 schema.org 詞彙,包含 Google 不做 rich result 的型別。兩支一起跑,才是完整的結構化資料驗證。

第四步,Search Console 的「網址檢查」。 輸入網址 → 測試線上網址 → 查看已檢索的網頁 → HTML。這裡看到的是 Google 算繪後實際拿到的 HTML,是判斷 JavaScript 問題最權威的證據。如果這裡有內容但 curl 沒有,代表你依賴算繪;Google 撐得住,AI 爬蟲撐不住。

第五步,也是最少人做但最有價值的一步:看伺服器日誌或 CDN 分析。 搜尋 User-agent 含 GPTBot、ClaudeBot、PerplexityBot 的請求,看它們有沒有真的來、抓了哪些頁、拿到什麼狀態碼。這是唯一的一手資料——前面四步驗的是「應該可以」,日誌驗的是「實際上有」。如果日誌裡連續數週完全沒有 AI 爬蟲的紀錄,回頭查 WAF。

第六步,產出端驗證:直接去問 AI。 用買家真正會打的問句(不是你的品牌名)去問 ChatGPT、Perplexity 與 Google 的 AI 概覽,記錄有沒有提到你、引用了哪一頁。這一步慢、有雜訊、每次結果都不同,但它是唯一衡量最終目的的方法。相關的追蹤方法我們在 GEO 時代 B2B SEO 生存指南 有詳細拆解,而生成式 AI 使用規模的成長趨勢可以參考 Statista 的生成式 AI 統計專頁。

衡量上必須注意的兩個陷阱。 第一,先記基準線再動手:改動前先跑一輪完整驗證並存檔,否則三個月後你無法證明任何事情。第二,不要期待線性成長:AI 引用沒有官方的 Search Console,樣本小、每次生成都有隨機性,單次結果沒有意義,要看的是四到八週的趨勢,而且要用「日誌有沒有抓到」與「抽樣問答有沒有被提到」兩組資料交叉驗證。技術面的健康度改善通常在數週內就看得到(爬蟲來訪頻率上升、抓取錯誤下降),被引用率則慢得多。

建議的節奏是:上線後第一天跑完整六步,第七天再跑一次(看爬蟲有沒有回訪),之後每月一次快檢、每季一次完整檢查。 網站改版、換 CDN、換 CMS、加防火牆規則之後,一定要重跑——我們看過的技術倒退,超過一半是「別的專案順手改壞的」,而不是原本就沒做。

技術地基做完之後,下一步才是內容:用買家真正會問的問題當標題,把工程知識寫成 AI 願意引用的段落。更多同主題的文章在 網站 SEO 主題頁;如果你想先讓人幫你把上面十二項跑一遍再決定要不要動手,可以看 官網與 SEO 服務,或直接跟我們談談你的網站現況。

延伸閱讀:《讓 AI 讀懂你的規格頁:產品頁 AEO 指南》、《四大 AI 搜尋引擎比較:外銷廠商先攻哪個》