サイト更新が検索結果に反映されない｜原因3つと早める手順

結論：原因は3つに切り分けられる

サイトを更新したのに検索結果が古いままのとき、原因は「公開側がそもそも更新されていない」「公開はできているがGoogleがまだ見に来ていない」「直したURLとは別のURLが評価されている」の3つにほぼ収まります。この順番で上から潰すのが最短で、しかも最初の1つは自分の手元で5分で判別できます。Google公式は再クロールについて「クロールには数日から数週間かかることがある」と明記しており、再クロールのリクエストを何度押しても早くはならないとも書いています。

つまり「待つしかない」部分と「今日直せる」部分が混在しているので、先に切り分けないと、直せるはずの不具合を何週間も放置することになります。実務で多いのは、Googleのせいだと思って待っていたら、実は公開側のサイトが古い版のまま止まっていた、というパターンです。Mihataでも自社サイトで8日間この状態に気づけなかったことがあり、その実測は記事の後半にそのまま書きました。

最初にやること（1分）

ブラウザのシークレットウィンドウで、該当ページのURLを直接開いてください。ここで新しい内容が見えていれば「公開側は更新できている」ので、原因は2番目か3番目です。古い内容が見えていれば、Googleは関係ありません。サイト側の問題なので、検索エンジンを待っても永遠に直りません。

症状別：疑うべき原因と、最初に見る場所

先に地図を出します。いま起きている症状がどれに当たるかで、見に行く場所が変わります。どの症状でも「推測で設定をいじる」より先に、下の「最初に見る場所」を1つだけ確認してください。

表の上から3行目までで、ほとんどの相談は決着します。4行目以降は「一度は反映されたことがあるのに、特定のページだけ挙動が違う」ときに疑う領域です。

手順1：そもそも公開側が更新されているかを確かめる

最初に確かめるのは検索結果ではなく、いま公開されているHTMLそのものです。ここが古ければ、Google側の話をする意味がありません。CMSの管理画面が「公開中」と表示していても、それは配信されている証明にはならない、というのが一番見落とされる前提です。

生HTMLを1行で確認する

ターミナル（macOSなら「ターミナル」、Windowsなら PowerShell）で次のように打つと、ブラウザのキャッシュも拡張機能も介さない「配信されている生のHTML」が見られます。URLは自分のページに置き換えてください。

• タイトルを確認する： curl -s https://example.com/news/ | grep -o '<title>.*</title>'
• 更新した文言が入っているか確認する： curl -s https://example.com/news/ | grep '新しい料金'
• 説明文（meta description）を確認する： curl -s https://example.com/news/ | grep 'name="description"'

2つ目のコマンドで、更新したはずの文言が1行も返ってこないなら、公開側のHTMLにその文言は存在していません。制作会社に更新を依頼している場合も、これを自分で1回打つだけで「依頼が反映されていないのか、Googleがまだ見ていないのか」が確定します。ターミナルを開きたくなければ、シークレットウィンドウで開いてページのソースを表示（Ctrl+U / Cmd+Option+U）しても同じことが確認できます。

キャッシュのヘッダーを見る

生HTMLが古かった場合、次は「誰が古い版を握っているのか」です。curl -sI https://example.com/news/ でヘッダーだけを取り、次の3つを見ます。

• cache-control： max-age の秒数が極端に大きい（たとえば 31536000＝1年）と、一度配られた版が長く居座ります
• age： そのレスポンスがキャッシュされてから何秒経っているか。大きい値ならキャッシュから返っています
• last-modified / etag： 更新したはずなのに日付が古いままなら、配信されている実体が古い版です

この etag と last-modified は、Google側の挙動にも直結します。Googleのクローラーは HTTPキャッシュの仕組みに対応しており、前回取得時の ETag を If-None-Match で送り、サーバーが「変わっていない」と答えれば HTTP 304 を受けて前回の内容を使い続けます。つまり、更新したのにサーバーが同じ ETag を返し続ける設定になっていると、Googleから見て「このページは変わっていない」ことになります。

公開処理・ビルドが失敗しているケース

最近のサイトは、CMSで記事を保存すると裏側でサイト全体を作り直して配信する作りが多くなっています。この構成では、CMS側の保存が成功していても、サイトを作り直す工程が失敗していれば本番は1文字も変わりません。しかもCMSの画面には成功と出るので、管理画面だけを見ていると何も気づけません。

当てはまる心当たりがあれば、公開側（ホスティングやデプロイ環境）の履歴・ログを見て、最後に成功した公開がいつかを確認してください。ここが「更新した日より前」で止まっていたら、原因はそれです。

手順2：Search Console の URL 検査で「Googleが見ている版」を見る

公開側が新しくなっていることを確認できたら、次はGoogle側です。Search Console の上部にある検索窓にURLを貼ると、URL 検査ツールが開きます。ここで見るべきは2か所だけです。

「前回のクロール」の日時

「ページのインデックス登録」を展開すると「前回のクロール」が出ます。公式ヘルプの説明どおり、これは「このページが Google で前回クロールされた日時」です。読み方は単純で、この日時が、あなたが更新した日時より前なら、Googleはまだ新しい版を見ていません。この場合、検索結果が古いのは正常な挙動であって、設定を疑う段階ではありません。

逆に、前回のクロールが更新後の日時なのに検索結果が古いままなら、クロール待ちではない別の問題です。手順4（正規URL）や、表示側の反映を疑う段階に進みます。

「インデックスされたページ」と「公開URLをテスト」は別物

URL 検査の既定の結果は、公式ヘルプが「これはライブテストではありません」と注意しているとおり、Googleが最後に取り込んだ版です。いま公開されているHTMLではありません。一方「公開URLをテスト」を押すと、その場でURLを取得して検査します。

この2つを並べて見ると切り分けが一気に進みます。ライブテストでは新しい内容が見えて、インデックス済みの版は古い。これなら純粋にクロール待ちです。ライブテストでも古い内容が返るなら、手順1に戻ってください。公開側が古いということなので、Googleは正しく動いています。

実務では、HTMLをそのまま目で確認するのが一番確実です。検査結果の「HTMLを表示」でGoogleが取り込んだHTMLが見られるので、更新したはずの文言で検索（Ctrl+F）してみてください。

更新が反映されない件とあわせて、「公開したのに最初から検索に出てこない」「検索結果の説明文が設定した文章と違う」という相談もよく一緒に来ます。症状が違うと見る場所も変わるので、公開したのに検索に出てこないときの切り分けと、検索結果の説明文が設定と違うときの直し方はそれぞれ別にまとめています。

なお、ここまでの切り分けは特別な道具を必要としません。ただ、「どこを見ればいいのか分からないまま制作会社とのやり取りが何往復もしている」という状態なら、構成ごと見直したほうが早いこともあります。Mihataでは中小企業のHP制作・リニューアルと、更新が確実に反映される公開フローの構築もお手伝いしています。いま困っている切り分けだけで済むならこの記事で十分なので、必要なときだけ見てください。

手順3：インデックス登録リクエストの実際の効き方と上限

URL 検査の画面には「インデックス登録をリクエスト」というボタンがあります。クロール待ちだと分かったときに押す価値はありますが、期待されているほどの効き目はありません。公式が自分で書いている制約を、先に知っておくほうが落ち着いて対応できます。

できること・できないこと

• 同じURLに何度押しても早くならない。公式は「再クロールのリクエストを同じ URL に対して何度も行っても、クロールが早くなることはありません」と明記しています
• インデックスされる保証はない。URL 検査ツールのヘルプにも「リクエストを送信しても、ページが Google インデックスに表示されるとは限りません」と書かれています
• 1日あたりの上限がある。公式ヘルプは上限の存在に触れていますが、具体的な件数は公開していません
• 反映まではやはり数日から数週間かかる。リクエストは「順番待ちの列に並ぶ」程度の意味で、割り込みではありません

結論として、重要なページを数本直したときに1回押す、という使い方が正しい使い方です。全ページを1本ずつリクエストするのは、上限に当たって終わるだけで時間の無駄になります。公式も「大量のURLがある場合はサイトマップを送信してください」と、はっきり別の手段に誘導しています。

やっても効かないこと

検索結果を早く入れ替えたい焦りから、効かない操作に時間を使ってしまうことがあります。実務で見かける空振りは次のとおりです。いずれも「Googleの再クロールを早める」効果はありません。

• 同じURLのリクエストを毎日押す
• robots.txt や meta robots を触ってみる（クロールを止めることはできますが、早めることはできません）
• ページを削除して作り直す（URLが変われば、評価の蓄積を捨てて最初からやり直しになります）
• 公開日時だけを現在時刻に書き換える（本文が変わっていなければ、重要な更新として扱われません）

手順4：継続的に反映を早める唯一の手段＝sitemap の lastmod

単発のリクエストではなく「更新したらだいたい早く反映される状態」を作りたいなら、手段は実質ひとつです。sitemap.xml の <lastmod> を、本当の更新日時で出すことです。

正確であることが条件

Googleのサイトマップの作成と送信には「Google は、<lastmod> の値が一貫して検証可能な形で正確である場合にこれを使用します」と書かれています。つまり、信用できると判断されたサイトマップでしか効かない仕組みです。

そして「重要な更新」の定義も示されています。本文・構造化データ・リンクの更新は重要な更新にあたりますが、著作権表記の年を変えただけのようなものは該当しません。サイドバーやフッターの文字が変わっただけで lastmod を更新する必要はない、という趣旨です。

全URLに今日の日付を出すのは逆効果

ここが一番の落とし穴です。「早く見に来てほしいから全ページの lastmod を毎日の日付にしよう」という発想は、はっきり裏目に出ます。Googleは公式ブログで、7年前に更新されたページについて「昨日更新した」と伝え続けるなら、やがて最終更新日の申告自体を信じなくなる、と述べています。

いったん信用されなくなると、本当に更新したときの lastmod も効かなくなります。短期的に何も得をせず、長期的に唯一の手段を失う、という割の悪い取引です。実務での方針は次の2つだけです。

• 正しい更新日時を出せるページだけ lastmod を書く。公式も「自信のあるページだけに使ってもよい」と認めています
• CMSの「更新日時」が、保存するたびに動くのか、本文を直したときだけ動くのかを確認する。前者なら、本文の更新だけを拾う設定に寄せる

自分のサイトマップを確認する

いま何を出しているかは、これで見られます。

• curl -s https://example.com/sitemap.xml | head -40
• 特定URLの申告値だけ見る： curl -s https://example.com/sitemap.xml | grep -A2 '/news/'

全URLが同じ日付、あるいは lastmod が1つも無い、というのはどちらもよくある状態です。Search Console のサイトマップレポートで、最後に読み取られた日と検出URL数もあわせて確認しておきます。

手順5：それでも古いままのとき、別のURLが評価されている

公開側は新しく、クロールもされているのに検索結果が変わらない。このときは、あなたが直したURLと、Googleが検索結果に出しているURLが違う可能性を疑います。同じ内容が複数のURLで見られる状態だと、Googleはそのうち1本を代表（正規URL）として選び、そのページを検索結果に出します。

「Google が選択した正規 URL」を見る

URL 検査の結果に「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」が並びます。この2つが食い違っていたら、それが答えです。あなたが更新したのは前者で、検索結果に出ているのは後者、という状態になっています。

Search Console のページのインデックス登録レポートでは、同じことが「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」「重複していますが、ユーザーが正規ページとして選択していません」という状態名で出てきます。該当URLの一覧も取れるので、全体でどれだけ起きているかはこちらで見るほうが早いです。

食い違いが起きる典型

原因はたいてい地味な重複です。重複した URL の統合で説明されている状況のうち、中小企業のサイトで実際によく当たるのは次のあたりです。

• www の有無： https://example.com/ と https://www.example.com/ の両方が開ける
• 末尾スラッシュ： /news と /news/ が両方開ける
• http が生きている： httpsへ転送されず、両方が別URLとして存在している
• パラメータ付きURL： 広告やメール配信で付く ?utm_source=... 等が独立したページとして扱われている
• index.html： / と /index.html が同じ内容で開ける

対処は、片方を301リダイレクトで寄せ、残したい側のURLを link rel="canonical" で明示し、sitemapにも残したい側だけを載せる、という3点セットです。ここで注意しておきたいのは、canonical の指定は強いヒントであって命令ではないことです。公式も、指定が無ければGoogleが自分で最適な版を判断すると書いています。指定とリダイレクトとサイトマップが互いに矛盾していると、意図しない側が選ばれ続けます。

なお、すでに検索結果に出てしまった古いURLや古い内容を「消したい」場合は、反映を待つのとは別の手順になります。検索結果に残った古い情報を消す手順に分けて書いています。

反映までの目安期間

「何日で反映されますか」という問いに、Googleは確定した数字を出していません。公式に書かれている範囲だけを並べると、次のとおりです。これ以上細かい約束はどこにも存在しないので、社内やお客様への説明も、この幅のまま伝えるのが誠実です。

幅が広いのは、更新頻度の高いサイトのページは頻繁に見に来られ、めったに変わらないサイトのページは間隔が開く、という性質があるためです。だから「反映を早める」の本質は、個別のリクエストではなく、更新が正しく申告される状態を保ち続けることになります。

一方で、この幅を根拠に待ってしまうのが危ないところでもあります。「数週間かかることもあるらしい」と思っていたら、公開側が止まっていた──次に書くのは、まさにそれをやった話です。

実測：自社サイトで8日間、ページが古い版のまま凍結していた話

ここからは、Mihataが自社サイト（mihata.jp）の運用で実際に起こした失敗の記録です。以下の日付・数字は公式ドキュメントの話ではなく、自社サイトの運用実測です。

何が起きたか

mihata.jp は、CMSで記事を更新するとサイト全体を作り直して配信する構成です。2026年9月24日から10月2日までの8日間、このサイトを作り直す処理が失敗し続け、本番サイトが古い版のまま凍結していました。その間に公開したはずの記事は、検索結果に出ないどころかサイト上にも存在していませんでした。

原因はビルド側です。全ページに同じ大きなデータを埋め込む作りにしていたため、ページ数ぶん膨らんでビルド環境のディスク容量（20GB）を超え、公開処理が完走しなくなっていました。検索の設定の問題でも、Googleの都合でもありません。

なぜ8日も気づかなかったか

CMS側の投稿は、毎回「成功」を返していたからです。管理画面には記事が並び、公開ステータスも正常。CMSの画面だけを見ている限り、一切の異常が見えませんでした。「公開した」という記録と「公開されている」という事実が、8日間ずれたままになっていたわけです。

ここから得た前提はひとつです。CMSが成功と言っていることは、公開されている証明にはならない。公開ボタンが押せたことと、本番URLに新しいHTMLが載っていることは、別の事実として確認しないといけません。

確認のやり方をどう変えたか

以降、Mihataは反映の確認を管理画面ではなく、本番から取得した実データの突き合わせに変えました。やっていることは2つだけです。

• 本番の sitemap.xml を取得し、更新したページの <lastmod> が実際に新しくなっているかを見る
• 更新済みの既存ページを実際に取得し、<title> が新しい内容になっているかを突き合わせる

どちらも前述の curl で確認できる範囲です。特別な監視ツールは使っていません。重要なのは「見る対象を管理画面から本番の応答に変えた」という点だけです。

新しいURLは見えるのに、直したページだけ古い

この件のあとに分かった、もうひとつの実測があります。新しく作ったURLは比較的すぐ200で返るのに、既存のURLは長期キャッシュのせいで古い版が返り続けることがあるという挙動です。

この状態は紛らわしく、「新しい記事は見えているから公開は動いている」と判断してしまいます。症状として「新しいページは出るのに、直したページだけ古い」が出たら、公開処理ではなく既存URLのキャッシュを疑ってください。手順1で挙げた cache-control と age を見れば、キャッシュから返っているかどうかはすぐ分かります。

読者への教訓

制作会社に更新を頼んでいる場合でも、curl かシークレットウィンドウで自分で生HTMLを1回確認するだけで、Googleのせいなのかサイト側のせいなのかが切り分けられます。これは専門知識ではなく、ただ「本番を直接見る」という手続きです。

この1手があるだけで、制作会社への連絡内容も変わります。「検索結果に出ません」ではなく「本番のHTMLに更新した文言が入っていません」と伝えられれば、相手も原因を探す場所を間違えません。逆に本番HTMLが新しいことまで確認できていれば、それはもう待つ時間です。

まとめ：今日やる順番

最後に手順だけ並べます。上から順に、1つずつ潰してください。

1. シークレットウィンドウか curl で、本番の生HTMLに更新内容が入っているかを確認する
2. 入っていなければ、公開処理・ビルドの履歴とキャッシュのヘッダーを確認する（Googleは無関係）
3. 入っていれば、Search Console の URL 検査で「前回のクロール」を見る
4. クロールが更新前なら、インデックス登録リクエストを1回だけ押して待つ
5. 並行して、sitemap の lastmod が本当の更新日時で出ているかを直す
6. クロール後なのに古いままなら、「Google が選択した正規 URL」を確認する

サイトの更新が確実に反映される状態を作るのは、記事を書くことと同じくらい運用の中身です。自社で切り分けまでは追えないという場合や、更新のたびに不安になる作りのまま運用しているという場合は、現状の確認からご相談いただけます。

よくある質問