サイトリニューアルでやってはいけないこと10選

大規模サイトのリニューアル後に自然検索流入が短期で30%前後落ち込むケースは、公開されたケーススタディで繰り返し報告されています。 Google Search Centralでも、URL変更やテンプレート刷新を伴うサイト移転はランキングの変動と再評価期間（一般に数週間〜数ヶ月）を伴うと明記されています¹。設計や運用の初期判断を誤ると、その揺らぎが恒常的な損失に転じます。各種の事例レビューでも、失敗の多くは高度なアルゴリズム起因ではなく、前提確認やリダイレクト設計といった基本の不徹底に端を発していました。プロダクトの刷新が価値の再定義であるのに対し、サイトのリニューアルは既存価値を毀損しない移行の設計が最重要です。そこで、CTOやエンジニアリングマネージャーが必ず押さえるべき、やってはいけないことを体系立てて解説します。各節では具体コードも示し、実務でそのまま検証できる形に落とします。なお、リニューアルや移行に伴う大幅なトラフィック低下は実務でもしばしば観測されており、設計と監視の徹底が不可欠です⁴⁵。

移行前にやってはいけないこと：現状把握とガードレールを省く

まず避けるべきは、現行サイトのベースライン（移行前の基準指標）を取らずに設計を始めることです。主要ランディングページの流入構成、クエリの意図、コンバージョンの寄与、被リンクの集約状況、レンダリングとCore Web Vitals（Googleが提示する表示品質の指標群）の分布、これらを粒度を揃えて記録しないままテンプレートの改修を進めると、見た目の改善と引き換えに収益ページの検索適合度が静かに失われます。特に上位クエリ群に対してユニークに機能している見出し構造や本文の語彙は、機械的なテンプレート置換で平坦化しがちです。ログとSearch Consoleのデータを突き合わせ、いわゆる80/20（上位の成果を生む重要URLの2割）の範囲を優先して守る設計指針を先に確定させるべきです。移行の監視・比較に備え、旧新を独立プロパティ（測定用の別環境）として計測・追跡することも推奨されます²⁵。

次に多いのは、ステージング環境の検索遮断を曖昧にすることです。robots.txtのDisallow（クロール回避のお願い）だけに頼ると誤配備やキャッシュで漏れます。検索エンジン側の尊重度は指示によって異なるため、ヘッダーでのnoindex（インデックス登録の禁止）を併用し、可能なら認証で物理的に遮断します。加えて本番へ移行する際にnoindexを解除し忘れる事故も頻発します。リリースパイプラインにチェックを組み込み、環境変数で明示的に切り替える作りにして人手の記憶に依存しないことが肝要です。開発中はクロールを遮断し、移転開始後は適切に解除するという基本原則を徹底します³。

# ステージング環境: robotsとヘッダーで二重遮断
server {
  server_name staging.example.com;
  location = /robots.txt { return 200 "User-agent: *\nDisallow: /\n"; }
  add_header X-Robots-Tag "noindex, nofollow" always;
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd; # 認証で物理遮断
}

ベースラインの計測体制を後回しにすることも避けたい失策です。新旧プロパティで計測スキーマ（イベント名や属性定義）がズレると比較が不能になり、原因特定の手がかりを失います。計測タグは早期に分離導入し、イベント名とスキーマを凍結してから開発を進めると、移行後の因果が追いやすくなります。旧サイトと新サイトを独立してウェブ解析で把握できるようにしておくと、移行後の評価が容易になります²。

設計とSEOでやってはいけないこと：URL・信号・内部リンクの軽視

無目的にURLを変更し、恒久リダイレクト（301）の設計を後回しにする判断は、やってはいけない代表例です。パスの正規化、トレーリングスラッシュ、クエリの扱い、大文字小文字、www有無など、正規形を先に決め、例外も含めて一対一で301を敷きます。一時リダイレクト（302）のまま放置したり、JavaScriptリダイレクトやmeta refreshで逃げると、評価の引き継ぎが逓減し、クローラビリティも落ちます。検索エンジンは最終的に到達するURLを理解しますが、評価の移転速度と確実性は設計次第で大きく変わります¹。大規模移行では、網羅的な301マッピングと回帰テスト、公開後の監視が推奨されます⁵⁶。

# Nginx: 旧URLから新URLへの恒久リダイレクトをmapで集約
map $request_uri $redirect_target {
  default "";
  /old-category/alpha /category/a;
  /old-category/beta  /category/b;
}
server {
  if ($redirect_target != "") { return 301 https://example.com$redirect_target; }
  # 末尾スラッシュの正規化
  if ($request_uri ~ ^(.+[^/])$) { return 301 https://example.com$1/; }
}

# Apache(.htaccess): wwwなしへ統一 + 旧→新の301
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
RewriteRule ^old-category/alpha/?$ /category/a/ [L,R=301]

// Node/Express: 301を明示し、クエリも引き継ぐ
app.use((req, res, next) => {
  if (req.hostname.startsWith('www.')) {
    const url = `https://${req.hostname.replace('www.', '')}${req.originalUrl}`;
    return res.redirect(301, url);
  }
  next();
});

canonical（正規URLの宣言）とhreflang（言語・地域の対応表）の不整合も、評価の分散を招く典型です。多言語・多地域サイトでは、自己参照canonicalと正しいx-defaultをセットで管理します。類似テンプレート間でcanonicalを共通親に誤設定すると、意図しない統合が起こります。生成ロジックはテンプレート層ではなくルーティング層で管理し、パラメータ条件と一緒に回帰テスト化すると事故率が下がります。

<!-- 各ページに自己参照canonicalを明示 -->
<link rel="canonical" href="https://example.com/category/a/">
<!-- 多言語の例 -->
<link rel="alternate" href="https://example.com/ja/" hreflang="ja">
<link rel="alternate" href="https://example.com/en/" hreflang="en">
<link rel="alternate" href="https://example.com/" hreflang="x-default">

デザインの簡素化と引き換えに内部リンク網を希薄化してしまうのも避けたい落とし穴です。パンくずや関連記事、ハブページからの系統リンクは、クローラビリティ（クロールされやすさ）の動脈です。UIから消した要素は、サイトマップやin-contentの文脈リンクで補い、シグナルの総量を落とさない方針を守るべきです。サイトマップは新旧のURLを混在させず、公開時点ですべて新URLだけを含むように切り替えます¹。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/category/a/</loc>
    <lastmod>2025-08-30</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

フロントエンドとパフォーマンスでやってはいけないこと：描画妨害と信号の劣化

JavaScriptレンダリングへの過度な依存で、初回表示とインタラクションの応答性を犠牲にするのは避けるべき判断です。Core Web Vitalsの閾値は、LCP（最大視覚要素の表示）2.5秒以内、CLS（レイアウトのズレ）0.1未満、INP（操作から次の描画まで）200ms以内が望ましいとされます⁷⁸¹⁰。SPA（単一ページアプリ）への全面移行を決める前に、SSR（サーバーサイドレンダリング）や静的生成、ルート単位のプリレンダリング、クリティカルCSSのインライン化、遅延読み込みの分割を併用し、表示経路を短くします。とりわけLCP候補の画像の遅延読み込みや、フォントのブロッキング読み込みは、視覚的完了の遅延を引き起こします。フォントはサブセット化し、preloadとdisplay: swapを適用して、可読性を担保しながら計測値を守ります⁷。

<!-- フォントのブロッキング回避と可視化の担保 -->
<link rel="preload" as="font" href="/fonts/Inter-roman-var.woff2" type="font/woff2" crossorigin>
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/Inter-roman-var.woff2') format('woff2');
    font-display: swap;
  }
</style>

画像最適化の抜け漏れは、見た目では気づかれにくいのに、転送量とLCPに直結します。フォーマットはWebPやAVIFを第一に検討し、サイズはレイアウトに応じて固定し、適切なwidth/heightを指定してCLSを抑えます。CDNの自動変換機能を使う場合でも、テンプレート側でsrcsetとsizesを定義し、ネットワークとレイアウトの両面から最適化します¹¹⁹。キャッシュ戦略も同様で、静的アセットは期限付きの強キャッシュとし、ファイル名にハッシュを付与してセマンティクスと整合させます。アプリケーション層ではETagやLast-Modifiedで協調キャッシュを活用します¹³¹⁴。

# Nginx: キャッシュと圧縮のベースライン
location ~* \.(js|css|woff2|jpg|jpeg|png|webp|avif)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}
gzip on;
gzip_types text/css application/javascript image/svg+xml;
# brotliを使える環境なら併用

外部タグの氾濫も、表示のブロックと信頼の毀損に直結します。タグマネージャーを介していても、配信先の応答が遅ければ同じです。優先度ごとにロード戦略を分離し、必須ではないサードパーティは遅延または同意取得後の挿入に切り替えます。法令対応の観点からも、同意前のトラッキングは避けるべきです。こうした外部依存を移行時に棚卸しし、削除・代替・遅延の三択で意思決定を済ませてから本番に臨む方が安全です¹²。

リリースと運用でやってはいけないこと：ノーモニター、ノーロールバック、ノーコミュニケーション

監視を用意せずに切り替えることは、運用として許容できません。検索・クロール・パフォーマンス・ビジネスKPIの各レイヤーに、即時の異常検知を用意します。サーバーログでは404と301の発生傾向を可視化し、旧URLからの到達が想定通り301で収束しているかを確認します。Search Consoleではカバレッジとサイトマップ登録、クロール統計を日次で確認し、重大なエラーやスパイクがないかを早期に検知します。アナリティクスではランディングページの上位群とコンバージョン率の有意差を、A/Bや期間比較で追い、テンプレート単位の影響を特定します。こうした仕組み化がない場合、問題は感覚で語られ、対策が遅延します⁵⁶。

ロールバック計画を用意しないのも、やってはいけない意思決定です。データ移行の可逆性、インフラの青緑デプロイ（Blue-Green）、DNSとキャッシュのTTL、検索信号の最小変更単位、これらを事前に設計しておくと、想定外の挙動が発生した際に段階的に戻す選択肢が取れます。部分的なテンプレートの切り戻しや、特定セクションの旧URL維持など、評価を守るための回避策は事前準備がすべてです。移転通知ツールやアドレス変更ツール（ドメイン移転時）を必要に応じて利用し、シグナルの整合を補助する判断も検討に値します¹。

最後に、リリースノートと関係者コミュニケーションを軽視しないことが重要です。営業・CS・広告運用・カスタマーの各接点には、URLの変更、ナビゲーションの変更、計測の変更が波及します。社内の検索リンクやブックマーク、外部の広告リンクはリダイレクトに頼るのではなく、更新計画をセットで進めます。こうした運用面の丁寧さが、検索以外のチャネルの落ち込みを抑え、移行全体のROIを守ります。

実務で直ちに使えるチェックの観点

移行前のベースライン確定、ステージング遮断と本番のnoindex解除の自動検査、301の一対一マッピングと回帰テスト、canonicalとhreflangの自己参照の検証、パンくずとサイトマップの同時更新、LCP候補の画像とフォントの最適化、第三者タグの遅延と同意制御、ログ監視と404収束のトラッキング、Search Consoleのサイトマップとカバレッジの監視、青緑デプロイとロールバック手順の訓練、これらを文章化し、リハーサルで欠落を洗い出すだけでも事故率は大きく下がります⁵¹。

# ヘッダー健全性のスポットチェック例
curl -I https://example.com/category/a/
# 期待: 200 / noindexなし / Cache-Control, ETag適正
curl -I https://example.com/old-category/alpha
# 期待: 301 → Location: https://example.com/category/a/

生成の自動化も、事故の再発防止に有効です。リダイレクト表はスプレッドシート起点ではなく、ソース管理下の宣言ファイルとして扱い、CIで重複や循環、自己参照を拒否します。canonicalやhreflangもスナップショットテスト化して、レンダリング結果を比較できるようにすると、人の目だけに頼らずに品質を担保できます。小さな自動化の積み重ねが、移行の難易度を現実的なものにします。サイトマップはジョブで差分生成し、公開直後にSearch Console APIで送信まで自動化すると、初動のクロールが安定します¹。

よくある事故の芽を事前に摘む小技

メタのnoindexは環境変数で明示し、ビルド時に強制的に挿入・削除するフラグを作ると解除忘れを防げます。クリティカルCSSはルートごとに分割し、LCP候補のスタイルのみをインライン化するだけで、体感の改善が得られます。画像はCMSでのアップロード時に自動でAVIFやWebPを生成し、テンプレートはtypeヒントとともにで最適な候補を提示すると運用負荷が下がります¹¹。必要に応じてSearch Console APIを用い、サイトマップの送信や再クロールリクエストの初動を自動化しておくと、移行直後の安定度が上がります¹。

<!-- pictureでのフォーマット自動切替 -->
<picture>
  <source type="image/avif" srcset="/img/hero.avif">
  <source type="image/webp" srcset="/img/hero.webp">
  <img src="/img/hero.jpg" width="1200" height="630" alt="製品の概要" loading="eager" fetchpriority="high">
</picture>

このように、やってはいけないことの多くは、高度な魔法ではなく、地に足の着いた設計と検証の不足に起因します。だからこそ、エンジニアリングリーダーが先回りしてガードレールを敷き、移行を制御可能な単位に分解することが、トラフィックと売上を守る一番の近道になります。

まとめ：壊さない勇気が、成長の最短距離になる

サイトのリニューアルは、攻めと守りの綱引きです。機能刷新やブランド表現を磨くほど、既存の評価や流入は壊れやすくなります。だからこそ、やってはいけないことを先に明文化し、ガードレールを自動化で固める姿勢が、結果として攻めの速度も上げます。今日できる一歩として、重要URLの棚卸し、301マッピングのドラフト、ステージング遮断の二重化、LCP候補の特定と最適化、そしてロールバック手順の通し稽古を予定に入れてください。小さな準備が、明日の大きな損失を確実に回避します。次にあなたが移行に臨むとき、どのガードレールから敷きますか。その問いにチームで答えを出す瞬間から、成功確率は上がり始めます。