seo-images

画像 SEO 監査

対象ページ（またはドメインのサンプル）にあるすべての <img> と <picture> を対象に、ページ単位で重点的に監査します。代替テキストの問題、フォーマットの不足（WebP/AVIF の対応状況）、レスポンシブ画像の不足（srcset / sizes）、LCP と CLS のリスク、ImageObject マークアップの欠落を明らかにします。優先度付きの修正リストに加え、そのまま貼り付けられる <picture> と JSON-LD のスニペットを出力します。

AgriciDaniel/claude-seo の seo-images スキルをベースにしています（MIT）。評価基準、遅延読み込みの分類、重要度の段階は上流の実装に準拠しています。データソースは、このカタログの SE Ranking / Firecrawl / Google API スタックに接続されています。

前提条件

• インベントリ作成に必須： mcp__firecrawl-mcp__firecrawl_scrape（生 HTML へのアクセス）。WebFetch が返すのは Markdown のみです。すべての <img> 属性（srcset、sizes、loading、fetchpriority、width、height、data-src* の遅延読み込み用バリエーション）は、スキルが参照する前に取り除かれます。Firecrawl がなければ監査を実行できません。bash extensions/firecrawl/install.sh でインストールしてください。
• 任意（PSI の節約バイト数の推定）： google-api.json が設定済みであること（Tier 0 — API キーのみ）。設定されている場合、ステップ 9 が実行され、画像ごとの実際の Lighthouse wastedBytes が修正リストに追加されます。
• 任意（SE Ranking 監査との照合）： SE Ranking MCP サーバーに接続し、対象ドメインの最近の監査が実施されていること。条件を満たす場合、ステップ 10 で画像関連の監査項目が同じ修正リストに追加されます。
• ユーザーから提供される情報：対象 URL（単一ページの監査）またはドメイン（サンプル監査）。ドメインの場合、Firecrawl クレジットを消費する前に、サンプルとして抽出するページ数をスキルが確認します。

プロセス

1. 対象を検証し、事前チェックを実施します。 URL を正規化します（末尾のスラッシュを削除し、IDN をデコード）。モードを判定します。

   • URL モード（単一ページのように見える入力ではデフォルト）：対象は 1 つの URL です。コスト：Firecrawl クレジット 1 件＋任意の PSI 呼び出し。
   • ドメインモード（入力がドメインのみの場合、またはユーザーがドメイン全体の監査を明示的に依頼した場合）：まずマッピングを行い、その後サンプルをスクレイピングします。
   • 事前チェック（該当する場合は skills/seo-firecrawl/references/preflight.md に準拠）：
     • Firecrawl に接続されていることを確認します。未接続の場合は、インストールコマンドを示して処理を中止します。
     • Google API が設定されている（~/.config/seo-skills/google-api.json が存在する）場合は、検出された Tier を記録します。ステップ 9 で使用します。設定されていない場合は、ステップ 9 をスキップとして記録します。
     • SE Ranking MCP が接続されており、対象ドメインの最近の監査が存在する場合は、監査 ID を記録します。ステップ 10 で使用します。該当しない場合は、ステップ 10 をスキップとして記録します。

2. 画像インベントリの収集 mcp__firecrawl-mcp__firecrawl_scrape（URL モード）または firecrawl_map + firecrawl_scrape（ドメインモード）

   • URL モード： 対象を formats: ["html", "markdown"]、onlyMainContent: false でスクレイピングします（監査ではナビゲーションやフッターの画像も対象です。ヒーローロゴ、フッターの信頼バッジ、装飾画像もすべて重要です）。SPA では waitFor: 2000 を渡し、遅延読み込みで挿入される画像がレンダリング後の DOM に表示されるようにします。返された html からすべての <img> と <picture> を解析します。画像ごとに以下を記録します。
     • src、srcset、sizes、alt、loading、fetchpriority、decoding、width、height、role、aria-hidden
     • 遅延読み込み属性：data-src、data-srcset、data-lazy-src、data-original、data-perfmatters-src、data-perfmatters-srcset、data-ewww-src、data-eio
     • クラスのシグナル：lazyload、lazyloaded、lazy、perfmatters-lazy、lazyload-eio
     • 親 <picture> 内の <source> エントリー：type、srcset、media
     • 解決済みの絶対 URL（クロスオリジン／CDN 検出用）
   • ドメインモード： firecrawl_map を実行します（デフォルトの limit: 500、上限あり。費用：検出された URL 1 件あたり約 0.5 クレジット。実行前に見積もりを提示してください）。URL リストから最大 10 ページをサンプルとして選びます。ホームページに加え、トラフィック上位のランディングページを選択します（SE Ranking が接続されている場合は DATA_getDomainKeywords のページ集計から、そうでない場合はサイトマップ内で最も階層が深い URL から選びます。これらは通常、カテゴリのインデックスではなくコンテンツページです）。スクレイピング前に、サンプル一覧とクレジット費用を確認します。次に各ページをスクレイピングします（1 ページあたり 1 クレジット）。インベントリには、サンプルページ上のすべての画像を統合します。
   • CSS の背景画像： 既知の盲点としてフラグを付けます。スタイルシート内の background-image: url(...) は監査しません。Google によるコンテンツ画像としてのクロール対象ではなく、画像検索での可視性も得られないためです。統合結果には「{n} 件の背景画像の可能性あり（計算済みスタイルの参照）— この監査の対象外です。ヒーロー画像／フィーチャー画像が CSS ベースの場合は、別途確認してください」と記載します。

3. 代替テキストの監査

   • references/image-checks.md § Alt text を読み込みます。各画像について、以下を確認します。
     • 有無： alt がない場合（alt="" は該当しません。空文字列の形式は純粋な装飾画像であれば有効です）。重要度：高。
     • 装飾画像としての指定漏れ： alt="" が適切なのは、画像が本当に装飾目的の場合に限られます。alt="" でありながら、非装飾的な src（例：商品写真のパス、ヒーロー画像のパス）を持つ画像には、「装飾目的か確認」とフラグを付けます（中）。
     • 汎用的なテキスト： alt の値が汎用パターンに一致する場合。ファイル名のみ（image.jpg、IMG_1234.png）、汎用的な名詞 1 語（photo、picture、image、banner）、CTA の文言（click here、read more、learn more）。重要度：高。
     • 長さ： alt が 10～125 文字の範囲外の場合。10 文字未満 → 中（説明が不十分な可能性があります）。125 文字超 → 低（長すぎる可能性があります。スクリーンリーダーではこのあたりで切り詰められます）。
     • キーワードの詰め込み： 同じキーワードトークンが alt 内に 3 回以上出現する場合、または alt の 50% 超がキーワードトークンの場合。重要度：中。
     • ページ内の複数画像で同一の alt： テンプレートの不具合としてフラグを付けます（中）。PDP のすべての商品写真で同じ alt を共有してはいけません。

4. フォーマットの対応状況（WebP／AVIF）

   • 各画像について、src 拡張子（.webp、.avif、.jpg／.jpeg、.png、.gif、.svg）と、<picture> の <source> の type 属性（image/avif、image/webp）から、配信されるフォーマットを分類します。
   • ページ（またはドメインのサンプル）について、次の3つの対応状況指標を計算します。
     • WebP または AVIF で直接配信される画像の割合（%）（選択された <img src> または選択された <picture> の <source> を使用）。
     • 少なくとも1つのモダンフォーマットの <source> を含む <picture> で囲まれた画像の割合（%）（段階的拡張 — フォールバックチェーン）。
     • モダンフォーマットの代替がなく、旧式フォーマットのままの画像の割合（%）（JPEG／PNG／GIF）。
   • 画像ごとのフラグ：
     • <picture> によるモダンフォーマットの代替がない旧式フォーマット → image_legacy_format（中）。
     • 500 KB を超えるアニメーション GIF → 代わりに動画（<video autoplay muted loop playsinline>）を推奨（中 — パフォーマンスと LCP への影響）。出典：Google PSI の efficient-animated-content 監査。
     • 写真コンテンツに使用されている SVG → image_svg_misuse（低 — ファイルサイズが非常に大きくなります。SVG はアイコンやイラスト向けです）。
   • JPEG XL に関する注記。 Chromium は2025年11月に Rust ベースの JPEG XL デコードの復活を発表しましたが、Chrome stable にはまだ含まれていません。Tips の注記として表示してください。現時点では対応不要で、2026年に向けて動向を確認してください。

5. レスポンシブ対応状況（srcset／sizes）

   • SVG 以外の各ラスター画像について：
     • srcset がない → image_no_srcset（中）。ブラウザーがサイズに適したファイルを選択できず、モバイルユーザーがデスクトップ向けのサイズの画像をダウンロードします。
     • srcset はあるが sizes がなく、<picture> の中にもない → image_no_sizes（中）。ブラウザーはビューポート幅の推定値を使用するため、誤った候補を選ぶことがあります。
     • srcset は宣言されているものの、すべての候補が同じ幅記述子（1x のみ、またはすべての w 値の差が100 px 以内）→ image_srcset_useless（低）。

6. 遅延読み込みと LCP シグナル

   • 各画像について、references/lazy-loaders.md の分類に従い、遅延読み込みの方式を native／perfmatters／ewww／js-generic／none に分類します。loading と併せて lazy_method を報告することで、JS ローダーを使用するページが loading="lazy" の欠如によって誤ってフラグ付けされないようにします（ネイティブ属性が意図的にない場合は、ローダーが処理しています）。
   • LCP 候補のヒューリスティック。 LCP 画像は通常、次の条件に該当する最初の <img> です。
     • 一般的なモバイルビューポートでファーストビューに表示される（描画なしでは正確なビューポートを特定できないため、ヒューリスティックでは、描画後の DOM で <header>／<nav>／<aside> の中になく、loading="lazy" を持つ祖先もない最初の <img> とします）。
     • 描画領域が大きい（width と height 属性の両方が300以上、またはビューポート全体に広がる sizes を持つ <picture> の <source> がある）。
   • LCP 候補について：
     • loading="lazy" が設定されている → image_lcp_lazy（高）。LCP 画像を遅延読み込みすると、LCP に直接悪影響を与えます。
     • fetchpriority="high" がない → image_lcp_no_fetchpriority（中）。Lighthouse の prioritize-lcp-image 監査。fetchpriority="high" を設定すると、LCP 画像がブラウザーのネットワークキューの先頭に移動します。
   • ファーストビューより下にある画像（LCP 候補ではなく、最初のビューポート内にもない画像）について：
     • ネイティブの loading="lazy" も JS ローダーのシグナルもない → image_below_fold_eager（中）。ファーストビューより下の画像は読み込みを遅らせるべきです。
     • decoding="async" がない → image_no_decoding_async（低）。非 LCP 画像のデコードがメインスレッドをブロックしないよう、非同期デコードを使用します。

7. CLS の寸法

   • 各画像について：
     • width と height の両属性がなく、インラインの aspect-ratio スタイルもない → image_unsized（高）。ブラウザーがスペースを確保できないため、画像の読み込み時にコンテンツが移動します。Lighthouse の unsized-images に該当します。
     • width と height はあるものの、アスペクト比が実際の表示比率と5%を超えて異なる → image_aspect_mismatch（低）。読み込み時にレイアウトが移動します。
   • どちらの場合も修正方法は同じです。画像の本来の寸法を width と height 属性に設定し、レスポンシブな拡大縮小は CSS で処理します。

8. ファイル名の品質

   • 各画像の解決済みURLからファイル名を抽出します。次の項目に該当する場合は指摘します。
     • カメラの初期設定の名前（IMG_xxxx、DSC_xxxx、DSCN_xxxx、P_xxxx、Photo_xx）→ image_camera_filename（Low）。
     • ランダムなハッシュ名（a3f9b2c.jpg、0e8d1f7.webp — 人間が読めるトークンを含まない16進数／Base64のパターン）→ image_hash_filename（Low）。画像CDNでよく見られます。SEOに適したバージョンが利用できないか確認してください。
     • すべて大文字、またはアンダースコアのみで構成されたファイル名 → image_filename_style（Low）。慣例では小文字とハイフンを使います。
   • CDN経由で配信される画像をすべて問題として指摘しないでください。多くのCMSではキャッシュ無効化のためにファイル名をハッシュ化しており、これは問題ありません。同じ画像のaltが欠落している、または汎用的な場合に組み合わせて指摘すると意味があります（ページ上に画像の内容を示す情報がまったくありません）。

9. ImageObject JSON-LD：検出、検証、生成

   • 検出： Firecrawlが返したすべての<script type="application/ld+json">ブロックを解析します。既存のImageObjectブロックを探します。画像検索のリッチリザルト用にトップレベルに記述されているものと、Article.image、Product.image、Recipe.imageなどの下にネストされているものが対象です。
   • 検証： Google画像検索のガイドライン（フィールド一覧はreferences/image-checks.md § ImageObjectを参照）に照らして検証します。トップレベルのImageObjectでは、次のとおりです。
     • 必須：@context、@type: ImageObject、contentUrl（画像URL）、creatorまたはcopyrightHolder。
     • ライセンス可能な画像のリッチリザルトで推奨：license（ライセンス条項のURL）、acquireLicensePage（ユーザーが画像を購入またはライセンス取得できるURL）、creditText（クリエイターのクレジット表記方法）。
     • よくある誤り：contentUrlの代わりにurlを使う、authorをPerson／Organizationオブジェクトではなく単なる文字列にする、寸法をNumberではなく文字列にする。
   • 生成： 既存のImageObjectブロックがなく、「マークアップする価値がある」基準を満たす各画像（ページのヒーロー画像／ファーストビューに表示され、ページに明確なクリエイター／所有者がいる画像）について、templates/image-object.jsonをもとに貼り付け可能なブロックを作成し、ライブHTMLからフィールドを入力します。解決できないフィールドは{REPLACE: ...}として記載します。生成されたファイルは02-remediation/image-object.jsonldとして出力します（.jsonld拡張子は、<script type="application/ld+json">に記述する成果物であることを示します）。
   • すべての<img>に対してImageObjectを生成しないでください。 ノイズになります。ヒーロー画像と、ライセンス可能な画像のリッチリザルトの対象となるべき画像に限定してください。

10. 任意：PageSpeed Insights のバイト削減量 （~/.config/seo-skills/google-api.json が存在し、Tier ≥ 0 の場合のみ）

    • python3 scripts/pagespeed_check.py "{url}" --strategy=mobile --json と --strategy=desktop --json を実行します（対象 URL ごとに API 呼び出しを 2 回行います。PSI の無料枠である 1 日 25k 回以内です）。
    • JSON レスポンスから以下の監査項目を取得し、画像ごとの wastedBytes を修正リストに統合します。
      • modern-image-formats — WebP／AVIF の配信によって削減できるバイト数です（手順 4 と重複します。PSI の数値を正式な値として扱います）。
      • uses-optimized-images — 再圧縮によって削減できるバイト数です。
      • uses-responsive-images — サイズに適したファイルの配信によって削減できるバイト数です（手順 5 と重複します）。
      • offscreen-images — ページ下部にある画像を遅延読み込みすることで、読み込みを先送りできるバイト数です（手順 6 と重複します）。
      • unsized-images — 寸法が指定されていないページ要素です（手順 7 と照合します）。
      • prioritize-lcp-image — 手順 6 の LCP 候補の判定基準を裏付ける、または否定する項目です。PSI が正式な値として扱う LCP 要素も示します。
      • efficient-animated-content — 手順 4 のアニメーション GIF の検出結果を裏付ける項目です。
    • PSI の各監査項目は、url と wastedBytes を含む details.items[] を返します。画像 URL（絶対 URL に解決済み）をキーに結合し、各修正項目に psi_wasted_bytes を付与します。これにより、優先順位付きリストをヒューリスティックな深刻度だけでなく、実際の削減量に基づいて並べ替えられます。
    • PSI が設定されているものの監査項目が返されない場合（Lighthouse が読み込めない非公開／保護された URL が原因の 4xx であることがほとんどです）、「PSI: could not analyse {url} ({reason})」と記載し、PSI 以外のシグナルを使って続行します。

11. 任意：SE Ranking 監査との相互参照 （SE Ranking MCP に接続されていて、最近の監査がある場合のみ）

    • DATA_listAudits → ドメインの最新の監査を探します。監査が存在しない場合、または 30 日を超えている場合は、この手順をスキップします（画像スキルから新しい監査を実行しないでください。実行するかどうかは seo-technical-audit が判断します）。
    • 画像関連の監査コードごとに、DATA_getAuditPagesByIssue を実行します。
      • images_oversized（または SE Ranking で現在「非圧縮画像」を表すコード）
      • images_no_alt
      • images_broken（画像 URL の 404／5xx）
      • images_no_dimensions（CLS）
    • 検出結果を統合します。監査とこのスキルの両方で問題が指摘された画像は、深刻度を 1 段階引き上げます。監査で指摘されているものの Firecrawl のサンプルに含まれていない URL は、「Audit-flagged pages not in this sample」の下に記載し、それらの URL に絞って再実行するよう提案します。

12. 統合する IMAGES.md を作成します。修正テーブルは、以下の順序で並べ替えます。

    1. 深刻度（Critical → High → Medium → Low）。
    2. 深刻度が同じ場合：PSI を実行したときは wastedBytes の降順、それ以外は影響を受ける画像数の降順。
    3. その後、問題コードのアルファベット順。

出力形式

seo-images-{target-slug}-{YYYYMMDD}/ フォルダーを作成し、以下を含めます。

seo-images-{target-slug}-{YYYYMMDD}/
├── IMAGES.md                       (synthesised audit + remediation list — primary deliverable)
├── images.csv                      (every image with all audit columns — engineering pastes into Jira)
├── 01-inventory.md                 (per-page image list with raw attributes)
├── 02-remediation/
│   ├── picture-snippets.md         (paste-ready <picture> blocks for the top N legacy-format images)
│   ├── alt-text-rewrites.md        (suggested alts for missing / generic-text cases)
│   └── image-object.jsonld         (generated ImageObject for the hero image, if applicable)
├── 03-psi-report.md                (PSI image-audit breakdown — only if Google APIs configured)
└── 04-audit-cross-ref.md           (image-related SE Ranking audit issues — only if step 11 ran)

IMAGES.md の形式は以下のとおりです。

# Image SEO Audit: {URL or domain}

> Snapshot dated {YYYY-MM-DD} · Mode: {URL | domain-sample (n pages)} · Images analysed: {n}

## Coverage at a glance

| Metric | Result |
|---|---|
| Total images | {n} |
| Missing alt text | {n} ({pct}%) |
| Generic / templated alt text | {n} ({pct}%) |
| Modern format (WebP/AVIF) coverage | {pct}% direct, {pct}% via `<picture>` fallback |
| `srcset` present (responsive) | {pct}% |
| `loading` strategy detected | native: {pct}% · JS-loader: {pct}% · none: {pct}% |
| LCP image flagged | {yes/no — element + risk} |
| Unsized (CLS risk) | {n} ({pct}%) |
| `ImageObject` JSON-LD | {present / partial / missing} |

## Top 10 remediations (severity × byte savings)

| Rank | Issue code | Severity | Images | PSI wastedBytes | Fix | Effort |
|---|---|---|---|---|---|---|
| 1 | image_lcp_lazy | High | 1 | 480 KB | Remove `loading="lazy"`; add `fetchpriority="high"` | S |
| 2 | image_legacy_format | Medium | 14 | 2.1 MB | Convert to WebP, wrap in `<picture>` with fallback | M |
| ... |

## By category

### Alt text ({n} issues)
- {n} images missing `alt` entirely. See `02-remediation/alt-text-rewrites.md` for suggested rewrites.
- {n} images with generic alt (`image.jpg`, `photo`, "click here").
- {n} images with identical alt across multiple images (templating bug).

### Format coverage ({pct}% modern)
- {n} images stuck on legacy JPEG/PNG. See `02-remediation/picture-snippets.md`.
- {n} animated GIFs >500 KB — recommend video.

### Responsive sizing ({pct}% have `srcset`)
- {n} images without `srcset`.
- {n} images with `srcset` but no `sizes`.

### Lazy loading & LCP
- LCP candidate: `{img src or selector}` — {risk summary}.
- {n} below-fold images loading eagerly.
- {n} images missing `decoding="async"`.

### CLS dimensions ({n} unsized)
- {n} images without `width`/`height` attributes.
- {n} images with aspect-ratio mismatches.

### File names ({n} flagged)
- {n} camera-default names (IMG_xxxx).
- {n} hash-only filenames coupled with a missing/generic alt.

### ImageObject JSON-LD
- Currently present: {none | block-level on hero | partial}.
- Recommended additions: {none | hero-image ImageObject for licensable-images rich result}.

## Paste-ready remediations

See `02-remediation/`:
- `picture-snippets.md` — `<picture>` blocks for the top N legacy-format images.
- `alt-text-rewrites.md` — alt-text rewrites for missing / generic cases.
- `image-object.jsonld` — `ImageObject` block for the hero image.

## Out of scope for this skill

- **File-level optimisation** (running `cwebp` / `exiftool` / ImageMagick / `ffmpeg` against the actual binary). This skill audits markup and references; converting and re-uploading the files is engineering work — see the pipeline note in `references/image-checks.md` § Optimisation pipeline if you want a starting recipe.
- **CSS background-images.** {n} likely background-image references detected via computed style, but not audited. They don't appear in Google Images and aren't subject to the `<img>`-tag rubric.
- **Site-wide audit at >10 pages.** This is a sampled audit. For domain-level "every image on every page", run `seo-technical-audit` first to surface the audit-grade signals, then come back here for sample-level deep audit.

## Recommended next steps

- {`seo-technical-audit` if domain-wide image issues need to be quantified — uncompressed-images counts, etc.}
- {`seo-schema` if `ImageObject` was generated and the page also needs `Article` / `Product` / etc. markup.}
- {`seo-google pagespeed` for the full Lighthouse breakdown (this skill only pulls image-specific audits).}

images.csv の列：page_url,image_url,alt,alt_length,alt_issue,format,in_picture,modern_source,srcset,sizes,loading,lazy_method,fetchpriority,decoding,width,height,unsized,lcp_candidate,filename_issue,psi_wasted_bytes,severity,fix,effort。

ヒント

• 基本的には URL モードを使ってください。 1 ページの監査では Firecrawl クレジットを 1 消費し、最もよくある依頼（「/this/page の画像を監査してください」）に対する成果物一式を生成します。ドメインモードは「サイト全体の代表的な状況を把握したい」という場合に使います。1 ページモードでは見つからないパターン（テンプレートの不具合、CMS 全体での alt の欠落など）を明らかにします。
• 推奨するのは <picture> です。 最新のフォーマットを推奨する場合は、AVIF と WebP の <source>、JPEG のフォールバック <img> を含む <picture> 要素を必ず推奨してください。単に <img src=".avif"> とするのは避けてください。AVIF のサポート率は 93% 以上、WebP は 97% 以上ですが、古いクライアントやクローラーでも安全に使えるマークアップにするには、フォールバックが必要です。
• LCP 画像を遅延読み込みしないでください。 これは、最新の CMS で最もよく見られる画像 SEO の間違いです。テーマには、ヒーロー画像にも適用される loading="lazy" のサイト全体のデフォルト設定が含まれていることがあります。このスキルの LCP ヒューリスティックで最も可能性の高い原因を見つけ、ステップ 10 の PSI で確実に確認できます。
• 純粋に装飾目的の画像では、alt="" が正しい設定です（細い水平線の SVG、背景の余白用画像など）。スクリーンリーダーに画像をスキップするよう伝えます。空の alt をすべて自動的に問題として報告しないでください。画像のファイル名と文脈から内容を伝える画像だと判断できる場合に限り、報告してください。
• 画像が少ない場合は、一覧の粒度を上げてください。 画像が 10 枚未満のページでは、集計値だけでなく、すべての画像を完全な監査行とともに IMAGES.md の「カテゴリ別」セクションに記載してください。画像が 100 枚以上ある場合は集計のみの出力が役立ちますが、それより少ないと詳細が分かりにくくなります。
• 無料枠の PSI は 1 日あたり 25k 件にレート制限されていますが、画像数ではなくリクエスト数がカウントされます。対象 URL ごとに PSI を 2 回（モバイル＋デスクトップ）呼び出すのがデフォルトです。Google のモバイルファーストのランキングシグナルだけを確認したい場合は、デスクトップを省略してください。
• CSS の background-image は実際に見落としやすい項目です。件数は報告しますが、監査はしないでください。Google はコンテンツ画像としてクロールしないためです。
• JPEG XL はまだ出荷できる状態ではありません（2025 年 11 月の Chromium の発表はデコーダーのサポート復活についてであり、安定版 Chrome にはまだ搭載されていません）。安定版に搭載されるまでは JPEG XL を推奨しないでください。現在、安全に使える最新フォーマットは WebP と AVIF です。
• 修正を自動適用しないでください。 このスキルは問題を診断し、そのまま貼り付けて使えるスニペットを生成します。どの修正を、どの順番で適用するかは人が判断します。
• デプロイ後に検証してください。 修正のデプロイ後、同じ URL に対してこのスキルを再実行してください。新しい実行結果の「カバレッジの概要」でライブ環境の状態を確認し、マークアップが実際に変更されたこと（CMS に保存されただけで、まだ公開されていない状態ではないこと）を確認できます。

併用に適したスキル

• 前段のスキル：
  • seo-firecrawl — ユーザーがすでにページをスクレイピングしており、次に画像に特化した分析を求めている場合。
  • seo-technical-audit — サイト全体の監査で画像の問題が見つかり、ユーザーが画像ごとの詳細な評価基準を求めている場合。
  • seo-page — URL レベルのキーワード／トラフィック評価が「更新」で、画像もその更新の対象となる場合。
• 後段のスキル：
  • seo-schema — ページに ImageObject だけでなく、Article ／ Product ／ LocalBusiness のスキーマも必要な場合。
  • seo-google pagespeed — Lighthouse のレポート全体を確認する場合（このスキルが抽出するのは画像監査項目のみで、PSI にはさらに 100 件以上あります）。
  • seo-drift — 画像マークアップのベースラインを作成し、CMS またはテーマのアップグレード後に発生するリグレッションを検出する場合。