Chrome 155のベータにJPEG XLの表示が入ったが、「入った」と「自社で足す」は別の判断 ── 配信している画像の形式を確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — Chrome 155のベータにJPEG XLの表示が入ったが、「入った」ことと「自社で使える」ことは別である
   1. ベータの紹介記事に、JPEG XLの項目が載った
   2. 日付を並べると、安定版は2026年10月6日の予定になっていた（10月5日時点）
   3. わからないことが、3つある
2. 02 なぜ・背景 — 画像の形式は、ブラウザではなく、配信する側が選んでいる
   1. ブラウザが対応しても、サイトの画像は自動では変わらない
   2. 形式を足したとき、確認が増える場所は3つある
   3. MDNは、JPEG XLを足すときの作法を書いている
   4. 数字で見ると、確認の意味が分かる
3. 03 この記事で出てくる用語
   1. JPEG XLとimage/jxl
   2. Acceptヘッダー
   3. picture要素とtype属性
   4. Varyヘッダー
   5. フォールバック
4. 04 型別 — 適用範囲・この記事が確かめていないこと・手順
   1. 適用範囲 — この確認が向いているサイト
   2. この記事が確かめていないこと
   3. 手順の流れは、4つに分かれる
   4. 数える前に、ページを3つに絞る
5. 05 明日、自社サイトで確認できることチェックリスト
   1. まず13項目を通して見る
   2. 観点別の内訳と、かかる時間
   3. 5分で終わらない項目があったとき
   4. 表に書く欄は、7つで足りる
6. 06 代替・他の選択肢（表で）
   1. 画像の形式を、どうするかの4つの選び方
   2. WebP・AVIF・JPEG XLを、文書の記載で並べる
   3. Googleの一覧に載っていない形式を、足すとき
   4. picture要素の書き方の例
   5. 自動変換に任せるときに、確かめること
   6. 「足さない」ことも、記録する判断である
7. 07 当サイトで内訳と応答を確かめてみた例
   1. 数えた範囲と方法
   2. 画像ファイルは、PNGとJPEGが全部だった
   3. ページのHTMLと、Acceptへの応答
   4. この例の限界
8. 08 このテーマの、これまで
   1. 画像の形式と、画像SEOの過去の記事
   2. 見た目と実際を分けて確かめた記事
9. 09 この記事のまとめ

01 何が起きたか — Chrome 155のベータにJPEG XLの表示が入ったが、「入った」ことと「自社で使える」ことは別である

ベータの紹介記事に、JPEG XLの項目が載った

Chrome for Developersのブログに、Chrome 155のベータ版を紹介する記事がある。記事の日付は2026年9月16日で、本文に次の一文がある。

"Chrome 155 is in beta as of September 16, 2026."

（訳: Chrome 155は、2026年9月16日の時点でベータ版である。）

この記事の中に、JPEG XLの項目がある。項目の最初の文は、次のとおりである。

"Adds support for decoding JPEG XL (image/jxl) images in Blink using jxl-rs, a memory-safe pure Rust decoder."

（訳: メモリ安全な、純粋なRust製のデコーダー「jxl-rs」を使って、Blink（Chromeの描画の仕組み）でJPEG XL（image/jxl）の画像を復号する対応を加える。）

項目は、続けて、JPEG XLの特長を挙げている。読み込み中の見た目を良くする段階的な復号、広い色域、HDR、高いビット深度、アニメーションである。ここは英文の言い換えであり、引用ではない。画像を配信する側にとっての要点は、ブラウザが、image/jxlの画像を表示できるようになる、ということである。

日付を並べると、安定版は2026年10月6日の予定になっていた（10月5日時点）

Chromeの公開予定を載せたChromium Dashの予定表を、2026年10月5日に取得した。Chrome 155の欄には、ベータの最初の日が2026年9月16日、安定版の日（stable_date）が2026年10月6日と書かれていた。つまり、この記事を書いた2026年10月5日は、予定どおりなら、安定版の前日だった。

2026年10月6日の更新: Chromeの公式リリースブログ「Stable Channel Update for Desktop」（2026年10月6日付）に、"The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming days/weeks."（訳: 安定版チャンネルは、Windowsとmac向けが155.0.8059.39/.40、Linux向けが155.0.8059.39に更新され、今後の数日から数週間かけて順次配信される）と書かれた。予定日どおりに、安定版の更新が告知されたことになる。ただし、この告知はJPEG XLの既定の状態に触れていないので、下の「確かめていないこと」は、この更新のあとも変わらない。

ただし、これは予定表の日付であって、「その日にJPEG XLが既定で使える」という意味ではない。次の項で、わからないことを分ける。

わからないことが、3つある

1つ目は、既定で有効になるかどうかである。ベータの紹介記事の項目は、既定で有効かどうかを書いていない。MDN（Mozillaの開発者向け文書）は、画像の形式の解説で、次のように書いている。

"Chrome 145 and later supports JPEG XL behind the #enable-jxl-image-format flag."

（訳: Chrome 145以降は、「#enable-jxl-image-format」というフラグの裏で、JPEG XLに対応している。）

「フラグの裏」とは、利用者が設定画面で手動で有効にしたときだけ動く状態のことである。155のベータで、この状態がどう変わるかは、紹介記事からは読み取れなかった。2つ目は、ベータの項目が、安定版にそのまま入るかどうかである。この記事は確かめていない。3つ目は、Chrome以外のブラウザと、検索エンジンの扱いである。MDNは、Safari 17以降が対応していて、Firefoxは先行版で対応していると書いているが、この記事は自分では試していない。Googleの検索の文書は、02章で見るように、JPEG XLを挙げていない。

確かめられたのは、「ベータの紹介記事に載った」「安定版の予定日は2026年10月6日」の2点までである（記事を書いた10月5日時点）。この記事は、「Chromeで使えるようになった」とは書かない。

02 なぜ・背景 — 画像の形式は、ブラウザではなく、配信する側が選んでいる

ブラウザが対応しても、サイトの画像は自動では変わらない

ブラウザが新しい形式を表示できるようになっても、サイトに置かれた画像が、ひとりでに新しい形式になるわけではない。画像は、置いた人が選んだ形式のまま、利用者に届く。形式を変える方法は、大きく3つある。1つ目は、自分で変換したファイルを置く方法。2つ目は、CMS（サイトの管理システム）のプラグインや機能に、変換を任せる方法。3つ目は、CDN（画像などを、利用者の近くから配信するサービス）の自動変換に任せる方法である。

どの方法を使っているかで、確認する場所が変わる。自分で置いているなら、ファイルの形式を数える。CMSやCDNに任せているなら、その設定が、どの形式まで出せるかを確かめる。自社がどの方法を使っているかがわからないままでは、新しい形式を足すかどうかを決められない。

形式を足したとき、確認が増える場所は3つある

画像の形式を足すと、確認が増える場所は、3つである。1つ目は、ページのHTMLである。画像を、picture要素と、その中のsource要素で書き分けるなら、それぞれの書き方を確かめる。2つ目は、画像のURLへの応答である。同じURLに、要求の条件によって別の形式を返す仕組みなら、返す形式と、キャッシュの扱いを確かめる。3つ目は、検索エンジンである。Googleの画像の文書が、どの形式を挙げているかを確かめる。

MDNは、JPEG XLを足すときの作法を書いている

MDNの画像形式の解説は、JPEG XLの項で、次のように書いている。2026年10月5日に開いた版である。

"When using JPEG XL, provide an alternative format such as AVIF, WebP, or JPEG with the <picture> element."

（訳: JPEG XLを使うときは、picture要素で、AVIF、WebP、JPEGなどの代わりの形式も用意してください。）

"Browser support is not yet universal."

（訳: ブラウザの対応は、まだ、すべてには広がっていない。）

この2文は、この記事の考え方と合っている。新しい形式を足すなら、今の形式は、残す。足さないなら、足さない理由を残す。

数字で見ると、確認の意味が分かる

2026年10月5日に、2つの文書で、形式の一覧を数えた。Googleの検索の画像の文書は、img要素のsrcで参照された画像について、対応する形式を7つ挙げている（BMP、GIF、JPEG、PNG、WebP、SVG、AVIF）。7つの中に、JPEG XLは入っていなかった。CDNの1つ、Cloudflareの画像変換の文書は、変換先の形式（format）の値として、auto、avif、webp、jpeg、baseline-jpeg、jsonの6つを書いていた。この6つの中にも、JPEG XLは入っていなかった。どちらも、2026年10月5日に開いた版での話であり、将来の更新で変わる可能性がある。

03 この記事で出てくる用語

JPEG XLとimage/jxl

JPEG XLは、写真にも図にも使える形式で、MDNは、ロスあり圧縮（細かい部分を捨てて小さくする）とロスなし圧縮（元と同じに戻せる）の両方、透明、アニメーション、HDRに対応していると書いている。通信の中では、種類の名前として「image/jxl」が使われる。この名前が、画像のURLへの応答の「Content-Type」や、picture要素の「type」属性に出てくる。

表示の部品（デコーダー）の話も、1つだけ触れておく。ChromeがJPEG XLの復号に使うと書いている「jxl-rs」について、GitHubのjxl-rsのページは、次のように書いている。

"It is the JPEG XL decoder implementation used in Google Chrome / Chromium and Mozilla Firefox."

（訳: これは、Google Chrome／Chromium、およびMozilla Firefoxで使われている、JPEG XLのデコーダーの実装である。）

Acceptヘッダー

ブラウザが画像を要求するとき、「この種類なら受け取れる」という一覧を、Acceptというヘッダーに付けて送る。MDNは、画像の要求の例として、avif、webp、png、svg+xmlの順に並べ、そのあとに「image/*」と「*/*」を付けた値を載せている。サーバーやCDNは、この一覧を見て、返す形式を選べる。これが「コンテンツネゴシエーション」で、MDNは、サーバーが、この仕組みで返す種類を選ぶ方法を「server-driven」（サーバー主導）と呼んでいる。

picture要素とtype属性

picture要素は、同じ画像の別の版を、source要素で並べておくための入れ物である。source要素のtype属性には、その版の種類を書く。MDNは、type属性の扱いを、次のように書いている。

"If the user agent does not support the given type, the <source> element is skipped."

（訳: ユーザーエージェント（ブラウザ）が、書かれた種類に対応していなければ、そのsource要素は飛ばされる。）

つまり、type属性を付けておけば、対応していないブラウザは、その版を読み飛ばして、次の版か、最後のimg要素に進む。

Varyヘッダー

同じURLが、要求の条件で別の中身を返すとき、キャッシュ（一度取った画像を使い回す仕組み）が混乱しないように、応答に付けるヘッダーである。MDNは、次のように書いている。

"Including a Vary header ensures that responses are separately cached based on the headers listed in the Vary field."

（訳: Varyヘッダーを付けると、その欄に並べたヘッダーの違いごとに、応答が別々にキャッシュされる。）

フォールバック

新しい書き方に対応していない相手のために、古い書き方の代わりを残しておくことを、フォールバックと呼ぶ。Googleの画像の文書は、picture要素やsrcset属性について、次のように書いている。

"We recommend that you always specify a fallback URL using the src attribute."

（訳: 必ず、src属性で、フォールバックのURLを指定することをおすすめします。）

04 型別 — 適用範囲・この記事が確かめていないこと・手順

適用範囲 — この確認が向いているサイト

自社のサイトで、画像を配信しているサイトが対象である。画像を自分で置いているサイトも、CMSのメディア機能を使っているサイトも、CDNを前に置いているサイトも含む。画像の形式を、いま足す予定がないサイトでも、「内訳を数える」「変換の仕組みが何をしているかを知る」の2つは、役に立つ。新しい形式を足すかどうかを決める日に、数字が手元にあるからである。

この記事が確かめていないこと

確かめていないことは、5つある。1つ目は、Chrome 155の安定版で、JPEG XLが既定で有効になるかどうかである。2つ目は、Safariなど、Chrome以外のブラウザの現在の状況である。MDNの文を引いただけで、自分で試してはいない。3つ目は、Googleの検索が、JPEG XLの画像をどう扱うかである。文書の一覧に載っていない、という事実だけを書く。4つ目は、JPEG XLに変えると、読み込みが速くなるか、小さくなるかである。数字は測っていない。5つ目は、CDNやCMSの、Cloudflare以外の製品の対応状況である。

手順の流れは、4つに分かれる

手順は、4つに分かれる。数えるのは、自社が配信している画像の形式を、拡張子ごとに数える作業である。応答を見るのは、画像のURLに、Acceptの値を変えて要求し、返ってくる形式とヘッダーを見る作業である。設定と文書を調べるのは、CDNやCMSの設定画面と、Googleの画像の文書を開いて、出せる形式と、対応する形式を書き写す作業である。決めるのは、「足す」「足さない」「様子を見る」の1つを選び、理由と見直す日を書く作業である。

数える前に、ページを3つに絞る

サイトの全ページを一度に調べる必要はない。トップページ、記事や商品のページを1つ、一覧のページを1つの3つで、画像の種類は、ほぼ見える。3つのページで、画像の置き方が違う（たとえば、トップだけ別の仕組みで画像を出している）ことがわかれば、そのページを足す。

05 明日、自社サイトで確認できることチェックリスト

まず13項目を通して見る

以下は、明日、自社のページを3つ開いて、画像の形式を確かめるための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜4番目がHTMLの確認、5〜7番目が画像のURLへの応答の確認、8〜9番目が画像ファイルの内訳と、変換の設定の確認、10〜11番目が文書との照らし合わせ、12〜13番目が足す場合の備えの確認と、判断の記録である。

• トップページ・記事か商品のページ・一覧のページの3つを選び、URLを表に書く
• 1つ目のページを開き、ブラウザの「ページのソースを表示」で「<img」を検索して、見つかった本数を書く
• 3ページの<img>のsrcを、拡張子（png・jpg・gif・svg・webp・avif・jxl）に分けて、形式ごとの本数を表に書く
• 3ページで「<picture」を検索し、見つかった本数と、そのうちtype属性が付いたsourceの本数を、別々に書く
• 画像を1枚選び、ブラウザの開発者ツールのネットワークの画面で、応答の「Content-Type」と「Content-Length」を書き写す
• 同じ画像のURLに、Acceptを「image/avif,image/webp,*/*」と「image/jxl,*/*」にして取り直し、Content-Typeが2回で違うかを書く（curlの-Hで指定できる）
• 応答に「Vary」があるかを見て、あれば値を書き、なければ「なし」と書く
• CMSのメディア一覧か、画像の置き場の一覧で、画像ファイルを拡張子ごとに数え、表の「内訳」の欄に書く
• CDNかCMSの、画像の自動変換の設定画面を開き、出力できる形式を全部書き写す（変換していなければ「なし」と書く）
• その設定の公式の文書を開き、形式の一覧にJPEG XLが「ある」か「ない」かを、書く
• Googleの画像の文書の「Use supported image formats」の一覧を開き、自社が配信している形式が全部入っているかを、形式ごとに○か×で書く
• JPEG XLを足す場合に備え、<picture>の最後の<img>のsrcが、一覧に載っているJPEGかPNGになっているかを、3ページで確かめる
• 「足す」「足さない」「様子を見る」の1つを選んで、理由を1行と、見直す日（たとえば安定版の30日後）を、表の上に書く

観点別の内訳と、かかる時間

すべてに目を通す時間は、あわせて45分ほどである（筆者の見積もりで、ページの画像の数で変わる）。内訳は、1〜4番目が10分、5〜7番目が10分、8〜9番目が10分、10〜11番目が10分、12〜13番目が5分である。画像の形式を足す予定がないサイトは、1〜3番目と8番目だけでも、「いまの内訳」が数字で手元に残る。

5分で終わらない項目があったとき

8番目は、画像の数が多いと、5分では終わらない。そのときは、拡張子ごとに、一覧の合計の件数だけを見ることで足りる。ファイルを1枚ずつ開く必要はない。9番目は、CDNやCMSの種類が多いサイトほど時間がかかる。種類が多いときは、トップページの画像を出している仕組みを先に調べる。

表に書く欄は、7つで足りる

表は、「ページのURL」「形式ごとの本数」「picture要素の本数」「Content-Type」「Vary」「Googleの一覧との照合」「判断と見直す日」の7つの欄で足りる。3ページ分なので、3行である。書いた表は、あとで同じ手順を繰り返すときの、前回の値になる。

06 代替・他の選択肢（表で）

画像の形式を、どうするかの4つの選び方

JPEG XLが表示できるブラウザが増えても、サイトの管理者が選べる道は、1つではない。4つに分けて、公式の文書に書かれていることと、先に確認することを並べた。公式が勧める順番ではなく、筆者の整理である。

この表から言えるのは、4つの選び方のどれでも、先に必要なのは「自社の内訳」と「応答の確認」だということである。表の中身は、2026年10月5日に開いた文書の記載であり、将来の更新で変わる可能性がある。

WebP・AVIF・JPEG XLを、文書の記載で並べる

3つの形式を、MDNの画像形式の手引きと、Googleの画像の文書の記載のまま、並べた。2026年10月5日に開いた版である。圧縮でどれだけ小さくなるかは、表に入れていない。MDNはWebPとAVIFについて数字を書いているが、比べている条件が違い、JPEG XLの項には数字がなかったため、同じ物差しで並べられないからである。

出典は、特徴とブラウザの対応の列が、MDNの「Image file type and format guide」の、WebP・AVIF・JPEG XLのそれぞれの項である。MIMEタイプの列も、同じ手引きの各項の「MIME type」の欄による。「Googleの一覧」の列は、Google検索セントラルの「Google Image SEO best practices」の、対応する形式の一覧による。取った日は、どの行も2026年10月5日である。表の「Chrome 145以降はフラグの裏」は、Chrome 155のベータの話ではなく、MDNの記載である。155のベータで状態がどう変わるかは、01章のとおり、確かめていない。

Googleの一覧に載っていない形式を、足すとき

Googleの画像の文書は、対応する形式を、次のように書いている。

"Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF."

（訳: Google検索は、imgのsrc属性で参照された画像について、次のファイル形式に対応している。BMP、GIF、JPEG、PNG、WebP、SVG、AVIF。）

この文は、JPEG XLを「使えない」とは書いていない。一覧に載っていない、という事実だけが読み取れる。同じ文書は、新しい形式を足すときの書き方も、次のように書いている。

"The picture element also comes in handy for using new image formats with built-in graceful degradation for clients that may not yet support the new formats."

（訳: picture要素は、まだ新しい形式に対応していないクライアントに向けた、組み込みの段階的な縮退（代わりの表示）をつけて、新しい画像形式を使うときにも便利である。）

この2つの文を合わせると、JPEG XLを足すなら、picture要素の最後のimgのsrcには、一覧に載っている形式（JPEGやPNG）を置いておくのが、文書と矛盾しない形である。文書は、imgのsrcにある画像を見つけると書いているので、最後のimgに一覧の形式を残す形は、文書の書き方と矛盾しない。

picture要素の書き方の例

JPEG XLを足すときの、picture要素の例を示す。ファイル名と説明文は、例のために付けたものである。MDNの書き方に沿って、新しい形式のsourceを先に置き、いまの形式のimgを最後に置いた。

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <img src="photo.jpg" alt="店の入口を正面から写した写真" width="1200" height="630">
</picture>

この形では、image/jxlに対応していないブラウザは、type属性を見て、そのsource要素を飛ばし、最後のimgのsrcにあるJPEGを使う。MDNのpictureの説明は、対応するsourceが見つからないときは、imgのsrcが選ばれると書いている。imgのwidthとheightには、画像の幅と高さを書き、altには、画像の内容を書く。WebPやAVIFも足すなら、sourceを、MDNの例のように、並べて足す。最後のimgは、必ず残す。

自動変換に任せるときに、確かめること

CDNやCMSの自動変換に任せているサイトは、変換先の形式が、設定で決まっている。Cloudflareの画像変換の文書は、autoの値について、次のように書いている。

"Automatically serves the most efficient format that the requesting browser supports."

（訳: 要求したブラウザが対応する、もっとも効率のよい形式を、自動で返す。）

この文書の、format の値の一覧には、JPEG XLが入っていなかった（2026年10月5日に開いた版）。同じ文書の、Workerの例は、AcceptにavifかwebpがあるかをAcceptの文字列で調べて、変換先を決める書き方になっている。Chromeが、JPEG XLの表示に対応しても、CDN側が、その形式を出せるように作られていなければ、自動では変わらない。これは、Cloudflare以外のCDNでも、確かめる価値がある。

自動変換には、もう1つ、確かめることがある。同じURLが、条件で違う形式を返すなら、キャッシュの扱いである。MDNは、サーバー主導の方法の欠点を、次のように書いている。

"As several representations of a given resource are sent, shared caches are less efficient and server implementations are more complex."

（訳: 同じ資源の複数の版が送られるため、共有のキャッシュは効率が下がり、サーバーの実装は複雑になる。）

自社のCDNが、Acceptの違いごとに、別々のキャッシュを持つのか、持たないのかは、Varyの有無で、ある程度わかる。5〜7番目の項目で、確かめられる。

「足さない」ことも、記録する判断である

足さない、と決めた日にも、理由を1行、書いておく。たとえば「Googleの一覧に載っていないので、様子を見る」「CDNの形式の一覧にないので、見送る」「内訳のほとんどがSVGなので、効果が小さい」などである。書いておくと、半年後に、同じ議論を、最初からやり直さずに済む。見直す日を、安定版の30日後など、日付で決めておくと、「様子を見る」が、永久に続くことも避けられる。

07 当サイトで内訳と応答を確かめてみた例

数えた範囲と方法

当サイト（WEBサイトサポート）の、公開している画像ファイルの形式を、2026年10月5日に数えた。数えた範囲は、サイトの画像などのファイル置き場の全体（1,416ファイル）である。あわせて、トップページ、ブログの記事1本、解説記事1本の3ページのHTMLを取って、imgとpictureの書き方を数えた。さらに、ブログの画像1枚に、Acceptの値を3通り付けて取り直し、応答を比べた。3通りは、「*/*」、MDNの例にある画像用のAccept、「image/jxl」を先頭に置いたAcceptである。

画像ファイルは、PNGとJPEGが全部だった

形式で数えた結果は、PNGが1,220、JPEGが176、GIFが3だった。WebPとAVIFとJPEG XLは、0だった。画像ファイルの合計1,399のうち、PNGが87.2%、JPEGが12.6%である。残りの17ファイルは、画像の拡張子（png・jpg・jpeg・gif・svg・webp・avif・jxl）ではなかった。当サイトは、いまのところ、新しい形式を1つも配信していない。

ページのHTMLと、Acceptへの応答

トップページのimgは70本で、srcの拡張子の内訳は、PNGが49、JPEGが17、SVGが3、GIFが1だった。picture要素は24個あり、中のsource要素も24個だった。24個のsourceは、どれも、type属性が付いていなかった。付いていたのは、画面の幅で画像を切り替えるための条件（media）だけで、形式で切り替える使い方は、していなかった。ブログの記事1本も、picture要素は1個で、同じ形だった。解説記事1本には、picture要素がなく、imgは8本（PNGが5、SVGが3）だった。

画像1枚にAcceptを3通り付けて取り直した結果は、3回とも、Content-TypeがPNGで、Content-Lengthも同じだった。応答に、Varyは付いていなかった。当サイトの画像は、Acceptの違いで、返す形式を変えていない。つまり、「ブラウザが対応した形式を、サーバーが選んで返す」仕組みは、使っていない。

この例の限界

これは、当サイトのファイル置き場全体と、3ページと、画像1枚での確認である。画像1枚の応答が、すべての画像で同じかは、確かめていない。サイトの画像をJPEG XLに変えると、どれだけ小さくなるかも、測っていない。当サイトがJPEG XLを足すかどうかは、この記事を公開した時点では、決めていない。確かめた内訳をもとに、見直す日を決めて、結果は、別の記事に書く。

08 このテーマの、これまで

画像の形式と、画像SEOの過去の記事

当サイトには、画像の形式を、別の角度から確かめた記事がある。画像SEOの基本 ── alt属性・次世代フォーマット・遅延読み込みを、公式ガイドで確認する14項目（2026年9月時点）は、次世代の形式と遅延読み込みを、Googleの公式のガイドで確かめた記事である。検索結果のファビコンにSVGとWebPは使えない ── Googleが対応する7つの画像形式を確認する13項目（2026年9月時点）は、検索結果のファビコンに使える形式の話で、Googleの対応する形式の一覧を、別の用途で確かめた。画像と対象を複数の場所で揃える提案に、Googleの公式文書は効果まで述べていない ── 1枚の画像で確認する14項目（2026年9月時点）は、画像を複数の場所で揃える提案の記事である。画像から探された実績は、2つのレポートに別々の形で現れる ── Search Consoleで確認する14項目（2026年9月時点）は、画像から探された実績を、Search Consoleで確かめる記事である。

ブログでは、検索は「探す」から「作る」に変わる日 — Google画像検索25周年リニューアルとAI Overviews画像生成、今週やるべき画像SEO点検が、Google画像検索の変化と、画像SEOの点検を扱った。faviconは「飾り」から「名乗り」になった — 検索結果とAI引用の"顔"を整える2026年版総点検は、ファビコンの形式を整える総点検である。

見た目と実際を分けて確かめた記事

「見た目では同じでも、実際は違う」という確かめ方は、この記事の「内訳を数える」「応答を見る」と同じ形である。見た目では区別できない ── 時刻の記録を読んだら、画像147本のうち45本が「運ばれてきた」側だったは、画像を時刻の記録で分けて数えた記事である。仕組みは在った。運ぶ気もあった。探す形が違っていた ── サムネイルが本番から消えていた日、ログは一度も鳴らなかったは、画像が本番から消えていたのに、ログが鳴らなかった話である。外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、外から取った画面が、目当ての画面とは限らなかった話である。記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったと、「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれ、「1本だけ書き方が違う」と指摘された ── 91本で数え直したら、標準だったのはその1本のほうだったも、確かめる段を増やす考え方で、通じている。