某語系沒有這篇內容怎麼接？設計清楚的缺頁回復路徑

多語頁面沒有對應譯文時，別一律送回首頁。本文整理頁面狀態、語系選單、錯誤網址與替代入口，設計清楚且可交接的訪客回復路徑。

多語網站新增語系或文章時，常遇到某個網址已有中文內容，卻沒有對應譯文。若直接送回首頁，訪客可能不知道內容是暫缺、網址打錯，還是本站根本沒有這項資訊。本文從盤點、狀態判斷、替代入口與實際測試，整理一條可維護的缺頁回復路徑。

盤點缺少語系頁

先從內容清單而不是瀏覽器零星回報開始。以每篇內容為一筆，記錄主語系是否仍有效、有哪些已完成譯文、哪些語系明確暫缺、最後檢查日期與負責人；再把語言選單、站內搜尋、分類頁和舊文章連結納入來源。這樣能看見缺口是單篇漏譯、整個分類尚未翻譯，還是舊連結已不再對應現行內容。盤點時不要只比文章數量，還要核對標題、主題和可到達入口，因為同一主題可能改名或合併，表面上有頁面，實際上內容已不相符。

可用一張簡單表先排優先順序： |假設頁面|主語系|英文|日文|下一步| |---|---|---|---|---| |服務流程說明|可用|可用|暫缺|提供英文或說明暫缺| |舊活動文章|已封存|無|無|確認是否保留入口|

這是示意分類，不代表任何網站現況。正式盤點可以先抽查流量入口、近期更新頁和轉換前會看的資訊，再擴至長尾文章；每頁都標「已完成、暫缺、不提供、已下架」其中一種狀態，避免把空白誤判成翻譯漏失。對大量頁面，先由內容清單產生候選，再人工確認語意與存續狀態，不要看到同 slug 就假設譯文完整。盤點時也要記錄訪客最初從哪裡進入，例如搜尋、電子報、社群分享或站內導覽，因為缺頁造成的影響會隨入口不同而改變。若清單顯示某一語系的缺口集中在高意圖說明頁，可先修復那些入口；若只是低流量舊文，先確認是否仍值得維護。這套排序讓團隊依明確條件處理，而不是按誰先抱怨決定。每次更新後再核對一筆已完成與一筆缺頁紀錄，確保表格不是舊狀態。

區分暫缺與不提供

「暫缺」和「不提供」需要不同的判斷依據。暫缺表示這個內容在其他語系仍有效，且有人負責評估或完成譯寫；應記錄預計檢查節點，但不要對訪客承諾未核准的上線日期。不提供則表示該頁在此語系沒有合適版本，例如內容只適用特定地區、政策或流程，不能單靠翻譯解決。兩者都不應由空檔案、404 狀態或翻譯工具失敗自動推定，因為技術訊號只能說明頁面目前不存在，無法代表內容決策。

實務上可依序問三件事：原文是否仍有效？目標語系是否有相同需求與適用條件？是否有明確負責人接受後續維護？若原文有效、需求存在且有人承接，列為暫缺；若適用條件不同，交由內容負責人決定是否改寫成在地版本；若原文已撤下，檢查是否有可取代的現行資訊，沒有就標記不提供或已下架。假設某服務流程僅適用一地，其他地區看到英文頁也可能造成誤解，應說明範圍並引導到通用資訊，而非照搬；如果只是排程尚未完成，就清楚標示目前可讀的語系並留下回報入口。每次狀態改變都更新清單，避免舊說明長期留在頁面上。若暫缺頁面確有排程，內部紀錄可寫負責角色與檢查日；訪客文案仍只陳述已確認的現況。若不提供的原因涉及地區差異，讓熟悉該流程的人確認說明是否容易被誤解，再決定替代入口。每次重新評估都保留原因和決策者，日後新需求出現時才知道是新狀況，或只是沿用舊決定。不要把「尚無負責人」寫成「不提供」，先指定待決策責任，避免營運空缺變成永久內容政策。

設定訪客回復選項

回復畫面先回答訪客最想知道的事：他找的內容是否存在、目前能讀哪個版本、接下來可以去哪裡。若相同文章已有其他語系版本，可提供明確的語言按鈕並標出實際語言；若暫缺，可讓訪客留在原本主題脈絡，查看該語系分類、相關文章或搜尋結果；若已下架，則說明頁面已移除，提供最近的有效內容入口。選項應依狀態出現，避免把每一種缺頁都塞進同一張通用錯誤頁，也不要暗中把人送到首頁，讓他重新猜一次。

假設訪客從日文選單開啟一篇只有繁體中文的操作說明，頁面可先簡短說明「目前沒有日文版本」，再給繁體中文版、同主題日文內容清單和回到原語系上一層三個選項。若訪客找的是按地區限定的流程，就顯示適用範圍與通用聯絡資訊，不把其他地區頁面冒充為對應譯文。主要按鈕要描述目的，例如「閱讀繁體中文版」，而不是含糊的「繼續」；次要入口可以回到原語系內容列表。只有在確實沒有可用內容時才放搜尋或首頁入口，並保留使用者剛才選擇的語系。設計前先確認頁面是否有能承接意圖的替代內容，若沒有，就坦白說明，不用不相關文章填滿畫面。頁面訊息宜短而具體，先說明目前狀態，再安排主次入口；若有多個替代方案，依和原搜尋意圖的接近程度排序。不要讓訪客必須先猜語言代碼，也不要要求他回首頁後重做剛才的搜尋。必要時提供可複製的內容名稱或回報缺譯入口，讓使用者能指出他原本要找的頁面。回報表單若不存在，就不要在文案中暗示可提交，改提供現有的分類或聯絡入口。

檢查語系選單連結

語系選單的測試重點，是確認每個選項都落在它所標示的語言內容，而不是只檢查選單能否展開。從一篇已完整翻譯的文章切換語系時，應優先帶到同一主題的對應版本；若沒有對應版本，就依站點定義前往明確標示的語系入口或缺頁說明，不能把原語系文章直接套上新語系標籤。測試也要涵蓋從分類頁、搜尋結果、頁尾選單進入的路徑，因為不同元件可能各自保留不同的網址組合規則。

可用測試矩陣逐格核對：語言名稱和目標內容一致、頁面標題與正文語言一致、缺譯時的目的地有提示、返回後仍保留可理解的脈絡。點擊每個選項後，檢查瀏覽器實際地址、頁面標題、主內容和返回行為；再直接複製該地址到新視窗，確認不是靠前一頁的狀態才顯示正確內容。若網址含有搜尋條件或頁面錨點，判斷它們在新語系是否仍有意義，無效條件應安全移除並顯示預期結果。也要測手機版的選單、鍵盤操作及螢幕閱讀器能否辨識語言名稱；按鈕文字不能只寫國旗或縮寫。發現錯配時記錄來源元件、選取語言、期待目的地和實際結果，修正共用產生規則後重測同類入口，避免只補單一頁面而留下相同故障。清單中可為每個跨語系選項標示「同頁譯文、語系首頁、缺頁說明」等預期結果，並讓不同元件共用相同判斷。抽測時包含桌機與手機，因為窄畫面常把語言選項放進另一個選單，容易暴露不同的連結設定。若目標內容尚未完成，語言選項可以仍可見，但其去向和提示須一致；若站點選擇隱藏不存在的譯文，也要確保訪客仍能找到語系導覽。

測試錯誤網址情境

錯誤網址不只包括拼錯，也包括語系代碼不受支援、內容 slug 不存在、文章已改名、尾端斜線或大小寫不同，以及語系存在但該篇沒有譯文。測試時先把情境拆開，因為它們的回復方式可能不同：可辨識的舊地址可能有明確替代內容；任意拼錯的網址通常不能猜測原意；有效文章的缺譯則應回到缺頁說明。不要把所有狀況一律轉址到首頁，否則訪客看不到錯誤原因，維護者也難以從結果判斷是哪一層出錯。

可建立一組人工案例：直接開啟有效譯文、直接開啟缺譯版本、輸入不存在的文章名稱、使用不支援的語系代碼，以及從外部書籤開啟已移除頁。每一例記下預期狀態、顯示訊息、可選下一步和實際結果。假設一篇舊文章已合併到新指南，測試要確認訪客到達的是確實涵蓋原主題的頁面，且頁面能說明內容已更新；若無法可靠判斷替代頁，就顯示找不到內容的說明與分類入口，不做猜測式跳轉。用無痕視窗測試，排除快取或登入狀態造成的假象；同時檢查返回鍵、重新整理、站內連結與搜尋引擎索引頁的行為。完成後確認頁面沒有循環跳轉、空白畫面或錯誤語言，並把重現步驟交給負責人。特別留意瀏覽器或網站常見的快取：修復後同一台裝置可能仍讀到舊結果，因此要用全新工作階段再開啟，也可比對不同入口的結果。只測畫面文字不夠，還要確認回應狀態與實際目的地符合團隊規則，避免錯誤頁看似正常、地址卻仍指向不存在的內容。將每個案例標成通過或待修，並保留可重現資訊，後續改版才知道哪些路徑需要回歸檢查。

記錄頁面處理規則

把規則記在可維護的內容清單中，至少包含內容名稱、語系狀態、適用範圍、可替代內容、回復畫面類型、決策負責人和最近檢查結果。新加入的人應能由紀錄分辨頁面是在等翻譯、此語系不提供，還是已下架，也能找到要檢查的入口。若只有程式裡不透明的預設值，編輯者可能把缺譯改成錯誤轉址；若只有表格、沒有實際測試，訪客看見的結果也可能不符決策。

新增語系、改名、合併或下架內容時，更新清單並重查受影響的語言選單、分類、搜尋結果和外部入口。由內容負責人確認語意與適用地區，網站維護者核對連結及錯誤狀態，再由另一位編輯以訪客角度走過主要情境；責任和結果都要找得到。暫缺頁若沒有明確完成日，就設定下次檢查時間，不要長期寫「即將推出」；若時間無法確認，改為描述現況。每個案例保留日期、測試語系、入口、預期和實際結果，方便下次重跑。

把「訪客看見什麼」和「內部如何修復」分成兩欄：前者是文案、入口與導向，後者是負責人、清單與檢查點。這能避免把待辦直接展示給訪客，也讓支援人員找到答案。規則更新後，抽查一筆完成案例和一筆缺譯案例，確認清單、畫面和目的地一致，並比對紀錄與畫面，確認規則已實際生效。把抽查結果回寫清單，讓後續維護者知道何時由誰核對；每次修正後重跑相關案例。先挑一篇常被跨語系分享的內容完成盤點，再用新視窗測試缺譯與返回路徑；若缺頁問題牽涉內容責任、網站維護和跨部門交接，先整理一條具體工作流程與訪客期待的下一步，再到ZhenheAI 官方網站描述流程，作為後續討論起點。