이미지 alt 속성과 JSON-LD 구조화 데이터는 크롤러가 페이지의 시각적 정보와 엔티티 구조를 해석하는 핵심 신호다. Google 이미지 크롤러는 alt 텍스트가 없으면 파일명과 주변 텍스트만으로 이미지를 추론하고, 구조화 데이터가 누락된 페이지는 Rich Results 자격을 잃는 것은 물론 ChatGPT Search·Perplexity 같은 AI 답변 엔진이 엔티티를 잘못 해석하거나 인용을 생략할 가능성이 높다. 두 항목은 WCAG 2.1 접근성(1.1.1 Non-text Content), 전통 SEO, AEO 전반에 동시에 영향을 미치므로 배포 전 체계적 점검이 필요하다.
이미지 alt 텍스트 작동 원리
Googlebot이 이미지를 처리하는 신호 우선순위는 alt 텍스트 → 주변 텍스트 문맥 → 파일명 → 페이지 제목 순이다. alt가 비어 있거나 누락되면 파일명이 신호를 대체하므로, IMG_2034.jpg처럼 의미 없는 파일명은 이중으로 불이익을 준다. AI 크롤러도 HTML 파싱 단계에서 alt 텍스트를 이미지의 텍스트 표현으로 소비하며, WCAG 2.1 기준 1.1.1은 장식용 이미지에 alt=""(빈 문자열 명시)를, 콘텐츠 이미지에는 실질적 텍스트 대안을 요구한다.
alt 텍스트 구현 체크리스트
- 콘텐츠 이미지에 구체적 텍스트 기술
왜: 크롤러는 alt 없이 이미지를 텍스트로 인덱싱하지 못한다.
어떻게: "전기 이미지" 대신 "200A 분전함 주차단기 교체 전후 비교"처럼 행위·수치·맥락을 25단어 이하로 포함. - 장식용 이미지는 alt=""로 명시, 속성 자체를 누락하지 말 것
왜: 속성 누락 시 스크린리더가 파일명을 그대로 읽는다.
어떻게: 배경 역할이라면 CSS background-image로 전환하거나alt=""로 명시. - 링크 이미지의 alt은 링크 목적지 기술
왜: 링크 안에 텍스트가 없으면 Google은 alt를 앵커 텍스트 신호로 사용한다.
어떻게: "로고 이미지"가 아니라 "홈 페이지로 이동" 형태로 목적지 명시. - 파일명을 의미 있는 kebab-case로 설정
왜: alt가 누락되거나 빈 문자열일 때 파일명이 폴백 신호가 된다.
어떻게:img2034.jpg→circuit-breaker-200a-installation.jpg
alt 텍스트 케이스 비교
| 케이스 | 예시 | 크롤러 처리 | 권장 |
|---|---|---|---|
| alt 속성 누락 | <img src="panel.jpg"> |
파일명으로만 추론, WCAG 위반 | X |
| 빈 문자열 (장식용) | alt="" |
장식으로 처리, 색인 제외 | O |
| 키워드 스터핑 | alt="전기 전기공사 전기배선 전기설치" |
스팸 신호, 랭킹 불이익 가능 | X |
| 간결한 기술 | alt="200A 분전함 차단기 교체 작업" |
이미지 콘텐츠 정확히 인덱싱 | O |
JSON-LD 구조화 데이터 구현 체크리스트
Google은 JSON-LD, Microdata, RDFa 세 포맷을 지원하지만 JSON-LD를 공식 권장한다. HTML 마크업과 분리되어 유지보수가 쉽고, Next.js의 next/head 또는 App Router의 generateMetadata로 동적 삽입해도 Googlebot이 렌더링 후 파싱한다.
- @context와 @type 필수 선언
왜: 네임스페이스와 타입 없이는 파서가 구조를 인식하지 못한다.
어떻게:"@context": "https://schema.org"와"@type": "Article"필수. - datePublished·dateModified를 ISO 8601 전체 형식으로 작성
왜: Google은 날짜 형식이 다르면 Rich Results에서 해당 필드를 무시한다.
어떻게:"2026-06-18T10:00:00+09:00"처럼 시각과 타임존 오프셋까지 포함. - author 객체에 @type 명시
왜: 이름 문자열만으로는 Person 엔티티로 해석되지 않을 수 있다.
어떻게:{"@type": "Person", "name": "홍길동", "url": "..."}구조 사용. - image 속성에 1200×630px 이상 ImageObject 제공
왜: Google Discover와 일부 Rich Results의 최소 해상도 요건이다.
어떻게:width와height를 ImageObject 내에 명시하면 크롤러가 다운로드 없이 크기를 확인할 수 있다. - 복수 스키마는 @graph 배열로 통합
왜: 같은 @type을 여러 블록에 분산하면 파서가 각각을 불완전한 객체로 인식할 수 있다.
어떻게: Article과 BreadcrumbList를"@graph": [...]하나로 묶는다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"@id": "https://example.com/blog/circuit-breaker-guide#article",
"headline": "200A 분전함 차단기 교체 가이드",
"description": "전기안전 기준에 따른 분전함 차단기 교체 절차 안내",
"image": {
"@type": "ImageObject",
"url": "https://example.com/images/circuit-breaker-200a-installation.jpg",
"width": 1200,
"height": 630
},
"datePublished": "2026-06-01T09:00:00+09:00",
"dateModified": "2026-06-18T10:00:00+09:00",
"author": {
"@type": "Person",
"name": "이전기",
"url": "https://example.com/authors/lee-jeongi"
},
"publisher": {
"@type": "Organization",
"name": "전기전문 블로그",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png",
"width": 200,
"height": 60
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/blog/circuit-breaker-guide"
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "홈",
"item": "https://example.com" },
{ "@type": "ListItem", "position": 2, "name": "블로그",
"item": "https://example.com/blog" },
{ "@type": "ListItem", "position": 3, "name": "차단기 교체 가이드",
"item": "https://example.com/blog/circuit-breaker-guide" }
]
}
]
}
</script>
검증 및 측정
- Google Rich Results Test — URL 또는 코드 스니펫을 입력하면 파싱 결과와 Rich Results 자격 여부를 즉시 확인.
왜: 로컬에서는 정상이어도 배포 후 렌더링 타이밍 문제로 JSON-LD가 누락될 수 있다. - Schema Markup Validator (validator.schema.org) — schema.org 공식 검증기. Rich Results Test보다 타입 체계를 더 엄격하게 검사하므로 필수 속성 누락 경고를 기준으로 수정한다.
- Google Search Console 서치 결과 강화 보고서 — 실제 색인된 페이지 기준으로 스키마 오류·경고를 집계한다. 검증기를 통과해도 GSC에서 오류가 보고되는 사례가 있다.
- Lighthouse 접근성 감사 (
image-alt항목) — alt 누락 이미지를 자동 탐지한다.
어떻게: CI 파이프라인에lighthouse --only-categories=accessibility를 추가해 배포마다 자동 점검.
흔한 오해: alt에 키워드를 많이 넣을수록 SEO에 유리하다
alt="전기 전기공사 전기배선 전기설치 전기패널 분전함" 형태의 키워드 나열은 Google Webmaster Guidelines에서 "피해야 할 관행"으로 명시된 스팸 신호다. 스크린리더 사용자에게는 무의미한 단어 목록이 읽히며 접근성을 직접적으로 해친다. 올바른 접근은 이미지가 실제로 전달하는 내용을 자연어로 기술하는 것이다. 검색 의도와 관련된 용어가 자연스러운 서술 안에 포함되는 것과, 의도적으로 키워드를 나열하는 것은 크롤러가 구분한다.
FAQ 1. FAQPage 스키마를 적용했는데 검색 결과에 FAQ가 전혀 표시되지 않는다. 스키마 오류인가?
스키마 오류가 아닐 가능성이 높다. Google은 2023년 8월부터 FAQPage Rich Results 노출을 대폭 축소해, 현재는 권위 있는 정부·의료 사이트에 한해 제한적으로 표시한다. 일반 콘텐츠 사이트에는 스키마가 유효해도 SERP에 표시되지 않는 것이 정책 기본값이다. HowTo 스키마도 같은 시점에 데스크톱 노출에서 제거됐다. 단, FAQPage 스키마는 AI 답변 엔진이 Q&A 구조를 인식하는 데 여전히 유효하게 작동한다는 점은 실무적으로 고려할 가치가 있다(Google의 공식 확인은 없음, 추정).
FAQ 2. 같은 페이지에 JSON-LD <script> 블록을 여러 개 배치해도 파서가 모두 읽는가?
기술적으로 가능하다. Google 파서는 같은 페이지의 여러 <script type="application/ld+json"> 블록을 모두 읽는다. 다만 같은 @type을 여러 블록에 분산하면 필수 속성이 각각 분리돼 파서가 개별 블록을 불완전한 객체로 판단할 수 있다. 권장 방식은 @graph 배열 하나에 모든 스키마를 통합하는 것이다. Article과 BreadcrumbList처럼 타입이 다른 경우에도 @graph로 묶으면 파서 신뢰도와 유지보수 양쪽에서 유리하다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.