文章寫得好、排名也不差，AI 摘要卻始終不提你，問題常常不在內容本身，而在機器根本不確定「這篇是誰寫的、這個人可不可信」。作者實體標記要解決的就是這件事：把「誰寫的」從一段人看得懂的文字，翻成機器能對齊、能查證的資料。這篇只談一個主題，就是怎麼用 Person schema、sameAs 與跨站一致的作者資料，讓搜尋引擎與生成式引擎把你的名字認成同一個、且可信任的人。把這套做對，你累積的每一分專業，才會真的記在同一個身分上，而不是被拆散成好幾個互不相干的名字。
1. 想讓 AI 引用我，得先解決「它根本不知道我是誰」
搜尋引擎與 AI 摘要在決定要不要引用一段內容時，會回頭問一個問題：這段話背後的人，在這個主題上有沒有可查證的資歷。這一節先講清楚，為什麼純文字署名過不了這一關，以及結構化的作者實體解決了什麼。先把這個前提想通，後面填欄位、串連結的每一步才知道自己在解決什麼問題，而不是照表操課卻不知所以然。很多人做了作者頁卻沒效果，往往是因為只做了外觀，沒做機器看得懂的那一層。
1.1 純文字署名與結構化作者，機器讀到的差距
純文字署名對機器來說是一段沒有邊界的字串，同名同姓就會混淆，它無法確定「王小明」是不是另一頁的那個「王小明」。結構化的作者實體則帶著型別、識別碼與外部連結，等於替這個名字辦了一張機器看得懂的身分證。比起把資歷寫在頁面某處讓機器自己猜，明確標記能把辨識成本降到最低。我們在協助內容型網站盤點時，常看到作者資訊寫得很完整、卻全是人看的文字，機器抓到的只有一個名字，其餘的資歷它讀不進去，等於白寫。差別就像把一份履歷印在紙上貼在牆角，跟把它整理成一份有欄位、可被系統讀取的檔案：前者人看得懂、機器只看到一團文字，後者才能被拿去跟其他資料交叉比對。作者實體標記做的，就是把後面這份機器可讀的檔案補上，讓你寫在頁面上的資歷真的被機器用得到。
1.2 作者實體要回答的三個問題
我們通常要求一份合格的作者實體，至少能替機器回答三件事：這是誰（姓名、職稱、任職單位）、憑什麼可信（外部可查證的個人頁面、專業檔案）、以及跨平台上這些身分是不是同一個人。缺了第三項，前兩項再漂亮也會被拆成好幾個互不相干的人。這三個問題環環相扣，少一個，累積的專業訊號就會出現斷點，機器無法把散落各處的足跡串成一個完整的人。
1.3 可信度為什麼會影響被引用
AI 在挑引用來源時，不只看單段內容寫得好不好，也會參考這段話背後的人在該領域是否可信。當一個作者被結構化成有識別碼、有外部佐證、跨站一致的實體，機器對它的信任度會比對一個來路不明的名字高。這不代表有了標記就一定被引用，可信度只是影響因素之一，內容品質、新鮮度與網站整體權威仍然各佔比重。但在其他條件相近時，一個機器認得出、查得到的作者，確實比一個模糊的署名更容易被採信。
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 沒有連上，兩邊的專業訊號就無法互相累積，文章享受不到作者的可信度，作者頁也接不到文章的佐證。@id 這條線，是把兩者縫在一起的關鍵。具體來說，作者頁的 Person 有一個 @id，文章的 author 就用同一個 @id 指回去，機器讀到時就知道這是同一個實體的兩處出現，而不是剛好同名的兩個人。一個站若有幾十篇文章，這條線把它們全部導向同一個作者實體，作者的每一篇產出都在替這個身分累積佐證，整站的專業訊號才會往同一個點集中，而不是散成一地。
2.3 少填勝過亂填
常有人想把 Person schema 的欄位塞好塞滿，以為填得越多越完整。但機器對每一個欄位都會試著對照，填了卻對不上頁面或外部來源的資料，不只沒加分，還會削弱整段標記的可信度。我們的做法是只填有把握、能被驗證的欄位，其餘留白。一份精簡但每項都站得住的標記，勝過一份看起來豐富、卻處處對不上的標記。寧缺勿濫，在這裡是很實際的原則。換個角度想，每多填一個無法驗證的欄位，就是多給機器一個挑出矛盾的機會；而每一個站得住的欄位，都是在替作者加一分可信。與其用數量堆出一份看似完整的檔案，不如讓每一項都能被外部或頁面佐證，整體的信任才是累加而非互相抵銷。
3. 我把散落各站的帳號用 sameAs 串成同一個人
sameAs 是作者實體最容易被低估的一欄。它的任務是告訴機器：這個 Person，跟外部某個平台上的檔案，是同一個人。當機器能把你的個人專業檔案、講者頁、專欄頁都連在一起，你的專業就不再只靠自家網站自我背書，而是由多個外部來源相互佐證。
3.1 哪些連結放進 sameAs 才有意義
我們只放兩類連結：一是由本人或所屬組織實際掌握、能長期維護的官方檔案；二是內容與作者專業高度相關、且該平台會顯示作者身分的頁面。臨時註冊、長期不更新、或無法證明由本人掌握的帳號，放進去反而稀釋可信度。連結必須可公開存取、回傳正常狀態碼，指向會 404 的頁面等於製造反效果。我們實際核對過不少客戶的 sameAs，最常見的狀況是連結指向一個早已改版或搬家的舊網址，機器順著點過去撲空，這一欄的佐證力量就白白流失了。另一個常見誤區是把公司官網首頁當成 sameAs 放進去，但首頁不等於作者本人的檔案，機器無法從中確認那個人的身分。sameAs 要放的是「能證明這個人是這個人」的頁面，而不是任何跟他沾得上邊的網址。選連結時問自己一句：點進去，看得出這就是那位作者嗎，看不出就不該放。
3.2 sameAs 不是連結愈多愈好
我們看過有人把十幾個社群帳號全塞進 sameAs，其中大半沒有內容、也沒有署名。機器要的是一致且可查證的佐證，不是數量。幾個真正能相互驗證身分、內容相關的外部檔案，勝過一長串空殼帳號。與其追求列得滿，不如確保每一條都經得起點進去檢視，這樣整欄傳達的訊號才乾淨、可信。
3.3 連結失效的代價比想像中大
sameAs 裡的連結一旦失效，傷害不只是少了一個佐證。機器順著一個死連結過去撲空，會降低它對整段標記的信任，因為這代表你提供的資料沒有被維護。我們建議把 sameAs 的連結納入定期檢查，平台改版、帳號停用、網址變動都可能讓它悄悄失效。把這些連結當成需要維護的資產，而不是填一次就不管，才能讓這一欄長期維持它的佐證價值。實務上可以把它併進既有的連結檢查流程，和站內死連結一起定期掃，成本不高，卻能及早抓到悄悄失效的 sameAs。對內容量大的站，這種例行維護尤其值得，因為作者數一多，失效連結累積起來就會拖累整體的可信度。
4. 我讓每個平台的作者資料長得一樣，避免被拆成兩個人
跨站一致，是作者實體能不能被機器認成同一個人的分水嶺。同一位作者在自家網站用中文全名、在講者頁改用英文拼寫、在專欄又換成一個縮寫，機器很可能判成三個人，專業訊號因此被切碎。
| 對齊項目 | 不一致時的風險 | 建議做法 |
|---|---|---|
| 姓名寫法 | 被判為不同人 | 全平台用同一種寫法與順序 |
| 職稱與任職 | 權威訊號被稀釋 | 以主檔為準，異動同步更新 |
| 個人簡介 | 專業焦點模糊 | 核心資歷描述保持一致 |
| 大頭照 | 視覺辨識降低 | 各平台用同一張近期照片 |
| 連結指向 | 身分無法互相佐證 | 互相指回同一組正規頁面 |
4.1 先立一份作者主檔，再往外對齊
我會在自家網站建一個獨立、可索引的作者頁，把姓名、職稱、專業領域、代表作與外部檔案連結都寫清楚，這一頁就是主檔。之後每上一個新平台，都拿這份主檔去填，而不是每次憑印象重寫。這麼做半年後回頭看，各平台資料不會愈長愈歪。主檔的好處是給了所有分身一個單一的事實來源，要更新時只要先改主檔、再往外同步，不會出現各處說法兜不攏的情況。我早年替一位長期投稿的顧問整理資料時就吃過虧：他在四個平台用了三種署名寫法，我們花了好一段時間才把這些分身重新對齊、串回同一個人。那次之後我就養成先立主檔的習慣，把一致性的工夫放在前面，而不是等資料長歪了再回頭收拾，後者的成本高得多。
4.2 換工作、改職稱時，記得回頭同步
作者資料最容易失準的時刻，是換單位或升遷。我們實務上遇過作者早已離開原公司，schema 裡的 worksFor 卻掛了兩年沒改，結果機器同時讀到新舊兩個矛盾訊號，反而不確定該信哪一個。我的建議是把「更新作者資料」列進異動流程，換工作、改職稱的當下就順手同步各平台與標記，讓一致性維持得住，而不是等哪天被發現才補。
4.3 一致性是被正確理解的前提
這套邏輯跟品牌實體的做法一脈相承：要被機器正確理解，一致性是前提。作者頁、文章署名、外部檔案講的是同一個人、同一組專業，機器就容易建立正確的作者畫像；若各處說法兜不攏，它反而可能略過或誤述。一致不代表每個平台都要一字不差地複製，而是核心的身分資訊與專業定位要對得起來，讓機器無論從哪個入口認識你，拼出來的都是同一個人。
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 導入作者實體後，多久會看到成效
這類訊號屬於長期累積，通常要數週讓機器重新抓取並關聯外部佐證，而且成效受內容品質與外部提及等因素共同影響，難以保證固定時程或幅度。把它當成長期信任資產經營，比追求短期名次波動更實際。與其盯著名次，不如觀察品牌與作者相關搜尋的呈現是否逐漸變得完整，例如搜尋作者名字時，結果是否開始把他的各個專業檔案正確關聯起來。這種變化通常是漸進的，代表機器對這個作者的理解正在變得更穩定，這比單一關鍵字的名次更能反映作者實體有沒有被建立起來。
6.6 worksFor 換了公司還沒改，會怎樣
機器可能同時讀到新舊兩個矛盾的任職訊號，反而不確定該信哪一個，削弱作者畫像的清晰度。建議把更新作者資料列進換工作、改職稱的異動流程，在當下就同步各平台與標記。保持一致不難，難的是記得在異動當下就處理，而不是拖到被發現才補。