ホームページの更新日を調べる方法｜スマホとPCでの確認手順

ホームページの更新日は、ページに表示された日付・ソースのdateModified・サイトマップのlastmod・HTTPヘッダーのLast-Modified・Search Consoleの「前回のクロール」・Wayback Machineのアーカイブ日、この6か所で調べられます。このうち4つは、パソコンを開かずスマホのブラウザだけで確認できます。

この記事は、自社サイトの更新日が今どう記録されているかを自分の手で確かめたい方に向けて書いています。読み終わる頃には、スマホとPCそれぞれの確認手順と、6か所の日付が食い違ったときにどれを信じればいいかを判断できる状態を目指します。

なお、更新したはずなのに古い内容が表示されるという症状は、更新日ではなくキャッシュの問題です。切り分けはホームページが更新されない原因とキャッシュの消し方にまとめています。担当と頻度を決めて更新を続ける仕組みづくりは更新されないサイトの信用低下を直す更新体制の作り方が担当です。この記事は「今の状態を調べる」工程だけを扱います。

Contents / 目次

1. ホームページの更新日を調べる6つの方法と使い分け早見表
2. スマホでホームページの更新日を調べる4ステップ
3. PCでホームページの更新日を調べる手順。ソースとHTTPヘッダー
4. 6つの日付が食い違うときの読み解き方
5. 更新日がどこにも出ていないときの直し方
6. 更新日の確認でよくある失敗と回避法
7. 更新日を調べるときの現場の落とし穴と妥協点
8. ホームページの更新日についてよくある質問
9. まず1分でできること

ホームページの更新日を調べる6つの方法と使い分け早見表

目的が「自社サイトがいつ更新されたか知りたい」だけなら、まずスマホでサイトマップを開いてlastmodを見る方法から試すのが手軽です。所要時間は1分ほどで、追加のツールもアプリも要りません。

ただし、WordPress標準のサイトマップにはlastmodが出力されません。開いてみて日付が見当たらない場合は、ページ上の表示日付を見るか、Search Consoleの「前回のクロール」を確認する方法に切り替えてください。標準サイトマップにlastmodを足す手順は、記事の後半で解説します。

また6つの方法は、それぞれ違う日付を見ています。ここを混ぜると「サイトは更新したのにGoogleの表示が古い」といった混乱が起きます。まず何が分かる方法なのかを整理しておきましょう。

調べ方	分かる日付の正体	スマホだけで可能か	時間の目安
ページに表示された更新日	サイト運営者が「更新した」と自己申告している日	できる	10秒
ソース内のdateModified	構造化データとして検索エンジンに伝えている更新日	PC推奨	1分
XMLサイトマップのlastmod	検索エンジン向けに宣言している最終更新日時	できる	1分
HTTPヘッダーのLast-Modified	サーバー上でそのファイルが最後に書き換わった日時	PCが必要	2分
Search Consoleの「前回のクロール」	Googleが最後にそのページを取りに来た日時	できる	2分
Wayback Machineのアーカイブ	外部に保存された過去の姿と、その保存日	できる	3分

使い分けの基本。自社サイトの「宣言している更新日」を知りたいならサイトマップのlastmod、「実際にいつ書き換わったか」を知りたいならHTTPヘッダーのLast-Modified、「Googleにいつ認識されたか」を知りたいならSearch Consoleを見ます。

この章の結論として、まず自分が知りたいのが「宣言した日」「書き換わった日」「Googleが見た日」のどれなのかを決めてください。それが決まれば、下の手順のうち使うのは1つか2つで済みます。

スマホでホームページの更新日を調べる4ステップ

スマホだけで確認できるのは、表示された更新日・サイトマップのlastmod・Search Consoleの前回のクロール・Wayback Machineの4つです。すべてブラウザ（Safari、Chromeなど）だけで完結し、アプリのインストールは要りません。

ステップ1. ページに書かれた更新日を確認する

まず調べたいページをスマホで開き、タイトルの近くと記事の一番下の2か所を見ます。「更新日」「最終更新」「Updated」などのラベルが付いた日付があれば、それが運営側の申告している更新日です。

ここで日付が1つも見つからない場合、そのサイトは更新日を表示していません。表示があっても「2023.04.12」のように公開日と区別がつかない書き方だと、読者にも検索エンジンにも判断できない状態です。この場合の直し方は後半のWordPressの章で解説します。

ステップ2. サイトマップを開いてlastmodを見る

スマホのアドレスバーに自社ドメインを入力し、末尾にサイトマップのパスを足して開きます。XMLがそのまま文字として表示されるので、各URLの下にある<lastmod>の日付を読めば、そのページの最終更新日時として宣言している値が分かります。

自社のサイトマップの場所が分からないときは、先にhttps://自社ドメイン/robots.txtを開いてください。ほとんどのサイトでSitemap:で始まる行があり、そこに正しいサイトマップURLが書いてあります。

• WordPress標準の場合：https://自社ドメイン/wp-sitemap.xml（Make WordPress Coreの公式アナウンスのとおり、WordPress 5.5以降で自動生成されるインデックスのURLです）
• 制作会社が用意した場合：https://自社ドメイン/sitemap.xmlに置かれていることが多いです
• SEO系プラグインを入れている場合：プラグインが独自のサイトマップを出していることがあります。正確なURLは各プラグインの公式ドキュメントで確認してください

WordPress標準のサイトマップを開いてlastmodが1つも見当たらなくても、故障ではありません。Make WordPress Coreの公式アナウンスのとおり、標準実装ではURL（loc）だけを出力し、lastmodは含めない設計になっています。 追加する方法は後半で解説します。

ステップ3. Search Consoleの「前回のクロール」を見る

スマホのブラウザでGoogle Search Consoleを開き、調べたいページのURLでURL検査を実行します。検査結果の画面に、Googleが最後にそのページを取りに来た日時が表示されます。項目名や画面の並びは変わることがあるので、見当たらないときはGoogle公式のURL検査ツールのヘルプで最新の画面構成を確認してください。

この日時が示すのは「Googleが最後にそのページを取りに来た日」であって、あなたが更新した日ではありません。Google公式のURL検査ツールのヘルプでも、このページがGoogleで前回クロールされた日時が現地時間で表示されると説明されています。

Search Consoleにまだ自社サイトを登録していない場合は、先に所有権の確認が必要です。手順はSearch Console登録手順と所有権確認にまとめています。

ステップ4. Wayback Machineで過去の姿と見比べる

インターネット・アーカイブが運営するWayback Machineは、過去のWebページを保存して公開している非営利のサービスです。 スマホのブラウザでサイトを開き、自社URLを入力すると、保存された日がカレンダー上に点で表示されます。

使いどころは、更新日がどこにも記録されていないサイトの調査です。たとえば2024年の保存分と直近の保存分を開いて見比べれば、「この2年で実質的に何も変わっていない」といった事実を、自分の記憶ではなく記録として確認できます。リニューアルの社内提案で「何年止まっているか」を示す材料にもなります。

ただし、すべてのサイトが同じ頻度で保存されているわけではありません。保存が数年に1回しかない、あるいは1件も無いこともあります。カレンダーに点が少ないときは、そこから更新の有無を読み取ろうとせず、ほかの方法に切り替えてください。

この章の結論として、スマホで用が足りるのは「宣言された更新日」と「Googleが見た日」までです。サーバー上で実際に何が書き換わったかを確かめたい段階に来たら、次のPCの手順に進んでください。

PCでホームページの更新日を調べる手順。ソースとHTTPヘッダー

PCが必要になるのは、ページのソースを開いて構造化データのdateModifiedを読む場合と、HTTPレスポンスヘッダーのLast-Modifiedを見る場合の2つです。どちらもブラウザに最初から入っている機能だけでできます。

ステップ1. ソースを開いてdateModifiedを探す

調べたいページを開いた状態で、次の手順で進めます。

1. ページ上で右クリックして「ページのソースを表示」を選ぶ（メニューの名称はブラウザによって変わります）
2. ソースが開いたら、Ctrl＋F（MacはCmd＋F）でページ内検索を開く
3. 検索窓にdateModifiedと入力する

ヒットすれば、次のような形で更新日時が書かれています。これは検索エンジンに向けて「このページはこの日時に更新した」と機械可読な形で伝えている値です。

"datePublished": "2026-04-10T10:00:00+09:00",
"dateModified": "2026-08-28T15:30:00+09:00"

ヒットしない場合は、構造化データを出していないか、Articleなどの型を使っていないだけです。ページ自体が壊れているわけではありません。dateModifiedで見つからないときは、更新modified<timeの3語でも検索してみてください。<time datetime="...">タグに日付が入っていることがあります。

ステップ2. Last-Modifiedヘッダーを確認する

HTTPレスポンスヘッダーのLast-Modifiedとは、サーバーが「このファイルを最後に書き換えたのはこの日時です」とブラウザに返す情報のことです。ブラウザの開発者ツールで確認できます。以下はChrome・Edgeでの手順ですが、タブやチェックボックスの名称・位置はブラウザとバージョンによって変わります。画面と違っていたら、Chrome DevTools公式のネットワーク機能のドキュメントで最新の名称を確認してください。

1. 調べたいページを開いた状態で、WindowsはF12、MacはCmd＋Option＋Iで開発者ツールを開く
2. 上部のタブから「Network」を選び、「Disable cache」にチェックを入れる
3. その状態でページを再読み込みする
4. 一覧の一番上にあるHTMLドキュメント（Typeがdocumentの行）をクリックする
5. 右側の「Headers」を開き、Response Headersの中にlast-modifiedがあるか見る

ターミナルが使える環境なら、次の1行のほうが早いです。コピーしてURLだけ差し替えれば動きます。

# ［前提］Mac は「ターミナル」、Windows は「コマンドプロンプト」で実行します。
# example.com の部分を、調べたい自社サイトの URL に置き換えてください。

# Mac / Linux の場合
curl -sI https://example.com/ | grep -i last-modified

# Windows（コマンドプロンプト）の場合
curl.exe -sI https://example.com/ | findstr /I last-modified

Windowsで「’curl.exe’ は、内部コマンドまたは外部コマンドとして認識されていません」と出る場合は、その環境にcurl.exeが入っていません。Microsoftの開発者向けドキュメントのとおり、curl.exeはWindows 10のInsider build 17063以降に標準で同梱されたもので、それ以前の環境では別途インストールが必要です。入れずに済ませたいときは、上の開発者ツールの手順で確認してください。

何も表示されなくても異常ではありません。Last-Modifiedを返すかどうかはサーバーとCMSの設定によって変わり、動的にページを組み立てる構成では返らないことがあります。 逆に、ホームページビルダーなどで作った静的HTMLのサイトでは、ファイルの更新日時がそのまま正確に返ってきます。CMSより古い作りのサイトのほうが正確な値が取れる、という逆転が起きる項目です。

ステップ3. document.lastModifiedは使わない

ブラウザのアドレスバーにjavascript:alert(document.lastModified)と入力する方法が古くから紹介されていますが、自社サイトの更新日を調べる用途では使わないでください。MDNのDocument.lastModifiedのリファレンスにあるとおり、最終更新日時が分からない場合は、その時点の現在日時が返る仕様だからです。

つまりLast-Modifiedを返さないサイトで実行すると、いつ試しても「今日の日付」が返ってきます。これを「今日更新された」と読んでしまう誤解が、現場でもっとも多い勘違いです。

確認結果をそのまま書き込めるチェックリスト

調べた結果は、その場でメモに落としておくと制作会社とのやり取りが速くなります。以下をコピーして使ってください。

■ 更新日 確認シート（調査日 2026-08-28 / 担当 ○○）
対象URL：
1. ページ上の表示日付　　　　… 有 / 無 　値：
2. ソースの dateModified 　　… 有 / 無 　値：
3. サイトマップの lastmod　　… 有 / 無 　値：
   （確認したサイトマップURL：            ）
4. Last-Modified ヘッダー　　… 有 / 無 　値：
5. Search Console 前回のクロール … 値：
6. Wayback Machine 直近保存日　　 … 値：

判定：1〜3がそろって一致しているか → はい / いいえ
次にやること：

この章の結論として、PCで見るべきはdateModifiedとLast-Modifiedの2つだけです。ここまで埋まれば、次の「日付が食い違うとき」の判断に進めます。

6つの日付が食い違うときの読み解き方

6か所の日付が一致しないのは、故障でも設定ミスでもなく、ほとんどの場合は正常です。それぞれ測っている対象が違うからです。どれを正とするかは、下の表で判断してください。

見えた日付	本当に示していること	ズレる主な原因
ページ上の表示日付	運営者が更新したと申告している日	手入力のまま直し忘れる。テーマが公開日を出している
dateModified	機械向けに宣言している更新日時	プラグインが自動出力し、表示日付と別々に動いている
lastmod	検索エンジンへ伝えている最終更新日時	プラグインの一括再生成で全ページが同じ日になる
Last-Modified	サーバー上でファイルが書き換わった日時	動的生成では返らないことがある。CDN経由だと配信側の日時に置き換わる
前回のクロール	Googleが最後に取りに来た日時	更新の有無と無関係。低頻度更新サイトは間隔が開く
Wayback Machineの保存日	外部が偶然保存した日	巡回頻度に依存。保存されていない期間がある

優先順位はこう考えてください。読者に対して正なのはページ上の表示日付、検索エンジンに対して正なのはdateModifiedとlastmodです。Last-Modifiedと前回のクロールは、あくまで裏取りの材料であって、正解の日付ではありません。

そのうえで、ページ上の表示日付とdateModifiedがズレているなら、そこは必ず直してください。Google検索セントラルの公開日に関するドキュメントでも、ユーザーに表示されるデータと構造化データの日付を整合させるよう求められています。 Google検索セントラルの公開日に関するドキュメントで原文を確認できます。

この章の結論として、直すべきなのは「表示日付とdateModifiedのズレ」と「lastmodが全ページ同じ日になっている状態」の2つだけです。ほかの食い違いは放置して構いません。

更新日がどこにも出ていないときの直し方

調べた結果、6か所すべてに日付が無かった場合の対処は、表示日付の追加とlastmodの出力の2つです。WordPressならどちらもコードの追加で対応できます。

記事に公開日と更新日の両方を表示する

更新日だけを出すと、いつ書かれた情報なのかが読者に伝わりません。公開日と更新日を並べて出し、更新していない記事では更新日を出さない、という書き方が扱いやすいです。テンプレートに次のコードを入れます。

<?php
// ［前提］WordPress のテーマの single.php など、記事本文のテンプレートに貼ります。
// 子テーマで編集してください。親テーマを直接編集すると更新時に消えます。
?>
<p class="post-dates">
  公開日
  <time datetime="<?php echo esc_attr( get_the_date( 'c' ) ); ?>">
    <?php echo esc_html( get_the_date( 'Y年n月j日' ) ); ?>
  </time>

  <?php // 公開日と更新日が同じ日なら、更新日は出さない ?>
  <?php if ( get_the_modified_time( 'Ymd' ) !== get_the_time( 'Ymd' ) ) : ?>
    ／ 更新日
    <time datetime="<?php echo esc_attr( get_the_modified_date( 'c' ) ); ?>">
      <?php echo esc_html( get_the_modified_date( 'Y年n月j日' ) ); ?>
    </time>
  <?php endif; ?>
</p>

WordPress標準のサイトマップにlastmodを足す

先に触れたとおり、WordPress 5.5以降の標準サイトマップはURLだけを出力し、lastmodを含みません。 公式に用意されているフィルターで追加できます。引数と戻り値の仕様はWordPress開発者リファレンスのwp_sitemaps_posts_entryで確認できます。

<?php
// ［前提］子テーマの functions.php、または自作プラグインに貼り付けます。
// WordPress 標準の /wp-sitemap.xml に lastmod を追加します。

add_filter( 'wp_sitemaps_posts_entry', function ( $entry, $post ) {
    // W3C Datetime 形式（例 2026-08-28T15:30:00+09:00）で出力する
    $entry['lastmod'] = get_post_modified_time( DATE_W3C, false, $post );
    return $entry;
}, 10, 2 );

貼り付けたら、必ず結果を目視で確認してください。/wp-sitemap.xmlを開くと個別のサイトマップへのリンクが並んでいるので、投稿のサイトマップを開き、<lastmod>が入っているかと、日時のタイムゾーン（末尾の+09:00）が正しいかを見ます。ここを確認せずに済ませると、ズレた日時を全ページ分まき散らすことになります。

管理画面の投稿一覧に更新日の列を追加する

WordPressの投稿一覧を眺めても、どの記事が何年放置されているかは分かりません。次のコードで更新日の列を足すと、並べ替えて古い順に確認できるようになります。

<?php
// ［前提］子テーマの functions.php、または自作プラグインに貼り付けます。
// 管理画面の「投稿一覧」に「更新日」列を追加し、並べ替えできるようにします。
// 固定ページにも出したい場合は manage_posts_columns を manage_pages_columns に。

// 1. 列の見出しを追加する
add_filter( 'manage_posts_columns', function ( $columns ) {
    $columns['cl_modified'] = '更新日'; // ［列名を変えたいときはここ］
    return $columns;
} );

// 2. 各行に更新日時を出力する
add_action( 'manage_posts_custom_column', function ( $column, $post_id ) {
    if ( 'cl_modified' !== $column ) {
        return;
    }
    // 日付だけでよければ 'Y-m-d' に変更してください
    echo esc_html( get_the_modified_time( 'Y-m-d H:i', $post_id ) );
}, 10, 2 );

// 3. 見出しクリックで並べ替えられるようにする
add_filter( 'manage_edit-post_sortable_columns', function ( $columns ) {
    $columns['cl_modified'] = 'modified';
    return $columns;
} );

コードを触るのが不安な場合は、先に管理画面の基本操作を確認しておくと安心です。WordPressの編集画面の使い方で、自分で直せる範囲を整理しています。

lastmodの一覧をAIに整理させて、放置ページを洗い出す

lastmodが出るようになったら、その一覧を棚卸しに使えます。サイトマップのXMLをそのままコピーして、Claudeなどの生成AIに貼り付け、古い順に並べ替えさせるのが手っ取り早いです。 ページ数が100を超えると手作業では現実的でなくなるので、ここはAIに任せていい工程です。

指示は作り込まなくて構いません。次の程度から始めて、返ってきた表を見ながら条件を足していってください。

次のXMLは自社サイトのサイトマップです。
各URLとlastmodを抜き出して、lastmodが古い順に並べた表にしてください。
今日は2026年8月28日です。最終更新から1年以上経っているURLには印を付けてください。
lastmodが無いURLは「未取得」として別にまとめてください。

［ここにサイトマップのXMLを貼り付ける］

AIに「このサイトの更新日を調べて」とURLだけ渡すのは避けてください。AIが自分でHTTPヘッダーを取得できるとは限らず、ページの見た目や記憶から推測した日付が混ざることがあります。日付そのものは自分で取得し、AIには取得済みのデータの整理だけを任せるのが安全な線引きです。

この章の結論として、更新日が出ていない状態は「表示日付を出す」「lastmodを出す」の2つで解消します。どちらも一度入れれば以降は自動で更新されます。

更新日の確認でよくある失敗と回避法

ここからは、更新日を調べたあとに実際に起きている失敗を5つ挙げます。どれも「日付は取れたのに、その読み方を間違えた」ことが原因です。

失敗1. document.lastModifiedの結果を更新日だと信じてしまう

アドレスバーにjavascript:alert(document.lastModified)を入れる方法で「今日の日付」が出たので、制作会社に「今日更新されているはずですが」と問い合わせてしまうケースです。

前述のとおり、最終更新日時が分からない場合は現在日時が返る仕様です（MDNのDocument.lastModifiedのリファレンス）。Last-Modifiedを返さないサイトでは、いつ実行しても実行した瞬間の日時が返ります。回避するには、この方法を静的HTMLのサイト以外では使わないことです。CMSサイトではサイトマップのlastmodを見てください。

失敗2. lastmodを全ページ一括で今日の日付にしてしまう

「更新日を新しくすればクロールが早くなる」と考えて、サイトマップを再生成して全URLのlastmodを同じ日に揃えてしまうケースです。プラグインの設定やサイト移設の直後に起きます。

Googleはlastmodについて、次のように説明しています。

Google公式の記述。「Google は、<lastmod> 値が一貫して正確であることを（ページの最終更新との比較などにより）検証できる場合に、この値を使用します。」 （Google検索セントラル サイトマップの作成と送信）

つまり、実際には変わっていないページのlastmodまで新しくすると、その値は信用されず使われなくなります。 回避策は、lastmodを手で書かず、上で紹介したように投稿の実際の更新日時から自動生成することです。

失敗3. 中身を変えずに更新日だけ新しくする

誤字を1文字直しただけ、会社概要の年号を変えただけで更新日を打ち直すケースです。Google検索セントラル サイトマップの作成と送信では、メインコンテンツや構造化データ、リンクの変更は重要な更新と見なされる一方、著作権の日付の変更は重要な更新とは見なされない、と説明されています。

回避策は、更新日を動かす基準を社内で1行決めておくことです。たとえば「本文の見出しが1つ以上増減した／価格や仕様の数字が変わった／写真を差し替えた、のいずれかに当てはまるときだけ更新日を動かす」といった具合です。誤字修正では動かさない、と決めておけば迷いません。

失敗4. 表示日付とdateModifiedが別々に動いている

テーマが本文の上に出している日付と、SEO系プラグインが構造化データに書き出しているdateModifiedが、それぞれ別のロジックで動いていて食い違うケースです。テーマを乗り換えたときや、プラグインを追加したあとに起きます。

回避策は、この記事のPC手順のステップ1で、ソースのdateModifiedと画面上の表示日付を並べて見比べることです。ズレていたら、どちらか一方を止めて出どころを1つにしてください。表示とデータで違う日付を出しているのは、読者にとっても検索エンジンにとっても不親切な状態です。

失敗5. キャッシュ越しの表示を見て「更新されていない」と判断する

更新作業をした本人が自分のスマホで確認し、古い内容が出ていたので「反映されていない」と報告するケースです。実際にはサーバー側は更新済みで、ブラウザやCDNのキャッシュを見ているだけということが少なくありません。

回避策は、更新日の確認と反映の確認を分けることです。まずサイトマップのlastmodや管理画面の更新日時で「サーバー側は更新されている」と確認し、そのうえで表示が古いなら、それはキャッシュの問題として切り分けます。手順はホームページが更新されない原因とキャッシュの消し方にまとめています。

この章の結論として、5つの失敗はすべて「日付が何を測っているか」の取り違えから起きています。表の3列目（ズレる原因）を先に読んでおけば、大半は防げます。

更新日を調べるときの現場の落とし穴と妥協点

ここは教科書的な記事には書きづらい、実務での限界の話です。先に結論を言うと、他社サイトの更新日は正確には取れません。そして自社サイトでも、外から取れる日付が実態と一致しないことがあります。

競合サイトの更新日は、そもそも正確に取れない

「競合がいつ更新しているか調べたい」という相談はよくありますが、外部から確実に取れる保証はどこにもありません。更新日を表示していないサイトは多く、Last-Modifiedヘッダーが返らない構成もあり、CDNを挟んでいるとヘッダーが配信側の日時に置き換わります。lastmodも、その会社が正直に出しているとは限りません。

取れるのは「更新日を出しているサイトの、自己申告の日付」だけです。競合の動きを継続して追いたいなら、更新日を調べるのではなく、変更を検知して通知するタイプの監視ツールを使うほうが目的に合います。ただしそれも有料の運用コストが乗るので、何のために追うのかを決めてから導入してください。

古い日付が見えるのが怖くて非表示にする、は逆効果になりやすい

「2021年のままだから、いっそ日付を消したい」という判断は、現場でよく出ます。気持ちは分かります。ただ、日付を消しても更新していない事実は変わりません。むしろ読者は「いつの情報か分からない」と感じ、料金や仕様のページでは判断を保留します。

Googleも、公開日や最終更新日をラベル付きで目立つ位置に置くことを実装方法として案内しています（Google検索セントラルの公開日に関するドキュメント）。日付を隠す方向ではなく、更新できていないページを絞り込んで、そこだけ直す方向で考えてください。放置ページの洗い出しは、前の章のlastmod一覧をAIに並べ替えさせる手順が使えます。

保守契約の「更新作業」の定義があいまいなまま進みやすい

毎月の保守費を払っているのに更新日が1年動いていない、というご相談は珍しくありません。多くの場合、契約上の「更新」がWordPress本体とプラグインのバージョン更新を指していて、コンテンツの更新は別作業という前提になっています。どちらも間違ってはいませんが、認識がズレたまま1年経つと、費用対効果の判断ができなくなります。

確認の仕方はかんたんです。次の3点を制作会社に聞いてください。丸腰で「更新してますか」と聞くより、はるかに話が早く進みます。

1. 直近12か月で、コンテンツを更新したURLの一覧をもらえますか
2. そのそれぞれで、どこを変えましたか（本文／画像／価格などの区分で）
3. サイトマップのlastmodは、投稿の更新日時から自動で出る設定になっていますか

費用の内訳そのものが気になる段階なら、WordPress保守費用の相場と内訳で何にいくらかかるのかを先に把握しておくと、比較の軸ができます。

サイト構成によっては、そもそも更新日を出せない

ノーコードツールや、AIに書かせたコードをそのまま公開している静的サイトでは、更新日を自動で出す仕組みが最初から入っていないことがあります。この場合、更新日は手で書くしかなく、書き換え忘れが必ず起きます。

更新のたびに人の手が要る構成のまま運用を続けるか、更新日が自動で出るCMSに載せ替えるか。この判断は、更新頻度が月1回を超えるかどうかを目安にすると決めやすいです。関連する判断軸はVibe codingのサイトが詰む前の更新設計で整理しています。

この章の結論として、更新日の調査で本当に価値があるのは自社サイトの棚卸しです。競合調査に使おうとすると、精度の低い数字を根拠に判断することになるので、目的を自社に絞ってください。

ホームページの更新日についてよくある質問

まず1分でできること

この記事を閉じる前に、スマホで自社ドメインの末尾に/robots.txtを足して開き、Sitemap:の行があるかどうかだけ確認してみてください。そこに書かれたURLを開けば、自社サイトが今どんな更新日を宣言しているかが1分で分かります。

調べた結果、更新が長く止まっていると分かった場合は、次に読むのは更新されないサイトの信用低下を直す更新体制の作り方です。誰が・どの頻度で・何を更新するかの決め方をまとめています。

ここまで読んで、コードの追加や保守会社とのやり取りを自社だけで進めるのは難しそうだと感じた方は、コレットラボのホームページ制作・運用支援にご相談ください。今のサイトの状態を一緒に確認して、どこから手を付けるか整理するだけでも構いません。更新日の管理まで見るホームページ制作からお気軽にどうぞ。