Article 구조화 데이터로 저자·발행일·이미지 마크업하기

게시 2026.07.15 · 약 6분 분량

핵심 요약 구글 공식 문서 기준 Article 구조화 데이터에는 필수 속성이 없다. JSON-LD로 headline·author·datePublished·image를 채우고 리치 결과 테스트로 검증하는 방법을 개발자 눈높이로 정리했다.

Article 구조화 데이터가 하는 일
필수 속성은 정말 없나?
저자·날짜·이미지를 채우는 규칙
마크업이 제대로 됐는지 어떻게 확인하나?
흔한 함정: 마크업과 화면이 어긋날 때

Article 구조화 데이터(structured data, 검색 엔진이 페이지 내용을 기계가 읽을 수 있게 덧붙이는 정보)는 블로그 글이나 뉴스 기사에 제목·저자·발행일·이미지 같은 정보를 명시해 구글이 페이지를 더 정확히 이해하도록 돕는다. 2026년 7월 기준 구글 검색 센터 공식 문서에 따르면 이 마크업에는 반드시 넣어야 하는 필수 속성이 없다. 대신 콘텐츠에 해당하는 권장 속성을 최대한 채우는 방식이다. 이 글은 일반 웹페이지에 JSON-LD(스크립트 태그 안에 넣어 구조화 데이터를 표현하는 형식)로 Article·NewsArticle·BlogPosting을 넣으려는 개발자를 대상으로 하며, AMP나 뉴스 발행사 전용 요건은 다루지 않는다.

Article 구조화 데이터가 하는 일

구조화 데이터는 사람이 보는 HTML 본문과 별개로, 검색 봇에게 “이 글의 제목은 무엇이고 저자는 누구이며 언제 발행됐다”를 구조화된 형태로 알려 주는 코드 조각이다. 화면 표시는 그대로 두고 봇이 참고할 메타데이터만 얹는 셈이다. 구글은 이 정보를 페이지 이해와 검색 결과 표현(제목 링크, 날짜 표기 등)에 활용한다.

Article 마크업에 쓸 수 있는 schema.org 유형은 세 가지다. 구글 공식 문서는 범용 기사에 Article, 뉴스 보도에 NewsArticle, 블로그 글에 BlogPosting을 쓰도록 안내한다. 셋은 상속 관계라 속성 구성이 사실상 같으니, 글 성격에 맞는 @type 하나만 고르면 된다. schema.org의 Article 유형 정의에서 전체 속성 목록을 볼 수 있다.

@type	용도
Article	범용 기사·칼럼
NewsArticle	뉴스·시사 보도
BlogPosting	블로그·개인 게시글

필수 속성은 정말 없나?

없다. 구글 검색 센터의 Article 구조화 데이터 문서는 “필수 속성은 없다(There are no required properties)”고 명시하고, 콘텐츠에 해당하는 속성을 넣으라고 안내한다. 다만 리치 결과(검색 결과에 이미지·날짜 등이 함께 노출되는 향상된 표시)로 이어질 가능성을 높이려면 권장 속성을 성실히 채우는 편이 낫다.

구글이 권장하는 핵심 속성은 다섯 가지다.

headline — 글 제목
image — 대표 이미지 URL 또는 ImageObject
author — 저자, Person 또는 Organization
datePublished — 최초 발행 일시
dateModified — 마지막 수정 일시

필수는 아니지만 실무에서는 headline·image·author·datePublished 네 가지를 기본으로 빠짐없이 넣는다. 검색 결과에 제목·이미지·날짜가 함께 노출되는 데 직접 관계되는 속성이기 때문이다.

저자·날짜·이미지를 채우는 규칙

속성마다 구글이 안내하는 세부 규칙이 있다. 실수가 잦은 세 가지를 짚는다.

저자(author)

구글 공식 문서는 author.name에 저자 이름만 넣으라고 안내한다. 직함·수식어·발행사 이름을 함께 적으면 안 된다(“편집장 홍길동”이 아니라 “홍길동”). 저자가 여럿이면 이름을 한 문자열에 몰아넣지 말고 각각을 배열의 별도 항목으로 담는다. 페이지에 저자로 표시된 사람은 전원 마크업에 포함해야 한다는 점도 구글이 명시한다. 저자 소개 페이지가 있다면 url이나 sameAs에 그 주소를 넣어 신원을 분명히 하는 것을 권장한다. E-E-A-T(경험·전문성·권위·신뢰) 신호로도 이어진다.

발행일과 수정일

datePublished는 글을 처음 낸 날짜, dateModified는 마지막으로 실질 수정한 날짜다. 오타 교정 같은 사소한 변경으로 발행일을 바꾸지 않는다. 구글은 두 날짜를 ISO 8601 형식(예: 2026-07-15T08:00:00+09:00)으로 쓰고 타임존을 함께 넣기를 권장한다. 구글은 타임존을 생략하면 Googlebot의 타임존이 기본값으로 적용된다고 안내하므로, 한국 시간이면 +09:00을 명시하는 편이 안전하다.

이미지(image)

구글 공식 문서는 대표 이미지를 여러 장, 16:9·4:3·1:1 세 가지 가로세로 비율로 제공하도록 권장한다. 이미지 URL은 구글이 크롤링·색인할 수 있는 공개 주소여야 한다.

아래는 BlogPosting 유형의 최소 예시다. JSON-LD는 <script type="application/ld+json"> 블록에 넣어 페이지 <head>나 <body>에 삽입한다.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "BlogPosting",
 "headline": "Article 구조화 데이터 적용기",
 "image": [
 "https://example.com/1x1.jpg",
 "https://example.com/4x3.jpg",
 "https://example.com/16x9.jpg"
 ],
 "author": [{
 "@type": "Person",
 "name": "홍길동",
 "url": "https://example.com/authors/hong"
 }],
 "datePublished": "2026-07-15T08:00:00+09:00",
 "dateModified": "2026-07-15T09:20:00+09:00"
}
</script>

마크업이 제대로 됐는지 어떻게 확인하나?

가장 먼저 쓰는 도구는 구글 리치 결과 테스트다. 리치 결과 테스트에 페이지 URL이나 코드 조각을 넣으면 어떤 리치 결과가 생성될 수 있는지와 오류를 함께 보여 준다. 배포 전 코드 점검에 먼저 쓰는 도구다. 구글에 특화되지 않은 일반 schema.org 문법 검사는 스키마 마크업 검사기(Schema Markup Validator, validator.schema.org)를 쓴다. 구글 안내에 따르면 이 검사기는 2021년 4월 옛 구조화 데이터 테스트 도구를 대체해 schema.org로 이관됐다.

사이트가 이미 검색에 노출된 뒤에는 구글 서치 콘솔의 향상(Enhancements) 보고서에서 실제 색인된 페이지의 구조화 데이터 오류·경고를 모아 볼 수 있다. 테스트 도구가 개별 페이지의 사전 점검이라면, 서치 콘솔은 사이트 전체의 사후 모니터링에 가깝다.

흔한 함정: 마크업과 화면이 어긋날 때

구글의 구조화 데이터 일반 가이드라인은 마크업 내용이 페이지에 실제로 보이는 내용과 일치해야 한다고 규정한다. 화면에 없는 저자를 마크업에만 넣거나 본문과 다른 날짜를 적으면 리치 결과 대상에서 빠지거나 수동 조치를 받을 수 있다. author에 적은 이름은 페이지 어딘가에 바이라인으로 실제 노출돼 있어야 한다.

또 자주 헷갈리는 지점이 datePublished와 dateModified의 구분이다. 아래 기준으로 나누면 된다.

속성	의미	바꾸는 시점
datePublished	최초 발행 일시	발행 후 고정, 사소한 편집엔 그대로
dateModified	마지막 실질 수정 일시	섹션 추가·결론 재작성 등 큰 변경 때