스키마 마크업, 남은 것과 끝난 것

이 글은 《자영업자 SEO·GEO》 시리즈 8편이다. 7편에서 봇의 출입을 정리했고, 이번 편은 봇에게 보여줄 형식을 정리한다. 스키마, 공유 태그, 색인 알림까지 기술 작업의 마지막 편이다.

이 시리즈의 기술 작업은 이번 편으로 끝난다. 3편에서 채널을 등록했고, 7편에서 봇의 출입을 정했다. 남은 것은 봇과 공유 화면에 내 정보가 어떤 형식으로 보이는가의 문제다.

4편에서 확인했듯 이 영역은 통념의 거품이 큰 곳이다. FAQ 스키마는 리치 결과가 끝났고, 구조화 데이터는 순위 요인이라는 공식 문장이 없고, llms.txt는 구글이 불필요하다고 못박았다. 거품을 걷어내고 나면 자영업자가 실제로 손댈 기술 형식은 넷으로 줄어든다. 지역 업체용 스키마 하나, 글에 붙는 스키마 하나, 공유 미리보기 태그 한 벌, 그리고 색인을 재촉하는 신호 하나.

각각 한 번 설정하면 끝나는 작업이고, 코드가 나오지만 홈페이지 빌더를 쓰는 경우 설정 화면에 같은 항목이 있는 경우가 많다. 직접 못 하겠으면 이 글을 제작 업체에 그대로 전달하는 용도로 써도 된다.

남은 스키마 둘, 그리고 넘지 말아야 할 선

스키마 마크업은 페이지 내용을 기계가 읽기 좋게 정리한 라벨이다. 구글이 지원하는 유형이 25종 안팎인데, 지역 자영업자에게 실익이 있는 것은 두 개다.

첫째가 LocalBusiness다. 구글 공식 문서 기준으로 필수 속성은 상호(name)와 주소(address) 둘뿐이고, 전화·좌표·영업시간·가격대를 더하면 좋다. 요령은 하나, 가장 구체적인 하위 유형을 고르는 것이다. 정비소라면 LocalBusiness보다 AutoRepair가 낫다. 정비공업사 예시로 뼈대만 보이면 이렇다.

{
  "@context": "https://schema.org",
  "@type": "AutoRepair",
  "name": "○○자동차공업사 (사실표의 공식 상호)",
  "address": { "@type": "PostalAddress", "streetAddress": "...", "addressLocality": "광명시" },
  "telephone": "+82-2-000-0000",
  "openingHours": "Mo-Fr 09:00-18:00"
}

값의 출처는 당연히 3편의 브랜드 사실표다. 둘째가 Article로, 블로그 글이나 소식 페이지에 제목·작성자·발행일을 라벨링한다. 구글 문서 기준 필수 속성이 없는 느슨한 유형이라 부담 없이 넣을 수 있다.

이 작업의 금지선은 4편의 원칙과 같은 뿌리다. 화면에 없는 내용을 스키마에 넣지 않는다. 구글 구조화 데이터 정책은 실제 페이지 내용과 다른 마크업을 문제 삼고, 가짜 리뷰·평점 마크업은 신뢰를 통째로 흔든다. 스키마는 있는 내용의 라벨이지 없는 내용의 창조가 아니다. 그리고 한 페이지에 같은 유형을 중복으로 넣지 않는다.

작성 후에는 반드시 검증기를 돌린다. 구글이 제공하는 리치 결과 테스트에 페이지 주소를 넣으면 오류를 짚어 준다. 검증 안 된 스키마를 배포하는 것보다는 스키마가 없는 편이 낫다는 것이 공식 문서들의 일관된 결이다.

기대치도 4편 그대로 잡는다. 스키마를 넣는다고 순위가 오른다는 공식 근거는 없다. 이 작업의 실익은 검색과 AI가 내 가게의 이름·주소·영업시간을 잘못 읽을 확률을 줄이는 것, 그 이상도 이하도 아니다. 그 정도면 반나절 투자로 충분한 값이다.

카톡 미리보기는 왜 안 바뀌는가

캐시 때문이다. 답부터 적었지만 구조를 알면 해결은 5분이다.

카톡이나 페이스북에 링크를 붙이면 뜨는 미리보기 카드는 오픈그래프라는 공통 규격의 태그를 읽어 만들어진다. 페이스북이 만들었고 규격 문서 기준 필수 태그는 넷이다. 제목(og:title), 유형(og:type), 이미지(og:image), 대표 주소(og:url). 이 네 줄이 홈페이지 머리 부분에 있으면 페이스북, 인스타그램 메시지, 카카오톡, 문자 앱까지 대부분의 공유 화면이 한 번에 해결된다. 카카오 개발자 문서도 카톡의 링크 미리보기가 이 태그를 읽는다고 안내한다.

문제는 고친 뒤다. 홈페이지 대표 이미지를 바꿨는데 카톡에는 옛날 사진이 계속 뜨는 경험, 자영업자 단톡방의 단골 질문이다. 원인은 플랫폼들이 미리보기를 매번 새로 읽지 않고 저장해 두기 때문이고, 해결책은 공식 도구에 있다.

플랫폼	도구	사용법
카카오톡	카카오 개발자 사이트의 공유 디버거·캐시 초기화	카카오 계정 로그인 후 주소 입력, 캐시 초기화 버튼
페이스북·인스타	메타 공유 디버거	페이스북 로그인 후 주소 입력, 다시 스크랩 버튼

두 도구 모두 무료이고, 미리보기가 어떻게 보일지 사전 확인하는 용도로도 쓴다. 메타 쪽 문서에는 함정이 하나 더 적혀 있다. 이미지는 주소 단위로 저장되므로, 같은 파일명으로 이미지만 갈아끼우면 갱신이 안 될 수 있다. 이미지를 바꿀 때는 파일 이름 자체를 바꾸는 것이 확실하다.

미리보기는 사소해 보이지만 위치가 중요하다. 한국 자영업 손님의 상당수는 검색이 아니라 단톡방과 일대일 카톡으로 가게 링크를 처음 만난다. 그 첫 화면이 깨진 이미지나 무관한 문구라면, 3편에서 만든 사실표가 무색해진다. 오픈그래프 네 줄은 공유라는 유통 경로의 간판 정비다.

사장다리의 적용 상태

이 매체 자체의 적용 현황을 기록해 둔다. 시리즈의 원칙대로, 권하는 것은 해 본 것이어야 하기 때문이다.

사장다리는 글마다 Article 스키마와 오픈그래프 태그가 자동으로 생성되도록 만들어져 있다. 글을 발행하면 제목·요약·발행일이 스키마로 붙고, 공유 카드 이미지가 글 제목으로 자동 생성되며, 사이트맵에 주소가 추가된다. 처음 만들 때 하루 이틀 걸린 설정이고 이후로는 손이 가지 않는다. 자동화가 가능했던 이유는 값의 원본이 한 곳에 있기 때문이다. 글의 머리에 적는 제목과 요약이 스키마와 공유 태그의 재료로 그대로 흘러간다. 3편에서 사실표를 먼저 만들라고 한 것과 같은 구조다. 원본이 하나면 형식은 자동화되고, 원본이 흩어져 있으면 형식마다 손으로 맞춰야 한다.

LocalBusiness 스키마는 사장다리에는 해당이 없어서 넣지 않았다. 매체이지 지역 사업장이 아니기 때문이고, 이것도 4편의 원칙이다. 해당 없는 유형을 넣는 것은 없는 기능을 위한 작업이다. 대신 이 공장 쪽 채널 정비에 AutoRepair 스키마가 들어갈 예정이고, 그 적용기는 시리즈 뒤에서 사례로 다룬다.

검증기는 발행 파이프라인에 넣어 두지 않아 분기 점검 목록에 올려 두었다. 자동화해 둔 것도 규격이 바뀌면 조용히 깨질 수 있어서, 스키마도 7편의 robots처럼 분기 한 번 눈으로 보는 루틴이 필요하다.

IndexNow, 한 번 제출로 빙과 네이버에 알린다

마지막 형식은 콘텐츠가 바뀌었다고 검색엔진에 먼저 알리는 신호다.

기본 구조에서 검색 반영은 로봇이 다시 와 줄 때까지 기다리는 일이다. 네이버는 로봇 방문 후 최대 1주일을 공식 반영 주기로 안내한다. IndexNow는 이 대기를 뒤집는 개방 프로토콜이다. 새 글을 올리거나 정보를 고쳤을 때 내 쪽에서 검색엔진에 신호를 보내고, 공식 문서 기준으로 참여 엔진 한 곳에 제출하면 전체에 공유된다. 참여 목록에 빙과 함께 네이버가 들어 있다는 것이 한국 자영업자에게 이 프로토콜이 의미 있는 이유다.

설정은 개발 지식이 조금 필요하다. 열쇠 파일 하나를 사이트에 올려 소유를 증명하고, 콘텐츠가 바뀔 때마다 주소를 전송하는 연동을 건다. 워드프레스는 관련 플러그인이 있고, 빙 웹마스터 도구에도 제출 기능이 붙어 있다. 직접 구현이 어려우면 홈페이지 업체에 IndexNow 연동이라는 단어 하나로 요청하면 된다. 안 되면 건너뛰어도 치명적이지 않다. 사이트맵과 서치어드바이저의 수집 요청이라는 기본 경로는 이미 3편에서 깔아 뒀다.

여기까지가 기술의 전부다. 스키마 둘, 태그 네 줄, 디버거 두 개, 신호 하나. 다음 편부터는 형식이 아니라 내용으로 간다. 구글 평가자 가이드라인 원문을 펴 놓고, 신뢰라는 단어가 실제로 어떻게 정의되어 있는지 읽는다.

이 시리즈는 적용 기록이 쌓이는 순서대로 나간다. 정비업 사장의 협업과 보험 설계사 제휴는 문의로, 시리즈 전체를 따라 읽으려면 뉴스레터로 받아보면 된다.

워크북. 이 편을 AI에게 시키기

8편의 숙제는 스키마와 공유 태그의 생성·점검이다. 마크업 문법을 배울 필요가 없는 대표적인 영역이다. 값은 사실표에서 오고, 문법은 AI가 안다.

내 홈페이지의 기술 형식을 정비하자. 홈페이지는 [주소]야.
1. [주소]를 읽고 지금 들어 있는 스키마와 오픈그래프 태그를 찾아 목록으로 보여줘.
2. 브랜드 사실표를 줄게: [사실표 붙여넣기]
   내 업종에 맞는 가장 구체적인 LocalBusiness 하위 유형을 고르고,
   사실표 값만으로 스키마 초안을 만들어줘. 사실표에 없는 값은 비워 두고
   나에게 물어봐. 지어 넣지 마.
3. 오픈그래프 필수 4태그 초안을 만들어줘. 이미지가 없으면 어떤 이미지를
   준비해야 하는지 규격과 함께 알려줘.
4. 적용 후 내가 돌릴 검증 목록을 만들어줘: 구글 리치 결과 테스트,
   카카오·메타 공유 디버거 주소와 순서.

검수 포인트: 2번 지시문의 "지어 넣지 마"가 핵심이다. 본문에서 본 대로 화면에 없는 값이 스키마에 들어가는 것이 이 영역의 최악이고, AI는 빈칸을 그럴듯한 값으로 채우려는 습성이 있다. 완성 후 검증기 실행과 결과 화면 확인은 사람이 한다. 검증기가 오류를 뱉으면 그 화면을 그대로 붙여 넣고 고치게 시키면 된다.

출처

이 글의 규격·정책 서술은 전부 각사 공식 문서를 근거로 한다. 2026년 8월 접속을 확인했다.

출처 전체(11건) 펼치기

구조화 데이터

• 구조화 데이터 지원 목록 — Google Search Central
• Local Business 구조화 데이터 — Google Search Central
• Article 구조화 데이터 — Google Search Central
• 구조화 데이터 일반 정책 — Google Search Central
• 리치 결과 테스트 — Google

오픈그래프·공유 미리보기

• The Open Graph Protocol — ogp.me
• A Guide to Sharing for Webmasters — Meta for Developers
• Meta 공유 디버거
• 카카오톡 공유 문서 — Kakao Developers
• 카카오 공유 디버거·캐시 초기화 — Kakao Developers

IndexNow

• IndexNow FAQ(참여 엔진·공유 방식) — indexnow.org