색인 0개였던 신규 블로그에서 사이트맵 정리 후 1개 색인된 과정

오후 3시, 멍하니 모니터를 보다가 식은 커피만 들이켰던 날이 있었어요.

작년 가을, 방 한구석에서 koritips.com 도메인을 새로 세팅하고 신나게 자판을 두드렸죠. 제로 웨이스트부터 낚시 게임까지 다양한 주제를 거치며, 이번엔 삶의 팁을 다루는 블로그로 새롭게 문을 열었습니다. 마음이 앞선 나머지 일주일에 무려 40~50개씩 글을 쏟아내듯 올렸습니다.

하지만 며칠이 지나도 구글 검색창에는 온통 고요함뿐이었어요. ‘내 블로그가 영원히 묻히는 건가?’ 진짜 멘붕이었어요.

빠르게 결과를 내고 싶어 다양한 주제를 한꺼번에 다뤘습니다. 지금 돌아보면 신생 사이트에는 좋은 선택이 아니었던 것 같습니다. 주제가 널을 뛰는데 구글이 신뢰해 줄 리 없었죠. 가슴이 답답해지며 손끝이 미세하게 떨리던 기억이 아직도 생생합니다.

먼저 결론부터 정리합니다 (요약)

제목만 보고 “그래서 비결이 뭔데?” 하실 것 같아서 먼저 말씀드립니다. 이 글은 검증된 해법이 아니라, 색인 0개였던 신규 블로그가 1개를 얻기까지의 기록입니다. 무엇이 결정적이었는지는 저도 아직 모릅니다. 대신 무엇을 확인하고 무엇을 바꿨는지는 순서대로 적어 두겠습니다.

1. 문제: 서치콘솔에 ‘발견됨 – 현재 색인이 생성되지 않음’이 쌓이고, 색인된 페이지는 0개였습니다.
2. 확인한 것: 서치콘솔의 사이트맵 목록에서 여러 플러그인이 만든 사이트맵이 겹쳐 있는 것을 발견했습니다. 글 주제도 제각각이었습니다.
3. 조치: 사이트맵을 sitemap_index.xml 하나로 정리해 다시 제출하고, URL 검사에서 색인 생성을 요청했습니다. 글은 한 주제로 모아 천천히 썼습니다.
4. 결과: 색인된 페이지가 0개에서 1개가 되었습니다. 세 가지 조치가 동시에 이뤄져서 어느 쪽 덕분인지는 구분할 수 없습니다.

조급증이 불러온 답답함.

당시에는 원인을 알 수 없었지만, 지금 돌아보면 너무 많은 주제를 한꺼번에 다룬 점도 영향을 줬을 가능성이 있다고 생각합니다.

당시 저는 퇴근 후 밤마다 눈을 충혈해가며 자판을 두드렸습니다. 남들이 말하는 디지털 노마드의 삶이 몹시 부러웠거든요. 하루에 서너 개씩 글을 채워 넣으며 스스로 무척 대견해했습니다.

하지만 정작 글의 주제는 산으로 가고 있었습니다. 환경 보호 실천법을 쓰다가 난데없이 모바일 게임 공략을 적었고, 다음 날엔 요리 레시피를 올렸죠. 구글 검색 로봇 입장에서는 이 블로그의 정체성을 도무지 알 길이 없었을 겁니다.

설마 내가 쓴 정성 어린 글들이 검색 엔진 입장에서는 혼란스럽게 보였을 줄이야. 나중에야 신생 도메인일수록 좁고 깊은 카테고리 하나를 파고들어야 한다고 느끼게 됐습니다. 다만 이건 어디까지나 제 개인 경험에서 나온 생각입니다. 구글이 단일 주제를 색인 조건으로 명시한 적은 없습니다. 첫 단추부터 단단히 잘못 꿰어져 있었던 셈이죠.

위 화면에서는 ‘페이지 색인 생성’ 보고서의 ‘발견됨 – 현재 색인이 생성되지 않음’ 항목과 그 URL 수를 보시면 됩니다.

‘발견됨 – 현재 색인이 생성되지 않음’은 무슨 뜻일까요

저도 처음엔 “오류인가?” 싶었는데, 구글 도움말 설명은 조금 달랐습니다. 구글이 페이지 URL은 찾았지만 아직 크롤링하지 않은 상태이고, 크롤링하면 사이트에 과부하가 걸릴 것으로 예상해 일정을 다시 잡은 것이라고 합니다. 그래서 해당 URL의 ‘마지막 크롤링’ 날짜도 비어 있습니다. 페이지에 명시적인 결함이 있다는 뜻은 아니라는 얘기입니다. 출처는 Search Console 고객센터의 페이지 색인 생성 보고서 도움말입니다.

제 사례에 대 보면 이런 해석이 됩니다. 신규 도메인에 글을 한꺼번에 수백 개 올린 상황이라 크롤링이 뒤로 밀렸을 가능성도 있습니다. 다만 이것도 추측일 뿐 확인할 방법은 없습니다. 같은 상태를 만난 분이 점검해 볼 순서는 이렇게 잡았습니다.

1. 서치콘솔 ‘페이지 색인 생성’ 보고서에서 해당 사유를 눌러 영향받는 URL 목록과 마지막 크롤링 날짜를 확인합니다.
2. URL 검사에서 대표 글 하나를 검사해 ‘라이브 테스트’가 통과하는지 봅니다. robots.txt 차단이나 noindex가 없다는 것을 먼저 확인하려는 것입니다.
3. ‘사이트맵’ 메뉴에서 제출된 사이트맵이 몇 개인지, 상태가 ‘성공’인지 확인합니다.
4. 중요한 글이 맞는지 판단합니다. 구글 도움말도 중요한 페이지라면 시간이 지나며 색인될 수 있다고 안내합니다.

2번의 ‘통과’가 구체적으로 어떤 화면을 말하는지 헷갈릴 수 있어서 따로 적어 둡니다. 라이브 테스트 결과에서는 아래 세 항목을 보시면 됩니다. 정상일 때는 맨 위에 “URL is available to Google”(화면 언어에 따라 한국어로 표시될 수 있습니다)이 나오고, 항목은 다음과 같이 보입니다. 항목 설명은 URL 검사 도구 도움말을 기준으로 정리했습니다.

라이브 테스트 항목	정상일 때	비정상일 때 확인할 곳
Crawl allowed?	Yes	No라면 robots.txt가 구글의 접근을 막고 있다는 뜻입니다. 브라우저에서 도메인 뒤에 /robots.txt를 붙여 열고, 해당 글 주소에 걸리는 Disallow 규칙이 있는지 봅니다. 워드프레스 ‘설정 > 읽기’의 검색 엔진 노출 제한 옵션, SEO 플러그인의 robots.txt 편집 기능, 호스팅 업체의 설정도 함께 의심해 볼 곳입니다(메뉴 이름은 버전에 따라 다를 수 있습니다).
Indexing allowed?	Yes	No라면 페이지가 색인을 막고 있다는 뜻이고, 사유가 같이 표시됩니다. 글 화면에서 페이지 소스 보기를 열어 noindex를 검색해 meta robots 태그가 있는지 보고, SEO 플러그인의 글별 설정에서 ‘검색 결과에 표시’ 옵션이 꺼져 있지 않은지도 확인합니다.
Page fetch	Successful	Failed라면 함께 표시되는 사유를 먼저 읽습니다. 크롤링이 허용되지 않아도 Failed로 표시되므로, 위 Crawl allowed? 값을 먼저 확인하는 편이 빠릅니다.

한 가지 순서가 중요합니다. robots.txt로 막혀 있으면 구글이 페이지를 열어 보지 못하기 때문에, 이때 Indexing allowed?는 항상 Yes로 나옵니다. 페이지 안의 noindex도 읽지 못한 상태라는 뜻이므로, Indexing allowed?가 Yes라고 안심하지 말고 Crawl allowed?를 먼저 보셔야 합니다. noindex 자체는 <meta name="robots" content="noindex"> 태그나 X-Robots-Tag 응답 헤더로 들어가며, robots.txt 안에 적는 noindex는 구글이 지원하지 않습니다(Google Search Central noindex 문서).

차단이나 noindex를 찾아 고쳤다면 같은 글에서 라이브 테스트를 다시 돌려 세 항목이 위 정상값으로 바뀌었는지 확인하고, 그다음에 ‘색인 생성 요청’을 누르는 순서가 맞습니다. 도움말에 따르면 라이브 테스트에서 색인 불가로 나온 페이지는 색인 요청 자체를 보낼 수 없습니다. 고친 뒤 실제로 색인에 반영되기까지는 보통 며칠 걸릴 수 있어서, 같은 URL의 ‘마지막 크롤링’ 날짜가 채워졌는지로 확인하시면 됩니다.

기본을 무시한 채 달리기만 했던 제 자신이 참 바보처럼 느껴졌습니다.

왜 내 글은 구글 눈에 띄지 않았을까?

스스로 꼬아버린 사이트맵 구조가 크롤링에 영향을 줬을 가능성을 의심했습니다.

뒤늦게 구글 서치콘솔을 샅샅이 뒤져보고 경악을 금치 못했습니다. 여러 플러그인이 중복으로 생성한 사이트맵 파일들이 서로 뒤엉켜 있더군요. 다만 중복 사이트맵이 구글 로봇을 가두는 것은 아닙니다. 구글은 사이트맵을 여러 개 제출하는 것을 허용하고, 중복되면 대개 경고 수준에서 끝납니다. 그래서 저는 사이트맵이 직접 원인이라기보다, 정리해서 나쁠 것은 없는 요소로 보고 손을 댔습니다.

이것이 결정적 원인이었는지는 아직 알 수 없습니다. 다만 사이트맵을 정리한 뒤 처음으로 색인이 시작되었습니다.

사이트맵이 겹쳤는지 확인하는 방법

같은 상황인지 보려면 서치콘솔 왼쪽 메뉴의 ‘사이트맵’에서 제출된 사이트맵 목록을 보시면 됩니다. 아래는 겹치기 쉬운 경로의 일반적인 예시입니다. 플러그인과 버전에 따라 경로는 다를 수 있습니다.

사이트맵 URL (예시)	만드는 주체 (일반적인 경우)
/sitemap_index.xml	Yoast SEO, Rank Math 등 SEO 플러그인
/wp-sitemap.xml	워드프레스 기본 기능
/sitemap.xml	별도 사이트맵 플러그인 또는 서버 설정

SEO 플러그인을 두 개 이상 켜 놓았다면 기능이 겹치기 쉽습니다. 플러그인 정리가 궁금하시면 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 기능이 겹치는 플러그인을 걸러내는 기준을 따로 적어 두었습니다.

망설임 없이 기존의 꼬여버린 사이트맵 경로를 전부 삭제했습니다. 오직 sitemap_index.xml 파일 하나만 정교하게 남겨두고 구글에 새로 제출했습니다. 뼈대를 정돈하고 나니 꽉 막혔던 체증이 내려가는 듯했습니다.

정리 순서는 아래처럼 잡으시면 됩니다. 삭제 방법은 플러그인마다 메뉴 이름이 다르니 큰 흐름만 적습니다.

1. 사이트맵을 만드는 플러그인을 하나만 남깁니다. 나머지 플러그인의 사이트맵 기능은 각 플러그인 설정에서 끕니다(메뉴 이름은 버전에 따라 다를 수 있습니다).
2. 브라우저에서 /sitemap_index.xml을 직접 열어 목록이 정상으로 나오는지 확인합니다.
3. 서치콘솔 ‘사이트맵’ 메뉴에서 기존 사이트맵 항목을 눌러 삭제합니다. 이미 꺼 둔 경로는 어차피 접근이 안 되므로 목록에서 지워 두는 편이 헷갈리지 않습니다.
4. ‘새 사이트맵 추가’ 칸에 sitemap_index.xml을 입력하고 제출합니다. 상태가 ‘성공’으로 바뀌는지 확인합니다.

2번과 3번에서 무엇을 정상으로 봐야 하는지 기준을 덧붙입니다. SEO 플러그인이 만든 sitemap_index.xml을 열면 보통 post-sitemap.xml, page-sitemap.xml, category-sitemap.xml처럼 하위 사이트맵 주소가 줄줄이 나열되고 각각 마지막 수정 시각이 붙어 있습니다. 어떤 하위 사이트맵이 나오는지는 플러그인 종류와 설정에 따라 달라질 수 있습니다. 여기서 글 목록에 해당하는 post-sitemap.xml까지 열어 실제 글 주소가 들어 있는지 한 번 더 보시길 권합니다. 목록이 아니라 404 오류나 빈 화면, 일반 HTML 페이지가 뜨면 서치콘솔에 제출해도 읽히지 않습니다. 이때는 플러그인의 사이트맵 기능이 켜져 있는지, 캐시 플러그인이 예전 응답을 붙들고 있지 않은지를 먼저 보시면 됩니다.

꺼 둔 경로(예를 들어 /wp-sitemap.xml이나 /sitemap.xml)도 같은 방식으로 열어 보세요. 404가 나오면 비활성화가 제대로 된 것이고, 서치콘솔 목록에서 지워도 문제가 없습니다. 반대로 여전히 XML 목록이 열린다면 그 경로를 만드는 기능이 아직 살아 있다는 뜻입니다. 일부 플러그인은 꺼 둔 경로를 남길 사이트맵으로 자동 이동시키기도 하는데, 이런 이동 동작은 플러그인과 버전에 따라 다르니 주소창에서 최종 주소가 어디로 바뀌는지 직접 확인하시기 바랍니다.

제출 후 검증은 두 가지만 보면 됩니다. 서치콘솔 ‘사이트맵’ 메뉴에서 sitemap_index.xml의 상태가 ‘성공’인지, 그리고 ‘발견된 페이지’ 수가 실제 발행한 글·페이지 수와 크게 어긋나지 않는지입니다. 수가 적게 잡히면 post-sitemap.xml에 글이 빠진 것은 아닌지, 글이 noindex로 설정돼 사이트맵에서 제외된 것은 아닌지 위 라이브 테스트 표로 돌아가 확인해 보세요.

한 가지 더 알아 두실 점이 있습니다. 구글 문서는 사이트맵 제출이 힌트일 뿐이고 구글이 사이트맵을 다운로드하거나 크롤링한다는 보장은 없다고 설명합니다(Google Search Central 사이트맵 만들기 문서). 사이트맵 하나가 50MB 또는 50,000 URL을 넘지 않는 한 파일을 나눠 쓰는 것도 문제는 아닙니다. 그래서 저는 사이트맵 정리를 “색인을 만들어 주는 마법”이 아니라 “기본 정돈”으로 보고 있습니다.

위 화면에서는 제출된 사이트맵이 sitemap_index.xml 하나뿐인지, 상태가 ‘성공’인지, 발견된 페이지 수가 있는지 보시면 됩니다.

문제의 원인을 똑바로 마주하는 일은 쓰라렸지만, 한편으로는 안도감이 밀려왔습니다.

수동 색인이라는 굴욕의 시간

자동 수집의 끈이 끊어졌다면 결국 작업자의 손끝으로 직접 해결해야 합니다.

구조를 고쳤다고 해서 구글이 곧바로 제 글을 긁어가지는 않았습니다. 일단 제가 할 수 있는 것부터 해보기로 했습니다. 결국 저는 발행한 모든 글의 URL을 일일이 복사하기 시작했습니다.

매일 퇴근하고 마우스를 붙잡고 앉아 주소창에 주소를 밀어 넣었습니다. 하루에 허용된 요청 한계치가 도달할 때까지 수동 색인 요청 버튼을 기계처럼 눌렀습니다. ‘과연 이 짓을 언제까지 반복해야 하나’ 싶어 눈앞이 캄캄해지기도 했어요.

수동 요청 방법은 서치콘솔 상단 검사창에 글 주소를 넣고, 결과 화면의 ‘색인 생성 요청’ 버튼을 누르는 것입니다. 구글 도움말에는 속성별로 하루에 보낼 수 있는 요청 수에 한도가 있다고만 나와 있고, 정확한 숫자는 공개돼 있지 않습니다. 요청해도 보통 하루 정도, 길게는 그보다 오래 걸릴 수 있고 색인이 보장되지는 않는다고 합니다(URL 검사 도구 도움말). 많은 페이지는 사이트맵 제출을 권장한다는 점도 같은 문서에 있습니다. 그래서 제 경우를 돌아보면 수동 요청은 효과보다 심리적 위안이 컸을 수도 있습니다.

마우스 휠을 내릴 때마다 들리는 딸깍 소리가 밤공기를 채우던 그 고독한 순간들. 조급하게 욕심부렸던 과거의 나를 탓하며 묵묵히 어떻게 하면 구독자에게 도움이 되는 글을 쓸 수 있을지를 고민했습니다.

위 화면에서는 URL 검사 결과의 ‘색인 생성 요청’ 버튼과 요청 접수 메시지를 보시면 됩니다.

지름길을 찾으려다 오히려 가장 먼 길을 돌아가는 기분이 썩 유쾌하진 않았습니다.

몇 달간 멈춰 있던 그래프가 처음 움직인 날

몇 달 동안 반응이 없던 서치콘솔에 작은 변화가 나타나기 시작했습니다.

수동 색인 작업을 병행하면서 글을 쓰는 패턴도 완전히 바꿨습니다. 무작정 쏟아내던 양치기식 포스팅을 즉시 멈추었습니다. 대신 3~4일에 단 하나의 글을 쓰더라도 깊이 있고 유용한 정보만 담았습니다.

주제 역시 다른 곳으로 눈돌리지 않고 오직 삶의 노하우와 정보라는 하나의 카테고리에만 집중했습니다. 글의 밀도가 높아지자 신기하게도 서치콘솔에 변화의 바람이 불기 시작했죠.

오늘 아침, 늘 그렇듯 떨리는 마음으로 서치콘솔 화면을 켰습니다. 그토록 갈망하던 초록색 완료 불빛이 그래프를 보는 순간 이게 뭐라고 눈물이 나올뻔한 순간이었습니다.

위 화면에서는 ‘색인 생성됨’ 그래프의 선이 0에서 올라갔는지, 아래 ‘색인이 생성되지 않은 이유’ 표의 항목 수가 어떻게 달라졌는지 보시면 됩니다.

이 화면을 보는데 그동안의 고생이 눈 녹듯 사라지며 한 우물만 파자라는 결심이…

사실 거창한 결과는 아닙니다. 2025년 12월 이후 색인된 페이지 수는 0개였습니다. 이번 작업 이후 처음으로 1개의 페이지가 정상 색인되었습니다. 숫자만 보면 초라해 보일 수 있습니다. 하지만 0과 1 사이에는 생각보다 큰 차이가 있었습니다. 적어도 이제는 구글이 제 사이트를 다시 읽기 시작했다는 신호였으니까요.

위 화면은 색인된 글이 실제로 검색에 잡히는지 확인한 것입니다. 이 화면에서는 검색 결과에 해당 글의 제목과 주소가 나타나는지 보시면 됩니다.

아직 색인된 페이지는 단 1개뿐입니다. 하지만 몇 달 동안 멈춰 있던 그래프가 처음 움직였다는 사실만으로도 충분했습니다. 오늘도 저는 다음 숫자 하나를 기다리며 글을 씁니다.

색인됐는지 확인하는 세 가지 방법

1. 페이지 색인 생성 보고서: ‘색인 생성됨’ 숫자와 ‘색인이 생성되지 않은 이유’ 표를 봅니다. 전체 추이를 볼 때 좋습니다.
2. URL 검사: 글 하나씩 ‘Google에 등록됨’인지 봅니다. 이 보고서는 개별 URL 검색을 지원하지 않아서 필요한 방법입니다.
3. site: 검색: 구글 검색창에 site:koritips.com 처럼 입력해 결과에 글이 나오는지 봅니다. 가장 빠르지만 대략적인 확인용입니다.

무엇이 효과였는지 가설별로 나눠 보면

세 가지를 거의 동시에 했기 때문에 저는 어느 쪽 덕분인지 분리하지 못했습니다. 그래서 조치별로 확인할 수 있는 근거와 한계를 표로 정리해 봤습니다. 아래 날짜와 건수는 기록 양식을 보여 드리려고 넣은 예시 값이며, 실제 측정 결과가 아닙니다.

조치 (예시)	날짜 (예시)	상태 변화 (예시)	해석의 한계
중복 사이트맵 정리, sitemap_index.xml 제출	예: 10월 첫째 주 월요일	사이트맵 상태 ‘성공’, 발견된 페이지 수 표시	구글은 사이트맵 제출이 크롤링을 보장하지 않는다고 설명
URL 검사로 색인 생성 요청	예: 사이트맵 제출 다음 날부터 약 2주간, 하루 10건 안팎	요청 직후 변화 없음	도움말상 보통 하루 정도, 더 걸릴 수 있음
단일 주제로 집중, 발행 빈도 축소	작업과 병행	색인 0개에서 1개	구글이 조건으로 명시한 사항이 아니라 개인 경험

색인 수는 앞으로도 기록해서 이 글에 덧붙일 생각입니다. 비슷한 신규 사이트를 운영하시는 분들이 비교할 수 있도록 형식은 아래처럼 잡아 두었습니다(예시 값입니다). 같은 요일, 같은 보고서 화면에서 확인해야 숫자를 비교할 수 있습니다.

확인일 (예시)	색인 생성됨 (예시)	발견됨 – 현재 색인 생성 안 됨 (예시)	메모
1주차 (예: 10월 둘째 주 월요일)	1	예: 120	색인된 첫 글 확인
4주차 (예: 11월 첫째 주 월요일)	3	예: 118	신규 글 발행 후 변화 관찰

이 글은 제 사례를 기록하는 글이라, 사이트맵 설정이나 색인 점검 절차는 꼭 필요한 만큼만 적었습니다. 플러그인이 겹치는지 가려내는 기준은 아래 링크한 글에서 따로 다룹니다.

이 글의 공식 문서 설명은 2026년 10월 기준으로 다시 확인한 내용입니다. 서치콘솔 메뉴 이름은 계정 언어와 업데이트에 따라 달라질 수 있습니다.

함께 보면 좋은 글

• 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것