Canonical: https://seo.whoops.com.tw/site-code-optimization/
Author: Sliven 褚崇名
Source robots: follow, index, max-snippet:-1, max-video-preview:-1, max-image-preview:large
Content modified (WordPress): 2026-11-14T10:31:59+00:00
Representation modified (content/template/converter): 2026-11-14T10:31:59+00:00

# 最佳網站程式碼 SEO 完整教學：從 Core Web Vitals 到程式碼層優化

 

圖片：網站程式碼最佳化完整指南：從 Core Web Vitals 到 AI 搜尋，非工程師也能做對的程式碼層 SEO精選圖片，呈現檢查 → 修復 → 驗證的 SEO 重點。（來源：https://seo.whoops.com.tw/wp-content/uploads/2026/06/site-code-optimization-featured-image.webp）

 

撰文作者 

[Sliven 褚崇名](<https://seo.whoops.com.tw/about/#founder-title>)

 

Whoops SEO 創辦人

 

SEO 與 AI SEO 專家，專長涵蓋技術 SEO、內容策略與 GEO 優化。從搜尋排名到 AI 答案中的品牌呈現，協助企業找出優化機會、排定執行順序，並追蹤實際成效。

 

圖片：Sliven 褚崇名肖像（來源：https://seo.whoops.com.tw/wp-content/uploads/2026/10/sliven-portrait-navy.webp）

 

[作者背景與專業領域](<https://seo.whoops.com.tw/about/#founder-title>) 更新 2026-11-14 約 18 分鐘閱讀

 

本篇內容

 

### 本篇內容

 

## 先看重點

摘自本文

- 程式碼最佳化不是裝更多外掛，而是先修掉渲染阻塞、語意化標籤、結構化資料這三件事，Core Web Vitals 三指標及格門檻 LCP 2.5 秒、INP 200 毫秒、CLS 0.1（來源：web.dev），做對一次同時服務傳統 SEO 與 AI 搜尋。

[文章開頭](<https://seo.whoops.com.tw/site-code-optimization/#article-body-start>)
- 渲染阻塞資源是指那些瀏覽器在畫出第一個畫面前必須先讀完的 CSS 與 JavaScript，讀愈久、畫面出來愈晚，直接拖慢 LCP。

[渲染阻塞資源怎麼解：CSS 與 JavaScript 的載入策略](<https://seo.whoops.com.tw/site-code-optimization/#%E6%B8%B2%E6%9F%93%E9%98%BB%E5%A1%9E%E8%B3%87%E6%BA%90%E6%80%8E%E9%BA%BC%E8%A7%A3%EF%BC%9ACSS-%E8%88%87-JavaScript-%E7%9A%84%E8%BC%89%E5%85%A5%E7%AD%96%E7%95%A5>)
- 先量測再動手：用 PageSpeed Insights 與 Search Console 的 Core Web Vitals 報告找出紅字，然後按「影響大、風險低」的順序處理。

[實戰步驟：按優先順序的程式碼最佳化檢查清單](<https://seo.whoops.com.tw/site-code-optimization/#%E5%AF%A6%E6%88%B0%E6%AD%A5%E9%A9%9F%EF%BC%9A%E6%8C%89%E5%84%AA%E5%85%88%E9%A0%86%E5%BA%8F%E7%9A%84%E7%A8%8B%E5%BC%8F%E7%A2%BC%E6%9C%80%E4%BD%B3%E5%8C%96%E6%AA%A2%E6%9F%A5%E6%B8%85%E5%96%AE>)

 

### 檢查網站的 SEO 基礎

從網站網址開始，檢視可讀性與頁面基礎訊號。

- 檢查標題與搜尋摘要標記
- 核對 canonical 與索引指令
- 整理公開 HTML 的待改善項目

[免費檢查網站](<https://seo.whoops.com.tw/free-seo-audit/>)[技術 SEO 顧問與健檢](<https://seo.whoops.com.tw/services/technical-seo-consultant/>)

 

[將 Whoops 設為 Google 偏好來源（另開 Google 設定頁）](<https://www.google.com/preferences/source?q=seo.whoops.com.tw>)

 

網站程式碼最佳化指的是調整 HTML、CSS、JavaScript 與結構化資料，讓頁面載入更快、結構更清楚，搜尋引擎與 AI 都更容易讀懂。它影響的是 Core Web Vitals 這組頁面體驗訊號，官方訂出的及格門檻是 LCP 在 2.5 秒以內、INP 在 200 毫秒以內、CLS 在 0.1 以內（來源：Google Search Central 與 web.dev）。把程式碼最佳化當萬靈丹會失望，但長期放著不處理，排名與體驗都會被對手拉開。

 

這篇文章不講空泛的 On-Page 概念，而是直接把報告裡那些紅字對應到實際的 HTML、CSS、JavaScript 該怎麼改，並且分清楚哪些你自己能做、哪些該交給開發者。讀完你會知道該先量測什麼、按什麼順序動手、以及 2027 年 AI 搜尋崛起之後，這些程式碼層的努力到底還值不值得。

 

> TL;DR：程式碼最佳化不是裝更多外掛，而是先修掉渲染阻塞、語意化標籤、結構化資料這三件事，Core Web Vitals 三指標及格門檻 LCP 2.5 秒、INP 200 毫秒、CLS 0.1（來源：web.dev），做對一次同時服務傳統 SEO 與 AI 搜尋。

 

## 網站程式碼最佳化是什麼：它跟 SEO 的關係，一句話講清楚

 

圖片：網站程式碼最佳化完整指南：從 Core Web Vitals 到 AI 搜尋，非工程師也能做對的程式碼層 SEO的文內圖，呈現速度、渲染、索引、體驗等 SEO 重點流程。（來源：https://seo.whoops.com.tw/wp-content/uploads/2026/06/site-code-optimization-seo.webp）

程式碼最佳化：檢查 → 修復 → 驗證。

 

會影響排名，但不是單獨決定排名的最大因素。網站程式碼最佳化屬於[技術 SEO](<https://seo.whoops.com.tw/technical-seo/>)底下的一環，調整的是 HTML、CSS、JavaScript 與結構化資料這層「地基」，讓頁面載入更快、結構更清楚，爬蟲與 AI 引擎都更容易讀懂。它對應到的排名因素是[頁面體驗訊號](<https://seo.whoops.com.tw/what-is-core-web-vitals/>)（page experience），這組訊號是必要條件，但不是充分條件，內容與連結仍然佔有很大比重。放回[搜尋引擎優化流程](<https://seo.whoops.com.tw/what-is-seo/>)來看，程式碼層只是其中一塊拼圖，但卻是最容易被拖延、也最容易被低估的一塊。

 

你打開 PageSpeed Insights 看到一片紅字，第一個念頭是不是「算了，改天再說」？說實話這個坑我也踩過，紅字看久了會麻痺，久了就當它不存在。可是這些紅字背後對應的，多半是幾行程式碼沒處理好，不是什麼需要重寫網站的大工程。與其每天追[演算法更新](<https://seo.whoops.com.tw/google-algorithm-updates/>)的風聲，不如先把眼前能掌握的程式碼層訊號穩住。

 

把程式碼層與內容層的關係想成蓋房子：程式碼是地基，內容是樓。地基不穩，樓蓋得再漂亮也會被拖累；地基穩了，你的[On-Page SEO 內容最佳化](<https://seo.whoops.com.tw/on-page-seo-content-optimization/>)才會真正發揮效果。很多站長把心力全押在寫文章，卻忽略了頁面根本載不快、結構根本讀不懂，這時候再好的內容也會被卡住。這也是為什麼 Google 的[實用內容指引](<https://seo.whoops.com.tw/google-updates-helpful-content-guidance-0425/>)會把頁面體驗與內容品質綁在一起談，兩者本來就不該分開。

 

### 反直覺的地方：最佳化常常是「拿掉」，不是「加上去」

 

多數人以為程式碼最佳化等於「裝更多效能外掛」，但裝太多外掛本身就是網站變慢的主因之一。真正的最佳化常常是刪掉沒用到的 CSS、移除重複的功能、把會阻塞畫面的資源往後挪。這個觀念會貫穿整篇文章，也是我把[網站架構最佳化](<https://seo.whoops.com.tw/website-architecture-optimization/>)與程式碼層分開講的原因：架構層管的是網站怎麼組織，程式碼層管的是每一頁的程式怎麼跑。

 

交給 AI 改前端時，也可參考[讓編碼代理採用現代 HTML 與 CSS 的方法](<https://seo.whoops.com.tw/modern-web-guidance/>)，先核對可用的原生功能，再決定哪些 JavaScript 能移除；專案的測試指令與相容性條件，則用[AGENTS.md 的專案規則寫法](<https://seo.whoops.com.tw/what-is-agents-md/>)留下明確要求。

 

## HTML 語意化標籤：搜尋引擎看的第一層結構

 

語意化標籤告訴搜尋引擎與 AI「這段內容的重要程度與角色是什麼」。正確使用 H1 到 H6，加上 header、nav、main、article、section、footer 這些標籤，能讓爬蟲快速理解頁面層級，也讓 AI 更容易抽出可引用的段落。規則很樸素：一頁一個 H1、用 H2 到 H6 表達層次、不要拿標題標籤來控制字的大小。

 

### 標題層級的黃金規則

 

我看過有人把整段促銷文案都塞進 H1，結果搜尋引擎根本不知道這頁在講什麼，排名當然上不來。標題標籤是給機器看地圖用的，不是給設計師調字級用的，這兩件事千萬別混為一談。字的大小交給 CSS 處理，標題交給 HTML 結構。

 

- 一頁一個 H1，對應頁面主題，通常等同 標題標籤的核心訊息。 
- H2 到 H6 表達層次，不跳級，不要 H2 直接接 H4，中間少一層會讓機器誤判結構。 
- 語意化標籤分工：header 是頁首、nav 是導覽、main 是主內容、article 是獨立文章、aside 是側欄、footer 是頁尾。 
- 標題不等於字型大小，要放大字用 CSS 的 font-size，不是把段落標成 H3。

 

### 結構清楚，AI 才抽得出答案

 

語意化標籤對 AI 引擎的好處特別明顯。結構越清楚，AI 越容易把某個段落當成獨立的答案區塊抽出來引用。這點在 2027 年的搜尋環境裡越來越重要，因為 [AI Overview](<https://seo.whoops.com.tw/what-is-google-ai-overviews/>)、ChatGPT、Perplexity 都會掃整篇結構來決定要引用哪一段。配上清楚的[中繼描述](<https://seo.whoops.com.tw/accurate-meta-tag-of-description/>)與標題層級，機器讀你的頁面會輕鬆很多。如果你想更系統地搞懂標題的用法，[標題標籤 SEO 指南](<https://seo.whoops.com.tw/heading-tags-for-seo-by-google/>)有 Google 官方版本的說明，可以對著自己的頁面逐條檢查。

 

## Core Web Vitals 三指標：LCP、INP、CLS 各代表什麼、及格標準多少

 

Core Web Vitals 是 Google 用來衡量頁面體驗的三個核心指標：LCP 衡量主要內容載入多快、INP 衡量互動回應多快、CLS 衡量視覺穩定度。三個指標要同時達到 Good 才算整體及格，用的是 28 天田野資料的第 75 百分位，不是看單次實測分數，而是看多數真實使用者的體驗。詳細的指標定義可以參考[Core Web Vitals 指標定義](<https://seo.whoops.com.tw/what-is-core-web-vitals/>)。

 

### 實驗室分數不等於田野分數

 

你是不是也以為 PageSpeed 那個 90 分就代表網站很快？其實那只是單次實驗室分數，跟田野資料的第 75 百分位是兩回事。實驗室分數是你自己測的那一次，田野資料是過去 28 天真實訪客的體驗，後者才是 Google 用來判斷排名的依據。兩個數字方向一致最好，但如果實驗室分數高、田野分數卻是紅字，代表真實使用者的設備或網路條件比你測試時差很多，這時要往手機端與資源大小去排查。

 

| 指標 | 衡量什麼 | Good（及格） | Needs improvement（需改善） | Poor（不及格） |
| --- | --- | --- | --- | --- |
| LCP（最大內容繪製） | 主要內容繪製完成時間 | ≤ 2.5 秒 | 2.5 到 4 秒 | ＞ 4 秒 |
| INP（互動到下一次繪製） | 互動回應延遲 | ≤ 200 毫秒 | 200 到 500 毫秒 | ＞ 500 毫秒 |
| CLS（累積版面位移） | 視覺穩定度 | ≤ 0.1 | 0.1 到 0.25 | ＞ 0.25 |

 來源：Google Search Central 與 web.dev 官方文件，門檻以田野資料第 75 百分位為準。

 

三個指標裡，最容易被忽略的是 INP。它在 2024 年 3 月正式取代了舊的 FID 指標，很多原本分數還行的網站被這次切換拉了下來，因為 INP 衡量的不只是第一次點擊，而是整段互動過程的回應速度。如果你只在 2024 年以前做過效能最佳化，現在回頭看報告，很可能 INP 已經變紅了。這個變化跟 Google 對[行動優先索引](<https://seo.whoops.com.tw/google-mobile-first-index-algorithm-point/>)的重視是一致的：手機 CPU 較弱，互動延遲更容易被放大。

 

- LCP 查什麼：通常是首圖太大、伺服器回應太慢、或關鍵 CSS 阻塞渲染。 
- INP 查什麼：通常是 JavaScript 太重、主執行緒被卡住、或第三方腳本太多。 
- CLS 查什麼：通常是圖片沒設尺寸、字型載入造成跳動、或廣告區塊動態插入。 
- 查詢工具：PageSpeed Insights、Google Search Console的 Core Web Vitals 報告、Chrome UX Report；搭配[整合 Lighthouse 的 PageSpeed Insights](<https://seo.whoops.com.tw/pagespeed-insights-revamped-with-lighthouse/>)一起看更全面。

 

整體速度問題另有專文處理，這裡聚焦程式碼層；想看主機、網路與整體策略的讀者，可以參考[網站速度](<https://seo.whoops.com.tw/website-speed-matters/>)的完整討論。如果你卡在「速度變慢是不是被[核心演算法更新](<https://seo.whoops.com.tw/google-may-2026-core-update/>)影響」，記得先排除程式碼層的問題，再去想演算法，順序反了會白忙一場。

 

## 渲染阻塞資源怎麼解：CSS 與 JavaScript 的載入策略

 

渲染阻塞資源是指那些瀏覽器在畫出第一個畫面前必須先讀完的 CSS 與 JavaScript，讀愈久、畫面出來愈晚，直接拖慢 LCP。解法分三層：把關鍵 CSS 內嵌或提前、用 defer 或 async 讓 JavaScript 不阻塞、把首屏用不到的資源延後載入。原則是讓使用者先看到畫面，再讓瀏覽器慢慢把剩下的補齊，而不是一次把所有東西都卡在前面。

 

把渲染阻塞想成結帳櫃台，所有人都在等同一個慢動作的店員，你只要把不用結帳的人先放走，隊伍就快了。CSS 與 JavaScript 就是那些堵在櫃台前的資源，能挪到後面的就挪，能不擋第一個畫面就不要擋。

 

### 關鍵 CSS 與延後載入

 

關鍵 CSS（critical CSS）指的是首屏需要的最小 CSS。把這一小段直接內嵌進 HTML，瀏覽器就不用等外部 CSS 檔下載完才畫畫面；至於首屏用不到的 CSS，可以用媒體查詢或 JavaScript 延後載入。圖片與 iframe 則用 loading=lazy，等使用者捲到附近才抓，這對圖片 SEO同時有幫助。Google 對於 JavaScript 的抓取有自己的一套流程，想了解爬蟲怎麼讀 JS，可以看[Google 抓取 JavaScript 連結](<https://seo.whoops.com.tw/google-will-crawl-the-javascript-link-to-the-indexed-site/>)的說明。

 

- defer：JavaScript 按順序執行、不阻塞 HTML 解析，適合有相依性的腳本。 
- async：JavaScript 各自抓、抓完就跑、不保證順序，適合獨立的第三方追蹤碼。 
- minify 與壓縮：把 CSS 與 JS 壓縮、用 gzip 或 brotli 傳輸、刪掉沒用到的程式碼（tree shaking）。 
- 現代圖片格式：用 WebP 或 AVIF 取代 PNG 與 JPG，檔案更小、畫質相近（來源：web.dev 圖片最佳化指南）。

 

這裡要小心，不是所有 script 都能隨便 async。有相依性的腳本（例如 A 函式庫要等 B 先載入）用錯順序會讓功能壞掉，這部分建議先在測試環境試，確認沒問題再上正式站。我自己會把這層調整直接交給工程師，因為 defer 用錯順序真的會把網站弄壞，不值得自己冒險。如果你的站還在用 HTTP/1.1，順手升級到[HTTP/2](<https://seo.whoops.com.tw/what-is-http2/>)也能讓多個資源並行下載，這是不用改程式碼就能拿到的小幅提升。

 

## 結構化資料與 JSON-LD：讓 Google 與 AI 都看得懂的內容標記

 

結構化資料是用標準格式把頁面內容的角色講清楚，例如這頁是文章、是 FAQ、是產品、是麵包屑。Google 推薦的格式是 JSON-LD，做法是在頁面放一段 script，只標記與內容相符的 schema。它不會直接衝高排名，但能幫助搜尋引擎與 AI 正確理解內容、爭取[複合式搜尋結果](<https://seo.whoops.com.tw/the-study-shows-featured-snippet-will-have-bad-effect/>)與 AI Overview 引用。想深入了解標記本身，可以看[結構化資料指南](<https://seo.whoops.com.tw/what-is-structured-data/>)；電商站則別漏掉[產品結構化資料](<https://seo.whoops.com.tw/what-is-structured-data/>)，它直接影響商品頁能不能拿到價格與庫存的 rich result。

 

### 用外掛自動帶入，不用手寫 JSON

 

你可能覺得結構化資料聽起來很工程，其實 WordPress 用 Rank Math 這類外掛就能自動帶入大半。你不用自己手寫 JSON，外掛會根據你設定的文章類型、麵包屑、組織資訊自動產出對應的標記，剩下的只要在發文時勾選就好。問答類頁面還可以參考[QAPage 結構化資料](<https://seo.whoops.com.tw/google-expands-rich-results-for-qa-page/>)的做法，讓問答內容更容易出現在複合式結果裡。

 

- JSON-LD 是 Google 推薦格式，放在 `` <script type="application/ld+json"> `` 裡。 
- 常見 schema：Article、FAQPage、BreadcrumbList、Organization、WebSite、Product。 
- 只標記與頁面內容相符的 schema，不相符反而可能被判定為垃圾標記。 
- 驗證工具：Google Rich Results Test、Schema Markup Validator。

 

結構化資料不會讓你一夜衝上第一頁，但它會讓你的內容在 AI 搜尋時代更容易被正確引用，這條投資長期很划算。相對地，也不要神化它，schema 對排名的直接因果關係有限，它扮演的是「讓機器更懂你」的輔助角色，搭配良好的Schema 標記習慣即可。

 

## WordPress 常見錯誤：為什麼裝了快取外掛還是慢

 

會變慢。WordPress 變慢最常見的程式碼層原因不是單一外掛，而是外掛之間互相疊加。每個外掛都會注入自己的 CSS 與 JS、做自己的資料庫查詢、掛自己的 hook，就算裝了快取外掛，如果同時跑著會持續掃描的效能監控、社群按鈕、頁面編輯器，快取救不回被這些程式碼拖慢的瓶頸。診斷順序是先用 Query Monitor 看哪個外掛最耗時，再決定停用、取代或瘦身。如果你的站剛改版完才開始變慢，也要對照[網站改版的 SEO 自保](<https://seo.whoops.com.tw/how-long-does-it-take-to-re-update-the-site/>)流程，確認不是改版過程動到了關鍵程式碼。

 

### 診斷順序：先找兇手，再決定停用或取代

 

很多人看到紅字第一反應是再裝一個外掛，結果是藥加藥。我接手過一個裝了四十幾個外掛的網站，停掉其中一半的效能與監控外掛後，反而比原本還快，因為那些加速外掛本身也在搶資源。這聽起來反直覺，但實務上很常見。如果你連搜尋引擎到底怎麼讀你的站都不確定，先回頭看[Google 搜尋的運作方式](<https://seo.whoops.com.tw/google-search-operation-way/>)，搞懂爬蟲流程再來改程式碼，方向會更準。

 

- 外掛過多：每個外掛都注入 CSS 與 JS、做查詢，互相疊加就是變慢主因，[外掛管理](<https://seo.whoops.com.tw/site-kit-by-google/>)要定期盤點。 
- 吃資源外掛：即時流量監控、壞連結掃描、不斷抓外部資料的社群按鈕最耗 CPU。 
- 功能重複：同時裝兩套 SEO 外掛、兩套快取會互相干擾，留一套就好；整套 SEO 設定可以參考[WordPress SEO 最佳化](<https://seo.whoops.com.tw/wordpress-seo-optimization/>)。 
- 重量級主題加頁面編輯器：Elementor 或 WPBakery 類組合容易產生大量冗餘程式碼。 
- 資料庫臃腫：修訂版本、垃圾留言、過期暫存累積會讓查詢變慢。

 

診斷的工具是 Query Monitor，它能列出每個外掛的載入時間與查詢數量，讓你一眼看出誰在拖慢網站。找到兇手之後，停用或取代就好，而不是無腦再加裝一個最佳化外掛。這條診斷路徑比WordPress 速度最佳化裡講的主機與快取設定更貼近程式碼層，兩者要一起做才完整。若是搜尋引擎收錄出問題，記得同時檢查[Googlebot 被擋](<https://seo.whoops.com.tw/gsc-page-indexed-without-content-googlebot-blocked/>)的狀況，程式碼層的 JS 錯誤也可能讓內容讀不到。

 

## 行動優先索引：手機版程式碼就是你的正本

 

行動優先索引（mobile-first indexing）指的是 Google 主要用手機版的內容與程式碼來判斷排名，不是桌機版。這代表手機版的 HTML、結構化資料、圖片 alt、內部連結都必須跟桌機版一樣完整，不能因為螢幕小就省略。手機版程式碼最佳化的重點是更嚴格控制資源大小、更在意 INP、更小心避免版面位移。完整的切換時程與檢查清單可以看[行動優先索引指南](<https://seo.whoops.com.tw/mobile-first-indexing-delay/>)。

 

你是不是只在自己桌機上檢查網站？多數流量早就來自手機了，桌機做得再漂亮，手機版殘缺，在 Google 眼裡就是殘缺的網站。關於行動搜尋的整體策略，可以參考[行動 SEO](<https://seo.whoops.com.tw/mobile-first-indexing-with-seo/>)的完整討論，這裡聚焦的是手機版程式碼要怎麼顧。手機頁面若被 Google 標記不支援行動裝置，會直接在搜尋結果上被扣分，這部分的判斷邏輯在[Mobile-Friendly 警告](<https://seo.whoops.com.tw/google-warns-site-not-compatible-mobile-devices/>)有完整說明。

 

- 手機版內容要完整：結構化資料、內部連結、圖片 alt 都不能桌機有、手機沒有。 
- 手機 CPU 與記憶體較弱：INP 更容易爆掉，JavaScript 要更節制。 
- 行動網路頻寬有限：圖片更要壓縮成 WebP 或 AVIF 並延後載入。 
- 回應式設計：比獨立手機版更易維護一致性，內容不會出現桌機與手機不同步的問題，可以搭配[RWD 網頁設計](<https://seo.whoops.com.tw/how-rwd-web-design-helps-our-brand/>)的觀念一起做。

 

驗證工具用 [Search Console](<https://seo.whoops.com.tw/google-search-console-guide/>) 的行動裝置可用性報告，或直接拿手機開你的網站實測。回應式設計不是萬能，某些複雜互動還是要針對手機特別處理，但對大多數內容站來說，回應式已經是兼顧一致性與維護成本的合理選擇。想在手機版上進一步提升[停留時間](<https://seo.whoops.com.tw/dwell-time/>)，把互動回應速度顧好是第一步，沒有人會願意在一個點了沒反應的頁面多待。

 

## 2027 AI 搜尋時代的調整：程式碼最佳化還有用嗎

 

有用，而且比以前更值得做，但目的從「討好排名演算法」擴大到「讓 AI 正確理解並引用你的內容」。AI 引擎同樣需要爬蟲讀得懂、結構清楚、載入夠快的頁面，差別在於它們更依賴結構化資料、語意清楚的標題層級、與可獨立抽取的答案段落。調整方向是：基礎的 Core Web Vitals 與渲染最佳化照做，再加上讓每個段落都能被獨立讀懂、關鍵結論放在段首、結構化資料標記到位。整體的 AI 搜尋趨勢可以參考[AI SEO 指南](<https://seo.whoops.com.tw/ai-seo/>)與[AEO 答案引擎最佳化](<https://seo.whoops.com.tw/what-is-aeo/>)的討論。

 

最常見的誤解是「AI 搜尋來了，傳統 SEO 沒用了」。其實剛好相反，傳統 SEO 的地基在 AI 時代更重要，因為 AI 要站在這個地基上讀你。你的頁面載不快、結構看不懂，AI 一樣讀不懂，被引用的機會就低。想了解搜尋意圖怎麼影響 AI 抽取的判斷，可以對照[搜尋意圖](<https://seo.whoops.com.tw/search-intent/>)的完整解析，把段落寫成機器跟人都能秒懂的形式。

 

| 傳統 SEO 訊號 | AI 搜尋訊號 | 程式碼層的重疊 |
| --- | --- | --- |
| 標題層級、關鍵字 | 可獨立抽取的段落、answer-first | 標題層級同時服務兩邊 |
| Core Web Vitals | 頁面載入夠快才能被完整爬取 | 渲染最佳化一次做對 |
| 結構化資料爭取 rich results | 結構化資料幫助 AI 分類 | JSON-LD 標記一次到位 |
| 內部連結與爬蟲收錄 | 清楚的XML Sitemap與robots.txt | 爬蟲預算管理共用 |

 

從這張表可以看出，傳統排名訊號與 AI 引用訊號在程式碼層高度重疊，做對一次就能同時服務兩邊，不是二選一。你想被 AI 引用，還是被 AI 漏掉？答案很明顯，那就把程式碼這層地基打好。誠實說一句，哪些段落會被 AI 引用很難預測，能做的是把結構做到最清楚，剩下的交給機制。至於要不要另外準備給 AI 讀的清單，可以評估[llms.txt](<https://seo.whoops.com.tw/llms-txt-guide/>)這類新規格，把它當成程式碼層之外的小補強。

 

### answer-first 寫法：把結論放段首

 

AI 抽取答案時，傾向抓每個段落的前兩三句。所以寫程式碼層的說明或文件時，把結論放在段首，再補原因與細節，會比把結論埋在段尾更容易被引用。這跟傳統寫作「鋪陳再收束」的習慣剛好相反，但對機器閱讀來說效率更高。這篇文章每個 H2 的第一段都是這樣寫的，你可以把它當成範本對照自己的內容。

 

## 實戰步驟：按優先順序的程式碼最佳化檢查清單

 

有，而且順序很重要。先量測再動手：用 PageSpeed Insights 與 Search Console 的 Core Web Vitals 報告找出紅字，然後按「影響大、風險低」的順序處理。第一輪先做不碰程式碼的，第二輪做低風險的程式碼調整，第三輪才碰渲染阻塞與 JS 載入策略。原則是能不碰原始碼就不碰，能小改就不大改，每次只動一件事再量測。

 

### 第 0 步：先量測，不要憑感覺

 

動手之前先看報告。用 PageSpeed Insights 測單頁、用 Search Console 的 Core Web Vitals 報告看全站趨勢、用 Screaming Frog 爬全站找出結構性問題。沒有量測就動手，等於蒙著眼睛改程式碼，改完也不知道有沒有效。如果你連全站有哪些重複網址、哪些頁面沒設 canonical 都還沒盤點，先用[常被忽略的技術 SEO 錯誤](<https://seo.whoops.com.tw/overlooked-technical-seo-mistakes/>)當檢查表，把低階問題清掉再進到程式碼層。

 

- 第 1 輪（不碰程式碼）：把圖片壓縮成 WebP 或 AVIF、啟用 lazy loading、停用多餘外掛、清理資料庫。 
- 第 2 輪（低風險程式碼）：補圖片 alt、修正標題層級、加 title 屬性、加 JSON-LD。 
- 第 3 輪（中高風險）：處理渲染阻塞的 CSS 與 JS、調 defer 或 async、做關鍵 CSS、minify。

 

| 自己做就能搞定 | 建議交給開發者 |
| --- | --- |
| 壓縮圖片、補 alt | 調整 defer 與 async 的載入順序 |
| 停用多餘外掛、清理資料庫 | 實作關鍵 CSS 內嵌 |
| 用外掛加 JSON-LD、修正標題層級 | 改寫主題或外掛的原始碼 |
| 看報告、排定優先順序 | 處理跨頁面的渲染阻塞架構 |

 

驗證節奏抓 7 到 28 天看田野資料，不要一天改十項，也不要用單次分數判斷成敗。改前先備份、先在測試環境驗證，這兩件事做了能幫你省下很多半夜救站的時間。每個網站的瓶頸不同，這個順序是通則，實際還是要看量測結果決定先動哪一項。改完一段時間後如果排名反而下滑，先別慌，對照[排名下降的復原步驟](<https://seo.whoops.com.tw/google-core-update-rank-recovery/>)逐項排查，多半是改動連帶動到了別的訊號。

 

## 常見錯誤與排坑：避開會讓排名倒退的幾個地雷

 

有些錯誤不是沒做最佳化，而是做錯方向，反而讓排名或體驗倒退。最常見的三種是：為了衝分數而過度刪 CSS 導致畫面跑版、亂用 async 讓功能壞掉、以及為了塞 schema 而標記與內容不符。這些地雷的共同點都是「看起來在最佳化，實際上在製造新問題」。

 

- 過度刪 CSS：把首屏需要的樣式也延後載入，畫面會先跑版再跳回，CLS 反而變差。 
- 亂用 async：有相依性的腳本被拆散，按鈕或表單功能直接失效。 
- 標記與內容不符：頁面明明不是產品頁卻標 Product schema，可能被判定為垃圾標記，嚴重時還會踩到[黑帽 SEO](<https://seo.whoops.com.tw/what-is-black-hat-seo/>)的紅線。 
- 忽略重複內容：程式碼層沒設好[重複內容處理](<https://seo.whoops.com.tw/google-duplicate-content-suggest/>)與[標準網址 canonical](<https://seo.whoops.com.tw/rel-canonical-not-guarantee/>)，多個網址指向同一份內容會分散權重。 
- 破壞爬蟲收錄：改 [robots](<https://seo.whoops.com.tw/robots-txt-seo-guide/>) 或 sitemap 時不小心擋到重要頁面，索引會跟著掉。

 

另一個容易忽略的是[關鍵字密度](<https://seo.whoops.com.tw/keyword-density/>)的迷思。很多人改程式碼時順手把關鍵字塞進 alt 與 title，以為塞越多越好，其實 Google 早就不在意密度這回事，自然分布反而更安全。程式碼層的最佳化是讓結構清楚，不是讓關鍵字變多。真正該花心力的是把[內部連結](<https://seo.whoops.com.tw/internal-link-optimization-strategy/>)串好，讓爬蟲跟使用者都能順著結構走完整個站。

 

## 回到搜尋意圖：先把最影響判斷的三件事做對

 

回到你最開始的搜尋意圖：如果目標是排名與體驗一起變好，那就先確認「最影響判斷的三件事」有沒有做對，分別是會阻塞渲染的資源、沒有語意的標籤、讓 AI 看不懂內容的結構。這三件做對，Core Web Vitals 與爬蟲理解度會一起跟上來。觀察期抓 7 到 28 天看田野資料，不要用單次分數判斷成敗。

 

說到底，網站程式碼最佳化不是把每一行都改到完美，是把最會拖垮判斷的那幾件事先修掉。排名變化要時間，不要做完三天沒看到效果就認定沒用，回去看報告找下一個瓶頸，而不是急著再裝新外掛。如果紅字還在，回到量測報告找問題，程式碼最佳化是持續維護，不是一次性專案。這跟[改善 SEO](<https://seo.whoops.com.tw/how-to-improve-seo/>)的整體邏輯一致：先穩地基，再談衝高，順序錯了會白費力氣。

 

想再往下走，可以把這份檢查清單跟你的[網站最佳化流程](<https://seo.whoops.com.tw/website-optimization-process/>)整合，排進每季的維護節奏。地基穩了，後續的[外部連結](<https://seo.whoops.com.tw/link-building/>)經營與內容產製才會真正發揮效果，這條路走穩了，傳統 SEO 與 AI 搜尋兩邊都會跟上來。若你還在評估要不要找人處理，先看[怎麼挑出真的懂程式碼層的 SEO 公司](<https://seo.whoops.com.tw/how-to-choose-seo-company/>)，別把這類工作外包給只會裝外掛的廠商。

 

## 常見問題 FAQ：網站程式碼最佳化的 6 個疑問

 

### 程式碼最佳化會直接衝高排名嗎？

 

不一定。程式碼最佳化影響的是頁面體驗訊號這一組排名因素，屬於必要條件而非充分條件。它會讓你的網站不會因為載入慢、結構亂而被扣分，但不會單獨把你推上第一頁，內容與連結仍然是主力。把它當成「不讓自己被扣分」的地基工程，會比當成「衝排名的捷徑」更符合現實。

 

### INP 跟以前的 FID 差在哪？為什麼 2024 年要換？

 

FID 只衡量第一次互動的延遲，INP 衡量整段互動過程的回應速度，涵蓋範圍更廣。Google 在 2024 年 3 月用 INP 正式取代 FID（來源：web.dev 官方公告），因為 FID 無法反映使用者在頁面上持續操作的體驗。切換之後，很多原本 FID 過關的網站 INP 變紅，因為它們的問題不在第一次點擊，而在後續的捲動與輸入回應。

 

### 不做結構化資料會被搜尋引擎懲罰嗎？

 

不會被懲罰，但會錯失機會。結構化資料不是排名因素的開關，沒做不會扣分，做了也不會直接加分。它的價值在於讓搜尋引擎與 AI 更正確地理解與分類你的內容，爭取複合式搜尋結果與 AI 引用。長期來看，做了會比沒做多一條被看見的管道。

 

### 程式碼最佳化哪些自己做、哪些該請工程師？

 

界線在於「會不會碰載入順序與原始碼邏輯」。壓圖片、補 alt、停用多餘外掛、用外掛加 JSON-LD，這些不碰原始碼，自己做就行；調 defer 與 async、實作關鍵 CSS、改寫主題原始碼，這些碰載入順序，建議交給開發者在測試環境處理。判斷標準是：改壞了能不能一鍵還原，不能就交給專業。

 

### 做完程式碼最佳化多久能看到排名或速度改善？

 

速度改善通常幾天內就能在 PageSpeed 看到，因為那是單次實測；但田野資料的 Core Web Vitals 狀態要等 28 天的資料週期才會穩定反映出來。排名變化更慢，通常要觀察數週到數月，因為排名牽涉的變因太多，程式碼只是其中一環。建議以 7 到 28 天為一個觀察週期，每次只動一項再比對。搭配[跳出率](<https://seo.whoops.com.tw/what-is-bounce-rate-exit-rate/>)與[轉換率](<https://seo.whoops.com.tw/conversion-rate/>)一起看，會更清楚體驗改善有沒有真的反映在行為上。

 

### AI 搜尋時代還要不要管 Core Web Vitals？

 

要。AI 引擎一樣需要爬蟲讀得懂、載入夠快的頁面，Core Web Vitals 代表的頁面體驗訊號在 AI 搜尋時代並沒有失效。差別在於 AI 還額外依賴結構化資料與清楚的標題層級來抽取答案，所以你要在原有的 Core Web Vitals 基礎上，再加做 answer-first 與 JSON-LD，兩者是疊加不是取代。

 

如果你正打算開始動手，先從量測做起。把 PageSpeed Insights 與 Search Console 的 Core Web Vitals 報告打開，把紅字一項一項記下來，按這篇文章的優先順序排進行事曆。不用一次做完，但要有節奏地推進，三個月後回頭看，你會發現那些原本讓你卻步的紅字，其實一個一個都被收掉了。需要有人幫你把整套流程跑一遍，也可以找我們聊聊，從程式碼層到內容層，一起把地基打穩。

 

### 把這篇用起來

#### 檢查網站的 SEO 基礎

從網站網址開始，檢視可讀性與頁面基礎訊號。

[前往實作入口 →](<https://seo.whoops.com.tw/free-seo-audit/>)

### 需要一起處理？

#### 技術 SEO 顧問與健檢

把網站問題整理成修復順序。

[前往實作入口 →](<https://seo.whoops.com.tw/services/technical-seo-consultant/>)

 

[Core Web Vitals](<https://seo.whoops.com.tw/tag/core-web-vitals/>)[網站效能](<https://seo.whoops.com.tw/tag/web-performance/>)

 

喜歡這篇內容？讓下次搜尋，更容易遇見 Whoops。

[將 Whoops 設為 Google 偏好來源（另開 Google 設定頁）](<https://www.google.com/preferences/source?q=seo.whoops.com.tw>)前往 Google 選取並確認，即可完成設定。

 

[## Sliven 褚崇名](<https://seo.whoops.com.tw/about/#founder-title>)

Sliven 褚崇名是 Whoops SEO 創辦人，負責技術 SEO、內容與關鍵字策略、WordPress 網站重建，以及 AI SEO、AEO、GEO 的量測與內容優化。作者頁可查閱由他署名的〈SEO 是什麼〉與〈AI SEO 是什麼〉等教學；內容中的自有量測、模型觀測與第三方來源應分開判讀，並以各頁標示的方法與限制為準。是否適合特定專案，仍需依網站現況、目標、執行範圍與可驗證成果判斷。

[查看作者文章 →](<https://seo.whoops.com.tw/about/#founder-title>)

 

## 討論與提問

 

### 發佈留言

 

WHOOPS / JOURNAL

## 更多值得一讀的文章

[探索知識庫 ↗](<https://seo.whoops.com.tw/blog/>)

[SEO 工具與數據約 21 分鐘閱讀

### 最佳 CrUX Vis 完整教學：真實使用者體驗視覺化工具

CrUX Vis 是 Chrome 團隊推出的免費視覺化工具，網址是 cruxvis.withgoogle.com。你在首頁的輸入框打上網址，它就會把這個網站最多 40 週、來自真實 Chrome 使用者的體驗資料，畫成一張張折線圖：LCP 多快、INP 多靈敏、CLS 穩不穩，每週一個點，一路鋪…

閱讀文章](<https://seo.whoops.com.tw/crux-vis/>) [技術 SEO約 18 分鐘閱讀

### 2027 網站速度為什麼重要：SEO、使用者體驗與 Core Web Vitals 完整關聯

網站速度會影響 SEO 排名，但它不是決定性因素，而是 Google「頁面體驗信號」的一部分。Google 自 2010 年把桌面版速度、2018 年把行動版速度納入排名，2021 年再整合 Core Web Vitals。當兩個頁面內容與權重差不多時，速度快、體驗穩的那一頁才有機會勝出。把 LC…

閱讀文章](<https://seo.whoops.com.tw/website-speed-matters/>) [技術 SEO約 18 分鐘閱讀

### 最佳結構化資料完整教學：Schema Markup 語法與 AI 搜尋實戰

結構化資料（Structured Data）就是用一段標準化的程式碼，明確告訴 Google 你這頁是文章、是產品、還是 FAQ，讓搜尋引擎不用再從文字去「猜」。根據 Google Search Central 的官方說明，結構化資料能讓你的頁面具備取得複合式搜尋結果（rich results）的…

閱讀文章](<https://seo.whoops.com.tw/what-is-structured-data/>)