ホームページの​リニューアルの​進め方検索順位と​問い合わせを​落とさない​手順

この​記事は、​リニューアルを​すると​決めた​後の​段取りに​絞ります。
作り直すべきか​どうかの​判断は、ホームページの​リニューアルは​必要かに​書きました。

リニューアルの​手順は、​公開の​前・​当日・公開の​後に​分けて​考える

リニューアルの​作業は、​デザインと​原稿づくりに​目が​向きがちです。
ただ、​検索順位と​問い合わせが​落ちる​原因は、​たいてい公開の​前後に​あります。
私たちが​今回進めた​順に​並べます​（最後の行は、​いまも続けている​ところです）。

ここから、​それぞれで​私たちが​実際に​やったことと、​つまずいたことを​書きます。

URLと​canonicalは、​変えないのが​いちばん​守りやすい

今回の​作り直しでは、​ヘッダー、​フッター、​トップ、​会社概要、​サービスの​ページ、​コラムの​全ページの​見た目を​変えました。
一方で、​ページの​URLは​1本も​変えていません。
削除した​ページも​ありません。
作り直した​ページの​<link rel="canonical">は、​すべて​本番の​URLを​指すように​して、​公開前に​機械で​照合しました。

canonicalは、​似た​ページが​いくつか​あるときに、​どれが​正規の​ページかを​検索エンジンに​示す印です。
Googleは、​各ページの​正規の​URLを​決めて​サイトマップに​含めて​送るよう​説明しています。
一方で、​サイトの​中である​ページが​正規に​選ばれないように​する​手段として​noindexを​使うことは、​その​ページが​検索から​完全に​外れてしまうので、​すすめていません​（Google 検索セントラル：rel="canonical" などを​利用して​正規 URL を​指定する​方法、2026年10月7日確認）。

作り直しの​途中で、​ひやりと​したことがあります。
トップの​試作を​何案か​作っていたのですが、​そのうちの​1つが、​中身は​まったく​別なのに、​canonicalだけは​トップの​URLを​指していました。
試作を​そのまま​本番に​混ぜると、​同じ​URLを​正規だと​名乗る​別の​ページが​2枚できます。
試作は​本番に​写さないと​決め、​公開の​後に、​試作の​URLを​本番で​開いて​404が​返ることも​確かめました。

URLを​変える​ページが​あるなら、​古い​URLから​新しい​URLへの​恒久的な​転送​（301）が要ります。
Googleは、​サーバー側の​恒久的な​リダイレクトを​すすめ、​転送は​できるだけ長く、​一般的には​1年以上​残すように​書いています​（Google 検索セントラル：サイトを​移転する​方法、2026年10月7日確認）。
一覧の​作り方と​転送の​決め方は、リニューアルが​必要かの​記事の​後半に​書いたので、​ここでは​繰り返しません。
私たちの​サイトにも、​以前に​記事を​まとめたときの​301が​あります。
作り直しで​転送の​設定が​消えていないかも、​公開の​後に​古い​URLを​開いて​確かめました。

試作の​noindexを、​本番に​持ち込まない

制作の​途中の​ページには、​検索に​出ないように​noindexを​付けておくことが​よく​あります。
私たちも、​試作の​ページには​すべて​noindex, nofollowを​付けていました。
数えると​211ページです。

これを​外し忘れて​公開すると、​Googleは​ページを​読みに​来たときに​noindexを​見つけて、​検索結果から​外します​（Google 検索セントラル：noindex を​使用して​コンテンツを​インデックスから​除外する、2026年10月7日確認）。
見た目には​何も​変わらないので、​気づくのは​検索の​数字が​落ちてから、になりがちです。

もう​1つ、​私たちの​サイトに​特有の​落とし穴が​ありました。
サイトマップを​作る​スクリプトは、​noindexの​ページを​自動で​外すように​作ってあります。
試作の​noindexが​残ったまま​流すと、​ほとんどの​ページが​サイトマップからも​消えるところでした。

そこで、​本番でも​noindexのまま​残すページを​先に​一覧に​しました。
404の​ページ、​申し込みの​ページ、​関西の​外の​地域記事8本の、​計10ページです。
公開前には、​noindexが​付いているのが​この​10ページだけで、​値も​今の​本番と​同じであることを​確かめています。

テスト用の​環境を​robots.txtで​クロールさせない​形に​している​場合は、​公開のときに​その​止めを​外します。
Googleも、​移転の​準備で​robots.txtなどで​クロールを​止めていたなら、​新しい​サイトでは​その​止めを​すべて​解除するよう​書いています​（Google 検索セントラル：ウェブ ホスティングの​変更と​ SEO、2026年10月7日確認）。
noindexと​robots.txtの​違いは、noindexと​robots.txtの​違いに​まとめています。

サイトマップと​llms.txtは、​新しい​ページの​一覧から​作り直す

サイトマップは、​作り直した​後の​ページの​一覧から​作り直しました。
今回は、​新しく​作った​無料診断の​ページと、​同時に​公開した​記事2本を​足しました。
noindexの​申し込みページは​載せていません。
公開の​直前の​組み立てで​204URLに​なり、​全U​RLが​200で​開くことを​確かめています。

llms.txtは、​AIの​サービスに​向けて、​サイトの​概要と​主な​ページを​書いておくファイルです。
会社の​説明と​サービスの​並びを​新しい​サイトに​合わせて​書き直しました。
ただし、​Googleは、​llms.txtのような​ファイルは​検索​（生成AIの機能を​含む）では無視され、​表示や​順位に​影響しないとしています​（Google 検索セントラル：生成 AI 機能向けの​最適化ガイド、2026年10月7日確認）。
置くかどうかの​考え方はllms.txtとはに​書きました。
サイトマップの​書き方はサイトマップの​作り方に​あります。

フォームは、​本番の​送信先に​つないで、​最後の​画面まで​送る

問い合わせを​落とす原因で、​私が​いちばん怖いと​思っているのが​これです。
リニューアルした​サイトは​見た目が​きちんとしているので、​フォームも​動いているように​見えます。

私たちの​試作では、​会社概要、​採用、​サービスの​LP 9本の、​計11ページの​フォームが、​どこにも​送信されない​作りに​なっていました。
入力欄も​ボタンも​そろっていて、​見た目では​分かりません。
ただ、​ボタンを​押しても​試作だと​知らせて​止まるだけで、​本番の​送信先への​送信も、​問い合わせの​完了を​計測に​知らせる​処理も、​どこから​来た​人かの​記録も​入っていませんでした。
見た目の​確認だけで​公開していたら、​問い合わせは​届かず、​計測にも​残らなかったはずです。

本番に​組み込むときに、​送信先、​完了の​計測、​どこから​来た​人かの​記録を、​今の​本番と​同じものに​つなぎ直しました。
そのうえで​13本の​フォームを、​パソコンの​幅​（Chromium）とiPhoneの​幅​（WebKit）で、​入力から​完了の​画面まで​通しています。
送られる​中身も、​今の​本番の​フォームに​同じ​入力を​したときと​比べました。

比べると、​違いが​1つだけ​見つかりました。
採用の​フォームの​職種の​値です。
今の​本番では、​見た目の​改行を​整えるための​見えない​文字が​値に​混ざり、​受け取る​側で​「その他」に分類されていました。
新しい​フォームでは​正しい​職種で​届きます。
作り直しで、​前から​あった​不具合が​見つかった​形です。

公開した​後は、​iPhoneの​Safariで​実際に​送り、​お客様側と​社内側の​両方に​メールが​届くかを​確かめる、と​手順に​入れていました。
フォームの​点検の​項目は問い合わせフォームの​チェックリストに、​公開後に​止まっていないかを​見張る​方法はフォームを​見張る​方法に​書いています。

計測の​タグは、​各ページに​1回だけ​入っているかを​数える

作り直しで​計測の​タグが​抜けると、​公開の​後の​数字が​比べられなくなります。
逆に​2回入ると、​アクセスや​問い合わせが​二重に​数えられます。

私たちの​サイトでは、​Google タグ マネージャー​（GTM）のタグを​各ページに​書かず、​公開の​組み立てのときに​全ページへ​1回だけ​入れています。
すでに​タグが​ある​ページには​入れない、という​二重入りの​止めも​あります。
今回は、​組み立てた​214ページの​それぞれで、​GTMの​IDが​2か​所​（<head>の​中と、​JavaScriptが​動かないとき用の​部分）だけにあることを​数えました。
2か所なら​1回、​4か所なら​二重です。

もう​1つ、​新しい​デザインに​なっていない​古い​ページが​混ざったら、​組み立てを​止める​仕組みを​足しました。
新旧の​ページが​混ざると、​ヘッダーや​計測の​作りが​ページに​よって​違ってしまうからです。
タグを​1か所で​管理する​考え方は、全ページの​計測タグを、​1か所で​管理する​方法に​書きました。

公開の​前に​確かめたことと、​確かめきれなかったこと

公開の​前には、​組み立てたものを​手元で​配信して、​次を​確かめました。

• サイトマップの​全U​RLが​200で​開く
• iPhoneの​幅​（WebKit・390px）で全206ページを​開き、​横には​み出す、​JavaScriptの​エラー、​読めない​ファイルが​どれも​0件
• 本番に​出さない​試作の​URLが​404に​なる
• 本番に​残すnoindexが​10ページだけ
• フォーム13本が​完了の​画面まで​通る

確かめきれなかったこともあります。
日本語の​改行です。
主な​ページは​スマホと​パソコンの​画面を​目で​見ましたが、​全ページを​機械で​数えることは​していません。
作り直すと​文字の​大きさや​行の​幅が​変わるので、​見出しが​単語の​途中で​折り返す所が​出やすくなります。
直し方は日本語が​単語の​途中で​改行されるときの​直し方に​まとめています。

もう​1つ、​公開の​前に​戻し方を​書いておきました。
1つ前の​状態に​戻す手順と、​急ぐときに​ホスティングの​管理画面から​1つ前の​公開に​戻す手順です。
使わずに​済みましたが、​公開の​当日に​戻し方を​考え始めると、​判断が​遅れます。

公開した​夜に、​スマホの​表示速度が​28点だった

公開は​10月6日の​21時ごろです。
その後の​22時すぎに、​PageSpeed Insightsで​測りました。
スマホでは、​トップが​28点、​最初の​大きな​表示が​出るまで​（LCP）が9.9秒でした。
コラムの​1ページも、​スマホで​56点、​LCPは​12.9秒です。
公開の​前の​確かめの​一覧に、​表示速度の​項目が​なかったことに、​ここで​気づきました。

原因として​大きかったのは​2つです。
1つは​文字の​書体​（Webフォント）です。
最初の​画面を​描く​前に、​書体の​ファイルを​35〜54本、​合わせて​0.8〜1.3MBほど​取りに​行っていました。
もう​1つは​トップの​背景の​3D表示です。
描く​準備が、​最初の​画面を​出す前に​走っていました。

直し方は、​書体の​読み込みを​最初の​画面を​描いた​後に​回すこと、​3D表示の​準備を、​読み込みが​終わって​手が​空き、​さらに​最初の​操作か​2.5秒後まで​遅らせることです。
3Dを​描くのが​重い​端末では、​動かない​絵に​切り替えるようにしました。
ほかに、​ヘッダーの​小さな​札の​画像を、​表示の​大きさに​合ったものに​しています。
直した​版は、​公開から​約3時間後、​日付が​変わった​10月7日の​0時すぎに​公開しました。

手元の​計測​（Lighthouse）では、​トップの​スマホが​83点から​99点に​なりました。
ただ、​手元の​計測は​PageSpeed Insightsの​28点を​再現しておらず、​条件が​違います。
直した​後の​PageSpeed Insightsでの​測り直しは、​この​記事を​書いている​10月7日の​時点で​まだ​記録できていません。

私が​この​件から​持ち​帰ったのは、​見た目のために​選んだ​部品は、​公開の​前に​速さで​確かめる、ということです。
とくに​スマホでの​最初の​表示は、​検索から​来た​人が​最初に​待たされる​所です。

公開した​後は、​主な​ページから​登録を​リクエストし、​数週間は​数字を見る

公開した​夜に、​Search Consoleの​URL検査から、​トップ、​新しく​作った​無料診断の​ページ、​同時に​公開した​記事2本の、​計4URLの​インデックス登録を​リクエストしました。
ページを​全部​送ったわけではありません。
URL検査からの​リクエストには​1日の​上限が​あり、​送っても​登録されるとは​限らないと、​Search Consoleの​ヘルプに​書かれています​（Search Console ヘルプ：URL 検査ツール、2026年10月7日確認）。
同じ​URLを​何度​送っても​早くはならず、​たくさんの​URLを​知らせるなら​サイトマップを​使う、ともあります​（Google 検索セントラル：URL の​再クロールを​ Google に​リクエストする、2026年10月7日確認）。
URLを​変えていない​ページは、​サイトマップと、​Googleが​ふだん​読みに​来るのに​任せています。

Bingなど、​IndexNowに​対応した​検索エンジンには、​公開の​たびに、​変わった​ページを​自動で​知らせる​仕組みに​しています。
加えて​同じ夜に、​Bing Webmaster Toolsの​APIで、​サイトマップの​新しい​順に​100URLを​送りました。

あとは、​Search Consoleで​登録された​ページの​数、​見つからない​ページ​（404）、​検索での​表示と​クリックを、​数週間かけて​見ます。
URLを​変えた​移転では、​Googleは​掲載順位が​一時的に​変わることが​あるとしています​（Google 検索セントラル：サイトを​移転する​方法、2026年10月7日確認）。
私たちは​URLを​変えていませんが、​公開の​翌日の​数字だけで​良し悪しを​決めない​つもりです。
公開の​日に​見る​画面は、Search Consoleの​使い方に​まとめています。

制作会社に​頼むなら、​公開の​前に​確かめる​一覧を​先に​決める

リニューアルを​制作会社に​頼む場合も、​ここまでの​確かめは、​発注する​側が​一覧として​持っておくと​安心です。
見積もりの​段階で、​次のことを​聞いておくと、​公開の​直前に​慌てずに​済みます。

制作会社​そのものを​替える​場合は、​名義と​権限の​引き継ぎが​先です。
それはホームページの​管理を​引き継ぐ​最初の​1週間に​書きました。
サーバーも​移すならホームページの​サーバーを​移すときを、​公開の​後に​続く​保守の​頼み方はホームページの​保守で、​制作会社に​頼むことを​ご覧ください。

bundlyzeは、​大阪・兵庫を​中心とした​関西の​会社の​ホームページを、​作り直しの​段取りから​公開後の​点検まで​受け持っている​会社です。
この​記事を​書いた​津嘉山は、​業務システム開発と​AWSを​専門と​する​エンジニアで、​この​サイトの​リニューアルも、​組み立てから​公開後の​直しまで​自分で​手を動かしました。

リニューアルを​決めたら、​まずは​いまの​サイトの​URLの​一覧と、​フォームが​いくつあるかを​書き出すところから​始めてみてください。