검색 등록은 사이트 소유권을 확인하고 URL 발견·진단 경로를 여는 작업입니다. 색인이나 순위를 보장하지는 않습니다. 신규 블로그가 검색되지 않으면 고정 대기 기간을 가정하기보다 공개 HTTP 응답, robots/noindex, canonical, sitemap과 Search Console의 URL 검사 결과를 순서대로 확인합니다.

이 글은 2026년 4월 개설 직후의 기록을 2026년 9월 8일 공식 안내와 대조해 보완한 회고입니다. 당시에는 DNS TXT 인증에 실패한 뒤 URL 접두사 속성과 HTML 태그로 인증했습니다. 실패 원인을 확정할 로그는 충분하지 않았으므로 관측과 추정을 구별합니다. 1편의 플랫폼 선택, 2편의 배포 구성을 읽지 않아도 아래 절차를 사용할 수 있습니다.

먼저 관측한 사실과 모르는 것을 나눈다

배포 4일차에 사이트는 정상 응답했지만 site:blog.ruahverce.com 검색에는 결과가 없었습니다. 당시 글은 약 6편이었습니다. 이 검색 결과만으로 색인된 URL 수나 검색되지 않는 원인을 확정할 수는 없습니다. Google은 site: 검색 결과가 항상 전체 URL을 보여주는 것은 아니라고 설명합니다.

당시 관측말할 수 있는 것아직 확정할 수 없는 것
일반 브라우저에서 사이트 정상 응답방문 가능한 배포 결과가 있음Googlebot도 동일 HTML을 받는지
site: 결과 0건그 검색에서 결과를 찾지 못함전체 색인 수, 순위가 낮은 원인
robots·sitemap 파일 존재발견/크롤링을 안내하는 파일이 있음모든 URL의 canonical/noindex/품질 정상
TXT 인증 실패소유권 확인 요청이 통과하지 못함옛 토큰 충돌인지 DNS 캐시인지
HTML 태그 인증 성공URL 접두사 속성 소유권 확인됨글이 색인되거나 순위가 오름

robots·sitemap·페이지 신호 점검

당시 robots.txt는 다음 형태였습니다. URL 수는 2026-04-28 스냅샷에서 사이트맵 약 72개, 이미지 사이트맵 11개였으며 현행 개수와 다를 수 있습니다.

User-agent: *
Allow: /

Sitemap: https://blog.ruahverce.com/sitemap-index.xml
Sitemap: https://blog.ruahverce.com/sitemap-images.xml

robots.txt의 허용은 크롤링을 막지 않는다는 뜻입니다. 색인을 명령하거나 HTML의 noindex를 덮어쓰지 않습니다. Google robots 안내에 따라 실제 글 URL도 함께 검사합니다.

<meta name="robots" content="index,follow,max-image-preview:large" />

max-image-preview:large는 큰 이미지 미리보기의 허용 설정이며 실제 노출이나 클릭률 향상은 보장하지 않습니다. 구조화 데이터 역시 페이지의 의미를 설명하는 수단입니다. 정상 JSON-LD 하나만으로 SEO 전체가 완벽하다고 판단하지 않습니다.

점검 순서는 HTTP 상태 → 실제 본문 → robots/noindex → canonical → sitemap 포함 → 내부 링크 → URL 검사로 둡니다. 이 순서면 파일이 존재하는지와 검색엔진이 글을 사용할 수 있는지를 구분할 수 있습니다.

신생 도메인을 이유로 3~6개월 기다려야 하나

고정 기간을 기다려야 한다는 근거는 없습니다. Google의 재크롤링 안내는 크롤링에 며칠에서 몇 주가 걸릴 수 있고, 요청해도 검색 결과 포함을 보장하지 않는다고 설명합니다. 이는 모든 신규 도메인에 3~6개월의 “샌드박스”가 적용된다는 말과 다릅니다.

외부 링크가 적거나 sitemap을 제출하지 않았다면 발견 경로를 늘리는 작업은 할 수 있습니다. 하지만 Search Console 미등록이 곧 발견 불가능을 뜻하지는 않습니다. Sitemap 제출과 색인 요청을 크롤 큐의 강제 실행 버튼처럼 설명해서도 안 됩니다.

제가 바로 할 수 있었던 일은 소유권 확인, 사이트맵 제출, 핵심 URL 검사였습니다. 이후에는 실제 페이지 색인 상태와 검색 실적을 관측해야 하며 도메인 연령만으로 원인을 설명하지 않습니다.

Search Console 속성과 인증 방법

공식 소유권 확인 문서를 기준으로 선택합니다.

속성범위인증의 출발점
도메인 속성해당 도메인과 하위 도메인·프로토콜DNS 공급자 방식
URL 접두사 속성지정한 프로토콜·호스트·경로HTML 태그/파일 등 표시되는 지원 방식

제 경우 ruahverce.com 도메인 속성에 DNS TXT를 추가했지만 “인증 토큰을 찾을 수 없다”는 오류가 나왔습니다. 이 사실과 원인 진단은 나눠야 합니다.

DNS 응답은 어느 resolver에서 봤는지 기록한다

Google Public DNS의 DoH JSON API를 사용하면 공개 재귀 resolver의 TXT 응답을 확인할 수 있습니다.

curl -fsS 'https://dns.google/resolve?name=ruahverce.com&type=TXT' \
  | python3 -m json.tool

이 응답은 권위 DNS에 직접 질의한 결과도, Search Console 인증 시스템이 같은 순간 읽은 값의 보증도 아닙니다. 캐시·TTL과 조회한 호스트를 함께 기록합니다. 인증 화면이 지시한 호스트와 토큰 값, 실제 권위 nameserver, 공개 resolver 응답을 비교해야 원인을 좁힐 수 있습니다.

당시 조회에서는 root에 TXT 한 개가, blog.ruahverce.com에는 TXT 0개가 보였습니다. 어느 호스트를 검증하는지에 따라 필요한 위치가 다르므로 서브도메인 TXT 0개 자체가 오류의 증거는 아닙니다. 옛 토큰 충돌 때문이었다는 초기 설명은 확인되지 않은 가설로 정정합니다.

Google은 여러 소유자의 검증을 허용합니다. 기존 토큰이나 메일·SaaS TXT를 지우고 새 토큰 하나만 남기는 방식으로 해결하려 하지 않습니다.

URL 접두사와 HTML 태그로 확인한 과정

저는 블로그 서브도메인을 우선 확인하기 위해 https://blog.ruahverce.com/ URL 접두사 속성을 선택했습니다. 인증 화면에서 발급된 값을 공개 홈페이지의 head에 넣습니다.

<meta name="google-site-verification" content="YOUR_VERIFICATION_TOKEN" />

Astro에서는 공통 레이아웃에 넣어 관리했습니다. 모든 글 페이지에 있어야 하는 것이 인증 필수조건은 아닙니다. Google은 속성의 공개 홈페이지에서 태그를 확인합니다. 인증 뒤에도 해당 태그를 유지해야 합니다.

당시 커밋 23707fe를 배포한 뒤 약 90초 만에 라이브 반영과 인증을 확인했습니다. 이것은 제 배포에서 관측한 시간이며 다른 사이트의 보장 시간이 아닙니다.

DNS TXT 확인 실패 후 URL 접두사 홈페이지의 HTML 태그를 확인해 소유권 인증을 마친 과정

TXT 실패의 정확한 원인을 확정하지 않은 상태에서 대체 인증을 완료한 흐름입니다. 인증 성공과 글 색인은 별도 사건입니다.

네이버 서치어드바이저 등록

네이버에서도 사이트를 추가하고 관리 화면의 소유 확인 안내를 따릅니다. 당시에는 HTML 태그 방식을 골라 공통 head에 추가했습니다.

<meta name="naver-site-verification" content="YOUR_NAVER_VERIFICATION_TOKEN" />

커밋 3dca8df의 배포에서 약 120초 뒤 반영을 확인했습니다. 두 배포의 시간 차이를 Google과 네이버의 색인 속도 차이로 해석하지 않습니다. 다른 검색엔진의 등록 옵션이 같다고 가정하지 말고 각 관리 화면의 지원 방식을 확인합니다.

등록 뒤 체크리스트: 발견·크롤링·색인·실적

  1. 사이트맵 제출: Google과 네이버에서 제출 가능한 sitemap 위치와 처리 결과를 확인합니다.
  2. 핵심 URL 검사: 홈과 대표 글의 라이브 HTML, canonical, noindex, 크롤링 허용 상태를 확인합니다.
  3. 색인 상태 기록: 제출 날짜·마지막 크롤링·선택된 canonical·색인 제외 이유를 URL별로 남깁니다.
  4. 실적 관찰: 노출·클릭·검색어를 기간별로 비교합니다. 등록 직후 수치 하나로 콘텐츠 품질을 판단하지 않습니다.
  5. 변경 알림 자동화: IndexNow를 지원하는 검색엔진에는 변경 URL을 알릴 수 있습니다. 접수는 색인 보장이 아닙니다.

Google 일반 블로그는 sitemap과 URL 검사 흐름으로 관리합니다. Google Indexing API는 JobPosting 및 BroadcastEvent가 포함된 VideoObject처럼 지원되는 콘텐츠에 한정되므로 일반 글을 대량 제출하는 우회 수단으로 사용하지 않습니다.

자주 묻는 질문

TXT 인증이 왜 실패했나요? 당시 기록만으로 원인을 확정하지 못했습니다. 정확한 속성 호스트와 토큰, 권위 DNS 설정, TTL과 재귀 resolver 응답을 비교해야 합니다. 토큰 공존 자체를 실패 원인으로 단정하지 않습니다.

홈페이지만 태그를 넣으면 인증이 풀리나요? 공개 홈페이지 head에 올바른 태그를 유지하는 것이 공식 조건입니다. 공통 레이아웃은 이를 관리하는 선택지입니다.

등록하면 바로 검색되나요? 소유권 확인·크롤링 요청·색인·순위는 별도 단계입니다. 어느 단계에서 멈췄는지 보고서와 URL 검사로 확인합니다.

회고: 기다림을 원인 설명으로 쓰지 않기

배포 자동화는 사이트를 공개하는 마찰을 낮췄지만 검색엔진의 판단까지 자동으로 끝내지는 못했습니다. 이번 경험에서 남길 것은 “신생 도메인은 몇 달 기다린다”는 규칙이 아니라, 관측한 증상과 확인한 원인을 분리하고 다음 검사로 연결하는 방식입니다.

플랫폼 선택 → 배포 구성 → 검색 등록까지 만들었다면, 다음에는 독자가 실제로 해결할 문제와 그 문제를 뒷받침하는 원천 자료를 글에 채웁니다. 검색 실적은 그 다음에 관측할 결과입니다.

참고자료