企業サイトのお知らせページは、一覧で「何の案内か」を伝え、詳細で「誰が、いつ、何をすればよいか」を説明する構成にします。特に、記事を出した公開日と、休業・イベント・変更が適用される期間を分けておくと、過去の案内を現在の条件と取り違えにくくなります。
この記事では、お知らせの一覧・詳細・期限後の表示を設計します。会社サイト全体で必要なページを決めるときは、親記事のコーポレートサイトの掲載内容の決め方をご覧ください。以下の表や例は一般的な設計案で、SEVEN PEBBLESの営業予定や顧客事例ではありません。
お知らせにする情報と、常設ページに置く情報を分ける
お知らせは、発生した出来事や変更を時点とともに伝える場所です。サービスの現在の仕様、問い合わせ方法、会社の住所など、継続して参照する情報の正本をすべてお知らせへ置くと、利用者が古い記事から現行条件を判断してしまうことがあります。
「新サービスを開始した」という案内はお知らせに載せ、現在の提供内容はサービスページで説明する、といった役割分担が考えられます。お知らせには現行ページへの通常リンクを付け、条件が変わったときは正本と過去の案内を合わせて点検します。
| 情報の種類 | お知らせで伝えること | 併せて確認する掲載面 |
|---|---|---|
| 営業日・受付の変更 | 対象、変更期間、利用者が取る行動 | 問い合わせページや受付案内の現在の状態 |
| サービス開始・変更 | 何がいつ変わるか、対象者 | 現行サービスページと申込先 |
| イベント | 日時、対象、参加方法、受付期限 | 申込フォームの受付状態 |
| メディア掲載・活動報告 | 確認できる出来事、掲載先、日時 | 引用・画像・関係者名の公開可否 |
掲載する事実がないときに、更新頻度を満たすためだけのニュースを作る必要はありません。架空の受賞、実績、参加者数や成果を加えず、確認できる出来事に絞ります。
一覧には、見分けるための情報を置く
一覧では公開日、具体的なタイトル、必要な分類、重要な状態を示します。タイトルを毎回「お知らせ」にせず、どのサービスや営業日の案内かが分かる言葉にします。サムネイルを使う場合も、重要な情報を画像の中だけへ入れません。
詳細へのリンクは、記事タイトルなど行き先が分かる文言にします。W3Cのリンクの目的に関する説明も、リンク文言とその文脈から目的が分かることを扱っています。「こちら」だけのリンクをいくつも並べるより、内容を読み分けられる入口にしてください。
重要な営業案内を一覧の先頭に置く場合は、対象期間が終わった後に固定を解除する担当と確認日を決めます。件数が増えたらページ送り、カテゴリー別一覧などを使い、トップページには入口を残します。何件出すべきかという共通の正解より、スマートフォンでタイトルが判読でき、必要な案内へ進めるかを確認します。
公開日・対象期間・終了後の状態を分ける
公開日はページを初めて出した日、対象期間は読者が案内に従う期間です。必要なら実質的な内容を変更した更新日も表示します。「投稿日」しかない休業案内では、いつ休むのかを本文から探さなければなりません。対象期間は見出しや冒頭にも書きます。
Googleの公開日・更新日についての公式資料は、ページの公開・更新日を、本文で扱う出来事の日付と区別しています。表示日付と構造化データを設定する場合は一致させ、実質的な更新がないのに日付だけを新しく見せません。検索結果での日付表示は保証されません。
| 案内の性質 | 日付・期間 | 期限後に確認すること |
|---|---|---|
| 一時的な受付停止 | 公開日と停止・再開の予定を分ける | 実際の再開確認後、終了表示と現行窓口を案内 |
| 申込を伴うイベント | 開催日と申込期限を分ける | 申込先の受付終了、一覧の募集中表示を点検 |
| 恒常的な条件変更 | 公開日と適用開始日を分ける | 現在の条件が常設ページにも反映されているか確認 |
| 活動・掲載の記録 | 公開日と出来事の日付を必要に応じて表示 | 記録として残す価値、参照先、公開許可を見直す |
これは本記事の編集上の設計表です。期限を過ぎた記事を一律に削除するルールではありません。記録として残す、終了を追記する、現行案内へつなぐなど、読者に必要な情報とURLの利用状況から判断します。
詳細ページは「対象・変更・行動」の順で原稿化する
冒頭に案内の要点を置き、その後に対象、日時、変更前後、利用者が取る行動、問い合わせ先を整理します。挨拶を長く続けてから要点を書くより、利用者がまず判断できる形にします。
次は架空の設備点検案内の構成例です。日付や時間の実例を創作せず、自社で確定した値を入れる項目として示します。
| 掲載箇所 | 原稿へ入れる内容 | 確認先 |
|---|---|---|
| タイトル | 対象設備・窓口と、点検による変更 | 承認済みの点検計画 |
| 冒頭 | 誰の利用に、どのような影響があるか | 業務担当が確認した対象範囲 |
| 日時 | 点検開始・終了の時刻、タイムゾーンが必要か | 作業計画と受付担当 |
| 利用者の行動 | 代替窓口、利用を控える時間、再開確認先 | 実際に利用できる窓口・ページ |
| 期限後 | 再開結果と、現在の案内へのリンク | 作業の完了記録 |
「予定どおり完了しました」と書くには完了の確認が必要です。終了予定時刻を過ぎたことだけで再開したと判断せず、状態が不明なら担当者へ確認します。未確定の料金や条件が重要な判断に関わる案内も、編集者の推測で補いません。
WordPressでは投稿・分類・表示面を合わせて確認する
WordPressの通常の投稿を使う構成では、タイトルと本文を登録し、お知らせ用カテゴリーなどへ分類して一覧を作れます。公式のカテゴリー画面の説明では、投稿を分類する機能が案内されています。ただし、カテゴリーを付ければ意図したトップページ欄へ自動表示されるとは限りません。テーマやサイトの設定を確認してください。
ニュース専用の投稿形式を使うサイトでは登録先が異なります。管理画面で現在の構成を確認し、「どこで作るか」「どの一覧へ出るか」「予約日時の基準は何か」を制作・運用担当とそろえます。下書きプレビューでは本文だけでなく、一覧のタイトル、省略表示、日付、分類、詳細へのリンクも点検します。
承認者や公開担当を決める工程は更新の承認フローを参照してください。本記事の中心は、承認後の情報が一覧と詳細で矛盾なく見えることです。
公開後は3つの掲載面と期限後の状態を見る
- トップページ等の入口：重要な案内へ進めるか。
- お知らせ一覧：対象・日付・タイトル・終了状態が読み分けられるか。
- 詳細と申込先：本文の期間、現在の受付状態、問い合わせ先が一致するか。
スマートフォンでは長いタイトルの折り返し、日付の欠け、押せる範囲を確認します。バナー、SNS等で同じ案内を出している場合は、内容変更時に点検する掲載面として社内記録へ追加します。修正履歴は、訂正した箇所、確認済みの原資料、修正日時、公開確認者を残します。
一覧から詳細、詳細から現行サービスへ進む関係は内部リンク設計の点検表で整理できます。期限付きの案内には、公開した時点で「次に確認する日」と「終了後に変える表示」を決めておきます。
よくある質問
毎週更新すれば検索順位は上がりますか？
更新回数だけで順位向上を約束できません。読者が必要とする確認済みの情報を掲載し、現在の条件と矛盾しないことを優先します。
終了した案内はすべて削除すべきですか？
一律には決めません。記録として残す必要や外部からの参照があるかを確認し、終了の明記や現行案内への接続を検討します。古い条件を現在も有効に見せないことが大切です。
参照した一次資料
資料確認日：2026年10月14日。図と掲載面・期間の比較表は一次資料を基にした独自の設計案です。営業予定、成果、運用実績を示すものではありません。
