從工程師視角看 SEO：頁面渲染、索引管理與效能優化

Foliohaven 將文章、導覽與 SEO 資料預先產生為 HTML，再以靜態檔案對外提供。這項架構選擇影響搜尋引擎取得內容的方式、頁面載入與執行成本，以及公開端的維護範圍。

本文接續前一篇的建站與部署流程，以 Foliohaven v1.1.0 說明渲染、索引與效能的工程設計，範例延續工作室官網與活動公告。下一篇則著重開發初期的 SEO 規劃、設定用途、繼承機制及實際設定流程。

技術 SEO 的目標與範圍

SEO（搜尋引擎最佳化）涵蓋內容、網站技術與站外連結等工作。依執行內容，可整理為以下三個方向：

這三個方向有助於整理工作範圍，實際執行時則經常需要相互配合。以站內連結為例，安排連結時既要考慮讀者如何瀏覽，也要讓搜尋引擎找到相關頁面；頁面標題則需要兼顧文案與 HTML 輸出。這類內容與技術搭配的做法，可參考 Google SEO 入門指南。

技術 SEO 的檢查項目與搜尋引擎處理頁面的方式密切相關。了解爬取、渲染與索引的分工，才能判斷問題發生在哪個環節。

搜尋引擎的內容處理流程

搜尋引擎發現網址後，會讀取頁面並處理其中的內容，再判斷是否納入索引。當使用者搜尋相關主題時，搜尋引擎便從索引中找出合適的頁面，依相關性等訊號排列結果。這些工作的分工如下：

• 爬取（Crawling）：發現網址後，請求頁面與相關資源，取得 HTTP 回應。
• 渲染（Rendering）：處理 HTML、CSS 與需要執行的 JavaScript，產生頁面呈現的內容。
• 索引（Indexing）：分析文字、圖片與其他資訊，判斷代表網址，將適合收錄的資料存入搜尋索引。
• 搜尋與排序：依使用者查詢、內容相關性及其他訊號選擇結果，決定排列順序。

不同階段的異常需要分別排查。頁面回應 5xx 時，應檢查服務、路由或來源連線是否異常；回應正常但正文依賴 JavaScript 才會出現時，則須檢查資源存取、資料請求與程式執行結果。Google 對整體流程的說明見搜尋的運作方式。

技術 SEO 以頁面可被取得、理解與正常使用為基礎，工程端的主要檢查範圍如下：

完成上述檢查，有助於排除頁面讀取與內容處理上的技術障礙。至於頁面是否被收錄、在特定查詢中如何排序，搜尋引擎還會考慮內容相關性、品質與其他訊號。工程上則透過渲染策略、URL 與索引規則、HTML 結構及效能設計，讓內容能被穩定取得、理解與使用。

頁面在哪裡產生：CSR、SSR 與 SSG

渲染策略決定主要內容何時出現在 HTML，也影響搜尋引擎取得內容時需要經過的環節。CSR、SSR 與 SSG 的核心差異是：HTML 在哪裡產生、什麼時候產生，以及如何交付給瀏覽器。

現代網站可依頁面與功能需求採用混合渲染（Hybrid Rendering），在同一系統中組合不同策略。例如：

• 公開產品介紹頁：使用 SSG 預先產生頁面，降低逐次產生 HTML 的伺服器成本，並提升快取效率。
• 需要即時內容的公開頁面：使用 SSR，在請求時取得資料並產生較新的內容，快取策略配合更新需求設定。
• 高度互動的內部管理系統：使用 CSR，由瀏覽器管理複雜的介面狀態與操作流程。

渲染策略與 UI 工具分屬不同層次。React、Vue 用來組合頁面與互動元件，搭配 Next.js、Nuxt 等框架，可以實作 CSR、SSR 或 SSG；Django、Laravel 等後端框架則可在收到請求後，以模板產生 HTML，也能提供資料 API。實際採用哪種渲染策略，要看主要內容何時、在哪裡產生，不能只憑框架名稱判斷。

Foliohaven 的選擇：SSG

官網介紹與部落格文章通常不需依訪客身分即時調整內容，適合在建置階段預先產生頁面。

Google 能執行 JavaScript，但主要內容若依賴 JavaScript 才能出現，就需要先載入並執行相關腳本，增加取得內容的時間與運算成本。對官網與部落格而言，將正文、連結與 SEO 資訊直接放進初始 HTML，是更穩定、容易驗證的做法。Foliohaven 因此採用 SSG，在建置時產生完整頁面，只為必要互動加入 JavaScript，讓搜尋引擎直接取得內容，同時改善載入效能並降低維護成本。相關原理可參考 Google JavaScript SEO 說明。

建置流程由 Core 整理文章與頁面模型，React 組合內容，再由 Astro 輸出完整 HTML。公開端交付建置完成的檔案，內容更新則透過重新建置與部署反映到網站。這項取捨減少公開端即時組合頁面的工作，也將更新成本集中於建置階段。

Islands 與漸進增強

SSG 可以預先產生頁面內容，但搜尋、篩選或切換深淺配色等操作，仍需要 JavaScript 在瀏覽器中回應。這些功能可以用一般 JavaScript 腳本處理，也能依需求搭配 React 等元件工具。

SSR 或 SSG 可以先把元件輸出成 HTML，讓瀏覽器直接顯示內容；之後再由瀏覽器執行對應的元件程式，處理點擊、記錄操作狀態並更新畫面。這個讓元件沿用既有 HTML、開始處理互動的過程，稱為 Hydration。

Hydration 的範圍取決於頁面的組成方式。若整個頁面由同一套元件管理，可以對整頁進行 hydration；若只有搜尋或篩選區塊需要元件互動，也可以只對這些區塊進行 hydration，正文與其他靜態內容不必一併交由元件管理。

Islands（島嶼架構）進一步把互動元件分成各自運作的區塊，僅為這些區塊載入 JavaScript 並啟動 hydration，其餘內容保留靜態 HTML。頁面因此可以保留元件的互動能力，同時縮小前端程式的載入與執行範圍。

Astro 採用 Islands 架構，透過 client:* 指令指定需要互動的元件，以及載入和啟動的時機，例如 client:load 會在頁面載入時啟動元件。

Islands 決定哪些區塊需要啟動程式，而這些程式尚未載入或無法執行時，頁面仍應保留基本的閱讀與瀏覽能力。漸進增強就是先用 HTML 提供正文與基本導覽，再用 JavaScript 加上搜尋、篩選或閱讀設定等功能。這種設計可以搭配混合渲染與 Islands 使用：渲染策略決定內容何時產生，Islands 控制互動元件的範圍，漸進增強則確保基本內容不依賴增強功能。

Foliohaven 的一般展示頁面預設不啟用 hydration，切換深淺配色、點選目錄跳到章節，以及返回文章後恢復閱讀位置等功能，由一般 JavaScript 腳本處理。

文章總覽 /articles/ 的初始 HTML 已有預設第一頁列表，搜尋元件再以 client:load 於頁面載入時啟動，讀取網址中的查詢參數，依標題、摘要、分類與 Tag 搜尋及篩選文章，並更新列表。

依照這樣的分工，驗收時可以先停用 JavaScript，確認正文、導覽與預設文章列表仍可閱讀；再啟用 JavaScript，檢查搜尋與篩選、深淺配色切換、目錄定位，以及返回文章後的閱讀位置是否正常。

URL 結構與索引管理

頁面具備可取得的內容後，搜尋引擎仍需透過連結發現它，並辨認對應的正式網址。URL 結構、站內導覽與索引設定共同影響這兩項工作。同一篇文章出現在不同網域、舊路徑或查詢網址時，站內連結、canonical、轉址與 Sitemap 應提供一致的訊號。

正式網址與站內連結

Canonical 表達偏好的代表網址，供搜尋引擎判斷相同或近似內容的主要版本。

站內連結與 Sitemap 應指向選定的正式網址。網站從舊網域或路徑搬移時，再於部署環境配置永久轉址，讓既有連結有明確去向。Canonical 本身不會把訪客轉走，搜尋引擎也仍會綜合其他訊號決定代表網址。相關原則見 Google 的 canonical 說明。

內容發現則依靠實際連結。分類、Tag、麵包屑、文章列表與分頁都使用可爬取的 <a href>，讓讀者與爬蟲從既有頁面走到文章。重要內容應在合理的導覽位置被找到，Sitemap 再補充可索引的網址清單。

Foliohaven 由 Core 統一產生路由與連結，並以全站設定的 siteUrl（正式網站網址）組成 canonical。

活動公告的範例網址可在頁面 Head 中輸出以下 canonical：

<link rel="canonical"
      href="https://www.example.com/events/brand-website-meetup/">

分類與 Tag 的靜態分頁各有自己的正式網址及 canonical。文章總覽的 /articles/?q=網站&page=2 則是瀏覽器查詢狀態，沿用 /articles/ 的初始 HTML 與 canonical；它不會因為每個搜尋條件，再產生一份獨立的靜態落地頁。

爬取、索引與公開狀態

robots.txt 定義爬取規則，頁面上的 Meta Robots 提供索引指示，文章發布狀態則決定內容是否納入公開產物。三者分別作用於爬取、索引與內容交付。

要讓搜尋引擎讀到頁面上的 noindex，就要允許它取得該頁面。若先用 robots.txt 阻擋爬取，爬蟲可能讀不到這個指示。另一方面，noindex 頁仍可被知道網址的人開啟，存取限制需要由認證與權限控制處理。細節可參考 Google 的 noindex 說明。

Foliohaven 的 robots.txt 允許爬取並提供 Sitemap 位置；Sitemap 由正式路由模型選出可索引頁面。各種發布與索引狀態的輸出如下：

驗證對象應包含一般文章、分類第二頁、搜尋查詢、noindex 文章與不存在的路徑，交叉核對 HTTP 狀態、canonical、索引指示及 Sitemap。

HTML 語意與結構化資料

網址與索引設定表達頁面的位置與收錄意圖，HTML 語意與結構化資料則表達內容結構及機器可讀的資訊。標題、正文、導覽、圖片與文章屬性應維持一致，使讀者、輔助工具及搜尋引擎能辨認各部分的用途。

正文與語意結構

文章頁以 main 表達主要內容、article 表達文章，導覽使用 nav。主標題由共用版型輸出 H1，正文再按內容安排 H2、H3 與更細的層級。章節標題需有合法且唯一的 ID；Core 會將 H2、H3 納入目錄，並連結到對應章節。

圖片 Alt 說明這張圖傳達的資訊，連結文字交代目的地或用途，影片與圖表的重要內容也以文字補充。這些資訊有助於理解內容，並且能直接改善輔助工具與不同閱讀條件下的使用。

手機與桌機應保留相同的主要內容與索引資訊，再透過響應式版面調整欄寬及排列。長表格與程式碼在各自區塊內捲動，避免把整頁撐寬；放大文字後，也要保留閱讀順序與操作入口。

共用的 Head 與結構化資料

HTML 的 <head> 存放頁面標題、描述、正式網址與索引指示等中繼資料，供瀏覽器、搜尋引擎與其他服務讀取。<title> 與 Meta Description 提供頁面名稱及內容簡述，也是搜尋引擎產生搜尋標題與摘要時的參考；Open Graph 與 Twitter Card 則提供分享連結時使用的標題、描述與圖片。

結構化資料用明確的類型與欄位描述文章、作者及導覽等資訊，幫助搜尋引擎理解這些內容之間的關係。JSON-LD 是常用的表達格式，資料以 JSON 撰寫，放在 <script type="application/ld+json"> 中，隨 HTML 一起提供。

Foliohaven 由 Core 的 SEO 模組把文章資料與單篇、頁型及全站設定整理為 SeoViewModel（頁面所需的 SEO 資料模型），再交給 Astro 的共用 Head 輸出中繼資料及 JSON-LD。共用這套流程，可讓各頁型採用一致的處理規則，減少標籤遺漏或資料彼此矛盾的情況。輸出 JSON-LD 時，系統會先跳脫可能提前結束 script 區塊的特殊字元，讓文字內容安全地保留在資料中。

以活動公告為例，系統使用 Schema.org 定義的兩種結構化資料類型：BlogPosting 描述公告文章本身，包括文章標題、作者、發布與更新日期及正式網址；BreadcrumbList 則表達頁面上的麵包屑導覽，列出各層的名稱、順序與連結，讓搜尋引擎辨認文章在網站中的位置。

驗證時，除了檢查 Head 標籤與 JSON-LD 格式，也要對照實際頁面，確認文章名稱、作者、日期、正式網址及麵包屑是否正確。輸出資料正確後，再分別確認搜尋結果與分享卡片的實際呈現。

全站、頁型與單篇 SEO 設定的用途、繼承及覆寫流程，將在下一篇說明。

頁面效能與資源交付

HTML 的內容與語意正確後，實際閱讀體驗仍取決於媒體傳輸、渲染阻塞、版面位移與主執行緒負載。效能優化應依實際瓶頸選擇調整項目，並以載入、互動及穩定性指標驗證結果。

效能指標與瓶頸分析

Core Web Vitals（核心網頁指標）是 Google 用來衡量網頁使用體驗的一組指標，分別觀察載入速度、互動回應與版面穩定性，對應 LCP、INP 與 CLS。表格中的 TTFB 與 FCP 則能協助追查伺服器回應及內容首次呈現的問題。

三項指標的良好門檻分別為 LCP 不超過 2.5 秒、INP 不超過 200 毫秒，以及 CLS 不超過 0.1。評估真實使用者的體驗時，手機與桌機分開統計，以各項指標的第 75 百分位數（p75）判讀；例如，LCP 的 p75 為 2.5 秒，表示約 75% 的載入紀錄落在 2.5 秒以內。在三項都有足夠資料時，各項的 p75 都需達到良好門檻，才算通過該組 Core Web Vitals 評估。

Lighthouse 是自動化的網頁品質檢查工具，可在指定條件下提供效能、無障礙與 SEO 等診斷，也會量測 LCP、CLS 等指標。

Lighthouse 反映指定裝置、網路與 CPU 條件下的測試結果，適合用來找出瓶頸、比較修改前後的差異。真實使用者資料則彙整一段時間內訪客的實際瀏覽與操作，用來觀察網站在不同使用情境下的表現。即使包含相同指標，單次測試結果與使用者統計仍需分開判讀。

Google 的排名系統會考量頁面體驗，也結合內容相關性與其他訊號，因此工具分數與搜尋排名仍需分開觀察。相關原則見 Google 頁面體驗指南。

圖片尺寸與載入順序

圖片會同時影響傳輸量、內容出現的時間與版面穩定性。響應式圖片透過 srcset 提供同一構圖、不同尺寸的候選圖，再以 sizes 說明圖片在版面中大約占多寬，讓瀏覽器依欄寬與螢幕像素密度選擇合適資源，減少手機下載不必要的大圖。

HTML 中的 width、height 或明確的構圖比例，用來預留圖片位置。若缺少這些資訊，圖片載入後才撐開區塊，就可能把正在閱讀的段落往下推；這類非預期位移可能計入 CLS。

合適的尺寸能降低傳輸量，載入順序則影響重要內容何時出現。首屏精選圖可能成為 LCP 元素，若延後載入，圖片較晚顯示就可能拉長 LCP，可用 loading="eager" 讓瀏覽器發現圖片時就安排載入，避免延遲載入造成的額外等待。必要時再以 fetchpriority="high" 提示較高優先序；較後面的內文圖則可用 loading="lazy" 延後取得。高優先序應限於關鍵圖片，避免彼此競爭。圖片取得後還需解碼，decoding="async" 則是非同步解碼提示，與下載優先序分開設定。

這些原則也適用於影片、Poster 與 iframe。除了預留空間，還要依是否出現在首屏，安排預覽圖、播放、載入與第三方資源，避免延後主要內容的呈現。

Foliohaven 將原始圖片處理成 WebP 與不同尺寸。一般響應式圖片保持原比例且不放大，社群分享用的裁切圖另作選用，不混進正文的尺寸候選。各種引用方式的處理範圍如下：

既有文章版型已為精選圖啟用 priority。客製版型或新增正文圖片時，仍需對照實際欄寬與出現位置，設定 sizes 及載入策略，因為 Core 不會分析整份 CSS 來替每張圖決定欄寬與重要性。

字型、布局與 JavaScript

字型同時影響傳輸與排版。系統字型可減少額外請求；Web Font 則需控制字重與檔案，設定 font-display 的載入顯示策略，並核對替代字型切換前後的換行及區塊高度。

工具列、目錄、搜尋等待區與延遲顯示的內容，應在初始 HTML 或 CSS 預留空間，減少程式啟動後插入內容造成的版面位移。驗證時比較初始化前後的幾何位置，並檢查章節定位、瀏覽器返回及前進的閱讀行為。

JavaScript 的成本包含下載、解析與執行。搜尋計算、事件處理、第三方腳本及元件狀態更新，均可能占用主執行緒並延遲互動回應。客製時需控制程式大小與啟動時機，避免非必要工作阻塞主要內容及操作。

共用 CSS 與前端程式透過公開入口交給 Astro／Vite 整理輸出。效能調整也要保留既有閱讀行為，包括章節定位、區塊內捲動、鍵盤操作，以及回到文章後的閱讀位置。

Edge、快取與 HTTP 回應

圖片、字型與 JavaScript 的處理之外，網路交付與快取策略也會影響回應時間及重複下載。

HTTP 狀態與內容類型必須符合資源。正常頁面回應 200，不存在的網址回應 404，CSS、JavaScript、JSON、XML 與媒體使用正確的 Content-Type。將不存在的路徑一律回成首頁 HTML，可能造成資源載入及索引判斷錯誤。

瀏覽器可搭配 ETag（版本識別標記）發出條件請求，在未變更時取得 304 回應並重用內容。驗證時應涵蓋瀏覽器、CDN 與來源端的快取設定。

Foliohaven 部署至 Cloudflare 時，依檔案路徑安排交付方式：assets/、media/ 放在 R2，其餘網站檔案交給 Workers Static Assets，再透過 Worker Routes 與 Cloud Connector，以同一主站網域提供內容。各層的分工如下：

這些網站檔案在建置時已經完成，Workers Static Assets 可直接回傳檔案內容。若另外加入自訂 Worker，是否先由該程式處理請求，則由部署與路由設定決定，相關行為見 Cloudflare 執行順序說明。

R2 檔案的重用則由快取標頭與規則控制。v1.1.0 上傳器會寫入 Cache-Control: public, max-age=0, must-revalidate，允許瀏覽器與共享快取保存檔案，但重用前須重新驗證；配合前述 ETag 與條件請求，內容未變時便能重用既有檔案。

這項分流會讓更新與還原同時涉及 R2、Worker 與 CDN。同一路徑的資源被覆寫後，舊 HTML 可能讀到新資源，CDN 也可能仍保留舊回應。因此，發布或還原完成後，都要確認 HTML 與實際載入的資源是否對應到預期的網站版本。第二篇已說明部署與網域設定，第五篇再接續狀態查詢及復原。

技術 SEO 驗證與效能量測

前面介紹的渲染、索引設定與資源交付，可以透過實際 HTML、HTTP 回應與量測報告驗證。這些工作可藉助 Agent 對照原始碼、實際回應與報告，指出差異及可能的修正位置，再提出驗證方式。

檢查 HTML 與 SEO 資訊

檢查內容頁時，可直接讀取伺服器回傳的 HTML，確認標題、正文與連結已經存在，再核對 title、description、canonical、robots、分享資料及 JSON-LD 是否符合頁面設定與內容。接著對照 Sitemap、HTTP 狀態與 Content-Type，確認網址、索引訊號及資源類型符合預期。

來源設定變更後，已建置的檔案與公開網站仍可能是舊版。例如，正式網站網址已改，公開 HTML 的 canonical 卻仍指向舊網域，就要對照來源、建置與部署版本，判斷是設定尚未生效、新版尚未建置，還是公開端仍在交付舊回應。

程式測試用來確認模型與規則，建置檢查產生的 HTML 與資源，瀏覽器及 HTTP 檢查則確認實際交付的結果。手機與桌機也要走過目錄定位、表格與程式碼捲動、返回與前進、鍵盤操作及文字放大；停用 JavaScript 時，正文與基本導覽仍應可用。問題附上網址、異常節點與重現方式，才能在修改後重做相同操作，確認修正是否生效。

正式網址可再透過 Search Console 的網址檢查工具查看 Google 已知的索引資料與選定 canonical，並對照即時測試結果。資料與測試的時間，可協助判斷這些結果是否反映本次更新；適用的結構化資料工具則檢查 JSON-LD 類型與欄位，並與實際頁面對照。

Foliohaven 以 pnpm build 產生並驗證完整網站，編輯預覽(4321 port)反映目前來源，部署前預覽(4322 port)對應最近成功的完整 Build。日常可用 pnpm verify:quick 做隔離快檢，不更新網站；完整 pnpm verify 涵蓋整合、三瀏覽器與正式 Build，Build 成功與整輪通過分別判定。服務停啟、隔離環境及產物更新依同版 README 執行，受測期間暫停來源修改。

請依目前專案的 README、AGENTS 與品質指南，檢查【頁面網址】。
本次改動或待確認事項：【改動範圍】。

先辨識來源、成功建置與公開部署版本，沿用現有服務；需要建置或執行測試時，依文件安排正式入口、服務停啟與隔離環境。
核對初始 HTML、正文與連結、Head 與 JSON-LD、Sitemap、HTTP 狀態、Content-Type 及媒體引用，並檢查手機／桌機、無 JavaScript 閱讀與既有閱讀操作。
回報預期結果、實際 HTML／HTTP 或瀏覽器證據、問題位置、修正建議與再驗證方式；無法讀取原始碼時，以 DOM、標籤或資源位置說明。
將網址、受測版本及重現方式附在問題旁，方便修正後回歸。這次先檢查並提出建議，公開部署另依授權進行。

測量效能與定位瓶頸

LCP 偏慢時，先確認報告指出的 LCP 元素，再追查資源請求與呈現時機。若是精選圖，就對照圖片尺寸、HTML 中的引用方式與載入優先序；若圖片早已下載完成，卻很晚才顯示，則繼續檢查樣式或主執行緒工作是否延後渲染。

CLS 偏高時，則找出發生位移的節點，確認是否與圖片尺寸、字型切換或延遲插入內容有關；互動回應較慢時，再追查長任務與事件處理。報告中的元素、請求及執行紀錄，可用來定位需要調整的圖片、樣式或腳本。

效能測試會受裝置、網路與快取影響，因此比較修改前後時，要固定網址、裝置、工具及測試條件，每組依序測三次，分別取各類分數與效能指標的中位數。原始報告用來重查診斷及單次波動，受測版本、工具版本、網路／CPU 節流、冷啟動與快取條件則用來重現測試、判斷哪些結果可以比較；工具警告與無法控制的條件也需註明。首次量測建立基準，後續再以同條件報告確認改善。

本機可用 Lighthouse 初驗，正式部署後再以公開 HTTPS 網址使用 PageSpeed Insights，納入實際 CDN、媒體與第三方資源。PageSpeed Insights 無法取得有效結果時，改用 Lighthouse 測同一網址，註明切換原因與環境；本機與公開網站、不同工具及條件的結果分組呈現。

品質門檻由網站需求與專案標準訂定。Foliohaven 的指南以手機與桌機 Performance 至少 95，Accessibility、Best Practices 及正常可索引頁的 SEO 各 100 為開發目標；預期不收錄的頁面依原本索引策略驗收。分數用來輔助診斷，修改後仍要重測指標與受影響的閱讀操作。

PageSpeed Insights 中的真實使用者資料來自Chrome 使用者體驗報告（Chrome UX Report，CrUX），由 Chrome 使用者實際瀏覽公開網站的資料彙整而成。報告呈現最近 28 天的統計，需確認手機／桌機的 p75，以及頁面或 origin（由通訊協定、主機與連接埠界定的來源）範圍；樣本不足時註明。這些資料用來觀察部署後的實際使用體驗，需隨新紀錄累積追蹤，與本輪三次實驗室測試的中位數分開判讀。TBT 可協助追查主執行緒阻塞，互動是否改善仍需實際操作與 INP 資料確認。

請依目前專案品質指南，量測【受測網址】，觀察重點為【觀察重點】。
先確認受測版本；已有本輪同版本、同條件的完整報告時補齊缺項。有修改前同條件報告才比較改善，首次量測作為後續基準。

本機或內網使用 Lighthouse，公開網址優先使用 PageSpeed Insights；服務不可用或無有效結果時，改用 Lighthouse 測同一網址，註明原因與環境。
手機與桌機分開，每組網址、工具及條件依序測三次，分別取分數與指標中位數；依專案品質目標判讀，不為分數改變預期 noindex 策略。
指出 LCP 元素、阻塞資源、長任務或位移節點，附診斷證據、可定位的程式／資源位置及再驗證方式。
保留原始報告供重查診斷與波動，附版本、裝置、工具、CPU／網路與快取條件，方便重現及比較；註明警告、不可控條件與未驗範圍。
若有 Chrome 使用者體驗報告（CrUX）資料，另列 p75、期間與頁面／來源範圍，資料不足時註明，不與本輪中位數混合，也不用 TBT 代替 INP。公開部署另依授權進行。

資料與建置架構

驗證時看到的內容差異，也可能來自資料與建置流程。文章、列表與索引若各自維護資料，更新標題時就可能只改到部分頁面。將內容與版型分開，由共用規則整理同一份資料，再供各頁使用，能減少這類不一致。

靜態網站可固定同一版本的來源，先產生並驗證候選網站，再切換完整產物。這能在建置失敗時繼續提供前版，也讓網站差異有明確的來源版本可追查。

Foliohaven 採用這種分工：以 HTML 保存正文、JSON 保存屬性與設定，由 Core 整理資料，再交給 React 與 Astro／Vite 輸出網站；pnpm build 固定來源並驗證候選產物，通過後才更新完整網站。來源、原始媒體、工作快照與復原紀錄留在作者環境，備份包含這些資料，才能恢復可編輯、可重建的專案。

內容管理與公開網站的安全邊界

內容管理涉及修改文章、設定或部署，應限制操作人員與存取來源；公開端則只提供網站運作所需的內容、資源與功能。將兩者分開設計，可以減少公開服務暴露的管理能力，也讓帳號與檔案權限更容易界定。

需要遠端管理時，建議透過 VPN 或 SSH Tunnel 連回受控環境，並限制帳號與網路來源。若使用容器，連接埠與掛載也需配合管理範圍，分別限制網路入口與檔案存取；有多人協作需求時，也要規劃登入、角色與操作權限。

預覽內容也有獨立的信任邊界。編輯器可透過 iframe sandbox 與 CSP（內容安全政策）限制腳本、表單及外部資源；這些限制作用於預覽環境，直接發布作者 HTML 的系統，仍需在發布前檢查腳本、嵌入內容與敏感資訊。

以 Foliohaven 為例，Studio 與 Local Service 留在作者環境，Studio 經同源代理使用綁定 127.0.0.1 的 Local Service，管理請求需通過驗證；公開端交付建置完成的靜態網站。

Studio 的文章預覽使用上述隔離方式，完整互動則透過部署前預覽確認。Foliohaven 的公開產物排除管理程式、文章設定原檔、原始媒體、工作紀錄、source maps 及憑證，正式正文仍按可信任作者提供的 HTML 處理。

網站上線後，主機、依賴、管理帳號與部署憑證仍需持續維護。Foliohaven 的備份、版本更新與復原流程，將在第五篇接續說明。

架構取捨與適用情境

內容管理、公開服務與備份的分工，也決定了部署與維護成本。SSG 適合多數訪客取得相同內容、更新後可接受建置等待的網站。內容規模、即時性與互動需求改變時，應重新評估建置、交付與維護成本。

架構比較應固定內容、功能與快取條件，以內容交付、索引訊號、使用體驗及維護成本為依據。Foliohaven 將主要頁面提前產生，內容管理留在作者環境，必要互動再由前端程式或獨立服務處理。

下一篇從開發初期的 SEO 規劃開始，說明 SEO 設定的用途、簡潔設定與繼承機制，並示範實際設定流程。