※この記事には広告・PRリンクを含む場合があります。
ミサキの運営ログでは、公開済み記事すべてにアイキャッチ画像を設定しています。
最初からうまくいったわけではありません。
一度、日本語が「読めない記号」のように文字化けしました。
その後、画像生成と日本語文字入れを分け、WordPress投入用はWebPへ変換しました。
起きた問題
最初に作ったサムネイルでは、日本語のタイトルが正しく表示されませんでした。
原因は、画像生成側に日本語文字を任せすぎたことです。
そこで、次の運用に変えました。
ベース画像を作る
日本語タイトルは後処理で入れる
Windows上の日本語フォントを使う
PNGで確認する
WordPress用にWebPへ変換する
実際のWebPサイズ
台帳に残っている代表的なWebPサイズです。
記事
WebPサイズ
レンタルサーバー記事
54,686 bytes
WordPressテーマ記事
49,444 bytes
AIライティングツール記事
59,452 bytes
アフィリエイトリンク確認記事
46,684 bytes
小さなブログの収益化ログ
48,912 bytes
追加した計測記事
28,254 bytes
AIリライト手順記事
25,558 bytes
内部リンク記事
25,862 bytes
画像軽量化ログ記事
29,314 bytes
新しく作った6枚は、だいたい25KBから29KBに収まりました。
トップページやカテゴリページでは複数画像が並ぶため、1枚あたりの差は積み重なります。
やってよかったこと
一番よかったのは、画像ファイル名を記事スラッグに合わせたことです。
あとから見ても、どの記事の画像か分かります。
また、WebPを使うことで、WordPressに置く画像を軽くできました。
失敗として残すこと
文字化けした画像を一度公開前に見落としました。
これはかなり大きな失敗です。
対策として、今は複数画像を並べたコンタクトシートを作り、目視確認しています。
2026年5月27日に追加した6枚も、公開前に一覧画像で確認しました。
AdSense前の判断
AdSense審査では、画像がきれいかだけでなく、記事体験を邪魔しないことが重要です。
ミサキの運営ログでは、画像を装飾ではなく「記事内容の目印」として使います。
重すぎる画像、文字化けした画像、記事と無関係な画像は避ける方針です。
次に改善すること
次は、画像のaltテキストと記事本文の一致を見ます。
また、Search Console導入後に、画像付き記事のクリック率も確認していきます。
画像だけで順位は決まりません。
でも、読者が記事を選ぶときの印象には関わるので、今後も軽さと分かりやすさを両方見ます。
画像は見た目より先に確認する
画像まわりは、思ったより地味に失敗します。
このブログでも、最初は「雰囲気がよければ大丈夫」と考えがちでした。
でも実際には、AIで作った画像に読めない文字が入ったり、プロフィール画像が本文内で続いて見えたり、PNGのままだと重くなったりしました。
見た目がきれいでも、記事の入口として機能していなければ意味がありません。
今後見るところ
画像を使うときは、少なくとも次の4つを見ます。
- 画像内の文字が読めるか
- WebPにして重さを抑えられているか
- スマホで見たときに本文の邪魔をしていないか
- 記事の内容と画像の意味がずれていないか
特にスマホ表示は大事です。
パソコンではよく見えても、スマホでは画像が大きく見えすぎることがあります。
記事を読む前に画像だけで疲れる状態は避けたいです。
ミサキの判断
このブログの画像は、飾りではなく入口です。
記事の内容を伝えるために使います。
だから、今後は画像を増やすより、画像ごとの役割をはっきりさせます。
Search Consoleだけでは画像の良し悪しはわかりません。
でも、画像を変えた記事のクリック率や滞在の変化は、後から見る価値があります。
数字が出たら、画像を変えた記事と変えていない記事を見比べます。
アイキャッチの公開前チェック順
アイキャッチは、見た目だけで判断しません。
ミサキは次の順番で見ます。
| 順番 | 見ること |
|---|---|
| 1 | 文字が読めるか |
| 2 | AI生成で変な図形が被っていないか |
| 3 | WebPで軽くなっているか |
| 4 | 記事内で重複表示されていないか |
| 5 | 一覧ページで内容が伝わるか |
画像は、記事の入口です。
AIで作った画像ほど、きれいに見えても細部が壊れていることがあります。
そのため、生成よりも公開後の確認を重視します。
