AI가 인용하는 스키마 마크업 — FAQ·HowTo·Product 가이드

결론부터 말하면 이렇다. FAQ·HowTo 스키마의 리치 결과는 2026년 5월 7일부로 구글 검색에서 완전히 사라졌다. 그런데도 스키마 마크업을 계속, 심지어 더 정교하게 써야 하는 이유는 따로 있다. 화면에 예쁜 아코디언 박스를 띄우는 일과 AI 오버뷰·AI 모드·챗GPT 같은 답변형 검색이 내 콘텐츠를 정확히 읽어 인용하는 일은 완전히 다른 시스템이기 때문이다.

많은 사업자가 "리치 결과가 없어졌으니 스키마도 필요 없겠다"고 오해한다. 리치 결과 자격 심사와 AI의 콘텐츠 파싱은 애초에 별개의 파이프라인이라 이 오해부터 바로잡아야 한다. 이 글은 무엇이 사라졌고 무엇이 남았는지, 그리고 FAQPage·HowTo·Product를 비롯한 여러 스키마 타입을 AI가 인용하기 좋게 쓰는 법을 좋은 예와 나쁜 예로 짚는다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• FAQ 리치 결과는 2026년 5월 7일 검색 결과에서 완전히 사라졌고, 서치 콘솔의 관련 도구도 순차 종료된다
• 그렇다고 FAQPage·HowTo 스키마 자체가 무효는 아니다 — 화면 노출용이 아니라 AI가 문맥을 정확히 읽게 돕는 용도로 여전히 유효하다
• AI 인용 관점에서 스키마 타입의 우선순위는 Organization·Article·Product가 먼저이고 FAQPage·HowTo는 보조적 가치를 가진다
• 실제로 복사해서 쓸 수 있는 FAQ·HowTo·Product·Review JSON-LD 좋은 예·나쁜 예
• 스키마가 오히려 손해가 되는 흔한 실수와, 리치 결과 테스트 도구가 줄어든 뒤의 검증 방법

조금 더 풀어 말하면, 구조화 데이터는 원래 두 가지 일을 동시에 해왔다. 하나는 구글 검색 결과 화면에 별점·가격·아코디언 같은 리치 결과를 띄우는 일이고, 다른 하나는 검색엔진과 AI가 페이지 내용을 정확히 해석하도록 돕는 일이다. 최근 몇 년 사이 첫 번째 역할은 일부 타입에서 대부분 사라졌지만, 두 번째 역할은 AI 검색 시대에 오히려 더 중요해졌다.

특히 2026년 들어 구글이 AI 오버뷰와 AI 모드의 비중을 계속 키우면서, "화면에 예쁘게 보이는가"보다 "AI가 오해 없이 인용할 수 있는가"가 실무자들의 새로운 관심사로 떠올랐다. 이 글은 SEO를 잘 모르는 사업가도 오늘 바로 자기 홈페이지 코드에 적용할 수 있도록, 최신 정책 변화부터 실제 코드 예시까지 예시 중심으로 쉽게 정리한다.

특히 홈페이지 제작을 이제 막 마쳤거나 준비 중인 사업자라면 이 글이 더 유용하다. 개발 단계에서 스키마 마크업을 함께 설계하면 나중에 페이지를 하나씩 뜯어고치는 것보다 훨씬 적은 품으로 끝난다. 반대로 이미 운영 중인 홈페이지라면, 이 글의 체크리스트만으로도 지금 있는 코드의 문제를 상당 부분 찾아낼 수 있다.

왜 리치 결과가 사라졌는데 스키마 마크업 이야기를 또 하는가?

구글은 FAQ 리치 결과를 2023년 4월 한 차례 축소한 뒤, 같은 해 8월 "잘 알려진 권위 있는 정부·보건 기관 사이트"로만 노출 대상을 좁혔다. 그리고 2026년 5월 7일, 이마저도 전면 중단하며 FAQ 리치 결과는 검색 결과에서 완전히 자취를 감췄다.

HowTo 리치 결과도 사정은 비슷하다. 2023년 8월 데스크톱 검색에서 완전히 제거됐고, 한동안 구글 앱(모바일)에서만 일부 남아 있다가 지금은 그마저 사라졌다. 두 타입 모두 "먼저 축소, 그다음 완전 폐지"라는 같은 수순을 밟은 셈이다.

구글은 이 변화를 별도 블로그 글이나 공지 없이, 개발자 문서의 짧은 안내문으로만 알렸다. "FAQ rich results are no longer appearing in Google Search"라는 문장이 사실상 공식 발표의 전부였고, 배경 설명도 따로 없었다.

구글은 이어서 2026년 6월에는 서치 콘솔의 FAQ 검색어 표시 필터·리치 결과 보고서·리치 결과 테스트 지원을 순차로 없애고, 2026년 8월에는 FAQ 리치 결과 관련 서치 콘솔 API 지원까지 종료할 예정이다. 3년에 걸친 단계적 축소가 사실상 마무리 단계에 들어선 셈이다.

여기서 중요한 사실 하나. FAQPage·HowTo는 스키마.org에 여전히 유효한 타입으로 남아 있다. 이 코드를 페이지에 넣어도 에러가 나거나 불이익을 받지 않는다. 다만 구글 검색 결과 화면에 아코디언·단계별 카드 같은 시각적 리치 결과를 더 이상 만들어주지 않을 뿐이다.

리치 결과라는 "전시 효과"가 사라졌다고 해서 이 데이터를 읽는 존재까지 사라진 것은 아니다. AI 오버뷰, AI 모드, 그리고 챗GPT·퍼플렉시티 같은 외부 AI 검색은 여전히, 오히려 이전보다 더 적극적으로 페이지의 구조화 데이터를 참고 자료로 활용한다. 사람에게 보여주는 창구 하나가 닫혔을 뿐, 기계가 읽는 창구는 그대로 열려 있다고 이해하면 정확하다.

구글이 왜 별도 설명 없이 이런 결정을 내렸는지에 대한 공식 답은 없다. 다만 업계에서는 두 가지 배경을 유력하게 본다. 하나는 FAQ·HowTo 리치 결과가 스팸 남용의 표적이 되어 온 역사다. 실제 질문·답변 콘텐츠 없이 리치 결과만 노리고 형식적인 FAQ를 채워 넣는 사이트가 오랫동안 문제였다. 다른 하나는 AI 오버뷰 자체가 이미 질문-답변형 요약을 제공하기 때문에, 별도의 FAQ 아코디언이 검색 결과 화면에서 중복 요소로 여겨졌을 가능성이다.

이미 스키마 작업에 시간을 들인 운영자라면 "그동안의 작업이 낭비였나"라는 걱정이 들 수 있다. 결론적으로는 낭비가 아니다. 화면 노출이라는 보상 하나가 없어졌을 뿐, 콘텐츠를 구조화해 두는 습관 자체는 이제 소개할 AI 인용 영역에서 그대로 값어치를 한다.

아직 리치 결과가 살아있는 스키마 타입은 무엇인가?

FAQ·HowTo가 사라졌다고 해서 리치 결과 자체가 없어진 것은 아니다. 오히려 여전히 화면에 노출되는 타입을 정확히 알아야 자원을 어디에 우선 투입할지 판단할 수 있다.

상태	스키마 타입	화면 노출 형태
살아있음	Product / Offer	가격·재고·별점이 검색 결과에 함께 표시
살아있음	Review / AggregateRating	별점 스니펫
살아있음	Recipe	조리 시간·칼로리·평점 카드
살아있음	LocalBusiness	지도·영업시간·주소가 포함된 로컬 팩
살아있음	BreadcrumbList	검색 결과 URL 대신 탐색경로 표시
폐지됨	FAQPage	없음(2026년 5월 완전 폐지)
폐지됨	HowTo	없음(2023년 완전 폐지)

이 표에서 알 수 있듯, 구글이 정리하는 리치 결과는 "사용자가 즉시 행동으로 옮기는 정보" 위주로 재편되는 흐름이다. 가격·평점·위치·조리 시간처럼 숫자로 딱 떨어지는 정보는 살아남았고, 문답·절차처럼 본문을 대신 요약해 보여주는 성격의 리치 결과는 정리 대상이 된 셈이다.

이 흐름은 뒤에서 다룰 AI 인용 우선순위와도 맞닿아 있다. 구글이 화면에서 우대하는 타입(Product, Review, LocalBusiness)이, 공교롭게도 AI가 인용할 때도 우선하는 타입과 상당 부분 겹친다.

정책이 자주 바뀐다고 해서 스키마 작업 자체를 미룰 이유는 없다. 어떤 타입이 리치 결과 자격을 유지하든 폐지되든, 화면 콘텐츠를 충실히 구조화해 두는 습관은 다음 정책 변화에도 그대로 적용될 수 있는 가장 안전한 투자다. 반대로 특정 리치 결과 하나만 노리고 콘텐츠를 왜곡하는 전략은, 이번 FAQ·HowTo 사례처럼 정책이 바뀌는 순간 통째로 무의미해질 위험을 안고 있다.

리치 결과와 AI 인용은 왜 다른 시스템인가?

리치 결과는 구글이 정한 자격 요건(Eligibility Guidelines)을 통과해야 화면에 뜨는 "심사 통과형" 기능이다. 스팸 방지 정책, 콘텐츠 품질 기준, 그리고 이번처럼 정책 자체의 폐지까지, 구글이 언제든 켜고 끌 수 있는 스위치에 가깝다.

반면 AI 오버뷰·AI 모드가 답을 생성하는 과정은 다르다. 이 시스템은 검색 결과 후보 페이지들의 본문·표·목록·구조화 데이터를 종합적으로 읽어 요약형 답을 만든다. 리치 결과 자격이 있는지 없는지는 이 과정과 직접적인 관련이 없다. 실제로 리치 결과 자격을 한 번도 얻은 적 없는 페이지가 AI 오버뷰에는 인용되는 사례도 흔하다.

쉽게 비유하면 이렇다. 리치 결과는 "매장 진열대에 특별 태그를 붙여주는 것"이고, AI 인용은 "직원이 매장 안을 직접 둘러보고 손님에게 설명하는 것"이다. 태그가 없어졌다고 직원이 매장을 안 둘러보는 것은 아니다.

• 좋은 예: FAQ 리치 결과가 안 뜨더라도 FAQPage 마크업을 유지하고, 답변 텍스트를 화면에 그대로 노출되는 문장과 일치시킨다
• 나쁜 예: "어차피 리치 결과도 안 뜨는데"라며 FAQPage·HowTo 마크업 자체를 통째로 삭제해버린다

리치 결과가 없어졌다고 스키마를 지우는 것은, 간판을 뗐다고 매장 안내문까지 치우는 것과 같다. 안내문은 손님(AI)이 여전히 참고하는 자료다.

이루웹이 정리한 구글의 2026년 첫 공식 AI 검색 최적화 가이드에서도 다뤘듯, 구글은 AEO·GEO를 별도 기법이 아니라 SEO의 연장으로 규정했다. 구조화 데이터를 다루는 관점도 마찬가지다. 리치 결과용과 AI 인용용을 나눠 생각하지 말고, "정확하고 일관된 정보 제공"이라는 하나의 원칙으로 통합해서 접근하는 편이 실무적으로 맞다.

AI 오버뷰·AI 모드는 스키마 마크업을 실제로 어떻게 쓰는가?

구글은 구조화 데이터가 순위를 직접 올려주는 요소는 아니라고 여러 차례 밝혀왔다. 대신 페이지 내용을 모호함 없이 파싱하도록 돕는 역할을 한다고 설명한다. 이 원칙은 AI 오버뷰·AI 모드에도 그대로 이어진다.

업계 분석가들은 이를 "오답 방지 인프라"라는 표현으로 설명하기도 한다. AI가 페이지의 자연어 문장만으로 가격·평점·단계 순서 같은 정보를 추출하면 실수가 생기기 쉬운데, 구조화 데이터는 이런 정보를 명확한 형태(타입이 정해진 값)로 미리 정리해줘 AI가 잘못 해석할 여지를 줄인다는 것이다. 이는 구글의 공식 입장이라기보다 SEO 실무자들의 해석이라는 점을 감안해서 참고할 필요는 있다.

이 관점에서 보면 스키마 마크업의 역할은 두 단계로 나뉜다. 첫 단계는 "이 페이지가 어떤 종류의 콘텐츠인가"를 알려주는 것(Article인지, Product인지, LocalBusiness인지)이고, 두 번째 단계는 그 안의 핵심 값(가격, 평점, 답변, 단계)을 명확히 짚어주는 것이다. 많은 사이트가 두 번째 단계에만 집중하다 첫 단계를 놓친다.

여기서 반드시 지켜야 할 원칙이 하나 있다. 마크업에 적은 정보는 반드시 화면에 보이는 내용과 일치해야 한다. 화면에 없는 답을 스키마에만 적어 넣는 행위는 구글이 명확히 스팸 신호로 분류하는 대표적인 사례다.

구조화 데이터는 "새로운 정보를 지어내는 도구"가 아니라 "이미 화면에 있는 정보를 기계가 읽기 쉽게 정리하는 도구"다. 이 순서가 바뀌면 스팸으로 간주될 위험이 있다.

정리하면, AI 인용을 노리는 스키마 마크업의 목표는 화려한 뱃지를 다는 것이 아니라, AI가 실수 없이 내 콘텐츠를 인용하게 만드는 것이다. 이 관점을 갖고 나면 어떤 타입을 우선해야 할지도 자연히 정리된다.

이 원칙은 본문 글쓰기 방식과도 맞닿아 있다. AI가 인용하기 좋은 문장은 대체로 결론을 먼저 말하고, 근거를 뒤에 붙이는 구조를 갖는다. "홈페이지 유지보수 비용은 월 5만원에서 15만원입니다. 왜냐하면…"처럼 답을 먼저 던진 뒤 설명이 이어지는 문장은, 스키마가 없어도 AI가 추출하기 쉽다. 스키마는 이런 문장 구조에 명찰을 달아주는 역할이라고 이해하면 된다. 문장 자체가 애매하면 아무리 정교한 스키마를 씌워도 한계가 있다.

한 가지 더 짚을 부분은 엔티티 밀도다. "이 서비스", "그 방법"처럼 대명사로 뭉뚱그리기보다 "홈페이지 유지보수 서비스", "구글 서치 콘솔 등록 절차"처럼 구체적인 고유명사를 반복해 쓰면, AI가 문장과 스키마 값을 서로 연결 짓기 쉬워진다. 대명사를 줄이고 구체적인 이름을 반복하는 습관이 결국 스키마 효과를 극대화하는 지름길이다.

AI 인용에 유리한 스키마 타입의 우선순위는?

모든 스키마 타입이 AI 인용에 똑같이 기여하지는 않는다. 업계에서 통용되는 우선순위를 정리하면 아래 표와 같다.

우선순위	스키마 타입	AI 인용에서의 역할
1순위	Organization	브랜드를 지식그래프의 특정 개체(entity)와 연결, sameAs로 공식 채널 증명
1순위	Article / BlogPosting	작성자·발행일·수정일로 신뢰도(E-E-A-T) 신호 제공
1순위	Product	가격·재고·평점을 정형 데이터로 제공해 쇼핑형 질문에 활용
2순위	FAQPage	질문-답변 쌍을 명확히 구분, AI가 정답 문장을 골라내기 쉽게 함
2순위	HowTo	단계별 순서를 구조화, 절차형 질문에 답변 조립을 돕는 참고 자료
2순위	Review	실제 사용자 경험을 정형 데이터로 뒷받침, 신뢰 신호 보강

이 우선순위가 뜻하는 바는 명확하다. AI가 "이 사이트가 누구인지, 무엇을 파는지, 얼마나 믿을 만한지"를 먼저 판단하고, 그다음 세부 질문에 답할 때 FAQPage·HowTo 같은 보조 정보를 참고한다는 것이다.

Organization·Article·Product를 갖추지 않은 채 FAQPage만 화려하게 채워봐야 순서가 뒤바뀐 노력이 될 수 있다는 것이 이 우선순위의 핵심 메시지다. 순서대로, 기초부터 채우는 접근이 필요하다.

실무에서 흔히 나오는 질문은 "그럼 FAQPage는 아예 나중에 해도 되는가"이다. 그렇지는 않다. 우선순위는 투입 순서를 뜻할 뿐, 무시해도 된다는 뜻이 아니다. 여력이 없는 소규모 사이트라면 Organization·Article부터 완성하고, 여력이 있다면 FAQPage·HowTo·Review까지 순서대로 확장하는 식으로 접근하면 된다.

FAQPage 스키마, 2026년에도 써야 할까? 좋은 예와 나쁜 예는?

결론부터: 써야 한다. 다만 목적이 바뀌었을 뿐이다. 화면 노출용이 아니라 AI가 "이 페이지에 이런 질문의 답이 있다"는 것을 빠르게 파악하게 돕는 용도다.

작성 원칙은 세 가지다. 첫째, 화면에 실제로 보이는 질문·답변만 마크업한다. 둘째, 답변은 핵심 문장을 앞에 두고 짧고 직접적으로 쓴다. 셋째, 페이지마다 다른 페이지에도 있는 뻔한 질문을 복제하지 않는다.

나쁜 예부터 보면 문제가 뚜렷하다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "저희 회사는 어떤가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "저희는 최고의 서비스를 제공하는 믿을 수 있는 회사입니다."
      }
    }
  ]
}

이 예시의 문제는 명확하다. 질문이 검색 의도가 없는 애매한 문장이고, 답변에는 정작 아무 정보도 없다. 게다가 이 문답이 페이지 화면에 그대로 없다면 스팸 신호로 읽힐 위험까지 있다.

좋은 예는 이렇게 바뀐다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "홈페이지 유지보수 비용은 보통 얼마인가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "소규모 홈페이지의 월 유지보수 비용은 보통 5만원에서 15만원 사이입니다. 콘텐츠 업데이트 빈도와 보안 점검 범위에 따라 달라집니다."
      }
    },
    {
      "@type": "Question",
      "name": "유지보수 계약 없이 직접 관리해도 되나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "가능합니다. 다만 보안 업데이트와 백업 주기를 스스로 챙기지 못하면 순위 하락과 해킹 위험이 함께 커집니다."
      }
    }
  ]
}

두 번째 예시는 구체적인 수치, 명확한 조건, 그리고 화면 본문과 일치하는 문장을 담고 있다. AI가 "홈페이지 유지보수 비용이 얼마냐"는 질문을 받았을 때 이 문단을 그대로 인용하기 좋은 형태다.

FAQPage는 개수 채우기가 아니라 정밀도 싸움이다. 세 개를 넣더라도 화면과 정확히 일치하는 세 개가, 스무 개의 뭉뚱그린 질문보다 낫다.

한 가지 더 챙길 부분은 질문 문장 자체를 실제 검색어에 가깝게 쓰는 것이다. "질문1", "질문2" 식으로 이름만 다르게 붙이기보다, 사람들이 실제로 검색창에 입력할 법한 자연스러운 질문 형태로 다듬으면 AI가 사용자의 질문과 매칭하기 훨씬 쉬워진다.

HowTo 스키마는 완전히 쓸모없어졌나?

아니다. 리치 결과라는 시각적 보상은 사라졌지만, 절차형 질문("어떻게 하나요")에 대응하는 콘텐츠 구조로서의 가치는 남아 있다. AI가 "구글 서치 콘솔에 사이트를 등록하는 방법"처럼 단계가 있는 질문을 받으면, 잘 구조화된 HowTo 콘텐츠를 참고 자료로 삼기 쉽다.

나쁜 예는 단계가 뭉뚱그려지거나 순서가 애매한 경우다.

{
  "@type": "HowToStep",
  "text": "설정을 잘 확인하고 필요한 걸 등록한 다음 저장하면 됩니다."
}

이 문장은 무엇을 확인하고, 무엇을 등록하고, 어디서 저장하는지 전혀 알 수 없다. 사람이 읽어도, AI가 읽어도 구체적인 행동으로 옮길 수 없는 문장이다.

좋은 예는 한 단계에 한 가지 행동만 담고, 그 행동에 필요한 구체적 대상을 명시한다.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "구글 서치 콘솔에 홈페이지 등록하는 법",
  "totalTime": "PT10M",
  "step": [
    {
      "@type": "HowToStep",
      "name": "속성 추가",
      "text": "서치 콘솔에 접속해 'URL 접두어' 방식으로 내 홈페이지 주소를 입력하고 속성을 추가합니다."
    },
    {
      "@type": "HowToStep",
      "name": "소유권 확인",
      "text": "HTML 태그 방식을 선택해 발급된 메타 태그를 홈페이지의 head 영역에 붙여 넣고 확인 버튼을 누릅니다."
    },
    {
      "@type": "HowToStep",
      "name": "사이트맵 제출",
      "text": "설정 메뉴의 사이트맵 항목에서 sitemap.xml 주소를 입력해 제출합니다."
    }
  ]
}

단계마다 이름(name)과 구체적 행동(text)을 분리해 담고, totalTime처럼 소요 시간을 함께 적으면 AI가 "이 작업이 오래 걸리는 일인지 아닌지"까지 답변에 포함하기 쉬워진다. 특정 단계에 도구나 준비물이 필요하다면 tool, supply 속성으로 별도 명시하는 것도 도움이 된다.

사람이 읽을 때도 따라 하기 쉬운 콘텐츠는 결국 AI에게도 읽기 쉬운 콘텐츠라는 원칙이 여기서도 그대로 적용된다. 단계를 인위적으로 쪼개 개수를 늘리기보다, 실제로 분리된 행동 단위로만 나누는 것이 정확도를 높인다.

Product 스키마는 왜 AI 인용에서 최우선인가?

쇼핑·가격 비교형 질문에서 AI는 정형화된 숫자 데이터를 압도적으로 선호한다. "얼마인가", "재고가 있는가", "평점이 몇 점인가" 같은 질문은 본문 문장을 해석하는 것보다 스키마에 적힌 값을 그대로 읽는 편이 훨씬 정확하기 때문이다.

나쁜 예는 실제 값과 어긋나거나, 근거 없는 평점을 적는 경우다.

{
  "@type": "AggregateRating",
  "ratingValue": "5.0",
  "reviewCount": "500"
}

방문자 후기가 실제로는 20건뿐인데 500건이라고 적으면, 이는 허위 리뷰 데이터로 간주돼 페널티 대상이 될 수 있다. 가격도 마찬가지다. 실제 판매가와 스키마의 가격이 다르면 신뢰를 잃는다.

좋은 예는 실제 데이터와 정확히 일치시키고, 통화·재고 상태까지 명확히 표기한다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "홈페이지 제작 스타터 패키지",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "KRW",
    "price": "1500000",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "23"
  }
}

여기서 reviewCount는 실제 확보된 후기 수를 그대로 쓴다는 원칙이 가장 중요하다. 후기가 쌓이는 대로 값을 갱신하고, 절대 부풀리지 않는다. availability는 InStock, OutOfStock, PreOrder 같은 schema.org가 정한 표준 값 중에서 실제 상태에 맞는 값을 정확히 골라야 한다. 임의로 문자열을 지어 넣으면 파싱 자체가 실패할 수 있다.

가격 정보가 서비스형 상품처럼 유동적이라면, 고정값 대신 priceSpecification으로 범위를 표기하는 방법도 있다. 다만 이 경우에도 화면에 표시된 견적 범위와 반드시 일치시켜야 한다.

쇼핑몰을 운영 중이라면 구글 머천트 센터에 등록한 상품 피드와 홈페이지의 Product 스키마가 서로 다른 시스템이라는 점도 알아둘 필요가 있다. 머천트 센터 피드는 쇼핑 광고·쇼핑 탭에, 페이지의 Product 스키마는 일반 검색 결과와 AI 인용에 각각 쓰인다. 두 값이 다르면 어느 쪽이 맞는지 신뢰도가 흔들리므로, 가격과 재고 상태는 두 곳 모두에서 항상 같은 값으로 유지해야 한다.

여러 스키마 타입을 한 페이지에 함께 써도 되는가?

당연히 된다. 오히려 실무에서는 한 페이지에 Article + FAQPage + BreadcrumbList처럼 여러 타입을 동시에 넣는 경우가 훨씬 많다. 이 글의 페이지 역시 실제로는 BlogPosting과 BreadcrumbList가 함께 들어간다.

여러 타입을 합칠 때는 @graph 구조를 쓰면 관리가 깔끔해진다.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "AI가 인용하는 스키마 마크업",
      "author": { "@type": "Person", "name": "이루웹 편집팀" }
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "스키마 마크업이 순위를 올려주나요?",
          "acceptedAnswer": { "@type": "Answer", "text": "직접적인 순위 요인은 아니지만, 콘텐츠 이해를 도와 간접적으로 기여합니다." }
        }
      ]
    }
  ]
}

주의할 점은 같은 타입을 페이지 하나에 중복으로 넣지 않는 것이다. Organization 정보를 페이지마다 조금씩 다른 값으로 반복해서 넣으면, 어떤 값이 진짜인지 AI와 검색엔진 모두 혼란을 겪는다. 사이트 전역에 공통으로 쓰는 정보(Organization, WebSite)는 레이아웃 단위에서 한 번만 선언하고, 페이지별로 달라지는 정보(Article, FAQPage, Product)만 개별 페이지에 넣는 구조가 유지·보수에도 유리하다.

네이버 같은 국내 플랫폼에도 같은 원칙이 통하나?

구글의 리치 결과·AI 오버뷰 정책은 구글 검색과 구글 AI 제품에 한정된 이야기다. 네이버 블로그(blog.naver.com)처럼 네이버가 직접 운영하는 플랫폼 안에서는 스키마.org 마크업을 넣어도 네이버 자체 검색 로직에 미치는 영향이 제한적이다. 네이버는 자사 플랫폼 콘텐츠를 별도의 내부 신호로 판단하기 때문이다.

반면 워드프레스·자체 도메인 홈페이지처럼 네이버 외부에 있는 사이트라면 이야기가 다르다. 이런 사이트는 네이버 서치어드바이저에 등록되고, 네이버도 구조화 데이터를 일부 참고하는 것으로 알려져 있어 이 글의 원칙이 그대로 적용된다. 결국 내 콘텐츠가 어느 플랫폼에서 서비스되는지에 따라 스키마의 효용이 달라진다는 점을 먼저 구분해야 한다.

Review 스키마는 왜 따로 다뤄야 하는가?

Review와 AggregateRating은 Product 안에 포함되기도 하지만, 후기 콘텐츠 자체를 다루는 페이지라면 독립적인 Review 스키마로 접근하는 편이 정확하다. AI는 "이 업체 후기가 어떤가요" 같은 질문에 답할 때, 실제 리뷰 텍스트와 작성자 정보를 함께 참고하는 경향이 있다.

나쁜 예는 리뷰 작성자를 익명 처리하면서 동시에 과장된 문구만 나열하는 경우다.

{
  "@type": "Review",
  "author": "익명",
  "reviewBody": "정말 최고예요! 완벽합니다!"
}

좋은 예는 실제 후기 내용을 요약해 담고, 평점과 날짜까지 함께 표기한다.

{
  "@context": "https://schema.org",
  "@type": "Review",
  "author": { "@type": "Person", "name": "김OO" },
  "datePublished": "2026-06-12",
  "reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
  "reviewBody": "홈페이지 제작 후 3개월 만에 검색 유입이 늘었습니다. 특히 문의 폼 개선이 체감됐습니다."
}

실제로 확보한 후기 텍스트만 사용한다는 원칙은 앞서 다룬 브랜드 톤 원칙과도 그대로 이어진다. 후기와 백링크는 품질 중심으로 제대로 쌓아야 진짜 신뢰 자산이 된다는 점에서, 스키마 표기 역시 과장 없이 있는 그대로 옮기는 것이 가장 안전하고 효과적인 방법이다.

또 하나 자주 나오는 실수는 직원이나 대표가 직접 작성한 후기를 고객 후기처럼 표기하는 것이다. 이런 경우 표면적으로는 스키마 문법에 문제가 없어 보여도, 실제 이용자가 아닌 사람이 작성한 후기라는 사실이 드러나면 신뢰도에 큰 타격을 준다. 후기는 반드시 실제 이용 고객에게서 받은 내용만 옮겨야 하고, 요약하거나 다듬더라도 원래 맥락을 왜곡해서는 안 된다.

Organization·저자 스키마로 AI가 브랜드를 알아보게 하려면?

FAQPage·HowTo·Product·Review가 "무엇을 답하는가"의 영역이라면, Organization과 저자(Person) 스키마는 "누가 답하는가"의 영역이다. AI는 출처가 불분명한 정보보다 실체가 명확한 주체가 말한 정보를 우선한다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "이루웹",
  "url": "https://iruweb.com",
  "sameAs": [
    "https://www.instagram.com/iruweb",
    "https://blog.naver.com/iruweb"
  ]
}

sameAs에는 회사의 공식 소셜 채널·외부 프로필 주소를 넣어 "이 도메인과 이 채널들이 같은 주체"라는 것을 AI와 검색엔진이 연결 짓게 돕는다. 블로그 글의 저자 정보도 마찬가지로, 이름만 적기보다 실제 프로필 링크까지 함께 제공하는 편이 신뢰도 평가에 유리하다.

익명으로 발행된 콘텐츠는 구조화 데이터를 아무리 잘 써도 신뢰도 평가에서 근본적으로 불리하다는 점을 기억해야 한다. 스키마는 이미 존재하는 신뢰를 기계가 읽기 쉽게 번역해줄 뿐, 없는 신뢰를 만들어주지는 못한다. E-E-A-T가 왜 중요한지를 함께 살펴보면 이 원칙이 더 명확해진다.

블로그 글이라면 Article 스키마의 author 속성에 Organization이 아니라 실제 작성자를 가리키는 Person 타입을 넣는 것이 좋다. 여러 명이 함께 운영하는 팀 블로그라도, 편집팀이나 대표 명의를 명확히 밝히고 그 인물의 실제 프로필과 연결하는 편이 익명보다 훨씬 유리하다. 회사 소개 페이지에는 Organization을, 개별 글에는 Person을 각각 짝지어 쓰는 구조가 가장 일반적이다.

지역 사업자라면 LocalBusiness 스키마를 어떻게 써야 하나?

병원·카페·학원처럼 오프라인 매장을 함께 운영하는 사업자라면 LocalBusiness 스키마가 별도로 필요하다. 특히 지역 검색·지도형 질문에서 AI가 참고하는 핵심 데이터이기 때문이다.

나쁜 예는 주소나 영업시간이 실제 매장 정보와 다르거나, 여러 페이지에 서로 다른 상호명이 흩어져 있는 경우다.

{
  "@type": "LocalBusiness",
  "name": "이루웹스튜디오",
  "address": "서울 어딘가"
}

좋은 예는 주소·영업시간·연락처를 실제와 완전히 일치시키고, 다른 페이지·다른 플랫폼의 상호 표기와도 통일한다.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "이루웹",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 000",
    "addressLocality": "서울",
    "addressRegion": "강남구",
    "postalCode": "06000"
  },
  "openingHours": "Mo-Fr 09:00-18:00",
  "telephone": "+82-2-000-0000"
}

여기서 핵심은 NAP(상호명·주소·전화번호) 일관성이다. 구글 비즈니스 프로필, 홈페이지, 네이버 플레이스에 적힌 상호명·주소 표기가 조금씩 다르면 AI와 검색엔진 모두 같은 업체인지 확신하지 못하고 신뢰도를 낮게 매길 수 있다.

지점이 여러 곳인 사업자라면 지점마다 별도의 LocalBusiness 항목을 만들어야 한다. 본사 정보 하나로 모든 지점을 퉁치면, "강남점 영업시간이 어떻게 되나요" 같은 지역 특정 질문에 AI가 정확한 답을 고르기 어려워진다. 지점별 페이지를 따로 두고, 각 페이지에 그 지점만의 주소·전화번호·영업시간을 개별적으로 마크업하는 것이 정석이다.

스키마 마크업이 오히려 손해가 되는 실수는?

가장 흔하고 치명적인 실수는 화면에 없는 내용을 스키마에만 적는 것이다. 구글은 이를 명확히 스팸 신호로 규정한다. FAQ 답변이 스키마에는 있는데 실제 페이지를 아무리 스크롤해도 그 문장이 안 보인다면, 이는 사용자를 속이는 행위로 해석될 수 있다.

두 번째 실수는 날짜 정보의 방치다. dateModified 값을 실제 수정 시점과 다르게 방치하거나, 내용은 그대로인데 날짜만 최신으로 바꾸는 경우다. 이런 불일치는 AI가 정보의 신선도를 잘못 판단하게 만들고, 발각되면 신뢰도에 오히려 마이너스가 된다.

세 번째 실수는 모든 페이지에 억지로 FAQ를 끼워 넣는 것이다. 실제 질문-답변 콘텐츠가 없는 페이지에도 형식만 갖춘 FAQPage를 넣으면, 정작 필요한 페이지의 신호까지 희석된다.

체크리스트: 스키마의 모든 값은 "화면에서 그대로 확인 가능한가"라는 질문 하나로 검증할 수 있다. 이 질문에 "아니오"가 나오면 그 값은 지우거나 화면 내용을 먼저 고쳐야 한다.

넷째로, 오래된 스키마 타입을 그대로 방치하는 경우도 있다. schema.org 어휘는 계속 갱신되므로, 1년 이상 손대지 않은 스키마라면 최신 속성명이 바뀌지 않았는지 한 번쯤 점검할 필요가 있다.

다섯째, JSON 문법 오류도 뜻밖에 자주 나온다. 쉼표 하나가 빠지거나 따옴표가 짝이 안 맞으면 전체 스크립트가 통째로 무효 처리된다. 페이지 하나에 여러 타입의 스키마를 겹쳐 넣을 때 이런 실수가 특히 잦으므로, 발행 전 문법 검증은 건너뛰지 않는 것이 좋다.

여섯째, 여러 페이지에서 서로 충돌하는 Organization 정보를 넣는 경우다. 홈페이지의 회사 소개 페이지와 블로그 하단의 회사 정보가 다른 주소·전화번호를 담고 있다면, 이는 앞서 다룬 NAP 불일치 문제와 똑같이 신뢰도를 흔든다. 전역 정보는 한 곳에서만 선언하고 페이지마다 재사용하는 방식으로 관리해야 이런 실수를 막을 수 있다.

일곱째, 홈페이지 제작 도구나 플러그인이 기본으로 넣어주는 스키마를 그대로 방치하는 경우도 흔하다. 자동 생성된 스키마는 종종 실제 업종과 무관한 예시 값이나, 이미 사용하지 않는 옛 서비스명을 그대로 담고 있다. 도구가 자동으로 넣어줬다고 안심하지 말고, 실제 값과 일치하는지 한 번은 직접 코드를 열어 확인해야 한다.

검증은 어떻게 하나? 리치 결과 테스트가 줄어든 뒤

구글이 FAQ 관련 리치 결과 테스트 지원을 2026년 6월부터 순차 종료하면서, "내 스키마가 맞게 작성됐는지" 확인하는 방법도 달라졌다. 그렇다고 검증 수단이 아예 없어진 것은 아니다.

• 스키마.org 문법 검증: 구글 도구와 별개로 스키마.org 자체의 어휘·구조 오류는 여전히 온라인 검증 도구로 확인할 수 있다
• 서치 콘솔의 다른 구조화 데이터 보고서: Product·Review 등 아직 지원되는 타입은 기존처럼 서치 콘솔에서 오류를 확인한다
• 개발자 도구로 직접 확인: 브라우저에서 페이지 소스의 application/ld+json 스크립트를 직접 열어, 화면에 보이는 문장과 값이 일치하는지 눈으로 대조한다
• AI 검색 결과 직접 확인: 챗GPT·퍼플렉시티·구글 AI 모드에 실제 질문을 던져, 내 페이지가 인용되는지 서치 콘솔 AI 성능 보고서와 함께 주기적으로 살펴본다

이 중에서도 가장 실전적인 방법은 마지막 것이다. 도구가 "문법이 맞다"고 판정해주는 것과, 실제로 AI가 그 문장을 골라 답하는 것은 별개의 문제이기 때문이다. 검증은 한 번으로 끝나는 작업이 아니라, 콘텐츠를 업데이트할 때마다 반복해야 하는 루틴으로 자리 잡아야 한다.

작은 사업자라면 매번 정교한 점검 체계를 갖추기는 어렵다. 현실적인 대안은 콘텐츠를 새로 발행하거나 가격·정책을 바꿀 때마다 그 페이지의 스키마만 함께 열어보는 습관을 들이는 것이다. 한 달에 한 번, 최근 바뀐 페이지 목록만 훑어보며 스키마 값과 화면 내용이 여전히 일치하는지 확인하는 정도로도 대부분의 불일치는 미리 걸러낼 수 있다.

업종별로는 어떻게 적용하나?

같은 원칙이라도 업종마다 우선순위가 다르다. 아래는 대표적인 업종의 적용 순서다.

• 치과·병원: Organization·LocalBusiness(진료 항목·주소·영업시간)와 FAQPage(비용·통증·회복 기간 질문)를 우선하고, Product성 시술 가격은 통화·범위를 명확히 표기한다
• 쇼핑몰: Product·AggregateRating을 최우선으로 채우고, FAQPage는 배송·교환 정책처럼 반복 문의되는 항목에 집중한다
• 학원·교육 서비스: Organization과 Article(강사 프로필·커리큘럼 설명)을 먼저 채운 뒤, HowTo는 "수강 신청 방법" 같은 실제 절차 콘텐츠에만 적용한다
• 세무사무소·법률 서비스: Organization·Person(자격증·경력)을 우선하고, FAQPage는 상담 비용·절차 문의에 집중한다. 시술·가격처럼 확정된 숫자가 없는 업종일수록 Article의 저자 신뢰도가 더 중요해진다
• 카페·소규모 매장: LocalBusiness(영업시간·주소)를 최우선으로 채우고, 메뉴 가격은 Product·Menu 관련 속성으로 보조한다

업종에 상관없이 지켜야 할 공통 원칙은 하나다. 화면에 있는 콘텐츠부터 충실히 채우고, 스키마는 그 콘텐츠를 기계가 읽기 쉽게 번역하는 마지막 단계로 삼는다는 것이다. 순서를 거꾸로 하면 아무리 정교한 스키마도 속 빈 강정이 된다.

예를 들어 치과 홈페이지라면, 순서는 이렇다. 먼저 병원 소개 페이지에 Organization과 LocalBusiness를 채워 "어디에 있는 어떤 병원인가"를 명확히 하고, 그다음 진료 항목별 페이지에 시술 정보를 Product 형태로 정리한다. 마지막으로 상담 전화가 많이 오는 질문(비용, 통증, 회복 기간)만 골라 FAQPage로 보강하는 순서다. 이 순서를 지키면 페이지가 늘어나도 관리 부담이 크게 늘지 않는다.

발행 전에는 다음을 확인한다.

• 스키마에 적은 모든 텍스트가 화면에서 그대로 확인되는가
• Organization·저자 스키마에 실제 채널 주소가 들어 있는가
• 가격·평점·재고 값이 현재 실제 값과 일치하는가
• dateModified가 실제 수정 시점을 반영하는가
• FAQPage·HowTo가 실제 질문·절차 콘텐츠가 있는 페이지에만 적용됐는가
• JSON-LD 문법 오류가 없는지 스키마.org 검증 도구로 확인했는가
• LocalBusiness가 있다면 다른 플랫폼과 NAP 정보가 일치하는가

이 일곱 가지만 통과해도 대부분의 흔한 실수는 걸러진다.

스키마 마크업 작업은 실제로 얼마나 걸리나?

규모에 따라 크게 다르다. 페이지 수가 적은 소규모 홈페이지라면 Organization·Article 기본 스키마는 하루 이틀 안에도 직접 채울 수 있는 수준이다. schema.org 문서와 이 글의 예시 코드를 그대로 응용해 자기 사업 정보로 값만 바꾸면 되기 때문이다.

반면 상품이 수백 개인 쇼핑몰이나, 지점이 여러 곳인 프랜차이즈라면 이야기가 다르다. 페이지마다 값이 달라지는 Product·LocalBusiness 정보를 하나하나 손으로 넣는 것은 비효율적이고 실수도 잦다. 이런 경우에는 데이터베이스 값을 자동으로 스키마에 반영하는 템플릿 구조를 개발 단계에서 미리 설계해두는 것이 정답이다. 상품 정보가 바뀌면 스키마도 자동으로 함께 바뀌게 만들어, 사람이 값을 일일이 갱신하다 놓치는 일을 원천적으로 막는 방식이다.

스키마 마크업은 "한 번 넣고 끝내는 작업"이 아니라 "콘텐츠가 바뀔 때마다 함께 갱신되는 시스템"으로 설계하는 것이 장기적으로 훨씬 적은 노력이 든다.

직접 코드를 다루기 부담스럽거나, 여러 페이지에 걸쳐 일관되게 설계할 여력이 없다면 이 단계에서 전문가의 도움을 받는 편이 시간을 아끼는 길이다. 특히 홈페이지를 새로 제작하는 시점이라면, 완성 후에 스키마를 따로 얹기보다 설계 단계부터 함께 반영하는 쪽이 나중에 페이지를 다시 손보는 수고를 크게 줄여준다.

AI 모드·AI 오버뷰에서 내 스키마가 실제로 쓰였는지 실험해보는 법

검증 도구가 "문법 오류 없음"이라고 알려주는 것과, 실제로 AI가 내 콘텐츠를 골라 답하는 것은 다른 문제라고 앞서 짚었다. 이를 직접 확인하려면 아래 순서로 간단한 실험을 해볼 수 있다.

1. 스키마를 새로 다듬은 페이지 중 핵심 질문 하나를 고른다(예: "홈페이지 유지보수 비용은 얼마인가")
2. 그 질문을 구글 AI 모드, 챗GPT, 퍼플렉시티 등 서로 다른 AI 검색에 각각 입력해본다
3. 답변에 내 사이트가 인용되는지, 인용된다면 어떤 문장이 쓰였는지 기록한다
4. 인용된 문장이 스키마에 적은 값과 일치하는지, 혹은 다른 문장이 쓰였는지 비교한다
5. 인용이 안 되거나 오답이 섞여 있다면, 그 페이지의 본문 문장과 스키마 값을 함께 다시 손본다

이 과정을 한 번에 완벽하게 끝내려 하지 않아도 된다. 신제품 출시나 정책 변경처럼 콘텐츠가 크게 바뀌는 시점마다 반복하면, 시간이 지날수록 AI가 내 사이트를 정확히 인용하는 빈도가 자연스럽게 늘어나는 것을 체감할 수 있다.

핵심만 다시 정리하면

이 글에서 다룬 내용을 한 번에 훑으면 다음과 같다. FAQ 리치 결과는 2026년 5월 완전히 사라졌고 HowTo는 이미 2023년에 사라졌지만, 두 타입 모두 스키마.org 규격 자체는 유효하다. 화면 노출이라는 보상은 없어졌어도, AI 오버뷰·AI 모드·외부 AI 검색이 콘텐츠를 정확히 읽어내는 데는 여전히 도움이 된다.

AI 인용 관점에서는 Organization·Article·Product처럼 브랜드 실체와 핵심 거래 정보를 담는 타입을 먼저 채우고, FAQPage·HowTo·Review는 그다음 순서로 보강하는 것이 효율적이다. 어떤 타입을 쓰든 가장 중요한 원칙은 하나로 귀결된다. 스키마에 적은 값은 반드시 화면에 보이는 실제 내용과 일치해야 한다. 이 원칙만 지켜도 대부분의 손해 보는 실수를 피할 수 있다.

마지막으로, 검증 도구가 줄어드는 흐름 속에서는 직접 AI 검색에 질문을 던져 인용 여부를 확인하는 습관이 가장 확실한 대안이다. 도구에 의존하기보다 사람이 직접 결과를 눈으로 확인하는 루틴을 만드는 것이 2026년 이후 스키마 마크업 운영의 새로운 기본기가 됐다.

자주 묻는 질문

FAQ 리치 결과가 없어졌는데 FAQPage 스키마를 계속 써야 하나요?

그렇다. 화면에 아코디언이 뜨지는 않지만, AI 오버뷰·AI 모드·외부 AI 검색이 질문-답변 구조를 파악하는 데는 여전히 도움이 된다. 다만 화면에 실제로 있는 질문·답변만 정확히 마크업해야 한다. 형식만 갖춘 FAQ를 억지로 늘리기보다, 실제로 자주 들어오는 문의 몇 개를 정확하게 담는 편이 훨씬 낫다.

HowTo 스키마도 이제 완전히 의미가 없나요?

의미가 없지는 않다. 시각적 리치 결과라는 보상은 사라졌지만, 절차형 질문에 대응하는 콘텐츠 구조로서 AI 답변 조립에 참고 자료가 될 수 있다. 단계를 명확히 나누고 구체적으로 쓰는 것이 핵심이며, 단계 수를 인위적으로 늘리기보다 실제 행동 단위 그대로 정리하는 편이 정확도를 높인다.

내 스키마가 실제로 AI 오버뷰에 인용됐는지 어떻게 확인하나요?

가장 확실한 방법은 실제 관련 질문을 챗GPT·퍼플렉시티·구글 AI 모드에 직접 입력해 결과를 확인하는 것이다. 이와 함께 서치 콘솔의 AI 성능 보고서로 노출·클릭 추이를 함께 살펴보면 더 정확히 판단할 수 있다. 한두 번 확인으로 끝내지 말고, 콘텐츠를 업데이트할 때마다 같은 질문으로 반복 확인하는 습관을 들이는 것이 좋다.

스키마 마크업이 검색 순위를 직접 올려주나요?

아니다. 구글은 구조화 데이터가 직접적인 순위 요인은 아니라고 밝혀왔다. 다만 페이지 내용을 정확히 이해하도록 돕는 역할을 하고, 이는 결과적으로 정확한 인용과 신뢰도 평가에 간접적으로 기여한다. 순위를 직접 올려주는 마법 같은 도구로 오해하지 말고, 이미 좋은 콘텐츠의 가치를 온전히 전달하는 보조 장치로 이해하는 편이 정확하다.

처음 시작한다면 어떤 스키마부터 채워야 하나요?

Organization부터 시작하는 것이 순서상 맞다. 브랜드 실체를 명확히 한 뒤 Article(저자·발행일)을 갖추고, 그다음 업종 특성에 맞게 Product나 FAQPage, 지역 사업자라면 LocalBusiness를 채우는 순서가 효율적이다. 한꺼번에 모든 타입을 완벽하게 채우려 하기보다, 이 순서대로 하나씩 늘려가는 편이 현실적이다.

리치 결과 테스트가 줄어들면 스키마 작업 자체가 무의미해지지 않나요?

아니다. 리치 결과 테스트는 어디까지나 문법과 화면 노출 자격을 확인하는 도구일 뿐이다. 스키마 마크업의 본질적인 목적, 즉 AI와 검색엔진이 콘텐츠를 정확히 해석하도록 돕는 역할은 도구의 존재 여부와 무관하게 계속 유효하다. 도구가 줄어들수록 오히려 화면 내용과 스키마 값을 직접 대조하는 수작업 점검의 비중이 커진다고 보면 된다.

지점이나 상품이 자주 바뀌는데 스키마도 매번 손으로 고쳐야 하나요?

수작업으로 매번 고치는 것은 비효율적이고 실수도 잦다. 홈페이지 구조를 설계할 때 상품·지점 정보가 바뀌면 스키마 값도 자동으로 함께 갱신되도록 템플릿화해두는 것이 장기적으로 훨씬 안전하다. 이미 운영 중인 사이트라면, 최소한 정보가 자주 바뀌는 페이지만이라도 우선적으로 자동화하는 것을 권한다.

---

스키마 마크업은 한 번 세팅해두고 끝나는 작업이 아니라, JSON-LD 기초부터 최신 정책 변화까지 꾸준히 손봐야 하는 살아있는 작업입니다. 화면 콘텐츠와 스키마 값을 계속 맞추고, AI 검색 결과에서 실제로 인용되는지 주기적으로 점검하는 루틴이 필요합니다.

혼자 챙기기 부담스러우시다면, 이루웹의 AEO·GEO 컨설팅과 SEO 최적화 홈페이지 제작에서 구조화 데이터 설계부터 AI 검색 대응까지 함께 도와드리고 있습니다. 우리 사이트에 맞는 스키마 우선순위가 궁금하시다면 이루웹에 편하게 문의해 주시면, 현재 상태를 진단해 드리고 실행 가능한 우선순위를 함께 정리해 드리겠습니다.