Mihata
Web制作2026.09.29

ホームページで404エラーが出る原因6つと直し方

自社サイトの一部のページを開くと「404 Not Found」「お探しのページは見つかりませんでした」と出る——この記事は、その画面をいま見ている方に向けて書いています。制作会社に連絡する前に、自分で確かめられることと、伝えるべき情報を先に整理します。

先に結論です。404はページ単位の事故であって、サイト全体の検索評価が下がるものではありません。Googleは公式ヘルプで「404 エラーはサイトのインデックス登録やランキングに影響を及ぼすことはない」と明言しています。実務で出会う原因は6つにほぼ収まり、そのうち本当に直すべきものは限られます。最初にやることは1つだけ、ブラウザの見た目ではなくHTTPステータスコードを測ることです。

いま出ている画面で、原因は半分まで絞れる

404は「そのURLに対応するページが無い」という意味しか持ちません。ですから、何が無いのかを先に決めます。出ている文言と、どの範囲が見られないかの2点で、見に行く先はほぼ決まります。

いま出ている症状

考えられる原因

最初に見る場所

一部のページだけ404。トップや他のページは表示される

URLの打ち間違い、ページの削除、リニューアルでのURL変更

そのURLの文字列と、Search Consoleの404一覧

トップは出るのに、下層ページがすべて404(WordPress)

パーマリンク設定・.htaccess・mod_rewrite

管理画面の「設定 > パーマリンク」

「ページが見つかりません」と書いてあるのに、検索結果には残り続ける

ソフト404(サーバーは200を返している)

コマンドでHTTPステータスを実測

サイト全体が開けない。「サーバーのIPアドレスが見つかりません」

ドメイン失効・DNS・サーバー契約

WHOISとサーバー会社の管理画面

全画面の赤い警告が出る

404ではない。セーフブラウジングの警告

Search Consoleの「セキュリティの問題」

「メンテナンス中」の表示が戻らない

CMSのメンテナンスモード

サーバー上のフラグファイル

「サイト全体が開けない」「警告が出る」は404ではない

ここを混同すると、直らないものを何時間も触ることになります。404はサーバーが生きていて、初めて返せるエラーです。サイト全体がどのページも開けないなら、原因はドメインかDNSかサーバー契約であって、ページの有無ではありません。

ドメインの更新忘れやサーバー契約の終了で全体が止まっているケースは、ホームページが突然表示されなくなったときの原因と復旧の期限に切り分け方をまとめています。そもそも自社のドメインとサーバーをどこに預けているか分からない場合は、ドメインとサーバーの管理会社を調べる3手順が先です。

赤い全画面の警告が出ているなら、それも404ではありません。Chromeの「偽のサイトにアクセスしようとしています」が自社サイトに出る場合の確認と解除の手順は、自社サイトに「危険なサイト」の警告が出たときの原因と解除手順に分けて書いています。「メンテナンス中」の表示が戻らないだけならメンテナンスモードが解除されないときの直し方を見てください。

HTTPステータスは自分で測れる

画面に何が書いてあるかと、サーバーが何番を返しているかは別物です。Macのターミナルなら、次の1行でそのURLの実際のステータスが出ます。

curl -o /dev/null -s -w "%{http_code}\n" https://example.com/your-page

この1行が返すのは、画面に何が書いてあるかではなく、サーバーが本当に返した番号です。ブラウザは200でも404でも同じように画面を描いてしまうため、この2つを分けて見ることが切り分けの土台になります。

Windowsでも、ブラウザでF12キーを押して開くデベロッパーツールの「ネットワーク」タブで、そのページの行に出る番号が同じものです。返ってくる番号の意味は3つだけ覚えれば足ります。200=正常に返っている、404=ページが無い、301=別のURLへ恒久的に転送している。この記事の以降の手順は、すべてこの実測値を前提にします。

原因1|リニューアル・URL変更で旧URLを拾えていない

中小企業のサイトで404がまとまって出るとき、最も多いのがこれです。サイトを作り直した、CMSを入れ替えた、ドメインを変えた——そのどれでも、ページのURLは静かに変わります。旧URLはお客様のブックマーク、名刺、他社からのリンク、そしてGoogleのインデックスに残り続けます。

ドメイン単位の301だけでは拾えないURLがある

これはMihata自身が踏んだ話です。mihata.jpは旧ドメイン nishikinomihata.com から移行したサイトで、サイト設定には旧ドメイン全体を新ドメインへ301で送る指定に加えて、記事4本ぶんの恒久リダイレクトを1本ずつ手で書いています。ドメインだけ付け替えれば済むページと、記事の統合などでURLの構造そのものが変わったページがあり、後者はドメイン単位の指定では拾えないからです。

言い換えると、リニューアル後の404が出るかどうかは「旧URL→新URLの対応表を作ったか」でほぼ決まります。対応表を作らずに「旧ドメインは全部トップへ」とまとめて飛ばすと、404は消えたように見えて中身は失われます。Googleも、無関係なページへ一律にリダイレクトすることをソフト404として扱うと説明しています。

この作業を怠っても、リニューアル直後は誰も気づきません。旧URLを踏むのは検索経由の訪問者と、以前このサイトを見た人だけだからです。社内の人間は新しいトップページから入るので、数か月経ってから「問い合わせが減った」という形で表面化します。404の発見が遅れるのは、この構造によるものです。

対応表の作り方と、301を残す期間

Googleはサイト移転のガイドで「元のサイトの URL から新しいサイトの URL へのマッピングは重要な項目です」と述べ、重要URLの洗い出し・CMSの一覧・サーバーログの3つを材料に挙げています。中小企業のサイトなら、旧サイトのサイトマップとアクセス解析の上位100URLを並べれば、実害のある範囲はほぼ覆えます。

リダイレクトの維持期間についても公式に目安があります。「リダイレクトをできるだけ長く保持します(一般的には 1 年以上)」、さらにユーザーの観点からは無期限での保持を検討するように、と書かれています。リニューアル1年後に「もう要らないだろう」と消すのは早すぎます。

なお、リニューアルそのものをこれから検討する段階なら、URLの対応表は見積もり時点で要件に入れておくべき項目です。判断の材料はホームページをリニューアルすべき7つのサインとホームページリニューアルの費用相場と進め方に整理してあります。

原因2|WordPressでトップは出るのに下層だけ404

「トップページは普通に見えるのに、お知らせも会社概要も全部404」という症状は、WordPressの定番の壊れ方です。記事そのものは消えておらず、URLを記事に結びつける仕組みだけが外れている状態なので、たいていは数分で戻ります。

まずパーマリンク設定を開いて「変更を保存」を押す

管理画面の「設定 > パーマリンク」を開き、何も変更せずに「変更を保存」を押します。これだけでURLの書き換えルールが作り直され、多くのケースはここで解消します。サーバーを移転した直後、プラグインを更新した直後、WordPressを別ディレクトリへ移した直後に起きたのであれば、まずこれを試してください。

それでも戻らなければ .htaccess と mod_rewrite

WordPressの公式ドキュメントは、.htaccess を「ディレクトリ単位でApacheの設定を扱う分散設定ファイル」と説明し、WordPressがこのファイルを書き換えることで「きれいなパーマリンク」を実現していると明記しています。つまり、このファイルが無い・書き込めない・書き換えられている、のいずれかなら下層ページは404になります。

確認するのは3点です。サイト直下に .htaccess が存在するか、そのファイルに書き込み権限があるか、サーバー側で mod_rewrite が有効か。権限が無いとWordPressはファイルを作れず、再保存を押しても何も起きません。レンタルサーバーによっては mod_rewrite が既定で無効なこともあるため、ここまで来たらサーバー会社のサポートに「mod_rewrite が有効か」と直接聞くのが最短です。セキュリティ系・キャッシュ系のプラグインが .htaccess を書き換えている場合もあるので、直前に入れた/更新したプラグインを一時的に止めて切り分けます。

原因3|大文字小文字・末尾スラッシュ・全角のURL表記ゆれ

「メールに貼られたURLだけ404になる」「印刷物のURLを打ち込むと出ない」というときは、ページではなくURLの文字列を疑います。人間には同じに見えても、サーバーにとっては別のURLです。

Googleも /APPLE と /apple を別URLとして扱う

Googleは公式ドキュメントで「Google 検索の URL の処理は大文字と小文字を区別する(例: /APPLE と /apple は、それぞれ独自のコンテンツを持つ別々の URL として扱われる)」と明記しています。Linux系のサーバーも同じ挙動なので、社内資料のURLが大文字始まりになっていただけで404、ということが実際に起こります。Googleは、サーバーが大文字小文字を区別しないなら、URLの表記を片方に揃えるよう推奨しています。

末尾スラッシュ・index.html・全角文字

末尾のスラッシュの有無は、サーバーとCMSの設定次第でどちらかが404になります。多くの環境は片方からもう片方へ自動で301しますが、自動化されていない構成では素通しで404になります。自社サイトで「あり」「なし」の両方を実測し、片方が404なら301を足すのが正解です。

もう1つよくあるのが、ワープロソフトやメールソフトが自動変換した全角の記号・全角スペースが混ざったURLです。見た目ではほぼ判別できないので、疑わしいURLはメモ帳など装飾のないエディタに貼り直してから開いてください。

原因4|消したページへのリンクが社内外に残っている

キャンペーンページや採用ページを閉じたあと、フッターやお知らせ本文にリンクが残っているパターンです。ページを消した判断自体は正しく、直すべきなのは404を出している側ではなくリンクしている側になります。

社外からのリンクは消せませんが、それは放置して問題ありません。Googleは、他サイトが間違ったURLを書いたことによる404は修正しなくてよいと説明しています。一方で、自社サイト内から張られているリンク、メールの署名、チラシや名刺に印刷されたURLは直す価値があります。そのURLを踏むのは、自社に興味を持ってくれた人だけだからです。

自社サイト内のリンク切れは、Search Consoleの404一覧から参照元をたどるのが確実です。ページ数が数十程度のサイトなら、更新のたびに「消したページ名」で自社サイト内を検索して、残っているリンクを拾う運用でも十分に回ります。重いツールを入れるより、消すときに一緒に直すほうが早いというのが実務の感覚です。

閉じたはずのページが検索結果に残ってしまい、古い価格や終了したキャンペーンが表示されている場合の消し方は、検索結果に古い情報が出るときの消し方にまとめています。削除ツールによる非表示は約6か月間しか有効でないため、恒久的な対処と組み合わせる必要があります。

原因5|画面は「見つかりません」なのにサーバーは200(ソフト404)

これが最もやっかいな404です。訪問者には「ページが見つかりません」と表示されているのに、サーバーは200=正常を返している状態を、Googleはソフト404と呼びます。エラーとして扱われないので、そのURLはインデックスに残り続け、クロールもされ続けます。Googleは大規模サイト向けのガイドで「soft 404 ページは引き続きクロールされるため、バジェットが無駄になります」と説明しています。

Mihataも業務自動化の中でこれに時間を溶かしました。あるサービスの /mypage が「200を返すのに中身が無い」状態で、ログイン状態を自動判定する処理が「ログインできている」と誤判定し続けたのです。最終的に、判定対象を /dashboard のページタイトルに変えて解消しました。見た目ではなくHTTPステータスで確かめる。この一文を書いた理由は、自分たちが守らずに詰まったからです。

ソフト404が起きやすいのは、JavaScriptで画面を組み立てるタイプのサイトです。Googleの公式ドキュメントは対処として、404ステータスを返すURLへリダイレクトするか、エラーを検知した時点でrobots メタタグを noindex にするかの2つを挙げています。自社で作り込んだ会員ページや検索結果ページがある場合は、ここを制作会社に確認してください。

原因6|直したのに404のまま=キャッシュの世代差

修正を入れて、自分のブラウザで見て、直っていない。あるいは逆に、消したはずのページがまだ表示される。この「時間差」は、配信の途中にあるキャッシュが古い世代を持ち続けているために起きます。

「自分のブラウザで見た」は証拠にならない

mihata.jp はCloudflare Workersから配信しており、静的なファイルには cache-control: s-maxage=31536000(=1年)を付けています。実際にトップページへ curl -sI を打つと x-opennext-cache: HIT が返り、配信側に保存済みの世代が使われていることがその場で確認できます。直した直後に自分のブラウザだけで見ても、見ているのは古い世代かもしれません。

逆の当たり外れもあります。キャッシュの指定を設定ファイル(mihata.jp では public/_headers)に書き忘れたパスは、既定の max-age=0, must-revalidate のまま出てしまい、毎回サーバーへ取りに行く状態になります。キャッシュは「効かせすぎ」と「効いていない」の両方が事故になるので、変更を入れたら実測するのが確実です。

実務上の作法は3つです。時間を置いて見る/スマートフォンの回線など別のネットワークから見る/ブラウザのキャッシュを消してから見る。それでも古いままなら、CDNやキャッシュ系プラグインの側でキャッシュの削除(パージ)が必要です。

Googleが実際に踏んだ404を一覧にする

自分で気づいた404は氷山の一角です。Search Consoleを使えば、Googleが実際に404を踏んだURLの一覧がそのまま取れます。手順はこうです。

  1. Search Consoleで対象のサイトを開き、左メニューの「ページ」(ページ インデックス登録レポート)を選ぶ。
  2. 「ページがインデックスに登録されなかった理由」の中から「見つかりませんでした(404)」の行をクリックする。
  3. 「例」の表に、404を返したURLが最大1,000件まで並ぶ。
  4. 各行の検査アイコンからURL検査ツールを開くと、そのURLがどこからリンクされているか(参照元)も確認できる。

ここで見るべきは件数ではなく中身です。自社サイト内からリンクされている404だけが、直す価値のある404です。他社が間違って書いたURLや、かつて存在して正しく閉じたページは、そのまま404で構いません。同じ画面には「ソフト404」の行もあるので、そちらも合わせて確認してください。

404が並んでいると不安になりますが、検索に出てこない原因が404だとは限りません。インデックス登録そのものが進んでいない、canonicalが別ページを指している、といった別の理由も多く、切り分けはホームページが検索結果に出てこないときの原因と確認手順にまとめています。

自社サイトのどこが404なのか、Search Consoleの画面を開いても判断がつかない、という段階でご相談をいただくことがよくあります。Mihataでは、いま出ている404が直すべきものかどうかの切り分けから、対応表の作成、リダイレクトの実装までを引き受けています。

404のまま残す/301で飛ばす/410で消す の判断基準

404を見つけても、すべてを直すわけではありません。判断は3択で、基準は「そのページの中身が、いまどこかにあるか」です。

規格の定義も確認しておきます。IETFのRFC 9110では、404(Not Found)はサーバーが対象リソースの表現を見つけられないことを示すが、恒久性は示さないとされています。対して410(Gone)は、リソースがもう無く、その状態はおそらく恒久的であることを示します。削除が恒久的かどうかサーバーが判断できない場合は404を使う、とも書かれています。

どうする

こういうとき

Google側の扱い

実務の注意

404のまま残す

もう提供していないサービス、終了したキャンペーン、そもそも存在しなかったURL

インデックスから削除され、クロール頻度が徐々に下がる

他社が間違えて書いたURLは直さなくてよい

301で飛ばす

ページを引っ越した、内容を別ページへ統合した、リニューアルでURLが変わった

転送先が正規のURLとして検索結果に出るようになる

飛ばす先は内容が近いページに限る。トップへの一括転送はソフト404扱い

410で消す

意図して恒久的に削除した。二度と復活させない

中長期では404とほぼ同じ扱い。落ちるのが数日早いことがある

復活の可能性が少しでもあるなら404を使う

410をわざわざ使う場面は多くありません。Googleは404と410を中長期的には同じように扱い、410のほうがわずかに早くインデックスから落ちることがある程度、と説明しています。迷ったら404で構いません。むしろ実害が出るのは3列目、内容の合わない先へ301で飛ばしてしまうパターンです。

判断に迷ったときは、「そのURLを踏んだ人が、本当に読みたかったものは何か」から考えてください。同じ内容が別のURLにあるなら301、もう提供していないなら404。読みたかったものが存在しないのに、それらしいページへ飛ばすのは、訪問者にとっても検索エンジンにとっても親切ではありません。

404ページ自体を作り込む

404が出ること自体は避けられません。避けられるのは、404を見た人がそのまま離脱することです。Googleは検索セントラルのブログで、独自の404ページを用意することを勧め、設計の要点を挙げています。

  • 探していたページが見つからなかったことを、分かりやすい言葉ではっきり伝える。
  • ヘッダー・ナビゲーションを含め、サイトの他のページと同じデザインにする。
  • トップページへのリンクと、よく読まれているページへのリンクを置く。
  • リンク切れを報告してもらう手段を用意することも検討する。

中小企業のサイトなら、ここに問い合わせへの導線とサイト内検索を足すだけで十分です。お問い合わせしようとして404を踏んだ人を、そのまま問い合わせフォームへ送れます。

ただし、ここで絶対にやってはいけないのが「404ページの代わりにトップページを表示する」処理です。Googleのヘルプは、ダミーコンテンツの作成、ホームページへのリダイレクト、robots.txtによる隠蔽を控えるよう明記しています。見た目のエラーは消えますが、ソフト404として扱われ、状況は悪化します。

再発防止に効く3つ

404は一度直せば終わりではなく、ページを更新するたびに生まれ直します。仕組みで止めるなら、次の3つで足ります。

  • URLを変える作業には必ず対応表を付ける。ページを消す・統合する・URLを変えるときは、作業前に旧URLと新URLの2列を書き出す。リニューアルなら発注仕様に入れる。
  • 公開の直後にステータスを実測する。変更したURLに対して、200か301か404かをその場で測る。画面を開いて確認した、で終わらせない。
  • 月1回、Search Consoleの404一覧を見る。見るのは自社サイト内からリンクされているものだけ。5分で済みます。

このうち最も効くのは1つ目です。リニューアル後の404は、技術ではなく段取りで決まります。Mihataが旧ドメインからの移行で記事単位の301を手で書き足しているのも、対応表を作ったから気づけたことで、作らなければ静かに4本のページが失われていました。

制作や運用を外部に任せている場合は、この3つを誰が持つのかを決めておくだけでも変わります。URLを変える判断は自社が、実装と実測は制作側が、月1回の確認はどちらかが——この程度の分担が書いてあれば、リニューアルのたびに同じ事故を繰り返すことはなくなります。

まとめ

整理します。404が出たら、まずHTTPステータスを実測して、サイト全体の停止や警告表示と切り分ける。次に、リニューアル・WordPressのパーマリンク・URL表記ゆれ・リンクの残骸・ソフト404・キャッシュの6つに当てはめる。そして404のまま残す/301で飛ばす/410で消すを、中身がいまどこにあるかで決める。

そして、Googleが「404 エラーはサイトのインデックス登録やランキングに影響を及ぼすことはない」と言っている以上、すべての404を消そうとする必要はありません。直す価値があるのは、自社サイト内からリンクされている404と、お客様に渡した印刷物・メールのURLだけです。

Mihataではホームページ制作を初期費用0円の月額制でご提供しており、サーバー・ドメイン・SSL・保守を含む形で運用をお預かりしています。既存サイトのリニューアルをご検討の場合は、ホームページリニューアルのページに、旧URLの引き継ぎを含めた進め方をまとめています。

いま404が出ているURLと、Search Consoleの「見つかりませんでした(404)」の画面をそのままお送りいただければ、直すべきものかどうかの切り分けからご一緒します。リニューアルの前段階のご相談でも構いません。

よくある質問

404エラーが出ていると、サイト全体の検索順位が下がりますか。

下がりません。GoogleはSearch Consoleのヘルプで、404エラーはサイトのインデックス登録やランキングに影響を及ぼすことはないと明言しています。404になったURL自体はインデックスから削除され、クロール頻度も徐々に下がりますが、それは他のページの評価とは別の話です。直す価値があるのは、自社サイト内からリンクされている404と、名刺やチラシなどお客様に渡したURLの404だけです。

トップページは見えるのに、下層ページだけ全部404になります。

WordPressなら、まず管理画面の「設定 > パーマリンク」を開き、何も変更せずに「変更を保存」を押してください。URLを記事に結びつける書き換えルールが作り直され、多くのケースはこれで戻ります。戻らない場合は、サイト直下の.htaccessが存在するか、書き込み権限があるか、サーバーでmod_rewriteが有効かの3点を確認します。直前に入れたセキュリティ系・キャッシュ系プラグインが.htaccessを書き換えていることもあるので、一時的に止めて切り分けてください。

ソフト404とは何ですか。普通の404と何が違いますか。

訪問者の画面には「ページが見つかりません」と表示されているのに、サーバーは200(正常)を返している状態です。エラーとして扱われないため、そのURLは検索結果に残り続け、クロールもされ続けます。Googleは、ソフト404ページはクロールされ続けるのでクロールバジェットの無駄になると説明しています。見た目では判別できないので、ターミナルでcurl -o /dev/null -s -w \"%{http_code}\" とURLを指定して実測するか、ブラウザのデベロッパーツールのネットワークタブで番号を確認してください。

リニューアルしたら404が大量に出ました。旧ドメイン全体をトップページへ301で飛ばせばよいですか。

やめてください。Googleは、内容の合わない無関係なページへ一律にリダイレクトすることをソフト404として扱います。404の表示は消えても、旧URLに付いていた評価は引き継がれません。必要なのは旧URLと新URLの対応表です。Googleもサイト移転のガイドで、元のURLから新しいURLへのマッピングは重要な項目だと述べています。Mihata自身も旧ドメインからの移行で、ドメイン全体の301に加えて記事4本ぶんの恒久リダイレクトを1本ずつ手で定義しています。

直したはずなのに、まだ404のままです。

配信の途中にあるキャッシュが古い世代を持っている可能性があります。mihata.jpはCloudflare Workersから配信しており、静的ファイルにはs-maxage=31536000(1年)を付けているため、curl -sIを打つとx-opennext-cache: HITが返り、保存済みの世代が使われていることが確認できます。直した直後に自分のブラウザだけで判断せず、時間を置く、スマートフォンの回線など別のネットワークから見る、ブラウザのキャッシュを消す、の3つを試してください。それでも古いままなら、CDNやキャッシュ系プラグイン側でキャッシュの削除が必要です。

まずはお気軽にご相談ください

AI・IT・デザインに関するお悩みやご相談、お見積りのご依頼など、
どんなことでもお気軽にお問い合わせください。

お問い合わせ