webサイトの公開前・公開時のチェックポイント。【リスク高め14選】

2021年03月27日 2021年07月17日

たぐと申します。
東京のweb制作会社でプロデューサーをしています。

Webサイトをリニューアルするとなったとき、何かと問題が起こりやすいのは、公開前だったりします。

あれやってない

あれどうなるんだっけ

にならないように、危険なことは最初に潰しておきましょう。今回は、私がwebサイトの制作に20年関わってきた中で、ここは気を付けておいた方が良いということをリストアップしておきます。（ざっと思いつくものなので都度更新するかもしれません。）

webサイト公開前のチェックポイント

チェックといっても色々あると思うのですが、なるべくクリティカルなものから潰していくべきと思います。それをしていないことでサイトが見れなくなるとか、間違った課金がされてしまうとか、、公開前って結構バタバタしていて、本来やるべきことが疎かになりがちなので、予めチェックリストを持っておくことは有効だと思います。

※そういう意味では、テキストの「てにをは」、文末の体裁、IE11で少し表示が崩れるとかは些細な問題です。

1. URLが変更になったページのリダイレクトをしているか。

これは、よくありがちというか危険度が高いです。

例えば、リニューアルに合わせて英語ページを作ったので、日本語サイト、英語サイトの配置場所を変えたような場合は注意が必要です。

元々トップページのURLが
/index.html
として、
リニューアル後のトップページのURLを
日本語：/jp/index.html
英語：/en/index.html

このように変更をすることがあるのですが、こういう変更をした場合、もともとの
/index.html　にアクセスしたユーザーを、
/jp/index.html　にリダイレクトしてあげる必要があります。
設定は、「.htaccess」というファイルを使うのが一般的です。
これをしていないと、元々のURLにブックマークしていたユーザー、もしくはリニューアル前に貼られていたリンクを辿って訪問したユーザーが「Not Found」のページを見てしまうということになりかねません。
危険度の高いものなので、特に気をつける必要があります。
当たり前と思うようなことでも、意外と抜けたりするものです。

2. SSLで暗号化通信ができているか。

リニューアルにあわせてwebサーバを移行する場合などには注意が必要です。
webサーバが変わるということは、
新サーバでの表示確認はテスト用のURLで行っているはずです。
本番のURLはリニューアル前のサイトで有効なわけですから。

テスト用のURL（ドメイン名）では
httpsでアクセスしたときにサーバ証明書エラーになってしまいます。

そうならないようにするためには、ローカルのhostsファイルを編集して、リニューアル後の正規のURLで新サーバの表示確認をする必要があります。それでサーバ証明書が有効であることを確認できます。

※なんのこっちゃという方もいると思うのでこれはまた別の機会に記事にしようと思います。

3. wwwありなしのアクセスに対応できているか。

https://www.example.co.jp
https://example.co.jp
上記２つのURLで本番サイトにアクセスできるはずなのに、「wwwなし」のURLでアクセスすると「Not found」になってしまう、ということが起こり得ます。

4. http://でのアクセスをhttps://にリダイレクトできているか。

http://へのアクセスをhttps://にリダイレクトするには、webサーバソフトがApacheである場合、その設定ファイルである.htacessを編集する必要があります。
サーバ証明書が有効になっているサイトは基本的にはすべてhttps://
でアクセスされるように以下のようなリダイレクト設定の記述を加えておきましょう。

下記の記載があると、Rewritebaseである「/」以下のデータを全てhttps:// がついた形のURLにリダイレクトしてくれます。

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{HTTPS} off
  RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

今はどうかわかりませんが、http://　のURLとhttps:// のURLが混在しているとGoogleの評価が分散するとか、セキュリティ的に問題がある、という話もありますので注意が必要です。

5. DNS切り替え、TTL短縮設定の担当、設定フローは明確か。

こちらは、そもそもDNSの管理を誰がやっているか的な話でもあったりします。
長年運用しているwebサイトなどでは、意外とDNSの設定管理を誰も把握していないということが普通にあります。
ドメイン管理をどこでやっているか、ということは把握しておきましょう。
その上で、公開時にどのような手順で公開を進めるのかを明確にしておく必要があります。

具体的には、

TTLの設定を短縮するタイミング
DNSのAレコード、CNAMEレコードを更新する担当
TTLの設定を復帰するタイミング

あたりです。これをきちんと把握しておかないと、DNSを切り替えたにも関わらずいつまで経ってもwebサイトがリニューアル後のサイトに切り替わらないということが起こり得ます。

6. テスト環境を参照しているファイルやAPIはないか。

何らかのリソースを絶対パスで指定しており、それが本番サーバではなくテスト環境のものを参照したりしていないか、確認しておきましょう。
画像やJavaScriptなどは基本ルート相対パス、もしくは相対パスで参照することがほとんどだと思うので、テスト環境のものを参照しているというケースは起こりにくくはあると思います。
ただ、もしそれがあるとBasic認証の入力ウィンドウが出たり、webサイトの閲覧に重大な支障をきたす恐れがあります。

あとおそろしいのが決済や機関システムなどのAPI連携です。
ここは最後の最後に検証用APIではなく、本番用に切り替える必要があるのですが、検証環境を参照していたということが起こり得ます。
そうすると、本番公開後の決済情報や個人の申し込み情報がテスト用のデータベースに蓄積されたり、正しく決済処理に乗らなかったりと面倒なことになってしまいます。このあたりは予め公開手順書などを作成し、設定の抜け漏れが無いように細心の注意を払う必要があります。

7. Google検索クローリング許可をしているか。

開発中のwebサイトをGoogle検索にインデックスさせないための設定を行うことがあります。そしてそれをそのまま忘れた状態で公開すると、いつまで経ってもwebサイトがGoogle検索にインデックスされないという状況が起こり得ます。
Googleにインデックスされない状態はwebサイトとして存在していないに等しい状態です。作成したwebサイトがGoogleにクローリングされる状態になっているかどうかは必ず確認するようにしましょう。

8. 対象端末での表示・機能の動作問題ないか。

これは公開前に一通り確認される部分だと思います。
ただ、CMSの機能動作などは公開直前にクライアントが確認する、ということになったりして、バタバタと相談をもらったりしがちです。
いずれにせよ、機能面については余裕を持った検証計画が必要です。
表示については、表示崩れがないかはもちろんですが、記載内容に誤りがないか、といったことはwebサイトオーナー側、制作側双方でチェックをしましょう。
特に・・・

価格
電話番号
重要な免責事項

などです。人の健康や資産に影響するものについては、特にチェックを厳重にする必要があります。下手すると損害賠償とかそんな話になりかねませんからね・・・。

9. 制作期間中の更新内容を反映できているか。

Webサイトリニューアルの制作期間は早くて３ヶ月、長いものだと１年間くらいかかるものもあります。なので設計フェーズで内容を固めていたとしても、デザインフェーズでコーディングフェーズで、掲載すべき情報に更新が入ることは普通にあります。
公開前にその「差分反映」という作業が必要になります。
その情報反映の予定をきちんと確保しておくことはもちろんですが、その内容が実際反映されたのかどうかをwebサイトオーナー側、制作側双方でチェックする必要があります。

この反映処理をするタイミングになって各部署担当がリニューアル後のwebサイトをはじめて見ることも多く、この段階になってから「あれしたい」、「これ入れたい」といった希望が入る可能性がそれなりに高いです。
ここは、スケジュール、対応費用など予めクライアントと握りをしっかりしておきましょう。そうしておかないとエンドレス修正対応の沼にはまることになりかねません。

11. エラーページの表示設定をしているか。

これも微妙に忘れがちです。
エラーページの最たるものはNot Foundエラーのページです。
ただ、エラーコードは 404 Not Foundだけではなく、サーバエラーやクライアントサイドのエラーなどさまざまなものがあります。
どのエラーページに対して対応するのかは予め決めておきましょう。

12. タグマネージャの発火処理をしているか。

サイト公開にあわせてタグマネージャ側でGoogle Analyticsのタグを発行して、Google Analyticsのアクセスログ集計をスタートする、ということもあります。
タグマネージャでGoogle Analyticsを有効化する場合、その処理は忘れないようにしましょう。公開後のアクセスログの推移を追えなくなってしまいますからね。

13. サイトマップXMLをGoogleに送信する準備をしているか。

サイトを公開したら必ずGoogleサーチコンソールを使ってSitemap.xmlを送信するようにしましょう。それでサイトのページが更新されたことをGoogleに伝え、リニューアル後のページがインデックスされるまでの時間を短縮することができるはずです。ただ、サイトの規模などによりSitemap.xmlの必要度合いは変わってくるようです。
サイトマップについて | Google 検索セントラル | Google Developers
この辺りの記事が参考になるかもしれません。

14. Basic認証等、アクセス制限は解除しているか。もしくは掛けるべき対象に掛かっているか。

開発中には、サイト全体もしくは一部にBasic認証やIP制限をかけたりしています。公開後にそれが確実に外れているかどうかはキャッシュをクリアするなどして確実に確認するようにしましょう。アクセスの多いサイトでいきなりID/PWを求めるウィンドウが表示されたりすると、ユーザーにいらぬ猜疑心を抱かせかねません。

まとめ

今回はwebサイトリニューアル時に対応を怠ると特にとまずいポイント14個をお伝えしました。
webサイトは印刷物とは違い、公開後も修正などができます。

ただ、だからといって、制作側がリスクを負わないかというとそういうことはありません。
クライアントによってはwebサイトそのものがビジネスの生命線だったりするわけで、1時間でもwebサイトが表示されていないとそれがそのまま損害に直結するケースも多いです。

最近はコーポレートサイトも大規模化されており、公開前にすべてをチェックすることは難しくなってきています。
だからこそ、クリティカルな部分から優先度をつけて潰しておくことが必要なわけです。

最悪なのは

サイトが見れない
ページが表示されない
申し込みできない
価格が間違っている

そういったことです。「てにをは」「ですます」の整合が取れていないとかは些細はところです。
今回お知らせした重要ポイントは特にクリティカルなところだと思うので、事故を起こさないための参考にしていただけると幸いです。

以下に今回の記事の内容も含めてチェック項目のリストを作りましたのであわせてご覧ください。