On-Page SEO 是什麼？2026 頁面優化核心元素與實戰順序

On-Page SEO 的定位：頁面層級優化的定義與邊界

On-Page SEO 是針對單一頁面的內容、HTML 與呈現方式進行優化，並會與技術及站外條件交會。它能幫助讀者與搜尋系統理解頁面，但不保證收錄、排名或 AI 功能引用；生成式搜尋也沒有公開「優先引用語意清晰頁面」的固定公式。

要理解這個系統，我們可以將其拆解為三個核心層級：內容層處理文字、多媒體與搜尋意圖的契合度，決定頁面是否回答了使用者真正想問的問題；HTML 層涵蓋標題標籤、Meta 描述、URL 結構與結構化資料，負責向搜尋引擎明確宣告頁面的主題與用途；技術層則關注頁面載入速度、行動裝置相容性等頁面體驗信號，確保內容能被順暢存取與渲染。這三個層級彼此獨立卻又相互影響，任何一層的缺陷都可能讓其他層級的優化成果大打折扣。 延伸閱讀：網頁標題與網頁描述怎麼寫。

內容層：語意深度與實體辨識的基礎

內容層的任務是清楚回答讀者問題，並交代範圍、證據與限制。關鍵字、實體或篇幅沒有可套用的公開密度公式；先服務讀者，再用實際搜尋與轉換資料驗證。

描述性 H2／H3 有助讀者與搜尋系統理解頁面結構，但 Google 沒有公布「實體數量」「主題叢集歸類」或標題層級的排名公式。若要理解已知排名系統及其邊界，可參考SEO 排名因子研究。

HTML 層：讓機器可讀的明確宣告

HTML 層提供 title、meta description、URL 與結構化資料等線索。描述性 title 有助 Google 產生 title link，但顯示文字可能被改寫；meta description 有時會成為 snippet，不能說成直接決定 CTR。URL 應穩定、可讀，不必為精確關鍵字重建既有網址。

結構化資料用標準格式描述頁面已可見的資訊；符合 Google 支援類型與政策時，頁面可能具備 rich result 資格，但不保證顯示或排名。FAQ rich results 目前主要限符合資格的政府與健康網站；Google AI 功能也沒有要求專用 Schema。

技術層：頁面體驗、渲染與可用性

技術層處理頁面效能、渲染與相容性。Core Web Vitals 目前包含 LCP、INP 與 CLS；INP 已在 2024 年取代 FID。Google 的排名系統會使用 Core Web Vitals，但良好分數不保證排名，也不能把單一指標當收錄門檻。

行動版內容應完整、可操作並符合真實裝置需求。圖片格式、尺寸與載入策略要用實測決定；alt 主要提供等價文字與圖片脈絡，不是額外關鍵字欄位。完整工作分工可參考SEO 完整指南。

維度	On-Page SEO	Off-Page SEO	Technical SEO
負責範圍	單一頁面內的元素與內容	站外連結、品牌提及與信任訊號	全站爬取、索引基礎設施與伺服器效能
可控程度	可直接編輯，但受 CMS、流程與資源限制	部分可控（需透過外部合作或內容吸引力）	部分可控（需開發、平台與維運資源）
典型工作	標題優化、意圖對齊、Schema 標記	公關發稿、客座文章、品牌搜尋量經營	修復 404、優化爬取預算、設定 robots.txt

On-Page、Technical 與 Off-Page 是便於分工的工作分類，邊界會因網站與團隊而重疊。單頁內容可直接編輯，但仍受 CMS、法遵、資料與資源限制；Technical SEO 也不等於完全可控。先找真正瓶頸，再決定由哪一層處理。

內容層優化：把頁面寫成「對的答案」

先釐清讀者問題、頁面任務與搜尋意圖，再決定關鍵字及內容深度。SERP 抽樣可觀察目前頁型與問題，但會隨地區、裝置、日期及查詢改變，也不是 Google 的必答清單；對齊樣本不保證收錄或排名。

搜尋意圖簇的判定機制

同一查詢可能出現資訊、商業、交易或導航等不同任務。可記錄固定條件下多個結果的頁型與問題，再結合客服、站內搜尋、Search Console 與商業資料分組；不要假設只覆蓋一種頁型就必然無法滿足多數使用者。

頁型或內容與查詢不符可能降低讀者滿意度，但 GA4 跳出率與停留時間不是公開的 Google Search 排名診斷。前幾名共同子題只能作候選，「超過半數」也是人工門檻；仍要確認該子題是否真的服務本文讀者。

完成問題分組後，可用描述性 H2／H3 與靠近標題的直接回答改善掃讀；但「一簇一標題」是編輯框架，不是 Google Passage Ranking 或 AI 摘錄器的公開要求，也不保證摘要或引用。

主題深度與 E-E-A-T 的頁面證據

可信內容可交代作者、第一手經驗、原始資料、來源與限制，讓讀者判斷主張。E-E-A-T 本身不是單一排名因素；作者實名、年資或作品不是所有頁面的固定第一層門檻，證據需求應依主題風險與內容類型決定。

容易過時的數據、介面與規則應標示來源日期與適用條件；低漂移概念不必機械式加年份。時點有助讀者判斷，不代表 AI 系統會依此建立公開的新鮮度分數。

證據應放在最能支持主張的位置，作者背景也應容易找到。Google 沒有公布把第一人稱或行內引用換算成更強 E-E-A-T 訊號的公式。

關鍵字佈局與語意實體的自然分佈

標題與首段應清楚描述頁面主題，可自然使用讀者熟悉的詞彙與必要同義詞；不必為了「語意關聯圖」把實體分配到每個 heading。重複關鍵字若損害可讀性或以操縱排名為目的，可能落入 keyword stuffing，但 Google 沒有公開頁面品質分數。

H2／H3 應反映讀者理解順序並具體描述段落內容，不需要每個標題都塞入一個實體詞。清楚標題有助導覽與理解，但不能宣稱特定命名會讓摘錄器建立固定判讀。

FAQ 可整理客服、站內搜尋、Search Console、使用者研究與 SERP 樣本中的真實問題；不必只複製前幾名結果，也沒有每題兩至三句的搜尋規則。FAQPage 標記與 rich result 資格要另依官方政策判斷。

HTML 層優化：標題、Meta、URL、圖片、結構化資料

HTML 元素應準確描述頁面：title、meta description、URL、圖片替代文字與結構化資料各有不同用途。任何一項都不是收錄或排名保證，也沒有必須依固定順序處理的官方規則。

標題標籤與 URL：描述清楚、保持穩定

title 元素應精簡、具描述性且能區分頁面，避免關鍵字堆疊與重複樣板。Google 沒有 50–60 字元或「前 12 個字元」的官方門檻，title link 也可能因裝置、查詢與系統選擇被截斷或改寫。

描述性 URL 比不透明參數更方便讀者與維護，也可提供頁面線索；但沒有「稀釋關鍵字權重」公式，日期或分類有時是合理架構。不要只為加入關鍵字更改既有 URL；若確定永久遷移，應更新內鏈、使用伺服器端永久轉址並驗證 canonical 與索引狀態。

使用一個清楚可見的主標題通常最容易維護，H2／H3 建立合理層級；Google 沒有「只能一個 H1」或每個 H2 後必須先有引言段的硬性規則。直接回答可提升閱讀效率，但是否需要引言由內容決定。

Meta 描述真的要壓在 150 字內嗎？一個值得測試的反向做法

AK 的做法是刻意不理會 150 字這個常見上限，把 Meta 描述寫長、寫完整，該講的賣點、規格、情境全部塞進去；這是一個可測試的假說，不是必須遵守的最佳實務，全站套用前應該先用單一頁面驗證。

Google 主要從頁面內容建立 snippet，有時使用 meta description；官方沒有公布「比任何一段更貼近查詢字」的可套用公式。原貼文轉述的 Portent 比例未附原始研究連結、方法與樣本，本篇不把六到八成或八成多當成已查證事實。

寫長不會讓超出顯示範圍的文字變成可靠候選庫。這個 AK 假說可保留為單頁實驗：固定查詢與觀察條件，比較 Google 實際顯示、CTR 與頁面內容；不能把 meta 長度本身當成 Google 機制。

測試方法：挑一個頁面，把它目前排名前五的查詢丟進 Google，看現在 Google 實際挑了哪一段當描述；如果那段寫得鬆散或答非所問，就把核心賣點壓進頁面同一段落，逼出一個夠完整的候選段落，再觀察 Google 是否改採用它。這不是通用最佳實務，是一個等待更多頁面測試結果驗證的假說，測試前後都要記錄同一批查詢與觀察窗口，才能比較。

證據狀態	Hypothesis（假說，附可執行的反證測試方法）
站點／來源類型	AK 自有 Threads 帳號貼文；文中轉述 Portent 第三方統計，本次任務未獨立查證原始研究
觀察窗口	貼文本身未附測試前後對照的觀察窗口；Portent 統計標註為 2026 年樣本，原始研究時間範圍未附
樣本／分母	貼文未提供樣本數或分母；Portent 統計聲稱「第一頁六到八成、2026 年達八成多」，但原始研究方法與樣本規模未附連結
變更槓桿	把 Meta 描述從壓在 150 字內，改為不限字數、涵蓋完整賣點與規格
觀察結果	貼文未附測試前後的量化對照；內容是操作邏輯與判斷依據，不是已完成的實測結果
AK 判讀	長版描述是否較常被採用尚未驗證；Google 主要從頁面內容產生 snippet，也可能使用 meta description，需用固定查詢與觀察條件實測
替代解釋	Google 改寫 Meta 描述的主因也可能是頁面內容本身缺乏對應段落，與 Meta 描述長度無關；查詢多樣性也可能讓單一固定 Meta 描述難以覆蓋所有情境
什麼情況會推翻此推論	同一頁做原始短版與長版對照，觀察期內 Google 選用你 Meta 描述的比例沒有變化，或曝光與點擊率沒有可歸因的差異，此假說不成立
來源／出處	AK Threads 貼文 DZ4OX6-gGMa（2026-06-22）；此貼文未收錄於本站 claims 檢索庫，本卡直接依原始貼文內容摘要
最後查核日	2026-07-22

更多方法與假說目前的驗證進度，收在AK 的 SEO 證據庫。

圖片替代文字：描述內容，不是堆砌關鍵字

圖片與多媒體同樣需要語意標記。檔名應具備描述性，例如 hand-press-espresso-machine.jpg 會比 IMG_2048.jpg 更容易被理解。alt 屬性則需準確描述圖片內容並自然帶入相關語意，例如「咖啡機把手壓下時產生的 crema 細節」；這不是讓你把關鍵字塞進去的欄位，而是讓視障使用者與搜尋引擎都能理解圖片在頁面脈絡中的角色。若圖片是裝飾性質，alt 應留空而非填入無意義文字。

描述性檔名便於管理，也可能提供圖片線索；alt 應依圖片目的提供等價文字，裝飾圖可用空 alt。不要把 alt 當關鍵字欄位，也不能宣稱它只影響圖片搜尋或必然改善 AI 多模態理解；優先序要看無障礙與頁面任務。

Schema 選錯類型的失敗模式

結構化資料應描述頁面可見的主要內容。符合 Google 支援類型與政策時可能取得 rich result 資格，但不保證顯示、排名或 AI 引用；選錯類型可能使資格失效，不能直接推論一般排名被排除。

產品頁若主要內容是商品資訊，就不應以 Article 取代適用的產品標記；FAQPage 必須與可見問答一致。Google 已停止顯示 HowTo rich results，合法保留其他用途的 Schema.org 標記不會因此產生 Google rich result，也不能說它必然浪費爬取資源。

可用 Google Rich Results Test 檢查 Google 支援類型的可解析性與資格問題，再確認標記與可見內容一致。工具通過不保證 rich result 顯示或排名；非 Google rich-result 類型可另用一般 Schema.org 驗證器檢查語法。

內部連結與站內權重流動

內部連結可協助讀者與 Google 發現頁面、理解目標頁脈絡與網站結構。描述性錨點與可爬取的 HTML 連結很重要，但 Google 沒有公布以連結位置或固定數量換算「站內權重」的公式；孤立頁也應先確認是否值得被索引與連結。 延伸閱讀：內部連結策略怎麼做。

內部連結應使用能預告目標頁的錨點，並放在讀者需要的相關脈絡中。「點這裡」有時仍可用於介面，但正文通常可寫得更具體；不必刻意避免所有重複錨點，也沒有「靠前就傳遞更多權重」的公開公式。

孤兒頁診斷的兩條路徑

Google Search Console Links report 顯示 Google 過去發現的內外部連結樣本，內部區塊可查看最常被站內連結的頁面與部分來源頁。它不是完整索引、即時爬取或內部錨點分布報告，資料也可能包含已移除連結。

Screaming Frog 等爬蟲可從指定起點模擬抓取站內 HTML 連結，建立當次可達的連結圖；結果受 robots、登入、JavaScript 渲染、設定與爬取範圍影響，也不等於網站所有頁面或 Google 所見。

Links report 適合查看 Google 提供的歷史樣本；自有爬蟲適合稽核目前可達連結。若要查特定 URL 的索引與 rendered HTML，另用 URL Inspection 或實際渲染；三者用途不同，不能簡化成「已收錄事實」對「完整現況」。

同主題有多頁在搶，誰該當內鏈負責頁？

同主題多頁不一定互搶，也不必預設只留一頁摘要。先比較各 URL 的查詢、意圖、轉換任務、canonical 與內鏈；若確有重疊，再依證據選擇保留、差異化、合併或永久轉址，避免只因平均排名輪替就下結論。

Codex 或其他工具可協助分群、找孤立頁與提出 301 或內鏈候選，但輸出仍須逐 URL 驗證來源、目標、狀態、canonical、流量與商業任務；工具不能在沒有人工決策時直接執行刪除或轉址。

完整判斷邏輯收在SEO 稽核方法論的決策帳本。查詢與頁面表現應看 GSC Performance report，而不是 Links report；後者不能告訴你哪個 URL 正在取得某查詢的曝光或排名。

內鏈錨點文字的分配原則

錨點文字應自然、具描述性且能預告目標頁；同一目標可以因上下文使用不同合理文字，但不需要刻意製造變體。Google 未說站內相同精確錨點必然構成過度最佳化；真正要避免的是關鍵字堆疊、誤導或低品質連結模式。

連結應放在讀者需要的相關脈絡中，首頁、導覽、正文或頁尾各有不同任務。Google 沒有公開「第一、二段傳遞更多權重」或每頁 3–5 條優於 10 條的公式；數量由內容長度與使用者路徑決定，並定期修復失效及孤立頁。

提升低排名頁面的能見度：On-Page 優先序行動框架

低表現頁沒有通用修復順序。可先確認查詢、頁面任務、索引狀態與實際缺口，再依證據修改內容、title、snippet 候選、內鏈或技術問題；「內容→內鏈→HTML」是本站工作框架，不是 Google 必須依序評估的排名機制。

當站內有大量頁面卡在 SERP 第二頁或更後面時，逐一修改 HTML 標籤的效率極低。以下是一個可重現的行動框架，專門針對這類低排名頁面：

1. 盤點候選頁面：依商業價值、查詢、曝光、點擊與趨勢設定站內門檻；曝光 50、位置 8–20 只是可調參數，不代表只差最後一推。
2. 篩選問題：比較實際 SERP、讀者需求與頁面任務，記錄缺少或過度的內容，不把前十共同項視為必填。
3. 尋找相關來源頁：找讀者會自然前往目標頁的既有內容；點擊與排名高不等於可量化的「高權重」。
4. 執行最小改動：依已確認問題補內容、調整標題或技術設定，避免同時改太多變因。
5. 建立相關內連與驗收：記錄變更日、查詢與對照區間，等待重新抓取後再用 GSC、分析與轉換資料判斷；不使用固定 30–60 天保證。

這五步任一步跳過會發生什麼

只改 title、只補內容或只加內鏈都可能有效，也可能無效，取決於真正瓶頸。Google 沒有「缺前十實體就只能從第 15 到第 12」的公開規則；應一次處理已確認的最小問題，記錄前後變化。

相關內鏈可幫助發現、導覽與理解脈絡，但不能把來源頁點擊或排名直接等同可轉移信任，也不能保證提高爬取頻率。先確認目標頁值得保留，再從真正相關的頁面建立可爬取連結。

為什麼順序不能倒過來執行

先加內鏈或先改內容都不是固定錯誤。若目標頁有價值但難以被發現，先補連結可能合理；若內容不符任務，先修內容較合理。Google 未說連向尚未完善頁面會降低來源頁信任度。

title、內容與內鏈的順序應依診斷決定。CTR、跳出率與排名之間不能在此宣稱固定因果；修改 title 後仍應核對 Google 實際顯示、查詢組成與轉換，而非把意圖對齊永遠排成第一步。

框架適用的站點條件與例外處理

這套工作框架適合已有可比較資料與相關來源頁的網站；新站也能用內鏈建立導覽與資訊架構。不要先建立「權重樞紐」只為傳遞分數，應先讓每頁有清楚任務與可用路徑。

全新網站或大量索引問題應先確認可抓取、可索引、canonical、內容價值與網站架構，詳見爬取與索引基礎檢查。多數新站沒有需要管理的 crawl budget 問題，Google 也沒有公開「索引信任」分數；內鏈對新站仍有發現與導覽價值。

On-Page SEO 落地檢查清單與量測銜接

上稿前記錄內容與技術狀態，上稿後再用搜尋、分析與轉換資料觀察，才能建立可追溯的優化紀錄。一次改動本身不能證明排名原因；應保留變更日、查詢範圍、對照條件與替代解釋。

上稿前：把六項元素一次校準

檢查 title、meta description、URL 與可見內容是否一致。title 與 URL 應描述頁面，meta description 提供摘要候選；Google 可能改寫 title link 與 snippet，三者也不會共同固定「決定」SERP 呈現。

Heading 應反映讀者理解順序，不必遵守單一 H1 或首段兩至三句的搜尋硬規則。alt 依圖片目的提供等價文字；結構化資料應與可見內容一致並通過適用驗證，但工具通過不保證 rich result 或排名。

內部連結應可爬取、指向有效且相關的目標，錨點文字要能預告內容。每頁至少兩條不是 Google 規則；數量與位置應依使用者路徑及內容需要決定。

上稿後：依資料量設定可驗證觀察窗口

上稿後可用GA4 事件追蹤與報表設定與 GSC 交叉觀察。GSC 的曝光、點擊、CTR 與平均位置會受查詢、裝置、地區、SERP 功能及需求變化影響；曝光增加不必然等於新收錄，位置前移也不能單獨證明意圖匹配改善。觀察窗口由重新抓取、資料量與決策風險決定，沒有 28 天最低規則。

GA4 engagement time 與 scroll 事件可描述量測到的互動，但停留或捲動不等於內容被理解，也不能單獨證明標題承諾、段落結構或搜尋排名原因。應搭配轉換、任務完成、質性研究與技術資料判讀。

單頁波動不能直接歸因於單一 On-Page 改動。可用相似且同期未改的頁面作參考，但非隨機對照仍受季節、查詢組成、競品與演算法影響；結果只能提高或降低假說可信度，不能直接「確認」因果。

把量測結果回饋到下一輪檢查

將結果回填到變更紀錄，區分觀察、推論與下一個測試。Schema 通過但曝光未升不能證明內容有問題；內鏈後位置前移也不能證明內鏈造成。先檢查替代解釋，再決定是否複製。

對照頁應盡量在主題、頁型、需求與基線上可比，並記錄同期其他變動。每次處理幾頁與觀察多久取決於樣本量與營運節奏；三至五頁、60 天只是本站可調工作設定，不是足夠數據的保證。

邊界與延伸：On-Page SEO 與 Technical / Off-Page 的分工

On-Page SEO 處理單頁內容與 HTML，但排名、索引與 AI 功能呈現還受查詢、技術、網站與外部環境影響。不要用「應有的排名」或缺乏站外佐證必然被拒絕等語句，應逐層確認真正阻擋。

On-Page 無法取代的站外信任訊號

Google 的系統會使用連結與多種信號，但沒有公開「外部連結＋品牌提及」的單一權威公式。競爭查詢可能需要更完整的網站、內容與外部認知；On-Page 改善也不能保證把導入的權重轉成排名。

實務上常見的誤判是將 On-Page 視為萬能工具，例如為了塞入關鍵字而把標題寫得冗長拗口，反而降低使用者點擊意願；或是盲目為所有頁面加上不相關的 Schema 標記，觸發 Google 的垃圾結構化資料警告。這些行為不僅無法彌補站外訊號的不足，還會削弱頁面原有的競爭力，讓後續的 Off-Page 投入事倍功半。

爬取與索引基礎設施的責任歸屬

伺服器回應狀態、robots.txt 規則、XML 站點地圖與 canonical 設定，這些決定搜尋引擎能否順利讀取頁面的技術環節，屬於 Technical SEO 的管轄範圍。當網站頻繁回傳 5xx 錯誤、重要目錄被 robots.txt 封鎖，或 canonical 指向錯誤時，On-Page 元素根本無法被爬蟲取得，優化工作等於在空轉。此時優先修復技術障礙，遠比調整頁面內容更迫切。

若頁面被 robots.txt 阻擋，Google 可能無法抓取其內容，但 URL 仍可能在某些情況被索引；noindex 則必須允許抓取才可被看見。Google AI 功能沿用一般搜尋資格，沒有公開大型語言模型同時評估可存取性與結構清晰度的引用公式。

關鍵字策略與 On-Page 的執行順序

關鍵字研究決定頁面該瞄準哪些搜尋意圖，這是 On-Page 優化的前置條件。若初始鎖定的關鍵字與商業目標脫節，例如以資訊型關鍵字承接交易意圖的流量，頁面內容即使寫得再好，也無法帶來有效的轉換。正確的執行順序是先確認關鍵字背後的搜尋意圖與商業價值，再據此規劃頁面的標題、內容結構與內部連結配置，讓 On-Page 元素服務於明確的商業目標。

當網站同時存在多主題、多頁面低表現，或內容意圖與商業目標嚴重脫節時，問題根源往往超出單頁 On-Page 的處理範圍。此時需要先進行全站性的語意內容盤點與技術稽核，確認哪些頁面值得投入資源、哪些頁面應該合併或移除，再針對保留的頁面執行 On-Page 優化。這個判斷需要同時考量站點規模、既有權重分布與競爭對手的布局，無法靠單一頁面的調整解決。

要判斷你的網站目前需要的是單頁 On-Page 調整，還是更全面的策略性投入，可以從三個徵兆著手：頁面是否持續無法被收錄、外部連結導入後排名仍無起色、以及內容與商業目標的對齊程度。若你正在評估這類資源配置，可以參考我們整理的SEO 服務項目與適用情境總覽，了解不同層級的優化工作各自對應的網站狀態。當你確認需要外部團隊介入時，檢視 SEO 策略藍圖、成長顧問與規模化系統的服務範圍與投入門檻，能幫助你對照自身資源與優先序，決定下一步該從哪個環節開始。

On-Page SEO 跟 Off-Page SEO 差在哪？

On-Page SEO 處理你頁面內可控制的元素，包含內容品質、HTML 結構與頁面體驗。Off-Page SEO 則處理站外訊號，例如外部連結與品牌提及。在執行順序上，通常先確保 On-Page 基礎穩固，再投入 Off-Page 資源放大效益。

做完 On-Page SEO 多久能看到效果？

搜尋表現沒有保證見效天數。可依重新抓取、資料量與商業週期設定觀察窗口，並用 GSC、分析及轉換資料排除季節、查詢組成、競品與其他變動；28–90 天只能是本站規劃範圍，不是普遍規則。

每個頁面都要加 Schema 嗎？

不需要每頁都加 Schema。只標記頁面可見且符合適用規格的資訊；Article、Product 等類型用途不同，FAQ rich results 目前主要限符合資格的政府與健康站，Google 已停止 HowTo rich results。標記不是排名加分，仍會增加維護成本。

長版 Meta 描述適合每一頁都套用嗎？

不建議直接全站套用。這是一個還在測試中的假說，只在頁面有足夠具體的賣點、規格或情境可以撐起更完整的敘述時才值得試；先挑一頁，比對它目前排名前五查詢下 Google 實際採用的描述，看是否需要補強再決定要不要放寬字數。

同主題有兩頁在打架，要馬上刪一頁或做轉址嗎？

不要急著刪或轉址。先確認是不是真的負責頁衝突，也就是同一個查詢底下兩個網址的曝光與排名是否真的在互相拉扯；確認之後再依決策帳本的訊號表決定刪除、更新、合併或轉址，流量或點擊差距不是唯一判斷依據。