7장. 블로그 도메인과 검색 등록 기본, 초보자가 꼭 알아야 할 설정 흐름
새 블로그의 검색 등록은 대표 주소를 하나로 정하고, 공개 접속을 확인한 뒤, Search Console에 소유권을 확인하고 사이트맵을 제출하는 순서로 진행하면 됩니다. 등록은 검색 노출이나 애드센스 승인을 보장하지 않습니다. 다만 검색엔진이 정상 URL을 발견하고 문제를 보고할 통로를 만들어 줍니다.
지금 블로그 주소를 브라우저에서 열어 최종적으로 표시되는 https 주소를 적어 보세요. 그 주소와 사이트맵이 정상이라면 아래 등록 절차로 넘어가고, http·www 유무가 뒤섞이거나 로그인 없이는 글이 열리지 않는다면 검색 도구보다 주소와 공개 설정부터 고쳐야 합니다.
처음 30분에 할 일
- 대표 URL과 실제 도착 URL이 같은지 확인합니다.
- 사이트맵·RSS·robots.txt 주소를 각각 직접 열어 봅니다.
- Google Search Console 속성을 추가하고 사이트맵을 제출합니다.
- 중요 글 한 편을 URL 검사하되, 결과가 늦다고 반복 요청하지 않습니다.
주소를 먼저 고정해야 등록 데이터가 갈라지지 않습니다
도메인은 단순한 이름이 아니라 모든 글 주소의 공통 뿌리입니다. 플랫폼이 주는 주소를 그대로 써도 검색 등록은 가능합니다. 독립 도메인이 검색 순위를 자동으로 올리는 것도 아닙니다. 차이는 장기 통제권입니다. 플랫폼 주소는 비용과 설정 부담이 적고, 독립 도메인은 플랫폼을 바꿀 때 같은 이름을 이어 갈 여지가 큽니다.
| 선택 | 적합한 상황 | 감수할 점 |
|---|---|---|
| 플랫폼 기본 주소 | 주제와 글쓰기 방식을 시험하는 단계 | 이전 시 주소를 그대로 가져가기 어려울 수 있음 |
| 독립 도메인 | 한 주제로 오래 운영할 계획이 분명한 단계 | 갱신 비용, DNS, HTTPS, 리디렉션 관리가 필요함 |
| 하위 도메인 | 서비스나 주제가 실제로 분리되고 운영 책임도 나뉘는 경우 | 속성·분석·콘텐츠 관리가 복잡해짐 |
초보자가 가장 자주 놓치는 것은 주소 문자열의 일치입니다. http 주소를 입력했는데 실제로는 https로 이동하거나, 루트 도메인을 입력했는데 www 주소로 끝날 수 있습니다. 검색엔진은 리디렉션을 이해할 수 있지만, 내부링크·사이트맵·소유권 등록이 제각각이면 문제를 추적하기 어려워집니다. 브라우저 주소창에 최종 표시되는 주소를 기준으로 내부링크와 제출 주소를 맞추세요.
이미 글이 많은데 도메인을 바꾸려는 경우
기존 유입이 있는 사이트라면 새 도메인을 연결하는 일을 단순 설정 변경으로 보면 안 됩니다. 기존 URL에서 대응하는 새 URL로 영구 리디렉션하고, 내부링크·사이트맵·대표 URL 신호를 함께 바꿔야 합니다. Google은 사이트 이동 시 URL 매핑과 영구 리디렉션, 새 사이트맵 제출 등을 안내합니다. 이동 전에 Google 검색 센터의 URL 변경 사이트 이동 안내를 기준으로 이전표를 만드세요.
반대로 글이 몇 편뿐이고 검색 유입도 거의 없다면 초기에 주소를 정리하는 편이 부담이 작습니다. 중요한 판단은 “독립 도메인이 더 좋아 보이는가”가 아니라 “기존 URL을 안전하게 연결하고 계속 갱신할 수 있는가”입니다.
도메인 유지 실패는 검색 도구 밖에서 복구합니다
도메인 만료, 결제수단 오류, 네임서버 교체 누락이 생기면 사이트맵 재제출보다 등록기관 계정과 DNS부터 복구해야 합니다. 갱신일·등록자 이메일·자동 갱신 결제수단·현재 네임서버를 한 표에 두고 만료 알림을 운영자 외 복구 연락처에도 보냅니다. DNS를 바꾸기 전에는 기존 레코드를 내보내고 웹·소유권 확인·메일 레코드를 구분하세요. 웹 주소만 살아나도 문의 메일이나 도메인 속성 확인은 계속 실패할 수 있기 때문입니다.
독립 도메인의 운영비에는 연간 갱신료뿐 아니라 인증서, DNS 장애 확인, 이전 리디렉션 유지 시간이 포함됩니다. 이 비용과 책임이 부담스럽다면 플랫폼 기본 주소가 잘못된 선택은 아닙니다. 다만 어느 쪽이든 관리자 계정을 잃었을 때의 복구 경로와 최종 URL 목록은 플랫폼 밖에 남겨야 합니다.
사이트맵·RSS·robots.txt는 서로 하는 일이 다릅니다
사이트맵은 검색엔진에 제공하는 URL 목록입니다. RSS는 최근 게시물의 갱신 흐름을 전달하는 피드이고, robots.txt는 크롤러가 접근할 수 있는 영역을 안내합니다. 셋 중 하나가 나머지를 대신하지 않습니다. 사이트맵을 제출해도 색인이 보장되지 않으며, robots.txt에서 접근을 허용해도 페이지 품질이나 대표 URL 문제가 자동으로 해결되지는 않습니다.
Google의 사이트맵 안내도 사이트맵을 페이지 발견을 돕는 힌트로 설명하며, 제출된 모든 항목의 크롤링이나 색인을 보장하지 않는다고 밝힙니다. 따라서 “제출 성공”은 작업 완료가 아니라 파일을 읽을 수 있다는 첫 신호로 해석해야 합니다.
사이트맵에 넣을 주소의 기준
검색 결과에 남기고 싶은 대표 URL만 넣고, 각 URL이 로그인 없이 200 응답으로 열리며 색인을 허용하는지 별도로 확인합니다. 리디렉션 전 주소, 미리보기 주소, 검색·필터 결과, noindex 페이지를 목록 수를 늘리려고 넣지 않습니다. XML 안의 주소는 완전한 절대 URL이어야 하고 대표 프로토콜·호스트와 일치해야 합니다.
주소를 추측하지 말고 직접 열어 확인합니다
플랫폼마다 사이트맵과 피드 경로가 다릅니다. 워드프레스는 기본 사이트맵이나 플러그인 사이트맵을 쓸 수 있고, Blogger는 사이트맵과 피드 주소가 별도로 제공됩니다. 인터넷에서 본 경로를 그대로 복사하기보다 플랫폼 도움말과 실제 응답을 확인하세요.
- 로그아웃하거나 시크릿 창에서 대표 글이 열리는지 봅니다.
- 사이트맵 주소를 열어 XML 또는 사이트맵 목록이 나오는지 확인합니다.
- RSS 주소를 열어 최근 공개 글의 제목과 링크가 보이는지 확인합니다.
- robots.txt를 열어 사이트 전체를 막는 규칙이 있는지 확인합니다.
- 피드 속 링크가 http인지 https인지, www 유무가 대표 주소와 같은지 비교합니다.
예를 들어 사이트는 https://www.example.com으로 열리는데 RSS 안의 링크가 http://example.com으로만 적혀 있다면 서치어드바이저에서 주소 불일치가 나타날 수 있습니다. 이때 RSS를 여러 번 제출하기보다 플랫폼의 HTTPS·리디렉션·맞춤 도메인 설정을 먼저 확인해야 합니다.
Search Console 속성은 운영 범위에 맞춰 고릅니다
Search Console에는 도메인 속성과 URL 접두어 속성이 있습니다. Search Console 속성 추가 도움말에 따르면 도메인 속성은 하위 도메인과 프로토콜을 포함한 도메인 전체 데이터를 묶고 DNS 확인을 사용합니다. URL 접두어 속성은 입력한 프로토콜과 경로 범위만 포함하며 여러 확인 방식을 쓸 수 있습니다.
- 독립 도메인 전체를 오래 운영한다면: DNS를 관리할 수 있을 때 도메인 속성이 편합니다.
- 특정 플랫폼 주소나 특정 경로만 볼 때: URL 접두어 속성이 이해하기 쉽습니다.
- www와 비www가 헷갈릴 때: 도메인 속성으로 전체를 보되 실제 대표 URL 정리는 별도로 해야 합니다.
소유권 확인이 끝나면 사이트맵 메뉴에서 실제 사이트맵 경로를 제출합니다. 그다음 URL 검사에서 대표 글 한 편을 확인하세요. URL 검사는 Google이 알고 있는 상태와 실시간 테스트 결과를 나눠 보여 줍니다. 실시간 테스트가 통과해도 색인 등록을 약속하는 것은 아니므로, 매 글마다 반복 요청하는 운영은 피하는 편이 좋습니다.
색인된 버전은 Google이 과거에 가져가 저장한 상태이고, 실시간 테스트는 현재 Googlebot이 접근할 수 있는지를 확인하는 별도 시점의 검사입니다. 오늘 noindex를 제거해 실시간 테스트가 통과해도 저장된 버전은 다음 크롤링과 처리 전까지 예전 상태일 수 있습니다. 반대로 실시간 테스트의 일시 장애가 이미 색인된 버전을 즉시 지운다고 단정할 수도 없습니다. 두 화면의 검사 시각과 최종 URL을 함께 기록하세요.
색인 요청보다 먼저 볼 네 가지
요청 버튼을 누르기 전에 페이지가 200 응답으로 열리는지, noindex가 없는지, robots.txt가 막지 않는지, 다른 글에서 내부링크가 연결되는지 봅니다. 이 네 조건이 틀린 상태에서는 요청 횟수를 늘려도 원인이 사라지지 않습니다. 글 제목과 본문도 확인하세요. 같은 설명을 주소만 바꿔 여러 번 발행했거나 검색자가 얻을 답이 거의 없다면 기술 설정만으로 해결하기 어렵습니다.
네이버와 Bing은 별도 창구로 등록합니다
Google 등록이 다른 검색엔진 등록을 대신하지는 않습니다. 국내 검색 유입을 확인하려면 네이버 서치어드바이저 공식 가이드를 따라 사이트 소유 확인, 수집·색인 가능 상태, 사이트맵과 RSS를 점검하세요. 메뉴나 지원 범위는 바뀔 수 있으므로 블로그 강의 화면보다 현재 공식 가이드를 우선해야 합니다.
Bing Webmaster Tools도 사이트 추가와 검색 성과 확인 기능을 제공합니다. Search Console에서 정보를 가져오는 선택지가 표시되면 이용할 수 있지만, 가져오기가 성공했는지와 사이트맵 상태는 Bing 화면에서 다시 확인하세요.
세 엔진을 등록했다고 방문자가 즉시 늘지는 않습니다. 등록의 실용적인 가치는 엔진별 발견 상태와 실제 검색어를 비교할 수 있다는 데 있습니다. Google이 느려도 다른 엔진에서 먼저 발견될 수 있고, 반대 상황도 생깁니다. 어느 한 화면만 보고 사이트 전체가 실패했다고 단정하지 마세요.
색인 상태 문구를 다음 행동으로 번역합니다
| 보이는 상태 | 먼저 확인할 것 | 다음 행동 |
|---|---|---|
| 발견됐지만 미색인 | 사이트맵, 내부링크, 서버 접근 | 중요 페이지 연결을 보강하고 시간을 두고 관찰 |
| 크롤링됐지만 미색인 | 중복성, 답변 충분성, 대표 URL | 같은 의도의 글을 통합하고 고유한 답을 보강 |
| 리디렉션 페이지 | 의도한 최종 주소로 이동하는지 | 정상 이동이면 원본 URL 자체의 색인을 기대하지 않음 |
| robots 또는 noindex 제외 | 의도한 비공개·중복 페이지인지 | 중요 글이면 차단 원인을 수정, 불필요 페이지면 유지 |
| 서버 오류 | 실제 접속, 호스팅 로그, 일시 장애 | 기술 문제를 먼저 복구한 뒤 재검사 |
‘제외됨’ 숫자를 0으로 만드는 것이 목표는 아닙니다. 로그인 페이지, 중복 피드, 리디렉션 전 주소처럼 검색 결과에 남길 필요가 없는 URL도 있습니다. 반면 핵심 본문이 noindex 처리됐거나 전체 사이트가 차단됐다면 즉시 고쳐야 합니다. 숫자의 크기보다 어떤 URL이 어떤 이유로 빠졌는지를 보세요.
발견에서 노출까지는 서로 다른 문을 통과합니다
- 발견: 사이트맵이나 내부링크에서 URL을 알게 됩니다.
- 크롤링: 서버 응답과 robots 규칙을 확인하며 내용을 가져옵니다.
- 렌더링·해석: 최종 콘텐츠, 대표 URL, 차단 신호를 판단합니다.
- 색인: 검색 후보로 저장할 가치와 중복 관계를 처리합니다.
- 노출: 실제 질의·위치·기기 맥락에서 결과 후보가 됩니다.
사이트맵 성공은 첫 문을 돕는 신호이고 라이브 테스트 성공은 현재 접근 가능성에 가깝습니다. 색인됐지만 노출이 없을 수 있고 노출됐지만 원하는 검색어 순위가 낮을 수도 있습니다. 어느 단계가 막혔는지 정해야 사이트맵 재제출, 기술 수정, 콘텐츠 통합, 제목 개선 중 맞는 행동을 고를 수 있습니다.
장애를 고친 뒤에는 즉시 정상 URL 수만 세지 말고 같은 표본의 검사 시각과 응답을 남깁니다. 전체 차단·서버 오류처럼 독자 접근을 막는 문제는 먼저 복구하고, 일부 중복 URL 제외는 의도한 대표 URL이 색인되는지 확인한 뒤 관찰합니다. 수정하지 않은 URL까지 일괄 ‘유효성 검사’하면 어떤 조치가 효과가 있었는지 흐려집니다. 재검토가 진행되는 동안에는 같은 설정을 반복 변경하지 말고, 새 오류가 핵심 URL로 번지는지만 확인하세요.
가상 사례로 점검 순서를 따라가 봅니다
이해를 돕기 위한 가상 사례입니다. 독립 도메인을 Blogger에 연결한 뒤 글 12편을 발행했는데 Search Console에는 일부 URL만 보인다고 가정하겠습니다. 운영자는 먼저 새 글 12편을 모두 반복 요청하는 대신 대표 주소, HTTPS 리디렉션, 사이트맵 응답을 확인합니다.
사이트맵에는 12편이 모두 있고 중요 글은 로그인 없이 열리지만, 새 글 4편은 어떤 글에서도 연결되지 않았습니다. 이 경우 관련 글 본문과 카테고리 탐색에서 자연스럽게 연결합니다. 또 두 글이 제목만 다르고 답이 거의 같다면 하나로 통합합니다. 며칠 뒤 같은 조건으로 다시 확인하되, 색인 개수만 보지 않고 노출 검색어가 생기는지도 봅니다.
반대로 사이트맵이 404를 내거나 대표 주소와 다른 프로토콜을 내보낸다면 콘텐츠 수정 전에 설정을 바로잡습니다. 이 분기가 중요합니다. 기술 문제와 콘텐츠 발견 문제를 섞으면 무엇을 고쳐야 했는지 알 수 없습니다.
등록 완료표보다 운영 기록이 더 오래 쓰입니다
메모에는 대표 URL, 속성 종류, 소유 확인 방식, 사이트맵·RSS 주소, 제출일, 마지막 확인일만 적어도 충분합니다. 도메인 갱신일과 DNS 관리 계정도 함께 남기세요. 비밀번호 자체를 문서에 적기보다 안전한 비밀번호 관리 도구를 쓰고, 복구 이메일과 2단계 인증 상태를 확인하는 편이 좋습니다.
- 주소가 바뀌면 Search Console만 고치지 말고 내부링크와 피드도 확인합니다.
- 테마를 교체하면 소유 확인 메타태그가 사라지지 않았는지 봅니다.
- 새 글이 미색인이면 요청 전에 공개·차단·내부링크·중복을 차례로 봅니다.
- 한 달 단위로 엔진별 노출 검색어와 중요 페이지 상태를 기록합니다.
오늘 끝낼 수 있는 마지막 분기
소유권 확인이 실패하면 인증 방식보다 공개 화면을 봅니다
URL 접두어 속성에서 HTML 메타태그를 사용했는데 확인되지 않는다면 태그를 다시 복사하기 전에 실제 페이지 소스를 확인하세요. 테마 편집기에 저장했어도 캐시가 이전 화면을 보여 주거나, 태그를 본문 한 편에만 넣었거나, 테마 교체 과정에서 사라졌을 수 있습니다. 메타태그는 사이트의 지정된 상단 영역에 남아 있어야 하며 확인 후에도 지우지 않는 편이 안전합니다.
DNS 확인은 레코드 이름과 값, 등록한 도메인 범위를 비교합니다. DNS 변경은 화면에 즉시 반영되지 않을 수 있으므로 같은 값을 여러 번 추가하지 말고 등록기관에서 저장된 레코드를 확인한 뒤 기다립니다. 다른 사람이 도메인을 관리한다면 값 전체를 안전하게 전달하고, 확인 완료 후 누가 DNS를 유지할지 기록하세요.
확인용 TXT 레코드는 소유권 확인이 끝났다고 바로 지우지 마세요. 등록기관, 레코드 이름·값, 추가일, 담당자를 운영 기록에 남기고 DNS 이전이나 네임서버 교체 때 함께 옮깁니다. 도메인 속성은 DNS 범위 전체를 확인하므로 이 레코드를 잃으면 향후 소유권 재확인이 필요할 수 있습니다.
사이트맵 성공인데 새 글이 빠지면 생성 주기를 확인합니다
사이트맵 파일이 정상으로 읽혔다는 사실과 최신 게시물이 파일에 들어 있다는 사실은 다릅니다. 새 글 URL을 사이트맵에서 직접 찾아보고, 없다면 플랫폼 생성 시점·캐시·공개 상태를 확인합니다. 임시 미리보기 주소나 검색 결과 페이지를 사이트맵에 억지로 추가하지 마세요. 독자가 방문해야 할 대표 본문 URL만 일관되게 관리하는 편이 좋습니다.
여러 사이트맵을 쓰는 대형 사이트가 아니라면 제출 개수를 늘리는 것이 목적이 아닙니다. 같은 URL이 RSS와 사이트맵에서 모두 발견되는 것은 이상이 아니며, 두 경로가 서로 다른 대표 주소를 가리키는지가 더 중요합니다.
리디렉션과 대표 URL은 브라우저 한 번으로 끝나지 않습니다
루트 주소, www 주소, http 주소, 개별 글 주소를 각각 열어 최종 도착지를 봅니다. 한 번만 이동하는지, 중간에 존재하지 않는 주소를 거치지 않는지, 모바일에서도 같은 결과인지 확인하세요. 내부링크가 오래된 주소를 계속 가리키면 방문자는 이동할 수 있어도 크롤러가 불필요한 단계를 반복합니다. 새 글부터 대표 주소로 연결하고, 오래된 핵심 글의 내부링크를 우선 갱신합니다.
색인과 노출, 순위를 서로 다른 단계로 봅니다
URL이 색인됐다는 것은 검색 시스템이 페이지를 저장하고 검색 결과 후보로 다룰 수 있다는 뜻이지, 원하는 검색어의 상단에 보인다는 뜻은 아닙니다. 노출이 0이라면 검색 수요와 의도, 제목, 사이트 내 연결을 확인합니다. 노출은 있는데 클릭이 적다면 검색어와 제목의 약속, 결과 화면의 경쟁 답변을 비교합니다. 클릭은 있는데 독자가 바로 나간다면 첫 화면이 질문에 답하는지와 모바일 가독성을 봅니다.
이 단계를 구분하면 사이트맵을 다시 제출해 해결할 문제와 본문을 고쳐야 할 문제를 섞지 않게 됩니다. 등록 도구는 콘텐츠 판단을 대신하지 않고, 콘텐츠 품질도 전체 차단 같은 기술 오류를 대신하지 않습니다.
한 달 점검은 모든 URL이 아니라 중요 URL 표본으로 합니다
글이 늘면 매번 전 페이지를 수동 검사할 수 없습니다. 홈페이지, 핵심 허브, 최근 발행 글, 유입이 큰 글, 최근 수정 글을 표본으로 정하세요. 각 표본에서 최종 URL, 색인 상태, 사이트맵 포함, 내부링크, 마지막 내용 검증일을 봅니다. 갑작스러운 변화가 발견되면 그때 같은 유형의 페이지로 범위를 넓힙니다.
검색어 자료가 쌓이면 의도하지 않은 표현으로 노출되는 글도 찾을 수 있습니다. 본문에 실제 답이 있다면 제목과 소제목을 더 선명하게 다듬고, 답이 없다면 억지로 키워드를 추가하지 말고 별도 질문으로 다룰 가치가 있는지 판단하세요.
사이트가 아직 없다면 도메인 구매부터 서두르지 말고 플랫폼 기본 주소로 주제와 발행 흐름을 시험해도 됩니다. 사이트는 있지만 등록하지 않았다면 대표 URL을 고정하고 Search Console·네이버·Bing의 소유 확인과 사이트맵 제출을 진행하세요. 등록했는데 글이 안 보인다면 주소 접근, 차단, 사이트맵, 내부링크, 중복성 순으로 진단하세요.
검색 등록은 한 번 누르고 잊는 출생신고도, 매일 오류를 새로고침하는 의식도 아닙니다. 발견 경로를 열고 문제가 생겼을 때 원인을 좁히는 계기판입니다. 오늘은 대표 글 한 편을 URL 검사하고, 그 글로 들어오는 내부링크 한 개와 사이트맵 포함 여부를 확인하는 데서 마무리해도 충분합니다.