我是吳承學，做搜尋引擎優化滿二十年。這幾年最常被問的一句話是：「文章我都寫了，為什麼 AI 摘要跟搜尋引擎就是不提我？」很多時候問題不在內容好不好，而在機器根本不確定「這篇是誰寫的、這個人可不可信」。作者實體標記，就是把「誰寫的」這件事，從人看得懂的文字，翻成機器能對齊、能查證的資料。這篇我只談一個主題：怎麼用 Person schema、sameAs 與跨站一致的作者資料，讓搜尋引擎與生成式引擎把你的名字認成同一個、可信任的人。

1. 我想讓 AI 引用我，得先解決「它根本不知道我是誰」

搜尋引擎與 AI 摘要在決定要不要引用一段內容時，會回頭問一個問題：這段話背後的人，在這個主題上有沒有可查證的資歷。若作者只是文章底部一行純文字姓名，機器只能猜；一旦作者被結構化成一個有明確識別碼、有外部佐證的實體，機器就能把不同頁面、不同平台上的同一個人串起來，累積成專業訊號。

1.1 純文字署名與結構化作者，機器讀到的差距

純文字署名對機器來說是一段沒有邊界的字串，同名同姓就會混淆。結構化的作者實體則帶著型別、識別碼與外部連結，等於替這個名字辦了一張機器看得懂的身分證。比起把資歷寫在頁面某處讓機器自己猜，明確標記能把辨識成本降到最低。

1.2 作者實體要回答的三個問題

我通常要求一份合格的作者實體，至少能替機器回答三件事：這是誰（姓名、職稱、任職單位）、憑什麼可信（外部可查證的個人頁面、專業檔案）、以及跨平台上這些身分是不是同一個人。缺了第三項，前兩項再漂亮也會被拆成好幾個互不相干的人。

2. 我決定在 Person schema 裡只填能被驗證的欄位

Person schema 的欄位可以填很多，但我的原則是：寧可少填，也不放無法對照到頁面內容或外部來源的資料。機器對「宣稱」的信任度，遠低於「可查證」。以下是我實際導入時，優先處理的欄位。

欄位 作用 我建議填法
name 作者主名稱 與各平台署名完全一致，含全名
url 作者在本站的正規頁面 指向站內作者頁，非文章頁
jobTitle 職稱 用實際頭銜，避免灌水形容詞
worksFor 任職組織 連到組織實體，與頁面顯示一致
knowsAbout 專業領域 列出實際長期產出內容的主題
sameAs 跨站身分連結 放可公開存取、由本人掌握的帳號

2.1 一份可直接改用的 Person 標記

下面是我常用的骨架，示範網址一律用 example.com，實際導入時換成你自己的正規網址。重點是這段標記裡的每一項，頁面上都要有對應的可見內容，不能只存在於程式碼裡。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/author/example-author/#person",
  "name": "示範作者",
  "url": "https://example.com/author/example-author/",
  "jobTitle": "資深搜尋優化顧問",
  "worksFor": {
    "@type": "Organization",
    "name": "示範顧問公司",
    "url": "https://example.com/"
  },
  "knowsAbout": ["搜尋引擎優化", "結構化資料", "內容策略"],
  "sameAs": [
    "https://example.com/linkedin-profile",
    "https://example.com/speaker-profile"
  ]
}

2.2 把作者實體綁進文章，而不是各寫各的

單獨放一段 Person 還不夠。文章的 Article 或 BlogPosting 標記裡，author 欄位要用 @id 指回同一個 Person 實體，讓機器知道「這篇的作者」就是「那個有完整檔案的人」。若文章裡的 author 只寫一個名字字串，跟站內作者頁的 Person 沒有連上，兩邊的專業訊號就無法互相累積。

3. 我把散落各站的帳號用 sameAs 串成同一個人

sameAs 是作者實體最容易被低估的一欄。它的任務是告訴機器：這個 Person，跟外部某個平台上的檔案，是同一個人。當機器能把你的個人專業檔案、講者頁、專欄頁都連在一起，你的專業就不再只靠自家網站自我背書，而是由多個外部來源相互佐證。

3.1 哪些連結放進 sameAs 才有意義

我只放兩類連結：一是由本人或所屬組織實際掌握、能長期維護的官方檔案；二是內容與作者專業高度相關、且該平台會顯示作者身分的頁面。臨時註冊、長期不更新、或無法證明由本人掌握的帳號，放進去反而稀釋可信度。連結必須可公開存取、回傳正常狀態碼，指向會 404 的頁面等於製造反效果。我實際核對過不少客戶的 sameAs，最常見的狀況是連結指向一個早已改版或搬家的舊網址，機器順著點過去撲空，這一欄的佐證力量就白白流失了。

3.2 sameAs 不是連結愈多愈好

我看過有人把十幾個社群帳號全塞進 sameAs，其中大半沒有內容、也沒有署名。機器要的是一致且可查證的佐證，不是數量。幾個真正能相互驗證身分、內容相關的外部檔案，勝過一長串空殼帳號。

4. 我讓每個平台的作者資料長得一樣，避免被拆成兩個人

跨站一致，是作者實體能不能被機器認成同一個人的分水嶺。同一位作者在自家網站用中文全名、在講者頁改用英文拼寫、在專欄又換成一個縮寫，機器很可能判成三個人，專業訊號因此被切碎。我早年替一位長期投稿的顧問整理資料時就吃過虧：他在四個平台用了三種署名寫法，我們花了好一段時間才把這些分身重新對齊、串回同一個人。我後來的做法是先定一份「作者主檔」，所有平台向它對齊，省下日後收拾殘局的功夫。

對齊項目 不一致時的風險 建議做法
姓名寫法 被判為不同人 全平台用同一種寫法與順序
職稱與任職 權威訊號被稀釋 以主檔為準，異動同步更新
個人簡介 專業焦點模糊 核心資歷描述保持一致
大頭照 視覺辨識降低 各平台用同一張近期照片
連結指向 身分無法互相佐證 互相指回同一組正規頁面

4.1 先立一份作者主檔，再往外對齊

我會在自家網站建一個獨立、可索引的作者頁，把姓名、職稱、專業領域、代表作與外部檔案連結都寫清楚，這一頁就是主檔。之後每上一個新平台，都拿這份主檔去填，而不是每次憑印象重寫。這樣半年後回頭看，各平台資料不會愈長愈歪。

4.2 換工作、改職稱時，記得回頭同步

作者資料最容易失準的時刻，是換單位或升遷。我實務上遇過作者早已離開原公司，schema 裡的 worksFor 卻掛了兩年沒改，結果機器同時讀到新舊兩個矛盾訊號。我的建議是把「更新作者資料」列進異動流程，讓一致性維持得住。

5. 我上線前會照這份順序自查

作者實體最怕的是「看起來有做，其實各處對不上」。我上線前會照固定順序檢查，寧可花十分鐘核對，也不要讓機器讀到互相打架的資料。

5.1 從標記到頁面，逐項對照

我會先用結構化資料測試工具確認 Person 沒有語法錯誤，再逐欄比對：schema 裡寫的職稱、任職、專業領域，頁面上是否都有對應的可見文字；author 的 @id 有沒有正確指回作者頁；sameAs 的每個連結是否都能開、都是本人掌握。可見內容與標記一致，是這一步的底線。

5.2 幾個我一再看到的錯誤

最常見的三個問題：一是作者頁用前端動態渲染，檢視原始碼看不到作者資訊，機器抓不到；二是 sameAs 放了會 404 或已停用的連結；三是同一個人在不同頁面用了不同的 @id，等於自己把自己拆成好幾個實體。這三項只要有一項，累積專業訊號的效果就會打折。導入後通常要數週，外部佐證與站內資料才會被穩定關聯，不必期待隔天見效。

6. 常見問題

6.1 只放純文字署名，機器真的認不出作者嗎

機器能讀到名字，但無法確定同名的人是不是同一個，也難以判斷這個人在該主題上的可信度。結構化的作者實體提供了識別碼與外部佐證，讓辨識與累積專業訊號都更穩定。

6.2 sameAs 應該放幾個連結才合適

沒有固定數字。原則是每個連結都要能相互佐證身分、內容相關、由本人掌握且可正常開啟。幾個高品質連結，效果通常勝過一長串空殼帳號。

6.3 作者頁用前端框架動態產生，會有影響嗎

可能有。若檢視原始碼時作者資訊是空的、要靠瀏覽器執行程式才出現，機器有機會漏抓。建議讓作者資訊在初始回應的 HTML 裡就能被讀到。

6.4 一個網站有很多作者，每個都要做嗎

建議至少替長期產出、且內容涉及專業判斷的主要作者建立完整實體。偶爾投稿一兩篇的作者可視情況簡化，但主要作者的一致性愈完整，整站的專業訊號愈扎實。

6.5 導入作者實體後，多久會看到成效

這類訊號屬於長期累積，通常要數週讓機器重新抓取並關聯外部佐證，而且成效受內容品質與外部提及等因素共同影響，難以保證固定時程或幅度。把它當成長期信任資產經營，比追求短期名次波動實際。

延伸閱讀