Structured Data vs Open Graph, 검색 가격과 공유 이미지는 어디서 고칠까요?
Structured Data는 검색엔진이 페이지의 상품·기사·조직 정보를 이해하도록 표현하고, Open Graph는 SNS와 메신저가 공유 카드의 제목·설명·이미지를 읽는 데 사용합니다. 오류가 보이는 화면부터 원인을 나눠야 합니다.
This content is not yet translated into English. Showing the other available language.
세 줄 요약
Structured Data는 검색엔진이 상품·기사 같은 페이지 의미를 읽는 형식이고, Open Graph는 SNS·메신저의 공유 카드 정보를 정합니다.
검색 가격이 틀렸다면 구조화 데이터와 본문을, 공유 이미지가 낡았다면 og 태그와 플랫폼 캐시를 먼저 봐야 합니다.
기존 사이트를 바꾸지 않고 문제 URL 하나의 공개 HTML과 원천 데이터를 대조하면 두 설정의 담당 범위를 바로 나눌 수 있습니다.
Structured Data와 Open Graph의 차이
Google 검색 결과에는 지난달 가격이 보이는데 카카오톡 공유 카드에는 예전 상품 이미지가 뜬다면 같은 태그 하나로 고칠 수 없습니다. 검색엔진이 상품 정보를 읽는 구조화 데이터와 메신저가 링크 미리보기를 만드는 Open Graph는 쓰임이 다르기 때문입니다. “메타데이터 오류”로 뭉뚱그리지 말고 문제가 나타난 화면부터 특정해야 합니다.
비교 기준 | Structured Data | Open Graph |
|---|---|---|
주요 소비자 | 검색엔진 | SNS·메신저 |
대표 정보 | 상품·기사·조직·이벤트 | 공유 제목·설명·이미지 |
주요 검수 | 본문 일치와 리치 결과 테스트 | 공개 태그·이미지 응답·공유 캐시 |
공통 원칙 | 화면과 같은 원천 데이터 사용 | 화면과 같은 원천 데이터 사용 |
Structured Data와 Open Graph를 이름만으로 고르지 않습니다. 실제 업무 한 건에서 공개 본문과 canonical를 나란히 적어 보면 어느 단계에 먼저 손대야 하는지 드러납니다. 담당자와 재검사 날짜까지 같은 기록에 남겨야 다음 수정이 추측으로 흐르지 않습니다.
검색 가격과 기사 정보는 어디서 읽을까요?
구조화 데이터는 페이지에 무엇이 있고 각 항목이 어떤 속성을 갖는지 표준 형식으로 표시합니다. Google 검색에서는 주로 schema.org 어휘를 쓰며 JSON-LD, Microdata, RDFa를 지원합니다. 상품명·가격·통화·재고 상태를 Product로, 기사 제목·저자·날짜를 Article로 표현하는 식입니다.
올바른 마크업은 일부 리치 결과의 표시 자격을 갖추는 데 도움이 됩니다. 검증 도구를 통과했다고 실제 리치 결과가 나온다는 약속은 없습니다. 페이지 화면에 없는 후기나 다른 가격을 구조화 데이터에만 적는 것도 허용되지 않습니다. 검색 결과 정보가 틀렸다면 먼저 공개 본문과 JSON-LD의 값이 같은지, 해당 유형의 필수·권장 속성이 맞는지 확인합니다.
공유 이미지가 낡았다면 어디를 볼까요?
Open Graph Protocol은 웹페이지를 소셜 그래프의 객체로 표현하기 위한 메타데이터 규약입니다. og:title, og:type, og:image, og:url 등이 기본 속성입니다. 이를 지원하는 SNS와 메신저는 링크를 붙였을 때 제목과 이미지, 설명을 구성하는 데 해당 값을 참고할 수 있습니다.
플랫폼마다 태그가 없을 때 값을 고르는 방식과 캐시 갱신 시점이 다릅니다. HTML을 수정해도 이전 미리보기가 한동안 남을 수 있고, 이미지 규격이나 접근 권한 때문에 새 이미지가 읽히지 않을 수도 있습니다. Open Graph 태그를 넣은 뒤에는 해당 서비스의 공유 디버거나 다시 가져오기 기능으로 결과를 확인합니다.
오류가 보이는 곳 | 먼저 읽을 코드 | 이어서 볼 것 |
|---|---|---|
검색 결과의 상품 가격·재고 | 구조화 데이터 | 공개 본문, Google 가이드라인, 리치 결과 테스트 |
SNS·메신저의 제목·이미지 | Open Graph | 이미지 응답, 플랫폼 캐시, 공유 디버거 |
일반 검색 제목·설명 | HTML | 검색엔진의 제목 재작성 가능성 |
대표 주소가 제각각임 | canonical와 | 내부 링크, 리다이렉트, 추적 기준 |
두 값은 어떤 원천에서 만들어야 할까요?
상품 화면은 커머스 데이터베이스에서, JSON-LD는 SEO 플러그인에서, Open Graph는 테마에서 만드는 경우가 있습니다. 운영자가 상품명과 가격을 바꿔도 세 출력이 함께 갱신되지 않으면 검색 결과와 공유 카드에 서로 다른 사실이 노출됩니다. 가격·통화·재고처럼 자주 바뀌는 값은 가능한 한 같은 데이터 원천에서 가져와야 합니다.
canonical와 og:url은 같은 대표 주소를 가리키게 관리하는 편이 안전합니다. 둘이 갈라지면 공유되는 URL과 검색의 대표 URL이 달라져 캠페인 추적과 성과 집계가 복잡해집니다. 페이지 템플릿 하나를 고친 뒤 상품·카테고리·기사 등 다른 유형의 출력도 표본으로 검사합니다.
Google은 AI 검색 기능을 위해 새로운 schema.org 마크업이나 별도의 AI 파일을 추가할 필요가 없다고 안내합니다. 구조화 데이터는 공개 페이지의 의미를 설명하는 기존 SEO 수단이고 Open Graph는 링크가 공유될 때의 표현을 맡습니다. 어느 쪽도 생성형 답변의 언급이나 출처 링크를 약속하지 않습니다.
GEO 점검에서는 공개 본문과 구조화 데이터가 같은 사실을 말하는지부터 봅니다. AI 답변에 오래된 제품 정보가 나온다면 최신 공식 페이지의 본문·JSON-LD·응답 상태·내부 링크를 확인합니다. Open Graph는 AI 답변의 입력 신호로 단정하지 않고, 같은 정보가 공유 카드에서도 어긋나는지만 별도로 검사합니다.
오류 화면에 따라 담당을 어떻게 나눌까요?
검색 결과가 문제라면 실제 노출 URL, 검색어, 구조화 데이터 테스트 결과를 남깁니다. 공유 카드가 문제라면 어느 메신저에서 언제 공유했는지와 미리보기 화면을 기록합니다. 이렇게 해야 콘텐츠 담당자가 상품 정보를 고칠지, 개발자가 템플릿을 고칠지, 플랫폼 캐시를 갱신할지 바로 나뉩니다.
두 화면이 모두 틀렸더라도 각각 검증합니다. 본문을 고친 한 번의 배포가 검색 재처리와 SNS 캐시 갱신까지 같은 시점에 끝낸다고 가정해서는 안 됩니다.
Structured Data와 Open Graph 병행 운영의 실제 판단
판단 회의에서는 Structured Data와 Open Graph의 기능 목록보다 검색 결과·공유 카드 항목이 어디에서 끊기는지를 봅니다. 공개 HTML, 링크, 원문 데이터가 다른 값을 내보내면 검색과 AI 답변도 서로 다른 정보를 집을 수 있습니다. 원천 데이터 항목이 달라진 URL을 표본으로 입력부터 공개 결과까지 따라갑니다.
Structured Data와 Open Graph의 공개 본문 항목은 발행 직후와 후속 관찰 시점을 나눠 기록합니다. 당일에는 공개 응답을 확인하고 검색 노출·클릭과 AI 언급·인용은 같은 질문 묶음으로 다시 측정합니다. 결과가 실제 고객 행동과 연결되지 않으면 작업 범위를 줄입니다.
참고 자료
검색 결과 구성을 더 확인하려면
자료 확인일: 2026년 8월 9일. SNS·메신저의 Open Graph 해석과 캐시 정책은 서비스별로 달라 실제 공유 결과를 다시 확인해야 합니다.
기존 사이트 적용 범위
문제가 보이는 상품·기사 URL과 실제 검색 또는 공유 화면을 문의에 남기면 이 운영 방식이 공개 본문·구조화 데이터·Open Graph·canonical를 대조해 SEO·GEO 불일치의 수정 지점을 진단합니다.
Structured Data와 Open Graph 비교 이후의 Search OS 운영
Search OS 적용의 출발점은 사이트 교체가 아닙니다. Structured Data와 Open Graph 비교에서 확인할 원천 데이터, 공개 본문 항목을 현재 웹사이트 위에서 측정하고 콘텐츠·기술·외부 정보 가운데 막힌 부분만 손봅니다.
내부 성과 집계 기준으로 Search OS 적용 고객사는 SEO와 AI 검색 노출이 평균 88% 이상 증가했습니다. 이후에는 Structured Data와 Open Graph 비교에 사용한 검색과 AI 답변을 같은 주기로 다시 읽습니다. 좋아진 상태를 기준선으로 삼고 이탈이 생긴 URL을 먼저 고쳐 최상의 노출 상태가 이어지도록 관리합니다.