WordPress画像がぼやける・小さい原因｜サイズと配信画像の確認手順

WordPressに載せた画像だけがぼやけるときは、元の写真を撮り直す前に「選ばれた画像ファイル」と「ページ上の表示幅」を比べます。画像そのものが小さい、表示する枠が小さい、縦横が切れている、圧縮で文字がにじむ、では直す場所が違います。

元画像が十分きれいなら、まず問題の画像1枚で設定を確かめましょう。この記事では、当サイトの公開HTMLと画像ファイルの確認記録を使って、切り分ける順番を説明します。

まず「ぼやける・小さい・切れる」を分ける

画像の症状と、最初に調べる場所
見えている症状 確認すること 最初の対応
ページに載せた画像だけぼやける 公開ページが小さい画像候補を拡大していないか 配信URLとファイル寸法を確認
画質はよいが、画像全体が小さい 画像ブロック、カラム、親の枠の表示幅 画像の幅と外側の枠を確認
上下や左右が欠ける 画像ファイル自体の切り抜きか、ページ上の比率設定か 元ファイルと掲載時の形を比較
元ファイルの文字・細部もにじむ 撮影時のピント、縮小、圧縮、書き出し前の元データ 元データから書き出し直す。撮影時からぼけていれば撮り直す

画像がはみ出す場合はスマホ表示の修正手順、画像が重い場合は画像の軽量化手順へ進みます。ファイル容量だけでは、ぼやける原因を決められません。

公開ページで、実際に使われる画像を確認する

  1. 問題のページと画像を1つ選ぶ。管理画面のプレビューだけでなく、通常の公開ページを開きます。端末・ブラウザ・画面幅・ズームを記録し、比較中は条件をそろえます。
  2. 元ファイルを別に見る。パソコンに残した元写真や書き出し前の画像と、公開画像を区別します。元から読めない文字は、WordPressの表示幅を変えても復元できません。
  3. 公開ページの画像URLを調べる。パソコンのChromeなら開発者ツールのNetworkを開き、Imgで絞ってページを再読み込みします。対象の画像を選び、Request URLとPreviewを確認します。遅延読み込みの画像は、その位置までスクロールしてから探します。
  4. そのファイルの寸法を確かめる。必要なら対象画像を保存し、ファイル情報で横・縦のピクセル数を確認します。ページ上で何pxの幅に表示しているかは、開発者ツールのElementsで対象画像を選び、表示寸法も確認します。

ブラウザキャッシュの影響を分けたいときは、Networkの「Disable cache」を使って比較できます。この設定でサーバー側やCDN側のキャッシュまで消えるわけではありません。Chrome公式：Networkの確認・画像の絞り込み・キャッシュ。

HTMLのsrcだけでは、ブラウザが選ぶファイルを断定できません。WordPressはsrcsetとsizesで複数の候補を出すことがあり、候補の選択はブラウザが行います。WordPress公式：レスポンシブ画像。

開発者向け：currentSrcとnaturalWidthの注意点

currentSrcはブラウザが読み込み用に選択した画像URLです。ただし、その値があるだけでは読み込み成功を証明しないため、Networkの結果も確認します。naturalWidthは密度補正後のCSSピクセルによる幅であり、常に画像ファイル自体の横ピクセル数と一致する値ではありません。ファイル寸法との比較では両者を混同しないようにします。

MDN：currentSrc ／ MDN：naturalWidth。

当サイトの確認記録：同じ画像に5つの候補があった

2026年10月19日、当サイトの画像軽量化記事の公開HTMLを調べ、アイキャッチのsrcsetに並ぶ5ファイルを個別に取得しました。以下は取得したWebPファイルの寸法とバイト数です。

当サイトの同一アイキャッチ画像の候補（2026年10月19日確認）
ファイルの寸法 ファイル容量 取得結果
300 × 158 px 13,068 bytes HTTP 200
768 × 403 px 45,274 bytes HTTP 200
1024 × 538 px 63,932 bytes HTTP 200
1536 × 807 px 104,112 bytes HTTP 200
1731 × 909 px 104,494 bytes HTTP 200

この確認から分かるのは「候補ごとに寸法と容量が違う」ということです。読者の端末がどの候補を選んだか、実際の表示幅、見た目の鮮明さはこの取得だけでは未確認です。大きい元画像がメディアライブラリにあることと、その画像が公開ページで使われていることは別に調べます。

たとえば小さい300px版だけを大きく表示していた場合、さらに圧縮する作業より、まず選ばれているサイズを確かめます。一方、ここで最大の候補を全画像に強制する必要もありません。画面に合う候補と容量を両方見ます。

表示幅600pxに対し、画像は何px必要か

比較の目安は表示する幅（CSS px）× 画面のピクセル密度です。これは必要量を考えるための概算で、合格を保証する数値ではありません。写真の内容、圧縮、拡大率によって見た目は変わります。

計算を説明するための仮定例。上の実測とは別の条件
表示幅 仮定した密度 横ピクセル数の目安
360 CSS px 2 720 px
600 CSS px 1 600 px
600 CSS px 2 1200 px

「スマホだから必ず小さい画像でよい」「本文幅と同じ横ピクセル数なら必ず十分」とは限りません。画面の物理ピクセルとCSSピクセルの比率は端末やページのズームでも変わります。MDN：devicePixelRatio。細かい文字のあるスクリーンショットは、実際に読めるかも確かめます。

WordPressで、問題の画像1枚だけ設定を見直す

  1. 編集前の選択状態を控える。画像の解像度・幅・高さ・縦横比と、掲載ページを記録します。
  2. 画像ブロックの解像度を確認する。「サムネイル」「中」「大」「フルサイズ」などの候補から、表示条件に合うものを試します。名称や候補はWordPressの版・テーマ・元画像によって異なります。
  3. 表示幅も別に確認する。解像度を上げても、ブロックやカラムの幅が狭ければ見た目の大きさは変わりません。まず1か所だけ変えてプレビューします。
  4. 公開後に同じ画像を調べ直す。表示、配信ファイル、容量を比較します。改善しなければ、控えた設定へ戻し、次の原因候補を調べます。

画像ブロックの設定項目はWordPress公式：画像ブロックで確認できます。アイキャッチ・関連記事のサムネイル・背景画像は、本文の画像ブロックとは設定元が異なるため、まず困っている掲載場所を特定してください。

大きい候補が存在しない場合は、元ファイルの寸法や、作られた画像サイズを確認します。すでに小さく書き出した画像をフルサイズで選び直しても、失われた細部は戻りません。元データから用意するか、写真なら撮影時のピント・距離・手ぶれを見直します。

小さい・切れるときは、画像の外側の枠も調べる

画像全体が小さい場合

画像の表示幅、カラム幅、親の枠の最大幅、周囲の余白を順に確認します。画像ファイルを大きくする操作と、画面上の枠を広げる操作は別です。スマホで横にはみ出すほど広げず、画面内に収まるかまで確かめます。

端だけ切れる場合

取得した画像ファイル自体で端が欠けているなら、別の切り抜きサイズや元データを確認します。ファイルでは全部見えるのにページ上で切れるなら、ブロックの縦横比・固定高さ・テーマの表示設定を調べます。

CSSのobject-fit: coverは枠を満たすために一部を切り取る場合があり、containは全体を収める代わりに余白が出る場合があります。どちらが適切かは、その写真で伝える内容から決めます。MDN：object-fit。全画像に同じCSSを追加する前に、問題の掲載箇所を絞りましょう。

変更後は、同じ条件で画質と容量を比較する

  • 必要な文字・商品の細部・入口などが読めるか。
  • PCとスマホで、意図しない切り抜きや横はみ出しがないか。
  • 同じ条件で配信画像を確かめ、必要以上の容量になっていないか。
  • 関連記事など、別の掲載場所を壊していないか。

記録する項目は「ページURL／掲載場所／症状／元ファイルの寸法／配信URLと寸法／表示幅と端末条件／変更した設定／確認結果」です。未測定は未測定と残します。画質の改善と、LCP・検索順位の改善は別々に測ります。

細部は読めるが読み込みが重い場合はWebP・圧縮・配信サイズの軽量化へ、アップロード自体が失敗する場合は画像アップロードエラーの確認へ進んでください。

仕様の確認日：2026年10月19日。リンク先の公式仕様、当サイトのファイル取得結果、計算用の仮定例を分けて記載しています。