ホームページの​更新は、​頻度より​「変わった​日に​直せるか」で​決める

「変わった​日に​直すもの」と​「決めて​足す​もの」を​分ける

ホームページの​更新というと、​お知らせや​ブログを​定期的に​足す​ことを​思い浮かべる​人が​多いと​思います。
ただ、​訪れた​人が​困るのは、​記事が​少ない​ことより、​書いてある​電話番号に​つながらない、​終わった​案内が​まだ​載っている、といった​ことの​ほうです。
そこで​私は、​更新を​2つに​分けて​考えています。
会社の​事実が​変わったら、​変わった​日に​直すもの。
それとは​別に、​自分たちで​決めた​ペースで​足していく​もの。
前者は​頻度を​決めようが​なく、​決めておくのは​「誰が​気づき、​誰が​直すか」です。

下の​表は、​更新する​中身ごとの​目安です。
公的な​基準は​ないので、​私たちの​考えとして​書いています。

更新の​頻度は、​検索の​順位に​どう​関わるか

「どれくらいの​頻度で​更新すれば​いいか」は、​検索の​順位を​気に​して​聞かれる​ことが​多い​質問です。
Googleが​公開している​ランキングの​仕組みの​案内には、​鮮度に​かかわる​システムの​説明が​あります。
検索クエリに​対して​鮮度の​高い​コンテンツが​期待される​場合に、​そうした​コンテンツが​上位に​表示されるように​する​仕組みで、​例として、​公開された​ばかりの​映画を​調べる​人には、​制作が​始まった​ころの​記事より​最近の​レビューを​返す、​と​書かれています​（⁠Google 検索セントラル：Google 検索ランキング システムの​ご紹介、​2026年10月4日確認）。
新しさが​効くのは、​新しい​情報が​求められる​検索の​ときです。
どの​サイトでも​更新の​回数が​多い​ほど​上がる、という​説明では​ありません。

むしろGoogleは、​役に​立つコンテンツの​作り方の​案内で、​内容を​ほとんど​変えていないのに​ページを​新しく​見せる​ために​日付を​変えていないか、と​自分に​問うよう​書いています。
サイトを​新鮮に​見せれば​順位が​上がると​考えて、​大量の​新しい​コンテンツを​足したり古い​コンテンツを​消したりしても、​順位は​上がらない、とも​書いています​（⁠Google 検索セントラル：有用で​信頼性の​高い、​ユーザーを​第一に​考えた​コンテンツの​作成、​2026年10月4日確認）。

なので、​更新の​頻度を​社内で​決めるなら、​記事を​足すペースより​先に、​全ページを​読み直す日を​決める​ことを​私は​勧めます。
変わったのに​直していなかった​所は、​気づいた​人が​言わないかぎり、​読み直すまで​見つかりません。

更新されていない​ホームページで​起きる​こと

古い​連絡先や、​終わった​案内が​残る

いちばん​多いのは​これです。
電話番号や​担当者の​メールアドレスが​変わったのに、​ページの​一部にだけ古い​ものが​残っている。
採用を​締めたのに、​募集の​ページが​そのまま​開ける。
見た​人は、​どれが​正しいのかを​確かめる​手間を​かけるか、​そこで​連絡を​やめるかの​どちらかに​なります。
問い合わせの​フォームの​宛先が、​退職した​人の​アドレスの​ままだった、ということもありえます。
送ってみて​確かめる​方法は予約・問い合わせフォームが​止まっていないか、​見張る​方法に​書いています。

ドメインや​証明書の​期限が​切れる

ドメインは、​サイトと​メールの​両方の​土台です。
JPドメインを​管理する​JPRSは、​登録更新の​期限を​過ぎて​意図せず​廃止に​なった​場合でも、​廃止から​20日以内なら​登録の​回復を​申し込めると​案内しています。
扱いや​受付の​期間は​契約先の​事業者に​よって​違うことが​あり、​通常は​手数料が​かかる、とも​書かれています​（⁠JPRS：ドメイン名の​廃止に​関する​注意、​2026年10月4日確認）。
20日は、​気づくまでの​日数としては​長く​ありません。

SSL証明書も、​私たちの​ドメインで​一度、​wwwなしの​アドレスの​分だけが​自動で​更新されない​作りに​なっていた​ことがあります​（2026年9月15日に​移した​経緯はSSL証明書の​期限切れを​防ぐ）。
こうした​期限は、​サイトの​文章を​直す人とは​別の​人が​契約を​持っている​ことが​多く、​更新の​担当を​決める​ときに​抜けやすい​ところです。

CMSの​修正が​当たらないままに​なる

WordPressのような​CMSで​作った​サイトは、​文章を​変えなくても、​本体や​プラグインの​更新が​要ります。
本体の​例では、​IPA​（情報処理推進機構）が​2026年7月22日に、​WordPress本体の​脆弱性に​ついて​注意を​呼びかけ、​影響を​受ける​サイトは​直ちに​更新する​ことが​推奨されている​こと、​自動更新で​バージョンが​上がっているかを​確かめ、​上がっていなければ​手作業での​更新を​検討する​ことを​案内しています​（⁠IPA：WordPressの​脆弱性対策に​ついて​(CVE-2026-60137、​CVE-2026-63030：wp2shell)、​2026年10月4日確認）。
文章の​更新を​社内でしていても、​この​種の​更新を​誰が​するのかが​決まっていない​サイトは​少なくないと​思います。

誰が​更新する​か​：気づく​人と、​手を​動かす人は​違うことが​多い

営業時間が​変わった​ことを​最初に​知るのは、​たいてい現場の​人です。
サイトを​直せる​人は、​別の​部署か、​外注先に​います。
更新が​止まるのは、​その間で​話が​途切れるからだと​私は​考えています。

決めておく​ことは​多く​ありません。
変わった​ことを​伝える​先を​1か所に​決め、​伝えたら​変わった​日に​直す、という​約束を​置いておく。
伝える​先が​決まっていないと、​誰かが​言ってくれるだろう、​で​止まります。
社内に​Webを​見る​人が​いない​場合の​役割の​分け方は、Web担当者が​いない​会社の​対策に​書いたので、​ここでは​繰り返しません。

自分で​更新するか、​外注するか​：サイトの​仕組みで​変わる

「自分で​更新できるか」は、​サイトが​どういう​仕組みで​作られているかで、​ほとんど​決まります。

私の​考えでは、​社内で​直すのは​文章と​写真までにして、​ページの​構成や​フォーム、​計測の​タグに​ふれる​変更は、​分かる​人に​任せるのが​無難です。
CMSの​管理画面からは、​見た目を​崩す変更も、​計測を​止める​変更も、​同じ​手軽さで​できてしまうからです。

外注する​場合に​揉めやすいのは、​頼んでから​反映までの​日数と、​契約に​含まれる​作業の​範囲です。
依頼の​窓口と​合わせて、​頼む前に​先方と​決めておきます。
直した​記録​（いつ、​どの​ページの、​何を）を​受け取れるかも​聞いておくと、​後で​何が​変わったのかを​追えます。
これとは​別に、​ドメインや​サーバー、​計測の​アカウントが​誰の​名義かは、​更新を​頼む前に​確かめておきます。
制作会社と​連絡が​つかなくなった​ときに​困るのは、​ここだからです​（確かめ方と​移し方はドメイン移管とはに​まとめています）。

私たちの​サイトの​更新の​仕方

参考までに、​この​サイトを​どう​更新しているかを​書いておきます。
この​サイトは​CMSを​使わない​静的な​HTMLで、​原稿の​手直しから​公開までを、​いまは​私が​担当しています。

コラムは、​記事1本が​Markdownという​書式の​テキストファイル1枚です。
書き出しの​仕組みに​通すと、​ページと​構造化データ、​記事の​一覧が​まとめて​作られます。
書き出す​ときには、​本文を​BudouXという​道具に​通して、​日本語が​語の​途中で​折り返されないように​しています。
直した​後は、​iPhoneの​Safariと​同じ​描き方を​する​WebKitと、​Chromeの​描き方の​両方で、​スマホと​パソコンの​幅で​折り返しを​点検します。
2つの​描き方で​見るのは、​Safariでだけ崩れる​ことが​あるからです。
2026年9月11日に​代表メッセージの​文章を​差し替えた​ときは、​BudouXを​通さずに​済ませた​ため、​iPhoneでだけ語の​途中で​折り返されていて、​同じ​日に​直しています​（詳しくは日本語が​単語の​途中で​改行される​原因と​直し方）。
文章を​差し替えるだけの​更新でも、​表示が​崩れる​ことは​あります。

サイトマップに​書く​更新日​（lastmod）は、​記事以外の​ページでは、​gitという​変更履歴の​最後の​記録の​日付から​取っています。
手で​書くと、​直したのに​日付が​古いまま、ということが​起きるからです。
記事は、​本文を​直した​ときに​原稿の​更新日を​書き換え、​その​日付を​使います。
Googleは、​lastmodの​値が​一貫して​正確だと​確かめられる​場合に​その値を​使うとし、​本文や​構造化データ、​リンクの​変更は​一般に​重要な​更新だが、​著作権の​表記の​年を​変えるだけでは​重要な​更新とは​見なされない、と​書いています​（⁠Google 検索セントラル：サイトマップの​作成と​送信、​2026年10月4日確認）。

2026年10月4日からは、​記事を​公開する​前に、​主な​事実と​出典、​自社の​体験、​題と​説明文を​1枚の​確認表に​まとめ、​私が​照らし合わせてからでないと​公開しない​ことにしました。
下​書きに​AIを​使うことも​あるからです。
Googleは、​コンテンツを​自動で​生成する​場合は​とくに、​正確性、​品質、​関連性を​優先する​よう​書いていて、​その​対象には、​検索結果に​表示されうる​title、​説明文、​構造化データ、​画像の​代替テキストも​含まれます​（⁠Google 検索セントラル：ウェブサイトで​生成 AI に​よる​コンテンツを​使用する​ための​ Google 検索の​ガイダンス、​2026年10月4日確認）。

古くなる​書き方を​やめた

更新で​手間が​かかったのは、​書いた​時点で​古くなる​日が​決まっている​記述でした。
2026年10月2日の​夜から​3日の​朝に​かけて、​公開していた​記事の​うち60本以上を、​その​時点の​公式の​情報で​見直しました。
補助金などの​締切日を​本文から​外し、​受付の​状態は、​確認した​時点で​受付中だったか​終わっていたか、という​形で​書くように​改めています。
確認できなかった​「無料」という​記述も、​この​とき外しました。
締切日は、​過ぎた​日から、​それ以上なにもしなくても​誤りに​なります。
更新の​手間を​減らすいちばんの​近道は、​古くなりにくい​書き方に​しておく​ことだと、​この​とき​思いました。

自分の​サイトほど、​ずれに​気づかない

2026年10月4日に、​会社概要の​冒頭を​「株式会社bundlyzeの​会社情報・事業内容・​大切に​している​価値観を​ご紹介します。」という​案内文から、​何の​会社かを​最初の​一文で​書いた​文章に​差し替えました。
冒頭に​会社を​説明する​一文を​置くよう、​自分で​記事に​書いていたのに、​自社の​ページが​そうなっていなかったのです​（その​記事は会社概要に​書く​項目）。
毎日のように​触っている​サイトでも、​こうした​ずれは、​別の​用事で​読み直すまで​残ります。
年に​1回の​読み直しを​表に​入れたのは、​この​ためです。

作り直す前に、​更新の​担当と​日付を​決める

更新が​止まっている​サイトを​見ると、​作り直したくなるかもしれません。
ただ、​仕組みを​新しくしても、​誰が​気づいて​誰が​直すかが​決まっていなければ、​数年後に​同じことが​起きます。
作り直すか​どうかの​判断はホームページの​リニューアルは​必要かに、​問い合わせが​減ってきた​ときの​切り分けはホームページからの​問い合わせが​減った​とき、​原因を​探す順番に​書いています。
問い合わせの​フォームを​直すなら、問い合わせフォームを​見直す​チェックリストから​始めてください。

bundlyzeは、​大阪市北区の​グラングリーン大阪を​拠点に、​大阪・兵庫を​中心とした​関西の​会社からの​ご相談に​対応していて、​打ち合わせは​Web会議でも​対面でも​できます。
全国から​オンラインでも​ご相談いただけます。
この​記事を​書いた​津嘉山は、​業務システム開発と​AWSを​専門と​する​エンジニアで、​この​サイトの​記事を​書き出す​仕組みと、​公開前の​点検の​手順も​自分で​組んでいます。

まずは、​自社の​サイトで​電話番号と​問い合わせの​宛先が​書かれている​場所を​全部​開いて、​今と​同じかを​確かめてみてください。