GitHub Pages로 만든 블로그는 SEO에 불리할까?

“GitHub Pages로 만든 블로그는 SEO에 약하지 않나?”라는 질문은 꽤 자주 나온다. 질문 자체는 맞다. 다만 답은 “GitHub Pages라서 약하다”가 아니라 “정적 사이트의 장점을 살리지 못하면 약해진다”에 가깝다.

검색엔진이 원하는 것은 특정 호스팅 브랜드가 아니다. 접근 가능한 URL, 읽을 수 있는 본문, 명확한 제목과 설명, 일관된 canonical, sitemap, 내부 링크, 그리고 사용자가 읽을 가치가 있는 콘텐츠다. GitHub Pages는 이 조건을 만족시킬 수 있다. 대신 서버에서 동적으로 처리하던 편의 기능을 빌드 단계에서 정확히 만들어야 한다.

불리한 지점은 있다

GitHub Pages는 단순한 정적 호스팅이다. 서버 미들웨어, edge rewrite, ISR, 요청 시점 데이터 조립 같은 기능은 없다. 그래서 다음 요구가 있으면 불리해진다.

• 사용자별로 다른 본문을 보여줘야 한다
• 글 발행 즉시 서버 캐시를 세밀하게 무효화해야 한다
• 검색, 댓글, 추천 글을 서버에서 실시간 계산해야 한다
• A/B 테스트나 개인화 랜딩을 URL별로 세밀하게 운영해야 한다

하지만 일반적인 기술 블로그는 이 요구를 대부분 갖지 않는다. 글은 발행 시점에 정적 HTML로 만들어져도 충분하다. 오히려 검색엔진 입장에서는 자바스크립트 실행 없이 본문을 바로 읽을 수 있는 정적 HTML이 더 예측 가능하다.

유리한 지점도 분명하다

정적 블로그의 장점은 단순함이다. 서버 장애가 없고, 데이터베이스 연결이 없고, 런타임 렌더링 비용이 없다. 페이지는 이미 만들어져 있으므로 HTML 응답이 빠르고 구조가 일정하다.

SEO 관점에서 이 단순함은 강점이 된다.

• 모든 글이 고유한 URL을 가진다
• 제목과 설명을 빌드 시점에 확정할 수 있다
• sitemap과 RSS를 자동으로 만들 수 있다
• BlogPosting 구조화 데이터를 글마다 넣을 수 있다
• 한국어와 영어 페이지를 hreflang으로 연결할 수 있다
• 배포 결과물을 눈으로 확인하고 Search Console에 제출할 수 있다

즉 문제는 GitHub Pages가 아니라, 정적 빌드 결과물이 검색엔진이 이해하기 좋은 문서인지다.

커스텀 도메인은 사실상 필수다

기술적으로는 username.github.io/repository 주소로도 블로그를 운영할 수 있다. 하지만 장기적으로는 커스텀 도메인을 붙이는 편이 낫다.

첫째, 브랜드와 URL이 짧아진다. 둘째, 나중에 호스팅을 옮겨도 주소를 유지할 수 있다. 셋째, Search Console, AdSense, 외부 링크가 모두 루트 도메인 기준으로 쌓인다. 블로그를 잠깐 쓰는 실험이 아니라 오래 가져갈 자산으로 본다면 도메인은 초기부터 고정하는 게 좋다.

핵심은 배포 수단과 주소 자산을 분리하는 것이다. GitHub Pages는 배포 계층이고, 커스텀 도메인은 검색 신호와 외부 링크가 장기적으로 쌓이는 기준점이다.

정적 블로그에서 지킬 기준

현재 구조에서는 다음 항목을 빌드 산출물로 보장한다.

• 각 페이지의 canonical URL
• 한국어/영어 대체 페이지의 alternate 링크
• 글 상세 페이지의 BlogPosting JSON-LD
• sitemap index
• RSS feed
• robots.txt의 sitemap 위치
• 태그 기반 목록과 내부 링크

이 기준은 검색엔진을 속이기 위한 장치가 아니다. 검색엔진이 문서의 주제, 언어, 발행일, 수정일, 관련 글을 덜 헷갈리게 만드는 장치다.

실제로 빌드가 끝나면 다음처럼 검색엔진이 읽을 수 있는 파일과 페이지가 생긴다.

dist/rss.xml
dist/sitemap-index.xml
dist/sitemap-0.xml
dist/ko/posts/github-pages-seo-tradeoffs/index.html
dist/en/posts/github-pages-seo-tradeoffs/index.html

글 상세 페이지에는 이런 구조화 데이터가 들어간다. 핵심은 “블로그 글”이라는 타입, 발행일과 수정일, 태그, 언어, canonical URL을 한 곳에서 일관되게 제공하는 것이다.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "GitHub Pages 블로그 SEO: 검색 노출에 불리할까?",
  "datePublished": "2026-07-01T00:00:00.000Z",
  "dateModified": "2026-07-01T00:00:00.000Z",
  "keywords": ["github-pages", "seo", "static-site"],
  "inLanguage": "ko",
  "mainEntityOfPage": "https://example.com/ko/posts/github-pages-seo-tradeoffs/"
}

검증도 감으로 하지 않는다. 로컬에서는 최소한 다음 명령으로 타입 검사, 테스트, 정적 빌드까지 한 번에 확인한다.

pnpm verify

이 명령이 통과해야 새 글이 sitemap과 RSS에 들어가고, 잘못된 frontmatter가 빌드를 깨뜨리지 않는다고 볼 수 있다.

가장 큰 SEO 리스크는 호스팅이 아니다

정작 위험한 것은 얇은 글이다. 도구 이름만 나열한 글, 공식 문서를 다시 쓴 글, 직접 해본 흔적이 없는 글은 정적 사이트든 서버 렌더링 사이트든 오래 버티기 어렵다.

Google Search Central은 사람을 위한 원본 정보, 깊이 있는 설명, 신뢰 가능한 출처, 직접 경험을 강조한다. 이 기준으로 보면 GitHub Pages를 쓰는지보다 “이 글이 검색 결과의 다른 글보다 더 나은가”가 훨씬 중요하다. 그래서 공식 문서를 다시 쓰는 글보다, 실제로 설정하고 검증한 결과를 글 안에 남기는 쪽이 더 강하다.

정적 블로그의 SEO 전략은 기술 설정보다 글의 질에 더 무게를 둬야 한다. 배포 구조는 검색엔진이 읽기 쉽게 만들고, 본문은 독자가 다시 검색하지 않아도 될 만큼 구체적으로 쓰는 것. 이 둘이 같이 가야 한다.

결론

GitHub Pages는 SEO에 불리한 도구가 아니다. 다만 정적 사이트의 책임을 빌드 단계에서 제대로 처리해야 한다. sitemap, RSS, canonical, 구조화 데이터, 다국어 링크를 자동화하고, 글 자체가 실제 경험과 판단을 담고 있다면 충분히 좋은 출발점이 된다.

서버가 없다는 것은 약점이 아니라 제약이다. 그리고 작은 기술 블로그에서는 그 제약이 오히려 글과 구조에 집중하게 만드는 장점이 될 수 있다.

자주 묻는 질문

GitHub Pages 블로그도 Google Search Console에 등록해야 하나?

등록하는 편이 좋다. sitemap을 제출하고 URL 검사로 주요 글을 요청하면 Google이 사이트 구조를 이해하는 데 도움이 된다. 특히 새 도메인과 새 블로그는 Search Console에서 색인 상태와 검색어 데이터를 확인해야 다음 글의 방향을 정할 수 있다.

github.io 주소로 운영해도 괜찮나?

실험용이면 괜찮다. 하지만 오래 운영할 블로그라면 커스텀 도메인이 낫다. 외부 링크, Search Console 데이터, AdSense 심사, 브랜드 신호가 모두 도메인 기준으로 쌓이기 때문이다.

정적 블로그에서 가장 먼저 확인할 SEO 항목은 무엇인가?

canonical, sitemap, robots.txt, title, description, 내부 링크, 본문 HTML이다. 이 항목이 안정적이면 GitHub Pages라는 호스팅 자체는 큰 문제가 되지 않는다.

이어서 읽기

프레임워크 선택까지 이어서 보려면 Astro vs Next.js: 기술 블로그에 Next.js를 쓰지 않은 이유를 읽으면 된다. 글을 계속 쓰기 어렵다면 개발 블로그 글쓰기: 개발자가 블로그를 계속 못 쓰는 진짜 이유를 먼저 보는 편이 더 현실적일 수 있다.