そもそもWebフォントが当たらないとは何が起きているのか
Webページの文字は、デザインで指定したフォントが使えないとき、自動的に端末標準のフォント（いわゆるフォールバック）で表示されます。デザイン上は游ゴシックやNoto Sansを当てたつもりでも、肝心のフォントデータが読み込めていなければ、ブラウザはとりあえず手元にあるフォントで文字を出してしまうわけです。これが「表示が崩れていないのに、なぜか雰囲気だけ違う」という見え方の正体です。
ローカルで確認していたときは、たまたまそのフォントがパソコンにインストール済みで正しく見えていた、というケースも少なくありません。公開して別の人の端末で開いた途端に標準フォントへ戻る場合は、まさにこのパターンを疑うとよいでしょう。
つまり問題のほとんどは「指定したフォントファイルにブラウザがたどり着けているか」に行き着きます。原因を当てずっぽうで探すより、読み込みの経路を上から順に確認していくのが近道です。
まず確認したい4つの原因
切り分けは、影響範囲が大きく直しやすいものから順に見ていくと効率的です。次の4点を上から確認してください。
それぞれの具体的な直し方は、続くセクションで掘り下げます。まずは自分のケースがどれに当てはまりそうか、目星をつけてみましょう。
- フォントファイルのパスが公開後の構成とずれていないか
- 読み込み用のタグやCSSの記述が正しいか
- フォント形式（woff2など）がブラウザに対応しているか
- 外部サービス配信のフォントが読み込めているか
症状別チェック表
Webフォントが表示されないは、症状を分けずに直そうとすると原因探しが長引きます。まず「自分だけで起きるのか」「全員で起きるのか」「特定ブラウザだけか」「差し替え後だけか」を切り分けます。
確認順序を固定すると、相対パス、ファイル名、キャッシュ、認証、外部読み込みのどこで止まっているかが見えます。修正後はローカル確認だけで終わらせず、実際の共有URLで再表示して、相手と同じ条件で直ったことを確認します。
- 自分だけ表示されない: キャッシュ、ログイン状態、ブラウザ拡張、端末幅を確認する
- 全員で表示されない: ファイル構成、相対パス、大文字小文字、アップロード漏れを見る
- 一部だけ崩れる: CSS/画像/JSごとに読み込みエラーを分ける
- 差し替え後だけ古い: URL、キャッシュ、更新対象ファイルの取り違えを確認する
パスの崩れと読み込み記述を直す
最も多いのが、フォントファイルへのパスが公開環境とずれているケースです。たとえば「C:/Users/…」のようなパソコン内の絶対パスを書いていると、公開後は当然たどり着けません。フォルダ構成を保ったまま、相対パス（例「./fonts/notosans.woff2」）で指定するのが基本です。
CSSの記述側も合わせて確認します。@font-faceで宣言したフォント名と、実際にbodyなどへ指定したfont-familyの名前が一字でも食い違っていると当たりません。外部サービスのフォントを使う場合は、headに読み込み用のlinkタグを入れ忘れていないか、あるいはCSS側のimport記述が抜けていないかを見直します。
ZIPでまとめて公開するなら、HTMLとfontsフォルダの位置関係をローカルと同じに保つことが大切です。圧縮時に余計な親フォルダが一段入ってしまうと、相対パスが全部ずれて一斉に読み込み不良が起きます。
形式・キャッシュ・差し替え後の注意点
記述が正しくてもフォントが出ないときは、ファイル形式を疑います。現在の主流はwoff2で、軽くて対応も広いため第一候補になります。古い形式しか用意していない、あるいは拡張子とCSSのformat指定が食い違っていると、ブラウザが読み込みを諦めてしまうことがあります。
意外な盲点がキャッシュです。一度フォントなしで表示されたページは、ブラウザが古い状態を覚えていることがあります。修正後に直ったか確かめるときは、スーパーリロード（強制再読み込み）やシークレットウィンドウで開き直して、まっさらな状態で見てください。
同じURLのままファイルを差し替えられる仕組みを使っている場合も同様で、差し替え直後は古いキャッシュが残ることがあります。閲覧者に「うまく表示されない」と言われたら、まずキャッシュを消した状態で再確認してもらうと切り分けが進みます。
ギガサイト便で表示を確かめる手順
フォントの修正が効いているかは、実際に公開環境に近い形で開いてみるのが確実です。ギガサイト便はAIなどで作ったHTMLやZIPを認証付きの共有URLとして公開できるサービスで、サーバー構築やデプロイ設定なしに本番に近い表示を試せます。次の手順で確認してみてください。
- フォントファイルを含めたZIP（HTML/CSS/JS/画像一式）を用意する
- トップページにZIPをドロップして共有URLを発行する
- 発行されたURLをスーパーリロードで開き、文字のデザインを確認する
- 崩れていたら、同じURLのままファイルを差し替えて再公開する
- 差し替え後はキャッシュを消した状態で再度開いて確認する
公開前にできる事前チェック
公開してから慌てないために、アップロード段階で気づける仕組みも活用しましょう。ギガサイト便ではアップロード時にセキュリティスキャンが走り、外部スクリプト依存や静的公開に不要なファイルなどの兆候を検出して警告します。フォントを外部サービスから読み込んでいる構成も、こうした警告から気づけることがあります。
なお、公開されるHTMLは静的に配信される点に注意してください。サーバー側で動的にフォントを差し込むような処理は動きません。フォントは必ずファイルとして同梱するか、外部配信を確実に読み込める形で指定しておくのが安全です。
事前に共有URLで一度開いて確認しておけば、相手に送る前に表示崩れをつぶせます。リンクを送り直さずに直せる差し替えの仕組みと合わせて使えば、修正のたびに新しいURLを配り直す手間も避けられます。
よくある質問
ローカルでは表示されるのに公開するとWebフォントが当たらないのはなぜ？
手元のパソコンにそのフォントがインストール済みで、たまたま正しく見えていた可能性があります。公開後は別端末でも読み込めるよう、フォントファイルを同梱し相対パスで指定してください。パスがずれていると標準フォントに戻ります。
フォントを修正したのに表示が変わりません。どうすればいい？
ブラウザが古い表示をキャッシュしていることがあります。スーパーリロード（強制再読み込み）やシークレットウィンドウで開き直し、まっさらな状態で確認してください。同じURLで差し替えた直後も同様の確認が有効です。
Webフォントの形式はどれを用意すればいい？
現在の主流はwoff2で、軽くて対応範囲も広いため第一候補になります。拡張子とCSSのformat指定が食い違っていると読み込みに失敗するため、記述と実ファイルを揃えておくことが大切です。
ZIPで公開するとフォントだけ読み込まれないのはなぜ？
圧縮時に余計な親フォルダが一段入り、HTMLとfontsフォルダの位置関係がずれていることが多いです。ローカルと同じ構成のままZIP化し、相対パスが崩れないようにしてください。
原因が分からないときはどこから確認すべきですか？
まず自分だけの問題か全員の問題かを分けます。次にシークレットウィンドウ、別ブラウザ、スマホで確認し、ファイル構成・相対パス・キャッシュ・認証設定を順に見ます。