운세 슬러그 페이지에 아티클 OG 메타 구조 추가
목차
Base.astro에 article 메타 props를 뚫고, star/[slug].astro에서 실제로 넘겨주는 작업을 했다.
사실 이 작업은 며칠 전부터 미뤄두고 있었다. 페이지는 이미 돌아가고 있었고, 콘텐츠도 쌓이고 있었는데 정작 검색엔진이 제대로 읽어야 할 메타 정보는 Base 레이아웃에 구멍이 나 있는 상태였음. 우선순위상 기능 구현이 먼저였던 건 맞지만, SEO 관련 구조는 늦게 잡을수록 나중에 고치기 번거롭다는 걸 알면서도 미룬 거라 솔직히 조금 찜찜했다.
왜 Base 레이아웃에 props를 뚫는 구조인가
Astro 프로젝트에서 레이아웃 컴포넌트는 여러 페이지가 공통으로 쓰는 HTML 골격을 담당한다. <head> 안의 <meta> 태그들도 당연히 여기서 관리하는 게 자연스럽다. 문제는 기본 페이지용 메타(title, description 정도)랑 article 타입 페이지용 메타는 구조가 다르다는 점이다.
Open Graph 기준으로 보면:
| 메타 속성 | 일반 페이지 | article 타입 페이지 |
|---|---|---|
og:type |
website |
article |
og:title / og:description |
공통 | 공통 |
article:published_time |
불필요 | 필요 |
article:modified_time |
불필요 | 선택적 |
article:author |
불필요 | 필요 |
article:section / article:tag |
불필요 | 선택적 |
즉 Base에 article 전용 props를 추가한다는 건, 레이아웃이 "이 페이지는 article이야"라는 신호를 받아서 조건부로 관련 메타를 렌더링할 수 있게 만드는 거다. 넘겨주지 않으면 그냥 일반 페이지처럼 처리하면 되고.
실제 구조 변경 흐름
Base.astro 쪽 변경은 대략 이런 패턴이다.
---
interface Props {
title: string;
description?: string;
// 추가된 article 메타 props
articleMeta?: {
publishedTime?: string;
modifiedTime?: string;
author?: string;
tags?: string[];
};
}
const { title, description, articleMeta } = Astro.props;
---
<head>
<meta property="og:type" content={articleMeta ? "article" : "website"} />
{articleMeta?.publishedTime && (
<meta property="article:published_time" content={articleMeta.publishedTime} />
)}
{articleMeta?.author && (
<meta property="article:author" content={articleMeta.author} />
)}
{articleMeta?.tags?.map(tag => (
<meta property="article:tag" content={tag} />
))}
</head>
그리고 star/[slug].astro에서는 각 슬러그 페이지가 갖고 있는 frontmatter 데이터를 꺼내서 Base에 넘겨주는 구조:
---
// 슬러그로 콘텐츠 가져오기
const { entry } = Astro.props;
const { title, description, pubDate, author, tags } = entry.data;
---
<Base
title={title}
description={description}
articleMeta={{
publishedTime: pubDate.toISOString(),
author: author,
tags: tags,
}}
>
<!-- 본문 -->
</Base>
파일 두 개, 변경 자체는 크지 않다. 하지만 이 흐름이 잡혀야 나중에 다른 슬러그 기반 페이지가 생길 때도 똑같이 articleMeta만 넘겨주면 된다는 게 핵심이다.
회고 — 작은 구조 결정이 나중을 결정한다
이런 작업을 리뷰할 때 팀원들한테도 자주 하는 말인데, 레이아웃 컴포넌트의 props 인터페이스 설계는 기능 코드만큼 신경 써야 한다. 지금 당장 slug 페이지 하나만 있다고 해서 articleMeta를 하드코딩으로 Base에 박아버리면, 두 번째 페이지 타입이 생기는 순간 레이아웃을 뜯어야 한다. 애초에 props로 받는 구조를 잡아두면 호출부만 수정하면 된다.
star/[slug].astro가 Base에 데이터를 "넘겨주는" 역할을 명시적으로 담당하게 된 것도 괜찮은 분리라고 본다. 레이아웃이 콘텐츠를 직접 알 필요 없이, 페이지 컴포넌트가 책임지고 정제해서 넘기는 방식. 나중에 articleMeta 안에 뭔가 추가되더라도 Base 내부 로직보다 slug 페이지에서 데이터를 어떻게 매핑하는지만 보면 된다.
SEO 작업은 눈에 바로 안 보이는 작업이라 우선순위에서 밀리기 쉬운데, 검색엔진 입장에서는 콘텐츠 퀄리티만큼 메타 구조도 중요하다. 특히 article 타입은 발행일, 수정일이 제대로 기록돼 있어야 크롤러가 콘텐츠의 신선도를 판단할 수 있으니까. 늦은 것보다 지금 잡은 게 낫다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.