SEO 專欄｜香港搜尋引擎優化實戰指南

搜尋引擎如何運作：爬取、索引、排名

要做好 SEO，先要理解 Google 處理你網站的三個階段：爬取（Crawling）、索引（Indexing）、排名（Ranking）。大部分 SEO 失敗的個案，問題其實卡在前兩步——網站根本冇被完整索引，卻花全部精力去執筆寫內容。

爬取：Googlebot 找不到的頁面等於不存在

Googlebot 透過連結發現新頁面。如果一個頁面冇任何內部連結指向它、又冇出現在 sitemap.xml，它就是一個孤立頁面，可能永遠不會被抓取。常見的爬取障礙包括：robots.txt 誤封了整個目錄、重要內容只在 JavaScript 執行後才出現、無限迴圈的篩選參數 URL 耗盡爬取預算、以及伺服器回應過慢導致爬蟲主動降低抓取頻率。

索引：被抓取不等於會被收錄

Google 抓取後會判斷這一頁值不值得放進索引。判斷失敗最常見的三個原因是：內容與站內其他頁面高度重複（例如同一批服務內容換個地區名做了十頁）、內容太薄冇獨立價值、以及 canonical 標籤指向了另一頁。在 Google Search Console 的「網頁」報表裡，「已檢索 - 尚未建立索引」與「重複內容，Google 選擇的標準網頁與使用者指定的不同」這兩個狀態，是最需要優先處理的訊號。

排名：不是單一因素，而是一組相對比較

Google 的排名系統會就每一個查詢，比較所有已索引的候選頁面。實務上可控的槓桿分四類：內容與搜尋意圖的匹配程度、網站在該主題的整體覆蓋深度、外部與內部的連結訊號、以及頁面體驗指標。要留意「排名」在 2026 年已不只是十條藍色連結——AI 摘要、影片區塊、圖片組、常見問題區塊都在爭奪同一屏空間，所以優化目標應該是「在該查詢的搜尋結果頁上以任何形式出現」，而不是單純追一個數字位置。

On-Page SEO：H1 至 H3 標題層級與頁面元素

On-Page SEO 的目標是讓 Google 與語言模型在幾百毫秒內判斷「這一頁在講什麼、答到什麼問題」。做法不神秘，但每一項都有具體規範。

H1：每頁一個，包含主要關鍵字

H1 應該只有一個，內容包含該頁最主要的目標關鍵字，並與 title 標籤意思一致但不必逐字相同。常見錯誤是把 logo 或網站名稱做成 H1，或者為了視覺效果在同一頁放三四個 H1。如果需要更大的字體，用 CSS class 處理，不要動標題標籤。

H2：劃分主要章節，對應關鍵字群組

每個 H2 應該對應一個子主題，而這個子主題最好本身就是一組相關關鍵字。以本頁為例，「Core Web Vitals 優化」是一個 H2，它下面覆蓋 LCP、INP、CLS 三組詞。H2 的數量反映內容的廣度，一篇完整的支柱頁通常有 8 至 15 個 H2。

H3：放真實用戶會打的問句

H3 是 GEO 時代最重要的位置。把用戶實際會搜尋的問句直接寫成 H3，然後在下面第一句就給答案，這種格式最容易被 AI 摘要抽取引用。例如「LCP 太慢，最有效的優化方法是什麼？」就比「速度優化建議」有效得多。層級不可跳級，H2 之下必須是 H3 而非 H4。

Title 與 Meta Description 的實際寫法

• Title — 控制在中文約 28 至 32 字內避免被截斷，最重要的關鍵字放前面，品牌名放最後。用分隔符號組合「主要關鍵字 | 次要關鍵字 — 品牌」的結構。
• Meta Description — 中文約 70 至 80 字。它不是排名因素，但直接影響點擊率。寫法應該是「這一頁解決什麼問題 + 具體包含什麼 + 一個行動理由」，並自然帶入關鍵字，因為符合查詢的字詞會在搜尋結果中加粗。
• URL — 短、含關鍵字、用連字號分隔英文單字。中文網站建議用英文 slug，避免 URL 編碼後變成一長串亂碼。
• 圖片 alt — 描述圖片實際內容，自然帶入關鍵字。裝飾性圖片應該用空的 alt 屬性讓螢幕閱讀器略過，而不是硬塞關鍵字。

內容深度：字數不是目標，覆蓋度才是

「文章要寫 3000 字」是被誤解最深的建議。Google 冇字數要求，但要排在競爭關鍵字前列，你的頁面必須覆蓋該主題下所有用戶會問的子問題——而完整覆蓋自然會產生足夠字數。實務做法是：搜尋目標關鍵字，把首頁十個結果的所有 H2 與 H3 抄下來，再加上「其他人也問」的問題，這份清單就是你的內容大綱最低標準。然後補上對手冇的東西：具體數字、實際案例、可下載的檢查清單。

技術 SEO 檢查清單

以下是我們做技術 SEO 審計時實際跑的清單，按優先級排列。前五項冇做好，後面全部都是浪費。

索引與可爬取性

• robots.txt 檢查：確認冇誤封 CSS、JS 或重要目錄，並宣告 sitemap 位置。
• sitemap.xml：只列出希望被索引的正式 URL，每條有正確的 lastmod，並已在 Search Console 提交。
• canonical 標籤：每頁指向自己的絕對 URL；分頁、篩選參數、追蹤參數版本統一指向主版本。
• noindex 誤用檢查：測試環境的 noindex 標籤最常在上線時忘記移除，這是最致命也最常見的失誤。
• HTTP 狀態碼：確認 404 頁面真的回應 404 而非 200，所有變更過的 URL 都有 301 而非 302。
• HTTPS：全站強制 HTTPS，冇混合內容警告，HSTS 已設定。
• www 與非 www、結尾斜線與否：統一一種形式，其餘 301 轉址。

國際化與多語言

• hreflang：香港繁體中文站應該用 zh-Hant-HK，並設定 x-default。如果同時有簡體版本，兩邊必須互相宣告。
• html lang 屬性：與 hreflang 一致，避免出現 lang="en" 但內容是中文的情況。
• 避免混用簡繁字體：同一頁同時出現「網上」與「网上」會影響專業觀感，也可能令模型判斷語言不一致。

行動裝置與可用性

• 視窗設定正確，冇橫向滾動。
• 可點擊元素之間有足夠間距，字體最小 16px 避免 iOS 自動縮放。
• 冇侵入式插頁廣告或蓋住內容的 Cookie 橫幅。
• 表單在手機上使用正確的 input type，讓鍵盤自動切換。

爬取預算管理

中小型網站通常不需要擔心爬取預算，但電商網站的篩選參數可以產生數萬個近乎重複的 URL，嚴重浪費爬取資源。處理方法是：用 robots.txt 封鎖純篩選參數路徑、對排序與檢視模式參數設 canonical、並在 Search Console 監控「已檢索但未編入索引」的數量趨勢。

Schema 結構化資料與 FAQ Schema 教學

結構化資料是用機器可讀的格式，把頁面上的資訊再講一次給搜尋引擎與語言模型聽。它不會直接提升排名，但會影響兩件關鍵事：能否取得複合式搜尋結果，以及 AI 能否準確理解並引用你的內容。

應該優先部署的 Schema 類型

• Organization / LocalBusiness — 品牌實體的基礎。填寫名稱、logo、地址、電話、營業時間、服務範圍。這是建立實體識別的起點，對 AI 引用尤其重要。
• WebSite — 宣告網站層級資訊，可加入 SearchAction 供站內搜尋使用。
• BreadcrumbList — 麵包屑路徑，讓搜尋結果顯示層級而非完整 URL。
• Service / OfferCatalog — 服務項目與價格區間，適合服務型企業。
• Product / AggregateOffer — 網店產品頁必備，包含價格、庫存狀態、貨幣。
• Article — 專欄文章，需要 datePublished、dateModified、作者與發布者。
• FAQPage — 常見問題。
• HowTo — 步驟型教學，每步有名稱與說明。

FAQ Schema 三條紅線

FAQPage 是最容易被濫用、也最容易觸發人手處罰的類型。三條必須守住的線是：一、schema 裡的每一條問題與答案，都必須在頁面上肉眼可見，隱藏內容屬違規；二、答案要真的回答問題，不能塞促銷文案或多條連結；三、同一組 FAQ 不要在多個頁面重複部署。另外要有預期管理——Google 已大幅收窄 FAQ 複合式摘要的顯示範圍，現時主要保留給政府與醫療網站，所以做 FAQPage 的主要回報已經由「搶佔搜尋結果空間」轉為「讓語言模型準確抽取你的答案」。

用 @graph 整合，避免重複宣告

很多網站的做法是在 head 塞五六個獨立的 JSON-LD 區塊，每個都重複宣告一次 Organization。更乾淨的做法是用 @graph 陣列把所有實體放在一個區塊內，並用 @id 互相引用。例如 Article 的 publisher 直接指向 @id 為 #organization 的節點。這樣可以減少檔案大小、避免資料不一致，也讓實體關係更清晰。本頁的結構化資料就是這樣組織的。

驗證流程

1. 用 Google 的複合式搜尋結果測試工具檢查是否有錯誤與警告。錯誤必須修正，警告視情況處理。
2. 用 Schema.org 的驗證器檢查語法與屬性是否合法。
3. 上線後在 Search Console 的「強化項目」報表監控，Google 實際偵測到的數量與你部署的數量應該相符。
4. 每次改動頁面文字後，同步檢查 schema 內容是否仍然一致——不一致是最常見的違規原因。

Google Tag Manager 與 Search Console 設定

為什麼要用 GTM 而不是直接貼代碼

三個實際理由：一、所有追蹤代碼集中管理，加新的像素不需要改網站程式碼；二、有版本控制與預覽模式，改壞可以即時回退；三、可以用觸發條件精細控制何時載入，把非必要腳本延後到首次互動之後，直接改善 INP。缺點是 GTM 本身也是一個腳本，配置不當會拖慢速度，所以要定期清理已停用的代碼。

GTM 基本架構

• 代碼（Tag） — 實際要執行的東西：GA4 事件、Meta Pixel、Google Ads 轉換。
• 觸發條件（Trigger） — 什麼時候執行：頁面瀏覽、元素可見、點擊特定連結、表單提交。
• 變數（Variable） — 動態取值：點擊的連結網址、表單 ID、頁面路徑、資料層變數。
• 資料層（Data Layer） — 網站主動推送資訊給 GTM 的橋樑，電商追蹤必須依賴它傳遞產品與訂單資料。

設定 WhatsApp 點擊追蹤的具體做法：建立「僅連結點擊」觸發條件，條件設為 Click URL 包含 wa.me，然後綁定一個 GA4 事件代碼，事件名稱設為 contact_whatsapp，並用 Click Classes 或自訂變數記錄按鈕位置。發布前一定要用預覽模式實測一次。

Google Search Console 使用重點

Search Console 是唯一顯示 Google 實際如何看你網站的工具，四個報表最有價值：

• 成效報表 — 篩選排名 8 至 20 位的查詢找快速機會；用「查詢」與「網頁」交叉比對，確認每個查詢是否落在正確的頁面。
• 網頁索引報表 — 重點看「已檢索 - 尚未建立索引」與「重複內容」兩個狀態，這是索引問題的直接證據。
• 網站使用體驗核心指標 — 真實用戶的 LCP、INP、CLS 分佈，比任何測速工具都準。
• 連結報表 — 查看外部連結來源與內部連結分佈。內部連結數最少的頁面往往就是排名最差的頁面。

另外兩個實用功能：網址檢查工具可以即時查看單一 URL 的索引狀態與 Google 看到的渲染結果；移除工具可以臨時隱藏不想被搜尋到的頁面，但只是暫時措施，真正的解法是 noindex 或刪除。

CRO 轉換率優化與 A/B 測試

把流量翻倍很難，把轉換率翻倍往往只需改幾樣東西。而且 CRO 的效果會同時放大 SEO 與廣告的回報——同一批流量帶來雙倍詢盤，等於獲客成本直接減半。

先診斷，再改動

改之前要知道流失發生在哪一步。用三個工具交叉驗證：GA4 的漏斗探索找出流失最嚴重的步驟；熱圖與捲動圖看用戶看到哪裡就停；錄影回放看實際的卡點（例如表單某個欄位反覆填錯）。冇診斷就改設計，是把主觀喜好當成優化。

轉換率影響最大的六個位置

1. 首屏訊息 — 三秒內要答到「你是誰、幫我解決什麼、我要做什麼」。從廣告點進來的落地頁，首屏文案必須與廣告文案呼應，否則用戶會覺得來錯地方。
2. 表單欄位數量 — 每多一個必填欄位，完成率就下降。只留真正需要的：稱呼、聯絡方式、一句需求。公司名、職位、預算範圍可以在後續對話問。
3. CTA 文案 — 「提交」改成結果導向的說法，例如「索取報價」或「預約免費評估」。同時避免同一頁出現三種不同的主要行動，會造成決策癱瘢。
4. 社會證明位置 — 客戶標誌、具體數字、真實評價要放在用戶產生疑慮的位置附近，而不是全部堆在頁尾。
5. 價格透明度 — 香港用戶對「請聯絡我們索取報價」的抗拒度很高。即使只提供起始價或區間，詢盤質素都會明顯改善。
6. 聯絡摩擦 — WhatsApp 浮動按鈕在本地市場的效果通常勝過表單。確保它在所有滑動位置都可見，並且點擊後自動帶入預填訊息。

降低購物車棄置率

先分辨是摩擦問題還是意願問題。摩擦問題的解法：縮短結帳步數、支援訪客結帳、在購物車頁就顯示完整運費與稅項、增加本地付款方式如 FPS 與 PayMe、優化手機表單的 input type 與自動填入。意願問題的解法：棄置挽回電郵序列（1 小時、24 小時、72 小時三封）、動態再營銷廣告、以及在結帳頁補上退換貨政策與安全付款標示。另外必須檢查結帳頁的速度——結帳流程每慢一秒，完成率都會下跌。

A/B 測試的三個前提

• 樣本量要夠 — 每月一百個訪客的頁面做 A/B 測試冇統計意義。流量不足時應該改做定性研究：用戶訪談、可用性測試、五秒測試。
• 一次只測一個變數 — 同時改標題、按鈕顏色與表單長度，贏了也不知道是哪一項起作用。
• 先定假設與成功指標 — 「我認為把價格區間放上首屏，會提升表單提交率，因為用戶不必猜預算」。有假設，輸了也學到東西。

要留意 A/B 測試工具本身可能造成閃爍（FOUC）與 INP 惡化。實作上應該用伺服器端分流或至少確保測試腳本同步載入且體積極小。

AI SEO 與 GEO 生成式引擎優化

搜尋行為正在轉移。越來越多用戶在 Google AI Overview、ChatGPT、Perplexity 與 Gemini 直接取得答案，唔會再逐條連結點入去。這代表 SEO 的目標由「排第一」擴展到「被引用」。這門功夫叫 GEO（Generative Engine Optimization）生成式引擎優化。

GEO 與傳統 SEO 的三個關鍵差異

七項具體執行做法

1. 答案優先寫法 — 每個 H2 或 H3 之後，第一句直接回答該標題的問題，不要鋪陳。模型抽取內容時通常只取標題後的第一至第三句。
2. 用真實問句做 H3 — 「SEO 一般幾久才見到效果？」勝過「成效時間」。問句與用戶提問的措辭越接近，被匹配的機會越高。
3. 提高可核實事實密度 — 加入具體價格、百分比、時間門檻、標準數值。「LCP 應在 2.5 秒內」是可引用的，「速度要快」不是。
4. 段落自我完備 — 每段不要依賴上一段的代詞才能理解。模型抽取的是片段，脫離上下文仍要成立。
5. 結構化資料重述 — 用 FAQPage 與 HowTo 把同一批答案以機器可讀格式再講一次，降低模型誤讀的機會。
6. 實體一致性 — 品牌名、地址、電話、服務描述在全站與所有外部平台完全一致，讓模型確認你是同一個實體。這是被「認識」的前提。
7. 主題群集覆蓋 — 圍繞核心主題建立完整內容網絡。模型判斷權威的方式與 Google 類似：看你在該領域的覆蓋廣度與深度。

怎樣量度 GEO 成效

傳統排名工具幫不了太多。實務上我們用四個方法：一、定期用固定的問題清單在 ChatGPT、Perplexity、Gemini 及 Google AI Overview 上實測，記錄品牌是否被提及與被引用的頁面；二、在 Search Console 觀察印象數上升但點擊率下降的查詢，這通常是 AI 摘要吃掉點擊的訊號；三、在 GA4 檢視來自 AI 工具的推薦流量（chatgpt.com、perplexity.ai 等來源）；四、追蹤品牌名搜尋量的變化，被 AI 提及的間接效果往往表現為品牌搜尋上升。