Field Log · Entry

개인 도메인 블로그가 구글에서 검색 안 될 때 — Search Console + 네이버 서치어드바이저 등록기 (3/3)

블로그 운영기 시리즈 3편 — 신규 도메인이 구글에 안 잡히던 시기, GSC와 네이버 검색 등록 회고

1편에서 자동화 실패와 결정을, 2편에서 Astro·Railway·Cloudflare 스택 셋업을 적었습니다. 이번 글은 그 다음에 부딪힌 벽 — 사이트는 떴는데 구글에 1건도 안 잡히던 첫 2주의 1차 회고입니다. 자체 SEO 신호는 완벽했고, Google Search Console DNS TXT 인증은 실패했고, 메타 태그 우회로 2분 만에 통과했습니다. 그 과정과 함정, 그리고 시리즈 마지막 결론까지.

이 글이 답하는 질문

신규 도메인은 왜 구글에 안 잡히는가? robots.txt·sitemap이 있는데도 왜?
DNS TXT 인증이 실패했을 때, 어디서부터 디버깅하나?
한국 블로그라면 네이버 서치어드바이저는 같은 패턴인가?

배포 완료, 그런데 site:blog.ruahverce.com 결과는 0건

2편을 끝낸 직후의 상태는 단순했습니다. 빌드 통과, Railway 배포 통과, Cloudflare 프록시 정상, https://blog.ruahverce.com 정상 응답. 글도 6편 정도 올라가 있었습니다.

그런데 구글에서 site:blog.ruahverce.com을 쳐봤더니 결과가 0건이었습니다. “하네스 엔지니어링”, “사내 RAG 회고” 같은 본문에 박힌 키워드를 쳐봐도 velog, gpters, brunch, OpenAI, 토스 기술블로그 같은 다른 사이트만 줄줄이 나왔습니다. blog.ruahverce.com 흔적은 어디에도 없었습니다.

배포 4일차였습니다. 처음에는 “원래 시간이 걸리겠지”라고 넘어갔다가, 같은 키워드로 네이버·다음·Bing도 다 0건인 걸 보고 자세를 바로 잡았습니다. 수동적으로 기다리는 단계가 아니라 능동적으로 알리러 가야 하는 단계였습니다.

이 시점에 처음 떠오른 가설은 “robots.txt나 sitemap이 잘못 깔렸나”였습니다. 그래서 자체 신호부터 점검했습니다.

자체 SEO 신호는 완벽했다 — robots.txt·sitemap·JSON-LD 점검

먼저 라이브 사이트의 robots.txt를 직접 받아서 확인했습니다.

User-agent: *
Allow: /

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

robots.txt 표준의 최소 권장 형태 그대로입니다. 모든 봇 허용 + 사이트맵 두 개 알림. Google Search Central 문서도 같은 패턴을 권장합니다.

sitemap-index.xml은 Astro의 @astrojs/sitemap 통합이 자동 생성합니다. 그 안에서 sitemap-0.xml이 글·시리즈·태그 페이지 URL 70여 개(2026-04-28 기준 72개, 글·태그·시리즈가 늘어날수록 자동 갱신)를 담고, sitemap-images.xml이 OG 이미지·다이어그램 URL 11개를 별도로 담는 구조입니다.

각 페이지 head의 robots 메타도 점검했습니다. Astro의 BaseLayout.astro 한 곳에서 통제됩니다.

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

max-image-preview:large는 SERP에 큰 썸네일을 허용하는 옵션입니다. 클릭률에 직접 영향이 있어 정적 콘텐츠 사이트는 켜두는 편이 유리합니다.

JSON-LD 구조화 데이터는 세 종류를 발행했습니다 — WebSite, BlogPosting, BreadcrumbList. 사내 RAG에서도 외부 시스템에 데이터를 넘길 때는 스키마부터 맞춰주는 게 정석인데, 검색엔진에 글의 구조를 명시적으로 알려주는 같은 패턴입니다.

여기까지 자체 신호는 합격이었습니다. 그런데도 색인이 0건. 자체 robots.txt와 sitemap은 어디까지나 수동적 신호라는 게 그제서야 와닿았습니다. 누군가 사이트를 발견해 줘야 그 신호를 읽으러 옵니다.

진짜 원인 3가지 — 신생 도메인, 백링크 0, GSC 미제출

원인을 세 줄로 정리하면 다음과 같았습니다.

1. 신생 도메인의 샌드박스 효과. 도메인을 산 지 4일째였습니다. 구글은 신규 도메인에 보통 3~6개월 정도의 관망 기간을 둡니다. 이 기간에는 글의 품질과 무관하게 색인 자체가 보수적으로 들어옵니다. Google Search Central 문서에서는 “샌드박스”라는 공식 용어를 쓰지는 않지만, 신규 사이트는 신뢰 평가가 누적되어야 한다는 표현으로 같은 사실을 인정합니다.

2. 백링크 0. 외부에서 사이트로 연결되는 링크가 한 개도 없는 상태였습니다. 검색봇이 이 사이트를 발견할 외부 경로 자체가 없는 상황입니다. robots.txt와 sitemap은 발견된 다음에 읽히는 신호이지 발견을 만드는 신호가 아닙니다.

3. Search Console 미제출. 1번과 2번이 시간이 메우는 변수라면, 3번은 하루 안에 메울 수 있는 변수입니다. GSC에 사이트를 등록하고 sitemap을 제출하면 — 글의 URL 검사·색인 요청까지 한 번에 — 봇의 크롤 큐에 강제로 넣을 수 있습니다.

그래서 우선순위는 명확했습니다. 3번을 즉시 처리하고, 1·2번은 시간을 쌓으면서 [4편 이후 글]에서 운영자 해자(PHM·반도체·사내 RAG)를 누적해 자연 백링크를 받자.

Google Search Console — DNS TXT 인증 실패 우회기

두 가지 등록 방법

GSC에 도메인을 추가하는 방법은 두 가지입니다.

도메인 속성: ruahverce.com 자체와 모든 서브도메인을 한 번에 묶음. 인증은 DNS TXT 레코드만 가능.
URL 접두사 속성: https://blog.ruahverce.com/처럼 특정 서브도메인·프로토콜만 묶음. 인증은 HTML 메타 태그·HTML 파일·Google Analytics·Google Tag Manager 중 선택.

처음에는 도메인 속성을 골랐습니다. 한 번에 묶는 쪽이 깔끔해 보였고, Cloudflare DNS도 이미 잡혀 있어서 TXT 한 줄 추가는 어렵지 않을 거라 생각했습니다. 그런데 GSC가 발급한 토큰을 Cloudflare DNS에 추가하고 확인을 누르자 다음 메시지가 떴습니다.

소유권을 확인할 수 없습니다. 도메인 이름 공급업체 / 도메인의 TXT 레코드에서 인증 토큰을 찾을 수 없습니다.

DoH로 권위 응답 직접 진단

Cloudflare DNS UI 상에는 분명 추가됐는데 GSC가 못 본다는 게 첫 의문이었습니다. DNS 전파 지연일 수 있어서 일단 DNS over HTTPS로 직접 조회해 봤습니다. WSL에서 일반적인 dig를 쓰면 사내망 DNS 캐시를 거치는데, Google의 공개 DoH 엔드포인트를 쓰면 Google이 그 시점에 보는 값을 그대로 받아볼 수 있습니다.

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

응답에는 root 도메인(ruahverce.com)에 TXT 레코드가 단 1개 있었습니다.

google-site-verification=yx0C_x-xohDAh8LiydyYRapQWuySaFUnBCGYmFCbUcQ

그런데 같은 명령을 name=blog.ruahverce.com으로 바꿔서 쳐봤더니 TXT 레코드가 0건이었습니다. 도메인 속성은 root 호스트의 TXT를 본다는 건 알았지만, 과거 다른 시점에 root에 박아둔 토큰이 남아 있는데 GSC가 그걸 새 토큰으로 인식하지 않는 상태였습니다. Cloudflare DNS UI에 이번 세션의 토큰을 추가했음에도 어딘가에서 옛 토큰이 함께 응답되면서 인증이 어긋났습니다.

URL 접두사 + HTML 메타 태그로 우회

여기서 두 가지 시나리오가 갈렸습니다.

시나리오 A: root TXT를 정리하고 새 토큰만 남긴 뒤 재검증. 안전하지만 다른 서비스(예: 메일·SaaS)가 박아둔 TXT가 있으면 같이 정리해야 해서 작업 범위가 커짐.
시나리오 B: 도메인 속성을 포기하고 URL 접두사 속성 + HTML 메타 태그로 우회. blog 서브도메인만 묶이지만, 이 사이트는 다른 서브도메인 계획이 없어 손실이 작음.

박사과정 일정과 본업 사이의 시간이 가장 큰 변수라서 B를 골랐습니다. GSC에서 URL 접두사 속성을 새로 만들고 HTML 메타 태그 인증을 선택하면 한 줄짜리 메타 태그를 받습니다.

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

이 한 줄을 BaseLayout.astro의 <head>에 박았습니다. 모든 페이지에 동일하게 들어가도록 공통 레이아웃에 두는 게 핵심입니다 — 인덱스 페이지에만 두면 GSC가 다른 URL을 검사할 때 메타가 사라져 인증이 풀릴 수 있습니다.

빌드 → git push → Railway 자동 빌드 → Cloudflare CDN 캐시 갱신까지 90초 정도 걸렸고, GSC 화면에서 확인을 누르자 곧바로 통과했습니다. 커밋은 23707fe 한 줄짜리 변경입니다.

검색 등록 흐름 — DNS TXT 인증 실패에서 메타 태그 우회 성공까지

위 다이어그램: GSC 도메인 속성 + DNS TXT 시도 → 옛 토큰 충돌·서브도메인 0건 발견 → URL 접두사 속성 + 메타 태그 우회 → 90초 라이브 반영 흐름.

DNS 디버깅은 사내 RAG에서 외부 SaaS와 SSO를 묶을 때 한 번 겪었던 패턴입니다. 그때도 root에 옛 토큰이 남아서 새 검증 페이로드가 어긋났고, DoH로 권위 응답을 직접 보는 것이 가장 빠른 진단이었습니다.

네이버 서치어드바이저 — 같은 메타 태그 패턴

한국어 콘텐츠 사이트라 네이버는 우선순위가 구글 다음입니다. 한국 검색 트래픽의 큰 비중이 네이버 검색에서 발생하기 때문에 GSC만 등록하고 끝낼 수 없습니다.

네이버 서치어드바이저는 GSC와 인증 방식 옵션이 거의 같습니다. HTML 파일·메타 태그·DNS TXT 중에서 메타 태그를 골랐습니다. 같은 BaseLayout <head>에 한 줄 더 추가합니다.

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

빌드 → push → 라이브 반영까지 120초. GSC보다 살짝 느렸지만 같은 흐름입니다. 커밋은 3dca8df입니다.

서치어드바이저의 강점은 한국어 검색 의도와 키워드 통계가 반영된다는 점입니다. 반대로 사이트맵 색인 속도는 GSC가 빠른 편이라 두 군데를 다 등록하면 색인 진입 채널이 두 개로 늘어나는 효과가 있습니다.

위 두 자리표시는 GSC 인증 통과 화면, 네이버 서치어드바이저 인증 통과 화면. 게시 직전 publish-blog 단계에서 실제 캡처로 교체합니다.

다음 액션 — sitemap submit, URL 검사, IndexNow API

인증이 끝나면 그 다음은 사이트맵 제출과 핵심 URL의 색인 요청입니다. GSC와 네이버 서치어드바이저 모두 같은 흐름입니다.

Google Search Console 쪽:

사이트맵 메뉴에서 sitemap-index.xml과 sitemap-images.xml 두 줄 제출.
URL 검사 도구에 핵심 글(시리즈 1·2·3편)의 절대 URL을 넣고 색인 생성 요청. 일일 쿼터가 있으니 글 6편 기준이면 한 번에 다 처리할 수 있습니다.

네이버 서치어드바이저 쪽:

요청 → 사이트맵 제출 메뉴에 같은 URL 두 줄.
요청 → 웹페이지 수집 메뉴에서 핵심 글 URL을 개별 수집 요청.

여기까지 하면 사람이 할 수 있는 능동 신호는 끝납니다. 한 가지 더 자동화할 수 있는 채널이 IndexNow입니다. 사이트가 글을 새로 올리거나 수정할 때 검색엔진에 HTTP 요청 한 줄로 알리는 표준입니다. 현재 Bing·Yandex·Naver가 채택했고, Google은 채택하지 않았습니다. 구글은 Indexing API를 별도로 운영하지만 job posting과 livestream 콘텐츠에 한정됩니다 — 일반 블로그는 sitemap + URL 검사 도구로 가는 게 정공법입니다.

운영 팁 한 가지 — Railway 빌드 후 IndexNow 핑을 자동으로 쏘는 후크를 만들면 push가 곧 검색엔진 알림으로 이어집니다. 2편에서 만든 git push → 빌드 → 배포 라인의 끝에 → IndexNow 핑 한 단계를 더 붙이는 일입니다.

바이브 코딩이 못 메우는 시간 — 도메인 연령은 누적이다

여기서 시리즈 전체의 정직한 결론이 나옵니다.

1편·2편에서 강조한 바이브 코딩은 인프라 비용을 1년 전 대비 압도적으로 낮춥니다. 1주일이면 정적 사이트, 자동 빌드, CDN, 도메인까지 깔립니다. 그런데 이번 편에서 부딪힌 벽은 시간이 메워야만 하는 변수들이었습니다.

도메인 연령: 4일된 도메인은 4일치 권위만 가집니다. 코드로 줄일 수 없습니다.
백링크: 외부 사이트가 인용해줘야 쌓입니다. AI가 대신 만들어줄 수 없습니다.
검색엔진의 신뢰 누적: 색인된 글이 시간이 지나며 유지·갱신·내부 링크 정합성을 통과해야 합니다.

세 변수 모두 push 한 번으로 메울 수 없는 양입니다. 1편 FAQ에서 “개인 도메인 블로그로 수익화가 가능한가요”라는 질문에 단기적으로는 어렵다, 1년 단위 누적 게임이라고 답한 이유가 여기 있습니다.

박사과정 일정과 본업 사이에서 글을 쓸 수 있는 시간은 새벽 1시간, 점심 30분입니다. 이 페이스로 시간 변수를 메우는 가장 현실적인 길은 두 가지입니다.

한 편을 진하게. 운영자 해자(PHM, 반도체, 사내 RAG)가 닿는 롱테일 키워드를 골라 한 편당 정보 밀도와 1차 자료 비중을 높입니다. 양보다 누적되는 권위.
시리즈를 닫아 두기. 흩어진 글보다 한 묶음으로 닫힌 시리즈가 내부 링크와 사용자 체류 시간 모두에서 신호가 좋습니다. 이 시리즈가 그 첫 사례입니다.

바이브 코딩이 가능 조건을 만들고, 그 위에 시간 변수가 쌓이는 구조 — 이게 1편의 명제 *“지금 시점이라야 가능했던 결정”*의 또 다른 면입니다. 출발이 가능해진다고 도착까지 가까워지지는 않습니다.

FAQ

Q1. DNS TXT 인증은 왜 실패했나요? GSC 도메인 속성은 root 호스트(ruahverce.com)의 TXT 레코드를 봅니다. root에 옛 검증 토큰이 남아 있는 상태에서 새 세션의 토큰을 추가하면, DNS over HTTPS로는 두 토큰이 모두 반환되어도 GSC가 현재 세션의 토큰을 식별하지 못해 실패할 수 있습니다. root TXT를 정리하거나, URL 접두사 속성 + HTML 메타 태그로 우회하는 게 빠른 해법입니다.

Q2. 메타 태그 인증의 함정은 무엇인가요? 가장 큰 함정은 메타 태그가 모든 페이지의 <head>에 들어 있는지입니다. 인덱스 페이지에만 추가하면, GSC가 다른 페이지를 검사할 때 메타가 사라져 인증이 풀릴 수 있습니다. Astro라면 BaseLayout.astro, Next.js라면 _document.tsx 또는 layout — 어떤 프레임워크든 공통 head에 두는 게 안전합니다.

Q3. IndexNow는 왜 Google이 안 받나요? Google은 자체 Indexing API를 운영하고, 이 API는 job posting과 livestream 콘텐츠에 사용 범위를 한정해 두었습니다. 일반 블로그·기술 글에는 받지 않습니다. Google 색인은 sitemap 제출 + URL 검사 도구가 정공법이고, Bing·네이버·Yandex는 IndexNow로 자동화 가능합니다.

Q4. 시리즈 다음 글은 어떤 방향인가요? 이 글로 블로그 운영기 시리즈는 닫힙니다. 다음 단계는 운영자 해자가 닿는 영역 — PHM 데이터 파이프라인, 반도체 장비 알람 분류, 사내 RAG 회고, LLM agent 시스템 설계 — 의 본격 글로 넘어갑니다. 1년 누적 게임의 본 게임이 그쪽입니다.

마무리 — 시리즈를 닫으며

자체 신호는 수동적입니다. robots.txt와 sitemap이 완벽해도, Google Search Console·네이버 서치어드바이저 같은 능동 등록이 없으면 신생 도메인은 발견되지 않습니다.
DNS TXT가 막히면 메타 태그로 우회합니다. DNS over HTTPS로 권위 응답을 직접 보는 게 가장 빠른 디버깅이고, URL 접두사 속성 + 메타 태그면 90초 안에 통과합니다. 메타는 공통 레이아웃 head에 두어야 안전합니다.
시간이 메우는 변수는 시간이 메웁니다. 도메인 연령·백링크·신뢰 누적은 push로 줄지 않습니다. 바이브 코딩이 출발을 가능하게 했고, 누적은 글과 시간이 합니다.

시리즈 세 편을 한 줄로 묶으면 다음과 같습니다.

1편 — Tistory·네이버 자동화 실패에서 git 기반 정적 블로그로 결정. 2편 — Astro·Railway·Cloudflare로 git push 자동 배포 라인 구축. 이번 글(3편) — 신생 도메인이 검색에 잡히기 시작한 첫 단계.

1주일 남짓의 1차 회고였습니다. 다음 글부터는 운영자 해자 본격 글로 갑니다.

도착점: blog.ruahverce.com 현재 hero — Astro·Railway·Cloudflare 스택으로 운영 중

위 이미지: 시리즈 세 편으로 만든 사이트의 현재 hero. 인프라가 깔리고, 검색엔진 채널까지 열린 상태에서 본 게임이 시작됩니다.