宿の公式サイトでは、予約サービスの変更、ページの整理、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公開後の確認方法で詳しく説明しています。
予約サイトと公式サイトの情報をそろえる作業はOTAと公式サイトの情報ずれをAIで点検する方法も参考にしてください。サイト全体の障害なら、変更を急がずWordPress障害発生後の最初の30分の順で事実を確認します。
リンク点検チェックリスト
- [ ] 予約、問い合わせ、電話、地図を最優先にした
- [ ] 公開ページだけを読み取り専用で調べた
- [ ] HTTP状態だけでなく最終URLと内容を確認した
- [ ] 401、403、429を即リンク切れと判定していない
- [ ] フォーム送信、予約、決済を自動実行していない
- [ ] 正式な差し替え先を公式情報で確認した
- [ ] 一括削除やトップへの一括転送をしていない
- [ ] バックアップ後に一件ずつ直した
- [ ] PCとスマートフォンからクリックした
- [ ] 変更内容、根拠、確認日を記録した
まとめ
宿サイトのリンク点検で大切なのは、エラー番号をゼロにすることではなく、お客様が予約、問い合わせ、来館まで迷わず進める状態を守ることです。
AIは多数のリンクを集め、応答状態や最終URLを整理する作業に向いています。一方で、正しい予約先、現在の契約、地図上の場所、公開してよい案内は人が判断します。読み取り専用の点検、公式情報による確認、一件ずつの修正、実際のクリック確認をセットにすれば、ITに詳しくない宿主さんでも安全に続けられます。
