블로그 이미지 SEO, alt 텍스트만으로는 부족한 이유와 플랫폼별 적용 체크리스트

구글 크롤러는 이미지를 세 번 통과해 본다

블로그 이미지 SEO를 검색하면 나오는 글은 대부분 비슷하다. "파일명을 영어로 바꾸세요", "alt 태그를 꼭 넣으세요." 틀린 말은 아닌데, 그게 전부라고 생각하면 구글 이미지 검색에서 꽤 많은 노출 기회를 그냥 흘려보내게 된다.

구글 서치센트럴의 이미지 SEO 공식 가이드를 직접 읽어보면, 크롤러가 이미지를 처리하는 과정은 단계가 있다. 발견(이미지를 찾을 수 있냐) → 이해(내용을 파악할 수 있냐) → 평가(품질을 판단할 수 있냐). 어느 단계에서 막히는지에 따라 처방이 달라진다.

이 글에서는 그 단계별 병목을 먼저 짚어보고, 플랫폼(티스토리·워드프레스·자체사이트)별로 실제로 무엇이 가능한지 구분해서 정리했다.

---

크롤러가 이미지를 처리하는 3단계 구조

6가지 이미지 SEO 요소를 구글 크롤러가 이미지를 처리하는 순서대로 분류하면 구조가 보인다. alt 텍스트를 아무리 공들여 써도, 이미지 자체를 발견하지 못하면 의미가 없다.

표에서 크롤 가능성을 최상으로 분류한 게 의외로 느껴질 수 있는데, 이유는 단순하다. 아무리 alt 텍스트를 공들여 써도 이미지가 CSS background-image로 삽입되어 있으면 구글 크롤러는 그 이미지를 색인하지 않는다. 발견 단계에서 막히면 이해·평가 단계 자체가 열리지 않는다.

---

발견 단계, 크롤러가 이미지를 찾을 수 있냐

HTML 태그와 삽입 방식 — 색인의 시작점

구글이 색인하는 이미지 포맷은 BMP, GIF, JPEG, PNG, WebP, SVG, AVIF다. 이 외의 형식은 색인 대상이 아니다.

구글 공식 문서에서 "반드시 태그의 src 속성으로 임베드하라"고 명시하고 있다. 반응형 이미지에 요소나 srcset을 쓸 때는 반드시 src 속성에 대체 URL을 함께 지정해야 한다.

<!-- 크롤러가 발견하는 예 -->
<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="설명">
</picture>

<!-- 발견 안 됨: CSS 배경은 크롤러가 인식 못 함 -->
<div style="background-image: url(image.jpg)"></div>

자바스크립트로 뒤늦게 로드되는 이미지도 발견이 늦어질 수 있다. 크롤러가 JavaScript 실행 전에 HTML을 먼저 파싱하기 때문이다.

Image Sitemap — CDN 이미지가 있다면

Image Sitemap은 구글이 기본 크롤링으로 발견하지 못하는 이미지, 특히 CDN 도메인에 올라간 이미지를 직접 알려주는 역할이다. 기존 sitemap.xml에 이미지 확장 네임스페이스를 추가하면 된다.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
    xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/posts/image-seo-guide</loc>
    <image:image>
      <image:loc>https://cdn.example.com/images/image-seo-checklist.webp</image:loc>
    </image:image>
  </url>
</urlset>

필수 태그는 , , , 네 가지다. 한 블록에 최대 1,000개의 이미지를 포함할 수 있다. CDN을 사용하는 경우 구글 서치콘솔에서 CDN 도메인 소유권도 별도로 확인해야 한다.

한 가지 주의할 점이 있다. , , 같은 추가 태그들은 구글 공식 문서 지원 목록에서 이미 제거된 상태다. 예전 가이드를 보면 이 태그들이 나오는데, 지금은 넣어도 의미 없다.

---

이해 단계, 크롤러가 이미지 내용을 파악할 수 있냐

alt 텍스트 — 핵심은 묘사, 키워드 나열은 역효과

구글 문서는 alt 텍스트를 "컴퓨터 비전 알고리즘과 함께 이미지 주제를 파악하는 데 사용된다"고 정의한다. AI가 이미지를 직접 분석하는데, 그 보조 정보로 쓰인다는 뜻이다.

나쁜 예: alt="SEO SEO최적화 블로그SEO 이미지SEO 최적화방법" — 키워드 스터핑이라 오히려 감점 요인이 된다.

좋은 예: alt="구글 서치콘솔 실적 보고서에서 이미지 검색유형 필터를 선택하는 화면" — 실제로 이미지에 보이는 것을 묘사한다.

장식용 이미지(버튼 아이콘, 구분선 등)는 alt=""로 비워두는 게 접근성과 SEO 모두에 맞는 처리다. 비워두는 것과 아예 생략하는 것은 다른데, alt 속성 자체를 빼면 일부 크롤러가 파일명을 텍스트로 읽어버릴 수 있어서 명시적으로 빈 값을 넣는 편이 낫다.

파일명 — 보조 신호지만 손이 크게 가지 않는다

구글은 파일명을 "가벼운 신호"로 본다. alt 텍스트보다 가중치는 낮지만, 업로드 전에 파일명을 영문 소문자+하이픈 형식으로 바꾸는 데 큰 수고가 드는 일도 아니다.

IMG_20260701.jpg → blog-image-seo-checklist-2026.jpg

이미지가 많은 블로그라면 리네임 배치 스크립트를 만들어두는 것도 방법이다. 관련 키워드를 파일명에 자연스럽게 녹이되, 하이픈으로 구분된 짧은 영어 구문이 가장 깔끔하다.

---

평가 단계, 크롤러가 이미지 품질을 판단할 수 있냐

포맷과 로딩 속도 — Core Web Vitals 경로

WebP는 2026년 기준 모든 주요 브라우저에서 지원된다. AVIF는 WebP 대비 25~50% 추가 파일 크기 절감이 가능하고, 두 포맷 모두 JPEG/PNG 대비 30~50% 파일 크기를 줄인다.

포맷이 직접 이미지 검색 순위에 영향을 주는 건 아니다. 다만 Core Web Vitals 중 LCP(Largest Contentful Paint)에 영향을 주고, LCP는 구글 순위 요소다. 간접 경로지만 무시할 수는 없다.

페이지 최상단 히어로 이미지에는 fetchpriority="high" 속성을, 스크롤 아래 이미지에는 loading="lazy" 속성을 붙이는 게 현재 권장 방식이다.

<!-- 히어로 이미지: 지연 로딩 하지 않음 -->
<img src="hero.webp" alt="..." fetchpriority="high">

<!-- 본문 하단 이미지: 지연 로딩 -->
<img src="content.webp" alt="..." loading="lazy">

ImageObject 구조화 데이터 — 자체사이트라면 챙겨볼 것

페이지의 대표 이미지를 primaryImageOfPage 속성이나 og:image 메타 태그로 명시하면 구글이 검색 결과에 이미지를 표시할 때 이를 참고한다. 리치 결과 자격을 갖추면 구글 이미지 검색에서 추가 정보가 함께 표시될 수 있다.

Discover에 이미지가 노출되려면 og:image로 지정된 이미지 너비가 최소 1,200px 이상이어야 한다.

자체사이트나 워드프레스(Yoast SEO 자동 생성)에서는 JSON-LD 형식으로 구조화 데이터를 삽입할 수 있다. 특히 레시피·제품·뉴스 기사처럼 구조화 데이터 스키마가 정의된 콘텐츠 유형은 ImageObject를 함께 넣으면 이미지 리치 결과(배지, 사이트명 표시 등) 적격 대상이 된다. 블로그 포스트라면 Article 스키마 안에 image 속성으로 포함시키는 방식이 가장 일반적이다.

---

플랫폼별 이미지 SEO 체크리스트

티스토리 — 할 수 있는 것과 없는 것

적용 가능

• alt 텍스트 에디터에서 수동 입력
• 업로드 전 파일명 영문 소문자+하이픈으로 변경
• WebP로 미리 변환 후 업로드 (squoosh.app 같은 외부 도구 활용)
• sitemap.xml 구글 서치콘솔 제출 (기본 페이지 사이트맵)

적용 불가

• 이미지 전용 Image Sitemap 생성 — 티스토리 플랫폼 자체가 미지원
• ImageObject 구조화 데이터 삽입 — HTML 헤더 편집 제한
• WebP 자동 변환

티스토리라면 발견 단계(크롤 가능성)와 이해 단계(alt 텍스트·파일명) 세 가지에 집중하는 게 현실적이다.

워드프레스 🔧

적용 가능

• Yoast SEO: ImageObject 구조화 데이터 자동 생성, Image Sitemap 자동 생성
• Converter for Media 플러그인: WebP/AVIF 자동 변환 (서버의 GD 또는 Imagick 라이브러리 필요)
• alt 텍스트, 파일명, lazy loading 속성 직접 제어
• CDN 연동 후 Image Sitemap에 CDN URL 포함

Yoast SEO만 설치해도 이해 단계와 평가 단계의 주요 항목이 자동으로 처리된다. 자체 서버를 쓰는 워드프레스라면 3단계 전체를 챙길 수 있다.

자체사이트 (Next.js 등) — 완전한 제어

적용 가능 (모든 항목 직접 구현)

• Next.js 컴포넌트: WebP/AVIF 자동 변환, lazy loading 기본 적용, LCP 이미지 priority prop 지원
• JSON-LD로 ImageObject 구조화 데이터 직접 구현
• Image Sitemap 직접 생성 및 서치콘솔 제출
• fetchpriority 속성 세밀 조정

자체사이트는 제약이 없는 대신 직접 구현해야 하는 항목이 많다. Next.js를 쓴다면 컴포넌트가 WebP 변환과 lazy loading을 기본으로 처리해줘서 이 부분은 사실상 공짜다.

---

단계별로 막힌 곳부터, 뭐부터 시작할까

이미지 SEO는 플랫폼 제약을 감안해서, 막힌 단계부터 푸는 순서로 접근하는 게 맞다.

발견 단계 (공통 필수)

1. 태그로 삽입 확인 — CSS 배경이미지 여부 점검
2. CDN 이미지가 있다면 Image Sitemap 제출 (워드프레스·자체사이트)

이해 단계 (공통 필수)

1. alt 텍스트 실제 묘사로 작성 — 키워드 나열 금지
2. 업로드 전 파일명 영문 소문자+하이픈 형식 변경

평가 단계 (자체사이트·워드프레스 추가)

1. LCP 이미지(페이지 최상단 대표 이미지)에 lazy loading 미적용, 나머지에 loading="lazy" 추가
2. WebP/AVIF 자동 변환 설정
3. ImageObject 구조화 데이터 삽입

발견 단계가 막혀 있으면 이해·평가 단계를 아무리 공들여도 효과가 없다. 3번 alt 텍스트와 4번 파일명은 오늘 당장 시작할 수 있고, Image Sitemap과 구조화 데이터는 플랫폼 이동이나 자체사이트 구축 때 함께 챙기면 충분하다. 처음부터 모든 항목을 동시에 건드리려 하면 오히려 우선순위가 흐려진다. 각 단계를 순서대로 점검하면서, 지금 사용 중인 플랫폼에서 통제 가능한 항목에 집중하는 게 실질적으로 빠른 길이다.

참고자료

• https://developers.google.com/search/docs/appearance/google-images
• https://developers.google.com/search/docs/crawling-indexing/sitemaps/image-sitemaps
• https://support.google.com/webmasters/answer/7576553