curl -sS -D - -o /dev/null "$OLD_URL"

リダイレクトを追跡し、経由するレスポンスヘッダーを確認する

curl -sS -L -D - -o /dev/null "$OLD_URL"

結果を記録しやすいように、最終ステータスと最終URLを出力する

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

検収記録には、最初のレスポンス、転送先URL、最終レスポンス、ページ内容を併せて保存します。恒久的な移転に用いるルールの種類は、技術責任者が実際のデプロイ環境に応じて確認すべきです。ブラウザで「転送されたように見える」だけで結論を出してはいけません。

不要な連続リダイレクト、旧URLへの逆戻り、テスト用ドメインへの転送、転送先ページの不存在などは、公開を止める条件に含めます。特に、トップページのルールだけを確認し、記事や製品詳細ページを見落とさないように注意してください。

## 5. ページ内容とcanonicalをどのように併せて検収するか？

URLにアクセスできることは、最低限の要件にすぎません。ページテンプレートの種類ごとに代表ページを抽出し、タイトル、主見出し、本文、画像の代替テキスト、内部リンク、問い合わせボタンがそろっているかを確認することをおすすめします。インポート後にページの枠組みだけが残る事態を防ぐためです。

canonicalは正規URLの確認項目として使えますが、あらゆる移行問題を解決する代替手段と考えてはいけません。検収時には、ページが宣言している正規URLを記録し、プロジェクトで決定した本番ページと一致していることを確認します。特に、旧ドメイン、プレビュー用ドメイン、無関係なページを指したままになっていないかを調べます。

多言語サイトでは、言語バージョン間の対応関係も追加で確認する必要があります。中国語版の製品ページが、一括置換の結果、英語版のトップページへリンクしてしまうような状態は避けなければなりません。言語切り替え、フッターリンク、本文中の関連リンクも、実際にクリックしてテストします。

同時に、移行前後の重要情報を比較します。料金条件、サービス範囲、事例の根拠、連絡先が、テンプレートの置き換え時に意図せず削除されてはいけません。営業活動で使うページについては、開発担当者が技術的なレスポンスを確認するだけでなく、業務責任者にも検収に参加してもらうことをおすすめします。

## 6. サイトマップでは何を確認する？まず本番ページ一覧と照合する

まず「公開し、検索エンジンに発見してもらう予定の本番ページ一覧」を整理し、生成されたサイトマップと照合することをおすすめします。「XMLファイルが1つ生成された」ことをもって、確認完了としてはいけません。

特に次の事項を確認します。

- サイトマップ内のURLが、本番ドメインと本番環境のものになっているか。
- 移行後の新しいパスが、計画どおりに含まれているか。
- 削除済み、リダイレクト中、まだ公開準備が整っていないURLが混入していないか。
- サイトマップに記載されたページが、ページで宣言されている正規URLと一致しているか。
- 多言語ディレクトリ、記事のページネーション、製品カテゴリなどで、分類全体が抜け落ちていないか。
- サイトマップの更新と再公開の担当者が明確になっているか。

サイトマップの項目数が変わった場合は、その理由を確認します。計画的にコンテンツを統合した結果なのか、それともインポート漏れや抽出条件の誤りなのかを調べる必要があります。項目ごとに比較できるよう、移行前後のファイルのコピーを保存しておくことをおすすめします。

サイトマップは移行検収の一部にすぎません。送信操作が完了しても、個々のページへのアクセス、コンテンツ、その後の状態を確認する必要があります。送信を根拠に、インデックス登録、検索順位、トラフィックの成果を約束することはできません。

## 7. Search Consoleでは公開前後にそれぞれ何を確認する？

![7. Search Consoleでは公開前後にそれぞれ何を確認する？](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

公開前に、まずチームが対象サイトのプロパティへアクセスできることを確認します。旧ベンダーの契約終了によって、担当者の権限が失われないようにしてください。移行前の重要なランディングページ、検索クエリ、クリック数、表示回数を記録し、観測日も保存して、その後の比較の基準にします。

公開後は、次の順序で確認して記録することをおすすめします。

1. **プロパティと権限**：現在表示しているものが今回の移行対象サイトか、担当者が引き続きアクセス権限を持っているかを確認します。
2. **代表的なURL**：重要ページのクロール状況、インデックス状況、正規URLの情報を確認し、過去の記録とその後の変化を区別します。
3. **サイトマップ**：送信対象、処理状況、関連するメッセージを確認します。異常があれば、実際のファイルに戻って原因を調べます。
4. **ページの問題**：総数だけに注目せず、ディレクトリやテンプレートごとに異常を整理します。
5. **検索パフォーマンス**：トップページだけでなく、旧ページと対応する新ページを併せて、クエリ、クリック数、表示回数を比較します。

ドメインも同時に変更する場合は、アドレス変更に関する手順が自社の移行ケースに適用されるかを別途確認します。同一ドメインでのサイト構築ツールの変更と、ドメインをまたぐ移行を混同してはいけません。

問題を発見したときは、ページURL、表示されたメッセージ、観測時刻、再テスト結果を同じ対応チケットにまとめます。1回のスクリーンショットだけを根拠に、ページを削除したり、ルールを繰り返し変更したりしないようにしましょう。

## 8. 公開当日の検収とロールバックをどのように進めるか？

公開作業は、準備、切り替え、再テスト、経過観察の段階に分けることをおすすめします。準備段階では重要なコンテンツ変更を凍結し、ページデータと設定をバックアップするとともに、旧サイトへの必要なアクセスを維持できることを確認します。

切り替え後は、まず主要な業務導線をテストします。旧URLからのアクセス、製品説明の閲覧、フォーム送信、通知の受信、営業によるフォローアップまでを確認してください。SEOの確認とリード獲得経路の確認は並行して行い、ページにはアクセスできるものの、問い合わせが誰にも届かない状態を防ぎます。

公開を止める条件は、事前に合意しておく必要があります。例えば、重要な製品ページにアクセスできない、大量の旧URLに予定された移行先がない、本番ページにテスト環境の制限が残っている、問い合わせの仕組みが機能しない、といった場合です。こうした状況が発生したら、責任者が修正かロールバックかを判断します。公開作業を進めながら基準を議論するべきではありません。

ロールバックにも手順書が必要です。誰が実行できるのか、どの設定を復元する必要があるのか、復元成功をどう確認するのかを明記します。移行当日になって、旧サイトがすでに削除されていた、旧ベンダーのアカウント権限が失効していた、と判明する事態を避けてください。

## 9. 移行後にパフォーマンスが変化したら、どうすれば混乱せずに調査できるか？

まず再現可能な技術上・コンテンツ上の問題を調べ、その後に、より広い検索パフォーマンスの問題を検討することをおすすめします。確認の順序は、ページにアクセスできるか、旧URLの移行先が正しいか、コンテンツが完全か、内部リンクが更新されているか、サイトマップとページの宣言が一致しているか、とするとよいでしょう。

データを比較するときは、同じ業務目的のページについて、旧URLと新URLを併せて確認する必要があります。新URLの履歴だけを見ると、移行前のデータを見落としやすくなります。一方、サイト全体の総数だけを見ると、重要なディレクトリで発生している損失が隠れてしまう可能性があります。

同時期の広告変更、コンテンツの削除や修正、季節的なキャンペーン、計測設定の調整も記録します。すべての変化をプラットフォーム変更のせいにしないためです。各回の修正では、明確になった一群の問題に絞って対応し、再テスト結果を記録することをおすすめします。複数の変更が重なり、原因を判断できなくなる事態を減らせます。

すべてのサイトに共通する回復期間はありません。移行検収では社内の再確認スケジュールを設定できますが、そのスケジュールを検索エンジンの処理期限の約束として示すべきではありません。

## 10. AIサイト構築プラットフォームを選ぶとき、移行機能についてどう質問するか？

ページを生成することと、旧サイトを引き継ぐことは、別々の検収作業です。[we0公式サイト](https://we0.ai/zh)では、自然言語による要件の記述、複数のAIエージェントによる構築、ビジュアル編集、独自ドメインでのデプロイ手順が紹介されています。企業はこれらを基にサイト構築方法を評価できますが、旧パスの維持、リダイレクト設定、移行後のテスト方法については、別途デモを求める必要があります。これらの作業が自動的に完了すると推測してはいけません。

別のタイプの製品の参考として、[Readdy公式サイト](https://readdy.ai/zh)では、コードのエクスポート、ドメインホスティング、SEO・GEO関連ツールが紹介されています。調達時には、エクスポート後に誰がデプロイ設定を保守するのか、パスのルールを誰が管理するのか、異常を誰が調査するのかを、さらに確認する必要があります。機能名は、プロジェクトの責任分担を明記した文書の代わりにはなりません。

[Alibaba Cloud開発者コミュニティのWan Xiaozhi紹介記事](https://developer.aliyun.com/article/1773673)では、対話型のサイト構築とデプロイの流れが取り上げられています。ただし、ページにはユーザー投稿コンテンツであることが明記されています。チームがサイト構築の利用場面を理解するための参考にはなりますが、ベンダーが今回のプロジェクトにおける移行作業の提供範囲を約束したものとして扱うべきではありません。

候補となるプラットフォームや導入支援事業者には、実際の旧ページを少数使ったデモを依頼し、その後に調達と公開の計画を決めることをおすすめします。デモでは、新しいトップページを1つ生成するだけでなく、異なるテンプレートや異常ケースも扱う必要があります。

## よくある質問

### ドメインを変えず、サイト構築プラットフォームだけを変更する場合も、移行チェックリストは必要ですか？

必要です。パス、本文、ページでの宣言内容、内部リンク、問い合わせの流れが維持されているかを確認することをおすすめします。ドメインが変わらないからといって、デプロイ後の結果がすべて自動的に元の計画どおりになるとは限りません。

### すべての旧ページをトップページへ転送してもよいですか？

標準的な対応方法にすることはおすすめしません。まず、各旧ページを引き継ぐ関連性のある新ページが存在するかを判断します。代替コンテンツがない場合も、トップページへの転送で欠落を覆い隠すのではなく、対応方法を明確に記録する必要があります。

### サイトマップを送信すれば、移行は完了したことになりますか？

なりません。旧URLからのアクセステスト、重要ページの確認、業務導線の検収も完了させ、Search Consoleの状態変化を継続して記録する必要があります。送信操作は、実際のアクセステストの代わりにはなりません。

## 関連ツール

- **URL対応表**：旧パス、新パス、対応方法、担当者を管理します。
- **curl**：レスポンスヘッダー、リダイレクトの経路、最終URLを確認します。
- **Google Search Console**：サイトに関する状態と検索パフォーマンスの確認記録を整理します。
- **ブラウザの開発者ツール**：ページの読み込み、リンク、フォームのリクエストを再テストします。

## 関連リンク

- [we0：サイト構築、ページ調整、デプロイの流れ](https://we0.ai/zh)
- [Readdy：サイト構築、コードのエクスポート、運用ツールの紹介](https://readdy.ai/zh)
- [Alibaba Cloud開発者コミュニティ：Wan XiaozhiのAIサイト構築の利用場面](https://developer.aliyun.com/article/1773673)

## まとめ

サイト構築プラットフォーム変更時の検収対象は、新しいサイトだけではありません。旧URLから新しいコンテンツへ、さらに問い合わせへと至る一連の経路全体が対象です。まずURL対応表を作成し、次にリダイレクト、ページ内容、サイトマップ、業務導線をテストし、最後にSearch Consoleも活用して継続的に問題を調べます。プラットフォームの機能は実際のページを使ったデモで確認し、移行の責任分担とロールバック条件は公開前に明文化しておく必要があります。