19장. 블로그 구조화 데이터: 글, FAQ, 탐색 정보를 과장 없이 전달하는 법
구조화 데이터는 페이지의 실제 정보를 기계가 읽을 수 있는 형식으로 설명합니다. 유효한 마크업은 특정 검색 기능의 자격 요건 중 하나가 될 수 있지만 색인, 순위, 리치 결과 노출을 보장하지 않습니다. 지원 유형·정책·페이지 품질·검색 맥락을 모두 충족해도 Google은 일반 결과를 보여 줄 수 있습니다.
블로그에서 가장 흔한 오류는 Article과 FAQPage의 역할을 섞는 것입니다. Article은 기사 제목·이미지·작성자·날짜 등을 이해시키는 데 도움을 주지만 일반 블로그 글에 별도 리치 결과를 약속하지 않습니다. Google Search 문서 변경 기록에 따르면 FAQ 리치 결과는 2026년 5월 7일부터 Google 검색에 표시되지 않으며, 2026년 6월에는 관련 문서도 제거됐습니다. 과거의 정부·건강 권위 사이트 제한을 현재 노출 자격처럼 설명해서는 안 됩니다.
비보장 경계: 테스트 통과는 문법과 일부 자격을 확인할 뿐 실제 리치 결과, 순위 상승, 클릭 증가를 인증하지 않습니다. 화면에 없는 정보를 마크업으로만 추가해서는 안 됩니다.
유효성·자격·실제 노출은 세 단계로 구분합니다
첫 단계는 구문 유효성입니다. 속성 이름, 값 형식, 필수 항목이 문서 규칙에 맞는지 검사합니다. 둘째는 해당 검색 기능의 자격입니다. 지원되는 콘텐츠 유형, 정책, 페이지 접근성, 가시 콘텐츠 일치 등을 충족해야 합니다. 셋째는 실제 노출입니다. 앞의 두 단계를 통과해도 Google 시스템이 검색어와 기기에 적절하지 않다고 판단하면 리치 결과를 표시하지 않을 수 있습니다.
구조화 데이터 일반 가이드는 JSON-LD를 권장 형식으로 설명하지만 Microdata나 RDFa도 지원 범위 안에서 사용할 수 있습니다. 형식을 여러 개 겹쳐 넣는다고 자격이 높아지지 않습니다. 유지보수하기 쉽고 화면 데이터와 동기화할 수 있는 한 형식을 선택합니다.
Schema.org에 유형이 존재한다고 Google 검색 기능이 지원한다는 뜻도 아닙니다. Google의 검색 갤러리와 유형별 문서에서 현재 지원 여부를 확인합니다. 지원되지 않는 속성을 추가하는 것이 항상 오류는 아니지만, 그것을 근거로 검색결과 기능을 약속해서는 안 됩니다.
지원 상태는 구현 당시 한 번만 확인하는 값이 아닙니다. 검색 기능이 종료되면 유효했던 마크업도 더 이상 해당 리치 결과를 만들지 않으며, 보고서와 테스트 항목도 사라질 수 있습니다. 유형별로 확인일, 공식 지원 문서, 사용 목적, 제거 조건을 인벤토리에 둡니다. Schema.org 상호운용성 때문에 유지하는 객체와 Google 검색 기능을 위해 유지하는 객체를 구분해야 지원 종료를 사이트 오류로 오판하지 않습니다.
Article은 글의 실체를 설명하지만 전용 노출을 보장하지 않습니다
Article, NewsArticle, BlogPosting은 기사형 페이지의 제목, 이미지, 날짜, 작성자 정보를 Google이 이해하는 데 도움을 줍니다. 공식 Article 문서는 권장 속성과 이미지 지침을 제공합니다. 필수 속성이 없다는 표현을 “아무 값이나 넣어도 된다”로 이해하지 않습니다. 적용하는 속성은 실제 페이지를 정확히 대표해야 합니다.
headline은 화면 제목과 의미가 같아야 하고, image는 해당 글을 대표하며 크롤링 가능해야 합니다. datePublished는 최초 발행 시점, dateModified는 의미 있는 최종 수정 시점을 ISO 형식과 정확한 시간대로 제공합니다. author는 실제 책임 주체를 나타내고 가능하면 작성자 소개 페이지와 연결합니다. publisher와 사이트 브랜드를 작성자로 바꿔 쓰지 않습니다.
Article 마크업만으로 Google 뉴스 포함, Discover 노출, 상위 순위, 큰 이미지, 작성자 이름 표시가 보장되지 않습니다. 마크업은 본문 품질·독창성·출처·정확성을 대신하지 못합니다. 일반 블로그 글이 BlogPosting을 사용해도 “Article 리치 스니펫이 반드시 생긴다”고 설명하면 안 됩니다.
Article에는 Google 문서상 필수 속성이 없지만, 이는 빈 객체도 유용하다는 뜻이 아닙니다. 해당하는 권장 속성을 정확히 제공합니다. 여러 작성자가 화면에 표시되면 각 사람을 별도 author 항목으로 두고 한 name에 합치지 않습니다. 이름에는 직책·‘작성자’ 같은 접두어·게시자명을 섞지 않으며 Person과 Organization을 실제 주체에 맞춥니다. url이나 sameAs는 그 작성자를 고유하게 확인할 수 있는 프로필로 연결합니다.
이미지는 마크업된 글을 실제로 대표하고 크롤링·색인 가능한 지원 형식이어야 합니다. 공식 권장은 16:9, 4:3, 1:1 비율의 고해상도 버전과 각 이미지의 너비×높이 50,000픽셀 이상입니다. 이 수치를 채운 로고를 넣는 것은 대체가 되지 않습니다. 여러 부분으로 나뉜 기사는 대표 URL이 임의로 첫 조각을 가리키지 않도록 각 페이지 또는 모두 보기 페이지의 캐노니컬 설계도 함께 확인합니다.
| 속성 | 실제 요건 | 흔한 오류 |
|---|---|---|
| headline | 가시 제목과 같은 글을 설명 | 검색 키워드 추가로 화면 제목과 불일치 |
| image | 대표성 있고 크롤링 가능한 이미지 | 로고만 넣거나 접근 차단 |
| datePublished | 실제 최초 발행일 | 매일 현재 날짜로 재생성 |
| dateModified | 실제 의미 있는 수정일 | 광고 로드만으로 자동 변경 |
| author | 실제 작성 책임자와 정확한 유형 | 키워드나 허위 전문가 이름 |
FAQPage는 검색 리치 결과 지원 중단과 콘텐츠 역할을 구분합니다
FAQPage는 사이트가 직접 작성한 질문과 답변이 한 페이지에 있는 경우를 위한 유형입니다. 사용자가 여러 답변을 제출하는 페이지는 QAPage의 대상일 수 있어 역할이 다릅니다. 질문과 전체 답변은 사용자가 페이지에서 확인할 수 있어야 하며 광고 목적으로 사용하거나 같은 FAQ를 사이트 전역에 반복 마크업하지 않습니다.
과거에는 잘 알려진 권위 있는 정부·보건 사이트에만 FAQ 리치 결과가 제공됐지만, 현재 판단 기준은 2026년 지원 종료 공지입니다. 따라서 일반 수익형 블로그는 물론 과거 제한 자격에 해당하던 사이트도 Google 검색의 FAQ 리치 결과 노출을 운영 목표로 두지 않습니다. 발행·업데이트 시점에는 공식 FAQ 리치 결과 지원 종료 기록에서 현재 상태를 확인합니다.
이 변화는 가시 FAQ 본문 자체를 삭제하라는 뜻이 아니며 Schema.org 어휘의 존재 여부와도 별개입니다. 사용자가 실제로 묻는 예외를 해결한다면 본문은 유지할 수 있습니다. 다만 Google 리치 결과만을 목적으로 한 마크업과 테스트 자동화는 제거 후보가 됩니다. Article을 함께 넣거나 다른 유형으로 이름을 바꿔 FAQ 검색 기능을 우회하려 해서는 안 됩니다.
본문 FAQ가 독자에게 유용하다면 마크업 노출과 무관하게 유지할 수 있습니다. 단지 리치 결과를 노리고 반복 질문을 붙이지 않습니다. Google 리치 결과만을 목적으로 한 FAQPage 마크업은 사이트 유형과 관계없이 제거 후보입니다. 다른 소비자가 읽는 Schema.org 상호운용 목적이 명확하고 화면 답변과 계속 동기화할 수 있다면 그 목적을 별도 원장에 기록하고 유지할 수 있습니다.
Breadcrumb는 실제 탐색 계층을 설명해야 합니다
BreadcrumbList는 현재 페이지가 사이트의 어느 계층에 있는지 나타냅니다. 사용자가 이동할 수 있는 논리적 경로와 일치해야 하며 검색 키워드를 넣기 위해 존재하지 않는 카테고리를 만들지 않습니다. Blogger 라벨 여러 개를 전부 계층으로 나열하면 실제 상하 관계가 없는 평면 태그를 잘못 설명할 수 있습니다.
각 ListItem의 position은 순서대로 이어지고 name은 사용자에게 이해 가능한 이름이며 item은 해당 단계의 대표 URL이어야 합니다. 마지막 항목 URL 처리 등 세부사항은 공식 Breadcrumb 문서를 따릅니다. 캐노니컬과 다른 프로토콜·호스트를 섞지 않습니다.
Breadcrumb가 유효해도 검색결과 URL 경로가 원하는 문구로 고정되지는 않습니다. 화면 탐색, 내부 링크, URL 구조와 함께 일관된 문맥을 제공하는 것이 목적입니다. 테마에 가시 breadcrumb가 없다면 마크업만 몰래 넣기보다 실제 사용자 탐색이 필요한지 먼저 설계합니다.
Blogger 테마의 기존 마크업부터 인벤토리합니다
Blogger 커스텀 테마는 BlogPosting, Breadcrumb, Organization 정보를 이미 출력할 수 있습니다. 게시물 본문에 또 추가하면 동일한 글을 설명하는 두 객체의 제목·날짜·작성자가 충돌할 수 있습니다. 새 마크업을 붙이기 전에 공개 URL을 리치 결과 테스트와 Schema 검사기로 확인해 현재 객체, 오류, 값의 출처를 기록합니다.
홈페이지, 게시물, 라벨 페이지는 템플릿 조건이 다릅니다. 게시물 한 개만 보고 사이트 전체가 같다고 가정하지 않습니다. 오래된 글·새 글·작성자가 다른 글·대표 이미지 없는 글을 표본으로 검사합니다. 모바일 렌더링에서 값이 달라지는 테마도 있으므로 최종 공개 결과를 봅니다.
- 같은 Article 객체가 두 번 존재하는가
- 화면 제목과 headline이 같은 글을 가리키는가
- 작성자 URL이 실제 소개 페이지로 열리는가
- 수정일이 매 요청마다 현재 시각으로 바뀌지 않는가
- 대표 이미지가 Googlebot에 열려 있는가
- http·https, www·비www URL이 섞이지 않는가
- FAQ 답변이 접힌 상태라도 사용자가 펼쳐 볼 수 있는가
중복이 있다고 무조건 하나를 임의 삭제하지 않습니다. 어떤 층이 테마 공통 출력이고 어떤 층이 게시물 수동 입력인지 확인합니다. 대개 한 곳에서 일관되게 관리하는 편이 안전합니다.
인벤토리에는 객체의 개수뿐 아니라 식별 관계를 남깁니다. 같은 글을 가리키는 BlogPosting 두 개가 각각 다른 날짜와 작성자를 말하는지, WebSite·Organization·Person이 별도 객체로 연결되는지, 페이지 URL과 mainEntityOfPage가 대표 URL을 가리키는지 봅니다. 파서가 둘 다 유효하다고 해도 서로 충돌하는 사실은 정책·의미 검수에서 실패입니다. 수동 본문 마크업을 제거할지 테마 객체를 고칠지는 어느 원본이 전체 글에서 지속적으로 갱신되는지로 결정합니다.
구현은 화면 콘텐츠를 원본으로 삼습니다
구조화 데이터 값을 별도 문서에서 수동 복사하면 시간이 지나 화면과 어긋납니다. 가능하면 제목 필드, 실제 게시·수정일, 작성자 프로필, 대표 이미지처럼 화면과 같은 데이터 원본에서 생성합니다. 속성을 많이 넣는 것보다 정확히 유지할 수 있는 속성만 제공하는 편이 낫습니다.
보이지 않는 리뷰 점수, 존재하지 않는 FAQ, 과장된 가격, 허위 작성자를 추가하지 않습니다. 구조화 데이터 정책 위반은 해당 기능 자격 상실이나 수동 조치로 이어질 수 있습니다. 마크업이 맞아도 콘텐츠가 검색 스팸 정책을 위반하면 보호받지 못합니다.
대표 이미지의 URL은 안정적으로 유지하고 이미지 변형이 필요하면 문서의 비율·크기 권장을 확인합니다. 날짜에 시간대를 포함하고, 작성자 유형을 Person과 Organization 중 실제 주체에 맞춥니다. 이름만 제공하는 것보다 독자가 작성자를 확인할 수 있는 페이지를 연결하는 것이 좋습니다.
구현 원장을 만들면 화면 필드와 마크업 필드의 연결이 보입니다. headline은 게시물 제목, datePublished는 최초 발행 기록, dateModified는 의미 있는 편집 기록, image는 실제 대표 이미지, author는 공개 프로필에서 읽어야 합니다. 원본이 비어 있을 때 임의 기본 작성자나 오늘 날짜로 채우지 않고 해당 속성을 생략하거나 발행을 보류합니다. 화면을 고쳤는데 마크업 값이 바뀌지 않으면 캐시와 생성 조건을 조사합니다.
테스트 통과 뒤에는 색인된 결과와 보고서를 별도로 봅니다
- 배포 전 테스트 입력으로 구문과 필수·권장 속성 경고를 확인합니다.
- 배포 후 공개 URL 테스트로 실제 렌더링 값을 확인합니다.
- 화면의 제목·날짜·작성자·이미지와 항목별로 대조합니다.
- URL 검사에서 대표 URL과 크롤링 가능성을 확인합니다.
- Search Console 개선 보고서가 제공되는 유형이면 유효·경고·오류 추세를 봅니다.
- 실제 검색결과 표본을 보되 리치 결과 미노출을 문법 실패로 단정하지 않습니다.
리치 결과 테스트는 Google이 지원하는 유형의 기술적 자격을 검사하는 도구입니다. 순위·색인·실제 노출을 예측하지 않습니다. Schema 검사기는 더 넓은 어휘를 볼 수 있지만 Google 검색 기능 지원을 인증하지 않습니다. 두 도구의 목적을 구분합니다.
Search Console 보고서도 사이트의 모든 URL을 완전 실시간으로 나열하는 인벤토리가 아닐 수 있습니다. 샘플과 처리 지연을 고려합니다. 오류 수정 검증 요청은 재처리를 돕지만 실제 리치 결과를 켜는 버튼이 아닙니다.
FAQ 지원 중단 뒤 관련 보고서나 테스트 항목이 사라지는 것은 개별 사이트의 파싱 실패 증거가 아닙니다. 모니터링 대시보드에서 FAQ 유효 항목 수를 핵심 목표로 삼던 규칙, API 필드, 배포 차단 조건을 점검합니다. 지원 종료된 검색 기능 때문에 정상 배포가 실패하지 않도록 해당 검사를 분리하되, 화면에 없는 답변이나 허위 정보 같은 일반 구조화 데이터 정책 검수까지 함께 끄지는 않습니다.
오류·경고·정책 문제는 다른 우선순위로 처리합니다
오류는 해당 기능의 자격을 막는 필수 문제일 수 있어 유형 문서를 기준으로 해결합니다. 경고는 권장 속성 누락처럼 자격을 반드시 막지는 않지만 제공 가능한 실제 정보라면 보강합니다. 존재하지 않는 정보를 경고 제거 목적으로 만들어 내지 않습니다. 정책 문제나 가시 본문 불일치는 문법 오류보다 우선해 바로 고칩니다.
| 상태 | 조치 | 잘못된 대응 |
|---|---|---|
| 필수 값 오류 | 실제 데이터 원본과 형식 수정 | 임시 허위 값 입력 |
| 권장 값 경고 | 실제 값이 있을 때 제공 | 경고 0개를 위해 값 조작 |
| 본문 불일치 | 마크업 제거 또는 화면과 동기화 | 사용자에게 안 보이게 숨김 |
| 리치 결과 미노출 | 자격·정책·검색 맥락 확인 | 마크업 반복 추가 |
| FAQ 리치 결과 | Google 검색 지원 종료를 반영하고 가시 본문은 독자 유용성으로 판단 | 다른 유형으로 지원 종료 우회 시도 |
변경과 롤백은 테마 버전과 표본 URL을 남깁니다
수정 전 테마를 백업하고 현재 객체와 테스트 결과를 저장합니다. 한 번에 한 유형 또는 한 데이터 원본을 고칩니다. Article 날짜와 Breadcrumb URL을 동시에 바꾸면 오류가 어디서 사라졌는지 알기 어렵습니다. 대표 표본을 통과한 후 사이트 전체에 확장합니다.
배포 뒤 파싱 오류, 페이지 렌더링 문제, 잘못된 날짜 대량 생성이 나타나면 이전 테마로 롤백합니다. 잘못된 마크업을 유지하는 것보다 제거해 일반 검색결과로 남는 편이 안전합니다. 롤백 뒤 공개 URL을 다시 테스트하고 캐시가 아닌 라이브 응답이 복구되었는지 확인합니다.
직접 조치나 정책 불일치가 발견되면 잘못된 객체를 먼저 제거·수정하고 영향 URL을 기록합니다. 구조화 데이터가 무시되더라도 페이지 자체는 일반 검색결과에 남을 수 있으므로, 리치 기능을 되찾겠다고 허위 속성을 급히 채우지 않습니다. 재검토가 필요한 사안과 단순 파싱 오류를 구분하고, 라이브 페이지와 Search Console 메시지를 같은 버전으로 보관합니다. 복구의 목표는 리치 노출 회복이 아니라 화면 사실과 기계 설명의 일치입니다.
리치 결과 트래픽이 줄었다는 이유만으로 이전 마크업을 복원하지 않습니다. 검색 기능 정책·자격·Google 표시 변화가 원인일 수 있습니다. FAQ 리치 결과는 사이트별 구문 수정으로 해결할 제한이 아니라 Google 검색 기능 자체의 지원 종료입니다.
발행 전 체크리스트
- Google이 현재 지원하는 유형과 검색 기능을 공식 문서에서 확인했습니다.
- 화면에 보이는 실제 콘텐츠만 마크업했습니다.
- Article의 제목·이미지·날짜·작성자와 공개 페이지가 일치합니다.
- FAQ 리치 결과의 2026년 지원 중단을 현재 상태로 반영하고 과거 정부·건강 제한을 현행 자격처럼 쓰지 않았습니다.
- 테마의 기존 객체와 수동 객체가 충돌하지 않습니다.
- 테스트 통과를 실제 노출 보장으로 표현하지 않았습니다.
- 배포 전 테마와 값, 배포 후 테스트 결과를 보관했습니다.
- 오류 발생 시 제거 또는 이전 버전 복구 절차가 있습니다.
구조화 데이터는 정확한 본문을 설명하는 층이지 부족한 본문을 대신하는 장식이 아닙니다. Article은 기사 실체 이해를 돕지만 전용 리치 결과를 보장하지 않습니다. Google 검색의 FAQ 리치 결과는 지원이 종료됐으며, Schema.org 상호운용성이나 독자용 FAQ 본문을 유지할지는 별도로 판단합니다.
구조화 데이터는 지원 상태와 화면 콘텐츠가 맞을 때만 유지합니다
Article은 화면 사실과 일치할 때만 유지하고 표시 확대를 약속하지 않습니다. FAQ 리치 결과 목적의 FAQPage는 2026년 5월 7일 표시 종료와 6월 관련 문서 제거를 반영해 사이트 유형과 관계없이 제거 후보로 분류합니다. Schema.org 상호운용 목적은 별도 근거가 있을 때만 유지합니다. 빈 값이나 허위 값으로 테스트를 통과시키지 않고 실제 정보가 없으면 속성 또는 객체를 제거합니다.