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

처음 Search Console에서 눈에 들어온 것은 다음 두 검색어였다.

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

확인 당시의 초기 관찰값은 노출 10회와 7회, 클릭 0회였다. 이 정도 숫자로 제목이나 콘텐츠 품질을 판정할 수는 없었다. 그래서 제목을 성급하게 바꾸기보다, 검색어가 가리킨 질문과 실제 페이지가 약속하는 범위가 맞는지부터 확인했다.

이 글에서 남기는 것은 성과 그래프가 아니라 그때의 점검 순서다. Search Console에서 보이는 숫자와 저장소에서 직접 확인할 수 있는 HTML·canonical·sitemap·내부 링크를 분리해 봐야, 작은 표본에 과잉 대응하지 않게 된다.

숫자에서 읽을 수 있는 범위

노출 7회와 10회는 제목, 순위, 콘텐츠 품질을 판정하기에 작은 표본이다. CTR을 계산할 수는 있지만 0%라는 한 값만으로 제목이 실패했다고 말할 수는 없다. Google이 이 사이트를 특정 의도로 시험했다거나 콘텐츠 적합성을 확인했다는 해석도 이 표에는 없다.

대신 검색어가 글의 주제와 완전히 어긋나지는 않는지는 볼 수 있었다. seo github pages와 github pages seo는 GitHub Pages 블로그의 검색 노출이라는 이 글의 범위와 연결된다. 그래서 새 글을 바로 추가하지 않고 제목이 약속한 질문과 본문이 맞는지부터 확인했다.

검색어 하나로 의도를 정하지 않은 이유

github pages seo는 짧아서 검색자가 처한 상황을 하나로 정할 수 없다.

상황	검색자가 묻는 것	이 사이트에서 맡길 글
시작 전	GitHub Pages로 블로그를 운영해도 괜찮은가?	플랫폼 선택과 비용을 비교하는 글
운영 중	노출은 있는데 클릭이 없으면 무엇을 볼까?	이 글의 Search Console 관찰 기록

이 구분을 하지 않으면 플랫폼 선택 글과 운영 중 점검 글이 같은 설명을 반복하게 된다. 이번 글은 “GitHub Pages가 SEO에 좋은가”를 다시 판정하지 않고, 작은 관찰값을 보고 실제로 어떤 확인 순서를 선택했는지에 집중한다.

저장소와 빌드 결과에서 확인한 것

Search Console의 숫자는 코드만으로 재현할 수 없다. 대신 이 저장소가 어떤 URL과 문서 구조를 내보내는지는 확인할 수 있다. 당시에는 다음 파일을 기준으로 확인했다.

확인한 파일	이 글에서 확인한 이유
`astro.config.mjs`	운영 사이트 URL이 `https://2dayapp.com`으로 설정됐는지 확인
`public/CNAME`	GitHub Pages가 사용할 커스텀 도메인 확인
`src/lib/alternates.ts`	번역본이 있을 때만 대체 언어 링크를 만드는지 확인
`scripts/check-internal-links.mjs`	빌드된 HTML의 같은 사이트 링크가 실제 파일로 이어지는지 확인

pnpm build 뒤에는 dist/가 생기고, 마지막 스크립트가 그 결과의 내부 경로를 검사한다. 글 HTML에 본문과 canonical이 들어가는지, sitemap과 RSS에 공개 URL이 생기는지도 로컬에서 확인할 수 있다. 반면 Google이 언제 다시 크롤링했는지, 어떤 위치에 노출했는지, 왜 클릭하지 않았는지는 이 저장소만으로 알 수 없다.

제목보다 먼저 확인한 페이지 약속

Google은 제목이 페이지 내용을 정확하게 설명해야 하고, 검색 결과의 스니펫은 meta description뿐 아니라 페이지 본문과 검색어에서도 만들어질 수 있다고 안내한다. 이 글에서 중요한 것은 github pages seo라는 단어를 한 번 더 넣는 일이 아니라, 검색자가 들어온 뒤 어떤 상황을 다루는 글인지 바로 알 수 있게 하는 일이다.

그래서 제목을 GitHub Pages SEO 정리처럼 넓게 잡지 않고 Search Console에 노출은 잡히는데 클릭이 없을 때라는 상황을 넣었다. 첫 문단에도 실제로 확인한 검색어와 숫자를 먼저 배치했다. 이 글이 약속하는 것은 플랫폼 장단점 전체가 아니라, 작은 노출값을 보고 무엇을 확인할지 정하는 순서다.

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

정적 블로그에서는 sitemap을 “제출했으니 끝”으로 보면 안 된다. 실제 빌드 결과물에 공개 글 URL과 필요한 대체 정보가 들어갔는지 확인해야 한다. 이 저장소에서는 package.json의 build 스크립트가 Astro 빌드와 내부 링크 검사를 이어 붙인다. SEO 구조 테스트는 글별 OG 이미지, 작성·수정일 메타데이터, 대체 링크 목록처럼 코드로 확인할 수 있는 구조를 별도로 검사한다.

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

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

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

이번 숫자로 내리지 않은 결정

검색엔진은 sitemap만 보고 사이트를 이해하지 않는다. Google은 중요한 페이지가 메뉴나 본문 링크를 통해 도달 가능해야 한다고 설명한다. 작은 블로그에서 내부 링크는 검색 신호이기 전에 독자에게 글의 역할을 알려주는 경로다.

이 사이트에서 이 글이 맡는 질문은 Search Console에 노출은 잡히는데 클릭이 없을 때 무엇을 볼 것인가?다. 플랫폼을 고를 때 GitHub Pages가 적합한지는 호스팅 비교 글의 몫이다. 이번 숫자만으로 같은 키워드의 일반론을 한 편 더 만들지는 않았다. 새 글보다 현재 글의 제목 약속, 빌드 결과, 내부 링크를 먼저 확인하는 편이 이 데이터에 맞는 결정이었다.

다음에 반복할 점검 순서

공식 문서의 체크리스트를 다시 옮기는 것만으로는 이 관찰의 가치가 커지지 않는다. 이번에는 숫자와 저장소 상태를 다음 순서로 분리했다.

검색어가 글의 질문과 맞는지 확인한다. 두 검색어는 주제와 연결됐지만, 이것만으로 검색 의도 전체를 안다고 보지는 않는다.
빌드된 HTML의 <title>, description, canonical, 본문을 확인한다. canonical은 실제 운영 도메인인 https://2dayapp.com 아래의 글 URL을 가리켜야 한다.
dist/sitemap-index.xml, RSS, 관련 글의 내부 링크에 공개 URL이 들어가는지 확인한다. sitemap이 있다고 해서 색인이나 클릭이 보장되는 것은 아니다.
같은 조회 조건으로 다음 Search Console 값을 모은다. 제목·도입·내부 링크를 한 번에 크게 바꾸지 않아야 다음 변화의 원인을 기록할 수 있다.

이 순서는 Google의 순위 공식이 아니다. 7회와 10회 노출이라는 작은 숫자에 과잉 대응하지 않기 위해 이 저장소에서 사용한 운영 순서다.

이 판단의 근거

이 글에서 고유한 자료는 Search Console에 실제로 보인 두 검색어의 초기 값과, 그 값을 확인한 저장소의 빌드 구조다. 나머지 검색엔진 동작은 공식 문서의 범위 안에서만 설명했다.

GitHub Pages가 정적 파일을 게시하고 커스텀 도메인을 지원한다는 점은 GitHub Docs와 커스텀 도메인 문서에서 확인했다.
sitemap이 URL 발견에는 도움을 주지만 크롤링·색인을 보장하지 않는다는 점은 Google의 sitemap 문서에서 확인했다.
제목과 스니펫이 페이지 본문과 검색어의 영향을 받는다는 점은 title link 문서와 snippet 문서를 기준으로 삼았다.

노출 7회와 10회가 작다는 판단, 한 번에 여러 요소를 바꾸지 말자는 운영 순서는 공식 문서의 통계적 결론이 아니다. 이 저장소의 작은 관찰값을 과장하지 않기 위한 해석이다.

다음 관찰에 남길 값

다음에 같은 검색어를 확인한다면 조회 기간, 페이지 필터, 노출, 클릭, CTR, 평균 순위를 함께 기록한다. 가능하면 Search Console 속성과 조회 조건도 남겨야 이전 숫자와 비교할 수 있다.

그 자료가 생기기 전까지는 “노출은 있었고 클릭은 없었다” 이상을 말하지 않는다. 이 글의 가치는 검색 순위를 예측하는 데 있지 않고, 작은 관찰값을 근거보다 크게 부풀리지 않는 점검 순서를 남기는 데 있다.

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