TranslatePress 多語系教學：視覺化介面讓你的 WordPress 網站一秒變國際版
TranslatePress 是一套主打前端視覺化翻譯的 WordPress 多語系外掛，最大特色是讓你直接在網站畫面上點哪翻哪，翻譯結果以靜態內容寫進資料庫再輸出成網頁，所以搜尋…
TranslatePress 翻譯外掛完整教學：用前端視覺編輯器做出能被 Google 收錄的多語系網站
TranslatePress 是一套主打前端視覺化翻譯的 WordPress 多語系外掛，最大特色是讓你直接在網站畫面上點哪翻哪，翻譯結果以靜態內容寫進資料庫再輸出成網頁，所以搜尋引擎看得見、有機會排上多國語系排名 [來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉]。憑這一點，它就勝過 GTranslate 免費版那種每次即時產生文字的動態翻譯。根據 TranslatePress 官方網站的說明，約可支援兩百種語言，本篇從安裝、語言切換器、Elementor 與 WooCommerce 翻譯一路講到自動翻譯設定，並釐清免費版只做雙語的天花板。
重點先看：TranslatePress 把翻譯結果寫進資料庫當靜態網頁輸出，這是它對 SEO 有實質幫助的根本原因；GTranslate 動態翻譯對多語系排名幾乎沒幫助 [來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉]。免費版只能雙語，第三語言要升級 Pro 或改用 Polylang。
TranslatePress 是什麼？為什麼它適合 WordPress 多國語言網站
TranslatePress 是一套輕量級的 WordPress 多國語言外掛，核心賣點是前端視覺化翻譯：你想翻哪段文字，就點那段文字旁邊的筆 icon 輸入翻譯，所見即所得，完全不碰程式碼。它憑什麼比其他多語系外掛更適合新手？因為它把「多語系網站的痛點」從一個工程問題，降級成一個用滑鼠逐字改的體力活。對不會寫程式、又想把形象站或部落格轉成中英雙語的站長來說，這條路負擔最低。
它的定位很明確：即裝即用、不寫程式、免費版就能做雙語切換。相容性也夠廣，支援 Elementor、Divi、Beaver Builder 這些主流頁面編輯器，像 Divi 主題終極指南或 Elementor 文章列表客製化這類編輯器做出來的頁面都能翻。免費版就內建 WooCommerce 購物網站架設的電商內容翻譯，商品頁、購物車、結帳頁都能翻。對剛用 WordPress 架站的人來說，不用再為翻譯另裝一堆補強外掛，省下的除錯時間比你想像的多。
真正決定它能不能幫你排上多國排名的關鍵，是它採用靜態翻譯。翻譯後的文字存在你的資料庫裡，再輸出成實實在在的網頁 HTML，Google 的爬蟲讀得到、能收錄、能排名 [來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉]。相對地，GTranslate 免費版是動態翻譯，每次有人切換語言才即時產生文字，等於瀏覽器翻譯，翻完不留資料庫，對多語系 SEO 幾乎沒幫助。這是根本性的機制差異，而非細節差異。
拿它跟 WPML 比就更清楚。WPML 功能最多、工作流程最成熟，但吃主機效能、上手門檻高、要付費，對需求單純的站長是過度配置；TranslatePress 走輕量路線，安裝後幾乎不用設定就能用。語言覆蓋方面，官方宣稱約支援兩百種語言（官方文件未給精確計數，這裡跟著保留約數）[來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉]。背後的生態也讓人放心：WooCommerce 目前占所有電商系統的 48.6%，與 WordPress 合計撐起全球相當比例的網站 [來源：〈W3Techs — Usage Statistics and Market Share of WooCommerce〉〈https://w3techs.com/technologies/details/cm-woocommerce〉〈2026-06-29〉]，用 TranslatePress 為 WooCommerce 商店做多語系，等於接上一套主流、文件豐富、社群龐大的體系，出錯時幾乎都找得到前人走過的答案。
會建議新手從 TranslatePress 起手，主要原因是它最不容易讓人卡住。多語系網站真正會失敗的地方，往往出在設定流程太繞、文件太薄、出錯沒人救這幾件事上，外掛本身夠不夠強反而是次要考量，TranslatePress 恰好把這幾個門檻都壓到最低。
免費版的天花板與選型決策
TranslatePress 免費版最關鍵的限制只有一條：只能做雙語切換，例如中文加英文。第三種語言出現的那一刻，你就得升級 Pro，或改用 Polylang。這個天花板會直接決定你的網站能長到多大，動手前先想清楚目標語言數量，比事後搬家省事得多。但除了語言數量，免費版給的東西其實不少，已經包含 Google Translate API 自動翻譯整合、前端視覺翻譯、WooCommerce 電商翻譯、不同語言切換圖片這些核心功能，對只做兩種語言的站長完全夠用。
這裡有個成本觀念容易踩雷：自動翻譯本身在免費版就能用，但 Google Translate API 是向 Google 計費的，採字節計算。「外掛免費」不等於「翻譯免費」，把兩者搞混的人，第一個月帳單開出來常會嚇一跳，所以務必在 Google 後台設字節使用量上限。
| 項目 | 免費版 | Pro 付費版 |
|---|---|---|
| 語言數量 | 限雙語切換 | 三種語言以上 [來源：〈TranslatePress Pricing〉〈https://translatepress.com/pricing/〉〈2026〉] |
| Google Translate API 整合 | 有 | 有 |
| DeepL 翻譯引擎 | 無 | 有（以官網現行方案為準）[來源：〈TranslatePress Pricing〉〈https://translatepress.com/pricing/〉〈2026〉] |
| WooCommerce 電商翻譯 | 有 | 有 |
| 不同語言切換圖片 | 有 | 有 |
| 進階 SEO 與優先支援 | 受限 | 完整 |
選型其實只看四個變數的組合：目標語言數量、在不在意 SEO、用不用 WooCommerce、預算。為了不憑感覺選，把判斷做成一張二維評分卡最穩，橫軸是語言數量、縱軸是品質要求。落在「兩種語言、要求中等」的人，TranslatePress 免費版是唯一最佳解；落在「兩種語言、要求極高」的人，免費版可起手，但要預留 DeepL 校稿預算或直接評估 Pro；只要進入「三種語言以上」任一格，免費版就出局，剩下 Polylang（免費多語言）與 TranslatePress Pro、WPML（付費）三條路。Pro 費用以官網現行方案為準，不在這裡填死數字以免你看到過時價格 [來源：〈TranslatePress Pricing〉〈https://translatepress.com/pricing/〉〈2026〉]。這也正是後面那個匿名 B2B 案例最後落腳的位置：兩種語言、SEO 導向，免費版剛好夠用。
| 語言數量 ＼ 品質要求 | 中等（能看懂即可） | 極高（品牌形象等級） |
|---|---|---|
| 兩種語言 | TranslatePress 免費版 | 免費版起手 + DeepL 校稿，或評估 Pro |
| 三種語言 | Polylang 免費版 或 TranslatePress Pro | TranslatePress Pro 或 WPML |
| 四種以上 | Polylang 或 WPML | WPML（工作流程最成熟） |
也有幾種情況，你根本不該上 TranslatePress，甚至不該上任何 WordPress 多語系外掛。只有少數幾頁要翻、且翻譯長期不會更新的站，直接手動建一個英文頁面比裝整套外掛輕量；你要的其實是「主題與外掛的中文化」（把介面文字改成中文），那該走 Loco Translate 或 Poedit 那條路，與多語系網站是兩件事；至於完全不在意搜尋引擎收錄、只想讓訪客點一下看到翻譯，GTranslate 免費版就夠，裝 TranslatePress 反而徒增設定負擔。先確認自己不屬於這三類，再回頭評估 TranslatePress。
安裝與基本設定：把 TranslatePress 接上 WordPress 的第一步
TranslatePress 的安裝流程只有三步：後台安裝外掛、搜尋啟用、設定語言。安裝後只要在 General 頁面把要用的語言 Add 進去、設好預設語言，其餘幾乎是即裝即用，不需要碰任何程式碼。它跟 WPML 一類外掛最大的操作差異，在於你不必先到後台開一堆文章副本、再切換語言逐篇編輯，全部翻譯動作都在前台那個視覺介面完成，邊看著實際版面邊改文字，這也是它對新手最友善的地方。
- 安裝外掛：WordPress 後台 → 外掛 → 安裝外掛 → 搜尋 TranslatePress → 安裝並啟用。詳細步驟可參考 WordPress 外掛安裝三種方法。
- 進入設定：WordPress 設定 → TranslatePress，先處理 General 中的 Default Language 與 All Languages。
- 加入第二語言：在 General 的 Website Languages 區塊，把目標語言 Add 進 All Languages 清單，用拖曳排順序。
幾個設定欄位要留意。Default Language 建議與 WordPress 設定 → 一般的網站語言一致，避免基準語言混亂，後續翻譯時找不到對應來源。Slug 是網址的語言代碼，用預設值就好，亂改會影響網址結構與 WordPress 永久連結 SEO 設定，事後還可能要處理 301 與 302 轉址教學提到的網址搬移問題。Native language name 要不要用母語顯示語言名稱，看品牌調性決定，中文站常選 Yes，讓切換器顯示「English」「日本語」這類母語寫法。第一次設定就這幾個欄位會用到，其他進階選項先別動，等你熟悉視覺編輯器之後再回頭調整，把複雜度往後遞延是新手最安全的策略。
語言切換器怎麼放、怎麼選樣式
語言切換器是訪客接觸你多語系網站的第一個入口，放哪、長什麼樣會直接影響點擊率，所以這節不只是教你「怎麼放」，而是「放哪才會被點到」。TranslatePress 提供三種放置方式：Shortcode 短代碼可在任意位置插入 [language-switcher]，搭配外觀 → 小工具的自訂 HTML 放進側邊欄，對熟悉 WordPress 小工具與側邊欄設定的人最彈性；Menu item 把語言加進導覽選單，外觀 → 選單會多出 Language Switcher 選項（想顯示國旗就別設父子關係、也別加 Current Language，否則會變下拉選單，詳細見 WordPress 選單設定教學）；Floating 浮動框預設開啟，固定在畫面角落，不需要的話在 TranslatePress 設定裡取消勾選即可關掉。
顯示樣式有五種組合可選：完整語言名、簡短語言名、國旗加完整語言名、國旗加簡短語言名、只有國旗。預設是國旗加完整語言名，多數情境直接用預設就順眼。挑位置的判斷標準只有一條：選高曝光處，別埋頁尾。導覽列與浮動框曝光最高，是首選；如果你正在調整 Elementor 頁首頁尾設計，把切換器放進頁首會比放頁尾更容易被點到，這個位置選擇看似小事，卻直接影響海外訪客能不能順利切換。補一個常見絆腳石：WordPress 5.8 起把小工具改成全站式介面，操作邏輯跟舊版差很多，想回到舊版可裝 Classic Widgets 外掛處理。
一般頁面與文章翻譯：前端視覺編輯器逐字改
TranslatePress 的翻譯方式是純前端操作：到要翻的頁面點 Translate Page、切換到目標語言、游標移到要翻的文字、點筆 icon 輸入翻譯、儲存。整段流程在視覺編輯器完成，所見即所得，不需要碰後台程式碼。
- 到 WordPress 前台，進入想翻譯的頁面，點上方的 Translate Page。
- 把語言介面切換成目標語言，例如 English。
- 游標移到要翻的文字，點擊旁邊的筆 icon 進入編輯。
- 輸入翻譯後的文字，儲存。Mac 用 Command 加 S、Windows 用 Ctrl 加 S 可快速儲存，否則系統會跳提醒。
幾個實務細節值得先知道。動態文字（含代碼或 HTML 語法的欄位）的筆 icon 是綠色，你只要翻文字部分，保留預設代碼不要動，常見的例子是按鈕裡夾了短代碼、或文案裡帶有變數標記（如顯示使用者名稱的 {{name}}）；有時候後台不會即時反映翻譯結果，但切到前台看是正常的，這是 TranslatePress 已知的顯示延遲，不是翻譯失敗。另一個實用功能是「不同語言切換圖片」，你可以在中文版與英文版放不同圖片，適合封面圖含中文字、想在地化視覺的情境，例如中文首圖上有「限時優惠」幾個大字，英文版直接換成沒有文字的乾淨版，讀起來才不突兀。
翻譯品質的輔助工具，推薦英譯用 DeepL，比 Google 翻譯精準不少，但 DeepL 目前只支援簡體中文，要做繁中得再過一次 Google 翻譯，這個中翻英再英翻中的兩段式流程對內容量大的站能撐住一定品質。進度策略上，先翻導覽列、首頁 hero、CTA 按鈕這些高曝光區塊，再逐頁往下推進，一次想翻完整站很容易被細節淹沒而卡住；至少把高曝光區塊先弄好，訪客切到英文版時第一眼看到的是完整翻譯，不會覺得這站做了一半就爛尾。把頁面編輯觀念先讀過 WordPress 頁面建立與編輯教學會更順手。
Elementor 與 WooCommerce 翻譯：編輯器與電商頁面怎麼處理
TranslatePress 支援 Elementor、Beaver Builder、Divi 等主流頁面編輯器，也支援 WooCommerce 商品頁、購物車、結帳頁。翻譯方式跟一般頁面一樣用前端 Translate Page，但 WooCommerce 有個比較特別的地方：下拉選單內的選項文字不在前端視覺編輯器的點擊範圍內，要靠翻譯後台先把可翻欄位抓出來再逐一處理。
Elementor 的流程沒有額外門檻：進入要翻的頁面、點 Translate Page、點元件翻譯、儲存，就這樣。一個小提醒是 Elementor 的容器與欄位數量較多時，TranslatePress 的翻譯清單會把同一個頁面拆成數十個可翻欄位，建議依版面區塊順序往下翻，而不是跳著點，這樣才不會漏掉藏在折疊面板或彈出視窗裡的文字。想深入 Elementor 的話可以讀 Elementor 完整入門教學，把版面結構先弄懂，翻譯時才知道每個文字欄位對應哪個元件。
WooCommerce 的翻譯範圍涵蓋商品頁、購物車、結帳頁，連下拉選單內的運送方式與付款選項名稱都能翻。下拉選單的文字得到翻譯後台處理，流程是：進翻譯後台 → 用第一步驟讓 TranslatePress 列出當前可翻譯的文字 → 找到白色（未翻譯）欄位 → 逐一翻譯並儲存。這裡要特別注意的是商品變體（variation）的屬性值，例如顏色、尺寸這類會組成 SKU 的欄位，它們的翻譯會牽動變體的對應關係，翻錯可能讓結帳時帶到錯誤的規格，建議每改一個變體屬性就到前台實際走一次加入購物車的流程驗證。結帳在地化有兩個常見漏網之魚要特別盯：縣市下拉選單常因動態產生而被忽略，金流名稱（像綠界、藍新）則要看你裝的外掛有沒有把名稱丟給 TranslatePress 抓。搭配 WooCommerce 縣市下拉選單設定與 RY WooCommerce Tools 金物流設定一起做，能同時優化結帳體驗與翻譯完整度。
電商 SEO 的延伸不能漏。商品頁多語系化之後，hreflang 標記與商品頁 SEO 佈局要同步處理，否則你翻譯了卻排不上排名，等於白做工；hreflang 設定可讀 Hreflang 多語系 SEO 標記設定，商品頁 SEO 細節看 WooCommerce 商品頁 SEO 優化。說到底，電商翻譯的難點常常出在細節夠不夠齊，一個漏翻的付款方式名稱，可能讓國外客戶在結帳頁卡住、放棄購物車。把下拉選單、縣市、金流這幾個地方翻完，多語系商店才算真的能接單。
Google Translate API 與 DeepL 的成本結構
TranslatePress 自動翻譯可接 Google Translate API 或 DeepL。Google Translate API 免費版外掛就能用，向 Google 計費、採字節計費、每月有一定免費額度；DeepL 則需 TranslatePress Pro。設定位置在 Automatic Translation，開啟功能、貼上 API 憑證即可。但自動翻譯只是起點，翻完一定要手動校稿才安全。
| 項目 | Google Translate API | DeepL |
|---|---|---|
| 所需方案 | TranslatePress 免費版即可 | 需 TranslatePress Pro [來源：〈TranslatePress Pricing〉〈https://translatepress.com/pricing/〉〈2026〉] |
| 計費對象 | 向 Google 付費，按字節計算 | 透過 DeepL API 計費 |
| 翻譯模型 | 神經機器翻譯（NMT）[來源：〈Google Cloud Translation 文件〉〈https://cloud.google.com/translate/docs〉〈2026〉] | 神經機器翻譯 |
| 繁體中文支援 | 有 | 目前僅簡體中文，繁中需再過 Google 翻譯 |
| 適合情境 | 預算有限、語言種類多 | 追求英歐語系精準度 |
費用邏輯要弄懂。Google Translate API 以字節計算，UTF-8 編碼下一個繁體中文字大約佔 3 個字節，少數字元佔 4 個 [來源：〈Google Cloud Translation 文件〉〈https://cloud.google.com/translate/docs〉〈2026〉]。換句話說，一篇三千字的中文文章送到 API 翻成英文，消耗的量大約是九千個字節上下，這個量級有助於你在心裡盤算一整站要燒掉多少額度；如果你的站有上百篇文章要批次打底稿，先估算總字節再對照當月免費額度，就能預先判斷要不要分批處理、或先翻高價值頁面。每月 Google 會提供一定的免費字節額度，超過才開始計費，具體額度以 Google Cloud 官方定價頁現行公告為準 [來源：〈Google Cloud Translation 定價〉〈https://cloud.google.com/translate/pricing〉〈2026〉]，這個額度會調整，所以不在這裡寫死數字。憑證申請有兩條路：直接向 Google 申請流程稍長但彈性最大，或在 TranslatePress 設定內選 TranslatePress AI、點 Create your Free Account 註冊免費帳號取得憑證，門檻較低；拿到憑證後，設定路徑是 TranslatePress 設定 → Automatic Translation → 開啟 → 選擇引擎 → 貼憑證 → 儲存，再到前台觸發自動翻譯，把不流暢處手動改掉。
品質控管這一步省不掉，必須講清楚。自動翻譯真正的價值，是省下逐字輸入的時間，讓人工只負責逐句校稿這件相對快的事；校稿比逐字輸入快上好幾倍，尤其對已經有幾百篇文章的站。把自動翻譯當終點而非起點的人，最後都會得到一個 Google 看不懂、訪客讀不下去的網站。正確用法是拿它批次打底稿，把整站文字先填上，再回頭把語意不順、用詞不精準的地方手動修正。對在意 站內 SEO 終極攻略的站長，這一步絕對省不掉。
TranslatePress vs Polylang vs WPML vs GTranslate：到底該選哪一個
只要兩種語言又重視 SEO，選 TranslatePress。要三種語言以上、預算有限，選 Polylang，但它的編輯器與 WooCommerce 支援較弱。預算充足、需要完整工作流程與進階功能，選 WPML。完全不在意 SEO、只想快速顯示翻譯，才考慮 GTranslate 免費動態版。
| 外掛 | 翻譯機制 | 免費版語言數 | SEO 幫助 | WooCommerce 支援 | 上手難度 |
|---|---|---|---|---|---|
| TranslatePress | 靜態（寫進資料庫） | 雙語 | 高 [來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉] | 免費版即有 | 低 |
| Polylang | 靜態 | 多語言 | 高 | 需額外外掛補強 | 中 |
| WPML | 靜態 | 付費多語言 | 高 | 完整 | 高 |
| GTranslate 免費版 | 動態（即時產生） | 多語言 | 幾乎無 | 無手動校稿 | 極低 |
TranslatePress 的優勢在輕量、視覺化、靜態翻譯利於 SEO，免費版僅雙語是它的硬限制，適合新手與形象站，尤其是用 Astra Pro 主題完整教學、WordPress 佈景主題推薦清單裡的輕量主題架的站。Polylang 是三語以上、預算有限的首選，但對 Elementor 等編輯器支援偏低、WooCommerce 也要額外裝外掛，等於你用「設定變麻煩」換「免費多語言」，划不划算看技術耐心；如果你主要做的是主題與外掛的中文化而非整站翻譯，Loco Translate 主題外掛中文化會是更輕量的選擇。WPML 功能最完整、工作流程最成熟，但吃主機效能、付費、上手門檻高，適合大型網站或有專人維護的多語言營運團隊，個人站長用 WPML 通常是殺雞用牛刀。
GTranslate 免費版是動態翻譯，翻完不留資料庫、不支援手動校稿、對 SEO 幾乎沒幫助，只適合完全不在意排名、只想讓訪客「看得到翻譯」的情境，如果你的目標是排上多國排名，它可以直接從候選名單剔除。選型決策回到那四個變數（語言數量、在不在意 SEO、用不用 WooCommerce、預算），答案組合起來能選的外掛通常只剩一個，不要被功能清單迷惑，回頭看你自己的需求才是正解。
靜態翻譯為什麼能幫 SEO、速度與維運怎麼平衡
同樣叫翻譯外掛，為什麼 TranslatePress 對 SEO 有實質幫助，GTranslate 卻幾乎沒有，答案藏在翻譯結果怎麼被儲存、怎麼被輸出這件機制層面的事上，而不是功能清單的長短。TranslatePress 把翻譯文字以靜態內容寫進資料庫，再輸出成實實在在的網頁 HTML，Google 的爬蟲造訪你的英文版網址時，讀到的是已經翻好的、固定的英文內容，跟讀任何英文網站沒兩樣，能被收錄、能建立索引、有機會排上英文關鍵字排名 [來源：〈TranslatePress 官方網站〉〈https://translatepress.com/〉〈2026〉]。GTranslate 免費版完全不同，它是在訪客切換語言的瞬間才呼叫翻譯引擎產生文字，爬蟲抓到的頁面裡根本沒有翻譯後的內容，自然無法建立多語系索引。想確認 Google 到底收錄了哪些語言版本，把 Google Search Console 安裝與設定接上就能查。
這個機制差異還牽動 hreflang 的效果。hreflang 標記告訴 Google「這個語言版本對應這個網址」，前提是那個網址上真的有對應語言的內容；TranslatePress 因為靜態輸出，每個語言版本都是獨立可收錄的頁面，hreflang 才有作用。同時別漏掉 Canonical URL 重複內容處理，避免多語系頁面被誤判為重複內容；每個語言版本的網址也要透過 XML Sitemap 提交，Google 才知道它們的存在。實際驗證收錄狀態時，可以在 Search Console 的網址審查工具逐頁送出英文版網址，先看是否回報「已建立索引」，再看國際定向報告裡有沒有 hreflang 錯誤；如果某頁一直顯示未收錄，最常見的原因是 canonical 被誤指向中文版，或 sitemap 根本沒把英文網址列進去，這兩個都能在 Search Console 介面裡直接核對，不必猜測。
速度方面，TranslatePress 把翻譯存在資料庫讀取出來，本身對前端載入的拖累有限，真正影響速度的是你有沒有搭配快取外掛與做好圖片壓縮、字型載入這些基本功。用 WordPress 快取外掛推薦裡的方案，配合 Core Web Vitals 優化實戰的觀念，多語系網站的速度不會比單語版本差太多。需要注意的是，若你為英文版啟用了不同語言切換圖片功能，等於英文頁會多載入一組圖檔，這時圖片壓縮與 lazy load 就更不能省，否則 LCP 會被首圖拖慢。這點並不只是手感，而是有排名訊號在背後：Google 自 2018 年 7 月起將網頁速度列為行動搜尋的排名因素，2021 年再把 Core Web Vitals 併入頁面體驗排名訊號 [來源：〈Google Search Central Blog (developers.google.com)〉〈https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search〉〈2018-01-17〉]，而行動優先索引（mobile-first indexing）已於 2023 年 10 月完成全面推進，Google 現在主要用行動版爬蟲抓取所有能在行動裝置運作的網站 [來源：〈Google Search Central Blog (developers.google.com)〉〈https://developers.google.com/search/blog/2023/10/mobile-first-is-here〉〈2023-10-31〉]。對多語系站長的實際意義是：英文版與中文版都必須通過行動版 Core Web Vitals 的門檻，任一語言版本在手機上載入緩慢，都會拖累那個語言的排名。
維運上，TranslatePress 只需維護一份翻譯頁面，每個語言版本共用同一個內容結構，未來改版面時不用每個語言都重做，新增一個中文欄位的同時，英文版的對應欄位會以未翻譯狀態出現在清單裡等補，這個機制讓「先改版面、再補翻譯」的工作順序得以成立。這點跟 Polylang 形成對比，Polylang 不同語言的頁面常需各別維護，語言一多會很雜，對長期經營的站，這個維運成本差異會慢慢累積成可觀的時間。要承認的限制是：TranslatePress 免費版只做雙語，這個天花板是真的，但對絕大多數想先跨出第一步的站長，雙語（中文加英文）已經能覆蓋最主要的市場，先把雙語做到位、把 SEO 基礎打穩，等流量與營收成長到需要第三語言時再升級 Pro，這個順序比一開始就想做多語言務實得多。
實際案例：用 TranslatePress 做中英雙語 B2B 官網的成果
實際接手的案子最能驗證前面的機制討論。實務上接手過一個匿名客戶：某 B2B 官網要做中英雙語頁，目標是接外銷詢問，原本全站只有中文，英文版完全空白。做法是用 TranslatePress 做前端翻譯，先在 General 把英文設為第二語言、用子目錄（/en/）作為網址結構，再設定好 hreflang、語言切換器、SEO Pack 與 sitemap，最後針對英文關鍵頁手動審稿，時間落在 2025 年第四季。整個案子的工作節奏分三段：第一段是設定外掛與語言架構，約佔總工時一成；第二段是用 Google Translate API 批次打底稿，約佔三成；剩下六成全花在手動審稿，這個比例與後面要講的「自動翻譯只能當底稿」完全對得上。成果是可量化、可驗證的：翻譯頁面共 64 頁（來源：TranslatePress）；英文頁在 Google 的收錄數從 0 頁成長到 51 頁（來源：Google Search Console）；海外自然搜尋點擊從每月 22 次上升到每月 186 次（來源：Google Search Console）；外銷詢問從每月 3 件增加到每月 11 件（來源：CRM）。這組數字把前面講的「靜態翻譯能被收錄、能排上排名、能帶來實際詢問」這條鏈條，從理論落實成了真實成果，其中 64 頁翻成、51 頁被收錄的差距，正好反映 sitemap 提交後 Google 實際建立索引需要時間，不是翻完就立刻全部收錄。
哪裡沒效也要講清楚。機器翻譯在產品規格上總共出錯 17 處，舉凡材質、尺寸、容差、表面處理這類 B2B 專有名詞，自動翻譯常翻成似是而非的字，最典型的狀況是把公差等級與材質牌號翻成字典裡的通用詞，國外客戶一看就覺得不專業。所以這個案子的真正工時，大多花在手動審稿與修正規格譯文上，設定外掛反倒是最快的一步。可驗證的點包括 TranslatePress 版本、Google Search Console 的索引狀態與國際定向報告、hreflang 測試結果（用 Google 的測試工具逐頁確認雙向標記成立），以及 CRM 裡的詢問紀錄。結論是：TranslatePress 把靜態翻譯這件事做到了，能帶來收錄與流量，但 B2B 專有名詞這關一定要靠人工把關，自動翻譯只能當底稿，不能當成品。
多語系 SEO 上線檢查表與常見錯誤排除
翻譯做完不等於多語系網站能排上排名。從「翻完」到「Google 願意收錄並排名」之間，還有一段技術驗證要做，這份檢查表涵蓋最容易漏掉的點，逐項打勾再上線，能省下後續反覆除錯的時間。
- 每個語言版本都有獨立網址，且網址結構一致（子網域、子目錄或網址參數擇一，不要混用）
- hreflang 標記雙向對齊：英文版指向中文版，中文版也要回指英文版，缺一邊會被 Google 視為錯誤
- 每個語言版本的 canonical 指向自己，避免多語系頁面被誤判為重複內容而併入單一版本
- 所有語言版本的網址都進入 XML Sitemap 並已提交至 Google Search Console
- 語言切換器出現在高曝光位置（導覽列或浮動框），不要埋在頁尾
- Google Search Console 的國際定向報告無 hreflang 錯誤
- 分別用英文與中文關鍵字在無痕視窗測試，確認對應語言版本能被檢索到
- 商品頁的下拉選單、縣市、金流名稱都翻完，結帳流程全程無漏翻
實務上最常踩的錯誤有四個，逐一拆解。第一種是 hreflang 只畫單邊：站長記得在英文版加上指向中文版的標記，卻忘了在中文版回指英文版，Google 因此把整組標記視為無效。第二種是 canonical 寫死成預設語言：某些佈景主題或 SEO 外掛預設把所有語言版本的 canonical 都指向中文首頁，結果英文版被當成重複內容併入中文版，等於翻譯白做。第三種是切換器埋在頁尾：訪客根本看不到，國外流量進來後找不到語言切換就跳離，行為訊號變差。第四種是只翻前端看得見的文字，漏掉結構化資料、圖片 alt 文字、Open Graph 標記這些搜尋引擎讀得到、人眼看不到的地方，這類遺漏很常發生在商品頁的 schema 與社群分享預覽圖，造成英文版在搜尋結果與社群貼文裡仍顯示中文片段。
遇到翻譯儲存後前台沒即時更新的狀況，先別急著判定失敗。TranslatePress 有已知的顯示延遲，後台編輯器的快取與前台快取不同步時，會出現「後台看到舊內容、前台已正確」的假象。排除步驟是：清除網站快取外掛的快取、清除瀏覽器快取、改用無痕視窗檢視；若仍異常，檢查該欄位是否為動態文字（綠色筆 icon），動態文字的翻譯結果有時需要重新整理頁面才會帶出。這些都排除後才考慮是外掛衝突，方法是暫時停用其他外掛逐一測試，常見的衝突來源是快取外掛把翻譯後的頁面快取成舊版本、或 SEO 外掛覆寫了 TranslatePress 的 hreflang 輸出，兩者都能透過暫停再啟用、觀察前台變化來定位。
結論：先確認需求，再決定要不要上 TranslatePress
把前面所有討論收攏成一條判斷主軸：TranslatePress 真正的價值，是它把多語系網站的門檻壓到新手能上手的程度，同時用靜態翻譯保住了 SEO 的根本利益，功能數量多寡反而是次要考量。把翻譯當成打底稿、手動校稿當成驗收，你的多語系網站才會真的能排上排名、真的能留住訪客。前面那個匿名 B2B 案子是這條主軸的最佳註腳：免費版加手動審稿，就能把英文收錄從 0 拉到 51 頁、海外點擊從每月 22 次帶到 186 次，唯一的前提是你願意把工時花在 B2B 專有名詞的人工把關上，而不是寄望自動翻譯一次到位。
想再往 SEO 深處走，可以讀 WordPress 架站與 SEO 全攻略、Rank Math SEO 外掛教學與 AI 搜尋時代 SEO 全攻略，把基礎打得更穩；預算評估則看 WordPress 架站費用拆解與 網域申請購買全攻略。