1. 概要(Executive Summary)
ホームページリニューアルを検討中なら、答えから言います。 デザインが古いという感じだけで着替えないでください。 リニューアルはうまくいけばブランドとお問い合わせを一緒に引き上げますが、間違えれば何年も積み重ねてきた検索ランキングと流入キーワードを一度に失います。 「サイトは綺麗だったのに検索しない」というリニューアル後日談の原因はほとんど同じです。 URLが変わったのに古いアドレスと新しいアドレスをつなげなかったこと。
だから順序が必要です。今サイトが本当に乗り越える段階かシグナルから確認し、部分改善で解決される問題かどうか選び、次に前面リニューアルが正しいという結論が出たら、その時SEO資産のエスカレーション設計を計画に含める順序。この記事では、その3つのステップを実務基準でまとめました。
リニューアル費用を先に聞く方が多いのですが、費用は「どれくらい乗り換えるのか」で分かれます。一部改善はページ数枚を手掛けるメンテナンス規模ですが、フロントリニューアルは事実上新規制作に近いです。見積もりを受ける前に改編範囲から確定しなければ比較が意味があります。
コアメッセージ
リニューアルで最も高価なミスはデザインの失敗ではありません エスカレーション失敗です。 Googleのページ評価はURL単位で付けられており、アドレスが変わると自動的には続きません。
新しいサイトがどんなによく出ていても、検索の流入が途切れると、問い合わせも途切れる。リニューアル計画書に「SEO移管」の項目がない場合、その計画書はまだ未完成です。
2.リニューアルが必要であるという8つの信号
結論から。以下の8つのうち 3つ以上該当する場合は、リニューアルを検討する時点が正しいです。 特に技術側信号(⑥~⑧)は放置するほど回復コストが大きくなる項目なので、一つだけかかってもスケジュールを取るほうが安全です。
2.1訪問者が最初に知っている信号
- ①モバイル未対応: スマートフォンで画面を指で広げて拡大しなければ文字が読まれたら、すでに答えが出てきます。 Googleは、モバイル画面に基づいてサイトを評価するためのモバイル優先インデックスを全面的に適用しました。モバイルで壊れたサイトは検索でも押されます。
- ②ロード3秒以上: 最初の画面が上がるのに3秒を超えると、待っている訪問者が急激に減少します。 Googleが推奨するLCP(最大コンテンツ表示時間)の基準も2.5秒以内です。 PageSpeed Insightsにアドレスだけを入れると、無料で測定されます。
- ③ブランドの不一致: 会社はリブランドを終えたが、ホームページには昔のロゴと古いスローガンがそのまま。名刺やホームページが他社のように見えたら信頼から削ります。
- ④お問い合わせ減少: 訪問者数は似ていますが、お問い合わせやコンバージョンだけ減っていると、サイトが説得に失敗しているという意味です。コンテンツより構造や動線の問題である可能性が高い。
2.2 オペレータだけが知る信号
- ⑤ 管理不可能な構造: 文句一行変えるのに外注業者にメールを送って数日待たなければならない構造自体が古いものです。担当者が直接修正できないサイトは放置され、放置されたサイトはより早く古いです。
- ⑥セキュリティ警告: アドレスウィンドウに「注意要」が浮かぶHTTPサイト、期限切れのまま放置されたSSL証明書。訪問者の前にブラウザが出口をお勧めする状況です。
- ⑦ CMS・技術支援終了: サーバーのPHPバージョンがサポート終了したか書いたWebビルダー・CMSがアップデートを停止した場合、セキュリティパッチも一緒に停止したのです。事故が発生する前に移動する必要があります。
- ⑧検索インプレッションの低下: サーチコンソールのインプレッション数・クリック数が四半期単位で着実に下がっている場合、コンテンツ競争力であれ技術品質であれ、手球の視点がすでに過ぎているのです。
信号を数字で確認する方法
感で判断せず、3つのツールで10分だけ見直してください。 PageSpeed Insightsでスピードとモバイル対応、 Google Search Consoleによる検索インプレッションの推移、 アナリティクス(GA)へのお問い合わせのコンバージョン率。
これら3つの数値は、リニューアル後のパフォーマンスを比較するベースラインでもあります。リニューアル前の数値を今キャプチャしておいてください。
3.部分改善vsフロントリニューアル
信号が確認されたとすぐに乗り換えることはありません。基本原則は一つです。 問題が「ページ」にあれば部分改善、「構造」にあれば全面リニューアル。 メインデザインが気に入らないのとCMSがサポート終了したのはまったく異なる手術です。
3.1 部分改善で十分な場合はいつか?
次の4つは、フロントリビジョンなしで解決されます。
- メイン・主要サブ数ページの デザインだけ古い 場合 — 該当するページのリデザインで十分
- 速度の問題が画像容量またはプラグインの過剰から来る場合 - 最適化タスクで解決する
- 情報が古い場合 - 必要なのはリニューアルではありません コンテンツの更新
- 切り替えがない場合 - お問い合わせボタンの位置、ランディング設定など 部分改善とテストから
逆にモバイル未対応、CMSサポート終了、管理不可構造のように 基礎が問題であれば、部分修理はお金の無駄です。古い骨組の上に塗装だけを再びする格だから、1~2年以内に同じ問題に戻ります。
3.2 判断基準表
| 判断基準 | 部分改善 | フロントリニューアル |
|---|---|---|
| 問題の場所 | 特定ページ・要素(デザイン、フレーズ、イメージ) | サイト基盤(CMS、メニュー構造、レスポンシブ未サポート) |
| モバイル対応 | 反応型になりますが、一部の画面がぎこちない | レスポンシブ自体はありません |
| 管理環境 | 直接修正可能、一部不便 | 修正ごとに外注が必要、CMSサポート終了 |
| URL構造 | 維持(SEOリスクなし) | 変更可能性が高い(エスカレーション設計必須) |
| 期間 | 数日〜受注 | 2~4ヶ月以上 |
| コストスケール | メンテナンスレベル | 新規制作に準拠 |
フロントリニューアルに向かって傾けた場合は、コスト構造を理解した状態で見積もりを受ける方が良いです。見積もり項目がどのように構成され、どこで金額が分かれるか ホームページ制作コストの構造で別にまとめました。
4. SEO資産を守るエスカレーション設計
この章はこの記事の中核です。フロントリニューアルで検索順位が崩れる原因はほぼ一つに集まります。 URLが変わったのに古いアドレスと新しいアドレスをつなげなかったこと。 Googleのページ評価はURL単位で積み重ねられます。 /about.php が /company/about に変わった瞬間、Google に古いページは消えて新しいページは初めて見ることです。この切断を埋めるデバイスは301リダイレクトです。
4.1 何が資産なのか調べる
リダイレクトマップを作成する前に、守る価値のあるページが何であるかから確認します。ツールは Google Search Console の 1 つで始めれば十分です。
- パフォーマンスレポート: 最近12ヶ月基準でクリック・露出が発生したページと流入キーワードをダウンロードします。ここでキャッチするページがすぐに守るべき資産のリストです。
- リンクレポート: 外部サイトが歩いたバックリンクがどのページに向いているかを確認します。バックリンクが付いたページのアドレスを変更しながらリダイレクトを減らすと、そのリンクの値は404で蒸発します。
- 完全なURLリスト: サイトマップ(sitemap.xml)やScreaming Frogなどのクロールツールを使用して、現在のサイトのURL全体を引き抜きます。数ページのサイトでも添付ファイル・画像アドレスまで数えるとリストが思ったより長いです。
4.2 リダイレクトマップはどのように作りますか?
スプレッドシートは2列です。左側に古いURL、右側に対応する新しいURL。原則は 1:1マッピングです。旧サービス紹介は新しいサービス紹介で、旧ブログ記事は新しいアドレスのようなグロー。対応するページがなくなった場合は、最寄りの上位カテゴリに送信されますが、行き先のないURLをすべてメインに追いやる方法は避けてください。 Googleは、ダークメインリダイレクトを事実上の404(ソフト404)として扱うことができます。
301と302は異なる
301は「永久取締役」、302は「ちょっと待つ」です。リニューアルエグゼクティブには、301を使用して既存のページの評価が新しい住所に継承されます。
サーバー設定(.htaccess、nginx conf)またはCMSのリダイレクト機能として適用し、適用後にいくつかの古いURLを直接開きます。新しいアドレスに進むか、応答コードが301に収まるかは、Chrome Developer Tool Networkタブですぐに確認できます。
4.3 移管チェック項目表
| チェック項目 | 視点 | 確認内容 |
|---|---|---|
| 流入ページ・キーワード調査 | 着手前 | GSCパフォーマンスレポート12ヶ月ダウンロード |
| バックリンク調査 | 着手前 | GSCリンクレポートでPylinkページをリストする |
| 301 リダイレクトマップ | 新しいURL構造の確定直後 | 古い URL → 新しい URL 1:1 マッピングシートの作成 |
| メタ情報移管 | コンテンツエスカレーション | title・description・構造化データページ別移転 |
| リダイレクト動作の検証 | オープン直後 | メインの古いURLのレスポンスコード301を確認する |
| サイトマップの再送信 | オープン直後 | 新しいsitemap.xmlをGSCに送信し、インデックスをリクエスト |
| 順位・流入モニタリング | オープン後4〜8週間 | 主なキーワードランキング、404エラー、クロール統計の追跡 |
エスカレーションをしっかりしても、オープン直後数週間のランキングが出てきます。これは、Googleが新しい構造を再クロールして評価を移動するのに時間がかかるためです。ここで慌ててURLをまた変えると混乱だけ大きくなります。リニューアル前にバックアップしておいたベースライン数値と比較しながら待つまでがエスカレーション設計です。
ちなみに、検索の流入は現在、伝統的な検索だけの問題ではありません。 AI検索で引用されるコンテンツ構造まで考えると SEOを超えてGEOに行く検索インプレッション戦略を一緒に読んでください。リニューアルはサイトのコンテンツ構造を再編成する稀な機会なので、この時反映しなければ二度働かない。
5. リニューアルプロセス ステップ5
フロントリニューアルの標準フローは5段階です。目に見えるデザイン・開発は第3段階に過ぎず、 成敗は最初のステップ(診断)と最後のステップ(検収・モニタリング)で分けられます。
ステップ1 - 診断と目標の設定
現在のサイトのデータを取得する手順です。 GSC・GA数値バックアップ、流入キーワードとバックリンク調査、そしてコンテンツインベントリ(全ページリストと維持・統合・廃棄判定)作成。続いて「リニューアルで何が良くなるべきか」を数字として定義します。お問い合わせのコンバージョン率か検索流入か採用支援かによって設計が異なります。
ステップ2 — 情報構造・コンテンツ設計
メニュー構造とページ固有のコンテンツを確認します。新しいURL構造がこの段階で決まるので、 リダイレクトマップの作成もここで開始します。デザインシアンの後にメニューを反転すると、スケジュールとコストが一緒に押されます。順序を守るだけで半分の紛争が防止されます。
ステップ3 — デザイン・開発
シアンの確定後、パブリッシングと開発が行われます。担当者が手に入れるのは二つ。シアンをモバイル画面基準で先に検討すること、そしてオープン後管理者画面で直接修正できる範囲を文書で確認しておくこと。 ⑤番信号(管理不可構造)を次のリニューアル事由に繰り返さないためには、今釘付けしなければなりません。
ステップ4 — ステージング検収
オープン前シルサーバーと同じ環境(ステージング)で検収します。全ページ誤字・壊れたリンクチェック、フォーム転送テスト(問い合わせが実際のメールで届くかまで)、モバイル実機確認、リダイレクトマップ標本検証。検収期間をスケジュールに入れていないプロジェクトは、この過程を開いた後に実ユーザーに行われます。
ステップ5 - オープンとモニタリング
オープン当日にはステージング用 noindex 除去確認、リダイレクト動作確認、GSC 新しいサイトマップ提出。その後、4〜8週間、週単位で404エラー、クロール統計、キーキーワードのランキングを表示します。オープンは終わりではなく、エスカレーション検証の始まりです。
6. リニューアル失敗を呼ぶ罠
失敗したリニューアルのパターンは繰り返されます。以下の4つが特に頻繁です。
トラップ1 — オープン日に追いつく
「イベント前日までは無条件にオープン」という日程が取れれば一番先に切り取るのが検手です。オープン日は遅れて開発は遅くなるので、ステージング検数の数日が半日に減ります。壊れたリンクと誤字を顧客が最初に発見するリニューアルはほとんどこのように作成されます。オープン日を決めると 開発完了日とオープン日の間に1~2週間を検収期間で打ち込んでください。
トラップ2 — コンテンツのエスカレーションがありません
新しいサイトを作りながら「昔の文章は古いから捨てよう」と判断しやすいです。ところがその古い文が検索流入の大部分を繰り広げている場合が多いです。見かけの訪問者が少なく見えても、累積されたブログ記事と資料ページがロングテールキーワードを握っている構造であれば削除はまもなく流入削除です。廃棄するかどうかは感じではなくGSCデータで決めてください。
トラップ 3 — noindex 残したままオープン
ステージングサーバーは検索に公開しないでください。noindexを掛けるか、robots.txtでクロールを停止します。問題は、この設定がシルサーバーにそのままつながる事故です。サイトはとても開いているが、検索露出だけ静かに消えるので、数週間経っても「検索しても出ない」という話を聞いてから発見されます。
オープン当日5分点検
新しいサイトの任意のページを開き、ソースビューで noindexを検索と、 ドメイン/robots.txtを開き、Disallow設定を確認し、古いURLを1つ入力します。 301に進むか 見てください。
これら3つのケースでは、最悪の事故のほとんどをオープン日に除外できます。
トラップ4 — リニューアルですべてを解決しようと期待
リニューアルはボウルを新しく作る事であり、盛る内容を作ってくれません。コンテンツが不良なサイトはリニューアルしても不良な新しいサイトになるだけです。再編と一緒にコンテンツ運営計画 - 誰が、どのくらいの頻度、何を上げるのか - このフォローアップはリニューアル効果を維持します。
7. 結論とチェックリスト
ホームページリニューアルの要体は2文で減らすことができます。 着替えてはいけない感ではなく、信号とデータで決める。着替えることにした場合は、新しく作ることに劣らず移す設計にボールを入れる。 新しいデザインは目に見えますが、守られた検索資産は目に見えません。そのため、頻繁に省略され、省略の対価はオープン後に請求されます。
着手前のチェックリスト
- 信号確認: 2枚の8つの信号のうち該当項目をチェック - 3つ以上の場合はリニューアルレビュー
- 範囲判定: 問題がページであるか構造であるかを判断します。
- ベースラインバックアップ: GSC・GA数値、流入キーワード、バックリンクリストをリニューアル前に確保
- リダイレクトマップ: 新しいURL構造の確定と同時に古いURL→新しいURL 1:1マッピングシートの作成
- 検収期間の確保: 開発完了とオープンの間1~2週間ステージング検収を日程に明示
- オープン当日チェック: noindex除去・robots.txt・301動作・サイトマップ提出確認後4~8週モニタリング
この6つの項目が計画書に含まれている場合、どのプロデューサーと進行しても、リニューアルの半分はすでに勝ったまま始まります。残りの半分はコンテンツとデザインの役割です。