- 更新の回数そのものが問題にならない理由
- 更新で実際に壊れやすい5つのところ
- 頻繁に更新するなら決めておく4つのこと
- 戻せる状態を先に作ると更新が速くなる理由
結論
更新の回数そのものは、ほとんど問題になりません。問題になるのは、更新のたびに人の手が入る部分と、失敗したときに戻せない状態のほうです。1日に何回までなら安全、という基準はありません。そういう基準を持ち出す説明を見かけたら、根拠を確かめてください。回数を減らすより、手順を短くして、戻し方を用意するほうが効きます。
なぜ「更新しすぎ」が心配されるのか
心配の中身は、たいてい三つに分かれます。検索順位が下がるのではないか、サーバーに負担がかかるのではないか、いつか壊すのではないか。前の二つは、通常の規模のサイトでは起きにくい話です。三つ目は本当です。ただし原因は回数ではなく、更新の作業に手作業が混じっていることと、壊れたことに気づく仕組みが無いことです。
検索については、更新した内容が検索結果に反映されるまでの時間を、こちらから決めることはできません。サイトマップに更新日を書けば、その値が一貫して正確な場合には参照されるとGoogleは説明していますが、サイトマップを出すこと自体は手がかりにすぎず、読み込みやクロールを保証するものではないとも書かれています。更新のたびに順位が動くことを期待して回数を増やすのは、方向が違います。
実際に問題になるところ
キャッシュ
いちばん多いのがこれです。HTMLは直したのに、見た目が変わらない。原因はCSSやJavaScriptが古いまま使われていることです。ブラウザやCDNは、同じURLのファイルを取り直さないことがあります。対策は、中身を変えたらURLを変えることです。ファイル名に版を入れる、あるいは読み込み側のURLに日付や番号を付ける方法があります。HTML本体はURLを変えられないので、こちらは毎回確認させる指定にして、ETagなどで変わっていないときだけ再利用させる、という組み合わせが一般的な作りです。
ビルドとデプロイ
原稿から自動でページを作る仕組みを使っている場合、更新は「原稿を直す」ではなく「作り直して置き換える」作業になります。途中で失敗しても、古いページが残っているせいで見た目には気づきにくいことがあります。生成の結果を置き換える前に、生成が最後まで通ったかを確認する手順を入れてください。
CDNと配信
CDNを使っていると、書き換えた後もしばらく古い内容が配られます。更新のたびに手で消して回るのは長続きしないので、消す対象と手順を決めて、更新作業の一部にしてしまうほうが続きます。
データベースの変更
表示の文言を変えるだけの更新と、項目を増やす更新は、危険度が違います。後者は戻すのが難しく、書き戻しが要ることもあります。同じ「更新」でも、戻し方が違うものを同じ手順で扱わないでください。
リンク切れ
ページを整理するとURLが変わります。古いURLを消したままにすると、社内の資料や取引先のブックマークから来た人が行き止まりに当たります。URLを変えるときは、古い住所から新しい住所へ転送する設定を残してください。
頻繁に更新するなら決めておくこと
- 更新の手順を、誰がやっても同じ順番になるように書き出す。
- 直したら何を見るかを決める。トップ、更新したページ、問い合わせフォームの三つは毎回見る。
- 戻し方を先に用意する。直前の状態に戻せるなら、更新は怖くありません。
- 大きな変更と小さな変更を分ける。文言の修正と、構成の変更を同じ日にやらない。
戻せることが分かっていると、更新の回数は自然に増えます。回数を我慢するより、戻せる状態を作るほうが結果的に速く進みます。
実務ではこうなる
週に二、三回お知らせを足す会社を考えます。ここで起きる事故は、たいてい「見出しの文字が化けた」「画像の向きが違う」「リンクの先が古い」の三つです。どれも更新直後にページを開けば見つかります。逆に、月に一度しか更新しない会社のほうが、一度の変更量が大きく、壊れたときの原因が絞れません。
社内の運用では、更新した日と内容を一行ずつ残しておくと、後から効きます。表示がおかしいという連絡が来たときに、その日に何をしたかが分かるからです。凝った記録は続かないので、日付と一行で足ります。
注意点
更新の頻度を上げるために、内容の薄いページを増やすのは逆効果になりやすい行為です。読む人の役に立たないページが増えると、サイト全体が探しにくくなります。更新は、直す価値のあるところを直すために使ってください。
もう一つ、更新作業を一人しかできない状態は、回数とは別の問題です。その人が休んだ日に、誤りを直せなくなります。手順を書き出しておくのは、回数を増やすためではなく、担当を替われるようにするためでもあります。
まとめ
回数は基準になりません。見るべきは、手順が短いか、失敗に気づけるか、戻せるかの三つです。キャッシュ、生成の失敗、CDN、データベースの変更、URLの変更に手当てをしておけば、更新が増えても壊れ方は増えません。根拠のない回数の目安に合わせて、直すべきところを我慢する必要はありません。