티스토리에 개인 도메인을 연결한 뒤 구글 검색 유입을 확인하려면 구글 서치콘솔에 블로그를 등록해야 한다. 티스토리 기본 주소를 사용할 때는 HTML 태그를 스킨에 넣는 방법이 익숙하지만, 개인 도메인을 ‘도메인 속성’으로 등록하면 DNS에 TXT 레코드를 추가하라는 화면이 나타난다.
여기서부터 초보자는 막막해진다. 도메인 업체의 DNS 관리 화면에 들어가도 ‘호스트’, ‘값’, ‘TTL’처럼 처음 보는 항목이 있고, 구글에서 복사한 인증 문자열을 어디에 넣어야 하는지 헷갈린다. 어떤 업체는 TXT 값에 따옴표를 자동으로 붙이기도 한다.
분명 구글이 준 값을 복사해 넣었는데 소유권 확인 버튼을 누르면 “TXT 레코드를 찾을 수 없습니다”라는 메시지가 나타나기도 한다. 호스트에 도메인 전체를 써야 하는지, 빈칸으로 두어야 하는지, @를 입력해야 하는지도 업체마다 설명이 달라 보인다.
결론부터 말하면 구글 서치콘솔의 도메인 소유권 확인이 실패하는 가장 흔한 이유는 다음 세 가지다.
첫째, 실제 DNS를 관리하는 곳이 아닌 다른 사이트에 TXT 레코드를 등록한 경우다.
둘째, 호스트와 값의 위치를 바꾸어 입력했거나 인증 문자열을 일부 수정한 경우다.
셋째, 설정은 정상적으로 했지만 DNS 정보가 아직 인터넷 전체에 반영되지 않은 경우다.
오늘은 구글 서치콘솔에서 도메인 소유권 확인이 안 되는 이유를 경험을 토대로 해결 사례를 공유해 본다. :)
※ 이 글은 2026년 8월 1일 기준으로 구글 서치콘솔과 티스토리의 공식 안내를 참고해 작성했습니다. 도메인 업체에 따라 DNS 메뉴와 입력란의 이름은 다를 수 있습니다.
1. 티스토리 연결과 구글 소유권 확인은 서로 다른 설정이다
먼저 티스토리에 개인 도메인을 연결하는 것과 구글 서치콘솔에서 도메인 소유권을 확인하는 것은 별개의 작업이라는 점부터 알아야 한다.
티스토리에 개인 도메인을 연결할 때는 도메인으로 접속한 방문자를 티스토리 블로그로 보내기 위한 DNS 설정이 필요하다. 일반적으로 CNAME 레코드 등을 사용하며, 티스토리는 개인 도메인 연결을 위해 host.tistory.io 또는 blog.tistory.com 가운데 하나를 목적지로 사용할 수 있다고 안내한다.
반면 구글 서치콘솔의 TXT 레코드는 방문자를 어디로 연결하기 위한 설정이 아니다. 해당 도메인의 DNS를 수정할 권한이 있는 사람인지를 확인하기 위한 인증용 정보다.
따라서 티스토리 연결에 사용한 CNAME 레코드와 구글 소유권 확인에 사용하는 TXT 레코드는 용도도 다르고 종류도 다르다.
예를 들어 www.example.com을 티스토리에 연결하기 위해 다음과 같은 CNAME 레코드가 이미 있다고 가정해 보자.
유형: CNAME
호스트: www
값 또는 목적지: host.tistory.io
구글 서치콘솔 인증을 위해서는 이 CNAME을 지우거나 수정하는 것이 아니라 별도의 TXT 레코드를 새로 추가해야 한다.
유형: TXT
호스트: @ 또는 빈칸
값: google-site-verification=구글에서_제공한_문자열
기존 CNAME을 TXT로 바꾸면 구글 인증보다 먼저 개인 도메인으로 티스토리에 접속하는 기능이 망가질 수 있다. DNS 관리 화면에서 반드시 ‘기존 레코드 수정’이 아니라 ‘새 레코드 추가’를 선택해야 한다.
서치콘솔에서 속성을 추가할 때도 ‘도메인’과 ‘URL 접두어’를 구분해야 한다.
‘도메인’ 속성에는 다음처럼 주소만 입력한다.
example.com
https://나 http://, www, 마지막의 /와 글 주소는 넣지 않는다. 도메인 속성으로 등록하면 http, https, www가 있는 주소와 없는 주소, 해당 도메인의 여러 하위 도메인을 한꺼번에 포함할 수 있다. 구글은 루트 도메인의 소유권을 확인하면 그 아래의 하위 도메인도 함께 확인된다고 안내한다.
반면 ‘URL 접두어’ 속성에는 실제로 사용하는 전체 주소를 입력한다.
URL 접두어 속성은 입력한 주소 형태만 대상으로 한다. https://www.example.com/과 https://example.com/은 서로 다른 속성으로 취급될 수 있다. 대신 HTML 태그나 구글 애널리틱스 등 DNS 이외의 인증 방법을 선택할 수 있다.
개인 도메인의 모든 주소 형태를 한꺼번에 관리하고 싶다면 도메인 속성이 편리하다. 하지만 DNS 수정 권한이 없거나 설정이 너무 어렵다면 실제 티스토리 주소를 URL 접두어 속성으로 등록하고 HTML 태그 방식으로 인증하는 방법도 있다.
여기서 또 하나 자주 생기는 문제가 있다. 도메인을 구입한 업체와 DNS를 실제로 관리하는 업체가 다를 수 있다는 것이다.
예를 들어 가비아에서 도메인을 구입했지만 네임서버를 Cloudflare로 변경했다면 실제 DNS 레코드는 가비아가 아니라 Cloudflare에서 관리해야 한다. 가비아 화면에 TXT를 등록해도 현재 인터넷에 공개되는 DNS가 Cloudflare라면 구글은 그 값을 찾지 못한다.
도메인 구입처에 들어가기 전에 현재 네임서버가 어디를 가리키는지 확인해야 한다. 도메인 업체의 ‘네임서버 정보’에서 확인하거나 Google Admin Toolbox 같은 DNS 조회 도구를 이용할 수 있다. 구글도 인증 오류를 확인할 때 실제 DNS에서 TXT 레코드가 제공되고 있는지 Admin Toolbox로 조회하도록 안내한다.
2. 호스트와 TXT 값, TTL에는 무엇을 입력해야 할까
구글 서치콘솔에서 도메인 속성을 추가하면 다음과 비슷한 인증 문자열이 나타난다.
google-site-verification=AbCdEf1234567890
이 문자열은 예시일 뿐이며 실제로는 사용자와 속성마다 다른 값이 발급된다. 다른 사람의 블로그에서 본 값을 복사하거나 예시 문자열을 그대로 사용하면 인증되지 않는다. 반드시 본인의 서치콘솔 화면에서 발급된 전체 문자열을 복사해야 한다.
도메인 업체의 DNS 관리 화면에서 ‘레코드 추가’를 누른 뒤 다음과 같이 입력한다.
| 입력 항목 | 일반적인 입력 내용 |
|---|---|
레코드 유형 |
TXT |
| 호스트·이름·Name | 빈칸 또는 @ |
| 값·내용·Value | google-site-verification=... 전체 문자열 |
| TTL | 업체 기본값 또는 자동 |
| 우선순위 | TXT 레코드에는 보통 입력하지 않음 |
가장 헷갈리는 부분은 호스트다. 구글은 루트 도메인을 TXT 방식으로 확인할 때 호스트 또는 이름 입력란을 비워 두거나, 도메인 업체의 안내에 따라 @를 입력하라고 설명한다.
여기서 @는 이메일 주소의 골뱅이를 뜻하는 것이 아니라 현재 관리 중인 루트 도메인 자체를 의미한다. DNS 관리 화면이 example.com 영역이라면 @는 example.com을 가리킨다고 이해하면 된다.
도메인 업체에 따라 호스트 입력 방식은 다를 수 있다.
빈칸을 허용하는 업체: 호스트를 비워 둔다.
빈칸을 허용하지 않는 업체: @를 입력한다.
도메인을 자동으로 붙이는 업체: @나 빈칸만 사용한다.
전체 도메인을 요구하는 업체: 해당 업체의 안내에 따라 example.com을 입력한다.
많은 DNS 서비스는 호스트에 입력한 글자 뒤에 현재 도메인을 자동으로 붙인다. 이때 호스트에 example.com을 직접 넣으면 실제로는 example.com.example.com이라는 잘못된 위치에 등록될 수도 있다.
따라서 입력 화면 옆에 .example.com이 이미 표시되어 있다면 전체 주소를 반복해서 넣지 않는 것이 좋다. 예를 들어 호스트 입력란 오른쪽에 .example.com이 고정되어 있다면 www를 입력할 때 최종적으로 www.example.com이 되는 구조다. 루트 도메인 인증은 대개 @ 또는 빈칸으로 처리한다.
TXT 값에는 구글이 제공한 문자열을 처음부터 끝까지 그대로 붙여 넣어야 한다.
google-site-verification=AbCdEf1234567890
google-site-verification= 부분을 빼면 안 되고, 등호 뒤의 문자만 입력해서도 안 된다. 앞뒤에 공백을 넣거나 줄을 바꾸고, 임의로 따옴표나 마침표를 추가해서도 안 된다. 여러 줄로 나누지 말고 한 줄 그대로 붙여 넣는다.
기존에 SPF나 네이버, 다른 구글 서비스 인증용 TXT 레코드가 있더라도 보통은 삭제할 필요가 없다. TXT 레코드는 같은 루트 도메인에 여러 개 존재할 수 있다. 기존 값을 덮어쓰지 말고 구글 서치콘솔 인증용 TXT를 별도의 레코드로 추가하는 것이 안전하다.
따옴표는 DNS 업체의 입력 방식에 따라 다르게 보일 수 있다. 사용자는 따옴표 없이 다음과 같이 입력했는데 저장 후 목록이나 DNS 조회 결과에는 양쪽에 큰따옴표가 붙어 있을 수 있다.
"google-site-verification=AbCdEf1234567890"
이것이 반드시 오류라는 뜻은 아니다. TXT 레코드는 DNS 시스템에서 문자열로 표현되기 때문에 관리업체가 저장하거나 보여주는 과정에서 따옴표를 자동으로 붙일 수 있다. 예를 들어 Cloudflare는 TXT 값을 따옴표 없이 저장하면 시스템이 큰따옴표를 자동으로 추가한다고 공식 문서에서 설명한다.
중요한 것은 사용자가 입력한 값 안에 불필요한 따옴표가 실제 문자로 중복 저장되지 않는 것이다. 업체가 자동으로 붙이는 따옴표는 정상일 수 있지만, 사용자가 따옴표까지 직접 넣은 뒤 업체가 다시 따옴표를 처리하면 값이 달라질 수 있다.
가장 안전한 방법은 도메인 업체가 별도로 따옴표 입력을 요구하지 않는 한 구글이 준 문자열을 따옴표 없이 그대로 붙여 넣는 것이다. 저장 후 목록에 따옴표가 자동으로 보인다면 일단 그대로 두고 외부 DNS 조회 결과에서 인증 문자열이 정상적으로 나타나는지 확인한다.
TTL은 DNS 정보를 다른 서버가 얼마 동안 기억할지를 정하는 시간이다. 초 단위로 표시되는 경우가 많다.
300: 5분
600: 10분
3,600: 1시간
14,400: 4시간
86,400: 24시간
소유권 확인을 위해 반드시 특정 TTL을 입력해야 하는 것은 아니다. 구글도 DNS 업체가 제안하는 기본 TTL 값을 사용할 수 있다고 안내한다. 자동, 기본값, 300초, 600초, 3,600초 가운데 업체가 기본으로 보여주는 값을 그대로 사용해도 된다.
TTL을 짧게 설정한다고 TXT 레코드가 구글에 무조건 즉시 반영되는 것은 아니다. TTL은 이미 조회된 DNS 정보를 얼마나 오래 보관할지에 영향을 주는 값이지, 도메인 업체가 새 레코드를 실제 네임서버에 게시하는 시간을 보장하는 버튼은 아니다.
3. 등록 후 바로 인증되지 않을 때 확인하는 순서
TXT 레코드를 저장한 다음 곧바로 서치콘솔의 ‘확인’ 버튼을 눌렀는데 실패하는 것은 드문 일이 아니다. DNS 변경 사항이 도메인 업체의 네임서버와 인터넷의 여러 DNS 서버에 전달되는 데 시간이 필요하기 때문이다.
빠르면 몇 분 안에 확인되지만 몇 시간 이상 걸릴 수도 있다. 구글은 수동으로 DNS 레코드를 등록한 경우 DNS 업체에서 새 레코드를 제공하기까지 2~3일이 걸릴 수 있으며, 인증에 실패하면 하루나 이틀 뒤 다시 시도하라고 안내한다.
따라서 저장 직후 인증에 실패했다고 TXT 레코드를 계속 삭제하고 다시 만들 필요는 없다. 설정이 맞다면 우선 몇 시간 기다린 뒤 다시 확인하고, 다음 날에도 실패한다면 외부에서 TXT 레코드가 보이는지 점검하는 것이 좋다.
Google Admin Toolbox의 Dig 기능에서 도메인을 입력하면 현재 외부에 공개된 TXT 레코드를 확인할 수 있다. 주소는 https://와 마지막 슬래시를 빼고 도메인만 입력한다.
example.com
조회 결과에 다음과 같은 문자열이 나타나는지 확인한다.
google-site-verification=AbCdEf1234567890
조회 결과에 인증 문자열이 전혀 없다면 구글 서치콘솔 문제가 아니라 DNS 설정이 아직 반영되지 않았거나 잘못된 네임서버에 등록했을 가능성이 크다. 이때 다음 순서로 확인해 보자.
첫째, 레코드 유형이 TXT인지 확인한다. 티스토리 연결에 사용하는 CNAME이나 A 레코드에 인증 문자열을 넣으면 안 된다.
둘째, 호스트가 루트 도메인을 가리키는지 확인한다. @ 또는 빈칸이어야 할 자리에 www를 넣었다면 TXT가 www.example.com에만 등록된다. 서치콘솔에서 example.com이라는 도메인 속성을 인증하고 있다면 루트 도메인에 값을 넣는 것이 일반적이다.
셋째, 값이 정확히 일치하는지 확인한다. 구글에서 복사한 google-site-verification= 전체 문자열과 DNS에 등록된 값을 한 글자씩 비교한다. 앞뒤 공백이나 잘못된 따옴표, 누락된 문자도 확인한다.
넷째, 현재 적용 중인 네임서버를 확인한다. 도메인을 구입한 업체와 네임서버를 운영하는 곳이 다르면 실제 네임서버가 있는 업체에 등록해야 한다.
다섯째, 저장 또는 적용 버튼을 끝까지 눌렀는지 확인한다. DNS 관리 화면에 따라 ‘추가’ 버튼을 누른 뒤 다시 ‘저장’, ‘적용’, ‘변경 완료’ 버튼을 눌러야 실제 반영되는 경우가 있다.
여섯째, 등록한 도메인과 서치콘솔 속성이 같은지 확인한다. example.com의 DNS에 TXT를 등록해 놓고 서치콘솔에는 철자가 다른 도메인을 추가했거나, 새 개인 도메인이 아닌 기존 티스토리 기본 주소를 보고 있을 수 있다.
일곱째, 예전에 받은 인증값이 아닌 현재 서치콘솔 화면에 표시되는 값을 사용했는지 확인한다. 여러 구글 계정이나 여러 속성을 등록하다 보면 다른 도메인의 TXT 값을 복사하기 쉽다.
외부 DNS 조회에서 인증 문자열이 정상적으로 보이는데도 구글 확인이 실패한다면 레코드를 그대로 둔 채 하루 정도 더 기다렸다가 다시 시도하는 것이 좋다. 구글은 DNS 레코드를 찾지 못하는 오류가 몇 분에서 며칠 동안 지속될 수 있다고 안내한다.
소유권 확인에 성공한 후에도 TXT 레코드는 삭제하지 않는 것이 좋다. 구글은 인증 상태를 유지하려면 확인이 끝난 뒤에도 DNS 레코드를 제거하지 말라고 안내한다. 나중에 구글이 다시 확인할 때 TXT 값이 사라져 있으면 소유권 인증이 해제될 수 있다.
또한 서치콘솔에서 ‘소유권이 확인되었습니다’라는 메시지가 나타났다고 해서 블로그 글이 곧바로 구글 검색에 노출되는 것은 아니다. 소유권 확인은 해당 도메인을 관리할 권한을 증명하는 과정일 뿐이다. 이후 사이트맵과 RSS를 제출하고, 구글이 페이지를 발견해 크롤링하고 색인하는 시간이 별도로 필요하다.
티스토리에 개인 도메인을 연결한 경우에는 개인 도메인으로 블로그가 정상적으로 열리는지도 확인해야 한다. DNS의 티스토리 연결 기록과 서치콘솔 인증 기록이 모두 정상이어야 하기 때문이다.
정리하면 티스토리 연결용 CNAME은 그대로 두고, 구글이 제공한 문자열을 별도의 TXT 레코드로 추가한다. 호스트는 도메인 업체의 방식에 따라 빈칸 또는 @, 값에는 google-site-verification=... 전체 문자열, TTL에는 기본값을 사용한다.
저장 후 따옴표가 자동으로 붙는 것은 정상적인 표시일 수 있다. 중요한 것은 따옴표 안의 실제 문자열이 구글이 제공한 값과 정확히 일치하는지다. 바로 인증되지 않으면 설정을 반복해서 지우기보다 외부 DNS 조회에서 TXT가 공개되고 있는지 먼저 확인한다.
구글 서치콘솔의 도메인 인증은 어려운 기술 작업처럼 보이지만, 핵심은 간단하다. ‘올바른 DNS 관리업체의 루트 도메인에 구글이 준 TXT 문자열을 수정 없이 추가했는가’를 확인하면 된다. 이 한 문장을 기준으로 차례대로 살펴보면 며칠째 막혀 있던 소유권 확인 문제도 대부분 원인을 찾을 수 있다.