블로그 article 페이지에 SEO 오픈그래프 메타 풀세트 추가
목차
블로그 article 페이지에 SEO 메타 풀세트를 박아 넣었다. published, modified, author 세 가지를 한 번에.
왜 지금 이 작업이었나
팀 내 블로그 프로젝트를 운영하면서 콘텐츠 퀄리티 작업은 꾸준히 해왔는데, SEO 인프라 쪽은 솔직히 후순위로 밀려 있었다. 기능 배포, UX 개선, 글 작성 파이프라인 정리가 먼저라는 판단이었고, 그게 틀린 우선순위는 아니었다.
근데 어느 시점부터 "글은 쌓이는데 검색 유입이 왜 이 모양이지?" 라는 질문이 나오기 시작했다. 크롤러 입장에서 보면 당연한 결과였다. 아무리 좋은 콘텐츠를 써도 메타데이터가 빈약하면 검색엔진이 그 글의 신뢰도와 최신성을 제대로 평가하지 못한다. 특히 article:published_time, article:modified_time, article:author 이 세 가지는 Open Graph 프로토콜에서 article 타입을 선언할 때 기본 중의 기본인데, 이게 없었다.
이번에 BaseHead.astro와 BlogPost.astro 두 파일을 손댄 건 역할 분리 때문이다.
| 파일 | 역할 | 이번 변경 |
|---|---|---|
BaseHead.astro |
사이트 전체 공통 메타 | article 전용 OG 메타 조건부 렌더링 추가 |
BlogPost.astro |
article 레이아웃 | published / modified / author 데이터 BaseHead에 내려주기 |
BaseHead가 공통 head 컴포넌트라면, article 전용 메타는 "있을 수도 없을 수도 있는" 옵셔널 데이터다. 그래서 BlogPost 레이아웃에서 frontmatter를 파싱해서 내려주는 구조가 자연스럽다.
실제로 어떤 메타가 박히나
Open Graph article 스펙 기준으로 이번에 추가한 세 가지는 이렇다.
<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-05-24T00:00:00Z" />
<meta property="article:modified_time" content="2026-05-24T00:00:00Z" />
<meta property="article:author" content="https://example.com/about" />
published_time과 modified_time은 ISO 8601 포맷이어야 하고, author는 URL이어야 한다는 게 포인트다. 단순 문자열 이름을 박아놓으면 스펙 위반이다. Astro frontmatter에서 pubDate, updatedDate를 Date 객체로 관리하고 있었기 때문에 .toISOString() 호출 한 번으로 해결됐다.
---
const { pubDate, updatedDate, author } = Astro.props;
const publishedISO = pubDate.toISOString();
const modifiedISO = (updatedDate ?? pubDate).toISOString();
---
updatedDate가 없으면 pubDate를 fallback으로 쓰는 게 안전하다. modified가 아예 없는 것보다는 published와 동일한 값이라도 있는 게 낫다.
메타 하나가 실제로 뭘 바꾸나
솔직히 "메타 몇 줄 추가"가 별거 아닌 것처럼 보일 수 있다. 팀에서도 처음엔 그런 반응이 있었다.
근데 구글 입장에서 보면 이 메타들이 꽤 중요한 신호다:
article:published_time— 이 글이 얼마나 신선한 콘텐츠인지 판단하는 기준. 특히 시의성 있는 주제는 최신성 점수가 랭킹에 영향을 준다.article:modified_time— 오래된 글을 업데이트했을 때 크롤러에게 "이거 다시 봐줘" 신호를 준다. 이게 없으면 예전에 크롤된 버전이 그대로 인덱싱된 채로 유지된다.article:author— 구글의 E-E-A-T(경험/전문성/권위성/신뢰성) 평가에서 저자 정보는 명시적으로 언급되는 요소다. author URL로 사람을 식별하는 구조적 데이터를 만들어두면 Knowledge Graph 연결에도 유리하다.
SNS 공유 측면에서도 차이가 난다. 카카오톡, 슬랙, 트위터에서 링크를 펼칠 때 이 OG 메타를 읽는다. og:type이 article이면 published time을 노출해주는 플랫폼도 있고, 미리보기 품질 자체가 달라진다.
회고
이런 작업은 "안 하면 당장 뭔가 터지는" 종류가 아니라서 계속 뒤로 밀리기 쉽다. 팀 리딩 입장에서 이런 기술 부채성 SEO 작업의 우선순위를 어떻게 잡느냐가 항상 고민인데, 결국 "콘텐츠 투자 대비 회수율"을 높이는 인프라라는 관점으로 설득하는 게 효과적이었다.
두 파일 수정으로 끝났지만, 변경 파일 수가 적다고 임팩트가 작은 건 아니다. 오히려 이런 핀포인트 수정이 제대로 된 위치에 제대로 된 데이터를 넣었는지 리뷰할 때 더 꼼꼼하게 봐야 한다. 스펙을 틀리게 넣으면 없는 것보다 못한 경우도 있으니까.
다음 스텝은 JSON-LD 구조화 데이터(Schema.org/Article)까지 붙이는 건데, 그건 다음 이터레이션으로.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.