[구글 SEO 14] 구조화 데이터(JSON-LD)로 검색결과 풍성하게

설명문이 검색 결과의 문장을 다듬는 일이라면, 구조화 데이터는 검색 결과의 겉모습 자체를 풍성하게 만드는 일이다. 별점, 작성자, 날짜, 게시판 토론 정보 같은 게 검색 결과에 붙는 걸 본 적 있을 텐데, 그게 다 구조화 데이터의 결과다. 이번 편은 그중 가장 다루기 좋은 형식인 JSON-LD를 커뮤니티 관점에서 정리한다.

구조화 데이터는 눈에 잘 안 띄는 작업이지만, 검색 결과에서 남들과 다른 모양으로 눈에 띄게 해주고, 요즘은 AI 검색이 내 페이지를 이해하는 데도 쓰인다. 신생 사이트일수록 이 작은 차별화가 클릭률에 도움이 된다.

1. 구조화 데이터란 무엇인가

구조화 데이터는 이 페이지가 무엇에 관한 것인지를 검색엔진이 기계적으로 이해할 수 있게 정리해 붙이는 부가 정보다. 사람은 화면을 보면 이게 글이고 저게 작성자고 저기가 댓글인지 바로 알지만, 기계는 HTML만 봐선 헷갈린다. 그 의미를 명시적으로 알려주는 게 구조화 데이터다.

표준은 Schema.org라는 공통 어휘를 쓴다. 글은 Article, 게시판 토론은 DiscussionForumPosting, 경로 표시는 BreadcrumbList, 사이트 운영 주체는 Organization 같은 식으로 타입이 정해져 있다. 이 표준 어휘로 이건 글이고 저건 작성자라고 라벨을 붙이는 것이다.

구글은 이 정보를 읽고, 조건이 맞으면 검색 결과를 리치 결과라 부르는 풍성한 형태로 보여준다. 작성자와 날짜가 붙거나, 토론 글임을 표시하거나, 답변 수를 보여주는 식이다. 같은 순위라도 더 눈에 띄니 클릭률에서 유리하다.

조금 더 감을 주면 JSON-LD는 사람 눈엔 안 보이는 정보다. 화면에는 아무 변화가 없고 오직 검색엔진과 기계만 읽는다. 그래서 디자인을 건드리지 않고도 페이지의 의미를 풍부하게 실을 수 있다는 게 장점이자, 반대로 실제 화면과 어긋나기 쉽다는 게 위험이다. 안 보이니까 대충 넣고 잊기 쉬운데, 안 보인다고 안 걸리는 게 아니다.

배경을 조금 더 주면, 구조화 데이터는 검색을 넘어 점점 더 중요해지고 있다. 음성 비서, AI 챗봇, 각종 자동화가 웹페이지를 이해할 때 이 구조화 정보에 크게 의존한다. 즉 사람이 아니라 기계가 웹을 읽는 시대에, 내 페이지가 무엇인지를 기계어로 정확히 말해주는 통로가 구조화 데이터다. 지금 안 해도 손해는 아니지만, 해두면 미래의 여러 창구가 열린다.

2. 왜 JSON-LD인가

구조화 데이터를 넣는 방식은 여러 가지가 있지만, 구글이 권장하고 나도 쓰는 건 JSON-LD다. 이건 head나 본문 어딘가에 스크립트 블록 하나로 구조화 정보를 통째로 넣는 방식이다. HTML 마크업 사이사이에 속성을 끼워 넣는 옛 방식과 달리, 데이터가 한곳에 모여 있어 관리가 쉽다.

가장 큰 장점은 화면 렌더링과 분리된다는 점이다. 디자인을 바꿔도 구조화 데이터는 그대로고, 반대로 구조화 데이터를 고쳐도 화면은 안 건드려도 된다. 서버에서 글 데이터를 이미 갖고 있으니, 그걸로 JSON-LD 블록을 만들어 페이지에 끼워 넣기만 하면 된다.

서버 사이드 렌더링을 하는 사이트라면 이 블록을 서버 응답 HTML에 함께 실어 보내는 게 좋다. 그래야 봇이 페이지를 받는 즉시 구조화 정보를 읽는다. 자바스크립트로 나중에 붙이면 렌더링에 의존하게 되니, 처음부터 서버 응답에 포함시키는 게 안전하다.

실무적으로는 페이지 템플릿 단위로 생성 로직을 만들어 두는 게 편하다. 글 상세 페이지 템플릿이면 그 글의 데이터를 받아 DiscussionForumPosting 블록을 찍어내고, 게시판 목록이면 목록에 맞는 마크업을 찍는 식이다. 페이지마다 손으로 쓰는 게 아니라, 데이터가 들어오면 마크업이 자동으로 나오는 함수 하나로 관리하는 것이다.

3. 커뮤니티에 맞는 타입

커뮤니티 사이트에서 가장 잘 맞는 타입은 DiscussionForumPosting이다. 이건 사용자들이 토론하는 게시판 글이라는 의미의 타입으로, 작성자, 작성일, 본문, 댓글 수, 추천 수 같은 걸 담을 수 있다. 요즘 검색엔진과 AI가 커뮤니티의 토론 콘텐츠를 특별히 신뢰하는 흐름이라, 이 타입을 제대로 다는 게 커뮤니티엔 특히 유리하다.

글 하나에 여러 타입을 조합할 수도 있다. 최상단에 사이트 운영 주체를 알리는 Organization, 페이지 경로를 알리는 BreadcrumbList, 그리고 글 자체를 나타내는 DiscussionForumPosting을 함께 넣는 식이다. 경로 정보인 BreadcrumbList는 검색 결과에 게시판 이름이 붙는 빵부스러기 표시로 이어지기도 한다.

중요한 건 담는 값이 실제 화면 내용과 일치해야 한다는 점이다. 구조화 데이터에 적은 작성자, 날짜, 댓글 수가 실제 페이지에 보이는 것과 같아야 한다. 서버가 가진 진짜 데이터로 채우면 자연히 일치하니, 별도의 하드코딩보다 실데이터 기반으로 생성하는 게 맞다.

커뮤니티 타입을 다룰 때 댓글을 어떻게 담을지도 고민거리다. 댓글 수 같은 집계는 넣기 쉽지만 개별 댓글까지 다 담으면 마크업이 비대해진다. 보통은 핵심 집계와 대표 정보만 담고, 지나치게 상세한 것은 생략한다. 마크업은 검색엔진이 페이지를 이해하도록 돕는 요약이지 페이지 전체의 복제본이 아니라는 감각이 필요하다.

덧붙이면 커뮤니티 콘텐츠는 구조화 데이터의 이점을 특히 잘 받는다. 작성자와 답변, 추천 같은 상호작용 정보가 풍부해서 담을 게 많기 때문이다. 정보성 글 하나짜리 페이지보다, 여러 사람의 토론이 오간 페이지가 구조화 데이터로 표현했을 때 더 입체적으로 보인다. 커뮤니티라는 형식 자체가 이 작업과 궁합이 좋다.

4. 검증과 함정

구조화 데이터는 반드시 검증하고 넘어가야 한다. 구글의 리치 결과 테스트 도구에 URL이나 코드를 넣으면, 유효한지와 어떤 리치 결과 후보로 인식되는지를 알려준다. 문법 오류가 하나만 있어도 통째로 무시되니, 넣었으면 반드시 통과를 확인해야 한다.

가장 조심할 함정은 거짓 마크업이다. 화면엔 없는 별점을 구조화 데이터에만 넣거나, 실제와 다른 정보를 담으면 구글이 스팸으로 간주해 수동 조치를 내릴 수 있다. 구조화 데이터로 검색 결과를 예쁘게 꾸미려다 사이트 전체가 벌점을 받는 것이다. 보이는 것과 마크업은 반드시 같아야 한다.

또 하나, 구조화 데이터를 넣었다고 리치 결과가 보장되는 건 아니다. 구글이 조건과 품질을 보고 보여줄지 말지를 정한다. 그러니 리치 결과는 될 수도 있는 보너스로 생각하고, 기본은 정확하고 정직한 마크업을 다는 데 두는 게 맞다.

검증을 습관화하는 팁으로, 새 타입을 추가하거나 마크업을 고칠 때마다 리치 결과 테스트를 통과시키고 배포하는 규칙을 정해두면 좋다. JSON은 쉼표 하나만 빠져도 전체가 깨지는데, 그러면 애써 넣은 구조화 데이터가 통째로 무시된다. 배포 파이프라인에 구조화 데이터 검증을 넣어두면 이런 조용한 무효화를 막을 수 있다.

5. Organization과 sameAs

사이트 운영 주체를 알리는 Organization 마크업도 유용하다. 사이트 이름, 로고, 검색창 정보 등을 담아 구글이 이 사이트의 정체를 이해하게 돕는다. 여기에 sameAs라는 항목으로 운영 중인 공식 SNS 계정을 연결할 수 있는데, 이게 은근히 헷갈리는 지점이다.

운영하는 공식 SNS가 있으면 sameAs에 그 주소들을 넣는 게 좋다. 하지만 운영하는 SNS가 없다면 sameAs는 아예 생략하는 게 표준이다. 억지로 채우려고 가짜 주소나 자기 사이트 주소를 넣으면 순환 참조나 스팸 신호가 되어 오히려 해롭다. 없으면 비워두는 게 정답이고, 나중에 공식 계정을 만들면 그때 추가하면 된다.

정리하면 구조화 데이터는 검색엔진에게 내 페이지의 의미를 정직하게 설명하는 라벨이다. JSON-LD로 커뮤니티에 맞는 타입을 실데이터로 채우고, 반드시 검증하고, 거짓은 절대 넣지 않는다. 다음 편에서는 구글 말고 또 하나의 검색엔진, 빙이 우리 글을 못 긁던 이유를 다룬다.

sameAs 이야기를 조금 넓히면, 이건 신뢰의 연결고리다. 공식 SNS 계정을 연결해두면 구글이 이 사이트와 그 계정이 같은 주체라고 이해하고, 흩어진 온라인 존재를 하나로 묶어 본다. 그래서 나중에 X나 스레드 같은 공식 계정을 열면 그때 sameAs에 추가하는 걸 잊지 말자. 다만 그전까지는 비워두는 게 맞다. 없는 걸 채우는 순간 신뢰가 아니라 스팸 신호가 된다.

끝으로 우선순위를 정리하면, 구조화 데이터는 기본기가 갖춰진 다음의 플러스알파다. 크롤과 색인이 안 되는데 구조화 데이터부터 붙이는 건 순서가 틀렸다. 봇이 사이트를 잘 돌고 콘텐츠가 색인되는 토대가 먼저다. 그 위에 구조화 데이터를 얹으면 검색 결과가 돋보이고 AI 인용 가능성도 열린다. 기초 다음의 심화라는 위치를 잊지 말자.