TranslatePress 多語系教學：視覺化打造多語網站

先回答核心問題：TranslatePress 是什麼，誰最適合用它

網站若有明確的海外受眾，缺少對應語言版本會增加理解與轉換阻力。把中文站做成英文版，也不一定要在後台逐筆處理字串；TranslatePress 要解的就是這段工作流程。

TranslatePress 是一套 WordPress 多語系外掛，它最核心的賣點僅有一個：讓你直接在前台翻譯。你打開自己的網站，切換到目標語言，游標點到哪一段文字，就翻譯哪一段，所見即所得。沒有後台那張密密麻麻的字串清單，沒有「翻完一篇還要切回去對照另一篇排版」的來回折磨。

這篇文章會帶你把 TranslatePress 從安裝、前台翻譯工作流程、自動翻譯引擎選擇、多語系 SEO 設定，一路做到 WooCommerce 雙語電商與效能優化。如果你還在比較幾套主流方案，可以先把這篇看完，再搭配 WordPress 多語系外掛深度評比 一起判斷，會更有概念，過程中可隨時對照 TranslatePress 官方網站。

誰最適合用 TranslatePress

換句話說，它特別適合這幾種人：

• 內容型網站站長：部落格、媒體站、知識站，文章數量多，需要一個能邊看版面邊修稿的工作流程。
• 在地服務與觀光旅宿業：民宿、飯店、旅行社、體驗活動，主要目的是接海外自由行旅客，通常僅需要中英雙語。
• WooCommerce 電商店主：商品頁、結帳流程、購物車訊息都要翻譯，而且在意每個語言版本的 SEO 表現。
• 非技術背景的站長：不想碰 .po .mo 檔案、不想研究字串名稱，僅想用滑鼠把網站變雙語。

反過來說，如果你要的是把佈景主題或外掛的「介面文字」中文化，例如把按鈕的 Add to Cart 改成「加入購物車」，那其實不是 TranslatePress 的主戰場，Loco Translate 這類字串翻譯工具更對症下藥。兩者解決的問題層次不同，千萬別搞混。

視覺化翻譯為什麼能改變整個工作流程

要理解 TranslatePress 的價值，得先看傳統多語系外掛是怎麼運作的。

部分多語系方案的主要工作區在後台，依內容、欄位或字串管理翻譯。這種流程適合集中處理譯稿，但完成後仍要回到前台確認排版。若你想比較不同工作方式，可以參考 Polylang 翻譯教學。

這種做法的好處是批次效率高，適合已經有完整翻譯稿、交給專業譯者逐字處理的團隊。但對大多數中小網站的站長來說，這個工作流程有個致命問題：翻譯和排版是脫鉤的。你不知道翻完的句子在前台長什麼樣、會不會換行跑版、按鈕文字會不會超出框架。

TranslatePress 把這個流程整個翻過來。你登入 WordPress，打開前台預覽，畫面上每一個可以翻譯的元素都會出現一個帶框的提示。你點下去，側邊欄跳出輸入框，你翻譯、它即時顯示結果。翻完一段，往下捲繼續翻下一段，整個過程跟你在校對自己網站沒兩樣。

這個差別聽起來很小，實際做一次你就回不去了。尤其是那種「介面零碎文字特別多」的頁面，例如首頁的標語區塊、服務介紹、行動呼籲按鈕、頁尾聯絡資訊。傳統做法你要在字串表裡大海撈針，視覺化做法你若點到哪、翻到哪。

面向	字串清單派（WPML／Polylang）	視覺化派（TranslatePress）
翻譯位置	後台字串表	前台即時預覽
排版檢查	翻完要切回前台看	邊翻邊看到結果
適合場景	有完整譯稿、專業譯者協作	站長自己翻、邊做邊修
學習曲線	較陡，要理解字串概念	直覺，會用滑鼠就行
批次處理	強項	較弱，逐頁進行

字串清單派並非不好。團隊夠大、譯稿夠完整，WPML 依然是最專業的選擇。但如果你是一人公司、三五人的小團隊，翻譯這件事多半會落到你自己頭上，那 TranslatePress 的視覺化工作流程會幫你省下大量來回確認的時間。

頁面編輯器相容性：用 Elementor 或 Divi 也能翻

很多站長聽到「視覺化翻譯」會擔心一件事：我的網站是用 Elementor 或 Divi 拉出來的，TranslatePress 抓得到那些動態產生的文字嗎？這是個好問題，也是很多人遲遲不敢做多語系的原因。

答案是：可以。TranslatePress 的設計就是在前台 DOM 層級抓取文字，不管你的頁面是 WordPress 預設編輯器、Elementor、Divi、或其他主流頁面編輯器拉出來的，它都能讀到最終渲染出來的文字節點。你在翻譯模式裡點到的每一個元素，背後對應的就是那段 DOM，翻譯結果會綁定在那個位置上。

實際操作上要注意的是：有些頁面編輯器的複雜元件（例如輪播、動態資料、自訂小工具）可能會有文字重複出現或抓不到的特殊狀況。遇到這種情況，你可以用 TranslatePress 翻譯面板裡的「列出所有字串」功能，用搜尋的方式找到那個漏掉的字串再手動補上。大多數情況下，標準的標題、段落、按鈕、圖片說明都能直接點選翻譯，不需要額外處理。

如果你的站還在選擇主題和編輯器的階段，先想清楚多語系的需求再決定，會比事後遷就外掛的限制更從容。

安裝前必須想清楚的三個決定

很多人裝多語系外掛的流程是這樣的：裝下去、設定語言、開始翻。然後翻到一半才發現網址結構選錯了、語言切換器的位置不對、自動翻譯的 API 還沒申請。整個網站改東改西，結果搞得一團亂。

不想走這條冤枉路的話，動手安裝之前，先把三個決定做好，後面會順很多。

決定一：要加哪些語言

聽起來像廢話，但這裡的陷阱是「貪多」。很多站長一開口就要中英日韓四語言全部上，結果每個語言都做到一半，沒有一個是完整的。

建議的做法是：從一個目標語言開始，做到完整再擴充。台灣的網站，第一步幾乎都是加英文。把英文版做到每一頁都翻完、SEO 設定到位、語言切換器運作正常，再考慮日文或其他語言。

TranslatePress 免費版僅支援一個額外語言（也就是中文加一個外語），付費版才支援多語言。這正好是一個天然的防呆機制，逼你先把第一個外語版本做扎實。

決定二：網址結構

多語系網站的網址有三種常見結構，每一種都會影響 SEO 和後續維護成本：

結構	範例	特色
子目錄	example.com/en/	集中在同一網域，設定與維護通常較單純
子網域	en.example.com	可分開部署與管理，適合各地區有不同團隊經營
獨立網域	example.es	完全分開，通常用於深度在地化經營

對台灣多數中小網站來說，子目錄通常是容易管理的起點。它讓語言版本集中在同一網域，也符合 TranslatePress 的預設結構。Google 並未把子目錄列為必然優於子網域或獨立網域的排名方案，真正重要的是網址穩定、內容完整，以及 hreflang 對應正確。

子目錄可採簡短且一致的語言代碼，例如 /en/ 或 /ja/，方便維護與辨識。不過 Google 不會單靠網址路徑判斷語言；頁面實際內容、hreflang 與網站內部連結才是語言版本對應的重點。

決定三：機器翻譯還是人工翻譯

這大概是整個決策裡最關鍵、也最常被誤解的一環。很多人聽到 TranslatePress 支援 Google Translate 和 DeepL 自動翻譯，就以為「裝下去就自動翻好好」。完全不是這樣。

自動翻譯的角色是打草稿，不是成品。它幫你把整站先翻一遍，給你一個可以動手修的底稿。但機器翻譯一定會有語意偏差、專業術語錯誤、語氣不對的問題，尤其是行銷文案和產品描述這種「不能翻得太硬」的內容。

所以正確的工作流程是：自動翻譯打底，再人工逐頁校修。TranslatePress 的視覺化介面就是為這個流程設計的，你開啟自動翻譯跑完一輪，再逐頁點開校修，把機器翻得怪怪的地方改掉。

如果你的網站是專業服務、醫療、法律、金融這類不能出錯的領域，自動翻譯僅能當參考，最終一定要人工把關。如果是部落格、生活資訊、產品介紹這類容錯率較高的內容，自動翻譯打底後抽查修潤即可。

還有一個成本觀念要先建立：人工校修的工時，通常遠高於你預期的。一段兩百字的中文，翻成英文後校修可能要花你十分鐘，聽起來不多，但一個五十頁的網站乘上去，就是好幾個工作天的份量。回過頭，建議把翻譯工作排進上架流程，每次發新內容就同步翻，而不是等累積一堆之後再回頭處理。後者那種「翻譯債」累積到後來，往往就是雙語站永遠做不完的真正原因。

從安裝到第一頁翻譯：完整走一遍

三個決定做好之後，就可以動手了。安裝流程很直覺，如果你之前裝過任何 WordPress 外掛，這裡不會卡關。接下來直接講 TranslatePress 特有的設定邏輯，照著走就能把雙語站架起來。

第一步：安裝與啟用

免費版可以直接從 WordPress 後台的外掛目錄搜尋 TranslatePress 安裝，並可串接 Google Translate v2 API。付費方案提供 SEO Pack、多語言、TranslatePress AI 等進階功能；DeepL 整合目前限 Business 與 Developer 方案。方案內容可能調整，安裝前應以官方方案頁為準。

第二步：基本設定

啟用後到「設定 → TranslatePress」，你會看到幾個分頁。第一個要設的是 General，在這裡選擇：

• 預設語言：通常是繁體中文（zh-tw）。
• 要新增的語言：選英文（en），設定語言切換器顯示的名稱和國旗圖示。
• 網址結構：維持子目錄的預設值即可。

存檔後，你的網站網址列會多出一個 /en/ 的版本，前台右上角（或你設定的位置）會出現語言切換器。點下去，整個介面切到英文模式，準備開始翻譯。

第三步：在前台開始翻譯

這是 TranslatePress 最關鍵的操作。登入 WordPress 後，打開前台的任何一頁，點上方管理工具列的 Translate Site 按鈕進入翻譯模式。進入之後，畫面上每一段文字、每一個按鈕、每一張圖片的替代文字，都會出現一個帶框的提示。

你用游標點到要翻譯的元素，左側會跳出翻譯面板。上面是原文，下面是空的翻譯欄位。你把英文打進去，右邊的預覽即時更新。翻完一個元素，往下滑繼續翻下一個，整頁翻完存檔。

第一次做的時候，建議挑首頁來練手。首頁通常元素最多元，有標題、副標、按鈕、圖片、頁尾資訊，翻完一個首頁就能完全掌握這套工作流程。接著再去處理服務頁、關於我們、聯絡頁這些核心轉換頁面。

翻譯面板的兩種視角：逐頁與全站字串

TranslatePress 的翻譯介面其實有兩種使用方式，很多人僅會用第一種。第一種是前面講的「前台逐頁點選」，適合校修排版和零碎文字。第二種是面板上方的一個「列出頁面所有字串」的列表視圖，它會把當前頁面所有可翻譯的字串一次列出來，包含一些前台點不到的隱藏字串，例如佈景主題裡的 gettext 字串、外掛產生的動態文字、結構化資料裡的欄位。

這個列表視圖在兩個情境特別好用：一是你要批次處理同一個頁面的大量文字，不想一個一個點；二是你發現前台某段文字翻譯後沒生效，懷疑它是不是來自某個外掛或主題的字串，這時候在列表裡搜尋關鍵字就能快速定位。兩種視角交替使用，翻譯效率會明顯提升。

一個實用的技巧：TranslatePress 會記住你已經翻過的字串，同一個字串如果出現在多個頁面（例如頁尾的版權聲明、按鈕文字），你若翻一次，其他頁面就會自動套用。這個設計大幅減少了重複工時，也是它比起傳統逐頁手翻的一大優勢。

自動翻譯引擎：Google Translate 與 DeepL 怎麼選

如果你的站僅有十幾頁，手動翻一翻也就算了。但一個稍有規模的網站動輒五六十頁，再加上部落格文章，全人工翻譯的工時會嚇死人。這時候自動翻譯引擎就派上用場了。

TranslatePress 可串接 Google Translate（透過 Google Cloud Translation API）；付費方案也提供 TranslatePress AI，而 Business 與 Developer 方案可整合 DeepL。各引擎的語言涵蓋、品質與費用不同，應先用少量內容測試。

Google Cloud Translation：覆蓋廣、速度快

Google 的翻譯引擎優勢在於語言覆蓋面，支援超過一百種語言，而且 API 穩定、文件齊全。對需要小眾語言（例如東南亞語系）的站來說，Google 幾乎是唯一選擇，支援語言與 API 細節可查 Google Cloud Translation 官方文件。

它的計價方式是按字元數計算。Google Cloud Translation Basic 目前每月前五十萬字元有免費額度，超出後依官方價目計費；實際成本仍取決於字元量、API 版本與帳戶設定，金額以 Google Cloud Translation 定價頁 為準。

Google 翻譯的弱項是文學性和語氣掌握。行銷文案、感性訴求的內容，翻出來會偏硬，需要人工修潤的比例比較高。

DeepL：語意自然、歐語系最強

DeepL 常被用在歐洲語系與需要調整語氣的內容，但翻譯品質會因語言配對、文體與術語而異，不能用單一結論判定必然優於其他引擎。正式導入前，先拿你的實際文案做盲測比較，引擎定位與能力說明可見 DeepL 官方網站。

DeepL 支援的語言範圍與 Google 不同，API 方案也可能包含固定費用、用量費用或免費額度。若目標語言在支援範圍內，而且很在意語氣，可以先估算 API 與 TranslatePress 方案的總成本再決定。

比較項目	Google Cloud Translation	DeepL
支援語言	涵蓋範圍廣，以官方清單為準	涵蓋範圍較集中，以官方清單為準
計價方式	按字元數，含一定免費額度	依 API 方案與用量計費
中英互譯品質	實用，偏直譯	較自然
歐語系表現	依語言與文體而異	可列入實際文案測試
適合場景	多語、小眾語言、預算敏感	重視語氣、主攻歐語市場

實務上的建議是：先用 Google 跑一輪全站打底，成本最低、覆蓋最廣。跑完之後，針對流量最高的幾個關鍵頁面（通常是首頁、服務頁、熱門商品頁），用 DeepL 或人工重新翻一次。把預算花在刀口上，不必整站都用最貴的引擎。這個分層策略能讓你在有限預算下把最重要的頁面品質拉到最高，同時控制住整體翻譯成本。

多語系 SEO 全設定：hreflang、語系網址、Sitemap

對 SEO 網站的讀者來說，這一段才是重頭戲。網站做多語系，如果語言版本沒有清楚串接，Google 可能選錯搜尋結果中顯示的版本。主要內容確實翻譯後，不會因為不同語言版本就被當成重複內容處罰。

多語系 SEO 有三個技術設定是必做的：hreflang 標記、語系網址結構、分語系 Sitemap。TranslatePress 的 Pro 版 SEO Pack 把這三件事自動化處理了大半，但你還是要懂背後的邏輯，才知道設定到底對不對。更完整的 hreflang 原理和常見錯誤，可另參考 hreflang 多語系 SEO 完全手冊，建議搭配閱讀。

hreflang 自動標記

hreflang 是 HTML link 標籤的一個屬性，作用是告訴 Google「這個頁面的中文版在這裡、英文版在那裡」。有了它，Google 才能在對的市場顯示對的語言版本。例如台灣使用者搜尋時看到中文版，美國使用者搜尋同一個主題時看到英文版。

TranslatePress Pro 會自動在每個頁面的 head 區段產生正確的 hreflang 標記，對應你設定的所有語言。你不用手動寫任何程式碼。但你要做的是：到設定裡確認 hreflang 有開啟，而且每個語言的 locale 代碼設對了（例如繁體中文是 zh-tw，英文是 en 或 en-us）。

實際產出的標記長得像這樣：在中文版頁面的原始碼裡，你會看到一組 link 標籤，分別指向自己（zh-tw）與英文版（en）。若另行啟用進階的 x-default 設定，還會有一個給未匹配語言訪客的預設版本。在英文版頁面裡，同樣的對應標記也要出現；Google 要求 hreflang 使用雙向回指，缺少回指的標記可能被忽略。

驗證時，打開每個語言版本的原始碼，搜尋 hreflang，確認標記齊全、網址可索引且互相回指。Search Console 的「國際定位」報表已於 2022 年 8 月公告停用，因此要改用原始碼檢查、網站爬取工具與網址檢查工具交叉確認，可對照 Google 的除役公告。

語系網址與 Slug 翻譯

子目錄結構下，每個語言版本的網址是 /zh-tw/關於我們 和 /en/about-us。這裡有一個常被輕忽的細節：URL slug 也要翻譯。中文版的 slug 可能是中文或拼音，英文版應該換成有意義的英文 slug。

TranslatePress 的 SEO Pack 支援 slug 翻譯，讓同一篇文章在不同語言版本有清楚、可讀的網址。這有助於訪客理解與團隊管理，但不要把網址裡有關鍵字當成排名保證。記得在翻譯模式裡，連 slug 欄位也一起處理。

圖片也能分語言替換

很多人不知道，TranslatePress Pro 有一個被低估的功能：為不同語言版本設定不同的圖片。這代表你的中文版首頁可以放一張針對台灣市場設計的 banner，英文版換成另一張針對海外受眾的視覺素材。不僅是圖片的 alt 文字翻譯，而是整張圖片都可以替換。

這個功能對行銷導向的網站價值很高。同樣一張產品情境照，台灣消費者看到的可能是繁體中文文案疊加的版本，海外客人看到的應該是英文版或乾淨無字的版本。語言切換器的圖片、頁首的 hero image、服務介紹的配圖，都可以依語言獨立設定。細節做到這個程度，訪客才會真的覺得「這個網站是為我準備的」，而不是「這僅是個翻譯過的網站」。

操作上，你在翻譯模式點到一張圖片時，面板會出現「上傳新圖片」的選項。你為英文版上傳對應的圖片，存檔後英文版就會顯示新圖，中文版維持原圖不動。圖片的檔名和 alt 文字也要記得跟著語言調整，這樣連圖片搜尋的 SEO 都能照顧到。

SEO 標題與 Meta 描述的翻譯

多語系 SEO 最容易翻車的地方，是頁面的 title 和 meta description。很多站長僅翻了正文，標題和描述還是中文（或乾脆兩個語言共用同一組），結果英文版的搜尋結果在 Google 上一團糟。

TranslatePress Pro 可以翻譯每個頁面的 SEO 標題、Meta 描述、Open Graph 標籤，甚至 Schema 結構化資料裡的字串。如果你用的是 Rank Math 做 SEO，TranslatePress 會直接整合它的欄位，讓你針對每個語言版本獨立設定。Rank Math SEO 外掛的完整設定教學 可以幫你把基礎打好。

分語系 Sitemap 與索引驗證

Sitemap 可以依語言分開，也可以在同一份 Sitemap 裡標註語言對應。TranslatePress 的 SEO Pack 可整合支援的 SEO 外掛輸出多語系 Sitemap。把實際產生的 Sitemap 提交到 Google Search Console，再觀察各語言網址的索引狀況；如果還沒設定好 Search Console，先看 Google Search Console 安裝教學，並用原始碼與網址檢查工具驗證 hreflang。

WooCommerce 雙語電商的實戰重點

電商網站做多語系，複雜度比內容站高一個量級。不僅是文章要翻，商品名稱、商品描述、變體規格、運費說明、結帳流程的每一段文字、Email 通知、甚至購物車裡的按鈕，全都要翻譯。而且每個語言的商品頁 SEO 都要獨立優化。

WooCommerce 目前是全球市佔率最高的電商平台之一，根據 W3Techs 的數據（2026 年 6 月），它在所有使用內容管理系統的網站裡佔有相當高的比例，這也意味著圍繞它的多語系需求非常龐大。

TranslatePress 核心功能可翻譯 WooCommerce 前台內容與字串；若要翻譯 SEO 標題、描述與商品 slug，則需要付費方案的 SEO Pack。實戰上要特別注意幾個地方。

商品頁的雙語 SEO

每個商品在英文版都應該有獨立的 SEO 標題、Meta 描述、以及翻譯過的 URL slug。英文商品頁的關鍵字佈局要重新思考，不是把中文關鍵字直翻就好。台灣市場搜尋「陶瓷馬克杯」，英文市場可能搜尋 ceramic coffee mug 或 handmade ceramic mug，背後的搜尋意圖和競爭環境完全不同。商品頁的 SEO 優化細節，可以參考 WooCommerce 商品頁 SEO 完全手冊。

結帳流程的在地化

結帳頁是轉換率的生死線。如果海外客人在結帳時看到半中半英的混亂介面，信任感會瞬間歸零。TranslatePress 可以翻譯結帳表單的每一個欄位標籤、按鈕文字、錯誤提示訊息。你要做的是切換到英文版，親自走一遍完整的結帳流程，把每一個沒翻到的地方補齊。

特別注意付款和物流的說明文字。很多金流外掛的字串是獨立產生的，要確認它們也被 TranslatePress 抓到了，不要僅翻前台看得到的文字。

貨幣與稅金是另一回事

語言翻譯解決了文字問題，但多語系電商往往伴隨多幣別、多稅制的需求。TranslatePress 僅管語言，不管幣別。如果你需要依照語言切換顯示貨幣（例如英文版顯示美元、中文版顯示台幣），要搭配 WooCommerce 的多幣別外掛來做。這一塊是獨立的工程，別指望一套翻譯外掛全部搞定。

效能與快取：別讓多語系拖垮 Core Web Vitals

多語系網站會增加翻譯紀錄與快取版本，效能仍要實測。TranslatePress 採靜態翻譯架構，翻譯結果（人工與自動翻譯皆然）儲存在本機資料庫、直接輸出成網頁 HTML，不會在每次前台載入時都重新呼叫翻譯 API；真正的負擔會依頁面、外掛、快取與尚未翻譯的字串而異。

Google 的排名系統會使用 Core Web Vitals 等網頁體驗訊號，但良好分數不保證排名，內容相關性仍更重要，這點可對照 Google Search Central Blog 於 2018 年 1 月的 Using page speed in mobile search 一文。行動優先索引（mobile-first indexing）則是 Google 主要使用行動版內容進行索引與排名，不代表「行動版」本身是額外加分項，官方在 2023 年 10 月的 Mobile-first is here 一文有完整說明。

對多語系網站來說，Core Web Vitals 的三個指標（LCP、INP、CLS）每一個都可能被多語系設定影響。你需要一套好的快取策略來抵消額外的負擔，WordPress 快取外掛的完整比較 裡有幾款經過實測的選擇。如果你想深入了解指標本身和優化方向，先看 Core Web Vitals 完全攻略，把觀念弄清楚再回來調多語系的快取。

TranslatePress 在效能上有做最佳化：翻譯結果會被快取，不會每次請求都重新查資料庫；自動翻譯的結果也會被存下來，不會每次都呼叫 API。但你要確認你裝的快取外掛有正確處理多語系頁面。有些快取外掛會把不同語言的頁面快取成同一份，這是個經典地雷，會導致英文訪客看到中文內容。

具體做法是：在快取外掛裡，把每個語言的子目錄路徑（例如 /en/）設定為獨立的快取群組，確保英文版和中文版各自有自己的快取副本。多數主流快取外掛都支援這個設定，但預設不一定開啟，要手動檢查。

五個實務上要主動避開的地雷

觀光旅宿網站做雙語時，常見需求是替原有中文內容補上英文版。真正吃掉工時、也最容易讓網站做不出效果的地方，通常是以下五個地雷。

第一個地雷是僅翻了正文，漏掉介面文字。語言切換器下方的「選擇語言」、搜尋框的預留文字、表單的送出按鈕、頁尾的版權聲明，這些零碎字串很容易被遺漏。訪客一進站，正文是英文的，但旁邊的按鈕還是中文，信任感瞬間打折。TranslatePress 的視覺化模式可以幫你抓到大部分，但你要有耐心把每個頁面從頭到尾點過一遍。

第二個地雷是hreflang 設定錯誤。最常見的是雙向標記不完整：中文版指向英文版，但英文版沒有指回中文版。x-default 是可選設定，不是每個網站都必須加入。hreflang 出錯時，Google 可能忽略標記或顯示非預期語言版本；請用原始碼、爬取工具與網址檢查工具交叉驗證。

第三個地雷是翻譯品質不一致。同一個詞，首頁翻成 Experience，部落格翻成 Tour，結帳頁又翻成 Activity。訪客會混淆，Google 也讀不出主題權威。建議在動手翻之前，先列一份術語對照表（glossary），把核心詞彙的英文定下來，全程統一。這份對照表日後也會成為你擴充第三、第四語言時的基礎。

第四個地雷是忘記翻譯圖片的替代文字和檔名。SEO 不僅看文字內容，圖片的 alt 屬性和檔名也是排名訊號。中文版的圖片 alt 是中文，英文版要換成英文。TranslatePress 可以為每個語言設定不同的圖片 alt，但你要記得到位，不要僅顧著翻正文。

第五個地雷是語言切換器藏太深。有些站長把語言切換器塞在頁尾的最角落，海外訪客根本找不到英文入口。正確的位置是頁首右上方或主選單裡，第一眼就看得到。TranslatePress 提供語言切換器的短代碼和小工具，你可以放在任何位置，也可以用浮動選單固定在畫面角落，確保任何頁面都能一鍵切換。

TranslatePress 付費方案拆解與採購建議

免費版能做基礎雙語：一個額外語言、視覺化翻譯介面、語言切換器，也能串接 Google Translate v2 API。若需要多個額外語言、SEO Pack、DeepL 或較完整的 AI 翻譯額度，再依需求升級付費方案。WooCommerce 前台翻譯本身不以付費附加元件為前提。

TranslatePress 的付費方案分為 Personal、Business、Developer，主要差異包含網站數量、DeepL 與 AI 翻譯額度；價格與內容可能調整，採購時以 TranslatePress 官方定價頁 為準。

到底該不該買？判斷標準很簡單：

你的情境	建議方案
僅做中英雙語、頁數不多、自己人工翻	免費版就夠
需要 Google Translate 自動翻譯打底	免費版即可串接 API；大量使用前先估算 API 成本
需要完整多語系 SEO（hreflang、slug 翻譯、meta 翻譯）	Pro SEO Pack
WooCommerce 電商雙語	免費版可翻前台；商品 SEO 欄位需要 SEO Pack
多語言、多站點、專業在地化營運	依網站數與引擎需求比較 Business、Developer

一個提醒：自動翻譯引擎（Google 或 DeepL）的 API 費用是另計的，不在 TranslatePress 授權費裡。不過如前面算過的，對中型網站來說 API 費用很低，真正貴的是人工校修的時間成本。授權費差幾十美元其實不是重點，把心力放在「怎麼把翻譯品質做到位」這件真正影響成果的事上，才是決定雙語站能不能帶來流量的關鍵。

動手前的四步檢查清單

看到這裡，你應該對 TranslatePress 的完整工作流程有清楚的輪廓了。真正要動手之前，把這四件事按順序做一遍，可以少走很多冤枉路：

1. 確認語言與網址策略：決定第一個外語（通常是英文），網址用子目錄結構，語言代碼用標準格式。把這個決定寫下來，整個專案都以此為準，不要中途改來改去。
2. 安裝並跑一輪自動翻譯打底：先讓整站有個英文草稿版，你才有東西可以校修。用 Google 引擎跑全站，成本最低。跑完之後備份一次，給自己一個可以隨時回滾的安全網。
3. 逐頁人工校修，從高流量頁面開始：首頁、服務頁、熱門商品頁優先。準備一份術語對照表，確保用詞全程一致。校修時連圖片 alt、按鈕文字、表單欄位都一起檢查。
4. 檢查 SEO 三件套：hreflang 標記正確且雙向回指、每個語言的 title 和 meta 都翻了、Sitemap 已提交到 Search Console。用原始碼、爬取工具與網址檢查工具驗證，持續觀察索引狀況。

多語系網站不是裝一個外掛就完工的專案，它是一個會持續長大的內容資產。每一篇新文章、每一個新商品上架，都要記得同步翻譯。把這個流程內化成上架標準作業的一部分，你的網站才會真正從「台灣限定」變成「國際版」，而且每多一個語言，都是一份會隨時間累積價值的長期資產。正因如此，建議挑一套用得順手、團隊願意長期配合的工具，因為真正決定多語系成敗的，從來不是外掛的功能強不強，而是你能不能持續地把翻譯這件事做下去。

TranslatePress 的視覺化哲學，本質上是把「翻譯」這件讓人望之卻步的事，拆解成你每天都能做一點點的小動作。不用一次到位，不用完美主義，若持續在校修，雙語站就會一天比一天完整。海外市場不會等你準備好才出現，但你可以從今天開始，一頁一頁地把國際版的基礎搭起來。現在，打開你的網站前台，從首頁開始翻第一段吧。