블로그 전체에 구조화 데이터 스키마를 심어 검색 노출 기반 마련

사이트 전체에 WebSite JSON-LD 스키마를 달았다. BaseHead.astro 한 파일이지만, 이게 모든 페이지 <head>에 공통으로 들어가는 컴포넌트라는 걸 감안하면 사실상 사이트 전체에 영향을 주는 작업이었다.

왜 JSON-LD였나

구조화 데이터를 마크업에 녹이는 방법은 크게 셋이다.

방식	삽입 위치	가독성	유지보수
JSON-LD	`<script type="application/ld+json">`	높음	쉬움
Microdata	HTML 태그 인라인 속성	낮음	번거로움
RDFa	HTML 태그 인라인 속성	낮음	번거로움

구글도 공식적으로 JSON-LD를 권장한다. HTML 구조와 완전히 분리돼 있어서 컴포넌트 수정 시 스키마가 깨질 위험도 낮고, 나중에 내용 바꿀 때 JSON 블록만 건드리면 된다. 선택지가 딱히 없었음.

BaseHead.astro에 때려 박은 이유

Astro에서 BaseHead.astro는 모든 레이아웃이 임포트하는 공통 헤드 컴포넌트다. 여기 한 번만 넣으면 블로그 전체 페이지에 자동으로 딸려 나온다. 페이지마다 따로 스크립트 태그 심을 필요가 없다.

---
// BaseHead.astro
const schema = {
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "...",
  "url": "...",
};
---

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

WebSite 스키마는 사이트 자체를 나타내는 가장 기본적인 타입이다. 여기에 name, url 정도만 있어도 구글이 사이트리스크(sitelinks)를 제공하거나 검색 결과에서 사이트 이름을 제대로 인식하는 데 도움이 된다. potentialAction으로 SearchAction까지 붙이면 검색 창 리치 스니펫도 나오는데, 그건 다음 작업으로 남겨뒀다.

구조화 데이터가 왜 중요한가 — 팀 관점 회고

블로그 SEO를 챙기는 건 단순히 트래픽 욕심이 아니다. 기술 블로그가 검색에서 잘 잡혀야 외부에서 유입이 생기고, 그게 곧 팀이나 개인 브랜딩으로 이어진다. 구조화 데이터는 그 중에서도 비용 대비 효과가 꽤 좋은 영역이다.

작업 자체는 짧다. 하지만 이런 종류의 작업일수록 "왜 지금 하냐"는 질문이 생긴다. 이유는 간단한데, 나중에 콘텐츠가 많이 쌓인 뒤 뒤늦게 달면 색인이 갱신되는 시점이 늦어진다. 크롤러 입장에서는 신규 스키마도 결국 변경 사항이라 재크롤링이 필요하기 때문이다. 초반에 달수록 그 갱신 비용을 아낄 수 있다.

앞으로 Article, BreadcrumbList 같은 페이지 단위 스키마도 붙여야 한다. BaseHead는 사이트 레벨, 각 포스트 레이아웃에는 Article 스키마를 따로 넣는 구조가 맞다. 이번 작업은 그 토대를 닦은 셈.

핀포인트 수정이었지만 체감 가중치는 높은 작업이었다. 다음은 포스트 페이지에 Article 스키마 붙이는 것부터.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.