多くの経営者がコーポレートサイトのリニューアルで最も心配するのは、デザインが良いかどうかではなく、新サイト公開後に以前検索できたキーワードで検索できなくなり、トラフィックがコンセントを抜かれたように落ちることです。
これはWebサイト開発段階である程度予防できます。実際にインデックスが落ちる場合、多くの場合は移行時にいくつかの小さなことを見落としたのであり、新サイト自体に問題があるわけではありません。
以下、実際のプロジェクトの順序に沿って、できるだけわかりやすく説明します。
一、まずURLルールを決めてからコードを触る
移行で最も問題が起きやすいのはURLです。旧サイトが`/product/123.html`で、新サイトが`/product?id=123`になったり、カテゴリ名をすべて変えたりすると、検索エンジンはそれを新しいページ群として認識し直します。
やり方は簡単です。移行前に旧URLのリストを作成し、管理画面、サイトマップ、検索リソースプラットフォームからエクスポートして、「元のパスを維持」か「新しいパスへリダイレクト」かを1件ずつ标注します。維持できるものはできるだけ維持し、特にすでに順位のあるカテゴリページや記事ページは重要です。
注意点：「見た目を整える」ためにすべてのURLを書き換えないでください。整っているのは人に見せるためで、インデックスはクローラーに見せるためです。両者が衝突する場合はインデックス維持を優先します。
二、301リダイレクトは全体に設定し、トップページだけにしない
301は移行の要です。よくある間違いはトップページだけリダイレクトし、内部ページがすべて404になることです。
正しい方法は1対1マッピングです。旧ページAは新ページAへリダイレクトし、すべてをトップページへ飛ばすのではありません。すべてトップページへ飛ばすのは「これらのコンテンツはなくなった」と検索エンジンに伝えるのと同じで、インデックスはすぐに落ちます。
もう一つのポイントは、リダイレクトチェーンを1階層以内にすることです。AがBへ、BがCへ飛ぶとクローラーが途切れやすくなります。Webサイト開発時に技術者へ直接AからCへ設定してもらいましょう。
企業サイトのリニューアルでカテゴリ構造が大きく変わる場合は、公開前にクローラーツールで旧サイトを巡回し、リダイレクトルール表を生成して開発に渡すことをおすすめします。公開後に補うのではなく、事前に準備しましょう。
三、コンテンツはサイト全体を書き直さず、まずマッピングを行う
一部のチームはリニューアル時に文案をすべて入れ替え、タイトル、ディスクリプション、本文を書き直します。その結果、新ページと旧ページが「対応しなくなり」、検索エンジンが関連性を再判断する必要があり、順位の変動が顕著になります。
より安定した方法は、主要ページは元のテーマとキーワードを維持し、まず構造を移行し、公開が安定してから文案を段階的に最適化することです。
具体例を挙げます。産業設備の会社がコーポレートサイトをリニューアルし、旧サイトに80以上の製品ページがありました。移行時に製品仕様、型番、用途をそのまま移し、レイアウトとナビゲーションだけを調整し、タイトルには元の型番ワードを残しました。公開から2週間で、主要製品ページのインデックスはほぼ維持できました。逆に、当時型番ワードをブランドスローガンに変えていたら、おそらく一から育て直す必要があったでしょう。
四、公開の進め方：まず小規模トラフィックで検証し、その後全体を切り替える
移行は「一斉切り替え」をおすすめしません。
実行可能な進め方は、新サイトをまず社内ネットワークやテストドメインで動作確認し、リダイレクト、サイトマップ、robots、canonicalが正常か確認します。その後、アクセスの少ない時間帯に切り替え、切り替え後すぐに新しいサイトマップを送信し、検索リソースプラットフォームでクロールとインデックスの変化を観察します。
注意点は3つあります。
- robots.txtの誤ブロックに注意：テスト環境ではよく`Disallow: /`と書かれ、公開時に削除を忘れてサイト全体がクロールされなくなります。
- canonicalが旧ドメインを指さないように：テンプレートをコピーすると持ち込みやすいです。
- サイトマップにトップページだけを入れない：主要カテゴリとコンテンツページを含める必要があります。
五、ミニプログラムやAppは代替品ではない、混ぜて移行しない
一部の企業はリニューアルを機にトラフィックをミニプログラム開発やApp開発へ誘導したいと考えます。それは問題ありませんが、Webサイトのコンテンツを直接下架しないでください。Webサイト、ミニプログラム、Appにはそれぞれ入口があり、検索エンジンはWebサイトの分しか認識しません。
もしミニプログラム開発を本当に行う場合は、Webサイトには完全なコンテンツページを残し、ミニプログラムは予約、会員、注文などのインタラクション機能を担当し、両方で同じコンテンツソースを使うことをおすすめします。そうすればインデックスにも影響せず、業務にも支障が出ません。
MIC Studioに相談するのが適しているケース
以下のような状況なら、外部チームへの相談を検討できます。
- 旧サイトの構造が乱れ、どのページにトラフィックがあるか誰も説明できず、まず整理してから移行する必要がある；
- 社内に専任のフロントエンドとバックエンドがおらず、Webサイト開発の期間が厳しい；
- 移行後にすでにインデックス低下が発生し、リダイレクトとインデックスの問題を調査する必要がある；
- 同時にコーポレートサイト、ミニプログラム開発、App開発を行い、コンテンツと技術の基準を統一したい。
MIC Studioは企業サイトの開発と移行の際、まず旧URLリストとリダイレクト表を作成してから、デザインと機能について話す習慣があります。順序が正しければ、後の手戻りが少なくなります。
実行可能な3つの提案
1. 公開前に旧URLリストをエクスポートし、維持かリダイレクトかを1件ずつ確認して表にまとめ、開発に渡す。
2. 301は1対1マッピングにし、リダイレクトは1階層以内に抑え、公開後すぐに新しいサイトマップを送信する。
3. 主要ページはまずコンテンツを維持してから文案を変更し、公開が安定して2週間後にキーワード最適化を行う。
移行はページを移せば終わりではありません。引っ越しに似ています。住所は正しく残し、旧住所には案内人を置き、物をむやみに替えないことです。これらを押さえれば、インデックスはほぼ維持できます。