ホームページリニューアルで失敗する10の典型例｜兆候・原因・防ぎ方と、起きた後の立て直し（2026年）

リニューアルの失敗は、たいてい公開日には見えません。新しいサイトは見た目がよく、社内の評判も上々です。数字が落ち始めるのは、公開から数週間たってからです。

問い合わせが減った。検索から来る人が半分になった。スマホで開くと重い。英語版だけ古いまま残っている。こうした問題の多くは、公開の数か月前、企画や発注の段階で仕込まれています。

この記事では、リニューアルでよく起きる失敗を10のパターンに分け、それぞれを兆候・原因・防ぎ方・起きた後の立て直しの順で整理します。実在の企業を名指しした失敗談は扱わず、公開された調査と公式の案内だけを引きます。

この記事が主に根拠にした情報

• Google Search Central のサイト移転、多言語サイト、インデックス制御の案内
• web.dev の Core Web Vitals の閾値と Vodafone の事例、HTTP Archive「Web Almanac 2024」、WebAIM Million 2026
• W3C の WCAG 2.2、欧州アクセシビリティ法（指令 2019/882）、オランダ政府の事業者向けポータル business.gov.nl
• McKinsey とオックスフォード大学の IT プロジェクト調査（2012年）、内閣府・公正取引委員会・IPA の資料

この記事で分かること	答えの要点
リニューアルの「失敗」とは何か	成果が落ちる・予算と期間が膨らむ・運用できない・法令に合わないの4つ（第1章）
どんな失敗が多いか	目的不在から発注・契約まで10のパターン（第2章）
それぞれをどう防ぐか	兆候・原因・防ぎ方・立て直しを各章で整理（第3〜12章）
起きてしまったらどうするか	止血・原因の切り分け・修正・再発防止の4段階（第13章）
日本と欧州で何が違うか	法令の期限、多言語、契約の形が違う（第14章）

1. リニューアルの「失敗」を定義する

公開できなかったことだけが失敗ではない

途中で頓挫した案件より、予定どおり公開したのに目的を果たせなかったケースのほうがずっと多くあります。この記事では失敗を次の4つに分け、どれかに当てはまれば失敗の兆候と見ます。

失敗の種類	具体的な状態	表に出る時期
成果が落ちる	問い合わせ・売上・検索流入が旧サイトより減る	公開後2〜12週
予算と期間が膨らむ	追加見積もりが続き、公開日が延びる	制作の中盤以降
運用できない	更新が止まる、担当者がいない	公開後3〜6か月
法令に合わない	アクセシビリティや Cookie の指摘を受ける	時期を選ばない

失敗が表に出るのは、原因が仕込まれてからずっと後です。このずれが、失敗を分かりにくくしています。

大規模なITプロジェクトでも同じことが起きている

McKinsey とオックスフォード大学は、2012年に5,400件を超える IT プロジェクトを調べました。初期予算が1,500万ドルを超える大規模なものは、平均で予算を45%、期間を7%超過し、見込んだ価値より56%少ない価値しか生まなかったと報告しています。挙げられた原因（焦点の欠如、要件の変化、技能、実行）は、はるかに小さなサイトのリニューアルにもほぼそのまま当てはまります。

2. 10の失敗パターンの全体像

兆候と、仕込まれる段階を一覧にする

まず10のパターンを一覧にします。どの段階で仕込まれ、どんな兆候で気づけるかを並べたのが次の表です。

失敗パターン	早めに気づける兆候	仕込まれる段階
1. 目的がない	「何を良くするか」を一文で言えない	企画
2. デザインだけ変える	打ち合わせの大半が配色と写真の話	企画〜設計
3. 移行を後回しにする	原稿の担当と期限が決まっていない	設計
4. 計測が途切れる	重要な操作の一覧がない	実装
5. 検索流入が落ちる	URL の対応表がない	設計〜公開
6. 表示が遅くなる	速度の目標が要件にない	設計〜実装
7. 法令対応が漏れる	アクセシビリティの基準を誰も知らない	企画〜実装
8. 多言語が崩れる	英語版が「あとで翻訳」になっている	設計
9. 運用体制がない	公開後の担当者が決まっていない	企画
10. 発注・契約でつまずく	見積もりが「一式」だけ	発注

一覧で分かるのは、10のうち多くが企画と設計の段階で仕込まれることです。次の図は、仕込まれる段階と、表に出る時期の関係をまとめたものです。

3. 失敗1：目的がないまま始める

兆候と原因

最も多く、ほかの失敗の起点にもなるのがこれです。兆候は単純で、「このリニューアルで何を良くするのか」を一文で言えないことです。

「古くなったから」「競合が新しくしたから」は、きっかけであって目的ではありません。目的がないと、判断の基準が担当者や経営者の好みになります。

防ぎ方：目的を数字に置き換える

着手前に、目的を測れる数字に置き換えます。次の表は、よくある目的と、それを測る数字の対応です。

よくある目的	測る数字	公開前に保存するもの
問い合わせを増やす	月の問い合わせ件数、フォームの到達率	直近12か月の件数
採用を強くする	応募数、採用ページの閲覧数	直近12か月の応募数
欧州の顧客を増やす	国別の流入と問い合わせ	国別の数字
更新を社内でできるようにする	更新1件にかかる日数	現在の日数と依頼の流れ
表示を速くする	LCP・INP・CLS（スマホ）	PageSpeed Insights の結果

表の右端の列が大事です。旧サイトの数字を保存しておかないと、新しいサイトが良くなったのかを比べられません。

起きた後の立て直し

公開後に「何のためのリニューアルだったか」が曖昧だと気づいた場合も、遅くはありません。今からでも目標の数字を1〜2個決め、Search Console と GA4 で旧サイト時代の数字を可能な範囲で取り出し、リニューアルすべき10のサインの測り方で現状を点検し直します。

4. 失敗2：デザインだけ変える

兆候と原因

打ち合わせの大半が、配色・フォント・トップの写真の話で終わる。これが兆候です。見た目は社内の誰もが意見を言いやすいため、議論がそこに集まります。

一方で、問い合わせの数を左右するのは、たいてい見た目より情報の並びと導線です。どのページから来た人が、何を読んで、どこで連絡するのか。この流れが旧サイトと同じなら、見た目を変えても数字はあまり動きません。

防ぎ方：見た目と成果に効く部分を分けて議論する

デザインの議論を、成果に効く部分とそうでない部分に分けます。次の表は、リニューアルでよく変える要素を、成果への効き方で並べたものです。

要素	成果への効き方	確かめ方
ページの並び（情報設計）	大きい	ツリーテストで探せるか
問い合わせの導線・フォーム	大きい	完了までの手順と離脱
本文の中身・事例	大きい	検索語と読まれた時間
表示速度	中〜大	Core Web Vitals
配色・フォント・写真	小〜中	読みやすさ・コントラスト

表のとおり、成果に大きく効くのは目に見えにくい部分です。見た目を変えるなら、同時に情報設計と導線も見直すことを前提にします。

起きた後の立て直し

見た目だけ変えて公開した場合も、全面的にやり直す必要はありません。問い合わせが多い上位10ページの導線を見直します。フォームの項目を減らす、問い合わせボタンを本文の途中にも置く、事例ページから連絡先へのリンクを足す。こうした小さな改修のほうが、もう一度デザインを変えるより効くことが多くあります。

5. 失敗3：コンテンツ移行を後回しにする

兆候と原因

デザインと実装が進んでいるのに、原稿の担当者と期限が決まっていない。これが兆候です。

コンテンツ移行は、ページを1枚ずつ確かめて、残す・直す・まとめる・消すを決める作業です。単純に見えて、旧サイトのページ数に比例して時間がかかります。後回しにすると、公開直前に大量の手作業が発生し、公開日が延びるか、質の低い移行で妥協することになります。

防ぎ方：最初に棚卸しをする

最初の作業として、コンテンツの棚卸しを行います。Nielsen Norman Group は、まず全ページを一覧にした台帳（インベントリ）を作り、そのうえで品質を評価する監査（オーディット）を行うよう説明しています。

台帳には、タイトル、URL、担当者、主題、更新日、メタ情報を並べます。そこに検索流入と問い合わせの数字を足すと、判断がしやすくなります。

判断	目安となる条件	旧URLの扱い
残す	流入や問い合わせがあり、内容も正しい	新URLへ301
直す	流入はあるが、内容が古い	直して新URLへ301
まとめる	似たページが複数ある	統合先へ301
消す	流入がなく、役目も終わった	410か404。無関係なページへ転送しない

「消す」と決めたページを、トップページにまとめて転送するのは避けます。Google は、関係のないページへの転送をソフト404（実質的に存在しないページ）として扱うことがあると案内しています。

起きた後の立て直し

移行が間に合わず、旧サイトのページを大量に消したまま公開してしまった場合は、Search Console の「ページ」レポートで404になった URL を確かめます。流入が多かった順に、新しいページへのリダイレクトを足すか、内容を戻します。

6. 失敗4：計測が途切れる

兆候と原因

リニューアルの後で「問い合わせが減った気がする」と言われても、数字で確かめられない。これが計測の途切れです。

原因の多くは、新しいサイトに計測タグを入れ直したものの、問い合わせ完了などの重要な操作の記録が抜けていることです。フォームの仕組みが変わると、旧サイトで動いていた記録の設定はそのまま使えません。

GA4 の保存期間にも注意が必要です。標準のプロパティでユーザー単位とイベント単位のデータを保存できる期間は2か月か14か月で、探索レポートはこの設定の影響を受けます。設定を確かめずにいると、新旧を比べたいときに古いデータが残っていないことがあります。

また、旧来の Universal Analytics は、標準のプロパティで2023年7月1日にデータの処理を終えています。旧サイトに古いタグしか入っていなかった場合、その時期以降の数字はそもそも記録されていません。

防ぎ方：公開前に「測る操作」の一覧を作る

公開前に、測るべき操作の一覧を作り、テスト環境で1つずつ動くかを確かめます。

確認する項目	公開前にやること	見落としたときの影響
重要な操作（問い合わせ完了など）	新旧で同じ名前のイベントにする	新旧の比較ができない
GA4 のデータ保存期間	14か月に設定されているか確かめる	1年前と比べられない
Search Console の所有権	新ドメイン・新URLでも確認する	公開後の不具合に気づけない
Cookie の同意の仕組み	同意前に計測が動かないか確かめる	法令違反、または計測ゼロ
旧サイトの数字	直近12か月以上を書き出して保存	比べる基準がなくなる

表の4行目は欧州向けのサイトで特に大事です。同意前の計測は法令の問題になり、設定を誤れば計測が止まります。

起きた後の立て直し

計測の抜けに気づいたら、その日のうちにタグを直します。失った期間のデータは戻りませんが、問い合わせの件数は、メールや CRM の受信記録から数え直せることがあります。

数え直した件数を、リニューアル前後で月ごとに並べると、少なくとも「減ったのかどうか」は判断できます。計測の監視を自動化する方法は、Search Console と GA4 の監視を自動化する記事でまとめています。

7. 失敗5：検索流入が急に落ちる

兆候と原因

公開から1〜2週間で、検索からの流入が目に見えて落ちる。

Google はサイト移転のガイドで、移転中は検索での掲載が一時的に揺れることがあると案内しています。新しい URL が表示されるようになるまで、数週間以上かかることもあります。つまり、ある程度の揺れは想定の範囲です。

ただし、大きな急落の多くは揺れではなく、設定の漏れです。よくある原因は次の4つです。

原因	確かめる場所	直し方
旧URLのリダイレクト漏れ	旧URLの一覧を巡回して状態を見る	301で対応する新URLへ
robots.txt・noindex の消し忘れ	新サイトの robots.txt と各ページの meta	テスト用の制限を外す
canonical・サイトマップの誤り	ソースとサイトマップの URL	本番の新URLに揃える
本文の大幅な削減	上位ページの新旧の比較	削った情報を戻す

Google はガイドのなかで、移転のためだけに必要だった noindex や robots.txt の制限を外し忘れないようにと念を押しています。テスト環境の設定がそのまま本番に持ち込まれるのは、それほどよくある失敗だということです。

防ぎ方：URL の対応表を最初に作る

防ぎ方の中心は、旧URLと新URLの対応表（リダイレクトマップ）です。コンテンツの棚卸し（第5章）と同じ台帳から作れます。

Google はリダイレクトをできるだけ長く、一般には少なくとも1年残すよう案内しています。リダイレクトの種類や設定例、Search Console のアドレス変更ツールの使い方は、301リダイレクトの記事で詳しく扱っています。

起きた後の立て直し：落ち方で動き方を変える

流入が落ちたときは、落ち方の大きさで動き方を変えます。次の図は、DevNJ が使っている判断の目安です。季節の波があるため、比べるのは前年の同じ時期か、公開直前の4週の平均にします。

落ち幅が大きいときの立て直しは、次の順に進めます。

1. Search Console で、クリックが落ちたページの上位20件を出す
2. その旧URLを1つずつ開き、正しい新URLに301で転送されるかを確かめる
3. 新サイトの robots.txt と、上位ページの noindex・canonical を確かめる
4. 直した URL を URL 検査ツールで再クロールに回す
5. 1週間ごとに、同じ20件のクリックを記録して戻り方を見る

報告事例として、Search Engine Journal はドメイン移転892件を調べ、元の流入に戻るまでの平均を523日と報じています。報告事例の平均で目安にすぎませんが、ドメインまで変える移転は回復に長くかかり得ます。

8. 失敗6：表示速度が悪くなる

兆候と原因

新しいサイトのほうが、旧サイトより遅い。意外に多い失敗です。大きな写真や動画、動きのある演出、チャットや広告の外部タグが、確認なしに積み重なるためです。

制作の現場では、速い回線とパソコンで確認するので、遅さに気づきにくくなります。実際の利用者は、移動中のスマホで開いています。

防ぎ方：合格ラインを要件に書く

web.dev は、Core Web Vitals の「良好」の閾値を、実際の利用者の75パーセンタイルで次のように示しています。この数字を、リニューアルの要件と検収の基準にそのまま書きます。

指標	何を測るか	良好の閾値
LCP	主要な内容が表示されるまでの時間	2.5秒以下
INP	操作への反応の速さ	200ミリ秒以下
CLS	表示中のレイアウトのずれ	0.1以下

速度は珍しい問題ではありません。HTTP Archive の「Web Almanac 2024」によると、3つの指標すべてで良好だったサイトは、スマホで43%、パソコンで54%でした。半分前後のサイトが合格していないことになります。

速度が成果に効いた公開事例

速度の改善が成果につながった公開事例として、web.dev は Vodafone のケースを紹介しています。2021年に公開された事例では、LCP を31%改善した版で、売上が8%、リードの到達率が15%、カートの到達率が11%増えたと報告されています。

これは大企業の EC の事例で、同じ割合が中小企業のサイトで出るとは限りません。それでも、速度が「見た目の好み」ではなく成果の数字に効くことを示す材料にはなります。

起きた後の立て直し

公開後に遅くなったと分かったら、PageSpeed Insights で上位ページを測り、原因の大きい順に手を打ちます。多くの場合、効くのは次の3つです。

• トップの大きな画像を、適切な寸法と形式に置き換える
• 使っていない外部タグ（過去のキャンペーン用など）を外す
• 画面上部の動画やスライダーを、静止画に置き換える

9. 失敗7：アクセシビリティと法令対応が漏れる

兆候と原因

「アクセシビリティは次の改修で」「Cookie のバナーは公開してから考える」。こうした先送りが兆候です。どちらも、後から足すと設計とデザインに手戻りが出ます。

WebAIM が2026年2月に上位100万サイトのトップページを調べた結果では、95.9%で WCAG の不適合が自動検出されました。最も多かったのはコントラスト不足（83.9%）で、代替テキストの欠落、フォームのラベルの欠落が続きます。リニューアルで新しいデザインを作るときこそ、こうした問題を一度に解消できる機会です。

日本と欧州で、期限のある法令が増えている

ここ数年で、サイトに関わる法令の期限が日欧の両方で続いています。次の図は、リニューアルの要件に関わる主な日付を並べたものです。

それぞれの内容を、日本・EU・オランダに分けて整理したのが次の表です。

地域	法令・指針	サイトへの影響
日本	改正障害者差別解消法（2024年4月1日施行）	事業者の合理的配慮が義務に。Web も環境の整備の一部
日本	電気通信事業法の外部送信規律	対象事業者は、外部送信の内容の公表などが必要
EU	欧州アクセシビリティ法（2025年6月28日適用）	消費者向けの EC・予約・銀行などが対象
オランダ	同法の国内の監督	EC は消費者・市場庁（ACM）が監督。アクセシビリティ声明が必要
オランダ	Cookie と GDPR	AP がバナーを点検。同意前の追跡は違反になり得る

欧州アクセシビリティ法では、従業員10人未満で、年間売上高または貸借対照表の合計が200万ユーロ以下の零細事業者が提供するサービスは義務の対象外です（指令 2019/882 第4条）。日本の会社でも、EU の消費者に向けて EC などのサービスを提供していれば対象になり得ます。

防ぎ方：基準を要件に書く

アクセシビリティは、W3C の WCAG 2.2 の AA を基準として要件に書くのが一般的です。基準が書かれていないと、制作会社は見積もりようがありません。

Cookie は、「拒否が同意と同じくらい簡単か」「同意の前に計測や広告のタグが動いていないか」を公開前の確認項目に入れます。オランダの AP は、1万サイトのバナーを自動で調べ、200を超えるサイトに警告を送ったと発表しています。

起きた後の立て直し

公開後に不備が見つかった場合は、まずフォームのラベル、キーボード操作、コントラストから直します。W3C の WAI は、簡易な確認から専門家の評価まで、段階に応じた評価の方法を公開しています。

10. 失敗8：多言語が崩れる

兆候と原因

日本語版だけ新しくなり、英語版は旧サイトのまま。英語版のURLが日本語版と対応していない。言語の切り替えボタンを押すとトップページに飛ぶ。これらが多言語の崩れです。

原因は、多言語を「日本語版ができたら翻訳する」作業として扱うことです。言語ごとの URL の構造、切り替えの仕組み、翻訳の担当と更新の流れは、設計の段階で決めておかないと、後から揃えるのが大変です。

Google の案内とよくある崩れ方

Google は多言語サイトについて、いくつかのはっきりした案内を出しています。次の表は、よくある崩れ方と、それに対応する Google の案内です。

よくある崩れ方	Google の案内	防ぎ方
ブラウザの言語で自動転送する	推測した言語で自動的に転送しない	切り替えは利用者に選ばせる
1つのURLで言語を切り替える	言語ごとに別のURLを使う	/ja/ と /en/ などに分ける
定型部分だけ翻訳する	本文が1言語のままだと体験が悪い	本文まで翻訳する
対訳の対応が崩れる	hreflang で言語版どうしを示す	相互にリンクする
切り替えでトップに飛ぶ	—	同じページの別言語へ飛ばす

表の1行目は、欧州向けのサイトで特に多い失敗です。

防ぎ方：言語を設計の単位にする

多言語サイトのリニューアルでは、ページの一覧を言語ごとに作り、「どのページとどのページが対訳か」を最初に決めます。この対応表は、hreflang の設定にも、リダイレクトマップにもそのまま使えます。

翻訳を自動化する場合の設計と注意点は、日英2言語サイトの翻訳を自動化する記事で扱っています。

起きた後の立て直し

崩れてしまった場合は、まず自動転送を止めます。そのうえで、言語版どうしの対応表を作り直し、hreflang と切り替えボタンのリンク先を揃えます。

11. 失敗9：公開後の運用体制がない

兆候と原因

公開した瞬間がゴールになっていて、公開後に誰が何をするかが決まっていない。これが兆候です。お知らせが半年止まる、事例が増えない、フォームのエラーに誰も気づかない、といった形で表に出ます。

原因は、リニューアルが「プロジェクト」として予算化され、運用が「誰かの片手間」に残されることです。

防ぎ方：役割と頻度を表にしておく

公開前に、運用の役割と頻度を表にします。担当者の名前が入らない行は、そのまま止まると考えてください。

役割	頻度	主な作業
更新担当	週1回	お知らせ・事例・採用情報の更新
数字の担当	月1回	問い合わせ・流入・速度の確認と共有
技術の保守	月1回	CMS とプラグインの更新、バックアップ
法令の確認	年1〜2回	Cookie・プライバシー・アクセシビリティ声明
翻訳の担当	更新のたび	他言語版への反映

起きた後の立て直し

運用が止まってしまった場合は、全部を一度に再開しようとしないことです。まず月1回の「数字の確認」だけを再開し、その数字をもとに、次に手を入れるページを1〜2件決めます。

12. 失敗10：発注と契約でつまずく

兆候と原因

見積書が「Web サイト制作一式」だけで、何が含まれるかが分からない。修正の回数や、変更が出たときの扱いが書かれていない。こうした発注のあいまいさは、制作の中盤で追加費用と納期の延長として表に出ます。

原因は、作業の範囲が決まらないまま価格だけで比べることです。見積書の読み方は、リニューアルの費用相場と見積もりの記事で11項目に分けて解説しています。

防ぎ方：契約で決めておく5つのこと

契約の前に、少なくとも次の5つを書面で決めます。

決めること	決めないと起きること	書き方の例
作業の範囲	移行やリダイレクトが範囲外になる	移行するページ数、リダイレクト件数
成果物と検収の基準	「完成」の定義で揉める	速度・アクセシビリティの合格ライン
変更の扱い	追加費用が積み上がる	時間単価と、承認の手順
公開後の保守	不具合の対応が有償か無償か曖昧	保守の範囲と期間、対応時間
名義と権利	ドメインやコードを引き取れない	ドメイン・サーバー・CMS の名義は発注者

日本では、制作の契約が請負（完成に責任を負う）か準委任（作業の遂行に責任を負う）かで、責任の形が変わります。IPA は情報システムの開発について、段階ごとの責務を解説したモデル取引・契約書を公開しています。

個人のフリーランスに発注する場合、日本では2024年11月1日に施行されたフリーランス法により、発注側に給付の内容・報酬の額・支払期日などを明示する義務があります。オランダの制作会社に頼む場合、総額より時間単価で見積もられることが多く、制作会社の平均で1時間€106、フリーランスの Web 開発者で€73（いずれも税抜）という調査があります。

起きた後の立て直し

すでに範囲で揉めている場合は、残りの作業を一覧にして、範囲内・範囲外・未決定に分けることから始めます。

制作会社との関係が続けられない場合は、ドメイン・サーバー・CMS・ソースコードの名義と管理者アカウントを先に確保します。これがないと、別の会社に引き継ぐこともできません。

13. 起きてしまった後の立て直し：共通の4段階

慌てて元に戻さない

公開後に数字が落ちると、「旧サイトに戻そう」という声が出ます。しかし、旧サイトに戻すと URL がもう一度変わり、検索の評価がさらに揺れます。元に戻すのは、原因を調べてからでも遅くありません。

10のパターンに共通する立て直しの流れを、4つの段階にまとめたのが次の表です。

段階	期間の目安	やること
1. 止血	当日〜3日	robots.txt・noindex・計測タグ・フォームの動作を確かめる
2. 原因の切り分け	1〜2週	落ちたページと時期を特定し、10のパターンに当てはめる
3. 修正	2〜6週	リダイレクト・本文・速度・導線を、影響の大きい順に直す
4. 再発防止	1〜3か月	チェックリストと運用の役割を見直す

期間は DevNJ の経験にもとづく目安で、サイトの規模や原因によって変わります。

立て直しにかかる工数と費用の幅

立て直しの費用は、原因によって大きく違います。次の表は、よくある修正の工数の目安を、オランダの時間単価の調査（€73〜€106）で金額に置き換えたものです。

修正の内容	工数の目安	費用の幅（税抜）
robots.txt・noindex の修正	1〜2時間	€73〜€212
計測タグとイベントの入れ直し	4〜8時間	€292〜€848
上位ページのリダイレクト追加（〜100件）	4〜12時間	€292〜€1,272
上位ページの速度改善	8〜24時間	€584〜€2,544
アクセシビリティの主要な修正	16〜40時間	€1,168〜€4,240

工数は DevNJ の目安で、実際の見積もりはサイトの仕組みと件数で変わります。円へはその時点の為替で換算してください。表から分かるのは、設定の漏れは安く直せるが、設計からの手戻りは高くつくということです。

14. 日本と欧州で、失敗の出方が違うところ

同じ失敗でも、重さが違う

日本と欧州の両方に向けたサイトでは、同じ失敗でも影響の出方が違います。特に、法令・多言語・計測の3つで差が出ます。

項目	日本向けのサイト	欧州向けのサイト
アクセシビリティ	合理的配慮の義務化。Web の基準は JIS X 8341-3 が参照される	欧州アクセシビリティ法。WCAG 2.2 に沿った対応が実務の目安
Cookie と計測	外部送信規律（対象事業者）	同意前の追跡は違反になり得る。当局が点検
多言語	日本語のみのことが多い	英語・現地語の2〜3言語が普通
検索エンジン	Google と Yahoo! JAPAN（Google の技術）	Google が中心。Bing も一定の割合
契約の形	請負・準委任。フリーランス法	時間単価の積み上げが多い

欧州向けのサイトでは同意前の計測が法令の問題になるため、失敗4と失敗7が同時に起きやすくなります。同意の仕組みと計測は、同じ担当者が見るのが安全です。

15. ケースで考える（架空の例）

ここからは、架空の会社を使って、失敗がどう連鎖し、どう立て直すかを見ます。実在の会社や事例ではありません。

ケースA：デザインだけ変えて、問い合わせが半分になった製造業の会社

日本の部品メーカーA社は、競合の新しいサイトに刺激され、トップページの写真とデザインを全面的に変えました。公開から2か月で、問い合わせが月20件から10件に減りました。

問い合わせの多かった「技術資料」のページが移行の際に消され、検索から来た技術者が行き止まりになっていました。A社は、資料ページを元のURLの近くに戻して301で転送し、資料のページから問い合わせへの導線を足しました。

ケースB：英語版の自動転送で、オランダの利用者が迷ったサービス業の会社

オランダに拠点を置く日系のサービス会社B社は、リニューアルで、ブラウザの言語に応じた自動転送を入れました。その結果、オランダ語の設定のパソコンで開いた日本人の利用者が、日本語版に入れなくなりました。

B社は自動転送をやめ、最初の訪問時に言語を選べる案内を出すように変えました。あわせて、hreflang を相互に設定し直しました。

ケースC：契約の範囲があいまいで、公開が3か月延びた小売の会社

EU の消費者に向けてオンライン販売を行うC社は、「一式」の見積もりで制作会社に発注しました。制作の中盤で、旧サイトの商品ページ800件の移行が範囲外だと分かり、追加費用と納期の延長が発生しました。

ケース	主な失敗	立て直しの中心
A社（製造業）	2 デザイン偏重、3 移行の後回し	消えたページの復元と301、導線の追加
B社（サービス業）	8 多言語の崩れ	自動転送の停止、hreflang の再設定
C社（小売）	10 契約、7 法令	範囲の再定義、アクセシビリティの要件化

16. 公開前後のチェックリスト

最後に、10のパターンを防ぐための確認項目をまとめます。公開の1か月前と、公開の当日、公開後90日に分けて使ってください。進め方の段取りそのものは、リニューアルの進め方とスケジュールの記事で詳しく扱っています。

企画・発注の段階

• リニューアルの目的を一文で言え、測る数字が決まっている
• 旧サイトの直近12か月以上の数字を書き出して保存した
• 見積もりに、移行・リダイレクト・多言語・アクセシビリティ・保守が含まれている
• 公開後の役割と担当者の名前が決まっている

設計・実装の段階

• 全ページの台帳があり、残す・直す・まとめる・消すが決まっている
• 旧URLと新URLの対応表がある
• 速度（LCP・INP・CLS）とアクセシビリティ（WCAG 2.2 AA）の合格ラインが要件にある
• Cookie の同意の前に計測や広告のタグが動かない

公開当日と公開後90日

• robots.txt と noindex にテスト用の制限が残っていない
• 旧URLの上位ページが、正しい新URLに301で転送される
• 問い合わせ完了などの重要な操作が記録されている
• 公開後4週・8週・12週に、目的の数字を旧サイトと比べる

まとめ

• リニューアルの失敗は、成果が落ちる・予算と期間が膨らむ・運用できない・法令に合わないの4つに分けて考える
• 10の失敗パターンの多くは、企画と設計の段階で仕込まれ、公開後90日のあいだに表に出る
• 起点になりやすいのは目的の不在。着手前に、何の数字をどれだけ動かすかを決め、旧サイトの数字を保存する
• コンテンツの棚卸しとURLの対応表は、移行・リダイレクト・多言語の3つの失敗をまとめて防ぐ
• 発注では、範囲・検収・変更・保守・名義の5つを書面で決める

参考にした情報源

検索・計測（Google ほか）

• URL の変更を伴うサイト移転 — Google Search Central：掲載の一時的な揺れ、数週間以上という期間、リダイレクトを少なくとも1年、noindex と robots.txt の外し忘れ
• 多地域・多言語のサイトを管理する — Google Search Central：自動転送をしない、言語ごとに別のURL、定型部分だけの翻訳を避ける
• ページのローカライズ版について Google に知らせる — Google Search Central：hreflang の設定
• noindex で検索インデックス登録をブロックする — Google Search Central：noindex の仕組み
• robots.txt の概要 — Google Search Central：robots.txt の役割
• HTTP ステータスコードとネットワークエラー — Google Search Central：ソフト404の扱い
• アドレス変更ツール — Search Console ヘルプ：ドメインを変える移転の手続き
• Universal Analytics の終了 — Google アナリティクス ヘルプ：2023年7月1日の処理終了
• データ保持 — Google アナリティクス ヘルプ：GA4 の保存期間（2か月・14か月）と影響範囲
• ドメイン移転892件の回復期間の調査 — Search Engine Journal：回復までの平均523日（報告事例）

速度・アクセシビリティ

• Web Vitals — web.dev：LCP・INP・CLS の閾値と75パーセンタイル
• Vodafone の事例 — web.dev：LCP 31%改善で売上8%増
• PageSpeed Insights：速度の計測
• Web Almanac 2024 Performance — HTTP Archive：Core Web Vitals の合格率（スマホ43%、パソコン54%）
• WebAIM Million — WebAIM：上位100万サイトの95.9%で不適合を検出
• WCAG 2.2 — W3C：アクセシビリティの基準
• Evaluating Web Accessibility — W3C WAI：評価の方法

法令・制度

• 指令 (EU) 2019/882 — EUR-Lex：欧州アクセシビリティ法の本文、零細事業者の除外、適用日
• European Accessibility Act — 欧州委員会：対象となる製品とサービス
• European Accessibility Act — business.gov.nl：オランダでの監督機関（ACM ほか）とアクセシビリティ声明
• AP pakt misleidende cookiebanners aan — Autoriteit Persoonsgegevens：Cookie バナーの点検
• Cookie バナーの点検結果 — Autoriteit Persoonsgegevens：警告後の修正状況
• 改正障害者差別解消法 — 内閣府：2024年4月1日からの合理的配慮の義務化
• 外部送信規律 — 総務省：電気通信事業法の外部送信規律
• フリーランス・事業者間取引適正化等法 — 公正取引委員会：取引条件の明示義務

プロジェクト・発注

• Delivering large-scale IT projects on time, on budget, and on value — McKinsey：5,400件超の調査、予算45%超過・価値56%不足
• 情報システム・モデル取引・契約書 — IPA：段階ごとの責務とモデル契約
• Content Audits — Nielsen Norman Group：棚卸し（インベントリ）と監査（オーディット）
• Benchmark report Agencies Q4 2025 — Simplicate：オランダの制作会社の平均時間単価（€106）
• Web developer zzp の時間単価 — Knab：フリーランスの Web 開発者の時間単価（€73）

いずれも2026年10月26日に確認したものです。法令の運用と数値は変わるため、判断の前に公式サイトで最新の情報を確認してください。