Article·BlogPosting 스키마 가이드

Article·BlogPosting 스키마는 블로그 글이나 기사 페이지의 제목, 날짜, 저자, 대표 이미지를 검색엔진이 읽을 수 있는 코드로 정리해주는 구조화 데이터다. 그런데 정작 구글 공식 문서를 직접 열어보면 다소 의외의 문장이 나온다. "필수 속성은 없다(There are no required properties)"는 문장이다.

많은 실무자가 헤드라인이나 발행일은 당연히 필수라고 생각하지만, 구글은 이 모두를 "권장" 속성으로 분류한다. 이 글은 이 오해부터 바로잡고, Article·NewsArticle·BlogPosting 중 무엇을 골라야 하는지, 권장 속성을 어디까지 채워야 실제 효과가 나는지, 저자(author) 표기에서 흔히 나오는 실수까지 예시 중심으로 정리한다.

블로그 하나를 운영하더라도 글이 수십, 수백 편으로 늘어나면 스키마 하나하나를 손으로 점검하기 어려워진다. 날짜 형식, 저자 표기, 이미지 배열처럼 반복되는 규칙 몇 가지만 정확히 익혀두면, 새 글을 쓸 때마다 같은 실수를 반복하지 않을 수 있다. 이 글에서 다루는 예시는 실제 배포 중인 코드와 구글 공식 문서 표현을 기준으로 정리했다.

이 글의 핵심은 다음과 같다.

• 구글 공식 문서는 "필수 속성이 없다"고 명시한다. 대신 headline·image·datePublished·dateModified·author 다섯 가지를 권장 속성으로 최대한 채워야 한다.
• 일반 블로그 글은 BlogPosting, 언론사 뉴스는 NewsArticle, 애매하면 상위 타입인 Article을 쓴다.
• image는 문자열 하나가 아니라 배열로, 16:9·4:3·1:1 세 비율을 함께 등록하는 것이 안전하다.
• author.name에는 이름만 넣어야 한다. "운영팀 김철수 팀장"처럼 직함·소속을 섞으면 값이 지저분해진다.
• 이 마크업이 있다고 특정 리치 결과가 즉시 뜨는 것은 아니다. 구글이 제목·이미지·날짜를 더 정확히 이해하도록 돕는 배경 정보에 가깝다.

왜 굳이 Article 스키마를 넣어야 하나

리치 결과 하나 안 뜨는데 이걸 왜 채워야 하나 싶을 수 있다. 실제로 Article 계열 스키마는 Review처럼 별점을 화면에 그려주거나 FAQ처럼 아코디언을 만들어주는 타입이 아니다. 그런데도 이 스키마를 채워야 하는 이유는 세 가지로 정리된다.

첫째, 검색엔진이 페이지를 오해할 여지를 줄인다. 마크업이 없으면 구글은 본문 텍스트에서 제목·날짜·저자를 추정해야 하는데, 디자인이 복잡한 페이지일수록 추정이 틀릴 가능성이 커진다. 둘째, 구글은 Google News의 톱 스토리 같은 뉴스 기능에 마크업이 필수는 아니라고 밝히면서도, Article을 넣으면 콘텐츠 성격을 "더 명시적으로" 전달할 수 있다고 안내한다. 셋째, 챗GPT·제미나이·퍼플렉시티 같은 AI 검색 서비스가 콘텐츠를 인용할 때도, 본문 산문보다 구조화된 사실(제목·날짜·저자)을 더 안정적으로 파싱한다는 점이 기술적으로 자연스럽다.

스키마를 넣는다고 순위가 즉시 오르지는 않는다. 다만 검색엔진과 AI가 같은 페이지를 두고 헷갈릴 이유를 하나씩 줄여주는 작업이라고 이해하는 편이 정확하다.

Article과 BlogPosting, 무엇이 다른가

Article은 스키마닷오알지(schema.org)가 정의한 상위 타입이고, BlogPosting과 NewsArticle은 그 아래에 속한 세부 타입이다. 셋 다 구글이 공식적으로 지원하는 타입이라, 어느 것을 골라도 아예 인식되지 않는 일은 없다. 문제는 정확도다.

일반적인 개인·기업 블로그, 칼럼, 인사이트 글이라면 BlogPosting이 가장 정확하다. 신문사·통신사처럼 보도 성격이 뚜렷한 기사라면 NewsArticle을 쓴다. 콘텐츠 성격이 둘 다 애매하거나 여러 형식이 섞여 있다면 상위 타입인 Article을 범용으로 써도 무방하다.

콘텐츠 유형	권장 타입	비고
개인·기업 블로그, 칼럼, 가이드 글	BlogPosting	가장 흔한 선택
언론사·통신사 보도 기사	NewsArticle	속보성·시사성이 뚜렷할 때
인터뷰, 사례 소개, 실무 후기	BlogPosting	블로그 형식이면 동일하게 적용
사내 공지, 보도자료 성격 글	Article 또는 NewsArticle	발행 주체·형식에 따라 판단
성격이 애매하거나 혼합된 콘텐츠	Article	상위 타입, 무난한 대안

실무에서는 세 타입 중 어느 것을 고르든 구글이 리치 결과를 다르게 취급한다는 근거는 크지 않다. 다만 schema.org 표준을 정확히 지키는 것 자체가 콘텐츠 성격을 명확히 전달하는 일이고, 향후 구글이나 다른 AI 검색 서비스가 타입별로 기능을 세분화할 가능성에도 대비가 된다. 지금 당장의 리치 결과보다 정확한 타입 선택이 장기적으로 유리하다고 보는 것이 맞다.

헷갈릴 때는 상위 타입 Article을 쓰는 것이 안전하다. 잘못된 세부 타입을 고르는 것보다, 정확한 상위 타입 하나를 쓰는 편이 낫다.

한 번 고른 타입은 특별한 이유 없이 자주 바꾸지 않는 것도 중요하다. 사이트 전체에 BlogPosting을 쓰다가 일부 글만 Article로 바꾸는 식으로 기준이 왔다 갔다 하면, 검색엔진 입장에서도 사이트의 콘텐츠 분류 기준을 다시 학습해야 한다. 처음 기준을 정했다면 사이트 전체에 일관되게 적용하고, 콘텐츠 성격이 명백히 다른 섹션(예: 뉴스 코너와 일반 블로그가 공존하는 사이트)에서만 타입을 구분하는 것이 실무적으로 깔끔하다.

주의할 점은 Article 계열과 자주 헷갈리는 다른 타입들이다. 단계별 설명이 중심인 글이라면 Article 대신 HowTo가 더 정확할 수 있고, 상품 소개가 중심인 페이지라면 Product가 맞다. 콘텐츠의 본질이 "이야기·정보 전달"이면 Article 계열, "절차·단계 안내"면 HowTo, "판매 대상"이면 Product라고 구분하면 헷갈릴 일이 줄어든다. 한 페이지에 여러 타입을 무리하게 섞기보다, 페이지의 주된 목적 하나를 기준으로 타입을 고르는 것이 원칙이다.

구글이 말하는 필수 속성은 정말 있을까

결론부터 말하면 구글 공식 문서 원문은 "필수 속성이 없다, 콘텐츠에 해당하는 속성을 추가하라"고 명시한다. LocalBusiness나 Product처럼 필수 속성이 명확히 정해진 타입과는 다르다. 그렇다고 아무것도 채우지 않아도 된다는 뜻은 아니다. 채울수록 구글이 콘텐츠를 더 정확히 이해한다는 것이 공식 문서의 취지다.

구글이 실제로 안내하는 권장 속성은 다음 다섯 가지로 정리할 수 있다.

속성	설명
headline	글 제목. 기기에 따라 길면 잘릴 수 있어 간결하게
image	대표 이미지. 문자열 하나가 아니라 배열 권장
datePublished	최초 발행 일시(ISO 8601 형식)
dateModified	가장 최근 수정 일시(ISO 8601 형식)
author	저자 정보. Person 또는 Organization 타입, name과 url 포함 권장

여기서 자주 나오는 오해가 하나 있다. "필수가 없다"는 문장을 "안 넣어도 순위에 전혀 영향이 없다"로 확대 해석하는 경우다. 정확히는 구글이 리치 결과 자격을 판단할 때 하나의 속성 누락만으로 전체를 탈락시키지 않는다는 뜻에 가깝다. 다만 headline·datePublished처럼 검색 결과 화면 구성에 직접 쓰이는 값이 비어 있으면, 구글이 본문에서 임의로 추정해야 하므로 정확도가 떨어질 수 있다.

"필수 속성 없음"은 "아무거나 넣어도 된다"가 아니라 "해당하는 것부터 최대한 채워라"는 뜻으로 읽어야 한다.

왜 구글은 다른 타입과 달리 Article에는 필수 속성을 두지 않았을까. LocalBusiness는 오프라인 매장이라는 명확한 실체가 있어 이름과 주소만 있어도 최소한의 정보가 성립한다. 반면 Article은 블로그 글, 뉴스 기사, 사내 공지, 개인 일기형 콘텐츠까지 폭넓게 아우르는 타입이라, 콘텐츠마다 저자나 발행일이 없는 경우도 흔하다. 형식이 다양한 콘텐츠를 하나의 타입으로 포괄하려다 보니, 필수 대신 권장이라는 유연한 기준을 택한 것으로 보는 것이 합리적이다.

이 유연함을 "안 채워도 무방하다"는 신호로 오해하지 않는 것이 중요하다. 실무에서는 headline·datePublished·image 세 가지만이라도 빠짐없이 채우는 것을 최소 기준으로 삼고, 여력이 되면 dateModified와 author까지 채우는 순서로 접근하는 편이 현실적이다.

이미지 속성은 어떻게 채워야 안전한가

image 속성에서 가장 흔한 실수는 썸네일 이미지 한 장만 문자열로 넣는 것이다. 구글 가이드라인은 이미지를 배열로 등록하고, 16:9, 4:3, 1:1 세 가지 비율을 함께 제공하는 것을 권장한다. 검색 결과가 노출되는 화면(데스크톱, 모바일, 카드형 등)마다 요구하는 비율이 다르기 때문이다.

해상도 기준도 명시돼 있다. 가로×세로 픽셀 수를 곱한 값이 최소 5만 픽셀 이상이어야 한다는 것이 구글의 권장 기준이다. 예를 들어 1200×630 크기 이미지라면 곱한 값이 75만 6천이라 기준을 크게 넘는다. 반대로 폭이 지나치게 좁은 썸네일은 기준 미달일 수 있으니 실제 배포 전에 크기를 확인해야 한다.

• 이미지는 배열로: "image": ["이미지1.jpg", "이미지2.jpg"]
• 비율은 16:9, 4:3, 1:1 세 가지를 함께 등록하는 것이 이상적
• 가로×세로 곱이 5만 픽셀 이상이어야 한다
• 이미지 URL은 반드시 크롤링·색인 가능한 상태여야 한다(로그인 필요, robots 차단 금지)

이미지 하나만 있어도 마크업 자체는 동작한다. 다만 여러 비율을 함께 제공해야 다양한 화면 형태에서 안정적으로 노출될 가능성이 커진다. 코드로 보면 차이가 더 분명하다. 아래는 같은 글에 이미지를 등록하는 나쁜 예와 좋은 예다.

"image": "thumb.jpg"

"image": [
  "https://example.com/images/post/16x9.jpg",
  "https://example.com/images/post/4x3.jpg",
  "https://example.com/images/post/1x1.jpg"
]

첫 번째 예는 상대 경로 문자열 하나뿐이라 구글이 실제 이미지 위치를 찾지 못할 위험이 있고, 비율도 하나뿐이다. 두 번째 예는 절대 경로(https://로 시작하는 전체 주소)로 작성한 이미지 세 장을 배열로 제공한다. 이미지 URL은 항상 절대 경로로 쓰는 것이 안전하다 — 상대 경로는 페이지 구조가 바뀌면 깨지기 쉽다.

author를 쓸 때 자주 하는 실수

저자 정보는 Article 계열 스키마에서 가장 실수가 잦은 속성이다. 구글 가이드라인은 author.name에는 이름만 넣고, 직함이나 소속은 별도로 다루지 말라고 안내한다. "운영팀 김철수 팀장"처럼 한 문자열에 여러 정보를 섞으면 검색엔진이 이름을 정확히 인식하기 어렵다.

나쁜 예(존재하지 않는 타입, 저자에 직함 혼입, 이미지가 문자열 하나)

{
  "@context": "https://schema.org",
  "@type": "Post",
  "headline": "홈페이지 제작 비용 완벽 정리",
  "author": "운영팀 김철수 팀장",
  "image": "thumb.jpg"
}

좋은 예(정확한 타입, 날짜 두 개, 이름만 담은 저자)

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "홈페이지 제작 비용 완벽 정리",
  "datePublished": "2026-09-17",
  "dateModified": "2026-09-17",
  "image": ["/images/cost-guide/cover.png"],
  "author": {
    "@type": "Person",
    "name": "김철수",
    "url": "https://example.com/about"
  }
}

나쁜 예의 문제는 세 가지다. "Post"는 schema.org에 정의된 타입이 아니라서 인식되지 않는다. 저자 이름에 직함이 섞여 값 자체가 지저분하다. 이미지가 배열이 아닌 문자열 하나뿐이라 다양한 화면 비율에 대응하기 어렵다.

author는 Person 타입만 되는 것이 아니다. 회사·팀 명의로 글을 발행한다면 "@type": "Organization"을 써도 된다. 저자가 여러 명이라면 하나의 문자열에 이름을 나열하지 말고, author 필드 자체를 배열로 만들어 각각 별도 객체로 넣는 것이 정확하다. 동명이인과 헷갈릴 수 있는 이름이라면 url이나 sameAs로 저자를 식별할 수 있는 링크를 함께 넣는 것이 좋다.

공동 집필이나 감수자가 있는 글이라면 아래처럼 배열로 넣는다.

"author": [
  { "@type": "Person", "name": "김철수", "url": "https://example.com/about/kim" },
  { "@type": "Person", "name": "이영희", "url": "https://example.com/about/lee" }
]

동명이인이 많은 흔한 이름이거나, 필명을 따로 쓰는 저자라면 sameAs로 소셜 프로필이나 프로필 페이지를 연결해두는 것도 방법이다.

"author": {
  "@type": "Person",
  "name": "김철수",
  "sameAs": "https://www.linkedin.com/in/example"
}

이루웹 블로그는 실제로 어떻게 자동 반영되나

이 원칙을 눈으로 확인하고 싶다면 지금 읽고 있는 이 블로그 자체가 실사례다. 이루웹 블로그는 글마다 코드를 새로 작성하지 않는다. 글 상단의 frontmatter(제목·설명·날짜·대표 이미지 등)만 정확히 채우면, 사이트 코드가 이 값을 그대로 읽어 BlogPosting 스키마를 자동으로 생성한다.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "글 제목(frontmatter title)",
  "description": "글 설명(frontmatter description)",
  "datePublished": "발행일(frontmatter date)",
  "dateModified": "수정일(없으면 발행일과 동일)",
  "image": ["대표 이미지(frontmatter cover)"],
  "author": { "name": "이루웹" },
  "publisher": { "@id": ".../#organization" }
}

여기서 dateModified를 별도로 관리하지 않았다면 발행일과 같은 값을 넣는 방식을 쓴다. 수정 이력을 아직 추적하지 않는 초기 단계라면 이렇게 시작해도 문제가 없고, 실제로 글을 고친 시점부터 값을 갱신하면 된다. author는 개인 필명 대신 조직(이루웹) 이름을 그대로 사용하는데, 이는 앞서 설명한 것처럼 author에 Organization 타입을 쓰는 정상적인 방식이다.

글마다 스키마 코드를 손으로 작성하지 않아도, frontmatter를 정확히 채우는 습관 하나로 구조화 데이터가 자동으로 완성된다는 점이 이 구조의 핵심이다. 같은 글에는 BreadcrumbList 스키마도 함께 자동 반영되는데, 탐색경로 구조화 데이터를 더 깊이 알고 싶다면 브레드크럼 완벽 가이드에서 확인할 수 있다.

위 코드에는 구글이 명시적으로 권장하지 않는 속성도 몇 개 섞여 있다. mainEntityOfPage는 같은 내용이 여러 주소로 존재할 때 "이 페이지가 대표 주소"라는 점을 밝혀주고, inLanguage는 글의 언어가 한국어라는 사실을 명확히 알려준다. 필수도 아니고 다섯 가지 핵심 권장 속성에도 없지만, 실무에서는 함께 넣어두면 손해 볼 것이 없는 보조 속성으로 취급하면 된다.

publisher 속성은 꼭 필요할까

publisher도 자주 보이지만 정작 구글의 최신 Article 가이드에서는 핵심 권장 속성으로 따로 안내하지 않는 속성이다. 그런데도 실무에서 여전히 폭넓게 쓰이는 이유는 과거 이력과 관련이 있다. 한때 AMP 기반 Top stories 기능이 publisher.logo 같은 세부 속성까지 요구하던 시절이 있었고, 그 관행이 지금도 다양한 SEO 플러그인과 템플릿에 기본값으로 남아 있다.

지금 기준으로는 publisher를 넣지 않았다고 오류로 처리되지는 않는다. 다만 사이트를 운영하는 주체(회사·브랜드)를 명확히 밝혀 둔다는 의미에서는 여전히 채워둘 가치가 있다. 이루웹 블로그도 앞서 본 예시처럼 publisher에 사이트 운영 조직 정보를 연결해두는 방식을 쓴다.

"publisher": {
  "@type": "Organization",
  "name": "OO스튜디오",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  }
}

logo까지 넣는 과거 관행은 AMP 시절의 흔적이지만, 브랜드 로고 이미지를 구조화된 형태로 한 번 더 명시해둔다는 점에서 지금도 나쁘지 않은 습관이다. 새로 스키마를 설계한다면 다섯 가지 핵심 권장 속성을 먼저 채우고, 여력이 있을 때 publisher·mainEntityOfPage·inLanguage 같은 보조 속성을 추가하는 순서를 권한다.

datePublished·dateModified 형식, 이렇게 자주 틀린다

날짜 속성에서 가장 흔한 실수는 형식을 사람이 읽는 문장으로 쓰는 것이다. "2026년 9월 17일"이나 "어제 발행"처럼 자연어로 쓰면 구글이 정확한 날짜로 해석하지 못할 위험이 크다. 구글이 요구하는 형식은 ISO 8601이다.

"datePublished": "2026-09-17"

"datePublished": "2026-09-17T10:00:00+09:00"

두 표기 모두 문법적으로는 인정되지만, 시간과 시간대(timezone)까지 포함한 두 번째 형식이 더 정확하다. 하루에 여러 번 글을 발행하는 사이트이거나, 발행 시각이 순위·노출 타이밍에 영향을 줄 수 있는 뉴스성 콘텐츠라면 시간 정보까지 넣는 것이 안전하다. 반대로 날짜만 있어도 형식 자체는 오류로 처리되지 않으니, 콘텐츠 성격에 맞게 선택하면 된다.

dateModified를 datePublished보다 이전 날짜로 넣는 실수도 종종 나온다. 수정일은 항상 발행일과 같거나 그 이후여야 논리적으로 맞다.

네이버 블로그에도 이 스키마가 필요한가

결론부터 말하면 아니다. Article·BlogPosting 같은 schema.org 마크업은 직접 <head> 코드를 편집할 수 있는 사이트(워드프레스, 카페24·아임웹 같은 빌더, 이루웹처럼 자체 도메인으로 운영하는 홈페이지)에 해당하는 이야기다. 네이버 블로그(blog.naver.com)는 네이버가 자체 플랫폼 안에서 글의 제목·날짜·작성자를 이미 자동으로 인식하고 관리하기 때문에, 이용자가 별도로 schema.org 코드를 삽입할 방법 자체가 없다.

반대로 워드프레스나 카페24처럼 직접 코드를 다룰 수 있는 환경에서 운영하는 홈페이지형 블로그라면, 이 글에서 설명한 속성들을 정확히 채워 넣는 실익이 분명히 있다. 운영 중인 채널이 네이버 블로그인지, 자체 도메인 홈페이지인지에 따라 이 가이드가 적용되는 범위가 달라진다는 점을 먼저 확인하고 넘어가는 것이 좋다.

워드프레스·카페24·아임웹에서는 어떻게 넣나

직접 코드를 다룰 수 있는 워드프레스라면 Yoast SEO나 RankMath 같은 SEO 플러그인이 글 작성 화면의 제목·발췌문·대표 이미지·작성자 정보를 읽어 Article 계열 스키마를 자동 생성해준다. 별도로 JSON-LD를 손으로 작성할 필요가 거의 없다.

카페24·아임웹·식스샵 같은 국내 빌더는 상황이 다르다. 블로그 게시판 기능 자체에 스키마 자동 생성이 포함되지 않은 경우가 많다. 이럴 때는 빌더가 제공하는 "직접 코드 삽입" 위젯이나 <head> 편집 기능을 활용해 <script type="application/ld+json"> 형태로 직접 넣어야 한다. 코드를 넣을 수 없는 요금제라면, 최소한 화면에 보이는 제목·날짜·저자 정보를 명확한 텍스트로 정확히 표기해두는 것이 차선책이다.

이미 플러그인이나 빌더 기능으로 스키마가 생성되고 있는데도 정확한지 모르겠다면, 새로 만들기 전에 먼저 확인부터 하는 것이 순서다. 브라우저에서 글 페이지의 소스 보기를 열어 application/ld+json을 검색하면, 이미 어떤 값이 들어가 있는지 눈으로 확인할 수 있다. 값이 비어 있거나 어색한 텍스트가 들어가 있다면 그때 플러그인 설정이나 빌더의 작성자·대표 이미지 항목을 다시 채우면 된다.

JSON-LD 구조화 데이터 자체가 처음이라면 JSON-LD 쉽게 이해하기에서 기본 개념과 코드 작성법을 먼저 확인하는 것이 순서에 맞다.

발행 후 어떻게 검증하나

코드를 넣었다고 끝이 아니다. 문법이 맞아 보여도 실제로는 값이 누락되거나 인식되지 않는 경우가 흔하다. 검증은 두 단계로 나뉜다.

• 발행 전: 구글의 리치 결과 테스트 도구에 페이지 URL을 입력하거나 코드를 직접 붙여넣어 오류·경고가 없는지 확인한다.
• 발행 후: 서치 콘솔의 URL 검사 도구로 실제 배포된 페이지를 조회하면, 구글이 실제로 어떤 속성을 읽었는지 확인할 수 있다. 서치 콘솔 사용법이 낯설다면 구글 서치 콘솔 사용법을 먼저 참고하면 된다.

URL 검사 도구에서는 "페이지가 Google에 등록됨" 아래 감지된 구조화 데이터 항목을 펼쳐보면, headline·datePublished 같은 속성이 실제로 어떤 값으로 인식됐는지 하나씩 나열된다. 여기서 값이 비어 있거나 예상과 다르게 표시된다면, 코드 자체의 문법 오류보다는 값이 아예 빠져 있거나 다른 필드와 이름이 헷갈린 경우가 많다. 페이지를 수정한 직후라면 구글이 다시 크롤링할 때까지 시간이 걸릴 수 있으므로, 같은 날 바로 재검사 결과가 달라지지 않아도 조급해할 필요는 없다.

AI 검색 시대에 날짜·저자가 더 중요해진 이유

전통적인 구글 검색에서 Article 스키마는 주로 뉴스 기능이나 화면 표시와 관련된 배경 정보였다. AI 검색이 확산되면서 이 역할에 한 가지가 더 추가됐다 — 답변을 생성할 때 어느 콘텐츠를 인용할지 판단하는 신호로도 쓰일 가능성이다.

챗GPT·제미나이·퍼플렉시티 같은 서비스가 특정 주제에 답하며 출처를 인용할 때, "언제 작성됐는지"와 "누가 썼는지"가 명확한 콘텐츠일수록 신뢰할 만한 출처로 취급되기 쉽다. datePublished와 dateModified가 정확하면 오래된 정보와 최신 정보를 AI가 구분하는 데 도움이 되고, author가 명확하면 익명 콘텐츠보다 신뢰도를 더 쉽게 판단할 수 있다. 이 효과를 정량적으로 증명한 대규모 공개 연구는 아직 부족하지만, 구조화된 사실이 산문보다 기계가 파싱하기 쉽다는 점은 기술적으로 당연한 전제다.

오래된 글을 그대로 방치하지 말고, 정보가 바뀔 때마다 본문과 dateModified를 함께 갱신하는 습관이 AI 검색 시대에는 더 큰 의미를 가질 수 있다.

전체 예시로 한 번에 보기

지금까지 다룬 속성을 하나의 페이지에 모두 적용하면 아래와 같은 형태가 된다. 실제 페이지의 <head> 안에 이 코드를 통째로 넣으면 된다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "홈페이지 제작 비용 완벽 정리",
  "description": "유형별 실제 견적 기준과 예산 짜는 법을 정리했습니다.",
  "datePublished": "2026-09-17T10:00:00+09:00",
  "dateModified": "2026-09-17T10:00:00+09:00",
  "inLanguage": "ko-KR",
  "mainEntityOfPage": "https://example.com/blog/cost-guide",
  "image": [
    "https://example.com/images/cost-guide/16x9.jpg",
    "https://example.com/images/cost-guide/4x3.jpg",
    "https://example.com/images/cost-guide/1x1.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "김철수",
    "url": "https://example.com/about/kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "OO스튜디오"
  }
}
</script>

속성 열 개 남짓이지만, 순서대로 채우면 어렵지 않다. 타입을 고르고(BlogPosting), 제목·날짜·이미지를 채우고, 저자를 이름만 정확히 넣은 다음, 여력이 되면 publisher까지 더하는 흐름이면 충분하다.

속성별 흔한 오류 한눈에 보기

지금까지 다룬 실수를 속성별로 모아보면 다음과 같다. 새 글을 발행하기 전 이 표만 훑어봐도 대부분의 오류를 걸러낼 수 있다.

속성	흔한 실수	올바른 방식
@type	"Post"처럼 schema.org에 없는 타입 사용	Article, NewsArticle, BlogPosting 중 선택
headline	지나치게 길어 기기에서 잘리는 제목	핵심 키워드를 앞에 두고 간결하게
image	문자열 하나, 상대 경로	배열, 절대 경로, 세 가지 비율
datePublished	"2026년 9월 17일"처럼 자연어 표기	ISO 8601 형식(2026-09-17)
dateModified	아예 비어 있거나 발행일보다 이전	발행일과 같거나 그 이후 날짜
author	이름에 직함·소속 혼입, 문자열 하나	이름만, Person/Organization 객체

표에서 보듯 실수는 대부분 "값을 안 넣는 것"이 아니라 "값의 형식이 틀린 것"에서 나온다. 속성을 아예 빠뜨리는 실수보다, 넣긴 넣었는데 형식이 틀려 구글이 값을 못 읽는 경우가 실무에서는 더 흔하다.

카테고리·태그 페이지에도 Article 스키마를 써야 하나

아니다. Article 계열 스키마는 개별 글 상세 페이지 하나에만 넣는 것이 원칙이다. 여러 글을 모아 보여주는 카테고리 목록, 태그 페이지, 블로그 홈 같은 곳에는 특정 글 하나의 제목·날짜·저자를 대표로 넣을 수 없기 때문에 Article 마크업이 애초에 맞지 않는다.

이런 목록형 페이지에는 대신 각 글을 순서대로 나열하는 ItemList 타입이 더 정확하다. "이 페이지 하나 = 글 하나"인 상세 페이지는 Article, "여러 글을 모아 보여주는" 목록 페이지는 ItemList로 역할을 나누면 헷갈릴 일이 없다. 실제로 이루웹 블로그도 글 상세 페이지에는 BlogPosting을, 목록·아카이브 페이지에는 별도의 목록형 구조화 데이터를 적용해 역할을 분리하고 있다.

• headline·image·datePublished 세 가지부터 채웠는가
• 글을 수정하면 dateModified도 함께 갱신하는가
• author.name에 이름만 넣고 직함·소속을 섞지 않았는가
• author.url 또는 sameAs로 저자를 식별할 수 있는가
• image를 배열로, 여러 비율을 함께 등록했는가
• 리치 결과 테스트에서 오류·경고 없이 인식되는가

리치 결과 테스트 경고, 어떻게 해석하나

리치 결과 테스트를 돌리면 "오류(Error)"와 "경고(Warning)" 두 종류가 뜬다. 오류는 마크업 자체가 깨져서 구글이 아예 읽지 못하는 상태이므로 반드시 고쳐야 한다. 반면 경고는 "필수는 아니지만 있으면 더 좋다"는 안내에 가까워, 발행을 막을 정도는 아니다.

Article 계열에서 자주 보이는 경고 몇 가지를 정리하면 다음과 같다.

• author.url이(가) 없습니다 — author 객체에 name만 있고 url·sameAs가 빠졌을 때 나온다. 저자 식별을 돕는 정보이므로 여유가 되면 채운다.
• image의(가) 권장 크기보다 작습니다 — 앞서 설명한 5만 픽셀 기준에 못 미칠 때 뜬다. 원본 이미지를 더 큰 해상도로 교체하면 해결된다.
• dateModified이(가) 없습니다 — 수정일을 아직 관리하지 않는 사이트에서 흔히 나온다. 발행일과 같은 값을 넣는 것만으로도 경고가 사라진다.

경고가 하나도 없는 상태를 목표로 삼되, 경고가 남아 있다고 발행을 미룰 필요는 없다. 시간을 두고 하나씩 채워가면 된다. 반대로 오류는 성격이 다르다. 오류가 뜬 상태로 발행하면 구조화 데이터 자체가 구글에 전달되지 않으므로, 발행 전 반드시 해소해야 한다.

기대치도 정확히 잡아야 한다. Article 계열 스키마는 Review나 FAQ처럼 검색 결과 화면에 별점이나 아코디언을 직접 만들어주는 타입이 아니다. 구글 공식 문서 표현을 빌리면, 검색 결과에서 제목·이미지·날짜 정보를 더 정확하게 보여주는 데 도움을 주는 배경 정보에 가깝다. 스키마를 넣었는데 화면이 그대로라고 해서 잘못 작성한 것은 아니다.

이런 최신 변화에 민감한 편이라면, 2026년에도 Article·BreadcrumbList 같은 핵심 스키마는 지원 중단 대상이 아니라는 점도 참고할 만하다. 관련 내용은 스키마 마크업 안 없앤다 — 뮬러가 꼽은 핵심 5가지에서 더 자세히 다룬다.

자주 묻는 질문

Article, NewsArticle, BlogPosting 중 하나만 골라야 하나

그렇다. 한 페이지에는 콘텐츠 성격에 맞는 타입 하나만 지정하는 것이 정확하다. 여러 타입을 동시에 넣기보다는, 본문 성격을 가장 잘 설명하는 타입 하나를 고르는 편이 검색엔진이 콘텐츠를 이해하기에도 명확하다.

author를 개인이 아니라 회사명으로 넣어도 되나

가능하다. author는 Person 타입뿐 아니라 Organization 타입도 공식적으로 지원한다. 필명을 따로 운영하지 않는 기업 블로그라면 조직명을 author로 쓰는 것이 오히려 자연스럽다.

dateModified를 안 채우면 문제가 되나

당장 오류가 나지는 않는다. 다만 수정 이력을 구글에 알려줄 방법이 사라진다는 단점이 있다. 별도로 관리하기 어렵다면 처음에는 발행일과 같은 값으로 채워두고, 실제로 글을 고칠 때마다 값을 갱신하는 습관을 들이는 것이 현실적이다.

워드프레스는 플러그인만 설치하면 저절로 되나

대부분 그렇다. Yoast SEO나 RankMath를 설치하고 글 작성 화면의 제목·발췌문·대표 이미지·작성자 항목을 채우면, 플러그인이 이 값을 읽어 Article 계열 스키마를 자동으로 생성한다. 다만 플러그인 설정에서 스키마 기능이 꺼져 있지는 않은지 한 번은 확인해보는 것이 안전하다.

스키마를 넣었는데 검색 결과 화면이 그대로다, 잘못된 건가

정상일 수 있다. Article 계열 스키마는 특정 리치 결과를 즉시 만들어내는 코드가 아니라, 검색엔진이 제목·이미지·날짜를 정확히 이해하도록 돕는 배경 정보에 가깝다. 화면이 바로 바뀌지 않는 것이 오히려 일반적인 반응이다.

NewsArticle을 쓰면 더 잘 노출되나

타입 선택만으로 노출이 보장되지는 않는다. NewsArticle은 언론사·통신사처럼 속보성이 뚜렷한 콘텐츠에 정확한 타입일 뿐, 일반 블로그 글에 억지로 NewsArticle을 붙인다고 별도의 우대를 받지는 않는다. 콘텐츠 성격과 타입을 정확히 맞추는 것이 노출 자체보다 우선하는 원칙이다.

이미지가 아직 없는 글도 스키마를 넣을 수 있나

넣을 수 있다. image도 필수가 아니므로, 이미지 없이 headline·datePublished·author만 채워도 마크업 자체는 정상 동작한다. 다만 이미지가 있는 페이지가 검색 결과에서 시각적으로 더 눈에 띄는 경향이 있으므로, 여건이 된다면 대표 이미지 한 장이라도 준비해 함께 등록하는 것을 권장한다.

기존에 발행한 글을 나중에 고쳐도 되나

물론이다. 오히려 처음부터 완벽하게 채우려 하기보다, headline·image·datePublished 세 가지만 먼저 채워 발행하고 이후에 author·dateModified·publisher를 순서대로 보강하는 방식도 현실적인 접근이다. 글이 많은 사이트일수록 한 번에 전부 손보기보다, 조회수가 높은 글부터 우선순위를 두고 점진적으로 정비하는 편이 부담이 적다.

---

Article·BlogPosting 스키마는 "필수 속성이 없다"는 말 때문에 오히려 대충 넘기기 쉬운 영역입니다. 하지만 headline·image·날짜·저자 다섯 가지를 정확히 채우는 것만으로도 검색엔진과 AI가 우리 글을 훨씬 명확하게 이해하게 됩니다. 글 한 편 한 편에 코드를 새로 짜야 한다는 부담 때문에 미뤄두셨다면, 이 글에서 정리한 체크리스트만이라도 기존 글부터 하나씩 대조해보시는 것을 권해 드립니다.

frontmatter나 플러그인 설정 한 번으로 끝나는 작업이니, 이번 기회에 기존 글까지 함께 점검해보시길 권해 드립니다. 구조화 데이터 세팅이 낯설게 느껴지신다면, 이루웹의 홈페이지 제작 서비스에서 스키마 설계부터 발행 전 검증까지 함께 도와드리고 있습니다. 궁금한 점은 상담 신청으로 편하게 문의해 주시기 바랍니다.