WooCommerce 縣市下拉：RY WC City Select 教學

你有沒有算過，一筆訂單從下單到真正送進客人手裡，中間被「打錯地址」吃掉多少錢？結帳頁那個看似無害的縣市欄位，預設是一個空白輸入框，客人愛打什麼就打什麼：「台北市」「臺北市」「Taipei」「台北」，物流系統全部視為不同東西。結果就是退件、重寄、客服一路追，毛利在這裡一滴一滴漏掉。這篇要談的，就是把 WooCommerce 結帳頁那個地址欄位，從一個自由心證的文字框，換成有規矩的縣市下拉選單，而我自己最常選的工具是 RY WC City Select 這支免費外掛。

先說結論：根據 W3Techs 的統計（2026 年 6 月），WooCommerce 是目前全球市佔最高的電商平台，但它預設的地址結構是為歐美設計的「國家 / 州 / 城市」三層，套到台灣的「縣市 / 鄉鎮市區 / 門牌」結構時，那個城市欄位永遠是自由輸入。把它改成下拉選單，不只解決打字錯誤，更是後面所有自動化的前提：綠界物流要標準縣市、超商取貨要對應門市、運費規則要依區域計算，全部都卡在這個欄位能不能給出一個乾淨的值。

一個打錯的縣市，到底會吃掉你多少成本

我用一個實際的情境把它拆給你看。一個客人結帳時，縣市欄位打了「台中市」，但他的行政區其實是新北市的某個區，因為他剛搬家、地址複製貼上沒改乾淨。訂單進來了，你出貨，物流掃不到對應的行政區，退回來。這時候你要付出的是：重新聯絡客人確認地址、重新包裝或重新列印託運單、可能還要吸收第二次運費。一筆低單價的訂單，光這一來一回就吃光利潤。

以家具電商這類網站為例，地址欄位原本是最容易被略過的退件來源：客單價不低，一件大型家具退件一次的來回運費很可觀，但退件原因長期被歸類成「物流問題」，沒有人回頭去看結帳頁那個欄位的設計。一旦把縣市欄位換成下拉選單、再把鄉鎮市區也做成連動，客人打錯地址的比例通常會明顯下降。這裡不給一個漂亮的百分比，因為每個站的基準不同，但方向是肯定的：把自由輸入換成結構化選擇，退件就會少。

這背後的道理很樸素：結帳頁的每一個欄位都是摩擦力。摩擦力有兩種，一種是「要打字」，一種是「打了會錯」。下拉選單同時解掉這兩種，客人不用打字、也不會打錯。對你來說，你拿到的是一個可以被程式直接使用的乾淨值，不需要再人工清洗。

三種做出縣市下拉選單的方法，我為什麼挑 RY WC City Select

要把那個欄位換成下拉選單，實務上有三條路。我先把它們擺在一起比，你會很清楚為什麼我長期偏好第三條。

方法	做法	優點	缺點
Checkout Field Editor 改欄位類型	把 billing_city 的 type 改成 select，手動塞選項	不用裝新外掛，設定集中在結帳表單	選項是死的、沒有連動、中文清單要自己維護，跟物流外掛的縣市格式不一定對得起來
自己寫 functions.php	用 WooCommerce 的 woocommerce_form_field 把 city override 成 select	完全可控、零多餘程式碼	要懂 PHP 與 WooCommerce hook，後續維護成本在你身上，台灣縣市清單改了要自己改
RY WC City Select 外掛	專門做國家 / 州 / 城市的下拉連動，內建多國城市清單，台灣在內	免費、連動、跟物流外掛的格式相容性高，作者是台灣人、清單在地化做得很完整	多一支外掛、要跟主題與其他結帳外掛測相容性

換句話說，前兩種方法都是「把欄位類型換掉」，但下拉選單真正的價值不在於它是 select，而在於它的選項是對的、而且會連動。你選了新北市，下一欄就該自動縮小範圍到新北市底下的區，整包全台鄉鎮混在一起丟給客人，是最差的體驗。Checkout Field Editor 做不到連動，自己寫要做到連動要花很多工。RY WC City Select 是專門為這件事生的，所以它成為我的預設選擇。

這支外掛與 RY WooCommerce Tools 出自同一開發者，可能有助維持台灣地址與物流格式的一致性，但實際相容性仍要依版本、WooCommerce 設定與金物流外掛測試。若準備串接綠界，可一併核對兩支外掛的支援範圍與更新紀錄；整體選擇則可參考電商外掛評測。

WooCommerce 的地址模型跟台灣差在哪：先搞懂為什麼預設會卡住

要真的理解這支外掛在做什麼，得先看懂 WooCommerce 預設的地址模型是怎麼設計的。它的核心結構是三層：國家（country）、州（state）、城市（city）。這是一個標準的美式地址模型，背後對應的是美國的「國 / 州 / 城市」邏輯，也勉強套得上多數歐美國家。

台灣的實際地址結構是四層：縣市、鄉鎮市區、路段、門牌號。把這個結構塞進 WooCommerce 的三層模型，就會出現一個必然的錯位：

WooCommerce 欄位	原本設計給誰	套到台灣被拿來放什麼
billing_country	國家	台灣（沒問題）
billing_state	州 / 省	22 個縣市（WooCommerce 內建有台灣的州清單）
billing_city	城市	鄉鎮市區（但預設是自由輸入文字框）
billing_address_1 / 2	街道門牌	路段與門牌號

看出問題了嗎？WooCommerce 其實有為台灣準備 state 清單，所以 billing_state 那一層預設就有 22 個縣市的下拉。但 billing_city 那一層，它沒有為台灣準備對應的鄉鎮市區清單，於是就退化成一個空白的文字輸入框。這就是為什麼很多站長以為「我有裝 WooCommerce、也有選台灣，地址應該沒問題」，結果一打開結帳頁，縣市是下拉、區卻是輸入框，一半結構化、一半放牛吃草。

RY WC City Select 補的，就是 billing_city 這一層的結構化。它做兩件事：第一，把 city 欄位從文字框換成下拉；第二，讓這個下拉根據你選的 state（縣市）連動，只顯示那個縣市底下的區。換句話說，你不是在「新增一個功能」，你是在「補完 WooCommerce 為台灣沒有做完的那一哩」。這個認知很重要，因為它解釋了為什麼這支外掛要跟 billing_state 緊密搭配，也解釋了為什麼後面會強調預設國家要設成台灣：整個連動的起點，就是從 state 那一層的選擇開始的。

這個結構性的理解，也會幫助你之後 debug。當某一層的連動壞掉，你會知道是 state → city 這條鏈斷在哪裡，不會把整個結帳表單從頭懷疑一遍。

訪客結帳與會員地址：下拉清單在兩種情境下的差別

結帳頁不是只有一種使用情境，它至少分成「訪客結帳」與「會員登入結帳」兩種，下拉選單在這兩種情境下的行為不一樣，你要分開測試。

訪客結帳是 RY WC City Select 最直接的戰場。客人沒登入、每次都是全新的 session，下拉清單一開始是空的，他要自己選縣市、再選區，流程乾淨。這個情境下，你要測的是「從零開始選」的體驗：下拉好不好點、連動速度快不快、選完之後運費有沒有跟著更新。多數人在這個情境下不會出問題，因為沒有歷史資料干擾。

會員登入結帳就複雜多了。WooCommerce 會把會員上一次用的地址帶進來預填，下拉應該要自動預選那個縣市與區。問題是，如果你的站以前沒有結構化地址，會員資料表裡存的是自由輸入時代的舊值—可能是「台北市」，可能是「taipei」，可能是某個連你自己都看不懂的拼法。這些舊值會在會員結帳時被帶出來，跟新的下拉邏輯對不上，輕則下拉預選不到正確的值、客人要手動重選，重則連動直接卡住、區欄位空白。

這裡有一個很容易被低估的坑：你裝好下拉、測完訪客流程、覺得一切正常，但你的老會員登入結帳時，帶入的還是髒的舊地址。所以測試的時候，一定要找一個「之前下過單的老會員帳號」實際走一次結帳，看看地址帶入的時候下拉有沒有正常預選。如果你也開放會員在「我的帳號」頁面編輯地址（多數 會員系統都會），那個地址編輯表單也要測，確認下拉在那裡的行為跟結帳頁一致。

舊髒值要不要清？我的建議是分兩步走。第一步，接受它：新進來的訂單都會走新的下拉，舊的會員資料就讓它自然被新訂單覆蓋，多數站這樣就夠了。第二步，如果你的站對地址乾淨度要求很高（例如要做精準的區域行銷、或要匯出給 ERP），那就需要寫一個一次性的資料清洗腳本，把會員資料表裡的地址標準化。這一步是進階操作，建議交給熟悉 WooCommerce 資料結構的開發者處理，不要自己硬改資料庫，改壞了會員地址是很難救回來的。

這整段的潛台詞是：下拉選單不是裝完就天下太平，它跟你站上既有的會員資料之間，有一個過渡期要處理。心裡有這個譜，裝完之後才不會被老會員的怪地址嚇到。

安裝前要先確認的三件事

很多人裝外掛的習慣是「搜尋、安裝、啟用、出問題再說」。我不建議你在結帳頁這樣玩，因為結帳頁壞掉的代價是直接掉單，而且你可能不會馬上發現。動手之前，花三分鐘把下面三件事確認掉。

1. 主題的結帳頁範本有沒有被改過

有些 WooCommerce 佈景主題會自帶結帳頁範本，或是你曾經請人客製過 checkout template。如果主題用自己的方式渲染 billing_country、billing_state、billing_city 這幾個欄位，RY WC City Select 的下拉連動可能會接不上。檢查的方法是到外觀 → 佈景主題檔案編輯器，看你的子主題底下有沒有 woocommerce/checkout/form-checkout.php 這類被複製過的範本。有，就先備份，安裝後優先在這個範本上測試。

2. 有沒有已經在改結帳欄位的外掛

RY WC City Select 處理的是國家 / 州 / 城市這三層的「類型與選項」。如果你同時裝了 Checkout Field Editor，或更廣義的 結帳表單客製化 外掛，而且你已經把 billing_city 改成 select，兩邊會搶同一個欄位。最乾淨的做法是讓 RY WC City Select 全權負責國家 / 州 / 城市這三層，其他外掛只管「新增、刪除、排序」那些非地址欄位。搶欄位是這類設定最常見的踩雷點，先理清楚責任歸屬，後面會省很多事。

3. 備份，包含資料庫

這不是廢話。外掛啟用時會寫入選項資料表，停用時不一定完全清乾淨。裝之前用 UpdraftPlus 或你慣用的備份工具跑一次完整備份，包含資料庫。萬一設定跑掉，你有一個確定能還原的點。這個動作花你兩分鐘，但它是你能放心實驗的前提。

一步步安裝與啟用：讓城市清單出現在結帳頁

前置檢查做完，安裝本身很直覺。如果你完全沒裝過外掛，WordPress 外掛安裝的三種方法我這裡不重複，只講這支外掛實際會遇到的狀況。

1. 從後台搜尋安裝：外掛 → 安裝外掛，搜尋「RY WC City Select」。找到作者是 RY 的那一支，安裝並啟用。如果你搜不到（有時候 WordPress.org 的搜尋很鈍），可以直接到 wordpress.org 外掛頁面下載 zip，再用上傳的方式安裝。
2. 啟用後先別急著開結帳頁：啟用後這支外掛會在 WooCommerce → 設定裡多出一個分頁，或是整合進「一般 / 運送選項」的相關區塊（位置會隨版本調整，以你後台實際看到的為準）。先把這個設定頁整個看過一次，知道它管哪些東西。
3. 確認預設國家設成台灣：WooCommerce → 設定 → 一般，「預設顧客位置」與「預設國家」設成台灣。這一步很關鍵，因為外掛會根據預設國家載入對應的城市清單。預設國家設錯，你會看到一堆跟台灣無關的選項。
4. 開無痕視窗測結帳頁：一定要用無痕或登出狀態測試，因為登入狀態下 WooCommerce 會帶入你自己的地址，看不到客人真實的輸入流程。確認縣市欄位變成下拉、而且選了某個縣市之後，下一欄的鄉鎮市區會跟著連動。

到這一步，外掛本身已經跑起來了。但「跑起來」不等於「正確」，接下來的中文化與地區清單才是重點。

中文縣市與鄉鎮市區清單的正確設定

這一節是整篇最核心、也最容易出錯的地方。台灣的地址結構有四層：縣市、鄉鎮市區、路段、門牌。WooCommerce 的 billing_state 在台灣被對應成「州」，而 RY WC City Select 把 billing_city 做成連動的縣市 / 鄉鎮市區兩層。你要確認的是，這些清單裡的字串，跟你後面要串接的物流系統一致。

台灣的 22 個縣市要齊全

台灣目前有 22 個行政區（直轄市 6 個、省轄市 3 個、縣 13 個）。外掛內建清單理論上會涵蓋全部，但你要實際點開下拉一個一個核對，不能假設。實務上曾發生過清單少了一個離島縣的情況（不是這支外掛，是另一支），結果那個縣的客人直接無法結帳。核對的方式很笨但最可靠：把 22 個縣市名稱列在旁邊，對著下拉一個一個勾。

注意「台」與「臺」的寫法

這是台灣地址系統裡最經典的地雷。官方文書用「臺」，但民間與多數物流系統用「台」。兩者在資料庫裡是不同的字串。你要確認的是：外掛清單用的寫法，跟你串接的物流外掛（例如 綠界 ECPay）期望的寫法一致。不一致的話，訂單會成立、下拉會過，但物流 API 在後台會回傳格式錯誤，然後卡在出貨流程裡，客人那邊看起來一切正常，你這邊根本不知道卡住了。

鄉鎮市區的連動要驗證

選了新北市之後，下一欄應該出現新北市底下的 29 個區，從板橋、三重一路到萬里、烏來。你要每個都點嗎？不用，但你至少要抽幾個縣市、各選一兩個區，確認連動真的生效；萬一整包鄉鎮全部塞在同一層給你選，就代表連動根本沒接上。連動沒生效的話，問題通常出在主題的結帳範本覆寫掉了前端 JavaScript，這時候就要回頭檢查前面提到的範本被複製的問題。

用 Loco Translate 把顯示文字中文化

外掛的欄位標籤、placeholder、錯誤訊息可能還是英文。與其在主題的 functions.php 裡硬改文字字串，不如用 Loco Translate 建立這支外掛的翻譯集，把「City」「District」「Select a city」這類字串一次中文化。用翻譯工具的好處是外掛更新時你的翻譯不會被覆蓋，而且集中管理，未來要改文案只要回來改一個地方。

串接綠界與超商物流時要驗證的六個欄位

如果你站上同時跑綠界金物流，整體的金流物流設定又是另一條主線，這裡只聚焦一件事：RY WC City Select 設好之後，跟物流外掛之間還有一道驗證要做。綠界的物流 API 對地址格式有明確要求，以下六個欄位是我會逐項檢查的清單。

欄位	綠界期望格式	檢查重點
收件人縣市	中文縣市全名，如「新北市」	下拉值不可帶空白或英文，不可是「Taipei City」
收件人鄉鎮市區	中文區名，如「板橋區」	連動後的值要跟縣市對得起來，不可張冠李戴
收件人地址	門牌段號，不可含縣市區	客人常把縣市區一起填進地址欄，要在表單提示中分開
超商門市名稱	超商取貨專用，由選店流程帶入	確認超商取貨的門市變數沒有被地址下拉覆蓋
手機號碼	09 開頭 10 碼	物流簡訊通知要用，格式錯會收不到取貨通知
買家備註	純文字	不可把地址資訊塞進備註欄，會干擾出貨單

這張表的重點不是欄位本身，而是「下拉選單改了之後，要回頭確認這些欄位的值還能被下游系統正確讀取」。地址是結帳資料的源頭，源頭一改，下游全部要驗證一遍。正因如此，我前面特別強調「台 / 臺」的寫法，因為綠界那邊只認其中一種，另一種會被當成格式錯誤。

如果你同時用 運費規則依區域計費（例如離島加收運費、本島免運），改完下拉之後也要回頭測一遍不同縣市的運費是不是正確觸發。下拉值變乾淨之後，運費規則的命中率通常會上升，因為之前那些「台」「臺」混用的訂單，根本對不上你設的區域條件。

行動版下拉選單的體驗調校

行動版的結帳頁是現在的主戰場，不是順便處理的項目。根據 Statista 的追蹤（2026 年 4 月），全球的網站流量裡，行動裝置長期佔了過半的比例，電商結帳這個環節尤其明顯，很多人是通勤、午休、躺在床上滑手機時衝動下單的。在這個情境下，下拉選單的好壞直接決定這一單成不成。

select 與 selectWOO 的差別

WooCommerce 預設用一個叫 selectWOO 的 JavaScript 函式庫來渲染下拉，它的目的是讓原生 select 在各種瀏覽器上行為一致、而且可搜尋。RY WC City Select 在多數版本裡會沿用這個機制，所以你的縣市下拉在桌機上會看到一個可搜尋的框。這在縣市數量多的時候很好用，但行動版上要特別注意：selectWOO 有時候會跟主題的 JavaScript 衝突，導致下拉點不開、或開了之後位置跑掉。測試的時候一定要在實機（或瀏覽器開發者工具的行動模式）上點一遍，不能只在桌機上看。

下拉框的觸控大小

原生 select 在手機上會叫出系統的選擇器，觸控體驗通常沒問題。但 selectWOO 這種自訂下拉，如果主題的 CSS 沒處理好，選項之間的間距會太窄，手指點下去容易誤觸隔壁的區。這時候要回到 CSS box model 的基本功，調 padding 與 line-height，確保每個選項的觸控區至少有 44px 高（這是無障礙規範裡常見的最低標）。如果你對 CSS 還不熟，CSS 入門的觀念在這裡會直接派上用場。

結帳頁的整體載入速度

速度是行動版結帳的另一個隱形殺手。根據 web.dev 的說明，每一秒的延遲都在趕走客人。RY WC City Select 本身很輕，但它載入的 jQuery 與 selectWOO 是額外的腳本，如果你的結帳頁同時跑了一堆追蹤碼、彈窗、A/B 測試工具，這些腳本會疊加。改完下拉之後，順手用 PageSpeed Insights 跑一次結帳頁，確認沒有因為這支外掛把分數拉掉。如果發現腳本阻塞，可以參考我們寫的 網站快取指南，把結帳頁的資源載入順序調整一遍。結帳頁通常不適合做激進的快取（因為它有動態內容），但 JS 的延遲載入、關鍵 CSS 的內聯，這些手法是安全且有效的。

如果你用的是 Elementor 這類頁面編輯器來做結帳頁的視覺，RWD 電商設計的考量也要一併照顧到，下拉框在不同螢幕寬度下的寬度、斷行行為，都會影響客人的填寫節奏。

五個最常踩到的錯誤與修法

這張表是實務上最常被回報的五個狀況。你可以把它當成問題發生時的第一份檢查表，照著走通常能解掉八成的狀況。

症狀	最可能的原因	修法
縣市欄位還是文字輸入框，沒變下拉	另一支結帳外掛搶走了欄位控制權	暫時停用其他會改 billing_city 的外掛，逐一開回來找出衝突源，讓 RY 全權負責
下拉出現了，但選項是英文或亂碼	預設國家沒設成台灣，或語言檔沒載入	WooCommerce 設定把預設國家設回台灣，用 Loco Translate 補齊繁中語系
選了縣市，鄉鎮欄位沒有連動	主題的結帳範本或快取外掛把前端 JS 擋掉了	把結帳頁排除在頁面快取之外，檢查主題是否有複製 checkout 範本
訂單成立但綠界物流回傳地址格式錯誤	下拉值的寫法（台 / 臺、是否帶空白）跟物流 API 不一致	核對外掛清單字串與綠界文件期望的字串，統一成同一種寫法
離島或特定縣市的客人無法結帳	清單漏了那個縣，或那個縣被錯誤地排除	逐一核對 22 個縣市是否齊全，補上缺漏的項目

這張表的邏輯是：症狀是表象，原因通常出在「欄位控制權」「語言與清單」「前端腳本」「字串一致性」這四個層面。下次遇到沒列在上面的狀況，順著這四個層面往下想，多半能找到方向。

設定完成後，怎麼知道真的有效

改完一個東西卻不量測，等於沒改。下拉選單裝好之後，我會盯三個指標，給你做參考。

第一個是結帳完成率。在改之前先記下你目前的結帳轉換率（加入購物車到完成訂單的比例），改完之後兩到四週再比一次。這個數字會受到太多因素干擾（季節、促銷、流量來源），所以不要期待它直線上升，但它不應該往下掉。如果改完之後完成率反而變低，通常是行動版的下拉出了問題，回去看前一段的觸控與 selectWOO 檢查。

第二個是退件率與客服工單。這是我最在意的指標。地址打錯造成的退件、客人主動反映「我地址填錯了能不能改」的訊息數量，改完之後應該要往下走。這個指標的好處是它直接對應成本，每一筆減少的退件都是實實在在省下來的運費與客服時間。如果你有用 訂單 LINE 通知，客服那邊收到的「地址問題」訊息頻率會是一個很直覺的觀察點。

第三個是結帳頁的平均填寫時間。下拉比打字快，這個改變應該反映在客人從進結帳頁到按下完成訂單的時間。時間變短，代表摩擦力降低了。這個指標可以用 GA4 的事件追蹤或結帳外掛自帶的分析來看，數字不需要很精確，看趨勢就夠。

這三個指標的共同特色是：它們看的是「方向」而不是「絕對數字」。我不會給你一個「改完一定會提升 X%」的承諾，因為那不誠實。但如果你改完之後這三個指標都沒有往好的方向走，那就代表問題不在下拉選單本身，而是在更上層的結帳流程設計，那會是另一個要拆的題目。

三個我會勸你不要踩的設定地雷

看完該怎麼做，反向也要講一下不要做什麼。這三個是實務上最常見、後果也最麻煩的錯誤設定，一開始就避開，比之後補救省事太多。

第一個，不要在結帳頁同時跑兩支會搶 billing_city 的外掛。我前面提過欄位控制權的問題，這裡再強調一次，因為它真的是第一名的原因。常見的組合是：你原本用 Checkout Field Editor 把 city 改成了 select，後來聽說 RY WC City Select 更好用，就直接裝上去、沒停用原來的設定。兩支外掛都在 hook 同一個欄位，結果是下拉時而出現、時而消失，或選項變成兩份清單混在一起。這種間歇性問題最折磨人，因為它有時候正常、有時候不正常，你很難穩定重現。原則很簡單：同一個欄位，只讓一支外掛負責。

第二個，不要為了省事，把綠界的縣市格式跟下拉的格式分開維護。有些人會想「下拉我用外掛預設的清單就好，綠界那邊出錯再說」，這是把責任推給未來的自己。正確的做法是一次性把兩邊的格式對齊：把下拉清單的字串，跟綠界物流 API 文件裡列的合法值，逐字核對一遍，確認是一致的。這個動作只做一次，但它決定了之後每一筆訂單能不能順利出貨。分開維護的代價，是你每個月都要處理幾張莫名卡住的訂單，而且很難追溯到是字串不一致造成的。

第三個，不要在沒備份的狀況下，直接對會員地址資料表做大量更新。我在前面提過舊髒值的清洗，這裡要補一個警告：地址資料表是會員信任的基礎，客人存的地址被改錯，他下次結帳會帶入錯誤地址，直接出貨到錯的地方。任何對會員地址的批次更新，都要先在測試環境跑、先備份、先小量驗證。如果你沒有測試環境，至少先匯出一份完整的會員地址備份，再動手。這不是膽小，這是對客人資料的基本尊重。

這三個地雷的共同點是：它們都是「省了當下的麻煩，卻把更大的麻煩延後」。結帳頁是收銀台，收銀台不適合走捷徑。

把這件事放進你更大的結帳優化藍圖

縣市下拉選單不是一個孤立的設定，它是結帳流程優化裡的一塊拼圖。把它裝好之後，你可以順著這條線往兩個方向延伸。

往「欄位精簡」的方向：把結帳表單上不必要的欄位砍掉、把可以合併的欄位合併，讓客人面對的填寫項目越少越好。這部分可以搭配結帳表單客製化的整體策略，把欄位的順序、必填與否、預設值都重新想一遍。一個乾淨的結帳表單，效果不亞於任何轉換率優化工具。

往「配套功能」的方向：地址乾淨了之後，很多本來做不到的自動化變得可行。依縣市不同的 動態定價、離島加運費的運費規則、特定區域的 優惠券限制，這些過去因為地址欄位不可靠而無法精準觸發的功能，現在都有了運作的基礎。地址是地基，地基穩了，上面的樓才蓋得起來。

如果你正在從零架一個 WooCommerce 站，這件事最好在建站階段就做好，等訂單量大了再回頭改會事倍功半。一開始就把地址結構化，後面所有跟地區有關的功能都不需要重來。也因此，我們在 WooCommerce 完整教學裡，會把結帳欄位的結構化列為必做的基礎設定之一。

清單不是設一次就永遠不用管：長期維護的觀念

很多人以為縣市清單裝好就一勞永逸，但台灣的行政區不是永遠不動的。歷史上有過幾次大的改制，例如桃園在 2014 年從縣升格為直轄市，這類變動雖然不頻繁，但一旦發生，你的清單跟官方格式就會出現落差。更常見的其實是另一種變動：外掛作者調整了清單裡的字串寫法（例如統一把「台」改成「臺」，或反過來），這種調整一旦發生，你跟物流 API 之間好不容易對齊的字串一致性就破功了。

所以我把「核對縣市清單」當成一年一度的例行工作，裝完就忘記是最危險的做法。每年挑一個固定的時間（例如會計年度結束、或站慶前後），照著以下幾件事走一遍：

• 核對 22 個縣市：照著內政部的最新行政區清單，把下拉裡的縣市逐一勾一遍，確認沒有缺漏、也沒有被改成奇怪的寫法。
• 抽查連動：每個直轄市各選一兩個區，確認鄉鎮市區的連動還正常，沒有因為外掛或主題更新而失效。
• 對一次物流 API 的字串：把下拉的值跟你綠界（或其他物流）後台期望的格式對一次，確認「台 / 臺」、有無空白、有無英文，這些細節還一致。
• 檢查翻譯：如果你用 Loco Translate 改過顯示文字，更新外掛後要回去看翻譯是不是還對得上新的字串。

這個年度檢查花你大概半個小時，但它能避免一種最冤枉的事：外掛默默更新、字串默默改了、訂單默默卡在物流、你兩個月後才發現。地址是地基，地基偶爾要回頭看一眼有沒有裂縫，這不是過度謹慎，這是基本的營運紀律。

外掛本身的更新也要納入管理。RY WC City Select 跟其他 WordPress 外掛一樣會發新版本，更新前先備份、更新後跑一次完整的結帳測試（訪客加會員兩種情境都走一遍）。如果你有設定 快取外掛或 WP Rocket 這類工具，更新後記得清一次快取，因為舊的 JS 有時候會被快取住，讓你以為連動壞了，其實只是瀏覽器抓到舊檔。

收尾：地址欄位是轉換率的最後一哩

結帳頁是一個網站的收銀台，而地址欄位是收銀台裡最不起眼、卻最容易漏單的一格。把它從自由輸入換成結構化的下拉選單，投入的時間不多，但它影響的是退件、客服、物流串接、運費規則這一整條鏈。這不是一個會讓你流量暴增的設定，但它會讓你已經帶進來的流量，更扎實地轉成已經送到客人手上的訂單。

如果你只想做一件事，那就做這件：今天就去打開你的結帳頁，用客人的身分走一遍結帳流程，看看那個縣市欄位是輸入框還是下拉。如果是輸入框，照著這篇的步驟，把它換掉。一個禮拜之後，回來看你的退件數字。

我們在 Whoops 處理過不少 WooCommerce 站的結帳優化，從欄位結構、金物流串接到轉換率提升，如果你卡在某個環節不知道怎麼往下走，這是我們能幫上忙的地方。把這篇當成你自己動手的第一份指南，需要更多人一起看著全局來調的時候，再把我們叫進來。卡關了，Whoops 隨時能陪你把結帳這一哩走順。