文章目錄
Google 預估薪酬新屬性 jobBenefits 與 industry：徵才頁怎麼填才不被退件
jobBenefits 與 industry 是 Google 在「預估薪酬」（Estimated Salary）結構化資料裡新增的兩個選填屬性，前者用一段文字描述公司福利（官方範例是「6 weeks paid vacation every year」），後者標示職位產業（Technology、Healthcare、Finance 這類英文規範值）。只要你的頁面本來就用了 Occupation 或 OccupationAggregationByEmployer 這套 JSON-LD，加上這兩個欄位屬於低風險動作，回報是讓職缺在搜尋結果多出產業與福利線索，提高被合適人才點擊的機率，而不是直接保證排名。
TL;DR：jobBenefits、industry 是預估薪酬規範下的兩個選填屬性，依附在 Occupation 物件最外層；填錯層級或塞到 JobPosting 裡完全不會顯示。根據 Google 官方 Estimated Salary 文件，industry 須用英文規範值，jobBenefits 是一段字串而非陣列，實測建議觀察 7 到 28 天的曝光與點擊變化。
很多招募人員聽到「Google 又加新欄位」就緊張，深怕慢了一步。先把結論講清楚：這不是演算法地震，而是招募漏斗最上層的一個小訊號。你該在意的不是「有沒有加」，而是「加在哪、寫什麼、會不會被判定資料不實」。對連SEO 基礎都還在打底的團隊來說，這兩個欄位更該當成選做項目，而不是必做項目。下面會逐段拆給你看。
先把結論講清楚：jobBenefits 與 industry 是什麼、寫了會發生什麼事
這兩個欄位的本質很單純。industry 告訴 Google「這個職位屬於哪個產業」，jobBenefits 用一句話告訴 Google「這家公司提供什麼福利」。它們都掛在預估薪酬的 JSON-LD 之下，跟 sampleSize、yearsExperienceMin、yearsExperienceMax 同一層級，不是巢狀塞進 estimatedSalary 物件裡。搞懂這個位置，後面的問題就少一半。
先看兩者的基本差異，這張表是這篇文章最該記住的東西：
| 欄位 | 接受格式 | 範例值 | 常見錯誤 |
|---|---|---|---|
| industry | 字串（英文規範值） | “Technology”、”Finance” | 寫成「科技業」中文 |
| jobBenefits | 字串（自然語言一句話） | “6 weeks paid vacation every year” | 塞成陣列或廣告詞 |
實務上我會把這次更新看成「從薪資導向走向價值導向」的招募轉變。過去求職者在結果頁只看得到一個數字區間，現在多了一條福利、一個產業標籤，等於在點擊之前就先做了一輪自我篩選。這對轉換率的意義不是「更多人點」，而是「更對的人點」。當然，前提是你的欄位值是真的。
有個底線要先講：這兩個欄位都是選填（optional）。不填不會被懲罰，但亂填會被撤掉複合式結果。所以與其焦慮「要不要馬上加」，不如先確認「我寫的東西頁面內文找不找得到」。這跟E-E-A-T 裡強調的 Trust 一脈相承，結構化資料寫得再漂亮，只要有一條跟事實對不上，信任就破功。這也是後面四個地雷段的伏筆。
退一步看，這次更新其實呼應了 Google 這幾年對搜尋最佳化的一貫方向：要你給機器更清楚的訊號，而不是塞更多關鍵字。理解了這個脈絡，就不會把 jobBenefits、industry 當成獨立任務，而是整頁訊號策略的一環。
釐清一個常被搞混的地方：預估薪酬 vs 徵才結構化資料，兩者差在哪
兩套規範服務的頁面類型完全不同
預估薪酬（Estimated Salary）呈現的是「某個職業在某地區的大致薪資範圍」，適合薪資查詢站、產業薪資報告頁；徵才結構化資料（JobPosting）則是給單一職缺招募訊息用的。判斷準則只有一句話：問自己「這頁是要讓人投履歷，還是讓人查薪資行情」。前者走 JobPosting，後者才碰預估薪酬。這個判斷跟搜尋意圖的分析邏輯完全一致，先把意圖搞對，再選工具。
這裡要小心，新加的 jobBenefits、industry 目前只掛在預估薪酬這邊。對單純發職缺的人來說，重點不是趕快把這兩個欄位抄過去，而是先判斷自己屬於哪一種頁面類型。把兩套規範的欄位混抄，是這陣子最常見的踩雷方式，跟關鍵字堆砌一樣，都是「看到好東西就硬塞」的壞習慣。
- JobPosting：單一職缺，含 datePosted、hiringOrganization、employmentType，是多數徵才頁該用的。
- Estimated Salary（Occupation）：職業層級的薪資分布，適合薪資資料庫、產業薪資報告。
- OccupationAggregationByEmployer：把同一雇主的職業資料彙總，新屬性可加在這裡。
我用白話說一次：JobPosting 像是一張徵人單，預估薪酬像是一份市場行情表。你在徵人單上貼市場行情的欄位，Google 會看不懂、直接忽略。這也是為什麼有些人照著教學加了欄位，結果複合式搜尋結果一點動靜都沒有，因為根本放錯物件。職缺類型的選擇也會影響點閱率的計算基準，別小看這一步。
如果你想更深入了解預估薪酬背後的產品結構化資料思維，會發現 Google 對「把頁面事實講清楚」這件事越來越執著，從電商到徵才都是同一套邏輯。
為什麼這兩個欄位值得馬上做：從薪資導向到價值導向的招募轉變
因為求職者現在在搜尋「軟體工程師 薪資」時，點擊前就會比較結果頁上的線索。有 industry 標籤能讓對方一眼看出「這是科技業」，有 jobBenefits 能多出一條「提供彈性工時、遠端選項」的訊息。當多數競品還沒補上這兩個欄位時，先做等於在搜尋結果頁就完成第一輪篩選，點閱率提升之後，招募端也能少花力氣在後續溝通成本。
這裡要強調一個分寸：這是「提高被合適人才點擊的機率」，而不是「保證排名」。如果你期待加兩個欄位就讓職缺頁衝上前三名，那一定會失望，因為排名因素從來不是單一欄位決定的。但如果你把它看成招募漏斗最上層（曝光）的小幅調整，ROI 其實不差，畢竟工程師改幾行 JSON-LD 就能完成，沒有平台串接成本。
換個角度想，產業標籤還能過濾掉不相關流量。想找金融業的人不會誤點科技業頁面，名單品質跟著提升。招募人資最怕的不是履歷少，而是履歷進來後才發現媒合度低、白忙一場。industry 在這個環節幫你做的是前置過濾，這層價值很多人沒算進去。這跟長尾關鍵字篩出精準流量的道理相通，越上層過濾得乾淨，下層轉換就越省力。
真要說的話，這次更新也順便提醒招募端：你的內容行銷不能只靠薪資數字說話。福利、產業定位這類價值訊號，在搜尋結果頁就要露出來，否則連點擊的機會都沒有。
實戰第一步：找到你頁面現有的預估薪酬 JSON-LD 程式碼
先確認頁面本來就有這套結構化資料
先在你要改的頁面按右鍵檢視原始碼，搜尋 ld+json 或 @type，看看有沒有出現 Occupation、OccupationAggregation 或 OccupationAggregationByEmployer。如果有，那就是你要動手的位置；如果完全沒有，代表你頁面本來就沒有預估薪酬結構化資料，這時要先從零開始建一段，而不是直接加 jobBenefits。順序錯了，後面全白忙。
實務上建議先用 Google 的 Rich Results Test（複合式搜尋結果測試）貼上網址，確認 Google 目前讀到什麼結構，再決定改哪一段。單看原始碼有時會被誤導，因為有些外掛會把 JSON-LD 動態注入，原始碼跟 Google 實際抓到的版本不一定一致。先看官方工具的判讀結果，比你盯著原始碼猜測準確得多。如果你常用 Google 工具，Site Kit by Google 也能幫你在 WordPress 後台直接看部分資料。
若頁面是用 ATS 或 CMS 自動產生，要先確認該外掛是否支援這兩個欄位。以 WordPress 來說，多數 SEO 外掛目前對預估薪酬的支援還很有限，多半需要你手動在站內 SEO 的 Schema 設定裡補一段自訂 JSON-LD。這一步是工程問題，不是內容問題，別用人資的角度硬喬。
- 搜尋關鍵字：ld+json、@type、Occupation
- 常見位置：
<head>內或<body>開頭的<script type="application/ld+json"> - 驗證工具優先順序：Rich Results Test 先用，Schema Markup Validator 補充
- 若外掛不支援：請工程師在範本層加一段自訂 JSON-LD，不要靠手動改單頁
老實說，很多人的預估薪酬頁根本從來沒上線過 JSON-LD，只是把薪資數字寫在內文裡。這種情況下，jobBenefits、industry 對你來說是「未來式」，不是「現在式」。先把 schema 這層補齊，再回來談新欄位，否則你加的東西根本沒地方掛。如果你連 schema 是什麼都還模糊，Google 官方 SEO 入門指南會是更實用的起點。
實戰第二步：把 industry 與 jobBenefits 加到正確的位置
位置、格式、值，三件事一次講清楚
這兩個欄位要加在 Occupation 或 OccupationAggregationByEmployer 物件的最外層，跟 sampleSize、yearsExperienceMin、yearsExperienceMax 同一層級，不要塞進 estimatedSalary 物件裡。industry 用英文產業名稱的字串（例如 “Technology”、”Healthcare”、”Finance”），jobBenefits 用一段自然語言的字串描述（例如 “6 weeks paid vacation every year”）。這是官方文件寫死的格式，沒有討論空間。
這裡給一個簡化後的 JSON-LD 骨架，方便你對照自己頁面的結構：
| 層級 | 欄位 | 類型 | 說明 |
|---|---|---|---|
| 最外層 | @type | 字串 | Occupation 或 OccupationAggregationByEmployer |
| 最外層 | name | 字串 | 職位名稱 |
| 最外層 | estimatedSalary | 物件 | 薪資區間，含 minValue/maxValue |
| 最外層（新） | industry | 字串 | 英文規範值，例如 “Technology” |
| 最外層（新） | jobBenefits | 字串 | 一句話描述最具吸引力的福利 |
台灣讀者要留意一個關鍵：英文值是給 Google 機器理解的訊號，真正的中文福利說明仍要寫在頁面內文給讀者看，不要為了欄位把整頁改成英文。industry 寫 “Technology”，內文照樣寫「隸屬資訊科技業，主力產品為 SaaS」；jobBenefits 寫英文一句話，內文用中文完整說明同一項福利。兩者各司其職，才不會兩頭落空。
老實說，industry 的值是最容易被偷懶搞砸的地方。有人直接寫「高科技業」，有人寫「IT」，這些都不在規範值清單裡，Google 可能直接不採用。穩妥的做法是參考 Google 官方的「預估薪酬」文件裡列出的範例值，照著抄比自創安全。挑產業值的時候也可以搭配語意關鍵字的思維，想想求職者會用哪些詞搜尋你的職缺。
如果你對 JSON-LD 的物件層級概念還不熟，建議先讀過標題標籤與結構的關係，建立「訊號要放在對的層級」的直覺，再回來改 JSON-LD 會順很多。
實戰第三步：用 Rich Results Test 驗證、上線後持續觀察
驗證不只是跑工具，而是看 Google 真的讀到什麼
改完後，把頁面網址丟進 Google 的 Rich Results Test，看 jobBenefits 與 industry 是否被正確解析、有沒有紅字警告。確認無誤再上正式環境，上線後在 Search Console 的「複合式報告」裡追蹤「預估薪酬」這個報表，觀察 7 到 28 天內的點擊與曝光變化。不要只看程式碼本身，因為有些欄位語法對、但內容被 Google 判定「與頁面不符」仍會失效。
這一點我想特別提醒：很多團隊改完 JSON-LD 就收工，根本沒回去看 Search Console 的報表。語法正確不代表結果正確。Google 會在索引與呈現階段做第二次判斷，只要它認為你的福利文字跟內文兜不起來，複合式結果照樣不會出現。驗證要分兩段：工具判讀是第一段，Search Console 的資料是第二段。想看流量怎麼被分配，Google Analytics 可以拿來做交叉比對。
- 驗證工具：Rich Results Test（優先）、Schema Markup Validator（補充）
- Search Console 路徑：搜尋結果報表內的複合式搜尋結果，找預估薪酬分類
- 觀察期：7 到 28 天，再看曝光與點擊是否變動
- 常見失效原因：福利文字與頁面內文不一致、industry 用了非規範值
若觀察期過了還是沒動靜，先別急著加更多欄位。回頭檢查兩件事：industry 是不是規範值、jobBenefits 寫的福利在內文找不找得到。九成的失效出在這兩個地方，而不是 JSON-LD 語法本身。如果你發現問題出在頁面根本沒被好好收錄，那要先解決的是技術 SEO 盲點，而不是結構化資料的細節。
最容易踩的四個地雷：選填不代表亂填
四個地雷，一個比一個容易把成果歸零
第一個地雷是把 industry 寫成中文或自創值（例如「高科技業」），Google 可能直接不採用；第二個是把 jobBenefits 填成廣告詞（「全球最佳公司」）而非具體福利，會被當成不實資訊；第三個是福利寫了但頁面內文找不到對應說明，造成資料與內容不符，可能觸發手動處置（manual action）撤掉複合式結果；第四個是把預估薪酬的欄位錯填到 JobPosting 物件裡，語法看似沒錯但 Google 完全不會顯示。
守住的原則只有一句：只寫頁面真的有的內容、用規範的英文值、放對物件層級。這三條聽起來像廢話，但實際專案裡，違反這三條的案例我見過太多。尤其是第三條，很多行銷為了讓福利看起來吸睛，會把 jobBenefits 寫得比內文浮誇，結果被判定資料不實。內容行銷的基本功在這裡一樣適用：說你做得到的，做到你說的。這部分可以參考我們對10 倍內容的討論，核心都是「別為了包裝犧牲真實」。
| 地雷 | 錯誤做法 | 正確做法 |
|---|---|---|
| industry 值 | 寫「科技業」「IT」 | 用 “Technology” 等規範值 |
| jobBenefits 內容 | 寫「全球最佳雇主」 | 寫「6 weeks paid vacation」 |
| 資料與內文一致性 | 欄位寫遠端、內文沒提 | 內文也要有對應福利說明 |
| 欄位位置 | 塞進 JobPosting 物件 | 放 Occupation 最外層 |
說到底，選填欄位給的是彈性，不是免死金牌。Google 對「資料不實」的判定不會因為欄位是選填就放水，一旦被歸類為垃圾內容，影響的不只這一個複合式結果，而是整個網站的信任訊號。這也是為什麼我們一直強調E-A-T 與YMYL 的框架，求職與薪資這類頁面本身就貼近 YMYL 邊界，寧可保守也不要浮誇。
這裡還有一個常被忽略的點要提醒：如果你的職缺頁同時有重複版本（例如 ATS 自動產生多個網址），結構化資料不一致會被當成重複內容處理，連帶影響預估薪酬的呈現。上線前先用301 重定向把版本收斂好，比事後救火輕鬆。
2026 年的調整：AI 搜尋與 GEO 之下，職缺內容怎麼被引用
當 AI 概覽直接組答案，這兩個欄位成了事實聲明
2026 年的搜尋場景裡，AI 產生的概覽（AI Overview）會直接從結構化資料與內文抽取關鍵資訊，組成「某職業在科技業的平均薪資與常見福利」這類答案。當你的 industry 與 jobBenefits 寫得具體且與內文一致，被 AI 引用為來源的機率會提高，等於多了不靠藍色連結的曝光管道。這是GEO（生成式搜尋最佳化）思維下最該把握的機會。
調整方向是：把這兩個欄位當成「給機器讀的事實聲明」，內文再用人話補充，讓 AI 引用與真人閱讀都能拿到同一套一致的事實。要避免的是欄位與內文各說各話，那會讓 AI 不知道該信哪一邊。AI 引用的邏輯其實跟人很像，它也討厭前後矛盾，一旦發現欄位跟內文兜不起來，就會降低這個來源的優先級。對 AI 搜尋整體怎麼運作，可以先看AI Overviews 的完整解析。
攤開來說，AI 概覽傾向引用結構化、可機讀、與內文一致的資料。industry、jobBenefits 在這個框架下，價值從「多一條福利訊息」升級成「被 AI 當作可信任的事實聲明」。這也是為什麼我前面一直強調一致性比花俏措辭更重要。想追蹤這波生成式搜尋對流量的衝擊，可以把預估薪酬報表的資料跟 AI 引用情況一起看。
一個務實建議：欄位寫英文規範值、內文寫中文白話說明，兩者對應同一組事實。例如 industry 寫 “Technology”、jobBenefits 寫 “Remote-friendly with flexible hours”，內文就照樣寫「本公司為資訊科技業，提供遠端與彈性工時」。這套雙軌寫法能同時餵飽 Google 的機器判讀與 AI 概覽的事實抽取，一魚兩吃。如果你打算用 AI 工具輔助寫徵才文案，ChatGPT 或 Claude 拿來產英文 jobBenefits 草稿還不錯，但最終一定要人工對照內文校正。
講到 AI 搜尋，也順帶提一個不少人問的：AEO（答案引擎最佳化）與AISO 在職缺內容上的應用。這兩個框架的核心都一樣，把事實講清楚、講一致，AI 就會偏好引用你。對預算有限的中小企業，AISO 策略裡的「先顧好結構化資料」這條，CP 值最高。
台灣場景的落地建議：英文規範值加中文內文的雙軌寫法
英文給機器、中文給真人，兩軌並行不衝突
建議採雙軌：industry 這類給機器讀的欄位用英文規範值（Technology、Finance），jobBenefits 主版本寫英文一句話、必要時在內文用中文完整說明同一項福利。原因是 Google 的結構化資料解析對英文規範值最穩定，但你的真實讀者是台灣求職者，所以福利的「人話版本」要落在頁面內文。
不要為了 SEO 把整頁改成英文，也不要為了親和力把 industry 改成中文，兩者各司其職才不會兩頭落空。台灣徵才頁的慣例是中文內文加英文專有名詞，這套雙軌寫法其實很符合現況，工程師只要在 JSON-LD 多填兩個欄位，不動到版面。
- industry：英文規範值（給機器），頁面內文可補中文產業名稱
- jobBenefits：英文主版本一句話加內文中文白話詳述
- 範例：industry 寫 “Technology”，內文寫「隸屬資訊科技業，主力產品為 SaaS」
- 避免：整頁中英夾雜或為了欄位把品牌頁改成純英文
真要說的話，這套雙軌邏輯不只適用預估薪酬。你在做答案引擎最佳化、做2026 SEO 趨勢裡談的 AI 搜尋轉型時，核心都是同一件事：給機器可機讀的事實、給真人可讀的故事。台灣團隊常常卡在中英之間取捨，其實不必取捨，分層處理就好。
如果你的徵才頁還會被拿去搭配llms.txt 這類給 AI 讀的網站宣告，更要確保結構化資料與內文的事實是一致的，否則 AI 讀到的訊號會打架。
與其他結構化資料的搭配：別讓預估薪酬孤軍奮戰
複合式結果是整頁訊號的總和，不是單一欄位的功勞
預估薪酬不該是你頁面上唯一的結構化資料。一個完整的徵才或薪資頁，通常還會搭配 Organization（公司資訊）、BreadcrumbList（麵包屑導航）、WebPage（頁面類型）等基礎結構化資料。這些一起出現，Google 對整頁的理解才會完整，預估薪酬的新欄位也才更有機會被採用。
實務上我會把結構化資料想成「一組互相背書的訊號」。industry 寫 “Technology”，但如果 Organization 的 sameAs 指向一個科技公司的官網、breadcrumb 也顯示「科技業職缺」分類，Google 的信心度會更高。反之，若整頁只有預估薪酬孤零零一塊，新欄位的可信度也會打折。這跟主題群集的道理一樣，訊號要成群，單點出擊效果有限。
退一步看，結構化資料的佈局應該跟你的網站架構對齊。薪資頁屬於哪個分類、公司頁與職缺頁之間怎麼用連結串起來、關鍵字最佳化怎麼呼應，這些都會影響 Google 對單一欄位的判讀信心。別把 jobBenefits、industry 當成獨立任務，它們是整頁訊號網的一部分。
如果你的網站還有行動優先索引或頁面體驗的歷史包袱，建議先確認這些基礎訊號穩定了，再回頭補預估薪酬的新欄位。地基不穩，上面的結構化資料再漂亮也撐不久。
FAQ：關於預估薪酬新屬性最常被問的問題
要不要馬上加？會被懲罰嗎？
有預估薪酬結構化資料就建議加，沒有就先評估頁面類型。選填欄位不填不罰，但亂填（不實、非規範值）會被撤結果。判斷順序：先確認頁面是預估薪酬類型，再決定要不要加這兩個欄位。更多判斷邏輯可以參考我們對「只有好內容能否排第一」的討論。
跟 JobPosting 的 jobBenefits 哪裡不一樣？
規範不同、顯示位置不同，別混抄。JobPosting 的福利欄位掛在徵才結構化資料下，預估薪酬的 jobBenefits 掛在 Occupation 物件下。兩者服務的頁面類型不同，放錯物件 Google 完全不會顯示。
可以填中文嗎？
industry 建議英文規範值，因為 Google 對英文值的解析最穩定。jobBenefits 技術上可填中文，但國際相容性較差，若你的求職者是台灣本地讀者，建議英文欄位加中文內文雙軌，而不是把欄位本身寫成中文。
多久看到效果？會影響排名嗎？
上線後觀察 7 到 28 天的曝光與點擊變化，排名無保證。這兩個欄位影響的是複合式結果的呈現與點閱率，不是排名因素本身。若期待排名提升，問題不在這兩個欄位，而在整體內容與連結策略，AI 搜尋 SEO 指南裡有更全面的建議。
ATS 能自動產生嗎？
視 ATS 而定，多數要客製或請工程師加欄位。主流 ATS 對 JobPosting 支援較完整，但對預估薪酬的 industry、jobBenefits 支援仍很有限，多半需要你在範本層手動補 JSON-LD。如果你正在挑 SEO 協作廠商，SEO 公司篩選指標也可以一併參考。
能不能填多個產業？
不建議。industry 用單一規範值最能讓 Google 準確判讀，若公司跨多個產業，挑最主要的那一個寫，把次要產業放進內文用文字說明。多填反而會模糊訊號，讓 Google 不知道該把你歸到哪一類。
回到搜尋意圖：現在該做的一件事與該觀察的訊號
如果只能先做一件事，就是挑一個你已經有預估薪酬結構化資料、且招募量最大的職位頁，把 industry 與 jobBenefits 補上、跑一次 Rich Results Test，當作試營運。上線後在 Search Console 的預估薪酬報表觀察 7 到 28 天的曝光與點閱變化，若有效再擴大到其他頁面；若無明顯變化，先回頭檢查欄位值是否符合規範、福利文字是否與內文一致，而不是急著加更多欄位。
講了這麼多，核心只有一句：先修正最影響判斷的訊號，再決定下一步。對預估薪酬的新屬性來說，最影響判斷的訊號就是「industry 用對規範值」跟「jobBenefits 跟內文兜得起來」。把這兩件事做對，比加十個花俏欄位都管用。招募 SEO 不是比誰欄位多，而是比誰的訊號最乾淨。想用更低成本的方式改善現況，不需發新文章也能改善 SEO 的幾個技巧值得一看。
回顧一下整篇的脈絡：先分清楚預估薪酬跟 JobPosting 是兩套規範，再確認你頁面屬於哪一種；接著把 industry、jobBenefits 放對層級、用對格式；上線後用 Rich Results Test 與 Search Console 驗證，並避開四個常見地雷；到頭來，在 AI 搜尋當道的 2026，這兩個欄位真正的價值是成為被 AI 引用的事實聲明，而不只是多一條福利訊息。
如果你連預估薪酬這套結構化資料都還沒建，那就先別管 jobBenefits、industry。回頭把 SEO 基礎與結構化資料的地基打好，再回來加這兩個欄位，效益才會疊加得上。招募是一場長期戰，訊號乾淨比訊號多更重要。準備好了，就挑一個頁面今晚動手，七到二十八天後回來看數字。若你想從更上位的角度重新檢視整體策略，可以從我們整理的整體 SEO 指南開始，把這些零散的點串成一條線。
