COLUMN
ホームページリニューアルの進め方｜205ページの文章とURLを変えずに、見た目だけ移行した
10月4日、この製品サイトの見た目を全ページまとめて作り変えた。
対象は固定ページ30と記事175、合わせて205ページ。
文章・見出し・リンク・URLは1文字も変えず、色と動きだけを新しいデザインへ移した。
トップページの表示速度の指標（LCP）も、計測した時点の5.7秒から2.7秒まで縮めている。
ホームページのリニューアルというと、デザインも文章もURLも一度に新しくする進め方がよく選ばれる。
私たちは今回、その逆をやった。
この記事では、中身を動かさずに見た目だけを替えた手順と、途中で引っかかった落とし穴を順に書いておく。
ホームページリニューアルで、まず「変えないもの」を決めた
作業の最初に決めたのは、新しいデザインの方向ではなく、変えないものの一覧だった。
本文の文章、見出しの文言と順番、ページ同士のリンク、URL、そしてクリック計測のためにボタンへ付けている印。
この5つは、どんなに見た目の都合があっても触らないことにした。
理由は単純で、検索エンジンが覚えているのはこの5つだからだ。
URLが変われば、それまでの評価を新しいURLへ引き継ぐための転送設定が要る。
見出しや文章を大きく書き換えれば、そのページが何について書かれているかの判断も一からやり直しになる。
見た目を替えるだけなら、検索エンジンから見たページはほとんど同じままで済む。
クリック計測の印を残したのも同じ考え方だ。
リニューアルの前後で問い合わせボタンの押され方を比べたいのに、計測の仕組みまで変わってしまうと、数字の差がデザインのせいなのか計測のせいなのか分からなくなる。
比べられる状態を残しておくことも、リニューアルの準備のうちだと思う。
見た目の切り替えを、CMSの本体ではなく追加の部品で行った
新しいデザインは、CMSの本体には手を入れず、後から足せる部品（プラグイン）として作った。
ページを組み立てて送り出す直前のHTMLに、新しいCSSとJavaScriptを差し込むだけの部品だ。
本文やリンクのHTMLそのものは書き換えない。
この形にしておくと、うまくいかなかった時に戻すのが簡単になる。
部品を止めれば、サイトは作り変える前の見た目にそのまま戻る。
本体を直接書き換えていたら、戻すには変更を1つずつ探して元に戻す作業が要ったはずだ。
実際、作業中は新しいデザインを当てていない状態のトップページが、作り変える前と1文字も違わないことを確かめてから先へ進んだ。
コンテナでは、ページの中身（記事や固定ページ）と、それを包むテンプレート、見た目を決めるスタイルを別々の層で管理している。
今回のリニューアルが文章に触れずに済んだのは、この分け方のおかげが大きい。
お客様のサイトでも、デザインを替えたい時に記事を1本ずつ直す必要はない。
切り替え方式はCookieではなく、URLで選んだ
新しいデザインには暗い配色（ダーク）と明るい配色（ライト）の2種類を用意し、どちらでも見られるようにした。
普通に開くとダーク、URLの末尾に指定を付けるとライトになる。
訪問者の選択を覚えておくのにCookieだけを使う方法も検討したが、採らなかった。
理由はページのキャッシュにある。
このサイトは表示を速くするために、一度作ったページを保存して次の人にそのまま返している。
その保存の目印はホスト名とパスだけで、Cookieは含まれていない。
Cookieで出し分けると、最初に開いた人の配色が保存され、後から来た全員に同じものが配られてしまう。
URLで出し分ければ、指定付きのURLはキャッシュの対象外なので混ざらない。
指定付きのページには検索エンジン向けに「登録しなくてよい」という印（noindex）を付け、正規のURLは指定なしの方を指したままにした。
ヘッダーに置いた切り替えボタンも、検索エンジンがたどらないようにしてある。
同じ内容のページが2つずつ検索結果に並ぶ事態は、これで避けられた。
205ページを1枚ずつ塗り直さず、既存のCSSから色を作った
トップページは一からデザインしたが、残りの204ページを1枚ずつ塗り直すのは現実的ではなかった。
そこで、いまのCSSから色の指定だけを抜き出し、文字・背景・枠線・影といった役割ごとに夜の色へ置き換えるスクリプトを作った。
ダーク用のCSSはこのスクリプトが自動で書き出す。
元のCSSを直した時は、もう一度流せば追いつく。
自動で済まなかったところも3つあった。
1つ目は、記事本文の見出しや太字が暗い文字のまま残ったことだ。
本文用のCSSは色を変数で持っていて、別の名前の変数がその変数を参照する二段構えになっていた。
片方だけ夜の色にしても、もう片方は最初に決まった昼の色を受け継いでしまう。
2つ目は、本文の中に直接書かれた背景色だった。
業種別のページの一部に、白に近い背景がHTMLに直書きされていて、CSSの置き換えでは届かなかった。
3つ目は、お問い合わせフォームのプルダウンで、ブラウザが用意する選択肢の部分は自動の置き換えでは色が変わらなかった。
フォームの部品は、背景と文字の色を1つずつ指定し直して読めるようにした。
公開前に見つかった、表示確認だけでは分からない崩れ
全ページを開いて眺めるだけでは見つからない崩れもあった。
いちばん驚いたのは、先に作っていた明るい配色のCSSの一部が、実は最初から効いていなかったことだ。
各セクションが別々の箱に包まれていたため、「この区画の次の区画」という指定が当たっていなかった。
見た目に大きな違和感がなかったので、ダークを作るために同じ指定を書くまで気づかなかった。
フォームの確認画面だけが古いデザインに戻る不具合も出た。
入力内容を送った後の画面は、通常のページとは別の経路で作られていて、そこに新しいデザインの処理が通っていなかった。
切り替えボタンを押すと一覧の2ページ目から1ページ目へ戻ってしまう不具合もあった。
どちらも、公開前のレビューで実際に入力して送る、2ページ目で押す、という操作をなぞって初めて分かった。
最後に、固定ページの全部と記事・機能・導入事例のページを、パソコンの幅（1440px）とスマホの幅（390px）で自動チェックした。
見るのは、白く大きな背景が残っていないか、文字と背景の色の差が足りているか、横にはみ出していないかの3点だ。
残ったのはオレンジのお問い合わせボタンの白文字だけで、色の差は基準の4.5に対して3.1だった。
これは以前のデザインでも同じ配色だったため、今回は据え置き、別に判断することにした。
本番への移行は4回に分け、そのたびにキャッシュを消した
本番への反映は、一度に全部を入れず、その日のうちに4回に分けた。
1回目が新しいデザインの部品の本体、2回目が移行・比較ページの図、3回目と4回目は表示速度の改善だ。
反映の前には、差し替える分のバックアップを取っておいた。
毎回やったのが、ページのキャッシュを消すことだった。
新しいファイルを置いても、保存済みのページが残っていると、訪問者には古い見た目が返り続ける。
反映した直後に「変わっていない」と慌てたら、まずキャッシュを疑うと決めておくと落ち着いて対処できる。
表示速度の改善では、思い込みが1つ外れた。
トップページの表示が遅いのは、動きを付けるJavaScriptの初期化が重いからだと考えていた。
測ってみると、時間を食っていたのは画面のレイアウト計算のほうだった。
画面の外にあるセクションの描画を後回しにする指定を足しただけで、LCPは5.7秒から2.7秒になった。
リニューアルの前に決めておけばよかったこと
やってみて、事前に決めておけば迷わずに済んだことが2つある。
1つはアクセス解析の扱いで、ライトの配色で見たページは指定付きのURLとして別に数えられてしまう。
集計の時にまとめる方法を、公開前に決めておくべきだった。
もう1つは、本番のキャッシュの設定を先に確かめておくことだ。
キャッシュの設定しだいでは、指定付きのURLのページが正規のURLに保存され、検索エンジン向けの印ごと配られてしまうおそれがある。
今回は反映の前に本番の設定値を確かめることにしたが、設計を始める前に見ておけば、切り替え方式で迷う時間も短くできた。
ホームページリニューアルの進め方に正解は1つではないと思う。
ただ、検索からの評価を積み上げてきたサイトなら、文章とURLを守ったまま見た目だけを替える進め方は、試す価値がある。
コンテナでは、記事・テンプレート・スタイルを分けて管理しているので、中身に触れずにデザインを入れ替えられる。
WordPressなど他のCMSから移る場合の進め方は、移行の案内ページにまとめている。
3層構造（コンテンツ・テンプレート・スタイル）の機能を見る
プラグイン機能を見る
WordPressからの移行・脱WordPressについて見る