從免費工具起步，打造持續優化 SEO 與 GEO 的網站

聊天訊息連接產品網站、行為分析與搜尋資料，報告和行事曆構成持續檢視的循環

概念插圖：從聊天任務到網站交付，再到定期分析與改進；不代表產品實際介面或成長成果。

產品網站上線後，團隊還有一連串工作：檢查頁面能否正常開啟、確認按鈕點擊是否有記錄、了解訪客從哪裡來，以及決定下一次要改進什麼。

這些資訊分散在部署平台、分析工具與搜尋後台。團隊需要把資料放在一起，再將分析結果轉化為具體修改。

這個 Slack 情境從一則建站請求開始。使用者請 Leina 建立產品介紹網站，同時串接流量分析與搜尋資料。網站上線後，又追加了一個目標：定期分析網站表現，並以付費轉換為目標持續改進。

整個過程串起三個應用程式：Vercel 負責部署、PostHog 記錄站內行為、Google Search Console 提供搜尋成效資料。Leina 在聊天中接收任務，使用已授權的應用程式，再將結果送回同一段對話。

本文將原始 Leina 錄影案例改寫為 Slack 使用情境；原始示範使用飛書（Feishu），下文的實作結果仍以該示範為依據。

免費工具可以節省哪些成本？

PostHog 提供免費額度，Google Search Console 可免費使用。Vercel Hobby 僅供個人非商業用途，商業產品網站須選擇允許商業使用的方案。免費工具起步是指運用適用的免費服務與額度；Leina、網域與超額用量等費用仍須分別確認。

先說清楚網站與資料需求

使用者先在 Leina 控制台連接 Vercel、PostHog 和 Google Search Console，再回到 Slack 交辦工作。將錄影中的請求整理後，可以表達為：

我已經連接 Vercel、PostHog 和 Google Search Console。請建立一個 Leina 產品介紹網站，包含首頁、價格頁、功能頁與部落格。使用 PostHog 收集點擊資料、建立報表，並串接 Google Search Console，支援後續 SEO 分析。

這個請求同時說明頁面範圍、使用的應用程式，以及上線後的資料需求。交付標準因此包含三部分：網站可以存取、重要操作有記錄、後續分析有明確的資料來源。

案例中的網站部署在 Vercel 的示範網域上，用於介紹 Leina 產品。網站也註明價格與功能以官方資訊為準，讓讀者能區分示範內容與正式產品資訊。

三個應用程式，各自提供一部分資訊

連接這三個應用程式後，可以從不同角度檢視同一個網站。

應用程式	在流程中的用途	團隊可以檢查什麼
Vercel	部署網站，查看部署狀態與網址	頁面是否上線，修改是否已發布
PostHog	記錄瀏覽、按鈕點擊與閱讀行為，建立儀表板	訪客看了哪些頁面，在哪裡繼續操作或離開
Google Search Console	驗證網站，查看搜尋成效與索引資訊	是否已有可分析的搜尋資料，哪些頁面需要關注

這些連線讓 Leina 能使用任務所需的工具。實際可執行的操作，仍取決於帳號、專案與授權範圍。連線方式可參考如何安全連接業務應用程式（簡體中文）。

從 Slack 任務到網站與資料

flowchart TB
  accTitle: 從 Slack 任務到網站與資料
  accDescr: 團隊在 Slack 交辦任務，Leina 透過授權連線使用 Vercel、PostHog 和 Google Search Console，再把結果送回 Slack。
  C("Slack
交辦任務與接收結果"):::channel <--> L("Leina"):::agent
  L --> A("已授權的應用程式連線"):::gateway
  A --> V("Vercel
部署網站"):::resource
  A --> P("PostHog
站內行為"):::resource
  A --> G("Google Search Console
搜尋成效"):::resource

Slack 承接任務與結果；Leina 透過已授權的連線使用部署、站內行為與搜尋資料功能。

網站上線時，一起交付可核對的結果

錄影中的交付回覆顯示，Leina 回報已部署 8 個頁面，並檢查每個頁面都回傳正常的 HTTP 200 狀態。後續畫面展示了可開啟的產品頁面，以及 Vercel 中標示為 Ready 的部署。

回覆也列出搜尋相關的基礎設定：頁面標題與描述、標準網址、社群分享中繼資料、結構化資料、robots.txt、網站地圖，以及文章之間的內部連結。

這些項目讓後續檢查有明確依據。團隊可以逐項核對頁面網址、部署紀錄與設定清單，並在下一次修改後重複檢查。

頁面與事件追蹤一起驗收

資料收集也在這次交付範圍內。錄影展示的 PostHog 儀表板包含瀏覽趨勢、頁面排行、主要行動按鈕（CTA）點擊、內部連結點擊、文章閱讀深度、常見問題展開、流量來源與裝置分布等指標。Leina 回報建立了 11 個報表，並透過瀏覽器操作確認事件有送達。

這是一個實用的交付標準：除了確認頁面能開啟，也要確認使用者操作會出現在分析工具裡。

例如，點擊「查看價格」後，是否出現對應事件？瀏覽部落格後，能否辨識頁面路徑與閱讀行為？通過這些檢查，團隊才有條件進一步分析網站表現。

錄影中的初始瀏覽與點擊資料來自驗收操作，能證明資料收集流程已有事件進入。要評估真實訪客的轉換情況，仍需要後續營運資料。

把網站擁有者需要參與的步驟留在流程裡

串接 Google Search Console 時，案例遇到一個前置條件：網站尚未完成擁有權驗證，當時的授權範圍也無法直接完成相關操作。

Leina 在對話中說明狀態，並列出需要使用者配合的步驟：在 Search Console 取得 HTML 驗證標記，交給 Leina 寫入頁面並重新部署，再回到 Google 後台完成驗證。

這讓使用者清楚知道工作停在哪裡，以及下一步由誰完成。後續錄影進入 Search Console 的資料頁面，介面仍提示資料正在處理，部分指標的使用資料也不足。

這個階段的成果，是建立收集與檢查資料的基礎。搜尋資料需要隨網站被瀏覽、檢索與處理逐步累積；初期報告也應如實說明可用資料與缺口。

把定期檢視變成具體任務

網站上線後，使用者在 Slack 追加目標：

請每兩週產出一次 SEO 與點擊分析報告，根據報告優化網站。我的目標是盡可能提高付費轉換。

這將工作從一次性交付延伸到持續營運。接下來需要確定：每次查看哪些資料、報告送到哪裡，以及 Leina 可以進行哪些修改。

錄影最後展示了已啟用的 SEO 與轉換報告任務。實際排程為每月 1 日與 15 日上午 10 點，也就是每月兩次。若需要嚴格每隔 14 天執行，設定時應明確說明，並確認使用的時區。

任務設定包含以下步驟：

讀取 Search Console 與 PostHog 的相關資料。
產出包含當期表現與分析結果的 PDF 報告。
依預設條件檢查改善項目，在授權範圍內進行有限修改。
部署修改，檢查相關頁面與事件傳送情況，並保留紀錄。
將摘要與報告送回原本的 Slack 對話。

任務畫面證明排程已建立。錄影沒有展示多個週期的執行成效，後續仍需透過執行紀錄與實際資料評估修改是否有效。

從定期分析到下一輪改進

flowchart TB
  accTitle: 從定期分析到下一輪改進
  accDescr: 排程任務收集搜尋與行為資料，資料不足時回報原因，否則分析並判斷是否修改；修改後部署驗證、留下紀錄，再把報告送回 Slack 並等待下一週期。
  T("排程觸發"):::channel --> D("收集搜尋與行為資料"):::resource
  D --> Q{"資料足夠？"}:::gateway
  Q -->|否| N("說明資料缺口與原因"):::restricted
  Q -->|是| R("分析表現
準備報告"):::agent
  R --> J{"符合修改條件？"}:::gateway
  J -->|是| E("範圍內修改
每期最多兩處"):::agent
  E --> V("部署與驗證
記錄修改與還原方式"):::resource
  J -->|否| H("摘要與報告
送回 Slack"):::channel
  V --> H
  N --> H
  H --> W("等待下一週期"):::channel
  W -.-> T

依任務設定定期檢視：資料不足時說明原因，符合條件時才在約定範圍內修改。

為每次優化設定明確範圍

案例將每期修改限制為最多兩處，允許調整標題、描述、CTA 文案、內部連結與社群分享中繼資料。每次修改都要記錄原因、預期效果與驗證方式。

價格、功能與支援平台等產品事實須以官方資訊為準；網站驗證標記與歸因參數也需要保留。修改完成後，要檢查部署及頁面存取狀況，並在報告中說明還原方式。

這些約定方便團隊追蹤每次變化：改了哪個標題、為什麼調整按鈕，以及下期應觀察哪個指標。

錄影中的判斷門檻屬於這次任務的設定。其他網站需要依流量、頁面用途與資料量設定條件，並先區分測試操作和真實訪客行為，再決定是否據此修改。

把付費目標延伸到網站之外

使用者希望提高付費轉換，而產品介紹網站直接記錄到的主要是瀏覽、點擊與跳轉。註冊與付款發生在後續的業務系統。

Leina 在交付回覆中表示，已為 CTA 連結加入 UTM 參數，以區分流量來源與按鈕位置。這為後續追蹤保留線索：訪客是從首頁、功能頁、價格頁，還是某篇文章進入。

要回答「哪個入口帶來付費客戶」，後續系統還需要保留這些參數，並與註冊、付款事件建立關聯。錄影展示了歸因準備，沒有展示完整的付費資料串接或轉換提升成果。

團隊可以分階段驗證：先確認瀏覽與點擊有記錄，再確認來源資訊能傳入業務系統，最後以相關的註冊與付費結果評估網站調整。

從定期 SEO 優化延伸到 GEO

SEO 著重搜尋能見度；GEO（生成式引擎優化）則關注內容能否在 AI 回答中被正確理解、提及與引用。兩者可共用部分內容與技術基礎；Google 的說明指出，基本 SEO 做法仍適用於 Google 搜尋的 AI 功能。

可以在這套流程中加入 GEO 檢查：依客戶常見問題改善頁面，補充可驗證的產品事實與來源，並定期以固定問題記錄品牌提及、引用頁面和回答正確性。將這些紀錄與網站行為資料一起檢視，再決定下一輪內容修改。

這是建議延伸的流程。原始影片展示 SEO、點擊分析與排程設定，沒有展示 GEO 監測或 AI 引用成長；驗證 GEO 成效仍需要增加相應的資料來源與檢查步驟。

從一次可驗收的交付開始

這個流程將網站建立、部署檢查、分析與定期檢視帶回團隊原本的對話。使用者在 Slack 說明目標，在授權或網站驗證需要協助時參與操作，並在同一處接收結果。

如果要用在自己的產品網站，可以從以下請求開始：

檢查產品網站的部署狀態、重要頁面與事件追蹤。根據已授權的搜尋與行為資料，先產出一份分析報告，列出來源、資料不足之處，以及最值得處理的兩個問題。確認報告後，再依約定頻率執行，並明確列出每次允許修改的範圍與驗證步驟。

先讓一次交付可以核對，再將驗證過的步驟排入固定任務。團隊就能依據同一組頁面、資料與業務目標，持續推進下一次改進。

進一步了解團隊協作，可閱讀團隊 AI Agent 總覽（簡體中文）與團隊 Agent 權限管理（簡體中文）。