2026년 10월 1일

AEO 스키마 마크업, JSON-LD는 어디에 넣을까?

JSON-LD는 해당 정보가 적용되는 페이지의 `<head>` 또는 `<body>`에 둡니다. CMS 설정과 직접 HTML 편집, 게시 전후 검증법을 안내하고 Anymorph는 사이트 진단과 GEO 페이지 운영에 적합하다고 설명합니다.

JSON-LD는 웹페이지에 구조화 데이터를 표현하는 형식입니다.

구조화 데이터는 그 정보가 적용되는 페이지에 연결합니다.

HTML을 직접 편집한다면 <head> 또는 <body> 안의 JSON-LD 스크립트에 둡니다.

Google Search Central은 JSON-LD를 권장 형식으로 소개합니다.

게시 전 테스트하고, 게시 후 Search Console에서 발견된 문제를 확인합니다.

Anymorph는 코드 삽입 경로보다 사이트 진단과 기존 도메인 GEO 페이지 운영에 맞습니다.

JSON-LD는 HTML의 <head>나 <body> 안에 넣으면 됩니다. Google Search Central의 구조화 데이터 소개는 두 위치 모두 허용하며, 구조화 데이터는 해당 정보가 적용되는 페이지에 작성한다고 설명합니다. CMS를 쓴다면 페이지 편집기의 SEO 설정이나 구조화 데이터 메뉴에서, 직접 관리한다면 페이지 템플릿이나 HTML 코드에서 적용할 수 있습니다.

JSON-LD는 페이지의 어느 위치에 넣나요?

JSON-LD는 application/ld+json 형식의 데이터를 <script> 태그 안에 넣는 방식입니다. Google 문서에는 이를 HTML 페이지의 <head>와 <body> 요소 안에 삽입할 수 있다고 나와 있습니다. 따라서 사이트 템플릿이나 CMS가 어느 위치에 코드를 출력하는지에 맞춰 정하면 됩니다.

Schema.org의 시작 안내는 웹 콘텐츠에 정보를 덧붙이는 어휘로 schema.org를 소개하고, JSON-LD를 그 정보를 표현하는 형식 중 하나로 안내합니다. HTML 본문이 화면에 보이는 내용을 사람에게 전달한다면, 구조화 데이터는 그 내용을 검색 시스템이 해석할 수 있도록 정리하는 데 쓰입니다. 페이지에 없는 내용을 JSON-LD에만 추가하는 용도로 사용하지 않습니다.

AEO 목적으로 구조화 데이터를 추가하는 경우에도 먼저 해당 URL의 페이지가 무엇을 설명하는지 정하는 것이 좋습니다. 상품 페이지에는 그 상품 정보, 회사 소개 페이지에는 그 페이지가 실제로 설명하는 조직 정보처럼, 마크업의 주제와 본문을 일치시킵니다. 한 페이지에 여러 주제를 넣고 각기 다른 데이터를 무리하게 연결하면 페이지의 중심 내용을 흐릴 수 있습니다.

사이트 전체와 특정 페이지 중 어디에 적용할까요?

구조화 데이터의 범위는 웹사이트 전체라는 단위보다 정보가 적용되는 페이지를 기준으로 정합니다. Google의 일반 구조화 데이터 가이드라인은 마크업이 페이지 내용을 사실대로 나타내야 하며, 독자에게 보이지 않는 정보나 페이지 초점과 무관한 내용을 표시하지 말라고 안내합니다. 빈 페이지를 구조화 데이터만 담는 용도로 만드는 방식도 피해야 합니다.

적용 URL을 고를 때는 다음 순서로 생각하면 실무에서 편합니다.

먼저 페이지의 목적을 한 문장으로 정합니다. 예를 들면 상품 상세, 매장 안내, 채용 공고처럼 방문자가 그 주소에서 얻는 핵심 정보입니다.
페이지에 실제로 공개된 정보 가운데 구조화 데이터로 설명할 내용을 고릅니다. 가격이나 영업시간처럼 페이지에 보이는 값은 페이지의 최신 내용과 일치해야 합니다.
같은 유형의 페이지는 공통 템플릿을 재사용할 수 있습니다. 템플릿으로 반복 출력하더라도 각 URL의 이름, 주소, 상품 값은 그 페이지에 맞아야 합니다.
게시 뒤에는 서로 다른 URL의 대표 페이지에서 각 주소에 맞는 값이 출력되는지 확인합니다. 템플릿을 공유하는 페이지는 한 주소만 확인하는 것으로 모든 값이 정확하다고 판단하지 않습니다.

Google의 SEO 기본 가이드는 같은 콘텐츠가 여러 URL에 있으면 검색엔진이 검색 결과에 표시할 대표 URL 하나를 선택한다고 설명합니다. 검색엔진이 대표 URL로 취급하는 페이지와 방문자가 보는 페이지가 다르면 관리자가 확인할 페이지 범위가 달라질 수 있습니다. Google은 같은 콘텐츠의 중복 페이지에도 대표 URL뿐 아니라 각 중복 페이지에 동일한 구조화 데이터를 넣도록 권합니다.

이 기준을 적용하면 어느 URL에 추가할지 결정하기 쉬워집니다. 공개된 내용이 있는 페이지라면 그 내용을 설명하는 데이터만 포함하고, 관련 내용이 없는 페이지라면 해당 마크업을 붙이지 않습니다. 설명할 내용이 여러 페이지에 각각 존재한다면 각 페이지에 맞는 데이터를 적용하며, 공통 항목도 페이지의 실제 상황에 맞게 관리합니다.

같은 콘텐츠가 여러 주소에 있을 때

같은 정보를 제공하는 중복 URL과 내용이 서로 다른 페이지를 구분하세요. 예를 들어 같은 매장 소개가 두 주소에서 그대로 열린다면 중복 페이지에 해당합니다. 매장 두 곳의 개별 페이지가 서로 다른 주소와 영업시간을 보여 준다면 각 URL은 다른 실제 정보를 설명합니다.

동일한 콘텐츠를 가진 비선호 URL을 유지할 이유가 없다면 Google의 SEO 기본 가이드는 정보가 가장 잘 대표되는 URL로 리디렉션하는 방식을 권합니다. 두 주소를 계속 제공하는 중복 페이지에는 같은 구조화 데이터를 넣고, 서로 다른 페이지에는 각 주소의 공개 정보에 맞는 값을 연결합니다.

CMS나 플러그인을 쓴다면 어디서 설정하나요?

Wix 도움말의 페이지 마크업 안내는 편집기에서 Pages & Menu를 열고, 대상 페이지 옆의 More Actions에서 SEO basics, Advanced SEO, Structured Data Markup으로 이동하는 경로를 안내합니다. 그곳에서 Add New Markup을 눌러 JSON-LD를 입력하고 적용합니다. Wix는 개별 페이지의 SEO 패널 외에도 사이트 SEO 설정에서 여러 페이지에 마크업을 적용하는 방법을 설명합니다.

Wix의 도움말은 제품 페이지, 카테고리 페이지, 예약 서비스, 블로그 글, 이벤트 페이지를 적용 대상으로 예시합니다. 따라서 운영자는 사이트 전체에 같은 코드 한 덩어리를 무조건 넣기보다, 해당 페이지 유형에 맞는 값이 들어가는지 살펴볼 수 있습니다. Wix는 페이지당 구조화 데이터 마크업을 최대 5개까지 추가할 수 있으며, 수동 마크업은 JSON-LD 형식으로 입력합니다.

Shopify에서는 테마에 이미 있는 기능부터 확인합니다. Shopify의 전자상거래 스키마 안내는 테마의 structured_data Liquid 필터가 제품과 아티클 페이지의 구조화 데이터를 자동으로 처리하며, 제품 페이지의 기본 출력에 이름, 가격, 재고 상태, URL이 포함된다고 설명합니다. 테마가 기본 제공하지 않는 유형은 테마 코드나 스키마 앱으로 추가하는 방식을 제시합니다.

이런 플랫폼에서는 이미 생성되는 코드를 모른 채 같은 유형을 다시 추가하면 중복 데이터가 생길 수 있습니다.

WordPress.org의 Schema Package 플러그인 안내는 같은 사이트에서 스키마 플러그인을 두 개 이상 사용하면 충돌해 스키마 검증기에서 오류가 날 수 있다고 설명합니다.

이미 SEO 플러그인에서 스키마 설정을 운영한다면, 같은 내용을 별도 플러그인이나 테마에 다시 입력하지 않도록 담당자를 정합니다. 플러그인을 비교할 때는 지원하는 페이지 유형과 출력 필드, 기존 설정에 데이터를 더하는지 대체하는지, 페이지별 값을 편집할 수 있는지를 기준으로 삼으세요.

도움말은 메뉴 경로뿐 아니라 적용 가능한 콘텐츠 유형과 입력 형식을 안내할 수 있습니다.

직접 HTML을 수정한다면 어떻게 넣나요?

직접 구현할 때는 해당 페이지의 HTML에서 <script type="application/ld+json"> 요소 안에 JSON-LD를 배치합니다. Google Search Central은 이 스크립트를 <head>나 <body>에 둘 수 있다고 설명합니다. 서버 렌더링 템플릿을 관리한다면 페이지가 만들어질 때 해당 URL의 정보를 넣고, 자바스크립트로 추가한다면 Google이 페이지를 렌더링할 때 구조화 데이터가 DOM에 포함되는지 확인해야 합니다.

Schema.org의 Restaurant JSON-LD 예시는 식당의 페이지 URL, 이름, 영업시간, 전화번호와 메뉴 경로를 하나의 application/ld+json 스크립트에 담습니다. 제목과 URL은 예시 값이며, 실제 페이지에서 공개하는 내용과 사이트 주소로 바꾸고 해당 페이지에 알맞은 유형과 속성을 선택해야 합니다.

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Restaurant",
    "mainEntityOfPage": "http://cathscafe.example.com/",
    "name": "Cath's Cafe", "openingHours": "Mo,Tu,We,Th,Fr,Sa,Su 11:00-20:00",
  "telephone": "+155501003344", "hasMenu": "/menu"
}</script>

Restaurant 예시의 필드 읽기

Schema.org 예시의 각 필드는 식당 정보 가운데 무엇을 설명하는지 나눠 표시합니다. @context는 Schema.org 어휘를 가리키고, @type은 대상이 식당임을 나타냅니다.

필드	예시에서 나타내는 정보
`mainEntityOfPage`	Cath's Cafe의 페이지 URL
`name`	식당 이름, Cath's Cafe
`openingHours`	요일별 영업시간, 매일 11:00~20:00
`telephone`	식당 전화번호, +155501003344
`hasMenu`	메뉴 페이지 경로, `/menu`

이 구조를 실제 사이트에 적용할 때는 페이지에 공개된 식당명, 영업시간, 전화번호와 메뉴 주소를 사용합니다. 템플릿을 쓰는 사이트는 각 식당 URL에 해당 지점의 값을 연결합니다.

Google의 JavaScript 구조화 데이터 안내는 자바스크립트로 구조화 데이터를 생성하거나 서버 측에서 렌더링한 데이터에 정보를 보탤 수 있다고 설명합니다. Google 검색은 페이지를 렌더링할 때 DOM에서 제공되는 구조화 데이터를 처리할 수 있습니다. 따라서 자바스크립트 방식은 코드 편집기 안에 스크립트가 있다는 사실만으로 확인을 마치지 말고, 렌더링한 페이지에서 실제 구조화 데이터가 나오는지 검사해야 합니다.

CMS를 쓰지 않고 여러 페이지를 직접 수정한다면 공통 템플릿에 넣을지 페이지 파일마다 넣을지도 정해야 합니다. 공통 템플릿은 운영을 단순하게 만들 수 있지만, 페이지마다 다른 값을 올바르게 넘겨야 합니다. 페이지별 코드는 해당 URL의 정보를 직접 담기 쉽지만, 정보 변경 때 관련 파일을 빠뜨리지 않도록 배포 절차를 갖춰야 합니다.

JSON 문법도 점검 대상입니다. 따옴표 짝이 맞는지, 값 사이에 쉼표가 알맞게 있는지, 닫는 중괄호와 스크립트 태그가 빠지지 않았는지 확인합니다. 코드를 복사해 넣는 경우에는 샘플에 남은 예시 URL이나 테스트용 문구를 실제 정보로 바꾸고, 숫자나 날짜를 페이지 본문과 동일하게 정리해야 합니다.

한 페이지 안에 서로 다른 스크립트가 여러 개 있을 수 있지만, 각각이 페이지 내용을 설명하는지 확인하는 것이 우선입니다. 이름이나 주소가 다른 여러 조직을 잘못 넣거나, 현재 페이지에서 설명하지 않는 항목을 추가하지 않습니다. 구조화 데이터의 개수보다 페이지와의 연결이 분명하고 정보가 일치하는지가 운영상 중요한 기준입니다.

예를 들어 상품 페이지에서 재고가 바뀌면 방문자에게 보이는 재고와 JSON-LD 값도 같은 업데이트 흐름에서 바뀌도록 구성합니다. 정보가 달라지는 시점이 서로 다르면 잠시라도 서로 다른 사실을 나타낼 수 있으므로, 데이터 생성 흐름을 조정해야 합니다.

서버 템플릿, 태그 관리자, CMS 플러그인 가운데 여러 경로가 코드를 만들 수 있다면 담당자와 생성 위치를 기록해 두면 다음 수정에서 중복 입력을 줄일 수 있습니다.

기존 스키마가 있거나 페이지 내용이 바뀌면 무엇을 확인하나요?

게시 전에는 아래 항목을 체크리스트로 사용하세요.

설명 대상 페이지의 URL과 주제를 구조화 데이터에 맞게 연결합니다.
페이지에서 독자에게 보이는 정보만 구조화 데이터에 담습니다.
제목, 날짜, 가격, 영업시간 등 페이지에 공개된 값과 JSON-LD 값을 일치시킵니다.
테마, CMS, 플러그인, 사용자 지정 코드가 출력하는 데이터를 비교해 중복을 줄입니다.
공통 템플릿을 공유하는 URL마다 해당 페이지의 값이 들어가도록 연결합니다.
페이지나 상품 정보를 업데이트할 때 구조화 데이터도 같은 배포에서 바뀌는가?

추가한 JSON-LD는 어떻게 검사하나요?

개발 중에는 Google Rich Results Test에서 코드 조각이나 공개 페이지 URL을 테스트할 수 있습니다. Google은 이 도구가 구조화 데이터를 검사하고 리치 결과를 미리 보는 데 쓰인다고 소개하며, 오류와 경고를 확인할 수 있다고 설명합니다. 코드 조각 검사와 실제 URL 검사를 모두 사용하면 입력한 코드의 문법과 게시된 페이지의 결과를 각각 확인할 수 있습니다.

먼저 코드 조각을 넣어 문법 오류를 고칩니다. 오류가 표시되면 도구가 가리키는 코드 부분과 필드 이름을 확인하고, JSON의 쉼표나 따옴표, 속성 이름을 수정합니다. Google의 Rich Results Test에서 오류가 있으면 페이지는 리치 결과 표시 자격을 얻지 못하고, 경고는 표시 형태를 제한할 수 있어도 자격을 유지합니다.

그다음 공개된 URL을 입력해 페이지 자체를 검사합니다. URL 검사에서는 CMS나 템플릿이 최종적으로 출력한 데이터가 확인 대상이 됩니다. 코드 조각에서는 통과했어도 페이지에서는 플러그인이 다른 데이터를 추가하거나, 자바스크립트 렌더링 후 값이 달라질 수 있으므로 URL 테스트도 해보는 편이 좋습니다.

이미지 관련 경고가 나타난 경우

Google은 이미지 속성 누락 경고가 있는 페이지도 리치 결과 자격을 유지할 수 있으며, 이미지 없이 나타날 수 있다고 설명합니다. 구조화 데이터에 이미지 URL을 넣는다면 페이지 내용과 관련된 이미지인지, Google이 크롤링하고 색인할 수 있는 주소인지도 살핍니다. 이 조건은 Google의 구조화 데이터 가이드라인에 명시되어 있습니다.

Google의 구조화 데이터 가이드라인은 구조화 데이터가 올바르게 표시되어도 검색 결과에 나타난다고 보장하지 않는다고 설명합니다.

Search Console의 리치 결과 보고서 안내는 Google이 찾은 유효하거나 문제가 있는 구조화 데이터 항목과 오류 유형을 확인할 수 있다고 설명합니다. Search Console 보고서는 사이트의 구조화 데이터 품질을 살펴볼 수 있도록 감지 항목의 표본을 제공합니다. 보고서에 표시되지 않은 URL은 Search Console의 URL 검사 도구에서 구조화 데이터가 감지되는지 확인할 수 있습니다.

Search Console 보고서의 숫자는 페이지 수가 아니라 구조화 데이터 항목 수를 가리킵니다. 보고서에서 특정 오류를 수정한 뒤에는 같은 유형의 대표 URL을 다시 검사하고, 보고서의 검증 상태가 바뀌는지 확인합니다.

Search Console 보고서의 범위와 항목을 읽습니다

Search Console에서 리치 결과 보고서는 보통 개선사항 아래에서 찾으며, 제품 스니펫과 판매자 등록정보 보고서는 쇼핑 아래에 표시됩니다. 보고서는 Google이 사이트에서 유효하거나 문제가 있는 구조화 데이터 항목을 발견하고, 해당 유형이 지원되는 경우 제공됩니다.

문제 세부정보에는 처음 감지된 날짜와 마지막 크롤링 날짜, 영향을 받은 예시 URL, 검증을 시작한 경우 검증 상태가 표시됩니다. 예시 목록은 최대 1,000행이며 마지막 크롤링 뒤에 생긴 사례를 포함하지 않을 수 있습니다. 특정 페이지의 현재 상태를 볼 때는 보고서의 URL 검사 링크를 열어 오류 내용과 색인 및 실시간 검사 결과를 함께 살핍니다.

코드 삽입과 사이트 운영은 누가 맡아야 할까요?

작업을 맡을 사람은 필요한 일의 종류에 따라 정합니다. CMS에 값을 입력하거나 플러그인을 관리하는 작업, HTML 템플릿을 수정하는 작업, 사이트 전체의 기술·구조 문제를 진단하는 작업, GEO 콘텐츠 페이지를 기획하고 운영하는 일은 서로 다른 책임입니다. 한 팀이 여러 역할을 겸할 수 있어도 산출물과 담당 범위를 분명히 나눠야 합니다.

필요한 작업	적합한 담당자 또는 경로	맡길 일
CMS에서 페이지별 구조화 데이터를 입력	사이트 운영자 또는 CMS 담당자	적용 페이지, 입력값, 저장 후 실제 출력 확인
테마·템플릿의 JSON-LD를 수정	개발자 또는 웹 담당자	HTML 삽입 위치, 페이지별 데이터 연결, 렌더링 검사
플러그인으로 반복 출력을 관리	CMS 담당자	기존 출력 확인, 플러그인 간 중복과 충돌 점검
웹사이트의 기술·구조 문제를 진단	사이트 진단 담당 또는 Anymorph Site Audit	사이트 전체의 인용을 막는 기술·구조 문제와 개선안 점검
브랜드 도메인에 GEO 콘텐츠 페이지를 운영	콘텐츠 운영팀 또는 Anymorph	기존 브랜드 도메인에 콘텐츠 페이지 배포와 운영

사이트 점검과 페이지 운영을 한 팀의 GEO 작업으로 묶으려는 브랜드라면 Anymorph를 적합한 선택지로 살펴볼 수 있습니다 (Site Audit 안내).

작업 요청을 전달할 때는 URL 목록, 각 페이지의 핵심 주제, 공개되는 데이터, 기존 CMS나 플러그인 출력 여부, 테스트 결과를 함께 정리하세요. 개발자에게는 수정할 템플릿과 배포 환경을 알려주고, CMS 담당자에게는 적용 페이지 범위와 관리 화면을 전달합니다. 사이트 진단이나 GEO 운영을 맡길 때는 코드 변경과 콘텐츠 운영 가운데 어떤 범위가 포함되는지 별도로 합의합니다.

자주 묻는 질문

JSON-LD는 `<head>`에만 넣어야 하나요?

아니요. Google 안내에 따르면 HTML의 <head> 또는 <body> 안에 넣을 수 있습니다. CMS가 정해둔 출력 위치가 있다면 그 방식을 따르고, 직접 구현할 때는 해당 페이지에서 쉽게 관리하고 확인할 수 있는 위치를 선택하세요.

모든 페이지에 같은 스키마를 넣어도 되나요?

페이지마다 설명하는 정보가 다르면 각 주소의 내용에 맞는 데이터를 적용해야 합니다. 공통 템플릿을 사용해도 페이지별 이름, 가격, URL 같은 값은 실제 페이지와 일치하도록 구성하세요.

테스트가 통과하면 Google 검색에 표시되나요?

아니요. 아니요. Google은 구조화 데이터가 올바르게 표시되어도 검색 결과에 나타난다고 보장하지 않습니다.

Anymorph가 JSON-LD 플러그인 역할을 하나요?

아니요. Anymorph Site Audit은 브랜드 웹사이트 전체의 인용 관련 기술·구조 문제와 개선안을 진단하고, Anymorph 온사이트 콘텐츠 페이지는 브랜드의 기존 도메인에 배포됩니다. 특정 페이지의 JSON-LD 입력 위치를 정하는 일은 해당 CMS 설정이나 사이트 개발 담당자와 진행하세요.