Astro 기술 블로그 SEO 체크리스트: 트래픽 기다리기 전에 먼저 고칠 것
Web
마지막 업데이트

Astro 기술 블로그 SEO 체크리스트: 트래픽 기다리기 전에 먼저 고칠 것

Astro 블로그에 트래픽이 적을 때, 첫 문제는 “글을 더 써야 하나?”가 아닐 때가 많습니다. 검색엔진이 아직 사이트를 발견하는 방식, 페이지 역할, 대표 URL, 다국어 관계, 그리고 어떤 페이지를 아예 색인하지 말아야 하는지에 대해 혼란스러운 신호를 받고 있을 수 있습니다.

기술 블로그에서는 이 혼란이 특히 비쌉니다. 글이 괜찮아도 아래가 흔들리면 반응이 약하게 옵니다.

  • 배포 호스트가 일관되지 않다
  • sitemap이 불완전하다
  • canonical URL이 다른 호스트를 가리킨다
  • 다국어 route가 반쯤만 연결돼 있다
  • 얇은 지원 페이지까지 전부 indexable 상태다

이 글은 Astro 기준의 실전 SEO 체크리스트입니다.

  • 라이브 사이트에서 무엇부터 확인해야 하는지
  • Astro가 어떤 출력을 안정적으로 만들어야 하는지
  • Google이 문서상 무엇을 권장하는지
  • 계속 발행하기 전에 어떤 검증이 가치가 큰지

짧게 말하면 배포 호스트, 크롤링 파일, 페이지별 메타데이터, canonical과 hreflang, 사실에 맞는 구조화 데이터, 얇은 페이지의 색인 여부를 먼저 정리한 뒤에 글 수를 늘려야 한다는 이야기입니다.

Quick answer

Astro 기반 기술 블로그에서 가장 효과가 큰 SEO 체크리스트는 보통 이 순서입니다.

  1. Astro의 production site URL을 정확히 맞춘다
  2. 라이브 호스트에서 robots.txt와 sitemap-index.xml을 확인한다
  3. 홈, 블로그 인덱스, 카테고리, 글 상세가 서로 다른 메타데이터를 쓰게 한다
  4. HTML <head> 안에 절대경로 self-canonical을 둔다
  5. 진짜 대응되는 번역 페이지에만 hreflang을 넣는다
  6. 실제 페이지 타입과 맞는 구조화 데이터를 넣는다
  7. 얇거나 지원용인 페이지는 robots.txt가 아니라 noindex로 처리한다
  8. 내부 링크와 카테고리 설명을 강화한다
  9. 최종 렌더 HTML과 Search Console 결과를 확인한다

여기가 약하면, 글만 더 발행해도 기대만큼 움직이지 않는 경우가 많습니다.

컴포넌트보다 먼저 배포된 진실부터 보기

Astro에서 가장 중요한 기술 SEO 설정은 의외로 단순한 경우가 많습니다. production 사이트 URL입니다.

Astro 공식 sitemap integration은 올바른 site 값이 있어야 제대로 동작합니다. 이 값이 틀리면 canonical, sitemap, 관련 출력이 한꺼번에 다른 호스트를 가리킬 수 있습니다.

그래서 첫 질문은 “컴포넌트 코드가 맞아 보이는가?”가 아니라:

  • 실제 공개 호스트가 무엇인가
  • 렌더된 <head>에는 어느 호스트가 찍히는가
  • sitemap에는 어느 호스트가 들어가는가

입니다.

공개 사이트가 https://www.example.com이라면, SEO 출력이 https://example.com이나 preview 도메인을 조용히 가리키게 두면 안 됩니다.

크롤링과 발견 기본기부터 고치기

랭킹을 보기 전에, Google이 올바른 페이지를 발견할 수 있어야 합니다.

Google의 robots 문서는 robots.txt가 크롤러 접근을 제어하는 용도라고 설명하지만, 페이지를 검색 결과에서 빼는 확실한 방법은 아니라고 분명히 적고 있습니다. 검색 결과에서 빼고 싶다면 noindex나 더 강한 제어를 써야지, robots.txt만으로 해결하려 하면 안 됩니다.

Google의 sitemap 문서도 아래를 권장합니다.

  • 절대경로 전체 URL 사용
  • 검색에 나오길 원하는 URL만 포함
  • 가능하면 사이트 루트에 sitemap 배치

Astro에서는 보통 아래를 먼저 확인하면 됩니다.

  • https://www.example.com/robots.txt
  • https://www.example.com/sitemap-index.xml
  • sitemap-0.xml 같은 실제 생성 파일

기본 확인 명령:

curl https://www.example.com/robots.txt
curl https://www.example.com/sitemap-index.xml
curl -I https://www.example.com/blog/

라이브 사이트의 크롤링 파일이 틀리면, 나머지 SEO 설정도 출발점이 약합니다.

모든 페이지 유형에 같은 메타데이터를 주지 않기

기술 블로그가 기계적으로 보이는 가장 흔한 이유 중 하나는 모든 페이지가 거의 같은 title/description 로직을 쓰는 것입니다.

최소한 아래 페이지 유형은 메타데이터 역할이 달라야 합니다.

페이지 유형달라야 하는 포인트
홈사이트 포지셔닝과 전체 가치
블로그 인덱스글 아카이브라는 의도
카테고리 페이지주제 클러스터의 의미
글 상세특정 문제, 가이드, 결과

홈, 카테고리, 글 상세가 검색 결과에서 서로 비슷하게 보이면 검색엔진도 문맥을 덜 이해하고, 사용자도 클릭할 이유가 약해집니다.

심사나 신뢰 신호가 중요한 사이트라면, 이 차이가 사이트 품질 인상에도 영향을 줍니다. 페이지 역할이 분리돼 있을수록 더 의도적으로 만든 블로그처럼 보입니다.

canonical URL은 절대경로로 단순하게 유지하기

canonical은 복잡성이 아니라 명확성이 필요한 영역입니다.

Google canonical 문서는 canonical 링크를 HTML <head>에 넣고, 상대경로보다 절대경로 URL을 쓰는 편을 권장합니다.

대부분의 Astro 블로그에서 가장 안전한 기본값은:

  • 각 페이지가 자기 자신을 canonical로 출력한다
  • canonical URL은 공개 호스트 기준이다
  • canonical은 <head> 안에 있다

최종 HTML은 보통 이런 식이어야 합니다.

<link rel="canonical" href="https://www.example.com/blog/my-guide/" />

좋은 canonical 체크 포인트:

  • 호스트명이 실제 공개 호스트와 같은가
  • URL이 절대경로인가
  • 글이 다른 locale을 canonical로 가리키지 않는가
  • 카테고리와 아카이브도 같은 규칙을 따르는가

다국어 블로그라면 canonical은 같은 언어 안에 두고, 언어 간 관계는 hreflang으로 연결해야 합니다.

hreflang은 진짜 alternate에만 쓰기

Astro 블로그에 한국어/영어 route가 있다면, Google이 언어별 대응 관계를 명확히 알 수 있어야 합니다.

Google localized versions 문서는:

  • alternate link가 올바른 <head> 안에 있어야 하고
  • 페이지끼리 서로 다시 링크해야 하며
  • x-default는 매칭되지 않는 사용자를 위한 fallback이라고 설명합니다

즉, 최종 HTML은 이런 식으로 의도적으로 출력돼야 합니다.

<link rel="alternate" hreflang="ko" href="https://www.example.com/blog/my-guide/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/blog/my-guide/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/blog/my-guide/" />

흔한 실수:

  • 글 상세에만 alternate가 있고 카테고리엔 없다
  • 영어 페이지 canonical이 한국어를 가리킨다
  • 한쪽만 다른 쪽을 가리키고 반대는 없다
  • x-default가 route마다 들쭉날쭉하다

다국어 쪽을 더 깊게 보려면 다국어 블로그 canonical과 hreflang 설정 가이드로 이어가면 됩니다.

구조화 데이터는 실제 페이지 타입을 더 잘 설명하는 용도로 쓰기

Google structured data 문서는 Search가 페이지 내용을 이해하려고 노력하며, structured data는 그 의미를 더 명시적으로 전달하는 단서라고 설명합니다.

기술 Astro 블로그에서 실전 시작점은 보통 이 정도입니다.

  • 글 상세에는 BlogPosting
  • 글과 아카이브에는 BreadcrumbList
  • 블로그 인덱스와 카테고리 페이지에는 필요할 때 CollectionPage

중요한 규칙은 “schema를 더 많이 넣기”가 아니라 “페이지를 사실대로 설명하기”입니다.

좋지 않은 예:

  • 얇은 아카이브를 풍부한 article처럼 마크업한다
  • 본문이 거의 없는 페이지에 article schema를 건다
  • HTML 날짜와 JSON-LD 날짜가 다르다
  • HTML URL과 JSON-LD URL이 다르다

욕심낸 schema보다 사실에 맞는 schema가 더 낫습니다.

얇은 페이지는 robots 차단이 아니라 noindex로 처리하기

많은 기술 블로그가 여기서 멈춥니다.

Google robots 문서는 robots.txt가 페이지를 Google에서 숨기는 메커니즘이 아니라고 분명히 말합니다. 검색 결과에서 페이지를 빼고 싶으면 noindex나 더 강한 방법을 써야 합니다.

Astro 콘텐츠 사이트에서는 보통 이런 페이지가 noindex 후보가 됩니다.

  • 짧은 개념 스텁
  • 거의 같은 내용을 반복하는 요약 페이지
  • 검색 랜딩 페이지로 가치가 약한 비교 글
  • 사용자에겐 필요하지만 검색 진입점으로는 약한 지원 페이지

콘텐츠형 사이트에서는 이런 정리가 새 글 10개보다 indexed quality ratio를 더 빨리 개선할 때도 많습니다.

Astro에서는 frontmatter와 layout 메타 태그 조합으로 자주 처리합니다.

---
title: 'Internal note'
description: 'Support page'
---
<meta name="robots" content="noindex, nofollow" />

정리하면, crawl 제어는 robots.txt, 검색 노출 제어는 noindex입니다.

카테고리 페이지를 topic hub처럼 다루기

카테고리 페이지는 링크 목록만 있으면 아쉽습니다.

검색과 사이트 품질에 도움이 되려면 보통 아래를 가져야 합니다.

  • 구체적인 제목
  • 그 주제를 실제 문장으로 설명하는 소개
  • 대표 글 노출
  • 주제 클러스터를 강화하는 내부 링크

기술 블로그는 글 포맷이 비슷한 경우가 많아서, 카테고리 페이지가 “왜 이 글들이 같이 묶이는지”를 설명해주는 역할이 더 중요합니다.

약한 카테고리 페이지는 사이트를 실제보다 더 평평하게 보이게 만듭니다.

내부 링크가 주제 구조를 설명하게 만들기

좋은 내부 링크는 기술 블로그에서 세 가지 일을 합니다.

  1. 크롤러가 관련 글을 발견하게 돕는다
  2. 주제 관계를 강화한다
  3. 좋은 글이 고립되지 않게 한다

많은 글에서 최소한 이 패턴이 있으면 건강합니다.

  • 하나의 상위 가이드
  • 하나의 인접한 체크리스트나 트러블슈팅 글
  • 하나의 자연스러운 다음 읽을거리

좋은 글이라도 주제 클러스터 안으로 링크되지 않으면, 검색엔진 입장에서는 강한 topical site의 일부로 읽히기 어렵습니다.

최종 렌더 HTML과 라이브 출력을 직접 확인하기

여기서 Astro SEO 설정이 조용히 실패하는 경우가 많습니다.

소스 컴포넌트만 보고 멈추지 말고, 실제 렌더 결과를 봐야 합니다.

라이브 사이트에서 볼 것:

  • page source
  • canonical URL
  • hreflang
  • robots meta
  • JSON-LD 출력
  • OG 이미지와 URL
  • 응답 상태

간단한 명령 예시:

curl -I https://www.example.com/blog/my-guide/
curl https://www.example.com/robots.txt
curl https://www.example.com/sitemap-index.xml

브라우저에서는:

  • view-source:https://www.example.com/blog/my-guide/
  • Search Console URL Inspection
  • structured data용 Rich Results Test

이 단계에서 “컴포넌트는 맞았는데 배포 페이지는 아니었다”는 문제를 많이 잡습니다.

이미 운영 중인 Astro 블로그라면 이 순서로 고치기

라이브 블로그라면 이 순서가 효율적입니다.

  1. 공개 호스트와 Astro site 값을 맞춘다
  2. robots.txt와 sitemap-index.xml을 확인한다
  3. 홈, 블로그, 카테고리, 글 메타데이터를 분리한다
  4. self-canonical을 확인한다
  5. localized site라면 hreflang을 확인한다
  6. 사실에 맞는 구조화 데이터를 넣는다
  7. 얇거나 우선순위 낮은 페이지를 noindex 처리한다
  8. 카테고리 설명과 내부 링크를 보강한다
  9. 핵심 URL 몇 개를 Search Console에서 다시 검증한다

이 순서가 저신호 SEO 항목을 먼저 만지는 것보다 사이트 이해도를 더 빨리 올려주는 경우가 많습니다.

Quick checklist

  1. Astro site 값이 실제 공개 호스트와 같다
  2. robots.txt가 라이브에 있고 과하게 막지 않는다
  3. sitemap-index.xml이 라이브에 있고 절대경로 공개 URL을 쓴다
  4. 검색에 나오길 원하는 URL만 sitemap에 들어간다
  5. 홈, 인덱스, 카테고리, 글 메타데이터가 서로 다르다
  6. canonical URL이 절대경로이고 <head> 안에 있다
  7. hreflang은 진짜 대응 페이지에만 들어간다
  8. 구조화 데이터가 실제 페이지 타입과 맞다
  9. 얇은 페이지는 robots.txt가 아니라 noindex로 제어한다
  10. 카테고리 페이지에 실제 설명 문장이 있다
  11. 글들이 주제 클러스터 안에서 서로 연결된다
  12. 라이브 최종 HTML을 확인했다

FAQ

Q. 트래픽이 적은 Astro 블로그에서 제일 먼저 뭘 고쳐야 하나요?

글 수보다 먼저 production host, 크롤링 파일, 페이지별 메타데이터, canonical, 내부 링크를 보세요.

Q. 얇은 페이지는 robots.txt로 막으면 되나요?

보통은 아닙니다. Google robots 문서도 robots.txt는 검색 결과에서 페이지를 빼는 적절한 방법이 아니라고 설명합니다. 검색 결과에서 빼려면 noindex를 쓰는 편이 맞습니다.

Q. 카테고리 페이지도 정말 중요한가요?

네. 기술 블로그에서는 topic hub 역할을 하면서 주제 구조와 크롤링을 돕습니다.

Q. 구조화 데이터만 넣으면 충분한가요?

아니요. 발견성, 메타데이터, canonical, 내부 구조가 먼저 어느 정도 건강해야 효과가 납니다.

Official References

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.

광고

관련 글

이 카테고리의 다른 글