自分だけサイトが表示されない原因6つと切り分け方

他の人は普通に見られるのに、自分のパソコンだけ会社のサイトが開かない。社内の数人からだけ「表示されません」と連絡が来る。自分のスマホでは出るのに、社内のWi-Fiにつなぐと出ない。

この記事は、その「いま起きている見え方の食い違い」を順番どおりに潰していく手順だけを書きます。SEOの一般論ではなく、何を見て、どこで切り分け、どこから先は自分では直せないのかに絞ります。

実際に手を動かすのは最初の5分です。そこで原因がほぼ半分に絞れます。

結論

自分だけサイトが表示されない原因は、大きく回線・キャッシュ・端末側の遮断の3グループに収まります。細かく分けると6つですが、最初にやることは1つだけです。

回線を変えてください。社内Wi-Fiにつないでいるパソコンを、スマートフォンのテザリングなど別の回線に切り替えて同じURLを開きます。ここで見えるならネットワーク側（社内のDNS・フィルタ・プロキシ）、見えないならサイト側か自分の端末側です。この1手で6つの原因のうち半分が消えます。

もう1つ、最初に切っておきたい区別があります。「サイトが表示されない」と「検索結果に出てこない」はまったく別の問題です。ブラウザにURLを入れて開けるなら、表示の問題ではありません。

「表示されない」と「検索に出てこない」を先に分ける

相談を受けたとき、最初に確認するのはここです。URLを直接入力して開けるかどうかで、話がまったく別の方向へ分かれます。

URLを入れれば開くのに検索結果に自社が出てこない、という状態はインデックスの問題です。表示の切り分けをいくら進めても何も出てこないので、ホームページが検索に出てこない時の切り分けのほうを読んでください。noindexやrobots.txtの話はそちらの領域です。

逆に、誰がどこから開いてもエラーになる場合は「一部の人だけ」ではありません。ドメインの有効期限切れやサーバー障害など、サイト全体が落ちている可能性が高いので、サイトが突然見られなくなったときに最初に疑うことの手順に移ります。

この記事が扱うのは、その中間です。ある人には見えて、ある人には見えない。あるいは、見えてはいるが自分だけ内容が古い。ここからが本題です。

誰に見えていないかで原因は決まる

「見えない」と言われたら、まず範囲を確定します。自分だけなのか、社内だけなのか、社外からもなのか。範囲が決まれば、原因の候補は数個に絞れます。

「スマートフォンだけ見え方がおかしい」は、表示されないのではなくレイアウトが壊れているだけ、というケースが実務では相当な割合を占めます。文字が重なる・横にはみ出すといった症状ならスマホだけレイアウトが崩れるときの直し方のほうが近いはずです。

切り分けの順番と、それぞれで分かること

順番には意味があります。安く速く、対象範囲の広いものから潰していくと、途中で原因が確定して残りをやらずに済みます。上から順にどうぞ。

最初の一手が「回線を変える」である理由

社内ネットワークには、たいていフィルタリング機器かプロキシか、管理者が指定したDNSサーバーが挟まっています。これらは端末の設定をいくら見ても表からは分かりません。回線を丸ごと変えると、その層を1回でまたげます。

テザリングで見えた場合、直すべきなのは自社サイトではなく社内のネットワーク設定です。サイト側をいくら触っても症状は消えません。逆にテザリングでも見えないなら、社内ネットワークは無実で、端末かサイトの問題に絞り込めます。

シークレットウィンドウと別ブラウザで分かること

シークレットウィンドウは拡張機能とCookieの影響を外した状態に近づきます。ここで正常に見えるなら、広告ブロッカーやセキュリティ系の拡張機能、あるいは古いCookieが犯人です。

別のブラウザでも試すのは、証明書の警告やブラウザ固有の設定を切り分けるためです。1つのブラウザだけで「保護されていない通信」と出ている場合は、そのブラウザが持っている証明書の扱いの問題であることがあります。証明書そのものが切れている場合の対処は「保護されていない通信」と出るときの直し方にまとめています。

原因1: ブラウザとDNSのキャッシュが古い

画面としては「このサイトにアクセスできません」「DNS_PROBE_FINISHED_NXDOMAIN」のようなエラーになるか、ページは出るのに内容が数日前のまま、という形で現れます。他の人は正常で自分だけ、という典型例です。

サーバーを移転した直後に多く起こります。名前解決の結果は端末側に一定時間残るためです。DNSのレコードにはTTL（Time To Live）という値があり、JPRSの用語辞典では「リソースレコードをキャッシュに保持してもよい時間を秒単位で示す」ものと定義されています。つまり古い情報が残る時間はTTL次第で、「何時間で切り替わる」と一律に言えるものではありません。

ブラウザのキャッシュは、Chromeなら閲覧データの削除から「キャッシュされた画像とファイル」を消します。OS側のDNSキャッシュは、Windowsならipconfigの ipconfig /flushdns で消せます。Microsoftのリファレンスにも「DNS名前解決の問題のトラブルシューティング時にDNSリゾルバーキャッシュをフラッシュする」用途として明記されています。macOSはAppleのサポート記事にあるとおり sudo killall -HUP mDNSResponder です。

原因2: 社内フィルタ・プロキシ・セキュリティソフトが弾いている

画面には「アクセスがブロックされました」という管理者向けの独自ページが出るか、あるいは何も出ずに延々と読み込み続けます。社内の一部の部署だけ、学校の端末だけ、といった偏った出方をするのが特徴です。

フィルタリングはホスト名（ドメイン名）単位で効くことが多く、カテゴリ分類のデータベースに載っていない新しいドメインは、内容にかかわらず「不明なサイト」として止められることがあります。開設したばかりのドメインや、社名とは関係のない文字列のドメインで起こりやすい現象です。

この層はサイト運営者側からは手が出せません。直すのは相手の情報システム部門であり、こちらができるのは「うちのドメインが遮断されているようです」と伝えられる材料を用意することだけです。だからこそ、どの範囲の人が見られないのかを先に確定しておく意味があります。

「サイトは開くのに一部の部品だけ落ちる」が最大のヒント

ここがこの記事でいちばん伝えたいところです。端末側フィルタが原因のとき、症状はページ全体が落ちるとは限りません。ページ本体は問題なく表示されているのに、画像だけ出ない、動画だけ再生されない、音だけ鳴らない、という形で出ます。

理由は単純で、最近のサイトは1ページの中で複数のホスト名から部品を取ってくるからです。本体は example.com、画像は img.example.com、動画配信は別サービスのドメイン、という構成はごく普通です。フィルタが特定のホスト名だけを弾けば、そのホストから来る部品だけが欠けます。

この症状は、運営側の環境ではほぼ確実に再現できません。社内で何度開いても正常なので「勘違いでは」と処理されがちですが、実際にはユーザーの環境で確かに起きています。再現しないことを理由に閉じないでください。

Mihataの集中時計で実際に起きたこと

自社での実例を書きます。Mihataが提供している集中時計は、音源のmp3と背景動画のmp4という大きなファイルを配信しています。サーバーを移した際、これらを media.mihata.jp という別のホスト名から配る構成にした時期がありました。

その結果起きたのが、「サイトは普通に開くのに音だけ鳴らない」という報告です。2026年8月、学校で使われているiPadからこの症状が上がってきました。SafariでもChromeでも鳴らない、他サイトの音は鳴る、という内容でした。社内のどの端末でも再現できませんでした。

原因は、フィルタリングDNSやセキュリティ製品が media.mihata.jp を「知らないサブドメイン」として遮断していたことです。サイト本体のホスト名は許可されているので、ページは何事もなく表示されます。落ちるのは別ホストから取りにいく音源だけでした。

2026年8月30日に、メディアをサイト本体と同じホスト名から配る構成へ戻して解消しました。分けた理由だったファイルサイズの制限も、実際に全48ファイルを測り直したところ超過していたのは1本だけで、その1本を軽く作り直せば足りました。配信を別ホストに分けるかどうかは、性能の話であると同時に「届くかどうか」の話でもあるというのが、この件で残った教訓です。

原因3: hostsファイルと端末に残った古い設定

症状は原因1とよく似ていますが、こちらはキャッシュを消しても消えても直りません。何日経っても自分だけ古いサーバーを見続ける、という形になります。

サイト制作時に、公開前の確認用としてhostsファイルへ手動でIPアドレスを書き込むことがあります。この記述は消さない限り永久に効き続け、本番公開後もその端末だけ旧サーバーを見にいきます。制作会社の担当者や、リニューアルに関わった社内の人の端末だけで症状が出ているなら、ここを疑う価値が高いです。

Windowsでは ipconfig /displaydns でDNSクライアントリゾルバーキャッシュの中身を表示できます。Microsoftのリファレンスによれば、この表示には「ローカルHostsファイルからプリロードされたエントリ」も含まれます。意図しないIPアドレスが出てきたら、その端末固有の設定が残っている証拠です。

プロキシの手動設定、VPNの接続、社内向けの独自DNSサーバー指定も同じ種類の原因です。いずれも「その端末にだけ書いてある設定」なので、他の人には再現しません。

原因4: CDN・サーバーのキャッシュで人によって見え方が違う

「直したのに自分には古いまま見える」「自分には新しく見えるのに、お客様からは古いと言われる」。これは故障ではなく、配信経路のどこかに残ったキャッシュを見ているだけであることがほとんどです。

いまのサイトは、閲覧者とサーバーの間にCDNが挟まっているのが普通です。CDNは地域ごとに分かれた拠点でコンテンツを保持するため、どの拠点につながったかで見えるものが変わります。東京の人には新しく、大阪の人には古い、という状態は原理的に起こりえます。

Cloudflareの場合、公式ドキュメントにあるとおり、レスポンスの cf-cache-status ヘッダーで状態が分かります。HIT はキャッシュから返した、MISS はキャッシュ対象だが無かったのでオリジンから返した、EXPIRED はキャッシュにあったが期限切れだった、という意味です。

なお、既定のキャッシュ動作のドキュメントには「CloudflareはMIMEタイプではなく拡張子でキャッシュを判断し、HTMLとJSONは既定ではキャッシュしない」と書かれています。つまり何も設定していなければHTMLは毎回サーバーまで取りに行くので、「ページの文言を直したのに古いまま」はCDNではなくブラウザ側のキャッシュ、という切り分けもできます。

curl でレスポンスヘッダーを見るのが最短

ブラウザの開発者ツールでも見られますが、端末の設定に影響されない確認としては、ターミナルから次の1行が最短です。

curl -sI https://example.com/

返ってくるのはHTMLではなくヘッダーだけです。ここで見るのは3つ。ステータス行（200なのか、404や503なのか）、cache-control（どれだけの時間キャッシュしてよいと宣言しているか）、そしてCDNのキャッシュ状態を示すヘッダーです。

実例として、この記事を書いている環境で mihata.jp の記事ページに対して同じコマンドを打つと、cache-control: s-maxage=31536000 と x-opennext-cache: HIT が返ってきます。前者は「配信側で最大1年キャッシュしてよい」という宣言、後者は「今回はキャッシュから返した」という記録です。この状態のページは、内容を直しても自動では切り替わりません。明示的にキャッシュを消すか、再ビルドして新しい内容を置き直す必要があります。

「人によって見え方が違う」と言われたとき、まずこのヘッダーを見れば、サイトの不具合なのか単にキャッシュの世代差なのかが1分で分かります。想像で議論するより速いです。

自分だけ新しく見えてしまう落とし穴

更新作業をした本人は、直前にサーバーへアクセスしているぶん新しい内容を持っていることが多く、「直った」と判断しがちです。ところが同じ瞬間、別の地域・別の回線から来た人はまだ古い版を見ています。

公開後の確認は、更新した本人のブラウザではなく、シークレットウィンドウか、できれば別の回線から行ってください。本人の画面で正常なことは、公開できている証明にはなりません。

ここまでの話は、確認方法さえ分かれば自分で進められる範囲です。Mihataではホームページの制作と、公開後の配信まわりの設定もあわせてお引き受けしています。記事の途中で恐縮ですが、社内に見られる人がいない、毎回制作会社に聞くしかない、という状態でしたら、よろしければ合わせてご覧いただけたら嬉しいです。

原因5: 回線側のDNS障害・ISP側の不調

特定のプロバイダの利用者だけが見られない、あるいは特定の地域からだけ開けない、という出方をします。本人からすれば「自分だけ見られない」ですが、実際には同じプロバイダを使う大勢が同じ状態です。

確認方法は、端末のDNS設定を公共のDNSサービスへ一時的に変更して開き直すことです。これで見えるなら、契約しているプロバイダのDNSサーバー側に問題があります。サイト側の作業では解決できないので、復旧を待つか、利用者にその旨を案内する対応になります。

ドメインの設定を変更した直後であれば、切り替わりの途中である可能性もあります。前述のとおり反映速度はTTLに依存するため、「何時間で伝わる」とは断定できません。設定変更の予定があるなら、変更の数日前にTTLを短くしておくのが実務的な準備です。

同じドメインを使うメールが届かなくなっている場合は、DNSの設定そのものを間違えている可能性が高まります。その切り分けは独自ドメインのメールが届かないときの確認手順に分けて書きました。

原因6: サイト側が落ちている、または一部だけ落ちている

全員に見えていないのに「自分だけ」と思い込んでしまうこともあります。社内の誰も外から確認していないだけ、というパターンです。7番目の手順で社外の人に開いてもらうのは、この思い込みを外すためです。

サーバーが一時的に応答できない状態では、500・502・503などのステータスコードが返ります。Googleはこれらの扱いについて、HTTPステータスコードのドキュメントで「クローラに対して一時的にクロールのペースを落とすように促します」と説明し、すでにインデックスに登録されているURLも「最終的には削除されます」としています。短時間なら影響は限定的ですが、長引かせてよいものではありません。

更新作業のためにメンテナンスモードへ入れたまま戻し忘れている、というケースも実際にあります。管理者としてログインしている人には普通に見えて、ログインしていない人には工事中の画面が出るため、まさに「自分だけ見える」状態になります。戻し方はメンテナンスモードから戻らないときの対処にまとめています。

逆パターン: 自分だけ見えて、他の人に見えない

相談としては、こちらのほうが厄介です。作った本人には完璧に見えているので、問題が起きていることに気づくまでに時間がかかります。

公開設定・Basic認証・管理者ログイン

最も多いのが、公開前の確認用に掛けたアクセス制限を外し忘れているパターンです。IDとパスワードを求める認証が掛かっていると、訪問者には認証ダイアログか、権限がない旨の画面が出ます。制作時にブラウザへ認証情報を保存した本人だけが、何の障害もなく素通りできます。

CMSの下書き状態も同じ構図です。管理画面にログインしている人にはプレビューが見えますが、一般の訪問者には存在しないページとして404が返ります。「ページを作ったのに誰も見られない」というときは、まずログアウトした状態か、シークレットウィンドウで開いて確かめてください。

Googleも、クロール頻度を抑える目的で401・403を使わないよう公式ドキュメントで案内しています。アクセス制限は「公開前に掛けて、公開時に外すもの」であって、運用中に掛けっぱなしにしてよいものではありません。

noindexは「表示されない」ではない

ここは混同されがちなので分けて書きます。noindexは検索結果に出さないための指定であり、URLを直接開けば誰でも普通に表示されます。だから「見られない」の原因にはなりません。

Googleのnoindexのドキュメントは、Googlebotがタグやヘッダーを検出すると、他サイトからリンクされているかどうかに関係なくそのページを検索結果から削除する、と説明しています。あわせて重要な注意として、noindexを有効にするにはrobots.txtでページをブロックせず、クローラがページにアクセスできる状態にしておく必要がある、とも明記されています。

robots.txtでブロックすればページを隠せる、というのも誤解です。robots.txtの概要が説明しているとおり、robots.txtはクロールを制御するための仕組みであって、アクセスを禁止するものでも、検索結果から確実に消すものでもありません。人に見せたくないなら認証を掛けるのが筋です。

そもそも誰が管理しているか分からない場合

認証を外したくても管理画面に入れない、サーバーの契約先が分からない、前任者も制作会社も連絡が取れない。この状態だと、原因が特定できても手が出せません。

契約情報の辿り方はドメインとサーバーの管理者が分からないときの調べ方に手順としてまとめてあります。表示トラブルが起きてから慌てて探すことになりがちな情報なので、平時に一度たどっておくことをお勧めします。

今日やる順番

最後に、この記事の内容を実行順に畳みます。上から順に、該当した時点で止めてください。全部やる必要はありません。

1. URLを直接入力して開けるかを確認する（開けるなら検索の問題であって表示の問題ではない）
2. 誰に見えていないかを確定する（自分だけ／社内だけ／全員）
3. 回線をスマートフォンのテザリングに変えて同じURLを開く
4. シークレットウィンドウ、次に別のブラウザで開く
5. ページ全体が落ちているのか、画像・動画・音など一部の部品だけかを見る
6. OSのDNSキャッシュを消す（Windowsは ipconfig /flushdns、macOSは sudo killall -HUP mDNSResponder）
7. curl -sI でステータスとキャッシュ関連のヘッダーを確認する
8. 社外の人に開いてもらい、全員か一部かを最終確認する

3番で見えたらネットワーク管理者へ、5番で一部の部品だけ落ちていたら配信元のホスト名を疑い、7番でキャッシュのヒットが確認できたらキャッシュを消す。ここまで来れば、少なくとも「誰に相談すればいいか」は確定します。

切り分けの途中で止まってしまった、社内に確認できる人がいない、という場合は、いま出ている画面と手順のどこまで進んだかをお知らせいただければ、続きをご案内できます。無理にお勧めはしませんので、困っている部分だけでもお聞かせいただければ嬉しいです。