旅宿官方網站可能因預訂服務更換、頁面整理或SNS帳號變更，讓原本正確的連結不知不覺失效。如果預訂按鈕打不開，可能當場錯失正在考慮住宿的客人。
但連結失效，不只代表「出現404的連結」。即使頁面能開啟，若到了另一間旅宿或服務終止公告，對營業而言也是壞掉的動線。相反地，AI檢查顯示403時，人的瀏覽器有時卻能正常開啟。
本文說明不熟悉IT的旅宿主人，如何與Codex、Claude Code等AI一起，從不做變更的檢查開始，由人確認正式目的地，再逐項修正。
結論：依清單、檢查、判斷、修正、再確認的順序進行
安全的連結檢查分為以下5階段。
- 列出網站連結與刊登頁面
- 請AI以唯讀方式調查回應狀態與最終URL
- 依對預訂、詢問的影響排列優先順序
- 由旅宿主人確認官方目的地，只修正一項
- 再確認修改後的頁面與目的地
不要一開始就委託AI自動修正。「有錯誤就刪除」「找不到就轉向首頁」等機械處理，可能刪掉必要說明，或把客人帶到無關頁面。
最優先檢查的連結
旅宿網站先確認與營收、客人行動直接相關的連結。
| 優先 | 連結 | 應確認的內容 |
|---|---|---|
| 1 | 官方預訂、空房搜尋 | 是否到達目前簽約的預訂服務與自家旅宿頁面 |
| 1 | 詢問 | 是否顯示表單或正確聯絡方式 |
| 1 | 電話 | 智慧型手機能否撥打正確號碼 |
| 2 | 交通、地圖 | 是否顯示旅宿的正確位置 |
| 2 | 預訂網站 | 是否到達自家旅宿現行方案的刊登位置 |
| 2 | 取消規定 | 是否為說明目前條件的頁面 |
| 3 | Instagram等SNS | 是否為官方帳號個人檔案 |
| 3 | 觀光設施、交通機關 | 是否為目前仍可使用的官方說明 |
| 3 | PDF、圖片、影片 | 是否能查看檔案或影片 |
隱私權政策與依日本《特定商取引法》刊登的資訊連結，常位於頁尾，也是容易漏看的位置。
定義「連結正常」的意義
技術上收到頁面，與客人能完成目的，是兩回事。預訂連結應確認：能點擊、前往預期網域、最後顯示自家旅宿預訂頁面、不是服務終止畫面，且在智慧型手機也能找到開始預訂的位置。
詢問連結不只要看得到表單，也要由人確認旅宿名稱、收件對象、必填項目與隱私說明是否正確。日常自動檢查不提交表單，實際寄送與接收測試，應另行決定頻率及負責人。
HTTP號碼是「調查起點」
連結目的地的伺服器會針對存取，回傳稱為HTTP狀態碼的號碼。
| 狀態 | 大致意義 | 檢查時的判斷 |
|---|---|---|
| 200系列 | 取得成功 | 確認顯示內容與旅宿名稱 |
| 300系列 | 前往另一個URL | 確認最終URL與轉向次數 |
| 401・403 | 需要驗證或拒絕存取 | 也用瀏覽器確認，不立即判為連結失效 |
| 404 | 找不到頁面 | 尋找官方替代頁面 |
| 410 | 頁面永久刪除 | 考慮刪除連結或正式替代目的地 |
| 429 | 短時間存取過多 | 降低檢查頻率，隔一段時間再試 |
| 500系列 | 對方伺服器問題 | 再確認是暫時還是持續故障 |
| 逾時等 | 在期限內沒有回應 | 分辨網路、DNS、TLS或暫時故障 |
MDN的HTTP狀態碼清單將200系列分類為成功、300系列為轉向、400系列為用戶端、500系列為伺服器端回應。但200只表示「取得成功」，不保證預訂目的地正確。
即使200也可能失效的例子
即使工具回報200 OK，以下情況仍是修正候選。
- 被導回預訂服務的共用首頁，找不到自家旅宿頁面
- 顯示另一間旅宿頁面
- 只顯示「此方案已結束」
- 網域變成買賣或廣告頁面
- 無法從SNS登入畫面前往官方帳號
- 地圖指向同名或名稱相似的其他設施
- 頁面本文存在，但預訂按鈕不能運作
檢查表不只記錄HTTP號碼，也記錄最終URL、頁面標題、預期旅宿或服務名稱，以及目視確認結果。
不要認定401或403一定是連結失效
外部服務可能根據自動巡覽、地區、Cookie、JavaScript或存取次數，只拒絕AI、檢查工具的連線。預訂頁面出現403 Forbidden，不代表應立即刪除連結。
用平常的瀏覽器、智慧型手機另一個網路，或從官方網站的動線開啟，隔一段時間再確認。必要時向預訂服務客服詢問。不只讓AI「發現錯誤」，也讓它「指出誤判的可能性」。
分開網站內連結與外部連結
從WordPress文章前往另一篇文章的站內連結，若因URL變更或文章刪除而失效，可以自行修正。
預訂服務、地圖、SNS與觀光協會等外部連結，可能因對方變更而突然無法使用。但旅宿無法修復外部網站的問題，應判斷要替換為官方替代URL，還是先顯示說明文字，等待復原。
請AI建立的檢查表
以試算表或Markdown建立包含以下項目的表格。
| 刊登頁面 | 連結文字 | 設定URL | 最終URL | 狀態 | 內容確認 | 優先度 | 處理 | 確認日 |
|---|---|---|---|---|---|---|---|---|
| 客房說明 | 確認空房 | 預訂URL | 最終目的地 | 200 | 自家旅宿預訂 | 1 | 正常 | 日期 |
| 交通 | 查看地圖 | 地圖URL | 最終目的地 | 200 | 位置錯誤 | 2 | 修正候選 | 日期 |
知道連結文字與刊登頁面，就能確認相同錯誤連結分布在多個頁面時的影響範圍。若加入「負責人」「確認依據」，之後也更容易重新檢查。
先指定安全的檢查範圍
向AI或連結確認工具說明以下限制。
- 只檢查公開頁面
- 起初只進行唯讀操作
- 不在短時間大量存取
- 不完成預訂、付款或詢問提交
- 不進入登入、管理畫面或客戶頁面
- 不保存URL附帶的個人資料或臨時權杖
- 尊重對方使用條款與存取限制
- 不以401、403、429或逾時作為自動刪除依據
機械式巡覽預訂表單，可能產生暫時預訂、保留庫存、通知郵件或存取限制。請明確區分「開啟頁面」與「確定操作」的界線。
重新導向要逐項判斷
頁面搬移時，可以從舊URL重新導向新URL。一般而言，301或308用於永久搬移，302或307用於暫時移動。Google Search Central的重新導向說明也說明永久、暫時轉向方式與搜尋中的處理。
但不要設定將所有不存在的URL導向首頁。只有存在相同內容的新頁面時，才導向該頁；沒有替代頁面時，應修正連結來源的說明。也不要建立多段轉向鏈或往返循環。
逐項修正的實務步驟
1. 確認影響
找出含有該連結的頁面、選單、頁尾、按鈕與圖片。同一URL若出現在多處，先決定修正順序。
2. 確認正式目的地
不要只憑搜尋結果判斷，應使用簽約服務的管理畫面、官方網站、服務商通知郵件或客服答覆。注意不要換成同名設施或非官方SNS。
3. 請AI提出變更方案
請AI以表格列出變更對象、目前值、建議值、依據與確認方法。此階段先不變更。
4. 備份後只變更一項
先修正一個營業影響較大的連結。選單或共用元件的變更會反映於全部頁面，因此要確認影響範圍。
5. 在PC與智慧型手機重新確認
從原頁面實際點擊，確認最終目的地、返回操作、新分頁行為與外觀。只有存在正式測試方法時，才執行預訂或詢問的確定操作。
6. 記錄於檢查表
保留修正日期、變更前後URL、依據、確認者與結果，讓下次檢查能判斷「為什麼使用這個連結」。
可交給AI的工作與由人決定的事項
| 適合交給AI | 由人決定 |
|---|---|
| 從公開頁面擷取URL | 該預訂目的地是否為目前契約服務商 |
| 記錄HTTP狀態與最終URL | 是否能改用其他服務 |
| 找出重複URL或轉向鏈 | 停止刊登、暫停或刪除的判斷 |
| 依優先度排列錯誤 | 價格、條款與預訂內容是否正確 |
| 建立修正候選與再確認步驟 | 正式環境變更與公開核准 |
| 整理與上次結果的差異 | 詢問、預訂的實際測試 |
不要未經確認就公開AI提出的「看似正確的URL」。尤其預訂、付款、電話與地圖，請由旅宿主人最後確認。
可複製使用的AI委託內容
不變更，只列出連結
請以唯讀方式檢查旅宿WordPress公開網站的連結。
對象為首頁、客房、價格、預訂、詢問、交通與頁尾。
以表格列出刊登頁面、連結文字、設定URL、HTTP狀態、最終URL與轉向次數，
優先處理預訂、詢問、電話與地圖。
請先不要變更WordPress、伺服器或重新導向設定。
不要提交表單、確定預訂、付款或登入。
不要在短時間大量存取，將401、403、429分類為需要目視確認。
依營業影響排序
請依對旅宿營業的影響，重新排序以下連結檢查結果。
［貼上檢查表］
優先度1為預訂、詢問、電話等阻止客人行動的項目，
優先度2為地圖、交通、價格與條款，優先度3為參考資訊。
即使HTTP 200，也請保留最終URL或顯示內容不適當的可能性。
不要執行修正，請加上應由人確認的項目。
整理正式替換候選
請針對以下連結建立替換方案。
［刊登頁面、目前URL、檢查結果、官方說明］
以表格列出目前URL、建議URL、依據、確認來源、未確認事項與變更後的確認方法。
不要只以搜尋結果或同名帳號作為依據；無法從官方資訊確認的項目，
請標示「需確認」。請先不要變更正式環境。
確認單一修正後的結果
已修正一個連結。請只以唯讀方式確認以下範圍。
［修正的刊登頁面與舊URL、新URL］
請確認刊登頁面的HTTP狀態、連結文字、新URL、轉向後的最終URL，
以及頁面標題。不要確定預訂、表單或付款操作。
不要變更其他頁面或設定，請區分已確認、未確認及需要人目視確認的項目。
檢查頻率
- 預訂、詢問與首頁：以外部監控日常確認入口
- 主要頁面全部連結：每月1次，或重大更新後
- 外部觀光、交通與SNS連結：每3個月1次
- 更換預訂服務或網域後：變更後立即確認，隔天再確認
- WordPress、佈景主題與外掛更新後：與公開確認一起進行
日常入口監控，可參考從外部監看旅宿WordPress的方法；文章公開後立即確認的細節，可參考WordPress公開後的確認方法。
預訂網站與官方網站資訊一致的工作，也可參考與AI檢查OTA與官方網站資訊差異的方法。若是整個網站故障，請不要急於變更，應依WordPress故障後的最初30分鐘的順序確認事實。
連結檢查清單
- [ ] 已將預訂、詢問、電話與地圖列為最優先
- [ ] 只以唯讀方式調查公開頁面
- [ ] 不只HTTP狀態，也確認最終URL與內容
- [ ] 沒有立即把401、403、429判為連結失效
- [ ] 沒有自動提交表單、預訂或付款
- [ ] 已依官方資訊確認正式替換目的地
- [ ] 沒有批次刪除或全部導向首頁
- [ ] 已在備份後逐項修正
- [ ] 已從PC與智慧型手機點擊
- [ ] 已記錄變更內容、依據與確認日
總結
旅宿網站連結檢查的重要目標，不是讓錯誤號碼歸零，而是維持客人能順利完成預訂、詢問與抵達旅宿的狀態。
AI適合收集大量連結、整理回應狀態與最終URL；但正確預訂目的地、目前契約、地圖位置與可公開的說明，由人判斷。結合唯讀檢查、官方資訊確認、逐項修正與實際點擊確認，不熟悉IT的旅宿主人也能安全持續進行。
