IT 시행착오··약 8분

Google Search Console에서 색인 요청하는 방법

새 글을 올린 뒤 Search Console URL 검사로 색인을 요청하는 실제 순서와, Cloudflare 챌린지 때문에 검수가 막혔던 사례를 정리합니다.

검색 결과(SERP) 일러스트 — Search Console 색인 (cc by 4.0, wikimedia-commons)

새 글을 올렸는데 며칠이 지나도 site:도메인에 안 뜨면, 보통 제일 먼저 Search Console을 엽니다. 다만 색인 요청 버튼은 “순위 올리기”가 아닙니다. 구글 쪽에 “이 URL 다시 봐 줘”라고 큐에 넣는 정도예요.

서민혁닷컴도 처음엔 workers.dev에서는 글이 잘 보이는데, 커스텀 도메인만 열면 Cloudflare Managed Challenge가 떠서 HTML이 안 읽히는 상태였습니다. 그 상태로는 Search Console 실제 URL 테스트도, AdsBot 검수도 의미가 없습니다. 색인 요청 전에 브라우저 말고 봇이 본문을 받는지부터 확인하는 습관이 생겼습니다.

요청하기 전에 내가 보는 것

운영 URL을 시크릿 창으로 연다. 200인지, 로그인 벽인지, 프리뷰 주소로 새지 않는지.

그다음 터미널에서 User-Agent만 바꿔 봅니다.

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://seominhyuk.com/

응답이 403이고 본문에 Just a moment...가 있으면, Search Console에 아무리 요청해도 허공에 던지는 겁니다. 우리 경우는 Bot Fight Mode(fight_mode)가 켜져 있었고, 끄고 캐시를 비운 뒤에야 AdsBot이 홈·글·sitemap을 200으로 읽었습니다. 자세한 과정은 Cloudflare Bot Fight가 AdsBot을 막던 날에 적어 두었습니다.

추가로 보는 것:

  • /robots.txt에 Disallow로 /posts/를 막지 않았는지
  • sitemap에 새 URL이 들어갔는지 (sitemap-index.xml → sitemap-0.xml)
  • canonical이 workers.dev나 예전 도메인을 가리키지 않는지

실패했던 순서(버튼부터 누름)

처음엔 Search Console에 URL을 넣고 바로 “색인 생성 요청”을 연타했습니다. 상태가 안 바뀌니 robots를 고치고, sitemap을 다시 제출하고, 또 요청했습니다. 문제는 안내판이 아니라 문이 잠긴 것이었습니다. 봇 curl을 먼저 했더라면 하루를 아꼈을 겁니다.

그다음 실패는 배포 직후 즉시 요청이었습니다. CDN에 옛 HTML·옛 제목이 남아 있으면, 실제 URL 테스트가 “성공”처럼 보여도 본문이 기대한 글이 아닐 수 있습니다. 퍼지 후 시크릿 창·curl로 제목/슬러그를 확인한 뒤 요청합니다.

도메인 소유권 TXT는 이미 있는 경우가 많습니다. 확인만 안 된 상태면 URL 검사가 애매해집니다. DNS·HTTPS 쪽은 커스텀 도메인 DNS 체크리스트를 따릅니다.

요청 전 최소 스크립트처럼 쓰는 확인:

UA_G='Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
UA_A='AdsBot-Google (+http://www.google.com/adsbot.html)'
URL='https://seominhyuk.com/posts/<새-슬러그>/'
curl -sI -A "$UA_G" "$URL" | head -n 12
curl -sI -A "$UA_A" https://seominhyuk.com/sitemap-index.xml | head -n 12
curl -s -A "$UA_G" "$URL" | head -n 5

본문 앞에 Just a moment...가 없고, 헤더에 cf-mitigated가 없으면 그다음에 Search Console로 갑니다.

URL 검사로 넣는 순서

  1. 운영 전체 URL을 브라우저에서 한 번 연다.
  2. Search Console 상단 검사창에 같은 URL을 붙인다.
  3. “실제 URL 테스트”를 먼저 돌린다.
  4. 가져오기 성공이면 “색인 생성 요청”.
  5. 같은 URL을 하루에도 여러 번 두드리지 않는다.

새 글은 대부분 “아직 등록되지 않음”으로 나옵니다. 요청 접수 후에도 몇 시간~며칠은 흔합니다. 반영이 안 되면 버튼을 더 누르기보다, 위에서 말한 접근성·중복·canonical부터 다시 봅니다.

실제 URL 테스트가 실패하면 사유를 읽습니다. robots 차단, 리다이렉트 루프, 서버 오류, “페이지를 가져올 수 없음” 등은 각각 처방이 다릅니다. 우리처럼 챌린지 HTML이 내려오면 구글 쪽에서는 본문을 못 본 것과 같습니다. Search Console UI만 보고 “색인 시스템이 느리다”고 단정하지 않습니다.

사이트맵은 따로, 내부 링크는 따로

수동 요청만 믿으면 글이 늘수록 빠집니다. Search Console Sitemaps에 https://seominhyuk.com/sitemap-index.xml을 넣어 두는 편이 덜 불안합니다. 사이트맵 작성 기준은 robots.txt와 sitemap.xml에 모아 두었습니다.

구글은 사이트맵만으로 사이트 구조를 다 이해하지 않습니다. 카테고리 목록이나 관련 글에서 새 포스트로 한 번이라도 링크가 있어야 발견이 쉬워집니다. “여기 클릭”보다 글 제목이 드러나는 앵커가 낫습니다.

새 글을 홈·카테고리에만 넣고 관련 글(relatedSlugs)을 비우면, 고립 URL이 됩니다. 반대로 관련 글만 잔뜩 넣고 sitemap에 빠지면 발견이 늦습니다. sitemap + 내부 링크를 같이 봅니다.

사이트맵 제출 직후 “성공”은 접수인 경우가 많습니다. 개별 URL은 URL 검사로 따로 확인합니다. /sitemap.xml 404인데 /sitemap-index.xml이 맞는 구성이면, 제출 URL을 인덱스 쪽으로 고칩니다.

자주 헛다리 짚는 경우

배포 직후 바로 요청했다가, CDN에 옛 HTML이 남아 있는 경우. Cloudflare라면 배포 후 한두 분 기다리거나 퍼지한 뒤 검사하는 편이 덜 헷갈립니다.

프리뷰 URL(*.workers.dev의 임시 경로 등)을 검사창에 넣는 경우. 운영 도메인만 Search Console에 두고, 프리뷰는 noindex나 인증으로 막는 쪽이 안전합니다.

“발견됨 - 현재 색인이 생성되지 않음”은 URL을 알지만 아직 안 넣었다는 뜻입니다. 요청 횟수보다 본문 품질·중복·사이트 신뢰 쪽을 손보는 게 맞습니다.

canonical이 www/apex/workers.dev 사이를 오가면 “어느 URL을 색인할지”가 흔들립니다. 문서는 apex https로 고정합니다. OG URL·sitemap·글 안 절대 링크도 같은 호스트로 맞춥니다.

글을 올린 날의 최소 루틴

  1. npm run build 후 배포가 반영됐는지 시크릿 창으로 확인
  2. Googlebot/AdsBot curl로 본문·sitemap 200 확인
  3. sitemap에 새 URL이 있는지 확인
  4. Search Console URL 검사 → 실제 URL 테스트 → 색인 요청(하루 과다 연타 금지)

색인과 순위는 다릅니다. 색인은 데이터베이스에 들어갔다는 신호일 뿐이고, 검색 상단은 제목·본문·속도·링크가 따로 경쟁합니다. 새 글을 올릴 때마다 저는 “봇이 200으로 본문을 받는지”만 먼저 확인하고, 그다음에 Search Console 버튼을 누릅니다. 버튼은 마지막 단계이지, 첫 디버깅 도구가 아닙니다.