구조화 데이터 넣고 검사 도구로 확인하기

이 글은 글 페이지 하나의 소스 편집 화면을 열어 두고 Article 구조화 데이터를 넣은 뒤 Google이 그 값을 읽었는지 검사 도구로 확인하는 절차입니다. 구조화 데이터는 페이지에 적힌 제목, 날짜, 글쓴이 같은 정보를 정해진 어휘로 한 번 더 적어 검색엔진이 칸별로 읽게 하는 코드입니다.

시작 전에 기대할 범위를 정해 둡니다. Google은 AI 개요와 AI 모드에 나오려고 특별한 schema.org 구조화 데이터를 추가할 필요는 없다고 밝힙니다¹. Article 마크업은 검색 결과의 제목, 이미지, 날짜 정보를 Google이 더 잘 이해하도록 돕는 용도이고² 올바르게 넣어도 검색 결과에 표시된다는 보장은 없습니다³. 그래서 이 절차의 끝은 "Google이 이 값을 읽었다"는 기록 한 줄입니다.

화면에 보이는 값부터 고릅니다

Google은 독자에게 보이지 않는 내용을 마크업하지 말라고 정해 두었습니다³. 정확한 정보라도 화면에 없으면 넣지 않습니다⁴. Article 유형에는 필수 속성이 없고 권장 속성 다섯 개 가운데 내 글에 해당하는 것만 넣으면 됩니다². 아래 표를 들고 화면에서 각 값의 자리를 찾습니다.

표 1. Article 권장 속성과 화면 대응. 출처: Article 구조화 데이터 문서², 구조화 데이터 일반 가이드라인³. 기준일: 2026-09-08 수정, 2026-10-05 확인. 범위: Google이 지원하는 Article 속성만 넣었습니다.

author의 name 칸에 직함이나 발행처 이름을 붙이지 않도록 Google은 따로 적어 둡니다². 표의 다섯 줄 가운데 화면에 자리가 있는 줄을 모두 채웠으면 코드로 넘어갑니다.

JSON-LD 한 덩어리로 넣습니다

Google 검색은 JSON-LD, 마이크로데이터, RDFa 세 형식을 지원하며 사이트 구성이 허락하면 관리가 쉬운 JSON-LD를 권합니다⁴. JSON-LD는 script 태그 안에 따로 적혀 화면 글과 섞이지 않으므로 앞 단계에서 고른 값을 한곳에 모아 두기 좋습니다. 아래는 형식을 보여 주는 설명용 예시입니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "화면의 글 제목",
  "datePublished": "2026-10-05T09:00:00+09:00",
  "author": [{ "@type": "Organization", "name": "편집팀 이름", "url": "https://example.com/about/" }]
}
</script>

@type은 Article, NewsArticle, BlogPosting 가운데 하나를 고릅니다². 예시처럼 화면에 수정일이 없는 글이면 dateModified 줄을 아예 두지 않습니다. 작업 중 메모를 주석으로 남겼다면 지웁니다. 리치 결과 테스트는 JSON-LD 안의 주석을 무시하지만 JSON-LD 표준은 주석을 지원하지 않아 실제 페이지에서는 오류가 될 수 있습니다⁵.

배포 전에 리치 결과 테스트를 돌립니다

리치 결과 테스트에서 URL 대신 코드를 고르고 위 덩어리를 붙여 넣은 뒤 테스트 실행을 누릅니다⁵. 기본 사용자 에이전트는 스마트폰입니다. 결과 맨 위의 상태 문구로 다음 할 일을 정합니다.

표 2. 리치 결과 테스트 상태 문구. 출처: 리치 결과 테스트 도움말 한국어판⁵, Article 문서². 기준일: 2026-10-05 확인. 범위: 화면 표기 아홉 가지 가운데 이 절차에 해당하는 다섯 가지입니다.

경고가 없다고 날짜까지 맞는 것은 아닙니다. datePublished와 dateModified는 적용 여부를 사이트가 정하는 권장 속성이라 리치 결과 테스트가 경고를 띄우지 않습니다. 날짜 두 줄은 화면 표기와 직접 견줍니다. 경고 항목은 고치면 품질에 도움이 되지만 리치 결과 자격에 필수는 아닙니다².

리치 결과 테스트는 지원 목록에 있는 유형만 판정하며 기사와 탐색경로는 그 목록에 들어 있습니다⁵. 목록 밖의 schema.org 유형을 넣었다면 Schema Markup Validator에 코드나 URL을 넣어 JSON-LD, RDFa, 마이크로데이터 문법 오류를 찾습니다. 이 검사기는 schema.org 어휘에 맞춰 검사합니다⁶. Google 검색에서 어떻게 동작하는지는 schema.org 문서보다 Google 문서를 기준으로 삼으라고 Google은 적어 둡니다⁴.

배포한 뒤 URL 검사로 Google이 받은 HTML을 봅니다

Google은 몇 페이지만 먼저 배포하고 URL 검사로 Google이 페이지를 어떻게 보는지 확인하라고 안내합니다. 이때 페이지가 robots.txt, noindex, 로그인 요구로 막혀 있지 않아야 하며 Google이 새 페이지를 찾아 크롤링하기까지 며칠이 걸릴 수 있습니다².

기사 유형은 여기서 한 번 더 길이 갈립니다. URL 검사의 "페이지에서 감지된 리치 결과" 목록에 기사는 없고 지원되지 않는 유형은 유효해도 이 도구에 표시되지 않습니다. 그래서 실시간 URL 테스트를 누른 뒤 테스트된 페이지 보기에서 HTML을 열고 application/ld+json을 찾아 headline 값이 화면 제목과 같은지 봅니다. 색인된 버전은 크롤링된 페이지 보기에서 같은 방식으로 봅니다⁷. 값이 보이면 Google이 받은 페이지에 마크업이 들어 있으니 표 4의 URL 검사 칸에 "보임"을 적습니다. 마크업을 고쳐 다시 배포했다면 같은 화면에서 색인 생성 요청을 눌러 둡니다².

Search Console 왼쪽 메뉴의 개선사항에는 유형별 리치 결과 보고서가 있습니다. Google이 유효한 마크업을 찾았고 지원 유형일 때만 보고서가 생기며 탐색경로는 지원 목록에 있지만 기사는 없습니다. 보고서 숫자는 페이지가 아닌 항목을 센 값이고 전체 가운데 일부를 뽑은 표본입니다⁸.

표 3. 검사 도구별 확인 범위. 출처: 리치 결과 테스트⁵, Schema Markup Validator 문서⁶, URL 검사 도구⁷, 리치 결과 보고서 개요⁸. 기준일: 2026-10-05 확인. 범위: 기사와 탐색경로 두 유형만 비교했습니다.

기록 한 줄과 막히는 경우

앞 단계의 결과는 아래 여섯 칸에 모읍니다.

표 4. 구조화 데이터 확인 기록. 출처: 표 1~3의 칸 구성을 옮김²⁵⁷⁸. 기준일: 2026-10-05. 범위: 페이지 한 개에 씁니다.

실시간 URL 테스트의 HTML에서 application/ld+json이 보이지 않으면 템플릿이나 서빙 과정에서 마크업이 빠졌을 수 있습니다. Google은 배포 뒤 템플릿이나 서빙 문제로 마크업이 깨질 수 있고 자바스크립트로 동적으로 넣은 JSON-LD도 읽을 수 있다고 적습니다⁴. 두 경우 모두 배포된 페이지 URL로 리치 결과 테스트를 다시 돌립니다. 항목이 감지되면 서빙은 정상이고 감지되지 않으면 배포된 페이지 소스에서 script 태그부터 찾습니다.

리치 결과 테스트의 코드 탐색기는 렌더링된 소스를 쓰며 robots.txt나 noindex로 막힌 페이지는 테스트하지 못합니다⁵. "URL을 크롤링할 수 없음"이 뜨면 마크업보다 크롤링 허용을 먼저 고칩니다. 그 순서는 AI 검색 답변에 내 사이트가 빠질 때 설정 점검하기에 있습니다.

기록이 증명하는 범위는 Google이 마크업을 읽었다는 사실까지입니다. 리치 결과로 표시되는지는 Google이 정하며³ AI 기능에 쓰일 별도 마크업이나 텍스트 파일은 요구되지 않습니다¹. 그런 파일 가운데 자주 거론되는 형식은 llms.txt 항목에 정리했습니다.