求職者追蹤系統是雇主用來接收、儲存和處理求職申請的軟體。以下是 2026 年每個主要 ATS 實際做什麼、如何從 URL 辨識每一個,以及圍繞「ATS 最佳化」的副業建議中哪些是對的、哪些是錯的。
求職者追蹤系統——如果你聽過招募人員使用「ATS」這個縮寫的話——是雇主用來管理其招募管道的軟體。當你在公司的職涯頁面點擊「投遞」並填寫表單時,你就是在向他們的 ATS 提交。當招募人員閱讀你的履歷、發送篩選邀請、安排面試或發送拒絕郵件時,他們都是透過 ATS 進行的。它是你和人類之間的層,而且候選人端的「ATS 最佳化」副業建議很可能誇大了這一層實際過濾的程度。
值得了解你的申請實際經過什麼流程,因為 ATS 的設計影響兩件事:申請表填寫需要多長時間,以及招募人員在另一端如何看到你的履歷。
ATS 同時負責四項工作。它託管公開的職缺發布——大多數公司網站上的「職涯」頁面是由 ATS 提供的,嵌入在公司的網域或 ATS 的子網域上。它接收申請並將其儲存在結構化資料庫中。它管理招募人員的工作流程:審查履歷、留下筆記、為候選人評分、安排面試、發送範本郵件。它還運行分析——填補時間、招募來源、各階段之間的轉化率、多元化報告,整個招募儀表板。
以下是你作為求職者最常遇到的系統。每個都有可辨識的 URL 模式,使其容易從職涯頁面連結中識別。
URL 模式:*.myworkdayjobs.com 或帶有 Workday 風格篩選器的 jobs.[company].com。
使用者:大多數大型企業(Fortune 500、大型上市公司、跨國製藥、銀行、專業服務公司)。
求職者體驗:繁重。長表單、頻繁的「建立帳戶」要求、多步驟申請流程。Workday 是為招募人員而非求職者設計的。
公開數據暴露:不穩定。部分 Workday 租戶會輸出 JSON-LD 結構化資料;許多不會。我們關於 JSON-LD JobPosting 的文章涵蓋了對監控的影響。
URL 模式:boards.greenhouse.io/[company] 或 [company].greenhouse.io。
使用者:中端科技公司(歷史上的 Stripe、Airbnb 等級公司),B 輪到上市階段的新創,注重人力資源的現代企業。
求職者體驗:輕量。簡短表單、清晰的階段、合理的預設值。
公開數據暴露:出色。每個公開職缺都有乾淨的 JSON-LD 結構化資料,這就是為什麼 Greenhouse 的職缺能快速出現在 Google Jobs 上。
URL 模式:jobs.lever.co/[company]。
使用者:中端科技,與 Greenhouse 客戶類似的特徵。歷史上偏好設計感的公司。
求職者體驗:輕量,公開職缺頁面比 Greenhouse 更乾淨。
公開數據暴露:非常好。每個頁面都有 JSON-LD。
URL 模式:jobs.ashbyhq.com/[company] 或 [company]/jobs。
使用者:高成長新創,A 輪到 C 輪,主要是科技和注重設計的公司。自 2023 年以來持續從 Greenhouse 和 Lever 搶奪市佔率。
求職者體驗:主要 ATS 中最輕量。簡短的申請流程,更少的必填欄位。
公開數據暴露:出色。乾淨的結構化資料和維護良好的網站地圖。
URL 模式:通常嵌入雇主網域(URL 中沒有明顯的「phenom」),但可在頁面原始碼中看到。
使用者:大型企業,尤其是那些想在招募後端之上疊加品牌化職涯體驗的企業。
求職者體驗:因雇主客製化而差異很大。有些很優秀;有些比原始 Workday 更差。
公開數據暴露:良好。Phenom 通常輸出比一般系統更豐富的 JSON-LD。
URL 模式:careers-[company].icims.com 或嵌入雇主網域。
使用者:傳統大型企業,尤其在醫療、零售和製造業。
求職者體驗:繁重。通常需要建立帳戶。
URL 模式:jobs.smartrecruiters.com/[company] 或 careers.[company].com。
使用者:中大型企業,特別是歐洲總部的企業(該公司最初是歐洲的)。
求職者體驗:中等。夠乾淨,但不如 Greenhouse 或 Ashby 輕量。
URL 模式:career[X].successfactors.com 或嵌入雇主網域。
使用者:大型傳統企業,尤其是使用 SAP 處理更廣泛人力資源體系的企業。
求職者體驗:繁重。通常是所有主要 ATS 中摩擦最大的。
URL 模式:URL 中以某種形式包含 taleo。
使用者:大型企業中日益縮小的份額,主要是那些運行 Oracle HCM 的企業。到 2026 年被視為舊系統,但仍然廣泛部署。
求職者體驗:過時。幾乎總是需要建立帳戶。許多候選人講述的「最糟糕的求職申請體驗」都是指某個 Taleo 實例。
你點擊「投遞」後的高層流程:
圍繞「對 ATS 友善的履歷」建議有一整個副業產業,誇大了 ATS 本身過濾的程度。以下是什麼是對的、什麼是錯的。
迷思:「如果你的履歷不匹配關鍵字,ATS 會拒絕你。」
現實:大多數現代 ATS 不會根據關鍵字自動拒絕。Workday、Greenhouse、Lever、Ashby、SmartRecruiters 和 Phenom 都預設將每份申請呈現給招募人員。淘汰問題可以自動拒絕,但那些是你填寫的明確是/否欄位。
迷思:「你需要特殊的對 ATS 友善的履歷格式。」
現實:一份乾淨的、單欄式的履歷,使用正常文字(沒有圖片、沒有圖片中的文字、沒有奇特字體),在每個主要 ATS 中都能正確解析。有兩欄、側邊欄或以圖片形式呈現文字的高度設計履歷可能解析不良,如果招募人員依賴解析後的視圖而非原始 PDF,這可能會傷害你。使用單欄設計,儲存為 PDF,就沒問題了。
迷思:「ATS 無法讀取 PDF。」
現實:每個主要的現代 ATS 都能讀取 PDF。有些仍然略微偏好 Word 文件,但差異很小。
現實:與職位描述的關鍵字重疊確實有幫助,但是為了招募人員,而非 ATS。
招募人員在 20 分鐘內瀏覽 50 份履歷。如果職位描述中的關鍵字在你履歷的上三分之一處可見,你在 5 秒內就被認為「明顯適合」。如果相同的內容被埋在底部的長篇散文段落中,你被認為「也許適合,我回頭再看」,而通常不會有第二次機會。
實際的含義:
ATS 作為把關者的作用比圍繞它的副業產業所暗示的要小。它很少自動拒絕,它能正常讀取 PDF,而你的申請幾乎總是會到達一位在不到 30 秒內瀏覽它的真人。重要的是那 30 秒的瀏覽是否落在你履歷中匹配職缺要求的部分——這是一個人類問題,不是演算法問題。
從這篇文章中更有用的收穫是 URL 辨識技巧。一旦你知道 Workday 意味著繁重的表單、Greenhouse 意味著輕量的表單,Ashby 結構良好、Taleo 是另一個時代的產物,你就可以相應地規劃你的投遞工作階段——而且你可以透過 ATS 直接監控特定雇主,而非等待 LinkedIn 跟上。我們的早期投遞完整指南涵蓋了其餘的流程。