我們如何打造多語系 AI 工具目錄

目錄在每種語言中都需要一致的身分識別

AI 工具目錄有兩項彼此相關的任務：協助使用者找到實用的軟體，並為每筆收錄資料提供穩定的身分識別。增加語言會同時擴大這兩項工作的範圍。翻譯後的介面看起來可能已經完整，但底層頁面對於哪個 URL 代表某個項目、某種譯文是否存在，以及搜尋引擎應考慮哪個版本，仍可能提供不一致的資訊。

Toolso 是一個多語系 AI 工具探索與發佈平台。本文以原始碼檢視，以及 2026 年 10 月 26 日對少量線上頁面的檢查為基礎，說明 Toolso 的語言路由、canonical URL、替代語言標註與 sitemap 項目如何搭配運作。本文不衡量排名提升，也不假設每筆收錄資料都在所有已設定的語言中具有內容。

一個實用的起點是這個簡單的問題：當同一個工具以多種語言呈現時，應用程式的每個部分能否一致地描述這些版本？這個問題將內容營運與技術 SEO 連結起來。翻譯不只是多一個選單選項；它需要彼此一致的內容、路由與中繼資料。

圖 1。英文首頁介面。截圖提供日期：2026 年 10 月 26 日。

1. 區分語言路由與語言識別碼

目前設定定義了十種語系：英語、簡體中文、繁體中文、韓語、日語、法語、德語、俄語、西班牙語和葡萄牙語。英語為預設語言。路由設定視需要使用語言前綴，因此預設語言不需要 /en 前綴，其他語系則使用前綴。

以一筆實際資料為例，Raphael AI 收錄頁面的英文路徑為 /tool/raphael，簡體中文路徑為 /zh/tool/raphael。我們於 2026 年 10 月 26 日檢查了這兩個頁面。頁面呈現後的 canonical URL 分別指向各自的語言版本。

內部路由鍵與提供給搜尋引擎的語言識別碼是分開的。在目前設定中，zh 對應到 zh-CN，tw 對應到 zh-TW，es 對應到 es-ES，pt 對應到 pt-BR。簡短的內部鍵方便路由處理，但不應在未加區分的情況下成為含義不同的語言標註。

路由器也停用了自動語系偵測，讓請求路徑中所編碼的語言具有明確含義。這不能證明在地化已完成：導覽翻譯、收錄內容翻譯，以及中繼資料是否正確，仍須分別檢查。

圖 2。Toolso 上的 Raphael AI 詳細頁。截圖於 2026 年 10 月 26 日提供，呈現產品介面，並不代表頁面的語言標註已通過驗證。

2. 統一建立 URL 身分識別

當頁面中繼資料與 sitemap 產生邏輯各自建立網址時，細微的 URL 差異可能持續擴散。一個元件可能省略預設語系，另一個卻將其加上；一個可能保留網域根路徑結尾的斜線，另一個卻將其移除。每個元件單獨來看都可能合理，但合併後的輸出卻不一致。

Toolso 的 canonical、hreflang 與 sitemap 輔助函式共用一個絕對 URL 建構函式。它將在地化路徑的產生交由同一套路由邏輯處理，並套用一致的根路徑正規化規則。在這項實作中，預設首頁 URL 會正規化為不含結尾斜線的形式。這是我們為了保持一致所採用的慣例，並不表示每個網站都必須採用這種寫法。

中繼資料輔助函式也支援為分頁 URL 傳入查詢參數值。提供這個選項時，同一個查詢參數會加入 canonical 與替代語言連結。如此一來，呼叫端便能讓第二頁與其他語言的第二頁建立關聯，避免誤連到第一頁。每個呼叫位置仍須檢視；輔助函式具備某項能力，不能證明每條路由都正確使用它。

canonical 標註用來表達偏好的 URL，但無法保證 Google 最後會選用該 URL。Google 的標準網址指南說明了這項差異。

3. 由實際譯文決定語言連結群組

應用程式支援十種語系，不代表每個工具都已完成十種語言的介紹。若將兩者視為同一件事，語言標註就會承諾超出實際內容的範圍。

我們的語言連結輔助函式可接收一組可用語系。呼叫端提供這個集合時，輔助函式只會為其中的語系產生替代連結。只有預設語言版本也在可用集合內時，才會加入指向該版本的 x-default 替代連結。若省略集合，就會宣告所有已設定的語系，因此呼叫位置有責任準確傳入內容的可用狀態。

路由設定停用了 next-intl 自動輸出的替代語言 HTTP Link。實作改為透過頁面中繼資料與 sitemap 輔助函式產生經過對應的語言標註，避免在明確的語言對應之外，還得維護另一組依原始路由鍵自動產生的標註。

部署後仍須檢查結果。在 Raphael 樣本中，英文與簡體中文頁面都宣告了相同的十個替代語言連結及 x-default，其中包含連回對方頁面的連結。這驗證的是該樣本呈現後的標註，無法驗證翻譯品質或搜尋索引收錄情形。Google 的在地化網頁說明文件解釋了語言代碼、回連，以及 x-default 的備援角色。

4. 將 sitemap 視為依內容產生的清單

sitemap 產生器很容易列出所有可能的語言 URL。更有用的清單應反映哪些內容實際符合列入條件。

Toolso 的 sitemap 產生器在查詢工具資料時會篩選已發佈的工具，並依照具有可用名稱與有效描述內容的紀錄，另行建立可用譯文集合。這些翻譯紀錄以游標分批讀取；產生器只保留組合 URL 所需的語系資訊，不會將每筆描述都累積在記憶體中。

接著，工具詳細頁項目只會針對可用語系產生。部落格文章詳細頁項目也會依每篇文章的語系集合進行篩選。兩者都使用共用的 URL 輔助函式產生 sitemap 網址與替代語言連結。因此，僅在資料庫中設定了某種語言，本身並不足以產生詳細頁項目。

修改日期也需要謹慎處理。工具詳細頁項目使用以內容更新為導向的 seoUpdatedAt 欄位，部落格項目則使用對應的內容更新日期或發佈日期。目的是反映有意義的內容變更，避免每次瀏覽次數更新都被視為一次新的編輯修訂。

這不能證明每個產生的項目目前在正式環境中都運作正常。提交 sitemap 本身也只是一項提示；Google 的 sitemap 指南並不保證檢索或建立索引。

5. 將備援內容設為明確狀態

缺少譯文需要有處理政策。否則，同一段原始語言的描述可能出現在多個語言 URL 下，網站卻將它們呈現為已完成的譯文。

工具詳細頁的中繼資料包含明確的翻譯備援分支。提供備援內容時，它會將頁面標記為 noindex，讓 canonical 指向英文工具版本，並在該回應中停用替代語言連結群組。翻譯資料暫時無法使用或缺少的情況另有處理方式，不應被描述成已成功翻譯的頁面。

部落格詳細頁的實作採用類似政策：備援時會指向文章的原始語言版本、停用替代語言連結，並使用 noindex。已封存的部落格內容也會標記為 noindex。這些是本專案在編輯與技術上的具體決策，並不是建議每個多語系網站都採用完全相同的規則。

實際上需要區分的是介面翻譯與內容翻譯。訪客可能仍需要存取備援內容，但搜尋中繼資料不應將其呈現為獨立且已完成的語言版本。sitemap 對內容可用狀態的篩選必須與詳細頁行為保持一致。

6. 分別驗證輸出與檢視實作

閱讀輔助函式很有幫助，但訪客與檢索器收到的是最終回應。中介軟體、快取、資料可用狀態，以及已部署的版本，都可能改變結果。因此，程式碼檢視無法取代回應檢查。

儲存庫包含一支 sitemap 稽核指令碼，可檢查回應狀態、robots 指令、canonical URL，並可選擇檢查語言關係。我們檢視了這支指令碼，並檢查兩個 Raphael 頁面呈現後的中繼資料及其 sitemap 項目。這些項目使用的 canonical URL 與替代語言連結，和抽查頁面一致。我們沒有執行完整的正式環境稽核，也沒有檢查 Search Console。

三張螢幕截圖分別呈現首頁、Raphael AI 收錄頁面與提交入口畫面，記錄的是擷取當下的介面狀態。若要重做技術檢查，可比對某筆收錄資料在兩種可用語言中呈現的 canonical 與語言連結，再將這些 URL 與 sitemap 比較，並記錄 URL 和日期。缺少譯文的行為應另外測試：已完成的譯文與備援內容需要不同的斷言。

Search Console 的觀察結果應另行記錄：Google 檢索了什麼、選用哪個 canonical，以及哪些內容已建立索引。分析與轉換數據則應放在另一份紀錄中。將這些紀錄分開，可以避免把一次本機實作檢查轉述為搜尋或營收成果。

其他目錄建置者可以沿用的做法

最值得沿用的概念，是讓內容的可用狀態決定 URL 宣告。將路由鍵與語言代碼分開，讓中繼資料與 sitemap 產生流程共用 URL 建構邏輯，並為缺少的譯文定義明確狀態。接著，在對搜尋成效提出主張之前，先比對這些設計意圖與實際回應。

對小型團隊來說，這也是一項營運紀律。新增語言時，應以已知的內容狀態與驗證步驟進入編輯流程。少量樣本可以揭露不一致，卻無法證明整個目錄的涵蓋情形。當路由規則或譯文可用狀態改變時，應重新檢查 URL 連結群組。

圖 3。匯入工具 URL 後的提交介面，已帶入媒體素材。截圖於 2026 年 10 月 26 日提供，畫面不代表已完成最終提交。圖中的價格與計數僅反映截圖當時的介面。

如果你正在建置多語系目錄，可以帶著這些問題探索 Toolso：每個語言頁面是否提供實用的內容？它的 URL 訊號是否準確描述了這些內容？