GitHub Pages SEO, 노출은 있는데 클릭이 없을 때

Search Console에 이런 검색어가 잡히기 시작했다.

검색어                클릭수  노출
seo github pages       0     10
github pages seo       0      7

처음에는 이걸 보고 글을 하나 더 써야 하나 싶었다. 이미 GitHub Pages 블로그 SEO: 검색 노출에 불리할까?라는 글이 있는데, 같은 주제로 또 쓰면 얇은 중복 글이 될 가능성이 크다. 반대로 그냥 넘기기에는 검색어가 꽤 정확하다.

내 결론은 이렇다. 노출 10회, 클릭 0회는 실패가 아니라 아직 판단하기 이른 신호다. 다만 “GitHub Pages SEO”라는 검색어로 후보에 들어가기 시작했다면, 지금은 새 글을 찍어내기보다 기존 글과 새 글의 역할을 나눌 타이밍이다.

이 글은 GitHub Pages가 SEO에 좋은지 나쁜지를 다시 설명하지 않는다. 그 이야기는 이미 앞 글에서 했다. 여기서는 Search Console에 노출은 잡히는데 클릭이 없는 상황에서 무엇을 먼저 봐야 하는지 정리한다.

0클릭을 너무 빨리 해석하지 않는다

노출 7회, 10회는 판단하기에 작은 표본이다. 이 정도 숫자에서 CTR을 계산해 “0%니까 제목이 망했다”고 결론 내리면 너무 빠르다.

초기 Search Console 데이터는 흔들린다. 특히 새 글이나 새 도메인은 검색 결과 아래쪽에 몇 번 보였다가 빠지고, 비슷한 검색어로 다시 잡히기도 한다. 그래서 이 단계에서 더 중요한 질문은 “왜 클릭이 없지?”가 아니라 “검색어가 내가 의도한 주제와 맞나?”다.

이번 경우에는 검색어가 나쁘지 않다. seo github pages, github pages seo 모두 기존 글의 주제와 맞는다. 엉뚱한 검색어로 잡힌 게 아니라면 첫 번째 관문은 통과한 셈이다.

문제는 그다음이다. 이 검색어를 입력한 사람이 원하는 답은 두 종류로 갈릴 수 있다.

검색 의도를 두 개로 나눈다

github pages seo라는 검색어는 짧지만, 검색자가 처한 상황은 다를 수 있다.

이미 “GitHub Pages로 만든 블로그는 SEO에 불리할까?”라는 글이 있다면 첫 번째 의도는 어느 정도 받는다. 그 글에서 또다시 모든 체크리스트를 길게 늘리면 글의 초점이 흐려진다.

반대로 “노출은 잡히는데 클릭이 없다”는 실제 데이터가 생겼다면 두 번째 의도를 별도 글로 다룰 이유가 생긴다. 공식 문서의 sitemap, title, helpful content 설명을 다시 쓰는 글이면 의미가 없다. 작은 정적 블로그 운영자가 지금 숫자를 보고 어떤 순서로 판단할지 남겨야 읽을 이유가 생긴다.

GitHub Pages 탓부터 하지 않는다

GitHub Pages는 정적 사이트 호스팅이다. GitHub Docs는 GitHub Pages가 저장소의 HTML, CSS, JavaScript 파일을 가져와 선택적으로 빌드한 뒤 웹사이트로 게시하는 서비스라고 설명한다. 또 github.io 도메인이나 소유한 커스텀 도메인으로 운영할 수 있다.

이 구조가 SEO에 무조건 불리한 것은 아니다. 오히려 글 본문이 정적 HTML로 만들어져 있으면 검색엔진이 읽기에는 단순하다. 대신 서버에서 알아서 처리해주던 일을 빌드 단계에서 직접 보장해야 한다.

내가 먼저 보는 것은 호스팅 이름이 아니라 배포 결과물이다.

[ ] 글 본문이 HTML에 들어가 있는가
[ ] title과 description이 글마다 다른가
[ ] canonical이 실제 운영 도메인을 가리키는가
[ ] sitemap에 새 글 URL과 lastmod가 들어가는가
[ ] 관련 글끼리 내부 링크가 이어져 있는가

이게 맞으면 “GitHub Pages라서 안 된다”는 쪽으로 바로 가지 않는다. 그다음은 검색 결과에서 보이는 약속을 본다.

제목은 검색어보다 질문에 맞춰야 한다

Google은 좋은 제목이 페이지마다 고유하고, 명확하고, 페이지 내용을 정확히 설명해야 한다고 안내한다. 또 검색 결과의 스니펫은 meta description만으로 정해지지 않고 페이지 콘텐츠와 검색어에 따라 달라질 수 있다.

그래서 github pages seo라는 단어를 제목에 넣는 것만으로는 부족하다. 검색자가 실제로 묻는 질문을 제목이 받아야 한다.

예를 들어 이런 제목은 너무 넓다.

GitHub Pages SEO 정리

무슨 판단을 주는지 보이지 않는다. 반대로 기존 글 제목인 GitHub Pages 블로그 SEO: 검색 노출에 불리할까?는 시작 전 독자에게는 맞다. 하지만 이미 Search Console에서 노출과 클릭을 보고 있는 사람에게는 조금 멀다.

이번 글 제목을 길게 잡은 이유가 여기에 있다.

GitHub Pages SEO: Search Console에 노출은 잡히는데 클릭이 없을 때 볼 것

조금 길지만 검색자의 상황이 드러난다. “불리한가?”가 아니라 “지금 이 숫자를 어떻게 봐야 하나?”에 답하겠다는 약속이다.

본문 첫 문단도 같은 역할을 해야 한다. GitHub Pages는 많은 개발자가 쓰는 정적 호스팅입니다 같은 문장으로 시작하면 너무 늦다. Search Console 데이터를 보고 들어온 사람은 배경 설명보다 판단 순서를 원한다.

sitemap과 canonical은 제출 여부보다 내용이 중요하다

Google의 sitemap 문서는 sitemap이 사이트의 중요한 페이지와 파일, 업데이트 시점, 대체 언어 버전 같은 정보를 검색엔진에 알려주는 파일이라고 설명한다. 다만 sitemap이 있다고 해서 모든 URL이 반드시 크롤링되거나 색인되는 것은 아니다.

정적 블로그에서는 sitemap을 “제출했으니 끝”으로 보면 안 된다. 실제 빌드 결과물에 새 글 URL과 수정일이 들어갔는지 봐야 한다.

확인할 파일은 보통 이렇다.

dist/sitemap-index.xml
dist/sitemap-0.xml
dist/rss.xml
dist/ko/posts/github-pages-seo-search-console-clicks/index.html

같이 볼 것은 canonical이다. 검색 결과에 잡히길 원하는 URL과 canonical이 다르면 검색엔진은 다른 URL을 대표로 볼 수 있다. GitHub Pages에서 커스텀 도메인을 붙였다면 특히 중요하다. sitemap이나 canonical이 username.github.io를 가리키고 실제 운영 주소가 example.com이면 신호가 갈라진다.

<link
  rel="canonical"
  href="https://example.com/ko/posts/github-pages-seo-search-console-clicks/"
/>

호스팅은 GitHub Pages여도 검색 신호는 커스텀 도메인으로 쌓이게 해야 한다. 이 부분이 틀어져 있으면 제목을 고쳐도 효과를 판단하기 어렵다.

내부 링크는 글끼리 역할을 나누는 장치다

검색엔진은 sitemap만 보고 사이트를 이해하지 않는다. Google은 사이트의 중요한 페이지가 메뉴나 페이지 안의 링크 같은 형태로 도달 가능하면 대부분 발견할 수 있다고 설명한다.

작은 블로그에서는 내부 링크가 더 노골적인 역할을 한다. “이 글은 플랫폼 판단 글이고, 저 글은 운영 중 점검 글이다”를 검색엔진과 독자에게 동시에 알려준다.

이번 경우에는 기존 글과 새 글을 이렇게 나눈다.

기존 글:
GitHub Pages로 블로그를 만들면 SEO에 불리한가?

이번 글:
Search Console에 노출은 잡히는데 클릭이 없을 때 무엇을 볼 것인가?

이렇게 나눠야 같은 키워드를 놓고 글끼리 싸우지 않는다. 같은 말을 조금 바꿔 반복하는 글은 검색 유입보다 사이트 안의 애매한 중복만 늘릴 수 있다.

흔한 SEO 글처럼 쓰지 않는다

Google의 helpful content 문서는 콘텐츠가 원본 정보, 분석, 충분한 설명, 명백한 추가 가치를 제공하는지 스스로 물어보라고 한다. 공식 문서를 다시 쓴 글은 여기서 약해진다.

GitHub Pages SEO 글이 흔해 보이는 이유도 여기에 있다. 대부분은 아래 항목을 반복한다.

- title을 잘 써라
- meta description을 넣어라
- sitemap을 제출해라
- robots.txt를 확인해라
- 좋은 콘텐츠를 써라

다 맞는 말이지만, 이 정도로는 읽을 이유가 약하다. 검색자가 다시 검색하지 않게 하려면 판단 순서를 줘야 한다.

나는 클릭 0회 상황을 이렇게 본다.

이 표가 글의 핵심이다. SEO 체크리스트 자체보다 “지금 숫자에서 무엇을 하지 말아야 하는가”가 더 중요하다.

한 번에 다 고치지 않는다

Search Console 숫자를 보면 자꾸 즉시 고치고 싶어진다. 하지만 title, description, 도입부, 내부 링크를 한 번에 크게 바꾸면 어떤 변화가 영향을 줬는지 알기 어렵다.

초기 글이라면 나는 보통 이렇게 한다.

1. 검색어가 의도와 맞는지 확인한다.
2. 제목이 검색어의 질문에 직접 답하는지 본다.
3. description이 본문과 같은 약속을 하는지 본다.
4. 도입부 첫 3문단 안에 결론을 넣는다.
5. 관련 글 2-3개와 내부 링크를 연결한다.
6. sitemap과 canonical이 실제 도메인을 가리키는지 확인한다.
7. 1-2주 뒤 같은 검색어의 노출, CTR, 평균 순위를 다시 본다.

이 순서가 중요한 이유는 단순하다. 검색엔진을 위한 장치를 고치기 전에, 검색자가 클릭할 이유를 먼저 만들어야 한다.

이 글의 근거

이 글은 “GitHub Pages에서 SEO가 잘 된다”를 보장하는 글이 아니다. 공식 문서가 말하는 검색엔진 동작 원리와, Search Console에 잡힌 작은 초기 데이터를 운영 관점에서 해석한 글이다.

공식 문서로 확인한 사실은 다음이다.

반대로 아래 판단은 공식 문서의 직접 인용이 아니라 운영상 추론이다.

- 노출 7-10회는 CTR을 평가하기에 작은 표본이다.
- 검색어가 맞게 잡히기 시작했다면 먼저 제목과 도입부를 점검한다.
- 기존 글과 새 글은 검색 의도 기준으로 역할을 나누는 편이 낫다.
- 한 번에 너무 많은 요소를 바꾸면 어떤 변경이 영향을 줬는지 보기 어렵다.

이 추론은 SEO 순위 공식이 아니다. 작은 정적 블로그에서 Search Console 데이터를 볼 때 과잉 대응을 줄이기 위한 운영 기준이다.

그래서 글을 더 써야 하나?

이번 검색어라면 글을 더 써볼 만하다. 단, 같은 글을 하나 더 쓰는 것이 아니라 역할이 다른 글이어야 한다.

기존 글이 “GitHub Pages는 SEO에 불리한가?”를 다룬다면, 새 글은 “Search Console에 노출은 잡히는데 클릭이 없을 때 무엇을 볼 것인가?”를 맡는다. 이렇게 나누면 두 글이 같은 키워드를 놓고 충돌하기보다 서로 보완한다.

반대로 아래 조건이면 새 글보다 기존 글 수정이 먼저다.

[ ] 기존 글 제목이 검색 의도와 너무 멀다
[ ] 기존 글 도입부에 결론이 없다
[ ] sitemap, canonical, RSS 같은 기본 항목이 본문에 없다
[ ] 관련 글끼리 내부 링크가 없다
[ ] Search Console 검색어가 기존 글 하나에만 명확히 대응한다

새 글은 “다른 질문”을 받을 때만 의미가 있다. 같은 질문을 조금 다른 말로 반복하면 사이트 안에서 약한 경쟁 페이지만 늘어난다.

결론

seo github pages와 github pages seo가 Search Console에 잡히기 시작했다면 좋은 신호다. 클릭이 없다고 바로 실패로 보지 않아도 된다. 아직 표본이 작고, Google이 어떤 검색어에 이 사이트를 후보로 올릴지 테스트하는 단계일 수 있다.

하지만 이 신호를 그냥 흘려보내면 아깝다. 먼저 검색 의도를 나누고, 기존 글이 맡은 질문과 새 글이 맡을 질문을 분리한다. 그 다음 title, description, 본문 첫 문단, canonical, sitemap, 내부 링크를 본다.

GitHub Pages SEO에서 중요한 것은 GitHub Pages라는 이름이 아니다. 검색엔진이 읽을 수 있는 정적 HTML, 헷갈리지 않는 URL 신호, 그리고 검색자가 클릭했을 때 바로 답을 얻는 글이다. 노출이 잡히기 시작한 시점은 그 구조를 고치기 가장 좋은 타이밍이다.

참고 자료

• GitHub Docs: What is GitHub Pages?
• GitHub Docs: About custom domains and GitHub Pages
• Google Search Central: SEO Starter Guide
• Google Search Central: Learn about sitemaps
• Google Search Central: Creating helpful, reliable, people-first content
• GitHub Pages 블로그 SEO: 검색 노출에 불리할까?
• 메타 설명을 바꿨는데 Google 검색 결과가 그대로인 이유