COLUMN
HTMLサイトのCMS移行｜貼っただけのお問い合わせフォームは、送信しても何も届いていなかった
静的なHTMLで作られたサイトを、今年の7月にコンテナへ移した。
元のサイトと新しいページを並べて見比べる限り、移行はほとんど終わったように見えていた。
ところが、そのまま貼り付けていたお問い合わせフォームは、送信すると完了画面までは進むのに、記録もメールも1件も残らない作りだった。
この記事では、HTMLサイトをCMSへ移すときに私が踏んだ手順と、見た目の確認だけでは気づけなかった4つのことを順に書いておく。
「HTMLのサイトをそろそろ自分たちで更新できるようにしたい」と考えている人の、段取りの参考になればうれしい。
HTMLサイトをCMSへ移すとき、最初に分けたのは「デザイン」と「中身」
今回のサイトは、HTMLとCSSで組まれたページと、別の場所で動いていた古いWordPressの記事が23件という構成だった。
デザインの原本はHTML側にあり、記事はWordPress側にしか無い。
この2つを一つのCMSにまとめて、ページも記事も同じ管理画面から更新できるようにするのが今回の移行だった。
最初に決めたのは、何を「正」にするかだった。
見た目はHTML側を正にする。
記事の文章と写真はWordPress側を正にする。
この2つを混ぜると、どちらの色が正しいのか、どちらの文章が新しいのかで毎回迷うことになる。
作業用のフォルダも、HTMLの原本、WordPressの書き出し、CMSに入れる側の3つに分けて、原本には手を入れないことにした。
もう一つ決めたのは、CMSの本体には手を入れないことだ。
見た目の違いは、テンプレートと部品と設定で出す。
本体を直してしまうと、あとでCMSを更新したときにその変更が消えるか、更新そのものができなくなる。
結果として、この案件で本体に入れた変更はゼロで済んだ。
手順1：見た目はHTMLを正にして、部品に分けて写す
HTMLのページを、そのまま1枚ずつCMSに貼ることもできる。
でも、それをやると更新のたびにHTMLを直すことになり、CMSにした意味がほとんどなくなる。
そこで、ページを「見出しの帯」「写真のギャラリー」「文章と画像の並び」「問い合わせへの誘導」のような部品に分けて、部品ごとに入力欄を作った。
担当の人は、部品を選んで文章と写真を入れるだけでページが組めるようになる。
部品に分けたら、全部の部品を1ページに並べた確認用のページを作った。
並べた部品は18種類で、このページを一度見るだけで、CSSの当たり漏れがまとめて見つかった。
たとえば、パンくずリストの帯の高さが、デザインでは51pxなのに79pxになっていた。
CMSが出力するパンくずを、もう一度外側の枠で包んでいたせいで、余白と背景が二重に効いていた。
1ページずつ見比べていたら、帯が少し太いことには気づけても、原因までは追えなかったと思う。
手順2：お問い合わせフォームは、貼るのではなくつなぎ直す
冒頭に書いたフォームの話は、ここで起きた。
HTMLのサイトでは、フォームのHTMLを、HTMLを自由に書ける部品にそのまま貼っていた。
画面は元のサイトと同じで、入力して送信ボタンを押すと、完了の画面も出る。
ただ、送られた内容はどこにも保存されず、担当者へのメールも送られていなかった。
壊れていたというより、最初からCMSのフォームの仕組みにつながっていなかった。
CMSのフォームは、入力欄の並び、確認画面、完了画面、送信先のメール、申込の記録を、ひとまとまりの設定として持っている。
見た目だけHTMLで再現しても、この設定が無ければ何も起きない。
今回は、すでに動いているフォームを土台に、このサイトの項目へ組み替えて9つのブロックで作り直した。
作り直した後は、実際に送信して、申込の一覧に1件入ること、メールが届くことを両方確かめている。
フォームでは、もう2つ気をつけたことがある。
1つは、送信先のメールアドレスを設定する場所が、問い合わせページごとに分かれていたことだ。
このサイトには問い合わせのページが2つあり、宛先を変えるときは両方を直す必要がある。
これは引き継ぎの文書に書いて、担当の人にも伝えた。
もう1つは、迷惑な送信を防ぐ仕組みの鍵だけを先に設定すると、画面側の準備が無いせいで、正しい送信まで全部はじかれてしまうことだった。
鍵の設定と画面の部品は必ずセットで入れる、という順番を決めておいた。
公開前のレビューでは、フォームを外から不正に使える送り方も見つかった。
これはこの案件だけの問題ではなかったので、CMSの本体の側で直し、公開前に塞いでいる。
フォームは、移行の中でいちばん「見た目が同じなら動いている」と思い込みやすい場所だと私は思う。
手順3：画像の代替テキストは、41枚を1枚ずつ見て書いた
WordPressから記事を運んだとき、本文の写真41枚の代替テキスト（alt）が空だった。
画像が表示されない環境や、読み上げソフトで読む人には、ここに書いた文章だけが写真の中身として伝わる。
「写真1」「写真2」のように番号を振って埋めることもできるけれど、それでは読み上げにも画像検索にも意味がない。
そこで、41枚を1枚ずつ開いて、写っている物と作業の内容を書いた。
製品名や型番が読み取れる写真は、それも入れている。
逆に、あえて空のままにした画像もある。
ページの見出しの背景に敷いた写真が11枚、問い合わせへの誘導の背景が12枚。
これらは飾りで、見出しの文字が内容を伝えているので、代替テキストは空が正しい。
同じ写真がトップのスライドと誘導の背景の両方で使われていたので、画像のファイル名で一括置換をすると、飾りの側まで説明文が入ってしまう。
置き換えは、スライドの部品の中だけに絞って行った。
記事一覧のカードに出る小さな写真24枚は、表示用の部品が代替テキストを空で決め打ちしていた。
ここは部品を1か所直して、記事のタイトルが入るようにした。
1枚ずつ直すのではなく、出している側を直すと、これから増える記事にも効く。
手順4：URLは「どれが正式か」を先に決め、353か所をそろえた
作業の途中で、サイトの正式なURLがwww付きかwww無しか、が揺れていたことに気づいた。
最初はwww付きで入れていて、あとからwww無しが正式だと確認できた。
CMSの設定、検索エンジン向けの組織情報、会社概要に表示しているURLの3か所を直し、HTMLの原本の側も32ファイル353か所をwww無しにそろえた。
原本をそろえておかないと、あとで原本からページを作り直したときに、古いURLが戻ってくる。
もう一つ、公開前の点検で見つかったのが、検索エンジンに伝える正式なURL（canonical）と、SNSで共有されたときのURL、サイトマップのURLが、作業用の仮のドメインのまま出ていたことだった。
画面ではまったく分からず、HTMLのソースを開いて初めて見える。
この3つは、本番のドメインを設定する1か所を直せばまとめて正しくなる作りなので、本番に上げる前に必ず確かめる項目に入れた。
公開前に、全ページを開くより先に確かめたこと
公開前の確認では、全ページを目で見る前に、URLの一覧を作って、全部が正常に開くか（HTTPの200が返るか）を機械的に確かめた。
対象は15のURLで、全部が200だった。
そのうえで、次の順に見ていった。
フォームから1件送って、記録とメールの両方が残るか。
サイト内検索で、存在しないページや404のページが結果に出ないか。
記事一覧で、絞り込みやページ送りを指定したときに件数が正しいか。
スマホの幅で、ページ送りのボタンが指で押せる大きさか。
今回は、ページ送りのボタンが40px四方しかなく、44px四方に広げた。
サイト内検索に404のページが出ていたのも、この順番で見て見つかったものだ。
レビューも含めて、公開前に直した項目は10ほどあった。
そのほとんどが、画面を見比べるだけでは同じに見えるものだった。
移行の確認を「元のサイトと見た目が同じか」だけで終えないことが、HTMLサイトの移行ではいちばん効いたと思う。
HTMLサイトのCMS移行で、手を抜かないほうがいい順番
振り返ると、手間をかけた順番はこうなる。
まず、見た目と中身のどちらを正にするかを決める。
次に、ページを部品に分け、全部の部品を並べた確認用のページで崩れをまとめて見つける。
フォームは貼らずに、CMSのフォームとしてつなぎ直し、実際に送って記録とメールを確かめる。
画像の代替テキストは、写真を見て書く。
URLは正式な形を先に決めて、原本ごとそろえる。
最後に、ソースにしか出ない情報と、検索・一覧・フォームの動きを確かめる。
HTMLのサイトは、作った人がいなくなると更新が止まりやすい。
CMSへ移す一番の目的は、社内の人が自分で直せるようにすることだ。
だから移行の最後には、更新する人の目線で管理画面から1件保存してみるところまでを工程に入れている。
移行の進め方の全体は移行のページに、フォームの申込の記録とページの部品については、それぞれの機能のページにまとめている。
フォーム申込一覧（CSV出力）の機能を見る
ページモジュールの機能を見る
WordPressからの移行・脱WordPressについて見る