Google에 색인시키기: Search Console 등록부터 첫 색인 요청까지
GitHub Pages로 만든 개인 블로그를 Google Search Console에 등록하고, 사이트맵과 URL 검사를 통해 첫 색인을 요청하는 과정 기록.
- Date
- Status
- done
- Tags
블로그를 만들고 글도 몇 편 올렸는데, Google 검색에서는 내 블로그를 찾을 수 없다. 이번에는 내 GitHub Pages 블로그를 Google Search Console에 등록하고 첫 색인을 요청하는 과정을 작성해 본다.
네이버 블로그 포스팅이 구글에 잘 안 뜨는 이유가 tistory 블로그는 구글 색인을 지원하고 naver 블로그는 구글 색인을 지원하지 않기 때문일 거다. 구글 잘못은 아니고 네이버 쪽에서 등록 가능하도록 해주면 되는데, 아마도 네이버 사측에서 네이버 검색엔진을 쓰게 하고 싶어서 그런 거 같다.
참고로 내 tistory 블로그는 현재 잘 구글에 색인되어 있더라. (https://insidecastle.tistory.com)
시작 전: 지금 블로그 상태 확인
먼저 Google에서 site:dgddgd314.github.io를 검색해 본다. (물론 여러분은 각자의 블로그 링크를 검색하자.) 결과가 없거나 극히 적다면 아직 색인되지 않았을 가능성이 높다.
이 검색은 대략적인 확인용이고, 정확한 상태는 Search Console의 URL 검사 도구에서 본다.
Search Console이 필요한 이유
Google은 다른 사이트의 링크를 따라 새 페이지를 발견하는 경우가 많다. (새롭게 신설된 위키피디아의 페이지 등이 이와 같은 방식으로 색인된다) 그렇기 때문에 운이 좋거나 내가 쓴 글이 정말 뛰어나 다른 글과 다른 edge를 가진다면 사이트를 따로 등록하지 않아도 언젠가 색인될 수 있다.
하지만 하꼬 개인 블로그를 운영하는 입장에서는 그런 행운을 기대할 수 없고, 코딩/기술 정보는 대부분 구글 검색을 통해서 확인하는게 많기 때문에, 내 글을 구글에 등록하지 않는다면 영원히 발견되지 않을 확률이 훨씬 높다. (GEO가 뜨면 달라지려나?)
Search Console을 연결하면 사이트의 소유자임을 증명하고, 색인 등록을 진행할 수 있다.
색인 등록이란 구글이 내 글을 발견해서 내 글이 무슨 글인지 파악했다는 것을 의미한다. 즉 구글이 내 글을 다른 사람의 검색 결과에 띄울 수 있다!
추가로 Google이 어떤 URL을 읽었는지와 색인을 막는 원인을 직접 확인할 수 있다.
| 기능 | 이번에 쓰는 이유 |
|---|---|
| 속성 등록 | 이 사이트의 소유자임을 Google에 증명한다 |
| 사이트맵 제출 | 색인하고 싶은 글 URL의 목록을 알려 준다 |
| URL 검사 | 특정 글을 Google이 읽을 수 있는지 보고 색인을 요청한다 |
| 페이지 색인 보고서 | 색인되지 않은 이유를 나중에 추적한다 |
1. Search Console(구글 서치 콘솔) 에 블로그 등록하기
구글 서치 콘솔 접속
Search Console에 접속하자. (https://search.google.com/search-console)
그럼 가장 먼저 뜨는게 이거다. tistory 블로그/github pages를 이용한 블로그 등 타 플랫폼(?)에서 블로그 색인 작업을 진행중이라면 URL 접두어에 자신의 블로그 링크를 입력하고 계속을 누르도록 하자.
도메인, URL 접두어 방식의 자세한 설명
속성(property)은 Search Console이 한 사이트로 묶어서 관리할 URL 범위를 뜻한다. 도메인과 URL 접두어는 포함하는 주소 범위와 소유권 확인 방법이 다르다.
도메인 속성: example.com처럼 프로토콜과 경로를 빼고 입력한다. 등록한 도메인의 http/https와 www를 포함한 모든 하위 도메인을 한꺼번에 관리할 수 있다는 장점이 있다. 대신 소유권 확인은 DNS 레코드로만 가능하다. 쉽게 생각하면 해당 사이트의 모든 것을 관리할 권한이 있을 경우만 가능하다.
하위 도메인이란 쉽게 생각하면 google.com으로 점으로 구분되어 끝나는 모든 링크(drive.google.com, cloud.google.com)를 생각하면 된다.
URL 접두어 속성: 입력한 주소로 시작하는 URL만 포함한다. 예를 들어 https://dgddgd314.github.io/를 등록하면 그 아래 글과 태그 페이지, /editor 등만 포함된다. 범위가 좁은 대신 HTML 파일, HTML 태그, Google Analytics, Google Tag Manager, DNS 등 여러 방식으로 소유권을 확인할 수 있다.
정확한 포함 범위는 Google의 속성 추가 안내에서 예시와 함께 확인할 수 있다.
소유권 확인 절차
속성 확인을 잠시간 진행한 이후 다음과 같은 화면이 뜬다. 이 블로그가 정말 내가 소유권을 가진 블로그가 맞는지 확인하는 절차이다. 위에서 URL 접두어를 골랐다면 다음과 같이 5가지의 방법으로 소유권 확인을 진행할 수 있다. (자세한 내용은 이 사이트를 참고하자.)
가장 편한 HTML 태그를 통해 소유권 확인을 진행하도록 하자.
- 아래의 메타태그를 복사하여 사이트 홈페이지의 첫 번째
<body>섹션 전에 나오는<head>섹션에 붙여넣습니다.
<meta name="google-site-verification" content="Search Console에서 받은 값" /> - 다음의 확인을 클릭하세요.
확인된 상태를 유지하려면 확인이 완료된 후에도 메타태그를 삭제하지 마시기 바랍니다.
Search Console은 meta 태그 하나를 준다. 이 태그가 내 블로그 메인 페이지의 <head>에 포함되도록 배포한 뒤, Search Console에서 확인 버튼을 누르면 된다.
잘 모르겠다면 GPT의 도움을 받도록 하자.
즉 저 2번의 "확인"을 클릭하면 구글 서치 콘솔이 해당 사이트에 접근해 meta 태그가 붙어있는지를 확인한다. 배포를 했는지 반드시 확인하자.
astro를 사용할 경우의 삽입법
astro 프로젝트의 경우 메타태그는 src/components/BaseHead.astro 에 넣으면 된다. (해당 파일의 내용은 모든 페이지의 <head>에 자동으로 들어간다.)
HTML 태그 사용 시 몇 가지 TMI
- 인증 이후에도 메타태그는 삭제하면 안된다. 구글 공식 사이트에 따르면 Search Console이 해당 메타태그가 실제로 있는지 주기적으로 검사하기 때문이다.
- 이와 같이 직접 HTML을 수정할 수 있어야 Search Console에 등록할 수 있다. Tistory는 이 기능을 친절하게도 제공하고 있으며, 네이버 블로그는 제공하고 있지 않기 때문에 원칙적으로는 색인 생성이 불가능하다.
네이버 블로그의 경우 몇 가지 꼼수가 있다: 내가 등록할 수 없기 때문에 위에서 얘기했듯 서치 콘솔이 네이버 블로그 포스팅을 찾을 수 있게 해주면 된다. 직접 tistory 블로그를 개설해서 네이버 글을 링크로 다는 방법(혹은 자동 리다이렉팅), 나무위키에 자신의 네이버 포스팅 링크를 걸어두는 방법 등이 있을 것이다. (후자의 방법은 권장하지 않는다)
- 블로그 모든 글 및 페이지의
<head>에 메타태그를 삽입할 필요는 없다. 그냥 메인 페이지 (이 블로그의 경우https://dgddgd314.github.io/)의<head>에만 있으면 충분하다. 다만 astro 및 기타 다른 정적 웹사이트 생성기는<head>를 공용 component로 공유하는 경우가 많아 어쩔 수 없이 모두 삽입된다.
다른 방법을 사용한다면
URL 접두어 속성에서는 HTML 태그 외에도 다음 네 가지 방법을 사용할 수 있다.
- HTML 파일 업로드: Search Console이 제공한 인증 파일을 이름과 내용을 바꾸지 않고 사이트 루트에 배포한다. 예를 들어 받은 파일이
google1234567890abcdef.html이라면https://내주소/google1234567890abcdef.html에서 열려야 한다. GitHub Pages에서는 보통 파일을public/에 넣어 배포할 수 있다. 마찬가지로 확인 후에도 파일을 삭제하면 안 된다.
- Google Analytics: 이미 사이트에 Google Analytics 추적 코드가 설치되어 있고, 현재 Google 계정에 해당 Analytics 속성을 관리할 권한이 있을 때 사용할 수 있다. 블로그를 처음 만드는 경우에는 당연히 Analytics가 없을 테니 사용하는 상황은 많지 않다. 단지 Analytics 계정이 있다는 것만으로는 부족하고, 확인할 사이트의 페이지에 실제 추적 코드가 배포되어 있어야 한다.
- Google Tag Manager: 사이트에 Tag Manager 컨테이너 스니펫이 설치되어 있고 현재 계정에 필요한 컨테이너 권한이 있을 때 사용한다. 이미 Tag Manager로 분석·광고 태그를 관리하는 사이트라면 편한데, Tag Manager를 서치 콘솔보다 먼저 등록하는 곳은 보지 못했다.
- 도메인 이름 공급업체(DNS): Google이 제공한 TXT 또는 CNAME 값을 도메인의 DNS 관리 화면에 추가한다. DNS 변경이 전파될 때까지 시간이 걸릴 수 있다. 도메인 속성은 이 방법만 사용할 수 있으며, 직접 구입한 커스텀 도메인을 소유하고 있을 때 가장 확실한 방식이다.
2. sitemap(사이트맵) 만들고 제출하기
사이트맵은 검색엔진에 공개할 URL 목록을 알려 주는 XML 파일이다. 필수는 아니지만 새 글과 페이지를 발견시키는 데 도움이 된다.
tistory 및 기타 상용 블로그 플랫폼의 경우
본격적인 이야기를 시작하기 이전에, tistory 및 기타 다른 상용 블로그 플랫폼들은 sitemap 관리 및 robots.txt를 자동으로 만들어 주는 걸로 알고 있다. 그래서 그냥 sitemap을 구글 서치 콘솔에 등록하기만 해도 된다.
다음과 같이 사이트맵을 추가하면 된다:
https://<당신의 블로그 이름>/sitemap.xml sitemap.xml과 rss의 차이점
둘 다 XML처럼 보이고 글 URL을 담을 수 있지만, 만들어진 목적이 다르다.
sitemap.xml: 검색엔진에 색인시키고 싶은 공개 페이지의 전체 URL 목록을 알려 주는 파일이다. 글뿐 아니라 목록, 카테고리, 태그처럼 검색 결과에 노출할 페이지도 담을 수 있다. 보통 사이트의 대표 URL과 수정일을 제공하며, Google Search Console의 Sitemaps 메뉴에는 이 파일 또는 sitemap-index.xml을 제출한다.
rss.xml: RSS 리더와 구독 서비스에 최근에 발행된 글을 전달하는 피드다. 글 제목, 발행일, 요약 또는 본문과 링크를 담는다. 보통 최신 글 일부만 유지하므로 오래된 글까지 포함하는 전체 URL 목록으로 보기 어렵다.
구글에 올라온 tistory 구글 콘솔 등록 글들을 보면 대부분 /rss 까지 사이트맵에 추가하곤 하는데, 그럴 필요는 없다.
물론 RSS를 Search Console에 제출하는 것이 틀린 것은 아니다. 다만 이 블로그처럼 XML 사이트맵이 따로 있다면 sitemap-index.xml로 전체 페이지를 알리고, rss.xml은 구독용으로 두는 구성이 이해하기 쉽다. RSS를 사이트맵 안에 억지로 넣거나 두 파일 중 하나를 삭제할 필요는 없다.
Astro 프로젝트의 경우
Astro 프로젝트는 @astrojs/sitemap 통합 기능을 사용해 빌드할 때 사이트맵을 자동으로 만들 수 있다.
- 프로젝트에
@astrojs/sitemap을 설치하고,astro.config.mjs에sitemap()통합을 추가한다.
public/robots.txt의Sitemap:줄을https://dgddgd314.github.io/sitemap-index.xml로 설정한다. (물론 각자의 블로그 주소로 하면 된다.)
npm run build를 실행해dist/sitemap-index.xml이 생성되는지 확인한다.
- 이 변경사항을 GitHub에 커밋하고 푸시해 GitHub Pages 배포가 끝난 뒤, 브라우저에서
https://dgddgd314.github.io/sitemap-index.xml이 열리는지 확인한다. 마지막으로 Search Console의Sitemaps메뉴에서sitemap-index.xml을 제출한다.
사이트맵을 제출했다고 모든 페이지가 즉시 색인되는 것은 아니다. 그래도 Google이 우선 확인할 URL을 알려 주고, 잘못된 사이트맵 형식이나 읽기 오류를 발견할 수 있다.
조금 복잡한 과정이지만 GPT에게 맡기면 잘 해준다.
Astro까지 사용하지 않을 경우
Astro, Jekyll, WordPress처럼 사이트맵을 대신 만들어 주는 도구를 전혀 사용하지 않는 순수 HTML 사이트라면 사이트맵 파일도 직접 만들고 관리해야 한다. 페이지가 몇십 개 이하라면 직접 작성할 수 있지만, 페이지가 많거나 자주 바뀐다면 빌드 스크립트나 사이트맵 생성 도구로 자동화하는 편이 낫다.
- 먼저 검색 결과에 노출하고 싶은 대표 URL만 고른다.
https://example.com/page.html처럼 도메인을 포함한 절대 URL을 사용한다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
</url>
<url>
<loc>https://example.com/posts/first.html</loc>
</url>
</urlset> - 위 내용을 UTF-8 형식의
sitemap.xml로 저장하고, 배포되는index.html과 같은 사이트 루트에 둔다. 배포 후에는https://example.com/sitemap.xml등에서 파일이 열려야 한다.
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml - 사이트 루트의
robots.txt에 위와 같이 사이트맵의 전체 주소를 적는다. 이 줄은 검색엔진이 사이트맵 위치를 발견하게 해준다.robots.txt가 사이트맵을 생성해 주는 것은 아니므로 두 파일을 각각 만들어야 한다.
- 사이트를 배포한 뒤 브라우저에서
/sitemap.xml과/robots.txt를 직접 열어 확인한다. 마지막으로 Search Console의 Sitemaps 메뉴에sitemap.xml을 제출한다. 사이트맵이 여러 파일로 나뉠 만큼 커졌을 때만 이들을 묶는sitemap-index.xml을 별도로 만들면 된다.
3. 대표 글을 검사하고 첫 색인 요청하기
사이트 소유권과 사이트맵 설정이 끝났다면, 이 글처럼 공개된 대표 글 하나를 URL 검사 도구에 넣는다. 여기서는 Google에 이미 알려진 URL인지, 크롤링과 색인을 막는 문제가 있는지, 라이브 URL이 읽히는지를 볼 수 있다.
- 상단 URL 검사창에 전체 글 주소를 붙여 넣는다. 예:
https://dgddgd314.github.io/blog/google-search-console-indexing-guide
- 색인되지 않았다면 ‘실제 URL 테스트’로 현재 배포본을 Google이 읽을 수 있는지 확인한다.
- 문제가 없다면 ‘색인 생성 요청’을 누른다.
- 며칠에서 몇 주 뒤 다시 URL 검사를 열어 상태를 확인한다.
다음과 같이 뜨면 성공이다!
‘색인되지 않음’이 나오면 볼 것
간혹 다음과 같은 알림과 함께 색인이 생성되지 않았을 수 있다. (내 예전 블로그) 다음과 같이 troubleshooting을 진행한다.
| 표시된 상태 | 먼저 확인할 것 |
|---|---|
| 발견됨 - 현재 색인되지 않음 | 사이트맵과 내부 링크, 콘텐츠 공개 상태를 확인하고 기다린다 |
| 크롤링됨 - 현재 색인되지 않음 | 실제 본문과 canonical 설정을 확인한다 |
| robots.txt에 의해 차단됨 | robots.txt의 규칙과 배포된 파일 내용을 확인한다 |
| noindex 태그에 의해 제외됨 | head의 robots meta 태그나 응답 헤더를 확인한다 |
색인 뒤에 할 일
확인이 되었다면... 축하한다!✌️ 드디어 블로그 글이 구글에 등록되었다.
사실 여기까지는 복잡할 뿐이지 어려운 일이 아니다. 색인이 완료되면 구글은 내 검색결과를 띄워주긴 하지만, 물론 맨 위에 띄워주지는 않는다. 구글 검색결과의 상위에 띄우는 일은... 이쪽은 복잡하고 어려우며 사실 하나의 발달된 산업(SEO=Search Engine Optimization)이 있는 곳이다.
한편 내가 블로그를 꽤 오랫동안 써오며 검색결과 상위도 여러 번 올려봤는데, 결국 가장 중요한 건 아직까지는 글의 퀄리티인 것 같다. AI generating text가 많아진 세상에서 결국 나만의 글을 적는게 아직까지는 edge를 명확하게 가진다고 생각하기 때문에, 여러분도 블로그를 잘 가꾸어갔으면 좋겠다.
아무튼 SEO 얘기는 나도 잘 모르는 분야이고 너무 방대해서 이 글의 하위 내용으로 다룰만한 내용은 아니다. 기회가 있다면 다음 기회에 다뤄보도록 하자. (사실 GEO를 적는 김에 곁다리로 적어보면 재미있을거 같기도 하다.)
색인 뒤에는 다음을 꼭 확인하도록 하자:
- 새 글을 올릴 때마다 사이트맵에 포함되는지 확인한다.
- 만약 사이트맵에 포함되지 않는다면 직접 자기가 색인을 요청한다.
- 구글 임마들 사이트맵 거의 안본다. 사실상 새로운 도메인이 등록되었을 때만 살짝 보는 거 같다, 그래서 자기가 색인을 요청하는게 속이 편하다.