初始化平台
目前載入進度 0%
方案 6 / AI 旗艦分析

AI 旗艦分析報告

競品 GEO 實測與固定題庫 Baseline,建立可持續追蹤的比較基準

網站名稱
Aulait GEO Scorecard
網站網址
https://geo.aulait.ai
產出時間
2026-07-28 16:50:48 UTC+8
報告格式AI 分析報告中英文內容採同一版本配對發布

01. 網站現況與改善優先順序

管理者產品/營運

本章會先整理網站目前具備的優勢、可延續運用的基礎,以及現階段較明顯的內容與技術缺口,協助團隊快速掌握網站現況。並綜合各項檢查結果與現有證據提出整體判斷,說明哪些能力已相對完整、哪些問題可能影響使用者理解、搜尋與 AI 判讀或後續系統整合。

Aulait GEO Scorecard 已公開 Sitemap、Robots、Meta、JSON-LD 與 OpenAPI 等檢核說明,適合作為網站管理與開發團隊的基礎檢核工具。

整體判斷

網站已具備實用的教學與初步檢核基礎;若要支援穩定的自動化或正式系統串接,應先補齊 API 契約、結構化資料一致性與頁面可取得性。

已有基礎

Robots 與 Sitemap 可正常取得,基礎搜尋與爬蟲設定清楚。

六大檢核面向均有公開說明,方便團隊理解與執行。

Meta、JSON-LD 與 OpenAPI 皆有檢核說明,便於團隊進一步檢視內容與技術結構。

待補缺口

OpenAPI 多個操作缺少請求/回應 Schema、錯誤契約與 operationId,限制 SDK 與 AI 工具整合。

部分頁面抽樣取得失敗,JSON-LD 與 HTML 的實體關聯也不完全一致。

本次證據未提供其他可確認的主要缺口。

優先處理公開頁面內容無法穩定載入或顯示不足,造成首次評估失敗

使用者無法閱讀服務介紹、判斷可用性或完成註冊流程,直接阻斷轉換與信任建立。檢索時能看到主站路徑存在,但頁面內容未能取得或呈現不完整,顯示有可用性或部署問題。

接續改善服務範圍與適用對象說明分散且缺乏匯流導引

潛在使用者(如網站開發者、SEO/內容營運、企業法務)難以在短時間內判斷產品是否符合需求,導致高反彈與低試用率。網站包含多處「解說(explanations)」與「比較(comparison)」頁面,但缺乏明確的單一路徑或分級導覽,讓任務導向的訪客難以找到快速決策資訊。

後續補強方案與價格、試用/演示細節不透明或分散

商業採購與POC(概念驗證)需求會受阻;採購方/工程採用方無法快速估算成本與導入可行性。網站呈現有「Plans」與多個 demo 方案路徑,但公開頁面中未見易於比較的條款與試用說明,無法直接驗證差異化或限制條件。

驗證方式AI 可回答性

完整回答題數增加;以固定題庫重跑驗證。

改善優先順序

以下將各項改善工作依影響程度與執行難度進行分類與排序,協助團隊辨識適合立即處理、需要規劃投入、可於後續改善或暫時持續觀察的項目。團隊可根據排序結果安排執行順序與資源配置;若工作涉及跨部門協作、較長開發時程或額外預算,則建議另行規劃。實際執行順序仍可配合業務目標、現有排程與可投入資源彈性調整。

優先處理高影響/低難度
1

集中整理服務範圍與適用對象

影響:高難度:低預估工期:約 5–10 個工作天

負責:內容/產品

目前相關說明分散在多個頁面,使用者需要跨頁查找才能判斷服務是否符合需求。可先整合既有內容與入口導引,降低理解成本並改善首次瀏覽體驗。

規劃投入高影響/高難度
1

建立結構化資料與頁面治理流程

影響:高難度:高預估工期:約 4–8 週

負責:產品/內容

JSON-LD 與 HTML 呈現的實體關係仍不完全一致,可能讓搜尋系統無法確認頁面主體。這項工作需要先訂出共同欄位與發布檢查方式,再由內容與產品共同維護。

後續改善低影響/低難度
1

集中整理六面向說明

影響:中難度:低預估工期:約 1–2 週

負責:內容

六大面向已有公開說明,但入口分散,讀者必須跨頁整理才能掌握完整內容。可先集中導覽與共通說明,降低網站管理者查找與理解的時間。

持續觀察低影響/高難度
1

宣稱外部 AI 成效

影響:低難度:高預估工期:待證據後再評估

負責:管理/內容

本次沒有可重複驗證的外部成效基準,現階段無法確認相關主張。建議先持續觀察,等固定題庫或後續量測累積足夠結果後再評估。

02. 網站現況與主要問題

管理者產品/營運技術/SEO

本章依問題對使用者與營運的影響,整理目前最需要留意的網站風險,並列出每項判斷所依據的頁面與檢查結果。讀者可從處理順序、影響範圍及相關負責面向,先確認哪些問題需要優先釐清與改善。

處理順序問題影響與證據主要頁面或負責面向
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.example93.5%84.9%89.9%92.7%79.4%無法判定正常
Competitor Betahttps://beta.example97.5%90.4%88.4%92.7%95.2%無法判定正常
Competitor Gammahttps://gamma.example92.5%82.2%78.3%70.9%87.3%無法判定正常
六面向實測長條圖展開圖表
Aulait GEO Scorecard(目標網站)Competitor AlphaCompetitor BetaCompetitor Gamma
020406080100爬蟲規則100%93.5%97.5%92.5%網站地圖89%84.9%90.4%82.2%結構化資料81%89.9%88.4%78.3%Meta 標籤91.8%92.7%92.7%70.9%HTML 原始碼90.1%79.4%95.2%87.3%API 規格47.9%無法判定無法判定無法判定

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 回答是否更完整、穩定且有依據。

顯示 20/20 題
編號意圖可直接貼給 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. 網站內容尚無法回答的客戶問題

行銷/內容產品/營運

本章從服務與營運範圍、票價與優惠、司機與車隊服務,以及技術支援、安全與客服流程等面向,整理客戶可能會問、但網站尚未完整說明的問題。每一題都附上推論基礎,方便內容負責人回頭確認缺口來自資訊不存在、散落在不同頁面,或說明不夠明確。

顯示 12/12 題
編號客戶意圖應補齊的客戶問題推論基礎
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. 各類頁面的內容缺口

行銷/內容產品/營運技術/SEO

本章依首頁、乘客或個人產品頁、企業方案頁、政策頁與支援頁等不同頁型,逐一整理各頁應承擔的任務、目前已有內容及主要缺口。透過頁型檢查,團隊可以判斷哪些資訊應補在原頁面、哪些需要集中整理,也能了解本次檢查未涵蓋的動態或登入後內容。

頁型

首頁/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. 網站六大面向檢查結果

管理者技術/SEO產品/營運行銷/內容

本章集中呈現網站地圖、爬蟲規則、結構化資料、Meta 標籤、HTML 原始碼與 API 規格六大面向的檢查結果。除了分數,讀者還可以查看各面向已具備的基礎、目前難以回答的問題與整體判斷,了解每項技術缺口會影響哪些搜尋、分享、AI 讀取或系統整合情境。

爬蟲規則100%
網站地圖85%
結構化資料77%
Meta 標籤91%
HTML原始碼90%
API 規格55%
重點說明

爬蟲規則目前表現最好,API 規格則是下一輪最需要先確認的基礎面向。部分面向可能採不同批次資料,因此不合併成單一平均分數,請作為並列證據閱讀。

返回報告最上方

網站地圖診斷

管理者技術/SEO產品/營運行銷/內容
85%表現佳改善優先度:優

檢視 Sitemap 涵蓋與頁型入口。

較容易回答

官方內容已有支持

  • Sitemap 是否列出核心頁面?
  • 是否有更新訊號?
  • 是否能辨識主要頁型?
較難完整回答

比較與條件仍需集中

  • 是否完整涵蓋所有頁型?
  • 更新日期是否穩定維護?
  • 長尾頁型是否都有一致結構?
判斷展開

整體判斷:網站地圖具備基本可回答性,但完整性仍受抽樣範圍限制。

返回報告最上方

爬蟲規則診斷

管理者技術/SEO產品/營運行銷/內容
100%表現佳改善優先度:優

檢視 robots 規則對搜尋與 AI 爬蟲的影響。

較容易回答

官方內容已有支持

  • 搜尋爬蟲能否存取核心內容?
  • robots 是否提供基本存取規則?
  • 是否有 Sitemap 指引?
較難完整回答

比較與條件仍需集中

  • AI 爬蟲的使用界線是否完整?
  • 例外規則是否覆蓋所有路徑?
  • 未識別爬蟲是否有明確處理?
判斷展開

整體判斷:基本讀取規則可回答,細部規則仍需補充證據。

返回報告最上方

HTML 與頁面可讀性診斷

管理者技術/SEO產品/營運行銷/內容
90%表現佳改善優先度:優

檢視 HTML 結構與機器可讀性。

較容易回答

官方內容已有支持

  • 頁面是否有清楚主要內容?
  • 標題階層是否可辨識?
  • FAQ 問答是否容易擷取?
較難完整回答

比較與條件仍需集中

  • 各頁型是否都有一致語意結構?
  • 主要內容是否都位於穩定區塊?
  • 動態內容是否能穩定呈現?
判斷展開

整體判斷:HTML 可讀性已有基礎,跨頁型一致性仍是限制。

返回報告最上方

結構化資料診斷

管理者技術/SEO產品/營運行銷/內容
77%表現佳改善優先度:優

檢視結構化資料是否符合頁面內容。

較容易回答

官方內容已有支持

  • 是否有可辨識的品牌實體?
  • 是否有基本 WebSite 資訊?
  • 是否能辨識主要內容類型?
較難完整回答

比較與條件仍需集中

  • 品牌與各頁型的關係是否完整?
  • FAQ 與內容實體是否一致?
  • 所有重要頁面是否都有對應 Schema?
判斷展開

整體判斷:結構化資料提供部分可回答基礎,完整關係仍需驗證。

返回報告最上方

API 規格情境判讀

管理者技術/SEO產品/營運行銷/內容
55%良好改善優先度:良好

判斷 API/OpenAPI 證據與整合限制。

較容易回答

官方內容已有支持

  • 是否有公開 API 規格?
  • 公開內容是否可直接檢索?
  • API 主要服務情境是否清楚?
較難完整回答

比較與條件仍需集中

  • 認證與配額是否足以正式串接?
  • 即時或受控資料能否穩定取用?
  • 錯誤、版本與 SLA 是否完整?
判斷展開

整體判斷:API 情境可做初步判讀,正式串接細節仍需補證據。

返回報告最上方

14. 五項優先改善工作

管理者產品/營運行銷/內容技術/SEO

本章從整份報告中挑出最值得優先推進的五項工作,將問題轉成明確的交付內容。每項工作會交代需要處理的範圍、負責角色、完成條件與驗收方式,方便管理者確認資源,也讓執行團隊知道做到什麼程度才算完成。

01
交付行動

執行公開頁面初步可見度掃描

以 GEO Scorecard 提供的六大面向(robots、Sitemap、JSON‑LD、Meta、HTML、OpenAPI)對主站與 10 個關鍵頁執行自動掃描,目的是建立可比基線。必要條件為能存取公開頁面與一名技術窗口;驗收條件為發布含各面向分數與前 10 項優先修正的基線報告,並由內容與工程雙方確認。

02
交付行動

修正公開索引與結構化資料

針對掃描結果優先處理 robots 規則、補充或分割 sitemap 以明確曝光重要頁,並在關鍵頁新增或修正 JSON‑LD 與 meta 標籤,執行需 CMS 或工程改版權限與測試環境;驗收以自動重測通過且重要頁面能被正確抓取與摘要為準。

03
交付行動

發佈或優化 OpenAPI 以支援 Agent 呼叫

針對有 API 的產品頁或資料入口建立或校正 OpenAPI 規格,提供 server、path、security 與範例回應,使 AI Agent 能可靠呼叫與引用;需工程團隊提供端點與測試範例;驗收為公開的 OpenAPI 規格可被檢驗工具載入並通過 GEO 對 Agent 可行性的檢核。

04
交付行動

建立內容審核與引用準則

與內容、法務與 SEO 共同訂定頁面引用與版本標注流程,把 meta 與 JSON‑LD 欄位納入發稿檢查表並進行編輯培訓;需內容負責人同意並提供樣板;驗收為三篇樣板頁完成審核並通過自動化檢查,且審核紀錄可追溯。

05
交付行動

導入持續監測與月度回顧

建立每月自動掃描與報表排程,設定警示與分發名單,並將結果納入月度回顧會議,由工程與內容追蹤修正任務;必要條件為監測帳號與報表自動化;驗收為連續兩個月的自動報表與會議紀要,且會議產出可執行的修正項目清單。

返回報告最上方

15. 可直接執行的改善工作

產品/營運行銷/內容技術/SEO

本章把報告發現拆成可排入工作清單的改善項目,並列出優先順序、改善目標、相依條件與驗收標準。產品、內容、行銷與技術團隊可直接依表格分工與排程,後續也能用相同標準追蹤進度,避免改善建議停留在方向層次。

優先順序工作項目改善目標驗收條件
1補齊核心頁面回答降低主要問題的資訊缺口固定題庫可在官方頁面找到完整答案
2分離 HTML 與 Meta 規則避免診斷混淆兩類檢核可獨立通過
3校正結構化資料穩定實體關係Schema 驗證無阻斷錯誤
4整理 Sitemap提升頁型涵蓋可見性核心頁型均被列入且可取得
5建立量測基準支持前後比較固定條件完成首次紀錄
返回報告最上方

16. 改善計畫與執行順序

管理者產品/營運行銷/內容技術/SEO

本章依工作先後關係安排改善階段,說明各階段應完成的內容、驗收重點,以及需要哪些跨部門配合。讀者可以從中看出內容整理、技術調整與後續量測如何接續,並依現有排程、預算與可投入資源調整實際執行順序。

階段天數改善流程完成判定
短期1 天 ~ 30 天盤點並修正核心缺口,幫助團隊建立可執行基線提交基線報告並完成利害關係人確認
中期31 天 ~ 60 天完成主要內容與技術改善,降低後續維護工期優先項目完成並通過驗證
長期61 天 ~ 90 天建立持續監控與迭代流程,讓改善效益能被追蹤產出追蹤結果與下一輪清單

依賴條件與風險需由內容及工程負責人共同確認。

返回報告最上方

17. 改善成效的衡量方式

管理者產品/營運行銷/內容

本章定義改善後應追蹤的指標、計算方式、資料來源與檢查頻率,涵蓋內容完整性、AI 回答、使用者任務、客服及技術整合等面向。團隊需先建立基準,再以相同題庫、期間與測試條件重跑,才能合理比較改善前後的差異。

指標定義資料來源頻率
六面向技術分數固定規則下的量測結果Rule Engine每次發布與每月
可回答題數可由官方內容完整回答的固定題數固定題庫每月
官方引用狀態外部 AI 是否引用官方來源GEO Baseline每月
自助解題行為FAQ 與說明頁的完成行為網站分析每月

比較原則:使用相同題庫、語言、期間與執行條件;建立基準前不宣稱提升。

返回報告最上方