ホームページリニューアルの流れとスケジュール｜7つのフェーズと期間の目安、発注側の準備物、遅れる原因、公開後90日の運用計画（2026年）

ホームページのリニューアルを決めたあと、最初に聞かれるのは「いつ公開できるのか」です。ところが、制作会社に聞いても「規模によります」という答えが返ってきて、社内の予定が立てられないことがよくあります。

期間が読みにくいのは、作業の量より判断と準備の待ち時間が長いからです。原稿が揃わない、決裁者が途中で意見を変える、旧サイトのサーバー情報が見つからない。こうした待ち時間は、制作会社の作業見積もりには入っていません。

この記事では、リニューアルを7つのフェーズに分け、それぞれの期間の幅、成果物、発注側と制作側の役割、決めるべきことを整理します。そのうえで、遅れる原因と対策、公開後90日の運用計画までを扱います。リニューアルすべきかの判断は「ホームページをリニューアルすべき10のサイン」、費用は「リニューアルの費用相場と見積もりの読み方」、URL変更の手順は「検索順位を落とさないリニューアル」、CMSの乗り換えは「WordPressから移行するか続けるかの判断基準」で詳しく扱っています。

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

• Google Search Central「URL の変更を伴うサイト移転」（2026年8月20日更新）と、アドレス変更ツール・noindex の案内
• GOV.UK Service Manual のフェーズ定義（discovery・alpha・beta・live）
• Nielsen Norman Group のユーザビリティテスト、コンテンツ監査、ツリーテストの記事
• W3C の WCAG 2.2 と評価方法の案内、欧州アクセシビリティ法（指令 (EU) 2019/882）
• McKinsey とオックスフォード大学による IT プロジェクト 5,400件超の調査（2012年）

1. リニューアルはどんな段階で進むか

7つのフェーズと公開後90日

制作会社ごとに呼び方は違いますが、リニューアルの中身はおおむね同じ段階をたどります。この記事では、次の7つのフェーズと、公開後の運用期間に分けて考えます。

英国政府のデジタルサービスの手引き（GOV.UK Service Manual）は、サービスの開発を discovery（調査）、alpha（試作）、beta（本番の構築と試用）、live（運用）、retirement（終了）の段階に分けています。Web サイトのリニューアルはそれより小さな仕事ですが、「作る前に調べる」「本番の前に試す」「公開後も改善を続ける」という考え方はそのまま使えます。

表の右端は対応の目安です。GOV.UK の段階はもっと大きな行政サービスを想定しているので、名前だけを借りるのではなく、各段階の目的（調べる・試す・作る・運用する）を合わせて読んでください。

中規模サイトのガントチャート

20〜60ページ、日本語と英語の2言語、問い合わせフォームと簡単な CMS を持つ企業サイトを例に、フェーズを週単位で並べたのが図1です。前のフェーズが終わる前に次を始める重なりがあるのが普通で、その重なりの部分で判断の待ちが起きると全体が延びます。

図1の例では、公開まで約20週（約5か月）です。このうち制作会社だけで進められる作業は半分ほどで、残りは発注側の判断・原稿・確認を待つ時間を含んでいます。この配分が、スケジュールの読み方の出発点になります。

2. 期間の目安：規模別の幅

規模ごとの期間

リニューアルの期間について、公的な統計はありません。下の表は、範囲の違いでどのくらい期間が変わるかを示すための目安です。費用の幅は「リニューアルの費用相場と見積もりの読み方」で扱っています。

規模が1段上がるごとに期間がおおむね倍になるのは、ページ数より関わる人と決めることが増えるためです。2言語になると原稿の確認者が2組になり、外部システムと連携すると相手側の予定にも合わせることになります。

フェーズごとの配分

規模が違っても、時間の配分には傾向があります。次の表は、小規模と中規模の例で、フェーズごとの週数を並べたものです。

重なりがあるため、合計は単純な足し算より短くなります。目を向けてほしいのは右端の列で、発注側の負荷が高いのはフェーズ2と3です。ここで社内の時間を確保できるかどうかが、全体の期間を決めます。

3. フェーズ1：準備と現状把握

目的を1文で書く

最初のフェーズでやるのは、作ることではなく調べることです。GOV.UK は discovery について、解くべき問題を理解する前に作り始めないこと、期間は決まっていないが4〜8週程度が一般的であることを示しています。企業サイトのリニューアルなら、2〜4週で足りることが多いです。

最初に、リニューアルの目的を1文で書きます。「古いから新しくしたい」では、後で判断の基準になりません。「欧州の問い合わせを月10件から20件に増やす」「採用ページから応募までの離脱を減らす」のように、何が変われば成功かが分かる形にします。

現状の数字を保存する

公開後に「良くなったのか」を判断するには、公開前の数字が要ります。ここで注意したいのは、データには保存期間があることです。Google Search Console の検索パフォーマンスのデータは直近16か月分で、それより古いものは自分で書き出して保存しておく必要があります。Google アナリティクス 4（GA4）の探索レポートで使うイベント単位のデータの保持期間は、2か月か14か月から選ぶ設定です。

コンテンツの棚卸し

Nielsen Norman Group は、コンテンツの一覧（インベントリ）と、その質を評価する監査（オーディット）を分けて考えるよう勧めています。一覧はクローラーや CMS の書き出しで自動化でき、評価は人が1件ずつ行います。監査の結果は、各ページを残す・直す・消すのどれにするかで記録します。

同じ記事は、最初から全部をやろうとせず、6週間などの期限を区切って、よく読まれているページから始めることも勧めています。数百ページあるサイトでは、アクセスの上位と、問い合わせにつながるページから手を付けると、フェーズ3の原稿計画に早くつなげられます。

4. フェーズ2：要件定義

決める項目

要件定義は、何を作り、何を作らないかを決めるフェーズです。ここで決めた内容が見積もりとスケジュールの土台になります。決める項目を、機能だけでなく品質の基準まで含めて並べます。

品質の基準は数字で書く

「速いサイト」「誰でも使えるサイト」と書くと、公開前のテストで合否を判断できません。基準は数字か規格名で書きます。

表示速度は、Google の Core Web Vitals の閾値が使えます。web.dev は、利用者の75パーセンタイルで、LCP（主要な内容の表示）2.5秒以下、INP（操作への反応）200ミリ秒以下、CLS（レイアウトのずれ）0.1以下を「良好」としています。web.dev はさらに、画像の容量やスクリプトの量の上限をパフォーマンス予算としてプロジェクトの初期に決めておくと、後の手戻りを防げるとしています。

アクセシビリティは、W3C の WCAG 2.2（2023年10月5日勧告、2024年12月12日更新）のレベルAAを基準にするのが一般的です。EU の消費者向けに EC などのサービスを提供する場合は、欧州アクセシビリティ法（EAA、指令 (EU) 2019/882）が2025年6月28日から適用されています。従業員10人未満で、年間売上高か貸借対照表の合計が200万ユーロ以下の零細事業者が提供するサービスは対象外です。自社が当てはまるかは、要件定義の段階で確認しておきます。

要件書とスケジュールは一緒に作る

要件が決まったら、制作会社はスケジュール案を出します。ここで発注側が確かめるのは、自社が担当する作業と期限が書かれているかです。制作会社の作業だけが並んだスケジュールは、原稿や確認の待ち時間を見込んでいません。

要件定義の終わりに、最初の意思決定（第12章の「要件の確定」）を行います。ここで範囲を固め、それ以降の追加は変更として扱うことを双方で確認します。

5. フェーズ3：情報設計と原稿

ページ構成とナビゲーション

情報設計（IA）は、ページをどう分け、どう並べ、どの名前で呼ぶかを決める作業です。旧サイトの構成をそのまま写すと、古い組織図がメニューに残りがちです。利用者が探すもの（サービス、価格、事例、問い合わせ）を起点に組み直します。

Nielsen Norman Group は、提案したメニュー構成で利用者が目的のページを見つけられるかを、文字だけの階層で試すツリーテストを紹介しています。デザインや原稿がなくても実施でき、リニューアルの最初に現状の構成を測る、カードソートのあとで新しい構成を確かめる、原稿やレイアウトを作る前に構成を固める場面で使うよう勧めています。

URL の方針を決める

構成が決まると、新しい URL が決まります。URL を変えるなら、旧 URL と新 URL の対応表（リダイレクトマップ）をこのフェーズから作り始めます。作り方とステータスコードの使い分けは「検索順位を落とさないリニューアル」で詳しく扱っているので、ここではスケジュール上の位置だけを押さえます。

原稿の計画を立てる

原稿は、リニューアルでもっとも遅れやすい作業です。誰が書き、誰が確認し、いつまでに入れるのかを、ページごとに表にします。旧サイトの文章を流用するページ、書き直すページ、新しく書くページで、必要な時間が大きく違います。

翻訳は原稿が確定してから始めます。日本語の原稿を直しながら翻訳を進めると、翻訳のやり直しが重なります。2言語のサイトで期間が延びるのは、主にこの順番待ちのためです。

6. フェーズ4：デザイン

ワイヤーフレームから見た目へ

デザインは、画面の骨組み（ワイヤーフレーム）で情報の配置を決め、そのあとに色・文字・写真の見た目を作る順で進めます。いきなり見た目から始めると、色の好みの議論に時間を取られ、配置の問題が後で見つかります。

少人数のテストを繰り返す

Nielsen Norman Group の Jakob Nielsen は、2000年の記事で、5人のテストで使いやすさの問題のおよそ85%が見つかるとし、15人で1回より5人ずつ3回に分けて、間に修正をはさむほうがよいと書いています。リニューアルでは、ワイヤーフレームかプロトタイプの段階で1回、実装後に1回テストできると、公開後の大きな作り直しを避けやすくなります。

テストの相手は、社員ではなく、実際の顧客に近い人にします。欧州向けのページは、欧州の読み手に見てもらいます。日本の担当者が分かりやすいと感じる構成が、現地の読み手にも同じように伝わるとは限りません。

7. フェーズ5：実装とコンテンツ投入

テスト環境は検索に出さない

実装は、本番とは別のテスト環境（ステージング）で進めます。ここで起きやすい事故が、テスト環境が検索結果に出てしまうことと、その対策として入れた設定を本番に持ち込んでしまうことです。

Google は、検索に出したくないページには noindex を使うよう案内しています。ただし、robots.txt でクロールを禁止すると、Google は noindex の指定を読めず、他のサイトからリンクされていれば検索結果に出ることがあるとしています。テスト環境は、ベーシック認証などでアクセスそのものを制限するのが確実です。

CMS ができたら原稿と画像を入れます。発注側が入力すると公開後の更新の練習になりますが、慣れないうちは時間がかかります。CMS を乗り換える場合の段取りは「WordPressから移行するか続けるかの判断基準」で扱っています。

8. フェーズ6：テストと公開準備

テストの範囲

テストは、制作会社の内部確認と、発注側の受け入れ確認（検収）の2段で行います。発注側の確認は、要件書に書いた基準に照らして行います。要件書にない項目は、合否の判断ができません。

W3C は、アクセシビリティの評価を設計と開発の早い段階から繰り返し行うほど、問題を安く直せるとしています。自動チェックツールだけでは基準を満たすかを判断できず、人による確認と、障害のある利用者の参加が評価を確かなものにすると説明しています。

公開前の準備

公開日の前に、切り替えに必要な準備を済ませておきます。Google は、URL を変えずにサーバーを移す場合でも、DNS の TTL（反映の待ち時間の設定）を1週間ほど前に短くしておくこと、旧サーバーはアクセスがなくなるまで残すことを勧めています。

最後に、4つめの意思決定にあたる「公開の判定」を行います（第12章）。重大な不具合が残っていれば、公開日を動かす判断もここで行います。

9. フェーズ7：公開当日

当日の段取り

公開日は、問題が起きても数日続けて対応できる平日の前半にします。金曜日の夕方や、長期休暇の直前は避けます。当日の作業は、時刻と担当者を入れた表にしておきます。

Google への手続き

Google は、URL の変更を伴う移転で、リダイレクトを有効にする、新しいサイトマップを送る、ドメインを変える場合は Search Console のアドレス変更ツールを使う、といった手順を案内しています。アドレス変更ツールの効果は、移転を始めてから180日間続きます。手順の詳細は「検索順位を落とさないリニューアル」を参照してください。

10. 役割分担：発注側と制作側

誰が何を担当するか

リニューアルの遅れの多くは、誰の担当かが決まっていない作業から生まれます。原稿、写真、ドメインの管理、法令表示の文面などは、制作会社が「発注側の担当」と考え、発注側が「制作会社がやってくれる」と考えている、ということがよくあります。

発注側に必要な時間

発注側には、少なくとも窓口担当と決裁者の2つの役割が要ります。窓口担当は社内の意見をまとめ、制作会社とやり取りします。決裁者は、第12章の4回の意思決定で最終判断をします。

この時間はDevNJ の進行管理の経験にもとづく目安です。窓口担当の時間が確保できないと、制作会社からの質問への返答が遅れ、その分だけ全体が延びます。窓口担当の業務を、リニューアルの期間だけ減らしておくことが、もっとも効く遅れの対策の1つです。

11. 発注側が用意するもの

準備物の一覧と期限

発注側が用意するものを、必要になる時期の順に並べます。とくにアカウント情報と原稿は、見つからない・書けないことでフェーズが止まりやすいものです。

12. 意思決定のタイミング

4つのゲート

リニューアルで決めることは多いのですが、後から変えると高くつく決定は4つに絞れます。それぞれをフェーズの区切りに置き、日付と決める人を最初に決めておきます。

ゲートを機能させる3つの条件

ゲートは、日付を決めるだけでは機能しません。次の3つが揃っている必要があります。

1. 決める人が最初から関わっている：最後のゲートで初めて見た役員が方向を変えると、それまでの決定がすべて戻ります。
2. 判断の材料が事前に届いている：会議の場で初めて資料を見ると、その場で決められず、次の会議まで待つことになります。
3. 決めたことを記録している：何を決めたかの記録がないと、後で「聞いていない」が起きます。決定事項は日付つきで1枚にまとめます。

13. 遅れる原因と対策

大きなITプロジェクトの調査から分かること

McKinsey とオックスフォード大学は、2012年に5,400件を超える IT プロジェクトを調べ、初期予算1,500万ドルを超える大規模なものは、平均で予算を45%、期間を7%超過し、見込んだ価値より56%少ない価値しか生まなかったと報告しています。企業サイトのリニューアルはこれよりはるかに小さな仕事なので、数字をそのまま当てはめることはできません。

ただ、この調査が示しているのは「遅れより、目的からずれることの損失が大きい」という点です。リニューアルでも、期日を守るために範囲を削った結果、最初の目的（問い合わせを増やす、など）に効く部分が抜けてしまうことがあります。範囲を削るときは、第1フェーズで書いた目的の1文に照らして選びます。

遅れの原因の一覧

次の表は、リニューアルで遅れが起きやすい原因と、その兆候・対策・遅れの幅をまとめたものです。遅れの幅は DevNJ が見てきた範囲の目安です。

休暇と繁忙期を予定に入れる

日本と欧州の両方の担当者が関わる場合は、双方の休暇と繁忙期を最初に予定表に入れます。日本の年度末、ゴールデンウィーク、お盆、年末年始と、欧州の7〜8月の夏休み、クリスマスから年始にかけての期間は、確認や判断が止まりやすい時期です。

14. 公開後90日の運用計画

公開直後は揺れるのが普通

公開後しばらくは、検索からの流入や順位が揺れることがあります。Google は、URL の変更を伴う移転について、中規模のサイトでは新しい URL が古い URL に置き換わるまでに数週間以上、大規模なサイトではさらに長くかかることがあるとしています。リダイレクトは少なくとも1年は残すよう案内しています。

URL を変えずにサーバーだけを移した場合でも、Google は公開直後にクロールの頻度が一時的に下がるのは普通で、その後数日で戻り、以前より増えることもあるとしています。公開直後の数字だけを見て、慌てて構成を変えないことが大切です。

期間ごとに見るものと判断の基準

Google は移転後の監視として、サイトマップのレポートで新旧の URL の登録状況を見る、ページのインデックス登録のレポートで旧サイトの減少と新サイトの増加を確かめる、検索クエリのレポートで新しい URL に表示とクリックが付いているかを見る、サーバーのログで想定外のエラーを探す、といった方法を挙げています。これを期間ごとに割り振ったのが次の表です。

比べるときは、季節の影響を避けるため、前年の同じ時期や、同じ曜日を含む期間と比べます。Search Console のデータは16か月分なので、前年同期と比べられるように、公開前に書き出したデータと並べます。

90日で決めること

GOV.UK は live の段階を、サービスを持続的に支えながら改善を続ける段階としています。改善は利用者の調査にもとづき、ブラウザと端末での確認やアクセシビリティの確認を経て出すこと、公開前に決めた成功の指標で成果を見直すことを求めています。

リニューアルでも、90日の時点で次の3つを決めると、公開後の改善が途切れにくくなります。

15. 日本と欧州で段取りが変わるところ

進め方の慣習の違い

日本と欧州の両方に向けたサイトでは、スケジュールの組み方にも違いが出ます。優劣ではなく、条件の違いとして押さえておくと、双方の担当者の期待をすり合わせやすくなります。

2言語サイトで先に決めること

2言語のサイトでは、言語ごとの URL の形（/en/ のような階層にするかなど）、片方の言語にしかないページの扱い、翻訳の確認者を、フェーズ3のうちに決めます。公開後に言語の構造を変えるのは、URL の変更を伴うため、もう一度移転するのと同じ手間がかかります。

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

ここからは、立場の違う3つの架空の会社で、スケジュールの組み方を考えます。実在の会社ではありません。

ケースA：日本の製造業、英語ページを拡充したい

日本の機械部品メーカーA社は、日本語40ページ・英語8ページのサイトを、日英とも40ページに揃えたいと考えています。欧州の代理店からの問い合わせを増やすのが目的です。

英語ページの原稿が新規で32ページ分必要になるため、原稿と翻訳の期間がスケジュールを決めます。要件定義の段階で、英語の原稿を確認する欧州の代理店の担当者を決め、その人の夏休みの予定を確認しておくことが、遅れを防ぐ鍵になります。

ケースB：オランダの日本食品店、ECを始めたい

デン・ハーグにある日本食品店B社は、5ページの紹介サイトに EC を加えたいと考えています。EU の消費者に販売するため、欧州アクセシビリティ法の対象になるかを要件定義で確認します。従業員10人未満で売上高が基準以下であれば、サービスとしては対象外になり得ますが、将来の成長も見込んで、WCAG 2.2 AA を基準に作る判断もありえます。

ケースC：日本のサービス業、公開日が決まっている

C社は、新サービスの発表に合わせて、3か月後にサイトを公開したいと考えています。中規模の範囲では間に合わないため、公開時は主要10ページに絞り、残りを公開後90日のうちに追加する計画にします。リダイレクトの対応表と現状のデータの保存は削りません。

17. チェックリスト

始める前

• リニューアルの目的を1文で書き、成功の指標と現状の数値を添えた
• 決裁者と窓口担当を決め、窓口担当の時間を確保した
• Search Console と解析ツールのデータを書き出して保存した
• サーバー・ドメイン・CMS の管理画面の権限を揃えた
• 双方の休暇と繁忙期を予定表に入れた

制作中

• 4つのゲートの日付と決める人を決めた
• 要件書に、速度とアクセシビリティの基準を数字か規格名で書いた
• 原稿の担当と期限をページごとの表にした
• 翻訳は原稿の確定後に始める計画にした
• テスト環境にアクセス制限をかけた
• リダイレクトの対応表を作り、テストの予定を入れた

公開と公開後

• 公開日を平日の前半にし、数日続けて対応できる体制を組んだ
• DNS の TTL を約1週前に短くした
• 公開当日に noindex と認証を外したことを確認した
• 1週・30日・60日・90日の確認の予定を入れた
• リダイレクトを少なくとも1年残すことを保守の契約に書いた

まとめ

• リニューアルは、準備・要件定義・情報設計と原稿・デザイン・実装・テスト・公開の7つのフェーズと、公開後90日の運用で考えます。
• 公開までの期間は、部分改修で1〜4週、小規模で2〜3か月、中規模で3〜6か月、大規模で6か月以上が目安です。
• 発注側の負荷が高いのは要件定義と情報設計・原稿のフェーズで、窓口担当の時間を確保できるかが期間を決めます。
• 要件・構成と原稿・デザイン・公開の判定の4回の意思決定を、日付と決める人つきで先に決めておきます。
• 遅れの原因は、原稿の遅れ、決裁者の後からの参加、範囲の追加に集中します。範囲を削るときは目的の1文に照らして選びます。
• 公開後は、Google が中規模サイトで数週間以上かかるとする反映の期間を見込み、30日・60日・90日の区切りで、保存しておいた公開前の数字と比べます。

参考にした情報源

Google（検索とアクセス解析）

• URL の変更を伴うサイト移転 — Google Search Central：移転の手順、中規模サイトで数週間以上という反映の期間、リダイレクトを少なくとも1年残すこと、移転後の監視（2026年8月20日更新）
• URL を変更しないサイト移転 — Google Search Central：DNS の TTL を約1週前に短くすること、旧サーバーを残す期間、クロール頻度の一時的な低下
• noindex を使用してインデックス登録をブロックする — Google Search Central：robots.txt でブロックすると noindex が読まれないこと
• アドレス変更ツール — Search Console ヘルプ：効果が180日間続くこと、事前の条件
• Google 検索のトラフィック減少をデバッグする — Google Search Central：16か月の期間で比べること、データを書き出して保存する方法
• 新しい Search Console の紹介 — Google Search Central Blog：16か月分のデータを持つようになった経緯
• データ保持 — Google アナリティクス ヘルプ：GA4 のデータ保持期間（2か月または14か月）と対象

表示速度とアクセシビリティ

• Web Vitals — web.dev：LCP・INP・CLS の閾値と75パーセンタイル
• Performance budgets 101 — web.dev：パフォーマンス予算の種類と、初期に決める理由
• WCAG 2 Overview — W3C WAI：WCAG 2.2 の公開日と更新日、適合レベル
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C：達成基準の本文
• Evaluating Web Accessibility Overview — W3C WAI：早い段階から評価すること、ツールだけでは判断できないこと
• Directive (EU) 2019/882 — EUR-Lex：欧州アクセシビリティ法の本文、適用日、零細事業者の除外
• European accessibility act — European Commission：対象の製品とサービス

進め方とユーザー調査

• Agile delivery — GOV.UK Service Manual：discovery・alpha・beta・live・retirement の段階
• How the discovery phase works — GOV.UK Service Manual：discovery の目的と、4〜8週程度という期間
• How the alpha phase works — GOV.UK Service Manual：試作で前提を確かめること、6〜8週という期間
• How the beta phase works — GOV.UK Service Manual：限定公開から一般公開への進め方
• How the live phase works — GOV.UK Service Manual：公開後の改善と指標の見直し
• Why You Only Need to Test with 5 Users — Nielsen Norman Group：5人で問題の約85%、5人ずつ3回のテスト（2000年3月18日）
• Content Inventory and Auditing 101 — Nielsen Norman Group：インベントリと監査の違い、記録する項目、期限を区切る進め方
• Tree Testing — Nielsen Norman Group：リニューアルでのツリーテストの使いどころ
• Delivering large-scale IT projects on time, on budget, and on value — McKinsey：5,400件超の調査、予算45%・期間7%の超過と56%の価値の不足（2012年）

いずれも2026年10月25日に確認したものです。期間と工数の目安は、DevNJ の作業計画にもとづくもので、公的な統計ではありません。規則や数値は変わるため、計画を立てる前に各リンク先で最新の情報を確認してください。