切換網站語言後回到首頁？檢查語系選單是否保留目前頁面
按頁型挑選測試樣本，逐語系比對網址與內容，並為缺少翻譯的頁面設定清楚回退去向，避免語言切換後失去閱讀脈絡。
語言切換看似只換一個選項，真正要核對的是：訪客換語言後，是否仍能讀到對應的那一頁；若該語系沒有版本，網站又會帶他去哪裡。以下用逐頁操作與明確回退規則，把「切換後回首頁」拆成可重做、可判斷的檢查流程。測試時先確認頁面對照，再評估目的地是否合理。不必先檢查所有網址，先從能重現的內容頁開始，逐步確認頁面配對與例外。
挑選多語內容頁
先挑五到十個有代表性的多語內容頁，不要從整站隨機點。至少選一篇文章、一個服務或產品說明、一個常見問題頁，以及一個可能沒有完整翻譯的頁面；若網站有分類頁、表單或活動頁，也要納入其不同版型。這樣能看出切換器是否只在文章模板正常，卻在其他頁型意外送回首頁。先記錄每頁目前語言、頁名、瀏覽器網址和預期的其他語系網址，從訪客角度逐頁開啟，不要只看後台的翻譯完成標記。把首頁當成控制組，另挑一篇可在兩種語言都找到的文章當配對組，兩者用途不同：首頁確認語言入口存在，內容頁確認頁面身分能被保留。若頁面有追蹤參數或錨點，先另存原始網址；測試時可同時記下切換前後的路徑、查詢參數與頁面標題。不要只挑最完整、最熱門的內容，應加入新舊頁面和不同編輯來源，避免樣本剛好都走同一條模板。最後用一張清單排定測試順序，標註哪幾頁已知有翻譯、哪幾頁仍待確認；資訊不足的頁面先列為待查，不推定它應該存在。這份清單是逐路徑核對的範圍，後續才能判斷問題集中在哪種頁型或特定內容。抽樣最好按訪客任務分類，而不是只按網址數量：找資訊、比較方案、完成聯絡，各挑一個常走入口，並確認它們在每個語系都有可辨認的配對。若同一篇內容有舊版、更新版或多個分類入口，記下你實際進入的來源，避免把不同內容誤配成翻譯。對文章清單、搜尋結果和站內推薦帶進來的頁面也留一筆，因為訪客不一定從首頁開始。
逐個切換語系
在每個樣本頁先記錄原始語系與網址，再從頁首、頁尾或行動版導覽找到語系切換入口，逐一選擇可用語言。每次只改一個變因：先不要同時登入、清除 Cookie、改網址或開多個分頁，否則出現首頁時難以知道是哪個動作造成。切換後先停一下，等頁面完全載入，再查看網址、標題和主要內容是否仍屬於原頁；不要因為導覽列換了語言，就判定任務成功。若切換器會開新分頁，回到原分頁確認它沒有被導回首頁；若選項需要展開，檢查鍵盤操作與觸控操作都能選到，而不是只有滑鼠懸停才出現。每次測完回到原始內容頁，重新執行下一種語言，不要沿著前次結果繼續點，避免測到不同的頁面或瀏覽器狀態。建議以表格記錄「原頁、選擇語系、落地頁、結果、截圖或備註」，並把成功定義為落在對應內容、語言有改變、主要內容標題吻合。首頁也許是可接受落點，但只有在原內容確實沒有譯文且回退規則明確時才如此。每個結果用通過、回退、錯誤三類標記；不確定原因就保留網址與畫面，先不要把失敗歸咎於翻譯缺漏。為了讓結果可比較，固定瀏覽器視窗大小與頁面縮放，並在同一次瀏覽器工作階段完成該輪。若頁面看似沒有反應，先確認載入指示是否結束、按鈕是否真的被觸發，再以重新載入後的同一來源重做一次；不要連續快速切換多個語言，避免前一次導覽尚未完成就被後一次覆蓋。若系統記住上次語言，記下它是否改變下一頁的起始語系，因為偏好記憶與目前頁面配對是兩個不同問題。
核對對應頁面路徑
逐頁比較切換前後網址，不要只對照網址開頭。語系前綴改變後，文章、分類或產品代碼等其餘路徑應指向同一份內容的目標語系版本；若頁面使用不同語系 slug，就以網站實際對照資料確認，而非假設英文標題可以直接翻譯成路徑。可在試算表放四欄：原始網址、目標語系、預期網址、實際落點，讓錯誤能被重現。比對時檢查大小寫、結尾斜線、網址編碼和必要參數；分享連結或搜尋結果若帶有查詢參數，確認切換後哪些參數應保留、哪些會妨礙路由。不要手動改寫實際網址來代替測試選單，因為這只能證明目標網址可開啟，無法證明語系選單知道目前頁面對應到哪裡。若同一文章在不同語言採不同 slug，應確認映射關係已經指定，並檢查對應是否唯一；一個來源指向兩個目標時，訪客可能依語系或裝置收到不同結果。對於會重新導向的網址，記錄最終落地網址，而不只記第一個回應位置。以下為假設示例，路徑僅用來說明核對方法，不代表任何網站的實際網址：原頁 /zh-tw/blog/example，預期英文頁 /en/blog/example，若切換後落在 /en/，就記為路徑映射待查，而不是判斷翻譯必定不存在。最後選兩頁交叉複測，確認問題可再現，而不是暫時性載入狀況。檢查連結時可先比對內容識別，而不是要求字串完全相同；不同語系可能有本地化網址，但標題、主題和頁面角色仍需相符。若找不到預期網址，搜尋站內同一篇內容並核對它在目標語系是否有可公開存取的頁面；搜尋結果存在不等於切換器能找到它。也請分辨 404、重新導向與權限頁，將回應結果和最終畫面一起留下。
標記缺少翻譯頁
遇到目標語系沒有同一份內容時，不要讓選單悄悄回到首頁，因為訪客會以為剛才看的文章已經消失。先請內容負責人確認是「尚未翻譯」、「不提供此語言」還是「頁面已下架」；這三種狀況的去向可能不同。把判斷結果記在路徑表，並指定一個可理解的落點，例如留在原語系頁面、顯示缺少版本的提示，或帶到該語系中最接近的上層分類。只有在內容確實沒有翻譯時，才把回退視為預期結果；若對應頁本來存在，就應回到路徑映射查找原因。避免把所有缺頁都送首頁，也不要以相似關鍵字自動猜一篇文章替代，因為使用者原本的閱讀目的可能因此中斷。若改到分類頁或上層頁，要讓畫面清楚說明目前語言版本未提供，並保留一個返回原文的選擇；若產品或服務細節依語系不同，也應把「可閱讀的替代內容」交由內容負責人確認，不可由測試者自行杜撰翻譯。測試紀錄可加上缺譯原因、核准者角色、選定落點和提示文字，不必記私人資料。這樣後續維護者能區分刻意缺譯與設定漏接，訪客也不會把正常回退誤認成連結故障。缺少翻譯也可能只缺一部分，例如標題已翻、內文仍是原文，或按鈕與表單未完成；因此不能只依頁面是否能開啟判定完整。先與負責內容的人訂一條可操作界線，例如哪些頁型一定要有對應版本、哪些允許沿用原文，並將例外明列。訪客切換時可讓選單保留目前頁面或提示可用版本，但提示要能說明下一步，不只寫「找不到」。不要在測試紀錄存放任何填寫欄位中的聯絡方式或私人內容。
測試回退目的地
把回退目的地當成一項可測試的規則，而不是遇到錯誤才臨時決定。可先為每種缺頁情況寫下預期：有同內容譯本就到配對頁；確認沒有譯本時留在原文、顯示說明或到相關分類；頁面已下架則到明確的替代內容或站內搜尋。接著在乾淨分頁與一般瀏覽狀態各試一次，檢查語系選單和直接存取失效路徑會不會各自採用不同目的地；如果結果不同，列為兩個流程追查，不要把其中一種當成普遍行為。核對落點是否保留使用者仍需要的線索，例如文章標題、所在分類、原文入口或搜尋條件；同時確認沒有把訪客帶到另一語言的未相關頁面。若回退由規則或設定控制，測試一個已確認的缺譯頁和一個已存在的譯頁，確保規則只影響適用的頁面。任何臨時首頁回退都應標為待決策，不能只因首頁永遠有效就把它視為良好體驗。可以用「預期→實際→差異→負責人」記錄：例如預期保留原文並顯示提示，實際落在首頁，差異是頁面脈絡消失，負責人再決定修正映射或補上明確提示。測完後整理通過條件，讓接手者能重做相同操作；切換成功、缺譯回退合理、非預期落首頁各自有明確判準，才不會只留下「看起來怪怪的」描述。若沒有單一標準答案，先讓負責內容的人在幾種可理解落點中選定一種，並在同類頁面一致套用；例外要按頁面列出，免得編輯者臨時挑選。接著檢查返回上一頁、重整和貼上目標語系網址三種動作，確認它們不會把訪客帶進重複跳轉或又送回原本起點。記錄規則的適用條件與最後確認人，日後新增語系時就能沿用相同判斷。
整理裝置與結果
完成桌面測試後，至少再用一種窄螢幕尺寸操作語系選單，因為手機導覽可能收進漢堡選單，觸控區、展開方式和頁面重新載入時機也可能不同。若可使用不同瀏覽器，再挑一個複測；但先保持同一內容與同一語系，避免一次改裝置、瀏覽器和登入狀態。測試前記錄裝置類型、瀏覽器、原頁網址和時間；測試後保存實際網址、落地頁標題、結果分類與必要截圖，並遮住個人帳戶資訊。不要只記「手機有問題」，要寫出例如「某內容頁切換至英文後落在英文首頁，桌面同路徑則保留文章」這種能重現的現象。整理時把故障按影響分組：所有頁都回首頁，優先查通用選單傳遞目前路徑的方式；只有特定版型失敗，查該版型的語系對照；僅缺少譯文時發生，檢查預先選定的回退規則。這些是排查順序，不代表先行判定原因。報告附上樣本總數、通過數、缺譯回退數、待查數，以及每項的重現步驟，沒有覆蓋的語言或裝置要明確標未測。交付前由另一位維護者照紀錄重做最容易出錯的一條路徑，核對修正後回到內容頁或既定回退目的地；若仍失敗，保留原始紀錄再修，不要把截圖更新當成修復證據。遇到跨裝置差異時，先比對兩邊起始網址是否相同，再確認是否登入、瀏覽器是否保留先前選擇，以及選單是否在導覽後被遮住。這些資訊能協助維護者把問題交給正確負責人，也降低只用單一截圖討論的來回。下一步列出常訪內容頁，實測一條完整路徑；若也在整理工作流程或網站，前往ZhenheAI 官網了解網站與 AI／自動化整合方向。