網站上線了，也擋住了幾隻鯊魚的攻擊。可是還是有幾個問題，我到現在還沒辦法知道：

別人在 Google 搜尋得到我的網站嗎？打開來會不會很慢？來的人都在做什麼？如果某個使用者按了按鈕卻沒反應或是跑很久，我能知道嗎？

今天要做的，是讓網站被看見，也讓我能看得見網站的狀況。

一、四個想觀察的面向

網站上線後，我想知道四件事：能不能被找得到、用起來順不順、有多少人使用、有哪些地方會遇到錯誤，而每一件都有對應的工具：

【圖 1｜四個面向與對應工具】

用餐廳對照：

• SEO 是招牌和地圖上的標記，讓人找得到店。
• 效能 是上菜速度，等太久，客人就走了。
• 數據分析 是來客數和點餐紀錄。
• 錯誤監控 是客人吃到壞掉的菜時，有人立刻通知廚房，而不是等客人默默不再上門。

二、SEO：讓搜尋引擎看懂網站

2.1 搜尋引擎怎麼運作

Google 找到一個網頁，大致會經過三步：

SEO（搜尋引擎最佳化）三步都有影響，但最基本的是前兩步：讓 Google 爬得到、看得懂。排名則由搜尋引擎綜合很多訊號決定，沒有人能保證。

2.2 要告訴搜尋引擎的東西

robots.txt 和 noindex 管的是兩件事：robots.txt 管「要不要來爬」，noindex 管「要不要收錄」。想讓登入頁、後台不出現在搜尋結果，要讓爬蟲進來看到 noindex；如果在 robots.txt 擋掉，爬蟲反而讀不到那張「不要收錄」。

兩者都並非安全措施：robots.txt 是任何人都看得到的公開檔案，後台擋人靠的是 Day 21 的權限。

對這個專案來說，Open Graph 也很實用。K-pop 粉絲常把連結分享到群組，預覽卡片如果有專輯封面和名稱，別人一眼就知道這是什麼，可能比較願意點開。

2.3 先盤點，再動手

跟之前一樣，我先請 Codex 做唯讀盤點，例如：

你是一位 SEO 與 AEO 專家，請分析這個專案目前的 SEO 與 AEO，
有哪些地方可以優化？請做深度分析，先不要修改。

結果有好有壞。專輯頁其實已經有動態的標題、描述和 canonical；但缺少 sitemap、robots、各頁面的收錄規則，品牌名稱也有「搜輯 Biashelf」「BIAS SHELF」混用的情況。

而這次分析的報告裡最有價值的，是一個從畫面上完全看不出來的問題。

2.4 畫面正常，搜尋引擎卻只看到一部分

一張專輯有好幾個版本，原本是利用點選畫面中的按鈕搭配參數切換。但盤點發現，伺服器回傳的 HTML 裡只有預設顯示的第一個版本的配置，其他版本會須要等瀏覽器執行 JavaScript、使用者點下去才會出現。

然而爬蟲並不會自己去點分頁。所以「Zine 版有幾張小卡」這種答案，明明在網站上，搜尋引擎卻看不到。

想讓爬蟲知道的內容，就要出現在伺服器回傳的 HTML 裡。 這也是為什麼內容全靠瀏覽器產生（CSR）的網站，SEO 效果有時比較差：Google 雖然能執行 JavaScript，但比較不穩定；LINE、Facebook 抓預覽時，主要讀取伺服器回傳的 HTML，不會像瀏覽器一樣執行互動。

修法是把所有版本都放進 HTML，沒選到的先隱藏起來，畫面不變。修好之後，補一條 E2E 測試直接讀原始 HTML，確認每個版本都在裡面。跟 Day 26 一樣，問題修好，就變成一條測試。

2.5 我這次補了什麼

搜尋和篩選的網址組合幾乎無限多（?q=aespa、?year=2026&sort=new……），如果每一種都被收錄，搜尋引擎會把力氣花在大量重複的頁面上，所以只收錄不帶參數的列表頁。

分享圖可以不用每張專輯各做一張。 只要設計一個模板（左邊放封面，右邊放團名、專輯名稱和品牌），Next.js 會在有人分享時，依那張專輯的資料自動產生圖片：

// app/albums/[slug]/opengraph-image.tsx（簡化）
export default async function Image({ params }) {
  const album = await getAlbum(params.slug);
  return new ImageResponse(
    <div style={{ display: "flex" }}>
      <img src={album.coverUrl} />
      <div>{album.title}・{album.artist}</div>
    </div>,
    { width: 1200, height: 630, fonts: [/* 中文字型 */] }
  );
}

兩個要注意的地方：中文字型要另外載入，否則中文會變成方塊，這點 AI 很常漏掉；另外，LINE 會記住預覽，同一個網址分享過一次，改了圖之後，舊的預覽可能還會留一陣子。

【圖 2｜把專輯網址貼到 LINE 的預覽卡片】

sitemap 要一直重新提交嗎？

sitemap 幾種產生的作法：

• 手寫一個 sitemap.xml 檔案(要自己更新)
• 部署時用工具產生 (要重新部署才會更新)
• 有人讀取時由程式產生( 自動更新 )

不管哪一種，提交給 Search Console 都只需要一次，之後 Google 會自己定期回來讀。也有人把 sitemap 改名、只提交給 Google，不讓其他爬蟲知道；但公開的頁面，爬蟲沿著連結一樣找得到，藏起來反而讓 Bing 這類搜尋引擎少了一份清單。

爬蟲來的時候，資料庫會不會被打爆？

sitemap 每天最多重新產生一次，其他時候直接回傳做好的版本。專輯頁比較特別：root layout 會讀取登入狀態，這一行讓整個網站的每一頁都變成「每次請求才產生」。所以我改成讓頁面用到的資料，在 Vercel 的伺服器上快取一週，大多數訪客和爬蟲可以共用快取，不用每次都查資料庫。

快取拉長之後，資料改了不會馬上出現在網站上，所以我另外在後台加了一顆「更新專輯快取」按鈕：修正資料後按一下，網站就會拿到新資料。

SEO 之外：AEO

越來越多人直接問 ChatGPT 或看 Google 的 AI 摘要，而不是點進搜尋結果。AEO（Answer Engine Optimization）是讓這些 AI 更容易引用你的內容。沒有保證被引用的公式，但有些寫法比較容易被理解和引用：

• 答案要直接，不要藏在需要點擊的互動元件裡（2.4 正是這個問題）。
• 用表格整理，例如版本比較。
• 標示來源和日期，例如「最後核對：2026 年 10 月 6 日」。

2.6 Google Search Console

Search Console 是 Google 提供的免費工具，可以看到 Google 怎麼看你的網站。sitemap 已經在 2.5 產生，部署到正式網站之後，這裡只要把網址交給 Google。

1. 驗證網域。 Google 會給一筆 TXT 記錄，加到 Cloudflare 的 DNS 裡。這就是 Day 23 提過的 TXT 記錄用途之一：證明「這個網域是我的」。

【圖 3｜Google Search Console 驗證網域 - 1 新增資源】
（依序選擇新增網站 -> 輸入網域）

【圖 4｜Google Search Console 驗證網域 - 2 開始驗證】

【圖 5｜Google Search Console 驗證網域 - 3 Cloudflare 驗證】
（一段時間後會驗證成功）

2. 提交 sitemap。 先打開 你的sitemap網址，確認裡面的網址都是正式網域開頭，再到 Search Console 填入這個網址。

【圖 6｜提交 sitemap】

3. 網址檢查。 一段時間後，在 Google Search Console 搜尋欄輸入任一頁網址，可以看到 Google 實際抓到了什麼、有沒有收錄。

收錄可能要幾天到數週以上，而且提交 sitemap 不保證每一頁都會被收錄。收錄的狀況可以在 Google Search Console 後台去查看。

三、效能：幾個專有名詞

3.1 Core Web Vitals

Google 用三個指標衡量「使用者覺得快不快」，合稱 Core Web Vitals：

3.2 實驗室數據 vs 真實數據

這是效能最重要的觀念：

Lighthouse 拿 100 分，不代表使用者覺得快。

【圖 7｜Biashelf 首頁的 PageSpeed Insights 結果】

這些建議很適合交給 AI 判斷：

以下是 PageSpeed Insights 的報告。請說明每一項建議影響的是哪個指標、
對真實使用者的影響大不大，依優先順序排列。先不要修改。

兩個提醒：AI 很容易為了衝分數，去改一些對使用者沒什麼差別的地方，所以要它先說明「影響哪個指標」；改完之後，再跑一次比對前後。

3.3 Vercel Speed Insights：每一頁的真實數據

Lighthouse 和 PageSpeed Insights 都要自己去查。Vercel Speed Insights 則是在網站裡放一段程式碼，每個真實使用者打開頁面時，都會回報這次的體驗，而且可以分頁面看。

設定流程：

1. 在 Vercel 專案的 Speed Insights 分頁按下啟用。
2. 請 AI 加上追蹤程式碼：

請安裝 Vercel Speed Insights：安裝 @vercel/speed-insights，
並在 root layout 加入 <SpeedInsights />。
這次允許修改 root layout，但只加這一處，其他內容不要動。

1. 重新部署。 後台的啟用，要等下一次部署才會生效。
2. 有真實訪客造訪後，數據才會開始出現。Preview 的數據也會收集，後台可以依環境篩選。

【圖 8｜Vercel Speed Insights 畫面】

免費版只提供一個總分（Real Experience Score），要看到每個指標的細節(哪一頁特別慢之類的)，需要另外付費升級。
Speed Insights 和下一節的 GA4，都是真實使用者的數據，也都能分頁面看。差別在於：Speed Insights 量的是「快不快」，GA4 量的是「做了什麼」。

四、GA4：來的人做了什麼

4.1 為什麼選 GA4

這次選 GA4，因為它是業界最常見的工具，學會了在別的專案也用得上；而且可以跟 Search Console 串在一起，看到使用者是搜尋什麼進來的。只想看流量的話，Vercel Web Analytics 更簡單。

4.2 設定

GA4 不用驗證網域。它的評估 ID 像一個「收件地址」，網站把資料寄到這個地址，你登入就收得到；Search Console 給你看的是 Google 掌握的資料，所以才需要證明網域是你的。

Google Analytics 這邊：

1. 建立帳戶和資源。 資源就是「要分析的網站」，時區選台灣、幣別選新台幣。
2. 建立網站資料串流。 填入 你的網域，依序設定完 DNS 後，會拿到一組 G- 開頭的評估 ID。畫面上那段「手動安裝代碼」可以跳過，交給 AI 用 Next.js 的方式載入。

【圖 9｜GA4 後台建立新帳戶】

【圖 10｜輸入完基本資料，選擇要追蹤的平台】

【圖 11｜可以看得到追蹤碼（G-XXXXXXXXXX），安裝完、部署完，可以測試】

網站這邊，交由Codex 處理：

請幫 Biashelf 加上 Google Analytics 4，評估 ID 是 G-XXXXXXXXXX。

1. 使用 @next/third-parties 的 GoogleAnalytics 元件，不要直接貼 gtag 的 <script>
2. 只在正式環境載入：判斷 VERCEL_ENV === "production"，Preview 與本機都不要載入
3. 這次允許修改 root layout，但只加這一處，其他內容不要動

兩個細節：

• 評估 ID 可以直接寫在程式裡。 它本來就會出現在每個訪客的瀏覽器裡，是公開的值，跟 Day 26 的 secret key 不一樣。
• 只在正式版載入。 Day 23 說過，每個分支都有自己的 Preview 網址；如果 Preview 也送數據，自己測試的瀏覽量會混進正式的報表。

部署後打開正式網站點幾頁，到 GA4 的「即時」報表，應該會看到自己。

【圖 12｜GA4 即時報表】

4.3 追蹤有意義的動作

只看瀏覽量，只能知道「有人來」。真正有用的，是使用者做了什麼：

能用 GA4 建議的事件名稱就先用，沒有合適的再自己命名。自訂事件可以等基本追蹤確認正常之後再加，一次只做一件事比較好除錯。

不要把 email、姓名這類能直接認出一個人的資料送進 GA4，這是 GA4 的規範明文禁止的。

電商最常用的是轉換漏斗：追蹤「加入購物車 → 開始結帳 → 完成購買」，看出多少人在哪一步離開。

4.4 GA4 的數字不是全部

• 會偏低。 部分廣告阻擋器、瀏覽器的隱私設定會阻止 GA4 載入，所以數字通常不等於真實的訪客總數。
• 要說明。 GA4 會用 Cookie，網站最好有一頁隱私說明，寫清楚用了什麼工具、收集了什麼。

五、Sentry：網站壞了，我需要知道

5.1 Vercel 的 log 不夠嗎？

Vercel 本身就有執行紀錄（Runtime Logs），但它跟 Sentry 擅長的地方不一樣：

關鍵在第一列：使用者瀏覽器裡發生的錯誤，伺服器根本不知道。 某支手機上按鈕點了沒反應，Vercel 的 log 裡什麼都不會有。

5.2 安裝：精靈負責安裝，AI 負責檢查

先在 Sentry 建立專案（平台選 Next.js），取得 DSN。DSN 決定錯誤要送到哪個專案，網站不需要知道你的 Sentry 帳號密碼。

接著在專案根目錄執行官方的安裝精靈。它會打開瀏覽器讓你登入、選擇專案，再自動安裝套件、建立設定檔：

npx @sentry/wizard@latest -i nextjs

精靈開始前如果提醒「有尚未 commit 的修改」，先停下來把目前的修改 commit 起來。精靈會修改好幾個檔案，跟其他修改混在一起，之後就很難分辨、也很難單獨退回。

精靈用的是官方範本，比 AI 自己寫的設定可靠；但它不知道 Biashelf 的需求，所以裝完再交給 AI 檢查（下一節的設定）。

裝的過程中會碰到兩把鑰匙：

source map 是「壓縮後的程式碼，對應到原始程式碼哪一行」的對照表。正式版的程式碼在打包時會被壓縮，沒有它，錯誤只會顯示「page-3f8a2c.js 第 1 行第 28471 個字」；有了它，才會顯示「AlbumDetails.tsx 第 117 行」。沒有 auth token，Sentry 一樣收得到錯誤，只是比較難看懂。

auth token 不能加 NEXT_PUBLIC_；GitHub Actions 的 CI 也不需要它，沒有 token 只是略過上傳。

5.3 依需求調整的設定

Sentry 有很多功能可以開關，精靈過程中會問一部分，其他要裝完後自己調整：

前三項最容易被忽略，而且精靈的預設值不一定符合需求：

• 精靈的設定，預設在任何地方都會啟用，包括本機開發。Day 25 的 E2E 測試會在 CI 上跑正式版的 build，測試中的錯誤也會被送出去。所以改成「有 Vercel 的環境名稱才啟用」，本機和 CI 都不送。
• Vercel 上的 Preview 和正式版，程式都認為自己是 production，不另外標記的話，測試時的錯誤也會觸發正式通知。
• Sentry 預設會收集不少資料：使用者 IP、Cookie、HTTP 標頭與請求內容、網址參數，甚至資料庫查詢的內容。像登入時送出的 email、錯誤回報的內容，都可能跟著錯誤一起被送出去。精靈安裝時會問「要不要減少收集個人資訊」，我選了 Yes，精靈會用 dataCollection 設定把這些關掉。舊版用的是 sendDefaultPii，新版已經改成 dataCollection。

後面三項功能都很實用，但都會消耗免費額度。先從錯誤監控開始，需要時再打開。

例如，交給 AI 的檢查指令範例：

我剛用 Sentry 安裝精靈完成設定，請檢查並調整，先列出要改的地方，等我確認：

1. 只在 Vercel 上的部署啟用：有 VERCEL_ENV（前端用 NEXT_PUBLIC_VERCEL_ENV）才啟用，
   本機開發、本機 npm run start、GitHub Actions 的 CI 都不要送錯誤
2. 環境標記：environment 使用同一個值，區分 Preview 與正式版
3. 確認 dataCollection 已關閉使用者資訊、Cookie、HTTP 內容、網址參數與資料庫查詢內容
4. 確認效能追蹤、Session Replay、Logs、Tunnel 都沒有開啟
5. 確認 auth token 沒有被 commit，也沒有 NEXT_PUBLIC_ 前綴

設定好之後，部署到 Preview，打開精靈建立的測試頁面觸發一次錯誤。錯誤會出現在 Sentry 的 Issues 列表：同一種錯誤會合併成一筆，顯示發生幾次、影響幾個使用者、發生在哪一行程式碼。

【圖 13｜可以從 Sentry 幫專案創建的範例頁面送出測試錯誤】

通知規則可以自己設定，例如「正式環境出現新的錯誤，就寄信」，Preview 的測試錯誤就不會吵到你。
確認 Sentry 收得到、環境標記正確、正式通知沒有被觸發，才算真的裝好。沒有故意弄壞過，就不知道它會不會響。

六、設定流程摘要，以及 AI 能幫什麼

6.1 四個工具的設定流程

【圖 14｜四個工具的設定流程：哪些自己做、哪些交給 AI】

四條流程幾乎都是同一個模式：自己在第三方後台設定 → 交給 AI 改程式 → 部署 → 自己確認。

GA4、Speed Insights、Sentry 都要改程式，改完要重新部署才會生效；Search Console 的設定在網站外完成，但它要讀的 sitemap，一樣要先部署上去。至於 Preview 或開發時的數據是否影響，建議要設定一下，可以靠後台篩選和環境標記區分。

6.2 哪些可以交給 AI

公開的識別碼可以交給 AI，秘密和第三方帳號自己處理，跟 Day 26 的分界一樣。GA4 評估 ID、Sentry DSN 可以直接給 AI；Sentry auth token 不要貼進對話或程式碼，放在 Vercel 的環境變數；Search Console 驗證、GA4 建立帳戶這類要登入第三方後台的步驟，也都自己來。

也有現成的 SEO audit skill（例如 seo-audit），不過這類 skill 多半偏向行銷面：關鍵字、競爭對手、內容缺口。技術面的檢查，用 2.3 那種自己寫的指令在提示詞中提及。

6.3 AI 可能的盲點

驗收

換個領域

結語與明日預告

今天的新觀念：

今天的三個發現，其實都在講同一件事：畫面上版本切換正常，爬蟲卻只看得到第一個；Lighthouse 分數很高，不代表使用者覺得快；裝了 Sentry，不代表警報真的會響。

我眼前看起來正常，不等於外面的世界看到的也正常。 今天打出的信號彈，一邊是讓別人看見 Biashelf，一邊是讓我看見使用者真正遇到的事。

不過，每多接一個服務，有時候就多一份帳單：網域、Vercel、Supabase、寄信、監控……網站能不能長久營運，最後還是要回到錢。明天，我們來算一算這艘船的開銷，並且嘗試著透過這個網站來獲得一些收入。

我們明天見。