※この記事には広告・PRリンクを含む場合があります。
ミサキの運営ログでは、記事のアイキャッチ画像をWebP中心にしました。
理由は、PNGのままだと重くなりやすいからです。
もうひとつの理由は、画像生成後の確認作業を固定したかったからです。
WebP化する前の問題
最初はPNG画像を使っていました。
PNGはきれいですが、サムネイル用途ではファイルサイズが大きくなりやすいです。
ブログはスマホで読まれることが多いため、表示が重くなるのは避けたいです。
そこで、アイキャッチはWebPを標準にしました。
確認した項目
確認項目
このブログでの見方
表示
記事一覧と本文で崩れず表示されるか
重さ
PNGより軽くできるか
文字
日本語が読めるか
重複
本文冒頭で画像が2枚続かないか
内容
記事テーマと合っているか
実際に失敗したこと
AI画像で日本語を長く入れたとき、文字が崩れました。
画像の中では読めない文字になり、記事の品質も低く見えます。
そのため、画像内の日本語は短くするか、入れない方針にしました。
タイトルや説明は本文側で伝えます。
WebP化だけでは足りない
WebPにすれば必ず良いわけではありません。
軽くなっても、画像が記事内容と合っていなければ意味がありません。
また、アイキャッチと本文内画像が連続すると、スマホで見たときに邪魔になります。
そのため、画像は作成後に公開ページで確認していきます。
このブログでの結論
アイキャッチ画像はWebPを基本にします。
ただし、軽さだけで採用しません。
読めること、内容に合うこと、表示が重ならないこと。
この3つを確認してから使います。
追加検証メモ
WebP化は、表示速度だけでなく運用ルール作りにもつながりました。今後は画像を作ったら、ファイル形式、表示、文字、本文内の重複、記事内容との一致を確認していきます。画像を増やすより、読者が迷わず本文に入れる状態を先に扱います。
申請前の追記
画像運用は、今後も記事公開前チェックに入れます。ファイル形式、表示崩れ、文字の読みやすさ、本文との重複、スマホ表示を確認していきます。特にAI画像は雰囲気が良くても、細部に違和感が出やすいです。画像を増やすより、記事本文へ自然に入れることを先に扱います。
画像は見た目より先に確認する
画像まわりは、思ったより地味に失敗します。
このブログでも、最初は「雰囲気がよければ大丈夫」と考えがちでした。
でも実際には、AIで作った画像に読めない文字が入ったり、プロフィール画像が本文内で続いて見えたり、PNGのままだと重くなったりしました。
見た目がきれいでも、記事の入口として機能していなければ意味がありません。
今後見るところ
画像を使うときは、少なくとも次の4つを見ます。
- 画像内の文字が読めるか
- WebPにして重さを抑えられているか
- スマホで見たときに本文の邪魔をしていないか
- 記事の内容と画像の意味がずれていないか
特にスマホ表示は大事です。
パソコンではよく見えても、スマホでは画像が大きく見えすぎることがあります。
記事を読む前に画像だけで疲れる状態は避けたいです。
ミサキの判断
このブログの画像は、飾りではなく入口です。
記事の内容を伝えるために使います。
だから、今後は画像を増やすより、画像ごとの役割をはっきりさせます。
Search Consoleだけでは画像の良し悪しはわかりません。
でも、画像を変えた記事のクリック率や滞在の変化は、後から見る価値があります。
数字が出たら、画像を変えた記事と変えていない記事を見比べます。
画像を軽くしたあとに見ること
WebP化は、ファイルを軽くするだけでは終わりません。
このブログでは、画像を反映したあとに次の順番で確認します。
| 確認項目 | 理由 |
|---|---|
| 公開URLで開けるか | 404画像になっていないか見る |
| 文字が崩れていないか | サムネイルの印象が壊れるため |
| 記事内で連続表示されていないか | 画像が2枚並ぶと読みにくい |
| スマホ幅で見切れないか | noteやブログ読者はスマホが多いため |
| 代替テキストが自然か | 画像だけで意味が伝わらない場合に備える |
AI画像は、作って終わると危ないです。
文字化けや余計な図形は、生成時より公開後に気づくことがあります。
だから画像も、本文と同じように検査対象として扱います。
