AI 旗艦分析報告
競品 GEO 實測與固定題庫 Baseline,建立可持續追蹤的比較基準
01. 網站現況與改善優先順序
本章會先整理網站目前具備的優勢、可延續運用的基礎,以及現階段較明顯的內容與技術缺口,協助團隊快速掌握網站現況。並綜合各項檢查結果與現有證據提出整體判斷,說明哪些能力已相對完整、哪些問題可能影響使用者理解、搜尋與 AI 判讀或後續系統整合。
整體判斷
網站已具備實用的教學與初步檢核基礎;若要支援穩定的自動化或正式系統串接,應先補齊 API 契約、結構化資料一致性與頁面可取得性。已有基礎
Robots 與 Sitemap 可正常取得,基礎搜尋與爬蟲設定清楚。六大檢核面向均有公開說明,方便團隊理解與執行。
Meta、JSON-LD 與 OpenAPI 皆有檢核說明,便於團隊進一步檢視內容與技術結構。
待補缺口
OpenAPI 多個操作缺少請求/回應 Schema、錯誤契約與 operationId,限制 SDK 與 AI 工具整合。部分頁面抽樣取得失敗,JSON-LD 與 HTML 的實體關聯也不完全一致。
本次證據未提供其他可確認的主要缺口。
使用者無法閱讀服務介紹、判斷可用性或完成註冊流程,直接阻斷轉換與信任建立。檢索時能看到主站路徑存在,但頁面內容未能取得或呈現不完整,顯示有可用性或部署問題。
潛在使用者(如網站開發者、SEO/內容營運、企業法務)難以在短時間內判斷產品是否符合需求,導致高反彈與低試用率。網站包含多處「解說(explanations)」與「比較(comparison)」頁面,但缺乏明確的單一路徑或分級導覽,讓任務導向的訪客難以找到快速決策資訊。
商業採購與POC(概念驗證)需求會受阻;採購方/工程採用方無法快速估算成本與導入可行性。網站呈現有「Plans」與多個 demo 方案路徑,但公開頁面中未見易於比較的條款與試用說明,無法直接驗證差異化或限制條件。
完整回答題數增加;以固定題庫重跑驗證。
改善優先順序
以下將各項改善工作依影響程度與執行難度進行分類與排序,協助團隊辨識適合立即處理、需要規劃投入、可於後續改善或暫時持續觀察的項目。團隊可根據排序結果安排執行順序與資源配置;若工作涉及跨部門協作、較長開發時程或額外預算,則建議另行規劃。實際執行順序仍可配合業務目標、現有排程與可投入資源彈性調整。
集中整理服務範圍與適用對象
負責:內容/產品
目前相關說明分散在多個頁面,使用者需要跨頁查找才能判斷服務是否符合需求。可先整合既有內容與入口導引,降低理解成本並改善首次瀏覽體驗。
建立結構化資料與頁面治理流程
負責:產品/內容
JSON-LD 與 HTML 呈現的實體關係仍不完全一致,可能讓搜尋系統無法確認頁面主體。這項工作需要先訂出共同欄位與發布檢查方式,再由內容與產品共同維護。
集中整理六面向說明
負責:內容
六大面向已有公開說明,但入口分散,讀者必須跨頁整理才能掌握完整內容。可先集中導覽與共通說明,降低網站管理者查找與理解的時間。
宣稱外部 AI 成效
負責:管理/內容
本次沒有可重複驗證的外部成效基準,現階段無法確認相關主張。建議先持續觀察,等固定題庫或後續量測累積足夠結果後再評估。
02. 網站現況與主要問題
本章依問題對使用者與營運的影響,整理目前最需要留意的網站風險,並列出每項判斷所依據的頁面與檢查結果。讀者可從處理順序、影響範圍及相關負責面向,先確認哪些問題需要優先釐清與改善。
| 處理順序 | 問題 | 影響與證據 | 主要頁面或負責面向 |
|---|---|---|---|
| 1 | 公開頁面內容無法穩定載入或顯示不足,造成首次評估失敗 | 使用者無法閱讀服務介紹、判斷可用性或完成註冊流程,直接阻斷轉換與信任建立。檢索時能看到主站路徑存在,但頁面內容未能取得或呈現不完整,顯示有可用性或部署問題。 | 首頁/Start |
| 2 | 服務範圍與適用對象說明分散且缺乏匯流導引 | 潛在使用者(如網站開發者、SEO/內容營運、企業法務)難以在短時間內判斷產品是否符合需求,導致高反彈與低試用率。網站包含多處「解說(explanations)」與「比較(comparison)」頁面,但缺乏明確的單一路徑或分級導覽,讓任務導向的訪客難以找到快速決策資訊。 | Explanations/Comparison |
| 3 | 方案與價格、試用/演示細節不透明或分散 | 商業採購與POC(概念驗證)需求會受阻;採購方/工程採用方無法快速估算成本與導入可行性。網站呈現有「Plans」與多個 demo 方案路徑,但公開頁面中未見易於比較的條款與試用說明,無法直接驗證差異化或限制條件。 | Plans/Demo 方案頁 |
| 4 | 技術整合文件與API說明可見但內容可驗證性不足,整合流程模糊 | 開發者與系統整合團隊在未取得清晰API規格、驗證範例與認證流程前,無法衡量整合成本與時程,延長採用週期。網站列有 OpenAPI / 技術解說路徑,但在本次檢索中未能取得完整可讀說明以供驗證。 | Explanations / OpenAPI |
03. 網站問題對客戶決策的影響
本章把網站問題放回客戶實際的決策流程,說明資訊分散、不完整或難以驗證時,會怎麼影響客戶認識品牌、理解服務、比較條件與採取行動。同時整理這些問題對轉換、客服與企業合作可能帶來的影響,讓團隊知道改善內容時應先處理哪一段決策障礙。
| 影響面向 | 目前證據 | 對客戶決策的影響 | 對成長的意義 |
|---|---|---|---|
| 品牌認知 | 核心服務與六面向已有公開說明 | 訪客可理解主要定位,但仍需整合價值主張 | 有助於建立一致認知,實際成效尚待量測 |
| 內容引用 | 技術說明已有主題基礎 | AI 可取得部分官方說明,但證據密度不一 | 可建立可引用內容,引用率尚待建立基準 |
| 比較決策 | 方案與功能資訊存在 | 條件分散時會增加比較成本 | 完整比較資訊可降低決策摩擦 |
| 服務效率 | FAQ 與說明頁提供部分自助資訊 | 常見問題仍有無法完整回答的情況 | 補齊答案後可再量測自助解題率 |
整體判讀:目前已有內容基礎,但所有成長效果均需以後續資料驗證。
04. 改善後的預期變化
本章整理各項改善完成後可觀察的變化,涵蓋乘客資訊、司機流程、優惠說明、車資透明度、企業合作及技術資料等面向。每項變化都搭配驗證方式,方便團隊區分可直接檢查的成果與仍需持續追蹤的成效,避免在尚未取得數據前先做保證。
| 改善方向 | 可觀察變化 | 驗證方式 |
|---|---|---|
| 資訊可理解性 | 核心答案更集中 | 內容稽核 |
| 機器可讀性 | 技術訊號更一致 | 六面向重跑 |
| AI 可回答性 | 完整回答題數增加 | 固定題庫重跑 |
| 持續維護 | 工作與量測可持續追蹤 | Backlog 與月報檢查 |
以上為可驗證的改善方向;實際結果仍受內容品質、搜尋需求與外部平台影響,不保證排名、流量、引用或營收。
05. 網站與競品的表現比較
本章以相同檢查面向比較 yoxi 與主要競品的爬蟲規則、網站地圖、結構化資料、Meta 標籤、HTML 原始碼與 API 規格。讀者可以看出 yoxi 目前相對領先或落後的項目,也能辨識因資料無法取得而不能直接下結論的部分,避免把缺少資料誤判為表現較差。
競品 GEO 比較
| 網站 | 爬蟲規則 | 網站地圖 | 結構化資料 | Meta 標籤 | HTML 原始碼 | API 規格 | 抓取狀態 |
|---|---|---|---|---|---|---|---|
| Aulait GEO Scorecardhttps://geo.aulait.ai目標網站 | 100% | 89% | 81% | 91.8% | 90.1% | 47.9% | 正常 |
| Competitor Alphahttps://alpha.example | 93.5% | 84.9% | 89.9% | 92.7% | 79.4% | 無法判定 | 正常 |
| Competitor Betahttps://beta.example | 97.5% | 90.4% | 88.4% | 92.7% | 95.2% | 無法判定 | 正常 |
| Competitor Gammahttps://gamma.example | 92.5% | 82.2% | 78.3% | 70.9% | 87.3% | 無法判定 | 正常 |
六面向實測長條圖展開圖表
Aulait(Aulait GEO Scorecard)在「對外可被機器程式化讀取的基礎設施」上表現明顯有利:官方網站公開說明六大面向(包含 OpenAPI、sitemap、robots、HTML 結構、meta 標籤、JSON‑LD),且實際可取得的 openapi.json 檔案顯示其把「API 與內容出口」作為可驗證的公開信號,這對需要被代理人或搜尋代理引用的網站是直接加分的商業設計(註:Rule Engine 的 openapi 分數為 47.9%)。官方也提供面向解釋頁與 FAQ,強調把診斷轉為可執行優化建議,對希望拿到可操作清單的企業很實用。
競品方面,Competitor Beta 明確主打整套 GEO 工具與付費服務(包含免費 GEO 檢測入口與付費版儀表板、追蹤與報表),適合需要長期追蹤與商業化執行的品牌客戶;它在 HTML 與 sitemap 等靜態技術面得分偏高(實測 HTML 95.2%、sitemap 90.4%),顯示其公開內容通常具備較完整的語意與索引目錄。Competitor Alpha強調 22 項指標的快速檢測與市場基準報表,對想快速量化「AI 可見度」並做橫向比較的中小團隊更友善。Competitor Gamma 的 GEO Scorecard 則定位在電商品牌的競爭分析,主打「與競品比較並給出可執行建議」,對電商/品牌行銷場景有明確吸引力。
相對弱項
Aulait 的弱點是其 openapi 分數僅 47.9%,意味著雖有公開規範與說明,但在「完整度或實作細緻度」上還有進步空間;而其他三家在公開文件層級未必提供可直接驗證的 OpenAPI(在公開頁面未見同等檔案),因此在不同使用情境下 Aulait 可能是唯一提供 API 信號的站點,但該信號尚未達到高分成熟度。官方文件將 OpenAPI 視作「代理可行動性」的訊號,但實務上只有公開且具完整定義的 API 才最有利於被複雜代理引用。
從內容呈現與元資料保守性看,Competitor Gamma 在 meta‑tags(70.9%)與 JSON‑LD(78.3%)的實測分數低於其他站,這表明其公開頁面在結構化標記層面未必最完整,對需要被大型語言模型直接摘用或引用來源片段的場景可能較不利;Competitor Alpha 與 Competitor Beta 在某些技術面(例如 HTML 或 sitemap)雖表現良好,但兩者的 OpenAPI 欄位為 null,按既定規則應視為「無法判定」,代表在以 API/交互能力為核心的整合需求上無法直接推斷可用性。競品的商業策略也造成限制:部分深度功能與報表必須付款或登入才能看到(例如 Competitor Beta 的付費儀表板與 Competitor Alpha 的企業服務),因此公開檢視只能觀察到平台定位與行銷說辭,無法完全驗證其運作細節。
判斷限制
本次比較以 Rule Engine 實測分數作為唯一技術量表,網路爬取的官方頁面僅用來補充各站的服務定位、功能說明與目標客群;因此所有技術分數皆不得修改或由我方解讀為不同數值。若某站的 openapi 欄位為 null,我們依指示視為「無法判定」而非零分。公開網站內容可能會因產品更新、付費功能上線或頁面改版而改變;我方引用的是各站公開說明(含工具頁、說明頁與新聞稿)作為商業脈絡證據,但未登入付費後台或執行私有 API,因此無法保證隱藏功能或企業整合能力。對於需要深度技術整合(例如:完整 OpenAPI 規格驗證、API token 流程、或企業級 SLA)建議進一步以試用帳號或官方技術對接文件進行現地驗證,因為公開行銷資料與實際產品實作間常有細節差異。
06. 20 題 AI 回答成效基準
本章整理 20 題固定題庫,涵蓋認知、問題解決、比較與決策等常見需求,並列出每題要觀察的網站資訊。這組題庫可作為改善前的回答基準,後續在相同條件下重測,才能判斷網站補強後,AI 回答是否更完整、穩定且有依據。
| 編號 | 意圖 | 可直接貼給 AI 的問題 | 官網核對重點 |
|---|---|---|---|
| Q01 | 認知 | GEO Scorecard 針對網站可被 AI 發現與引用的評估,包含哪些檢測面向? | 是否列出 robots、sitemap、JSON‑LD、meta tags、HTML 語意、OpenAPI 等六大面向 |
| Q02 | 認知 | 平台如何呈現檢測結果與優先改進項目(儀表板、分數、報表格式)? | 有無分數拆解、視覺化圖表、PDF/CSV 匯出或逐案建議欄位 |
| Q03 | 認知 | 使用者可以透過哪些方式提交網站或頁面以進行檢測? | 支援單一 URL、Sitemap、批次上傳或 API 呼叫的項目與限制 |
| Q04 | 認知 | 平台對技術標準的支援範圍與深度為何(例如 JSON‑LD 類型、OpenAPI 規格)? | 列出的標準清單、驗證規則、範例或測試案例是否可得 |
| Q05 | 認知 | 不同方案(含 demo)在功能、檢測頻率或輸出上有何差異? | 計畫頁是否列出方案差異、限制條件、試用範圍與額外付費項目 |
| Q06 | 問題解決 | 當 robots.txt 阻擋重要頁面時,建議採取的優先修正步驟為何? | 是否建議修改規則、測試工具、部署順序與重新掃描驗證流程 |
| Q07 | 問題解決 | 若大量文章缺乏結構化資料,如何在 CMS 中有效批次補回? | 是否提供模板、程式碼範例、批次套用或 CMS 插件建議 |
| Q08 | 問題解決 | 若 OpenAPI 端點無法正確被 AI agent 呼叫,排查順序應如何設計? | 檢查項目:規格一致性、認證、CORS、範例回應與錯誤碼紀錄 |
| Q09 | 問題解決 | 當 sitemap 與實際站內頁面不同步時,哪些同步策略最有效? | 是否建議自動產生、排程更新、lastmod 管理與提交機制 |
| Q10 | 問題解決 | 在不對外揭露敏感資料前提下,怎麼把測試範例交給平台做完整檢測? | 可提供的替代方案:staging、allowlist IP、匿名化樣本或部分授權 |
| Q11 | 比較 | 在 AI 可見性評估上,GEO 與傳統 SEO 工具的評估重點差異為何? | 是否以 AI 索引/Agent 可呼叫性為導向,或偏向傳統關鍵字/技術 SEO |
| Q12 | 比較 | GEO 的評分機制在透明度與權重揭露上與其他分數系統比較如何? | 是否公開權重、項目說明、範例計算或僅顯示單一綜合分數 |
| Q13 | 比較 | 平台的自動提示(自動修正建議)與人工診斷結果,哪類情境較適合自動化? | 有無自動修復建議範例、誤判風險說明與人工覆核流程 |
| Q14 | 比較 | 使用 API 批次提交與透過網頁介面逐一檢測,各自的優缺點為何? | 比較點:吞吐量、認證方式、速率限制、結果回傳格式 |
| Q15 | 比較 | 不同方案對報告頻率、資料留存與歷史紀錄的差異為何? | 是否列出保留期限、歷史比較功能與頻率(即時/定期/按需) |
| Q16 | 決策 | 評估導入此檢測服務時,應召集哪些內部單位共同審核? | 建議利害關係人:SEO/內容、開發/網管、產品、法務與資安 |
| Q17 | 決策 | 要將檢測流程納入 CI/CD,自動化需哪些 API 能力或 webhook? | 是否有公開 OpenAPI 規格、驗證方式、回傳狀態與 webhook 支援 |
| Q18 | 決策 | 如何在導入後 6 個月內衡量是否達到預期成效(建議 KPI)? | 可量化指標:可索引頁數變化、AI 來源被引用次數、處理時間減少 |
| Q19 | 決策 | 選定方案時,應要求哪些 SLA 與資料合規保證? | SLA 內容:可用率、回應時效、資料保留政策、隱私與存取控管 |
| Q20 | 決策 | 技術改造外包時,應要求供應商提供哪些可驗收的交付物? | 驗收項:檢測報告、修正清單與優先級、再掃描記錄、測試日誌 |
07. AI 可直接回答的網站資訊
本章依網站目前可取得的官方內容,區分 AI 已能直接回答的問題與仍難以完整回答的問題。除了列出問題,也會說明判斷所依據的內容與不足之處,讓團隊知道哪些資訊已具備引用基礎,哪些仍需集中整理合約、費用、合規、管理或技術整合資料。
官方內容已有支持
- 你們檢測哪些技術面向(例如 robots、sitemap、JSON‑LD、meta 標籤、HTML、OpenAPI)?
- 我要如何開始測試(啟動流程、需要準備哪些資料)?
- 有哪些定價方案或示範方案可以參考?
- 如何聯絡商務或技術支援?
比較與條件仍需集中
- 報告會交付可直接匯入工程系統的工單或優先矩陣嗎?
- 測試過程是否需要提供帳號或 API 金鑰?測試資料的保存期限與是否會與第三方共享?
- 不同方案的價格、每月檢測次數與配額怎麼比較?有無企業折扣或最低合約期?
- 是否提供 webhook、公開 API key 發放流程、CI/CD 範例或 SLA 保證?
判斷展開
整體判斷:被引用的準備程度:中;引用準備度:中低。
08. 網站內容尚無法回答的客戶問題
本章從服務與營運範圍、票價與優惠、司機與車隊服務,以及技術支援、安全與客服流程等面向,整理客戶可能會問、但網站尚未完整說明的問題。每一題都附上推論基礎,方便內容負責人回頭確認缺口來自資訊不存在、散落在不同頁面,或說明不夠明確。
| 編號 | 客戶意圖 | 應補齊的客戶問題 | 推論基礎 |
|---|---|---|---|
| M01 | 方案與價格透明度 | 各方案(包含 demo 分級)之間的功能差異與使用限制具體為何? | 檢索到「方案」與多個 demo 範例頁面,但無法完整讀取或驗證每一方案的功能清單與限制說明,導致無法確認可比較欄位。 |
| M02 | 方案與價格透明度 | 計費方式(按月/按年/按評估次數/按座位)與超額使用計算方式是否公開且可預估? | 網站上有「plans」與「comparison」導引頁,但現有公開描述未能明確呈現計費細節或超量政策(或該內容在頁面中未能被完整擷取)。 |
| M03 | 方案與價格透明度 | 是否提供免費試用、PoC 期間的資源限制(例如 API 呼叫上限、報告數)與試用轉正的條件? | 看到 demo 與 start 入口,但未能取得或確認試用條件與轉換流程的具體條款與技術限制。 |
| M04 | 評分方法與資料來源 | GEO Score 的演算法或評分指標有哪些?各指標的權重與更新頻率如何揭露? | 網站有「about」與「explanations」分類,推測與評分說明相關內容可能分散或摘要式呈現,且當前檢索未能取得完整方法論文件。 |
| M05 | 評分方法與資料來源 | 分數所用的地理與第三方資料來源清單、授權與更新策略是否可查(例如是否使用公開資料、商業授權、或客戶上傳資料)? | 雖見多個說明頁面(含 JSON-LD、meta-tags 等技術說明),但未能直接確認資料來源清單或授權條件的公開位置。 |
| M06 | 評分方法與資料來源 | 若客戶對某筆評分結果有異議,是否有可追溯的審核程序、修正時效與誰負責的聯絡窗口? | 站內有 FAQ 與 contact 頁面,但未找到或無法確認針對評分爭議的標準流程或 SLA 條款細節。 |
| M07 | 技術整合與輸出能力 | 是否提供機器可讀的 API(OpenAPI 規格)、範例請求/回應、以及 SDK 或範例程式碼? | 網站包含「explanations/openapi」頁面,但公開內容是否包含可下載或操作的 OpenAPI 規格檔與範例尚未能完整驗證。 |
| M08 | 技術整合與輸出能力 | 支援的資料上傳格式、報告導出格式(CSV/JSON/PDF)與自動化接入的限制為何?是否有大小或欄位規格? | 有多處技術說明類頁面(如 html/jsonld/meta-tags),但缺乏或無法擷取到明確的輸入/輸出格式與尺寸限制說明。 |
| M09 | 技術整合與輸出能力 | 系統整合的授權與安全要求(API 金鑰管理、角色權限、IP 白名單、SAML/SSO 支援)有哪些已被說明? | 網站提供隱私與條款頁面,但在公開技術文件中未明顯列出整合安全機制或因檢索受限而無法取得完整技術細節。 |
| M10 | 上線、支援與合規 | 客戶上線流程:時間表、所需交付物、驗收標準與成功交付的衡量指標為何? | 站內有 start 與 contact 等入口,顯示有上線流程導引,但具體時程和交付物說明未能完整讀取或明確化。 |
| M11 | 上線、支援與合規 | 支援與回應 SLA(例如回報後響應時間、嚴重等級判定、升級流程)如何定義?是否有商業合約範本可供下載? | 網站列出聯絡方式與常見問題,但未能確認有完整的支援等級與商業 SLA 文件公開。 |
| M12 | 上線、支援與合規 | 資料保留、刪除與合規(GDPR、CCPA、ISO/安全認證等)具體政策與客戶責任分界如何說明? | 隱私與條款頁面存在,但在目前檢索下,無法完整取得或驗證詳細的合規聲明與資料保留週期條款。 |
09. 建議優先補強的官方內容
本章盤點網站現有內容中,哪些資訊已具備成為官方引用來源的基礎,以及哪些主題值得優先補強。內容涵蓋服務定位、乘客與司機功能、企業方案、定價與限制、合規、多語系及技術資料,並提出可放回網站的具體補充方向。
服務定位與核心功能(GEO Scorecard 的目的與輸出)
強現有素材首頁與關於頁說明平台是「AI 搜尋 / AI 能見度(AI-readiness)檢測與建議」工具,指出目標是檢查網站能否被 AI 發現、理解與引用。已公開描述平台用途與價值主張。
建議將「可交付成果」具體化以便引用:列出輸出報表範例(欄位名稱、範例值)、可下載格式(PDF/JSON)、交付時間(例如:掃描即時 / 報告產生時間)與更新日期。若能附上典型報告範例截圖或樣本 JSON,引用就可立刻穩定發出。
六大面向評估(robots.txt、Sitemap、JSON‑LD、Meta、HTML 語意、OpenAPI)
中高現有素材有專門的「六大面向說明」頁與各面向單獨說明頁,內容解釋各訊號為何重要並提到評分標準與實作建議(例如 robots、sitemap、meta-tags、html、openapi 等)。
建議把每一面向的「可驗證判準」明確化並版本化:例如 robots 的判準(允許/拒絕哪些 user‑agent)、sitemap 的必檢欄位、JSON‑LD 必須出現的 schema 類型與最小屬性集、OpenAPI 的必檢項(servers、security、examples)。對每項列出可機器比對的檢核項(標準化檢核清單)與示例片段,以利第三方與 AI 系統穩定引用。
分數定義、用途與常見問題(Score 與 FAQ)
中現有素材FAQ 頁說明分數可作為 AI‑SEO / 技術理解度的診斷量表,並說明與搜尋成效資料搭配使用的建議;但現有說明較偏概念、未完整列出計分細則與權重。
建議公開並版本化「計分公式」與「指標權重」,或至少提供每個檢查項是否為必須、加分或資訊性。對外揭示最近一次模型或檢核規則更新日期。若不能公開全部算法,至少提供穩定的黑盒描述(例如:面向 A 佔總分 X%),並新增範例計算。這會大幅提高可被引用的信度。
API 與 OpenAPI 規格(機器可讀介面)
中現有素材網站公開了 OpenAPI 規格檔案並有說明 OpenAPI 對 Agent 可行動性的意義,顯示存在對外 API 或 demo 規範。
建議公開一份可下載且版本化的 OpenAPI 文件(含示例請求/回應與授權方式),並在文件首頁標註版本號與最後更新日。若目前為 demo/示範規格,明確標示「非正式」或「測試用」,並提供穩定的可驗證 endpoint 或 sandbox。這使第三方與 AI 能準確引用接口能力。
隱私、資料使用、與服務條款(資料提交、責任、付款)
中高現有素材已有隱私權政策與服務條款頁,包含電子郵件驗證、網站分析、付款與客服等處理說明,表明平台有列出資料使用與責任邊界。
建議將與報告相關的資料保留、刪除、與分享政策細節化;加入範例情境(例如:若用戶提交網站 A 的 URL,平台會保留哪些資料、保存多久、是否會用作模型訓練),並在條款或隱私頁加上最近更新日,供引用時確認法律與合規範圍。
計畫、價格與示範方案(Plans / Demo)
中低現有素材網站有 plans 分頁與多個 demo/plan 範例路徑(示意存在多種方案或 demo),但公開可讀的定價細節與每個方案的明確限制(例如 API 呼叫數、掃描次數、支援服務)無法完全判定。
建議公開每個方案的明確規格表:價格、包含檢測次數、API 呼叫配額、報告存取期限、支援 SLA。若因商業考量不能全面公開價格,至少提供「方案比較矩陣」與典型適用情境(小型網站 / 企業 / 代理商),並在方案頁標示最後更新日與試用限制,方便第三方穩定引用。
適用對象與案例(誰應該使用、客戶/合作夥伴)
中現有素材關於頁提到服務定位並示意與特定企業的關聯(示例合作夥伴或適用產業),但缺乏結構化案例研究或可驗證的客戶實例細節(例如:成效數據、前後比較)。
建議補充結構化案例研究(問題 → 措施 → 指標變化 → 時間),並提供經過同意的客戶名稱與可核對的 KPI。若無法公開客戶資料,提供匿名化但具體的範例數據與方法學,使引用者能驗證工具效用。
10. 網站內容的理解與比較缺口
本章從「服務是什麼、為什麼選擇、如何使用、如何比較、有哪些限制」等讀者常見的理解路徑,檢查網站提供的資訊是否足夠。讀者可以看出現有內容在哪些地方已能支持人工閱讀,以及哪些契約、費用、流程或機器可讀資料仍不足,因而影響比較與驗證。
| 面向 | 目前表現 | 診斷 |
|---|---|---|
| What | 良好 | 網站以「GEO Scorecard」為主題,提供線上檢測與說明頁(首頁、Start、Plans、FAQ、Comparisons、Explanations 等),並設有分級示範方案頁面供操作演示。已公開說明多項可檢測的項目(sitemap、robots、JSON-LD、meta 標籤、OpenAPI 等)。說明面向明確且有多個入口(首頁、說明集合、方案頁),直接告訴訪客服務範圍;但部分功能細節(輸入/輸出範例、產出格式)未在單一頁面完整呈現,降低一次性理解的便利性。 |
| Why | 良好 | 網站說明聚焦在網站索引品質、結構化資料與 API 文件可讀性,強調讓檢測結果可用於 SEO、索引與機器處理的判斷。部分說明頁解釋各檢測項目的意義與影響。動機與價值描述存在,但多為分散說明;網站有理由說明(為何要檢測),但未集中列出可量化的業務決策或適用場景(例如:合規、數據整合、SLA)。因此訪客需跨頁整合資訊才能完整理解為何採用該服務。 |
| How | 需關注 | 有「Start」入口與示範方案頁,顯示可上傳或輸入網站以獲取報告;同時有說明頁解釋各檢測方法(sitemap、robots、OpenAPI、JSON-LD 等)。不過公開的 API 文件說明(若存在)在操作層級(request/response schema、範例、錯誤契約)並非完整機器契約。流程敘述有,但缺少機器與整合端所需的契約細節(request/response 範例、error schema、operation-level security);使用者可理解「做甚麼」,但難以直接自動化或驗證整合流程。 |
| Who | 良好 | 目標對象顯性為網站管理員、SEO/内容團隊與開發者(有技術性說明頁與 demo plan),並提供聯絡與隱私/條款頁以供企業洽詢或合規查驗。對象陳述明確且有商業聯絡管道,但缺少針對不同規模組織的明確使用情境與案例說明(例如企業整合、代理商流程範例),讓決策者難以直接比對內部需求。 |
| When | 需關注 | 網站提供即時檢測入口(Start / demo plans),但未在常見位置顯示明確的服務 SLA、報告產出時程或資料保存期。部分說明頁有檢測描述,但缺少最後更新或版本標示。使用時效性敘述不足;訪客無法立即判斷執行檢測後需要等待多久、結果是否可重現或資料何時過期,影響採用決策與自動化排程。 |
| Alternatives | 良好 | 網站設有「Comparison」頁面,提供與其他方案比較的結構,但主要比較框架與細節多為內部或示範式呈現,未呈現完整競品清單或第三方驗證報告。存在比較工具與頁面,但缺少第三方驗證、獨立基準或實際案例數據作為替代方案評估的依據;訪客仍需自行與外部產品比對才可下定論。 |
| Comparison | 良好 | 比較頁面與多個 demo plan 展示不同功能分層;說明頁提供項目細分(sitemap、robots、schema 等),可做初步功能比對。網站內部能支援功能層級的比較,但比較標準偏向功能列舉而非可量化指標(例如 API 合約完整度、回應範例、rich result 支援度),對技術採購者仍不足以直接驗證落地可行性。 |
| Pros/Cons | 良好 | 優點:結構化說明頁面齊全、示範方案與聯絡資訊明確;robots 與 sitemap 檢測說明可取得。缺點:公開的機器可讀契約(OpenAPI schema、response/request 範例)、一致性的 JSON-LD 主體標註及 meta 重複處理說明不足。優缺點在頁面可被辨識;但缺失集中於自動化整合與可驗證性(機器契約與一致性檢核),直接影響能否將檢測納入 CI 或自動化流程。 |
| Evidence | 良好 | 已公開的證據包含首頁、功能/方案頁、說明集合與多個技術子頁(OpenAPI、JSON-LD、Sitemap、Robots 等說明頁),可被人讀取並部分支持核查;同時存在 demo plan 頁面供交互試用。證據來源分散且多為說明性文件;對於機器與自動化檢驗需求,關鍵證據(完整 response/request schema、範例、錯誤契約、lastmod 更新紀錄的一致呈現)並未集中提供,限制第三方驗證與自動化比對。 |
| Freshness | 需關注 | 說明頁與 demo 頁可見功能陳列,但在多數技術條目(例如 API、sitemap 更新時效、JSON-LD 版本)缺少明確的版本或最後更新時間標示;sitemap 與 robots 顯示存在但更新註記範圍與一致性未明。缺乏明確的更新時間戳或版本紀錄,讓使用者無法快速判斷資訊是否仍為最新或與其平台狀態相符;對企業採購與自動化同步造成疑慮。 |
| Machine Readability | 需關注 | 網站提供結構化資料(JSON-LD)與 OpenAPI 類說明頁,顯示有朝向機器可讀的意圖;但公開的 OpenAPI 部分缺少完整的 components.schemas、response/request schema、examples 與 operation 細節,且 JSON-LD 在主體一致性與 rich result 關鍵欄位上有說明不一致的風險。雖具建構基礎(JSON-LD、OpenAPI 文件存在),但缺乏完整的機器契約(schema、範例、錯誤回應、operation-level security)以及 JSON-LD 主體一致性保護,導致自動化 agent、SDK 或第三方系統難以可靠消費或做為真實世界決策來源。 |
- 建立並公開機器可驗證的 API 契約(完整 components.schemas、response/request schema、範例與錯誤回應):當前文件缺少這些要素,阻礙 SDK/agent 自動化整合與第三方驗證。理由:雖有 OpenAPI 說明頁,但缺少機器友好的 schema 與例子,無法直接程式化使用。
- 集中呈現報告輸入/輸出樣本與可下載格式說明(包含範例報告、欄位定義、資料保存期):理由:訪客與機器需樣本以比較、驗證與自動化匯入,但目前需跨多頁整合資訊,且缺少可下載範本。
- 明確標示版本與更新時間(尤其在 OpenAPI、JSON-LD 與 sitemap 相關頁面):理由:缺乏時間戳或版本紀錄會使企業與自動化流程無法判斷資訊新舊與相容性。
- 修正 JSON-LD 主體一致性與 rich result 必要欄位的說明(集中示例並對齊 HTML meta):理由:現有 JSON-LD 說明顯示主體標註可能不一致,會影響搜尋引擎與知識圖譜的可辨識性。
- 在比較頁或 FAQ 中加入可量化比較指標與第三方驗證/案例(例如:覆蓋頁面數、檢測頻率、平均處理時間):理由:現有比較偏向功能列舉,缺乏量化指標使技術採購者難以直接判斷效能與投入產出比。
11. 各類頁面的內容缺口
本章依首頁、乘客或個人產品頁、企業方案頁、政策頁與支援頁等不同頁型,逐一整理各頁應承擔的任務、目前已有內容及主要缺口。透過頁型檢查,團隊可以判斷哪些資訊應補在原頁面、哪些需要集中整理,也能了解本次檢查未涵蓋的動態或登入後內容。
首頁/Landing
以「AI SEO 與網站索引分析平台」定位,宣稱協助檢核網站能否被 AI 發現、正確理解並被引用為可信來源;內容導向檢測與說明而非顯性展示完整計費或整套客戶流程。
- 直接證據
- Aulait GEO Scorecard
- 主要缺口
- AI SEO 與網站索引分析平台.
- 判斷限制
- 未能確認首頁是否直接提供付費方案摘要、立即執行的掃描按鈕或註冊/上傳流程入口,使用者如何從檢測到付費或落地執行路徑不明。
關於(About)
說明以「從分析走向可執行的 AI-ready 優化」為任務,目標為協助企業評估被 AI 理解與引用的能力,並提出具體可執行的建議。內容側重方法論與價值主張。
- 直接證據
- 關於我們
- 主要缺口
- GEO Scorecard.
- 判斷限制
- 無法確認是否有具名客戶案例、實際成效數據或技術合作夥伴清單;社會驗證與商業案例透明度不足。
說明總覽(Explanations index)
提供「六大面向」教學/評估路徑(robots.txt、Sitemap、JSON-LD、Meta 標籤、HTML 語意、OpenAPI),說明各項對 AI 檢索與引用的重要性。內容以教育與評估準則為主。
- 直接證據
- 六大面向說明
- 主要缺口
- GEO Scorecard.
- 判斷限制
- 雖有完整面向列舉,但無法判定該索引頁是否連結到可執行的在線掃描工具或僅為文字說明;也不明確標示每面向的檢測深度或權重。
說明:robots.txt
解釋 robots.txt 為公開抓取邊界的第一層入口,會影響能否被抓取、是否能完整渲染與外部系統理解。內容以合規與發現度為評估重點。
- 直接證據
- robots.txt 與網站發現度 / robots.txt 合規
- 主要缺口
- Aulait GEO Scorecard.
- 判斷限制
- 無法判定是否提供對目標站點的實時 robots.txt 掃描、差異比對或修正建議產出;也不清楚是否檢查 Crawl-delay、sitemap 指向等細節。
說明:Sitemap
說明 sitemap.xml 對內容發現效率與更新訊號的影響,視為對搜尋引擎與 AI 系統提交的正式頁面目錄。
- 直接證據
- Sitemap 完整度
- 主要缺口
- Aulait GEO Scorecard.
- 判斷限制
- 未見明確證據指出是否會驗證 sitemap 的格式正確性、URL 數量限制、lastmod/use of priority 等欄位或提供修正建議。
說明:Meta 標籤
將 Meta Tags 定義為頁面給搜尋引擎與 AI 的第一層說明,強調其對主題辨識與摘要生成的影響。
- 直接證據
- Meta 標籤品質
- 主要缺口
- Aulait GEO Scorecard.
- 判斷限制
- 無法確認是否同時檢查社群分享 meta(og:、twitter:)、title/description 長度、重複性或語言標記等具體指標。
說明:HTML 語意
強調 HTML 結構對 AI 與搜尋系統理解內容的基礎作用,關注內容是否為人可讀且可供機器推論的骨架。
- 直接證據
- HTML 語意
- 主要缺口
- Aulait GEO Scorecard
- 判斷限制
- HTML 語意.
說明:OpenAPI / Agent 可行動性
說明 OpenAPI 能將服務能力以機器可讀方式表述,對成為 AI 生成回答的資訊來源有幫助。公開規格檔包含標題與說明,且註記為示範(demo/Manual OpenAPI specification aligned with the current Next.js APIs for demo)。
- 直接證據
- Agent 可行動性
- 主要缺口
- GEO Scorecard - geo.aulait.ai; "GEO Scorecard Public API" (OpenAPI spec info).
- 判斷限制
- 規格檔註記為 demo;無法確認該 API 是否為公開可用且具 SLA 的生產端點,或僅作為展示用途。缺乏完整 endpoint 列表、使用範例與認證流程說明的可視證據。
常見問題(FAQ)
明確說明 GEO Scorecard 的分數可被視為一套針對 AI SEO 與技術理解度的診斷量表,建議將基礎面檢核結果與實際搜尋成效資料一起使用。
- 直接證據
- FAQ 說明
- 主要缺口
- GEO Scorecard.
- 判斷限制
- 無法確認分數對應的優先處理項目、時間線或可交付成果;也未見 SLA 或顧問服務層級的明確說明。
隱私與條款(Privacy / Terms)
隱私政策提到電子郵件驗證、網站分析、訂單付款與客服聯繫等資料處理;服務條款概述使用方式、付款安排、資料提交規則與責任邊界。
- 直接證據
- 隱私權政策
- 主要缺口
- GEO Scorecard; 服務條款
- 判斷限制
- GEO Scorecard.
12. 各類頁面的改寫範例
本章以現有頁面為例,示範如何重整說明順序、補足必要條件,讓使用者更快找到操作方式、費用限制與服務差異。每個範例也會標示可直接採用的內容、仍需查證的資訊,以及需要產品、法務或技術確認的部分,避免把示意文字直接當成已核定文案。
| 頁型 | 目前內容問題 | 改寫示意 | 證據界線 |
|---|---|---|---|
| 首頁 | 服務價值較分散 | 以一段話說明評估對象、六面向與報告用途 | 不加入未公開成效 |
| 方案頁 | 比較條件需跨區塊閱讀 | 先列適用對象,再列交付內容與限制 | 價格與承諾以正式方案為準 |
13. 網站六大面向檢查結果
本章集中呈現網站地圖、爬蟲規則、結構化資料、Meta 標籤、HTML 原始碼與 API 規格六大面向的檢查結果。除了分數,讀者還可以查看各面向已具備的基礎、目前難以回答的問題與整體判斷,了解每項技術缺口會影響哪些搜尋、分享、AI 讀取或系統整合情境。
爬蟲規則目前表現最好,API 規格則是下一輪最需要先確認的基礎面向。部分面向可能採不同批次資料,因此不合併成單一平均分數,請作為並列證據閱讀。
網站地圖診斷
檢視 Sitemap 涵蓋與頁型入口。
官方內容已有支持
- Sitemap 是否列出核心頁面?
- 是否有更新訊號?
- 是否能辨識主要頁型?
比較與條件仍需集中
- 是否完整涵蓋所有頁型?
- 更新日期是否穩定維護?
- 長尾頁型是否都有一致結構?
判斷展開
整體判斷:網站地圖具備基本可回答性,但完整性仍受抽樣範圍限制。
爬蟲規則診斷
檢視 robots 規則對搜尋與 AI 爬蟲的影響。
官方內容已有支持
- 搜尋爬蟲能否存取核心內容?
- robots 是否提供基本存取規則?
- 是否有 Sitemap 指引?
比較與條件仍需集中
- AI 爬蟲的使用界線是否完整?
- 例外規則是否覆蓋所有路徑?
- 未識別爬蟲是否有明確處理?
判斷展開
整體判斷:基本讀取規則可回答,細部規則仍需補充證據。
HTML 與頁面可讀性診斷
檢視 HTML 結構與機器可讀性。
官方內容已有支持
- 頁面是否有清楚主要內容?
- 標題階層是否可辨識?
- FAQ 問答是否容易擷取?
比較與條件仍需集中
- 各頁型是否都有一致語意結構?
- 主要內容是否都位於穩定區塊?
- 動態內容是否能穩定呈現?
判斷展開
整體判斷:HTML 可讀性已有基礎,跨頁型一致性仍是限制。
結構化資料診斷
檢視結構化資料是否符合頁面內容。
官方內容已有支持
- 是否有可辨識的品牌實體?
- 是否有基本 WebSite 資訊?
- 是否能辨識主要內容類型?
比較與條件仍需集中
- 品牌與各頁型的關係是否完整?
- FAQ 與內容實體是否一致?
- 所有重要頁面是否都有對應 Schema?
判斷展開
整體判斷:結構化資料提供部分可回答基礎,完整關係仍需驗證。
API 規格情境判讀
判斷 API/OpenAPI 證據與整合限制。
官方內容已有支持
- 是否有公開 API 規格?
- 公開內容是否可直接檢索?
- API 主要服務情境是否清楚?
比較與條件仍需集中
- 認證與配額是否足以正式串接?
- 即時或受控資料能否穩定取用?
- 錯誤、版本與 SLA 是否完整?
判斷展開
整體判斷:API 情境可做初步判讀,正式串接細節仍需補證據。
15. 可直接執行的改善工作
本章把報告發現拆成可排入工作清單的改善項目,並列出優先順序、改善目標、相依條件與驗收標準。產品、內容、行銷與技術團隊可直接依表格分工與排程,後續也能用相同標準追蹤進度,避免改善建議停留在方向層次。
| 優先順序 | 工作項目 | 改善目標 | 驗收條件 |
|---|---|---|---|
| 1 | 補齊核心頁面回答 | 降低主要問題的資訊缺口 | 固定題庫可在官方頁面找到完整答案 |
| 2 | 分離 HTML 與 Meta 規則 | 避免診斷混淆 | 兩類檢核可獨立通過 |
| 3 | 校正結構化資料 | 穩定實體關係 | Schema 驗證無阻斷錯誤 |
| 4 | 整理 Sitemap | 提升頁型涵蓋可見性 | 核心頁型均被列入且可取得 |
| 5 | 建立量測基準 | 支持前後比較 | 固定條件完成首次紀錄 |
16. 改善計畫與執行順序
本章依工作先後關係安排改善階段,說明各階段應完成的內容、驗收重點,以及需要哪些跨部門配合。讀者可以從中看出內容整理、技術調整與後續量測如何接續,並依現有排程、預算與可投入資源調整實際執行順序。
| 階段 | 天數 | 改善流程 | 完成判定 |
|---|---|---|---|
| 短期 | 1 天 ~ 30 天 | 盤點並修正核心缺口,幫助團隊建立可執行基線 | 提交基線報告並完成利害關係人確認 |
| 中期 | 31 天 ~ 60 天 | 完成主要內容與技術改善,降低後續維護工期 | 優先項目完成並通過驗證 |
| 長期 | 61 天 ~ 90 天 | 建立持續監控與迭代流程,讓改善效益能被追蹤 | 產出追蹤結果與下一輪清單 |
依賴條件與風險需由內容及工程負責人共同確認。
17. 改善成效的衡量方式
本章定義改善後應追蹤的指標、計算方式、資料來源與檢查頻率,涵蓋內容完整性、AI 回答、使用者任務、客服及技術整合等面向。團隊需先建立基準,再以相同題庫、期間與測試條件重跑,才能合理比較改善前後的差異。
| 指標 | 定義 | 資料來源 | 頻率 |
|---|---|---|---|
| 六面向技術分數 | 固定規則下的量測結果 | Rule Engine | 每次發布與每月 |
| 可回答題數 | 可由官方內容完整回答的固定題數 | 固定題庫 | 每月 |
| 官方引用狀態 | 外部 AI 是否引用官方來源 | GEO Baseline | 每月 |
| 自助解題行為 | FAQ 與說明頁的完成行為 | 網站分析 | 每月 |
比較原則:使用相同題庫、語言、期間與執行條件;建立基準前不宣稱提升。