多數人以為，把文章網址設成中文，等於在 SEO 上先扣一分，這幾乎是台灣站長圈的共識做法，先假設中文網址不夠專業，再想辦法補救。但 Google 自己公開的文件與官方影片給的答案，是另一套完全不同的版本，非英文網址不但沒問題，Google 甚至把「用讀者的語言下網址」寫進最佳做法的建議裡。
這個誤解會存在，很大一部分要歸咎於 WordPress 的預設行為。固定連結設定選「文章名稱」結構的話，文章一發布，標題是什麼，網址（slug）就直接變成什麼；多數人寫中文標題，從沒想過要手動把它改成英文，這是幾乎每個用 WordPress 寫作的人都會踩到的路徑，不是誰做錯了什麼決定。WordPress 中文網址因此成了一個很普遍、卻很少被真正查證過的疑問，這樣做真的會拖累排名嗎？如果不會，為什麼分享到 LINE 或臉書時，連結卻常常變成一長串看不懂的亂碼？
這兩個問題背後的答案並不一樣，一個關乎排名，一個關乎編碼機制，混在一起想才會產生誤解。
WordPress 用中文標題直接產生網址的預設行為
打開 WordPress 後台，設定裡的固定連結只要選「文章名稱」這個結構，系統就會把每篇文章的標題原封不動拿去產生網址路徑。中文標題也不例外，WordPress 不會像處理法文或德文那些帶重音符號的字母一樣，把腔調字母轉寫回基礎拉丁字母；遇到中文字元，它直接把整段文字視為合法的多位元組 UTF-8 內容保留下來，不刪、也不轉寫成拼音，原樣收下。
會這樣，是因為 WordPress 核心負責處理 slug 的那組函式，從設計上就沒有替中文安排「音譯」這道手續。多數台灣站長寫文章時，也很少會在發布前特地把中文標題改成一串英文字，一來要多花時間想詞，二來系統本來就會自動生成、不改也能正常發布。久而久之，中文網址就成了 WordPress 中文站台最常見的預設樣貌，而不是某個人偷懶或做錯決定的結果。
也正因為這是預設行為、幾乎人人都會踩到，這樣寫網址有沒有問題，才會變成一個值得認真查證的問題，而不是隨口一句「聽說不好」就能帶過。
Google 官方文件與影片對非英文網址的實際立場
要回答中文網址傷不傷排名這個問題，與其猜測或參考別人的經驗談，不如直接看 Google 自己怎麼說。Google 公開的網址結構文件，以及官方頻道上一支專門回答這個問題的影片，兩邊講的是同一件事，網址用不用中文，跟排名好不好，原本就不是同一回事。
非英文網址不影響排名的官方說法
Google Search Central 的官方文件《Google 搜尋的網址結構最佳做法》裡，把「使用目標對象的語言」列為讓網址更容易理解的做法之一，文件建議在網址中使用目標讀者的語言，如果有需要音譯的字詞，也建議照音譯處理。文件裡舉的其中一個範例，就是把面向日文讀者的網址路徑，直接寫成日文假名本身，完全沒有轉寫成羅馬拼音；另一個德文範例，則是把兩個德文單字分別放進網址路徑的不同層級，同樣沒有轉寫成別的語言。也就是說，網址內容用讀者看得懂的語言，是 Google 自己在文件裡示範的做法，不是站長自己想像出來的權宜之計。
同一個問題，Google 的官方頻道 Search Central 也做過更直接的回答。在 SEO Snippets 系列裡，一支名為〈Can my URLs use non-English words?〉的影片中，Google 的 John Mueller 親自解答這個疑問，原話是「Yes, non-English words and URLs are fine, we recommend using them for non-English websites」，意思很明確，非英文的字詞與網址沒有問題，對非英文網站，Google 反而建議這樣使用。Mueller 接著補充，唯一的條件是「as long as URLs are valid and unique, that’s fine」，也就是網址本身要有效、要唯一，滿足這兩個條件就沒有問題。中文網址踩中的，正是 Mueller 講的這個情境。
網址塞入關鍵字的排名份量，其實很小
不過，中文網址不扣分，不代表反過來網址塞滿關鍵字就會加分，這是另一個容易被順勢誤解的極端。Google 前搜尋垃圾郵件團隊主管 Matt Cutts，在 2009 年一支官方影片裡談過網址裡放關鍵字這件事，原話是「It does help a little bit to have keywords in the URL」，但他緊接著提醒「It doesn’t help so much that you should go stuffing a ton of keywords into your URL」。網址裡有關鍵字確實有一點點幫助，但幫助小到不值得為了塞滿關鍵字，硬把網址拉得又長又雜。
到了 2016 年 1 月的一場 Google Webmaster Central hangout，John Mueller 也確認網址裡的關鍵字仍然是排名因素之一，但份量非常小。兩則官方發言前後相隔 7 年，結論卻高度一致，網址裡的語言選擇與關鍵字份量，對排名的影響都很輕微，真正該花心力的地方是內容本身的品質，不是糾結網址該用中文還是英文、該塞幾個關鍵字。
中文網址複製分享後跑出一長串編碼的技術成因
排名的疑慮解開後，還有另一個常被跟排名混在一起討論的問題，中文網址複製到 LINE 或臉書，為什麼會變成一串看不懂的百分比符號？這跟排名完全無關，是另一層技術機制在運作，而且答案跟多數人以為的不一樣，這串編碼不是分享出去那一刻才產生的，而是文章存進資料庫的當下就已經定型。
WordPress 資料庫裡的網址欄位，其實早就是編碼
WordPress 核心負責處理 slug 的函式叫 sanitize_title_with_dashes()，收在核心檔案 wp-includes/formatting.php 裡。文章要儲存的時候，這支函式先用 wp_is_valid_utf8() 確認標題是不是合法的 UTF-8 字串，是的話就用 mb_strtolower() 把英文字母轉成小寫，緊接著呼叫另一支函式 utf8_uri_encode()，把整段文字轉成網址能用的格式。
utf8_uri_encode() 實際做的事，是逐一檢查每個字元占幾個位元組，按照 UTF-8 的規則判斷這是單位元組、雙位元組、三位元組還是四位元組的字元。遇到中文這種三位元組字元，它會把字元拆成三個位元組，每個位元組各自轉成「百分比符號加兩碼十六進位值」的格式輸出，例如「中」這個字，最終被轉成 %E4%B8%AD。也就是說，WordPress 把文章存進資料庫的那一刻，post_name 欄位裡存的本尊，就已經是這串百分比編碼，不是原始的中文字，後台編輯畫面之所以看起來還是乾淨的中文，是介面體貼使用者，把已經編碼的欄位值解碼還原顯示出來的結果——這只是介面做的表面功夫，資料庫裡從第一天起存的就是編碼字串。
一個中文字編碼後膨脹成九個字元
這段換算不需要外部引用，照 UTF-8 的編碼規則就能自己驗算。中文字，也就是中日韓統一表意文字，在 UTF-8 底下每個字固定占 3 個位元組；而百分比編碼會把每一個位元組轉成「百分比符號加兩碼」共 3 個 ASCII 字元，所以 1 個中文字編碼後等於 3 個位元組乘以 3 個字元，也就是 9 個字元。
用「中文」這兩個字實際驗算一次，編碼後會變成 %E4%B8%AD%E6%96%87，總共 18 個字元，剛好對上 2 個字乘以 9 的算法。換成一句更貼近讀者情境的標題，例如 10 個字的「品牌設計為什麼很重要」，若這串文字是連續的中文、中間沒有空白需要拆詞，編碼後會膨脹成整整 90 個字元；如果原本標題裡帶有空白或標點，WordPress 在轉換時還會在詞與詞之間插入連字符，實際字元數只會更多，不會更少。複製到 LINE 或臉書貼文欄位裡看到的那一長串亂碼，就是這套機制的直接產物，不是 WordPress 的程式碼出了問題，而是編碼機制原本就這樣運作。
中文網址在分享、後台分析上付出的真正代價
排名沒事，編碼機制也搞懂了，那中文網址真正的問題出在哪？答案不是「不好看」這麼籠統的說法，而是三個具體的實際面向，分享時失去可讀性、後台數據判讀變麻煩，以及某些系統的相容性風險。這三種代價值不值得為了它們去改網址，交給每個人依自己的使用情境判斷。
分享到社群後，失去一眼辨識的優勢
中文網址在瀏覽器網址列或 WordPress 後台編輯畫面裡看起來一目瞭然，這正是不少人選擇沿用中文網址的原因，標題寫什麼，網址就長什麼樣，讀者一眼就能猜到內容在講什麼。問題出在複製貼上的那一刻，一旦這段網址被貼進 LINE 聊天室、臉書貼文欄位或 Dcard 文章裡，前面講的那套百分比編碼機制就會啟動，原本一看就懂的中文，瞬間變成一長串以 %E4 開頭的字元。
這不是中文網址設計得特別差，而是任何非 ASCII 字元的網址，只要被貼進純文字欄位，都會經歷同一套 UTF-8 轉百分比編碼的流程，日文、韓文、阿拉伯文網址一樣會遇到同樣的狀況，不是中文獨有的缺陷。差別只在於，原本一看就懂正是選擇中文網址的主要理由，這個理由在複製貼上的瞬間就被完全抵銷掉了。
GA 和 Search Console 報表變得難以判讀
後台分析工具遇到中文網址，會出現另一種麻煩。流量報表與 Google Search Console 的成效報表裡，列出的網址路徑，就是伺服器實際回應的那串百分比編碼字串，工具端不會額外幫忙翻譯回中文。站長想從報表裡找出某一篇文章的數據，得先想辦法把中文轉換成對應的百分比編碼，才篩選得到，平白多了一道轉換的手續。
這不是這些工具的問題，而是它們忠實反映了伺服器真正回應出去的那個網址字串。報表列表裡看到編碼而不是中文，是預期中的結果，只是對習慣直接用中文關鍵字篩選資料的人來說，判讀起來少了幾分直覺。
廣告投放、外部連結建置的相容性風險
還有兩個發生機率不低，卻容易被忽略的相容性問題。一是部分廣告投放後台或一些較舊的第三方系統，解析非 ASCII 網址時可能不夠穩定；二是想邀請其他網站連結到自己的文章時，一長串編碼網址在溝通上比一個乾淨的英文網址麻煩得多，對方得花額外力氣確認連結有沒有貼對、格式有沒有跑掉。
Google 官方的網址結構文件裡也提到，依標準定義，網址裡的保留字元必須做百分比編碼；連結的 href 屬性則是視需要處理 ASCII 字元，非 ASCII 範圍的字元則建議一律採用百分比編碼。連 Google 自己都特別提醒這件事，側面說明非 ASCII 網址在某些傳輸環節需要額外留意，不是危言聳聽，但也不必看得太嚴重，實際情況會依系統與平台而不同。
保留中文網址仍然合理的少數情境
把前面的排名事實與代價都攤開後，答案不是所有人都該把網址改成英文，而是要看情境。如果讀者幾乎全是台灣本地的中文使用者，平常搜尋、點擊、分享都在中文語境裡完成，中文網址一看就懂的優勢，原本就是實際存在的好處，不是自我安慰。
如果文章內容本身就是在地地名、生活口語或台灣特有的用詞，例如某條老街的名字、某種只有台灣人在用的講法，直接音譯成英文反而會失去原本的意義，讀者看了拼音也不見得認得出來。再加上，如果這個網站不特別追求對外的連結建置，也不打算之後拓展到跨語言市場，廣告投放與外部溝通的相容性風險相對就沒那麼要緊。符合這幾個條件，繼續用中文網址，代價是可以接受的。
改成英文網址有兩種做法，各自限制不一樣
如果評估下來，覺得繼續用 WordPress 中文網址要付出的代價確實划不來，實務上通常有兩條路可以走，讓外掛自動把標題轉換成拼音或英文，或是自己每次發文手動輸入英文 slug。這兩條路各有各的限制，沒有哪一種絕對比較好，重點是先搞懂原理，再依自己的情況判斷。
外掛自動轉換的做法，各有取捨
這類做法通常是攔截 WordPress 產生 slug 的那個環節，把中文標題自動轉寫成拼音或音譯字串。好處很直接，省事，不用每篇文章都動腦想英文詞。限制也同樣明顯，拼音轉出來的字串本身沒有語意，讀者看到一串羅馬拼音，一樣猜不出這篇文章在講什麼，跟中文網址比起來，只是換了一種看不懂的方式；而且轉換規則因產品而異，哪天換了工具或停用外掛，舊網址的轉換邏輯可能對不上新的規則，會產生變動的風險。
不論用哪一種轉換方式，最終產生的 slug，一樣要通過 sanitize_title_with_dashes() 這道關卡。如果轉換出來的結果仍然含有非 ASCII 字元，一樣會被 utf8_uri_encode() 編碼，等於白轉。判斷這類做法有沒有真正解決問題，關鍵是看它轉出來的字串是不是純 ASCII 的拼音或英文，而不是看外掛的名稱或行銷說法怎麼包裝。
手動輸入英文網址的判斷準則
另一條路，是每次發文時自己動手把 slug 改成精簡的英文字詞。這條路不依賴任何轉換規則，運作方式最直接，但考驗的是流程紀律，每篇文章發布前都要記得手動修改，一旦哪次忘了改，就會漏回中文網址的老路。
改成英文網址時，判斷準則可以直接參考 Google 官方文件已經講明的原則，網址用簡單的描述性字詞，多個英文單字之間用連字符分隔，不要用底線。Google 文件裡對這點特別做了說明，底線常被用來表示應該保持在一起的概念，基於這個歷史因素，官方不建議用它來分隔單字。實務上套用這條準則，挑最能代表這篇內容的幾個關鍵字詞，用連字符串起來，避免把所有相關詞都塞進同一個 slug 裡，才是站得住腳的做法。
已經上線的中文網址，現在調整的判斷依據
前面談的都是新文章該怎麼決定，但更常見的疑問，其實是已經發布很久、已經被讀者分享、也已經被 Google 收錄的中文網址，看完前面這些，還要不要現在動手改？
中文網址、編碼網址其實是同一個網址
很多人擔心，自己文章的網址列顯示的是中文，但分享出去卻變成編碼，這樣算不算變成兩個不同的網址，會不會害排名或收錄分散在兩個地方。這個疑慮，前面提到的那支 Google 官方影片其實已經直接回答過，網址其餘部分可以用 Unicode UTF-8 編碼表示，網站可以選擇顯示成跳脫版本，也就是 %E4%B8%AD 這種百分比編碼形式，也可以選擇顯示成 Unicode 版本，也就是直接顯示中文字，這兩種形式對 Google 來說是等價的。
這個等價關係，技術規範層面也站得住腳。Google 的網址結構文件本身寫明，Google 搜尋支援由 IETF（網際網路工程工作小組）所定義的網址格式，而這個標準本身就規定，網址裡的保留字元必須用百分比編碼表示。也就是說，百分比編碼形式，本來就是這個網址在網路傳輸協定層級的正式表示法，中文字顯示只是瀏覽器介面為了方便使用者閱讀所做的還原。從協定的角度看，兩者是同一份位元組、同一個資源，不是兩個不同網址，不會因此讓收錄或排名分散開來。
真的要改，301 轉址是必要動作
如果評估後還是決定要把已經上線的中文網址改成英文，重點不是改完 slug 就結束，而是一定要搭配轉址，而且要用對的轉址類型。Google 官方文件《重新導向與 Google 搜尋》明確建議，更換網址時優先使用伺服器端的 301（或 308）永久轉址，因為這是 Google 最容易正確解讀的方式；其次是 0 秒的 meta refresh 轉址；JavaScript 轉址則是最後的手段，因為如果頁面渲染失敗，Google 很可能根本看不到這個轉址動作。
文件也說明，永久轉址的效果是搜尋結果會直接顯示新的轉址目標，暫時轉址則搜尋結果仍然會顯示原本的來源頁面，Google 不會把暫時轉址當成正規化的訊號來處理。實務上的結論很清楚，真的要把中文網址改成英文，一定要在伺服器端設定 301，把舊網址導到新網址，而不是單純改掉 slug 就收工。少了轉址這一步，原本已經被分享出去、已經被收錄的中文網址，不會自動接上新網址，只會直接變成 404，把先前累積的流量與連結價值一次歸零。
WordPress 中文網址值不值得改，答案從來不是一定要改或絕對不用改，而是先把兩件事分開看，排名不受影響，是 Google 官方文件與影片都講清楚的事實；分享時失去可讀性、後台數據判讀變麻煩，則是實實在在存在的代價。前者不需要為它焦慮，後者才是真正該拿來衡量的東西。
如果讀者幾乎都在中文語境裡互動，這個代價可以接受，不動它也沒關係；如果對外連結建置與跨語言擴充是接下來要做的事，那把新文章的 slug 改成精簡的英文字詞，是相對划算的選擇。已經上線的文章要不要動，則多看一眼有沒有做好 301 轉址這一步，做對這一步，不管網址最後長什麼樣子，先前累積的東西都不會平白流失。