從資訊檢索原理看 SEO：實體、主題廣度與查詢對齊的三個實作點
談 SEO 專利很容易變成兩種極端：一種是把專利當成排名公式逐字照做，一種是完全不看，認為專利只是研究方向。比較實際的用法是第三種：把專利當成「Google 用什麼角度看一份文件」的線索，再回頭檢查自己的網站有沒有給出這些角度需要的訊號。
以下三個角度，是我們在做技術優化時實際會動手改的東西，每一項都附上可以自己檢查的方法。
一、實體優先於字串：先讓機器知道你是誰
搜尋系統早就不是把查詢當字串比對。查詢會先被解析成實體與意圖，文件也會被解析成實體集合，再看兩邊對不對得上。這代表一件很現實的事：如果你的公司在網路上沒有一組穩定、可交叉驗證的身分資料，你就不是一個「實體」，只是一堆字。
可以自己檢查的三個訊號：
- 同一組事實（品牌名、法定名稱、成立年、所在地、負責人、聯絡方式）是否在官網、社群簡介、商業登記與結構化資料裡完全一致，沒有互相矛盾。
- Organization 結構化資料裡有沒有 name、url、logo、foundingDate、address、contactPoint、sameAs 這幾個欄位。缺 foundingDate 與 address 是最常見的漏洞。
- sameAs 有沒有指向你真正在經營的官方檔案，而不是隨便列一堆社群。
這一步做完之前，做再多關鍵字都事倍功半，因為系統不確定這些頁面在講同一個主體。
二、主題廣度與內部連結：一個主題要有整片內容，不是一篇
資訊檢索的相關性判斷會參考文件所屬網站在該主題上的整體覆蓋度。單篇文章寫得再好，如果整站只有這一篇在講這個主題，它在競爭激烈的字上很難站穩。
實作方式是主題叢集：一個核心頁負責主要查詢，周邊多篇文章各自負責一個子問題，彼此互連。以「台中行銷顧問」為例：
| 角色 | 負責的查詢 | 連結方向 |
|---|---|---|
| 核心頁（服務項目） | 台中行銷顧問、行銷顧問公司 | 接收所有子頁連結 |
| 子頁 A（定價） | 行銷顧問怎麼收費、顧問月費 | 連回核心頁，並連向案例頁 |
| 子頁 B（合作方式） | 顧問陪跑是什麼、方案制差別 | 連回核心頁 |
| 子頁 C（成效驗收） | 顧問成效怎麼看、報表看什麼 | 連回核心頁與數據類文章 |
| 子頁 D（在地） | 台中中小企業行銷、中彰投 | 連回核心頁與在地文章 |
內部連結的錨點文字要用真實查詢語句，不要用「點此了解更多」。錨點文字是系統理解目標頁主題的重要輸入。
三、查詢語意與段落對齊：讓每個問題都有一段專屬回答
同一個主題底下，使用者的問法會有幾十種變體。系統在比對時看的是語意，不是字面。所以與其把同義詞硬塞進同一段，不如替每一種問法各寫一段直接回答。
做法很單純：
- 從 Google Search Console 匯出這個頁面已經有曝光的查詢，取前五十筆。
- 把語意重複的合併，通常會收斂成八到十五種真實問法。
- 每一種問法寫成一個 H2 或 H3，底下第一句直接回答。
- 回答長度控制在八十到一百二十字，超過就往下拆子段落。
這個方法同時服務三件事：傳統排名的相關性、AEO 的答案抽取、以及 LLM 引用時的段落完整性。
技術面不要漏掉的六個基本盤
上面三個角度是策略面。技術面有六件事如果沒做，前面都會打折：
| 項目 | 通過標準 | 常見錯誤 |
|---|---|---|
| canonical | 每頁指向自己，參數頁指向主網址 | 分頁全部指向第一頁 |
| 索引控制 | 該收錄的沒有 noindex，會員頁與購物流程有 noindex | 整站被 noindex 卻沒人發現 |
| 內容在原始 HTML | 關掉 JavaScript 仍看得到主要內容 | 靠前端框架渲染，爬蟲拿到空殼 |
| 標題與描述 | 每頁獨立且具體，含品牌名與該頁角色 | 全站共用同一組描述 |
| 圖片替代文字 | 描述圖片內容並含自然關鍵字 | 留空或塞滿關鍵字 |
| Sitemap 與 lastmod | 內容更新後 lastmod 跟著變 | lastmod 永遠是產生當天 |
這六項我們會在接手任何一個網站的第一週全部掃過一次，通常會找出三到五個問題。以我們最近一次全站掃描為例：二一六個網址逐頁檢查，缺描述零頁、H1 數量不等於一的零頁、混合內容零頁，這種狀態才算把基本盤守住。
先做哪一項
如果資源有限，順序是：實體一致性 → 技術基本盤 → 主題叢集 → 查詢對齊。實體與技術是地基，做完之後每一篇新內容的效益都會提高；反過來先寫一百篇文章而地基沒補，效益會被大量稀釋。
想確認自己的網站現在卡在哪一層，可以先看服務項目裡的技術優化說明，或預約諮詢做一次現場檢查。
三個常見的技術債，以及修好之後看到的變化
第一個是分頁的 canonical 全部指向第一頁。這會讓第二頁之後的內容等於不存在，商品數多的電商最常中招。修正方式是每一頁指向自己，並確認分頁之間有 rel 連結。我們處理過一個服飾客戶，修正後兩個月內被收錄的商品頁數從一百多頁增加到八百多頁。
第二個是內容靠前端框架渲染，爬蟲拿到空殼。判斷方式很直接：把瀏覽器的 JavaScript 關掉重新載入，看主要內容還在不在。不在就要處理伺服器端渲染或預先產生 HTML，這件事無法用其他優化補救。
第三個是 lastmod 永遠是 sitemap 產生當天。這會讓搜尋引擎無法判斷哪些頁面真的更新過，久了就會降低抓取頻率。正確做法是讓 lastmod 跟著內容修改時間變動，內容沒改就不要動它。
這三項都不需要新預算，但都需要有人真的打開後台去看。我們接手網站的第一週會把它們全部掃過一次，通常會找出三到五個問題。