第四章：結構化資料與 Schema Markup 實務解析

3.1 網站架構規劃與 URL 設計原則

為什麼網站架構是技術 SEO 的基礎

網站架構（Site Architecture）是指網站內各頁面的層級關係、分類方式，以及頁面之間的連結邏輯。它不只是資訊整理的問題，更直接影響搜尋引擎是否能有效檢索、理解與評估網站內容。

良好的網站架構，必須同時滿足兩個核心目標。第一，讓使用者能快速找到所需資訊；第二，讓搜尋引擎能順利抓取重要頁面，並清楚掌握網站主題脈絡。

從 SEO 的角度來看，網站架構可視為整體網站的基礎工程。若結構清楚，搜尋引擎較容易理解內容之間的關係，重要頁面也更有機會獲得良好的檢索與排名表現。相反地，若架構混亂、層級過深、導覽不清，即使內容本身具有價值，也可能因為不易被理解而影響整體成效。

扁平化架構原則

理想的網站架構應盡量採取扁平化設計，也就是從首頁出發，使用者或搜尋引擎能在較少點擊次數內抵達大多數重要頁面。實務上，常會以「三次點擊原則」作為規劃參考。

扁平化架構的優勢主要體現在三個層面。首先，可提升搜尋引擎爬蟲發現重要內容的效率，降低深層頁面不易被檢索的風險。其次，距離首頁越近的頁面，通常越容易承接網站內部的權重傳遞。最後，對使用者而言，資訊尋找路徑也會更直覺，能有效降低跳出率與迷失感。

常見且合理的網站層級如下：

首頁 → 分類頁 → 子分類頁 → 內容頁

若網站出現過深的層級，例如：

首頁 → 分類 → 子分類 → 次子分類 → 年份 → 月份 → 文章頁

則不論是 SEO 表現或使用者體驗，通常都較不理想。

分類與導覽規劃

主導覽列（Main Navigation）通常代表網站最核心的主題分類，因此不僅影響使用者瀏覽動線，也會成為搜尋引擎理解網站內容結構的重要依據。

在規劃分類時，建議掌握以下幾項原則。

首先，分類應具備明確區隔，避免彼此高度重疊。若不同分類之間界線模糊，搜尋引擎較難判斷網站主題分工，使用者也容易無法快速理解內容定位。

其次，分類名稱應站在使用者角度命名，盡量使用市場上常見、容易理解，且具有搜尋需求的詞彙，而非企業內部術語或過度抽象的名稱。

最後，主分類數量不宜過多。一般而言，主導覽列建議控制在 7 至 8 個以內。過多選項不只會增加選擇負擔，也可能分散網站主題焦點與內部權重配置。

麵包屑導覽（Breadcrumb）

麵包屑導覽是顯示頁面路徑層級的導覽元件，例如：

首頁 > 網頁設計 > RWD 響應式設計

它的價值不僅在於提示使用者目前所在位置，更有助於提升整體網站導覽性與搜尋引擎對頁面階層的理解。

對使用者而言，麵包屑導覽可快速說明頁面所屬分類，並提供返回上層頁面的便利路徑。對搜尋引擎而言，這類階層提示有助於理解頁面在整體網站中的角色。

若再搭配 BreadcrumbList 結構化資料，搜尋結果中甚至可能直接顯示麵包屑路徑，進一步提升搜尋片段的清晰度與點擊吸引力。

URL 設計原則

URL 是頁面的唯一地址，也是搜尋引擎理解頁面內容的重要輔助訊號。規劃良好的 URL，應具備以下特性。

• 1. 簡潔且具描述性
  使用者看到網址時，應能大致理解頁面主題。例如：
  較佳寫法：example.com/web-design/responsive-design
  較不理想的寫法：example.com/cat/sub-cat/2024/03/post?id=12847&ref=nav
• 2. 統一使用英文小寫與連字號
  建議使用小寫英文，並以連字號（-）作為單字分隔方式。應避免使用空格、底線或中文網址。雖然搜尋引擎能辨識中文 URL，但在分享與複製時，常會因編碼問題而降低可讀性。
• 3. 反映網站結構
  URL 路徑最好與網站分類邏輯一致，讓使用者與搜尋引擎能從網址本身理解頁面所屬脈絡。
• 4. 避免不必要的參數
  若索引頁面包含大量動態參數，例如 ?id=123&sort=date，可能增加重複內容風險，也會提高技術管理複雜度。若參數無法避免，應搭配 Canonical 標籤指定標準版本。
• 5. 維持穩定性
  URL 一旦建立並被搜尋引擎索引，原則上不應頻繁更動。若必須修改，應同步設定 301 永久轉址，避免流量與 SEO 訊號流失。

從架構角度思考內部連結

內部連結不只是單純在文章中加入超連結，而是一套協助搜尋引擎理解內容關聯與網站重點的結構策略。

重要頁面應獲得更多內部連結支持，主題相近的頁面則應形成清楚的內容群集。新發布的內容，也應從既有的重要頁面導入連結，協助搜尋引擎更快發現並理解其價值。

同時，也應避免出現孤立頁面（Orphan Pages），也就是沒有任何內部連結指向的內容。這類頁面即使存在，也可能因為檢索入口不足而難以獲得曝光。

3.2 網站速度優化與 Core Web Vitals

速度為什麼會影響 SEO

網站速度早已不只是工程層面的議題，而是影響 SEO 與使用者體驗的重要因素。Google 自 2010 年起即將網站速度納入排名考量，到了 2021 年 Page Experience 更新後，Core Web Vitals 更進一步成為正式的頁面體驗訊號。

其核心原因在於，搜尋引擎希望將使用者導向載入快速、互動流暢、瀏覽穩定的網站。若頁面載入時間過長，不僅會降低使用者停留意願，也容易造成跳出率上升與互動率下降。

此外，網站速度往往也與商業成效直接相關。尤其在行動裝置情境下，速度延遲常會影響詢價、註冊、購物等轉換表現。因此，速度優化不只是 SEO 問題，更是整體網站經營的重要環節。

Core Web Vitals 三大指標

Google 目前以三項核心指標評估頁面體驗，統稱為 Core Web Vitals。

LCP（Largest Contentful Paint，最大內容繪製）

LCP 用來衡量頁面主要內容出現在畫面中的速度，通常是主圖、主視覺區塊或主要內容容器完成顯示的時間。

• 良好標準為 2.5 秒以內。
• 介於 2.5 至 4 秒 之間，代表仍有改善空間。
• 超過 4 秒，則屬於表現不佳。

造成 LCP 過慢的常見原因包括伺服器回應時間過長、圖片資源過大、CSS 或 JavaScript 阻擋渲染，以及前端渲染流程過重等。

INP（Interaction to Next Paint，互動到下一次繪製）

INP 用來衡量頁面對使用者操作的反應速度，例如點擊按鈕、展開選單或輸入資料後，介面是否能快速回應。

• 良好標準為 200 毫秒以內。
• 介於 200 至 500 毫秒 之間，代表需要改善。
• 超過 500 毫秒，通常表示互動反應偏慢。

INP 表現不佳，常與主執行緒被大量 JavaScript 占用、第三方腳本過多、DOM 操作過重，或互動事件缺乏適當節流機制有關。

CLS（Cumulative Layout Shift，累計版面位移）

CLS 衡量頁面在載入過程中的版面穩定性，也就是畫面元素是否會突然位移，影響使用者操作與閱讀體驗。

• 良好標準為 0.1 以內。
• 介於 0.1 至 0.25 之間，代表仍需改善。
• 超過 0.25，則表示頁面穩定性不足。

常見成因包括圖片或影片未預留尺寸、字型載入造成跳動、動態插入廣告或嵌入模組，以及 JavaScript 即時改動版面配置等。

網站速度優化的核心方向

伺服器層面

網站速度優化應先從伺服器基礎開始。若目標客群集中在台灣，伺服器建議部署於台灣或鄰近東亞地區，以降低網路延遲。

此外，啟用 CDN、伺服器快取、HTTP/2 或 HTTP/3，以及 Gzip 或 Brotli 壓縮，也都是常見且有效的基礎優化手段。

圖片優化

圖片往往是頁面中最占資源的元素之一，因此是速度優化的重點項目。

建議優先採用 WebP 或 AVIF 等較高效率的圖片格式，並根據實際顯示尺寸提供適當大小的檔案，避免以過大圖片縮放顯示。首屏外圖片則可採用 Lazy Loading 延遲載入，減少初始載入負擔。

另外，所有圖片都應設定明確的 width 與 height，以提升版面穩定性並降低 CLS 問題。

CSS 與 JavaScript 優化

首屏所需的關鍵 CSS 應優先載入，非必要樣式則可延後處理。未使用的 CSS 也應定期清理，以減少無效資源負擔。

JavaScript 部分則應區分必要與非必要腳本，非關鍵資源可使用 defer 或 async 延後執行，大型套件則可依頁面需求拆分載入，以降低首屏壓力。

第三方資源管理

實務上，許多網站效能問題並非來自網站主體，而是過多的第三方資源，例如追蹤碼、聊天工具、社群模組或廣告腳本。

因此，建議定期盤點第三方腳本使用情況，刪除不必要工具，並盡可能將非核心資源延後載入，以減少對主執行緒與頁面效能的影響。

常用的速度檢測工具

• Google PageSpeed Insights 可提供 Core Web Vitals 的實測數據與優化建議。
• Google Search Console 的 Core Web Vitals 報告可協助檢查整站效能問題。
• Lighthouse 適合用於單頁效能分析。
• WebPageTest 則能提供更細緻的瀑布圖與多情境測試資料。

3.3 行動裝置優先索引（Mobile-First Indexing）

什麼是行動優先索引

Google 已將多數網站切換為行動優先索引（Mobile-First Indexing），也就是說，搜尋引擎會以行動版網站內容作為主要索引與排名依據，而非桌面版內容。

換言之，即使使用者最終是在桌面裝置上搜尋，Google 仍會優先參考手機版頁面的內容品質與結構完整性。

行動優先索引帶來的影響

在行動優先索引的架構下，最重要的原則就是：行動版內容不可明顯少於桌面版內容。

若桌面版保留完整文字、FAQ、表格、結構化資料與補充說明，但行動版因版面考量而大幅刪減，搜尋引擎可能只會根據行動版所呈現的內容進行評估，進而影響頁面整體價值判斷。

除了本文內容之外，結構化資料、Meta 標籤、圖片 ALT、影片資訊等，也都應在行動版完整保留，並與桌面版維持一致。

響應式設計（RWD）是最佳做法

Google 最推薦的實作方式是響應式網頁設計（Responsive Web Design, RWD）。RWD 使用相同的 HTML 與相同的 URL，再透過 CSS 依照裝置尺寸調整版面。

這種做法有幾個明顯優勢。首先，可避免多版本網址管理造成的 SEO 複雜度。其次，可降低桌機版與手機版內容不同步的風險。最後，對維護與開發而言，也通常更有效率。

行動體驗檢查重點

在檢查行動版 SEO 時，建議特別確認以下項目：

• 按鈕與連結是否足夠大，避免誤觸。
• 文字尺寸是否清楚易讀，內文通常建議至少 16px。
• 是否存在影響閱讀的蓋版廣告或過度干擾的彈出視窗。
• 內容是否不需水平捲動即可完整閱讀。
• 表格、圖表與互動元件在小螢幕上是否仍具良好操作體驗。

3.4 SSL / HTTPS 安全性設定

HTTPS 已不是加分項，而是基本要求

HTTPS 是 HTTP 的加密版本，透過 SSL/TLS 憑證保護瀏覽器與伺服器之間的資料傳輸安全。Google 早已將 HTTPS 視為排名訊號之一，而在現今網站環境中，它更接近基本門檻，而非額外加分項目。

若網站仍停留在 HTTP，瀏覽器通常會顯示不安全警示，這不僅影響搜尋表現，更會直接削弱使用者對品牌與網站的信任感。

SSL 憑證的常見類型

常見的 SSL 憑證可分為 DV、OV 與 EV 三種。

• DV 憑證僅驗證網域所有權，適合多數一般企業網站。
• OV 憑證除網域外，也會驗證企業身分。
• EV 憑證則屬於較完整的企業驗證方式。

不過，從 SEO 角度來看，這三種憑證之間並沒有明確的排名差異。對大多數網站而言，真正重要的是是否穩定、安全且正確地完成 HTTPS 部署。

HTTPS 遷移時的注意事項

若網站由 HTTP 遷移至 HTTPS，需同步完成以下檢查與更新：

• 將所有 HTTP 頁面以 301 轉址至 HTTPS 版本。
• 更新網站內部連結。
• 更新 XML Sitemap。
• 確認 Canonical 指向 HTTPS 版本。
• 重新在 Google Search Console 驗證 HTTPS 屬性。
• 更新 robots.txt 中的 Sitemap 路徑。
• 檢查 CSS、JavaScript、圖片等資源是否仍引用 HTTP，避免產生 Mixed Content 問題。

3.5 XML Sitemap 建立與提交

XML Sitemap 是什麼

XML Sitemap 可視為提供給搜尋引擎的網站地圖，用來列出希望被檢索與索引的重要頁面，協助搜尋引擎更有效率地掌握網站內容。

它對大型網站、新網站、更新頻繁的網站，或架構較複雜的網站尤其重要。

XML Sitemap 應包含哪些資訊

標準 Sitemap 通常會包含以下欄位：

• <loc>：頁面完整網址
• <lastmod>：最後修改日期
• <changefreq>：預期更新頻率
• <priority>：頁面相對重要性

其中最重要的是 <loc>。<lastmod> 亦有參考價值，但前提是該日期必須反映實際內容更新時間，而非為了表面維護頻率而任意更新。

Sitemap 的最佳做法

Sitemap 應僅列出真正希望被索引的正式頁面。

不應納入 noindex 頁面、被 robots.txt 阻擋的頁面、404 頁面，或已經 301 轉址的舊網址。所有收錄於 Sitemap 的 URL，原則上都應正常回傳 200 狀態碼。

若網站規模較大，超過單一 Sitemap 的限制，建議使用 Sitemap Index，並依內容類型拆分，例如文章、商品、分類頁等分別建立。

若網站內容更新頻繁，則建議由 CMS 或後端系統自動生成 Sitemap，以降低人工維護風險。完成後，也應提交至 Google Search Console，並在 robots.txt 中標示 Sitemap 路徑。

圖片 Sitemap 與影片 Sitemap

若網站包含大量圖片或影片，也可額外建立圖片 Sitemap 或影片 Sitemap。這有助於搜尋引擎更完整理解媒體資源內容，進一步提升圖片搜尋或影片搜尋的曝光機會。

3.6 robots.txt 設定與檢索控制

robots.txt 的作用

robots.txt 是放置於網站根目錄下的純文字檔案，用來告知搜尋引擎哪些路徑可檢索、哪些路徑不建議檢索。

它是網站與搜尋引擎之間的重要溝通機制之一，搜尋引擎通常會先讀取 robots.txt，再決定後續的檢索策略。

不過，robots.txt 並不是安全防護工具。它只能對遵守規範的爬蟲提供指示，無法阻止惡意機器人或保護敏感資料，因此不適合作為權限控管手段。

基本語法

robots.txt 常見指令包括：

• User-agent：指定規則適用的爬蟲
• Disallow：禁止檢索某一路徑
• Allow：在限制範圍內允許特定路徑
• Sitemap：告知 XML Sitemap 的位置

常見設定情境

• 管理後台與登入頁面通常不需要被檢索。
• 站內搜尋結果頁通常不建議索引，以避免形成大量低品質頁面。
• 篩選與排序產生的大量參數頁，也應視情況加以控制。
• 測試站或開發站則更應明確阻擋，避免被意外收錄。

常見錯誤

最常見也最嚴重的錯誤，是誤擋重要頁面。若 Disallow 規則設定錯誤，可能使整個重要目錄無法被搜尋引擎檢索。

另一項常見誤解，是將 Disallow 視為 noindex。實際上，Disallow 只是阻止爬蟲抓取內容，並不保證頁面不會出現在搜尋結果中。若目的是避免索引，應透過 noindex 進行處理。

此外，也應避免阻擋 CSS 或 JavaScript 檔案，否則可能影響搜尋引擎正確渲染頁面內容。

3.7 Canonical 標籤與重複內容處理

重複內容為什麼需要處理

重複內容是指不同 URL 呈現相同或高度相似的內容。這類情況在網站實務中十分常見，例如 HTTP 與 HTTPS 並存、網址有無結尾斜線、商品篩選參數產生多個版本、列印頁與正式頁共存，或改版後新舊網址未整合等。

若未妥善處理，搜尋引擎可能難以判斷哪一頁才是標準版本，進而造成權重分散、檢索資源浪費，甚至影響索引判斷。

Canonical 的作用

Canonical 標籤是放在 HTML head 區塊中的標記，用來告知搜尋引擎某頁面的標準版本 URL。

例如：

<link rel="canonical" href="https://example.com/page/" />

透過 Canonical，可協助搜尋引擎將相似頁面的訊號集中於指定的正式版本。

Canonical 的使用原則

• 每個頁面都建議設置 Canonical。即使只有單一版本，也建議採用 self-referencing canonical 指向自己。
• Canonical 應指向可索引、可正常開啟的正式頁面。
• 應使用完整的絕對網址，而非相對路徑。
• 同一組重複內容的不同版本，Canonical 應一致指向同一個標準頁。

需要注意的是，Canonical 屬於強烈建議，而非強制命令。若搜尋引擎認為指定不合理，仍可能自行判定其他頁面為標準版本。

其他處理重複內容的方法

• 若舊網址已不再使用，最直接的方式通常是設定 301 轉址。
• 若頁面不希望出現在搜尋結果中，可使用 noindex。
• 若問題主要來自大量參數網址，則應從網站架構與參數管理策略上進一步優化。

3.8 Hreflang 多語系 / 多地區設定

Hreflang 的用途

Hreflang 用來告知搜尋引擎，同一內容存在不同語言或不同地區版本，協助 Google 將最適合的頁面顯示給相對應的使用者。

例如，若網站同時提供繁體中文（台灣）與英文版本，Hreflang 可協助搜尋引擎判斷台灣使用者應優先看到哪一個版本，其他地區使用者則應對應顯示其他語言頁面。

適用情境

Hreflang 特別適合以下情境：

• 多語系網站，例如中、英、日三種語言版本。
• 多地區但同語言網站，例如 zh-TW 與 zh-HK。
• 同時面向多語言與多市場的國際型網站。

常見錯誤

Hreflang 最常見的問題之一是缺少回指，也就是 A 頁指向 B 頁，但 B 頁未反向指回 A 頁，導致設定不被完整採納。

另一項常見錯誤是語言碼與地區碼格式不正確，例如大小寫錯誤、使用底線分隔等。

此外，也建議設定 x-default 作為預設版本，以便在搜尋引擎無法明確判斷語言或地區時提供對應頁面。

還需特別注意，Hreflang 與 Canonical 不可互相衝突。每個語言版本的 Canonical 應指向自己，而非指向其他語系頁面，否則會削弱該語言版本的存在價值。

台灣企業常見應用

對台灣企業而言，常見的多語系組合包括：

• 繁體中文（zh-TW）＋英文（en）
• 繁體中文（zh-TW）＋簡體中文（zh-CN）
• 英文（en）＋東南亞在地語言版本

若網站目標客群橫跨多國市場，Hreflang 是不可忽略的重要技術設定。

3.9 301 / 302 轉址策略與常見錯誤

常見轉址類型

• 301 代表永久轉址，適合網址永久更換、網站改版或頁面正式整併。
• 302 代表暫時轉址，適合短期活動、測試或暫時性導流。
• 307 與 302 性質相近，但技術規則更嚴謹。
• 308 則與 301 類似，同樣代表永久轉移。

從 SEO 的角度來看，最重要的是正確區分「永久變更」與「暫時變更」兩種情境。

什麼情況應使用 301

以下情境通常應使用 301：

• 網站更換網址
• 網站改版後頁面重新對應
• HTTP 遷移至 HTTPS
• 舊頁面下線並導向新頁
• 相近內容頁整併至同一正式頁

什麼情況可使用 302

以下則較適合使用 302：

• 短期活動頁導流
• A/B 測試
• 暫時性維護
• 短期地區分流

常見錯誤

最常見的問題是永久改址卻使用 302，導致搜尋引擎誤以為舊頁仍是正式版本，進而延後權重移轉與索引更新。

另一項常見錯誤是轉址鏈，例如 A → B → C → D。這不僅增加載入時間，也會浪費搜尋引擎檢索資源。理想做法應是直接由 A 指向 D。

此外，也應避免轉址迴圈，例如 A 指向 B、B 又指回 A，造成頁面無法開啟。

最後，不建議將大量不相關的舊頁一律導向首頁。這類做法通常無法有效保留頁面價值，甚至可能被視為軟性 404。較合理的方式，是將舊頁一對一導向最相關的新頁面。

3.10 網站可檢索性診斷與除錯

可檢索性是技術 SEO 的第一步

若搜尋引擎無法順利檢索網站，後續的索引、理解與排名都將失去基礎。因此，可檢索性可說是技術 SEO 的第一道檢查關卡。

常見的可檢索性問題

若伺服器頻繁回傳 500、502、503 等錯誤，搜尋引擎便無法穩定讀取頁面。若此類情況持續發生，甚至可能導致 Google 降低網站檢索頻率。

404 頁面本身不一定有害，但若大量重要舊網址失效且未妥善轉向，就可能浪費原本累積的外部連結價值。

此外，robots.txt 設定錯誤、忘記移除 noindex、Canonical 指向錯誤頁面、重要頁面缺乏內部連結支持，也都是實務上常見的可檢索性問題。

常用診斷工具

• Google Search Console 是最重要的官方診斷工具，可用來確認頁面索引狀態、未收錄原因與檢索異常。
• Screaming Frog SEO Spider 可模擬搜尋引擎爬蟲掃描整站，找出斷鏈、轉址鏈、重複標題與遺漏描述等問題。
• Ahrefs、Semrush 等工具也提供站台稽核功能，適合定期追蹤網站技術健康度。

建議的診斷流程

技術 SEO 的檢查不宜零散進行，建議依照以下順序系統化檢查：

• 先確認 robots.txt 是否誤擋重要頁面。
• 再檢查 Sitemap 是否正確且可提交。
• 接著查看 Search Console 的索引狀態與覆蓋情況。
• 之後使用爬蟲工具掃描整站。
• 最後再進一步檢查 Core Web Vitals、行動體驗與結構化資料。

透過這樣的流程，較能從「是否可被檢索」一路檢查到「是否可被理解與排名」。

3.11 JavaScript SEO 與動態渲染

為什麼 JavaScript 會影響 SEO

現代網站常使用 React、Vue、Angular、Next.js、Nuxt.js 等前端框架，以提供更流暢的互動體驗。然而，這些技術也可能增加搜尋引擎讀取與理解內容的難度。

傳統網站通常在首次載入時就能提供完整 HTML，而 JavaScript 架構的網站，則常需先執行腳本後才會生成完整內容。若搜尋引擎無法及時完成渲染，便可能導致內容檢索延遲，甚至部分資訊無法被正確讀取。

Google 如何處理 JavaScript

Google 的確具備執行 JavaScript 的能力，但並非毫無限制。

一般而言，Google 會分為兩個階段處理頁面：先抓取初始 HTML，再排程執行 JavaScript 進行渲染。這代表若頁面主要內容依賴 JavaScript 動態產生，索引速度往往會較慢。

此外，JavaScript 渲染需要更多運算資源，並非所有頁面都能在短時間內被完整處理。

常見解法

• 伺服器端渲染（SSR）
  由伺服器先產出完整 HTML，再交由瀏覽器載入。這是對 SEO 較友善的做法之一。
• 靜態網站生成（SSG）
  在網站建置階段預先產出靜態 HTML，具備速度快、穩定性高的優勢，適合部落格、品牌官網與知識型網站。
• 增量靜態更新（ISR）
  兼顧靜態輸出速度與內容更新彈性，適合希望平衡效能與維護效率的網站。
• 動態渲染（Dynamic Rendering）
  針對搜尋引擎與一般使用者提供不同版本，可作為過渡解法，但通常不建議作為長期依賴方案。

JavaScript SEO 檢查重點

• 重要內容不應完全依賴客戶端 JavaScript 才顯示。
• 內部連結應使用標準 <a href> 標記。
• Title、Description、Canonical、hreflang 等關鍵標籤應可被搜尋引擎正確讀取。
• 結構化資料也應在渲染後完整存在。
• 可透過 Search Console 的網址檢測工具或 Rich Results Test，確認搜尋引擎實際看到的頁面內容。

3.12 Log File 分析

什麼是 Log File 分析

Log File 分析是透過伺服器存取日誌，直接觀察搜尋引擎爬蟲實際如何造訪網站的分析方式。

這類分析之所以重要，在於它並非根據工具估算，而是直接來自真實紀錄。透過 Log File，可以掌握 Googlebot 何時造訪網站、造訪頻率、檢索了哪些頁面、遇到哪些錯誤，以及檢索資源實際分配在哪些內容上。

Log File 能協助觀察什麼

透過 Log File，可進一步了解：

• 搜尋引擎爬蟲的檢索頻率是否穩定。
• 哪些頁面最常被檢索，哪些重要頁面幾乎沒有被造訪。
• 是否存在大量浪費檢索預算的行為，例如爬取 404、參數頁、後台頁等低價值內容。
• 新發布內容是否能被搜尋引擎快速發現。
• 網站是否存在過多 301、404 或 5xx 狀態碼問題。

如何取得 Log File

Log File 的存放位置會依伺服器環境而異。無論是 Apache、Nginx、共享主機或 CDN，取得方式都可能不同。若為大型網站，通常會由主機商、DevOps 團隊或系統管理人員協助匯出。

分析重點

在實務上，建議優先觀察以下幾個方向：

• Googlebot 檢索量是否有異常升降。
• HTTP 狀態碼分布是否健康，200 應占多數。
• 是否存在過多 301、404 或 5xx。
• 搜尋引擎是否過度消耗資源在低價值頁面。
• 重要頁面是否確實被檢索。
• 新內容是否能被快速發現與處理。

對小型網站而言，透過 Excel 或 Google Sheets 即可完成基本篩選分析。若網站規模較大，則可搭配 Screaming Frog Log File Analyser 等工具進行更深入的檢視。

本章重點回顧

技術 SEO 是整體 SEO 策略的基礎工程。網站架構決定搜尋引擎能否順利發現與理解頁面；網站速度與 Core Web Vitals 影響排名與使用體驗；行動優先索引則要求網站在手機版內容與體驗上維持完整性。

同時，XML Sitemap 與 robots.txt 是網站與搜尋引擎溝通的重要工具；Canonical 可協助處理重複內容；Hreflang 則是多語系網站不可忽略的技術設定；而正確的轉址策略，關係到權重與流量能否順利承接。

若網站採用 JavaScript 架構，也必須確保搜尋引擎能有效讀取內容；進一步透過 Log File 分析，則能從實際爬蟲行為中掌握網站的技術健康狀態。

總結而言，技術 SEO 的核心，不在於單一設定是否完成，而在於網站是否真正具備「可檢索、可理解、可載入、可使用」的整體基礎。只有當這些基礎穩定到位，內容策略與外部優化才更容易發揮效果。

問與答（FAQ）