ホームページの更新頻度に、すべての会社へ当てはまる「月○回」という正解はありません。住所・営業時間・料金は事実が変われば直ちに直す一方、実績・事例は材料と掲載許可がそろってから追加し、記事は目的と制作体制に合わせて公開するため、それぞれ動く時計が違います。三つを同じ予定へ押し込んだ結果、急ぐべき修正が定例日まで残り、書く理由のない記事だけが本数合わせで増える――避けたいのは、そんな優先順位の逆転。

先に決めるのは回数ではなく、情報ごとの「更新のきっかけ」「担当」「承認者」「期限」「最終確認日」です。事業情報・実績・記事を分けて運用表へ落とす手順を整理し、公開作業をする人だけでなく、変更を最初に知る人まで含めて設計することが、忙しい月にも止まりにくい運用の出発点。

更新頻度は「月何回」ではなく情報の寿命で決める

更新頻度を考えるとき、多くの担当者は「毎週か、毎月か」から決めようとしますが、頻度を情報の性質より先に置くと判断が逆になります。古くなった瞬間に誤案内となる情報は変更連動、案件の完了や掲載許可によって生まれる情報は発生連動、読者の疑問へ計画的に答える記事は企画連動。まず寿命と発生条件を分け、その後で日程へ落とす順序です。

この分け方なら、更新がない月も「放置」とは限りません。住所も料金も変わらず、新しい実績は許可待ち、記事は次回公開に向けて取材中なら、公開件数がゼロでも運用は進行中。変化がないことを確認した記録と、次に確認する日が残っているかを見てください。

2025年12月にIT・製造業の中小企業のマーケティング担当者110人を対象として行われた調査では、Webサイトの更新頻度について「年に1回未満」が30.0％、「必要な時だけ不定期」が27.3％でした。対象が限られるため全業種へ一般化はできないものの、ここで分けて見たいのは、更新回数の少なさと、必要な時に動ける仕組みの有無。調査概要は株式会社イノーバ「Webサイト活用調査」、割合は株式会社イノーバによる調査結果の公開ページで確認できます。

検索対策を理由に、内容が変わっていないページの日付だけを新しくしたり、サイトを新鮮に見せる目的で記事を増減したりする必要はありません。Google Search Centralが警告例として挙げるのも、実質的な変更がない日付更新や、鮮度を装うためだけの追加・削除です。基準に置くのは「何回更新したか」ではなく、読者が正しい判断をできる状態へ変わったかどうか。出典：Google Search Central「Creating Helpful, Reliable, People-First Content」。

事業情報・実績・記事を三つの更新タイミングへ分けた図

事業情報は変更が決まった時点で更新を始める

会社概要、所在地、電話番号、営業時間、休業日、料金、提供範囲、申込条件、採用条件などは、定例の更新日を待つ情報ではありません。社内で変更が確定した時点から準備を始め、公開日までに必要なページへ反映します。新料金を店頭では案内しているのにホームページだけ旧料金、移転後も古い地図が残る――こうした食い違いを防ぐ鍵は、「Web担当者が気づく」ことに依存しない連絡経路。

最初に、変更を知る部署から更新担当へ渡す項目を決めておきます。料金改定なら、新料金、適用開始日、対象商品、旧料金の扱い、見積もり中案件への適用、関連するPDFや申込フォームまでを一組に。適用日や対象範囲が抜けたまま情報が小分けで届くと、公開作業だけでなく承認までやり直しになるため、決定事項を一枚にまとめて回す方が、反映漏れと確認の往復を抑えられます。

次に作るのは、「どこに同じ情報があるか」の一覧で、料金はサービス詳細だけでなく、トップページの訴求、料金表、よくある質問、キャンペーン案内、資料ダウンロード、構造化データにも現れ、住所なら会社概要、アクセス、フッター、地図サービス、採用ページまで対象が広がります。運用表の関連ページ欄へURLやページ名を記録しておけば、変更のたびにサイト内検索から探し直す手間は不要。

一方、変更が起きにくい情報にも確認日は必要。ただし「毎月必ず全文を読む」と一律に決めず、誤りが問い合わせや契約判断へ与える影響で間隔を変えます。初版では、料金・営業日・募集状況など影響の大きい項目を短めに、沿革や理念など変化の少ない項目を長めに置き、実際の変更件数と見落としを見ながら調整すれば十分でしょう。業界共通の規則ではなく、自社の確認漏れを防ぐための目安と考えてください。

公開後の確認までが更新作業です。管理画面で保存できたことだけで終わらせず、パソコンとスマートフォンで表示を開き、リンク先、フォームの選択肢、税込・税別の表記、改定日を確かめます。公開担当と確認担当を分けられない小規模な体制なら、少し時間を空けて見直す、変更前後の画面を並べるなど、自己確認の読み飛ばしを減らす工夫が必要。

実績・事例は「公開できる状態」になった時に追加する

実績や導入事例は、案件が終わった日と公開できる日が一致するとは限りません。成果物の公開、顧客名の掲載、写真や数値の使用には確認が必要で、担当者の記憶が薄れてから材料を集めると具体性も失われます。だから更新頻度は「月に何件載せるか」ではなく、案件終了時に事実を集め、許可と原稿確認がそろったものから公開する流れで決めるのが自然でしょう。

材料を集めるなら、案件の振り返りと同じタイミング。相談前の課題、選ばれた提案、制作・導入で工夫した点、公開後に確認できた変化、掲載できる写真、顧客コメントの有無を短いフォームへ残しておけば、記事化の段階でゼロから聞き直さずに済みます。成果を断定できない場合は、実施した内容と確認できた事実を分け、推測の効果を足さないこと。

候補の棚卸しは定期的に行い、月初に「先月完了した案件」「許可待ち」「原稿確認中」「公開可能」を並べます。案件がない月に無理な事例を作る必要も、許可待ちを放置する理由もないため、ここでの定例日は公開ノルマではなく、止まっている工程を見つける日。

新しい事例を増やす一方で、古い代表事例も見直します。現在は提供していないサービス、古い画面、変更前の料金、終了した制度を前提にした説明が残るなら、注記や差し替えを検討してください。すべてを消すのではなく、当時の実績として残す価値と、現在のサービス選びを誤らせる恐れを比べ、公開継続・更新・非公開を判断します。

実績の事実収集から掲載許可、原稿確認、公開後の見直しまでの流れ

記事は目的と体制から公開間隔を決める

記事の更新頻度は、事業情報や実績より計画性を持たせやすい反面、回数だけを目標にすると薄い内容が増えます。先に決めるのは「誰の、どの判断を助ける記事か」。必要な調査、取材、執筆、画像、確認に使える時間から公開間隔を組みます。月4本を掲げても承認が月末に集中して止まるなら、その数字を運用計画とは呼べません。

記事は一種類ではありません。休業案内、申込期限、イベント情報など期限のある告知は読者が行動する前に届く日から逆算し、検索され続ける解説記事は、公開を急ぐより検索意図へ答える材料と一次情報をそろえる方を優先します。採用インタビューや調査レポートのように複数人が関わる記事では、取材候補、確認期間、公開できない表現を早めに決めること。

現実的な本数を出すには、直近の一本に使った時間を工程別に記録します。企画二時間、取材一時間、執筆四時間、画像と入稿二時間、確認一時間という具合に実績を取り、担当者が一か月に確保できる時間と照らしてください。外部へ依頼しても、企画意図や専門情報の提供、公開前の承認は社内に残るため、その時間をゼロとして計算しないのが前提です。

公開後は、読者の疑問や事業の変更に合わせて改訂し、誤字の修正と、結論・条件・手順が変わる更新を分けます。後者で残したいのは、何を見直したかが分かる記録。Google Search Centralは、検索結果に使われる公開日・更新日の判断について、ページに見える日付と構造化データを整合させ、公開または大幅に更新した日を示すことを案内しており、日付だけを新しくするのではなく、実質的な変更と更新日を対応させる必要があります。出典：Google Search Central「Influence your byline dates in Google Search」。

更新候補は検索順位だけで選ばず、問い合わせで繰り返し聞かれること、営業資料と説明がずれている箇所、制度や仕様が変わった記事、読まれているのに次のページへ進まない記事を集め、読者への影響と修正工数で並べます。新規記事を一本作るより、すでに読まれている記事の古い条件を直す方が価値の高い月もあるはず。

担当・承認・確認日を一枚の運用表にする

更新ルールは文章で長く説明するより、一行を見れば動ける表にします。最低限の列は「情報」「更新のきっかけ」「情報提供者」「更新担当」「承認者」「公開期限」「関連ページ」「最終確認日」「次回確認日」「状態」の十項目。小さな会社では同じ人が複数の役割を兼ねても構いませんが、空欄のままにせず、誰が判断するかを明示してください。

とくに分けたいのは、情報提供者と更新担当。料金変更を決める責任者、実績の事実を知る現場担当、記事の素材を持つ営業担当が、管理画面へ直接入力する必要はありません。変更を知る人が所定の方法で渡し、更新担当がページへ反映し、承認者が内容を確定する流れ。こうすれば、Web操作ができる一人へ情報収集まで集中する状態を避けられます。

公開期限に「できるだけ早く」とだけ書いても、実務上の締切にはなりません。事業情報は適用開始より前、期限付き告知は読者が準備できる日、実績は掲載許可と原稿確認の完了後、記事は編集予定日というように、情報ごとに起点と締切を対にする設計。緊急変更用の連絡手段も通常の依頼と分け、休業や価格変更が日常の修正依頼に埋もれない経路を用意しておきましょう。

情報 更新のきっかけ 主な担当 承認 期限・確認
料金・営業時間 変更の決定 決定部署→更新担当 責任者 適用前に公開／短めの定期確認
実績・事例 案件完了と掲載条件の成立 現場→原稿担当 案件責任者 許可・原稿確認後／候補は定期棚卸し
解説記事 読者課題と企画の採択 編集担当 記事責任者 制作可能な計画日／既存記事も見直す
期限付き告知 日程・条件の確定 主催部署→更新担当 告知責任者 読者の準備期間を含めて公開／終了後に撤去

表の初版に必要なのは、完璧さより空欄を見つけられること。実際に更新したら、依頼日、公開日、差し戻し理由、抜けた関連ページを記録し、翌月に列や期限を直します。運用表そのものを更新すると、自社ではどの情報が遅れやすいか、承認がどこで止まるか、外部支援を頼む範囲はどこかが見えてきます。ここまで分かれば、表は単なる記録ではなく改善の材料。

情報、きっかけ、担当、承認、確認日を一行で管理する運用表の図

更新できない月は、止める範囲を先に決める

繁忙期や担当者の不在で、予定どおり更新できない月はあります。そんな時、最優先にするのは誤案内を防ぐ更新。料金・営業時間・受付状況・募集条件など現在の判断へ直結する情報、期限付きの告知、問い合わせフォームの選択肢は止めず、記事の新規公開や大規模な事例編集は延期できると、平常時に線を引いておきます。

延期しても、材料の収集までは止めない方が再開しやすくなります。完了案件の写真とメモを保存する、問い合わせで出た質問を一行で残す、更新候補へ状態を付けるといった軽い作業なら、まとまった執筆時間がなくても継続可能。忙しさが解消した時に、記憶をたどるところから始めずに済みます。

同じ工程が繰り返し止まるなら、頻度を下げるだけでは解決しません。情報提供が遅いのか、原稿作成が重いのか、管理画面の操作が難しいのか、承認者が一人へ集中しているのか――まず詰まり方を分けてください。社内で担うのは事実の提供と最終判断、外部へ任せるのは構成・執筆・画像・入稿などと役割を切り分ければ、更新全体を丸投げせず、不足する工程だけを補えます。

更新本数を減らす判断も、運用の失敗ではありません。月二本の記事を一本文へ改めても、事業情報の正確さと実績候補の収集を保ち、一本の内容を深くできるなら読者にとっては改善であり、逆に本数を維持するため確認不足の記事を公開すれば、後から直す負担が増えるだけ。

まず30分で運用表の初版を作る

最初の作業は、サイト内の全ページを棚卸しすることではありません。まず会社概要、料金・サービス、実績、記事、期限付き告知の五つを一枚へ書き、各行に更新のきっかけ、変更を知る人、更新する人、承認する人、公開期限、最終確認日を入れます。空欄が残った列こそ、更新頻度を決められなかった原因。

そのうえで、直近三か月に起きた変更を当てはめてください。Web担当へ連絡が届かなかった、関連ページの一部だけ古かった、掲載許可待ちの実績を忘れていた、記事の承認が締切後になった――こうした実例から期限と連絡方法を修正します。運用表は理想の組織図ではなく、次の変更が起きた日に迷わないための道具です。

ホームページの更新頻度は、一つの数字では管理できません。事業情報は変更時、実績は公開条件が整った時、記事は目的と体制に合う計画で動かし、変化がない情報には確認日を置く。三つの時計を担当・承認・期限へつなげることが、更新件数の少ない月にも正確さと継続性を保つ運用の土台です。

参考資料