ウェブサイトリニューアルのSEO要件書はどう作成する？移行と検収のポイント一覧

サイトリニューアルで、プロジェクトの進行と検索流入をどう両立させるか。「cahier des charges seo refonte d'une site」のようなサイトリニューアル時のSEO要件書で、プロジェクト責任者が本当に解決すべきなのは、最適化の提案をいくつか追加することではありません。移行範囲、納品責任、受け入れ基準について、デザイン、開発、コンテンツ、マーケティングの各チームで合意することです。ページが表示されるのは出発点にすぎません。旧ページの流入が適切な新ページにたどり着くかどうかは、公開時に見落とされやすい重要なポイントです。

着手前に、既存サイトの資産とリニューアルの範囲を明確にする

要件書を「新しいトップページをもっと見栄えよくする」ことから始めてはいけません。今回変更するのがデザイン、コンテンツ管理システム、ドメイン、ディレクトリ構造のどれなのか、あるいは複数を同時に変更するのかを確認しましょう。ドメインとパスを変更しないリニューアルでは、ページのコンテンツや技術的な実装が重点になる場合があります。一方、ドメインの変更や多言語ディレクトリの調整も行う場合は、移行テストと公開後の監視期間を別途計画する必要があります。

既存サイトのリストには、少なくとも現在のURL、ページタイプ、タイトル、ステータスコード、正規URLに加え、自然検索からの訪問や問い合わせに貢献しているページを含めます。サイトのクロール結果、Google Search Console、アクセス解析ツール、業務チームの記録を照合してデータを確認できます。直近の流入だけを見てはいけません。季節性のある製品や、購買までに時間がかかる製品の技術資料にも、残す価値がある場合があります。

削除予定のページについては、要件書にその理由と処理方法を記録します。たとえば、生産終了製品に代替モデルがある場合は、関連ページへ誘導できます。適切な代替コンテンツがない場合、エラーをなくすためだけに一律でトップページへリダイレクトするのは適切ではありません。代替先の妥当性は業務責任者が確認し、SEO担当者が検索への影響を確認し、開発担当者が実装を担うようにして、公開当日に判断の責任者を巡って議論する事態を避けましょう。

移行表は公開前の臨時添付資料ではなく、納品物として扱う

移行表には、旧URL、新URL、ページタイプ、処理方法、担当者、テスト結果を1件ずつ記載することをおすすめします。維持するページは、可能な限り元のパスを維持します。変更が必須の場合は、旧URLから最も関連性の高い新URLへ301リダイレクトで直接転送し、リダイレクトの連鎖を避けます。また、検索意図の異なる複数の旧ページを、区別なくトップページへ転送してはいけません。

要件書では、URLのルールについても合意しておきます。大文字と小文字、末尾のスラッシュ、パラメータ、ページネーション、正規URLをどのように扱うかを明確にします。リダイレクト、内部リンク、canonicalタグ、サイトマップが、いずれも同じ転送先URLを示すようにします。完全に削除され、適切な代替コンテンツもないページには、404または410ステータスコードを返すことができます。どちらを選ぶかは実際の運用方法に応じて決めればよく、すべての404を障害とみなす必要はありません。

海外向けサイトでは、言語ごとのページも個別に確認する必要があります。中国語、英語、その他の言語の対応ページは、それぞれ個別にマッピングし、旧版の商品詳細ページが新サイトの別言語のトップページへ一律に転送されないようにします。hreflangを使用する場合は、言語・地域コード、ページ間の対応関係、最終URLを確認します。対応する翻訳ページがない場合は、対応先URLを作り上げてはいけません。多言語のパスが確定したら、翻訳チームと開発チームに並行して作業を依頼すれば、手戻りを減らせます。

技術要件は、確認可能な作業として記載する

「検索エンジンに配慮したページ」では、受け入れ確認ができません。重要なコンテンツやリンクにアクセスできるか、ページが正しいステータスコードを返すか、タイトルとディスクリプションをページごとに編集できるか、canonicalタグ、構造化データ、サイトマップを誰が生成するかを、要件書に明記します。開発環境では検索エンジンのアクセスを制限し、公開時には残すべきでないアクセス制限、robotsルール、noindexタグを項目ごとに解除します。

デザイン案の承認後も、実際のページを確認する必要があります。製品仕様、用途、問い合わせ窓口が画像の中にしかない場合、ユーザーが情報を確認しにくく、コンテンツの更新にも不便です。スクリプトの読み込みに依存する重要なコンテンツは、検索エンジンが取得できるかテストします。パフォーマンス要件は「読み込みを速くする」とだけ記載せず、代表的なページとテスト環境を選び、公開前後のCore Web Vitalsを記録するとともに、基準未達時の修正責任者を明確にします。

リニューアルに中国国内のサーバー、ドメイン、接続事業者の変更が含まれる場合は、ICP登録の確認もスケジュールに加えます。登録、変更、接続に関する手続きが必要かどうかは、サイトの実情と所管当局および接続サービス事業者の要件に基づいて確認します。営利目的の事業については、関連する許認可要件も別途確認してください。書類の整理や確認手順のサポートが必要な場合は、中国国内ICP登録サービス番号をご確認いただけますが、審査期間を固定の公開予定として扱うべきではありません。

受け入れ確認は2回実施する：公開前にリスクを確認し、公開後に実際の状況を確認する

公開前には、少なくともトップページ、主要カテゴリ、重点製品、コンテンツ記事、各言語のテンプレートをサンプリングして確認します。流入や問い合わせの多いページ、重要なリダイレクトは、1件ずつ検証します。確認項目にはページの表示だけでなく、ステータスコード、タイトル、canonicalタグ、内部リンク、フォーム送信、モバイルでの使いやすさも含めます。テスト環境での合格を、正式環境での再確認の代わりにしてはいけません。

公開後は、更新したサイトマップを速やかに送信し、重要な旧URLが移行表どおりにリダイレクトされているか確認するとともに、クロール、インデックス登録、自然検索の状況を継続的に確認します。要件書では、監視期間、レポートの頻度、異常時のエスカレーション経路、ロールバック条件を事前に定めておくのが望ましいです。たとえば、主要ページにアクセスできない、問い合わせフォームが機能しないといった場合に、誰が公開の一時停止を判断し、誰が復旧を担当するかを明確にします。短期的な順位や流入の変動を、移行の失敗と単純にみなすことはできませんが、異常を無視してよい理由にもなりません。

マーケティング施策の導線確認も忘れてはいけません。旧広告のランディングページ、ソーシャルメディア、メール、計測イベントが、引き続き旧URLを参照している場合があります。ページのリダイレクトが正常でも、フォームの流入元判定やコンバージョン計測が途切れる可能性があります。サイト構築、SEO、広告運用を一体化したプロジェクトでは、易營寶のような一体型サービスの連携方法を参考にし、URL移行、広告リンク、問い合わせ追跡を同じ公開チェックリストにまとめておくとよいでしょう。流入に異常が出てから個別に調査するのではなく、事前に一元管理できます。

要件書を確定する前に、開発責任者、コンテンツ責任者、マーケティング責任者がそれぞれ確認・承認することをおすすめします。表に沿って実行できるか、不足資料は誰が補うか、遅延によってどの工程に影響が出るかを確認します。特に移行表とロールバック計画は、設計段階で時間をかけて確認し、ドメインを切り替える当日まで判断を先送りしないようにしましょう。