유입 늘리기

사이트맵을 냈는데 구글이 안 가져갑니다 — 서치콘솔 '보류 중' 점검 순서

조건부로 쓸만2026-08-07·읽기 9분·글 써봄

서치콘솔에 사이트맵을 제출했는데 상태가 며칠째 보류 중이고 검색에도 안 나온다면, 아래 순서로 확인하면 됩니다. 결론부터 적으면 보류 중은 오류가 아니고, 대부분은 사이트 쪽 결함 몇 가지 중 하나입니다.

점검은 5분이면 끝납니다. 먼저 확인하는 순서를 적고, 그다음에 결함이 하나도 없는데도 안 가져가는 경우에 무엇을 할 수 있는지 적겠습니다. 저는 그 경우에 해당했습니다.

사이트맵 제출 — 서치콘솔 3단계

1. 서치콘솔 → 왼쪽 메뉴 색인 생성 → Sitemaps

2. 새 사이트맵 추가 칸에 sitemap.xml 을 입력합니다. 전체 주소가 아니라 뒷부분만 넣습니다. 도메인은 이미 등록돼 있으니 앞에 붙이면 중복이 됩니다.

3. robots.txt 에도 사이트맵 위치를 적어둡니다. 서치콘솔에 낸 것과 별개로, 크롤러가 처음 들어올 때 여기를 봅니다.

User-agent: *
Allow: /

Sitemap: https://내주소/sitemap.xml

'보류 중'은 오류가 아닙니다

상태값을 오해하면 멀쩡한 걸 계속 고치게 됩니다. 넷만 구분하면 됩니다.

상태	뜻	할 일
`보류 중`	접수됐고 아직 안 읽었다	기다립니다. 며칠은 정상 범위입니다
`가져올 수 없음`	주소를 열지 못했다	아래 1~3단계 점검
`성공`	읽었다	색인은 별개입니다. 아래 '색인은 다른 문제' 참고
`오류 있음`	형식이 잘못됐다	사이트맵 XML 자체를 확인

보류 중이 2주 넘게 이어지면 그때부터는 사이트 쪽을 의심합니다.

안 가져갈 때 점검 순서

1단계. robots.txt 와 sitemap.xml 이 열리는가

가장 흔한 사고가 여기 있습니다. 개발 중에 넣어둔 Disallow: / 가 그대로 배포되는 경우입니다.

curl -s -o /dev/null -w "%{http_code}\n" https://내주소/robots.txt
curl -s -o /dev/null -w "%{http_code}\n" https://내주소/sitemap.xml
curl -s https://내주소/robots.txt | head -3

robots.txt 와 sitemap.xml 이 200 으로 열리는지 확인한 터미널 화면

둘 다 200 이어야 하고, robots.txt 안에 Disallow: / 가 없어야 합니다.

여기서 403 이 나온다면 사이트가 아니라 앞단 방화벽이 막는 것일 수 있습니다. 브라우저로는 열리는데 명령줄에서만 막히면 그렇습니다. 요청에 붙는 프로그램 이름표(User-Agent)를 명시해서 다시 확인해 보세요.

2단계. 사이트맵 안 주소가 전부 200 인가

사이트맵에 적어둔 주소 중 301·404 가 섞여 있으면 검색엔진이 그 사이트맵을 신뢰하지 않습니다. 한 줄씩 확인해야 합니다. 눈으로 보기엔 멀쩡한데 슬래시 하나 차이로 리다이렉트되는 경우가 많습니다.

이 스크립트를 하나 만들어두면 배포할 때마다 씁니다.

#!/bin/bash
# 사용: bash checkmap.sh https://내주소
UA="Mozilla/5.0 (sitemap-check)"
SITE="${1%/}"
curl -s -A "$UA" "$SITE/sitemap.xml" | grep -oP '(?<=<loc>)[^<]+' | while read -r u; do
  printf "%-38s %s\n" "${u#$SITE}" "$(curl -s -A "$UA" -o /dev/null -w '%{http_code}' "$u")"
done

사이트맵 안 주소를 한 줄씩 확인해 전부 200 이 나온 터미널 화면

전부 200 이어야 합니다. 하나라도 다르면 그 주소를 사이트맵에서 빼거나 고칩니다.

3단계. noindex 와 canonical

템플릿에 noindex 가 남아 있으면 사이트맵과 무관하게 색인되지 않습니다. 개발 환경에서 넣고 지우지 않은 경우가 대부분입니다.

canonical 도 같이 봅니다. 다른 주소를 가리키고 있으면 검색엔진은 그쪽을 대표 주소로 삼고 이 페이지는 버립니다.

robots 메타태그가 없고 canonical 이 자기 주소를 가리키는 것을 확인한 터미널 화면

robots 메타태그가 아예 없는 것이 정상입니다. 없으면 색인 허용입니다.

4단계. 사이트맵 형식

확인할 것	기준
주소 형식	절대경로(`https://` 부터). 상대경로는 무시됩니다
`lastmod`	`YYYY-MM-DD` 또는 W3C 날짜 형식
도메인	서치콘솔에 등록한 것과 정확히 같아야 합니다 (`www` 유무 포함)
개수	5만 개·50MB 를 넘으면 나눠야 합니다

결함이 없는데도 안 가져갈 때

여기부터가 제 경우였습니다. 위 4단계를 전부 확인했고 결함이 하나도 없었는데 사이트맵을 읽어가지 않았습니다.

이때 남는 원인 후보는 사이트 밖에 있습니다.

후보	왜 그럴 수 있나
새로 만든 도메인	검색엔진이 신뢰를 쌓기 전입니다. 크롤링 예산 자체가 적게 배정됩니다
무료 공용 서브도메인	같은 도메인을 여러 사람이 나눠 씁니다. 남이 먼저 쌓은 이력이 영향을 줄 수 있습니다
콘텐츠가 적음	가져갈 것이 적으면 다시 올 이유도 적습니다

저는 첫 두 개 중 어느 쪽인지 확인하지 못했습니다. 구분하려면 같은 내용을 자체 도메인에 올려 같은 기간을 비교해야 하는데, 그건 아직 안 해봤습니다. 도메인 하나를 새로 사서 같은 글을 올리고 몇 주를 기다려야 나오는 답이라 시간이 걸립니다.

세 번째는 제 경우 확실히 해당됐습니다. 글이 거의 없는 상태였습니다. 크롤러 입장에서 보면 지도만 있고 갈 곳이 없는 사이트였던 셈입니다. 이건 사이트맵 문제가 아니라 콘텐츠 문제이고, 고치는 방법도 사이트맵 쪽에는 없습니다.

정리하면 이 상황에서 사이트맵으로 할 수 있는 일은 없었습니다. 점검해서 결함이 안 나왔다면 그 방향은 거기서 끝이고, 아래의 다른 수단으로 넘어가는 편이 낫습니다. 같은 조건에서 결과를 보신 분이 있으면 알려주시면 좋겠습니다.

대신 할 수 있는 것

기다리는 것 말고 할 수 있는 일이 있습니다. 순서대로 효과가 큽니다.

하나. 색인 요청을 직접 넣습니다

서치콘솔 URL 검사 에 주소를 넣고 색인 생성 요청 을 누릅니다. 사람이 눌러야 하고 하루 한도가 있어서 모든 글에 쓰는 용도가 아닙니다.

대문과 대표 글 몇 개
크게 고쳐서 다시 평가받고 싶은 글

이걸로 대문이 먼저 잡히면 나머지가 따라 잡히는 경우가 있습니다.

둘. lastmod 를 정직하게 관리합니다

검색엔진은 lastmod 를 재방문 판단에 쓰는데, 믿을 수 있을 때만 씁니다.

<url>
  <loc>https://내주소/글1/</loc>
  <lastmod>2026-08-07</lastmod>
</url>

빌드할 때마다 전체를 오늘 날짜로 찍으면 그 신호를 통째로 무시하기 시작합니다. 본문이 실제로 바뀐 글만 올립니다. 파일 수정 시각을 그대로 쓰지 말고 본문 해시가 바뀐 경우에만 갱신하는 편이 안전합니다.

셋. 내부 링크를 만듭니다

사이트맵은 지도일 뿐이고, 크롤러는 실제로는 링크를 타고 다닙니다. 지도에 적혀 있어도 걸어갈 길이 없으면 잘 안 갑니다. 대문에서 어느 글이든 두 번 안에 닿을 수 있어야 합니다.

대문에 최근 글 목록을 둡니다
전체 글을 한 장에 모은 페이지를 만듭니다
분류 페이지에서 각 글로 이어지게 합니다
글 안에서 관련 글로 걸어줍니다

정적 사이트라면 빌드할 때 자동으로 만들어지게 해두는 편이 낫습니다. 손으로 관리하면 글이 늘수록 빠지는 데가 생깁니다.

넷. 다른 곳에서 링크가 들어오게 합니다

새 도메인이 신뢰를 얻는 가장 확실한 경로입니다. 검색엔진 입장에서 외부 링크는 "다른 사람도 이 사이트를 인정한다"는 신호입니다.

관련 커뮤니티에 도움이 되는 답변을 남기면서 근거로 걸거나, 자기가 이미 쓰고 있는 다른 채널에서 걸어줍니다. 대량으로 링크를 만들어주는 서비스는 쓰지 않는 편이 안전합니다. 순위를 올리려고 만든 링크는 검색엔진이 걸러내며, 심하면 사이트 전체 평가가 내려갑니다.

다섯. 네이버는 따로 챙깁니다

네이버는 IndexNow 라는 방식으로 색인 요청 자동화를 지원합니다. 글을 올릴 때마다 "이 주소 봐달라"를 자동으로 보낼 수 있습니다.

구글이 안 가져가는 동안 네이버 쪽이라도 먼저 잡히게 해두면, 최소한 한쪽에서는 유입이 생깁니다. 한국어 콘텐츠라면 이쪽 비중이 작지 않습니다.

색인은 다른 문제입니다

사이트맵 상태가 성공 으로 바뀌어도 검색에 안 나올 수 있습니다. 읽어간 것과 색인한 것은 다릅니다.

단계	확인 방법
사이트맵을 읽었나	서치콘솔 → `Sitemaps` 상태
페이지를 크롤링했나	서치콘솔 → `색인 생성` → `페이지`
색인됐나	검색창에 `site:내주소/글1/`
검색에 나오나	서치콘솔 → `실적` 의 노출수

site: 검색에 나오는데 실적에 노출이 없다면 색인은 된 것이고, 그다음은 본문이 할 일입니다.

흔한 오해 셋

이렇게 알기 쉽다	실제
사이트맵을 내면 색인된다	사이트맵은 "여기 있습니다" 까지입니다
`보류 중` 은 오류다	접수 상태입니다. 며칠은 정상입니다
사이트맵만 있으면 링크는 필요없다	크롤러는 링크를 타고 다닙니다

판정 — 조건부로 쓸만

사이트맵은 내야 합니다. 안 내면 시작도 안 되고, 내는 데 5분이면 됩니다. 위 점검 4단계도 한 번 해두면 오래 씁니다.

다만 그것만으로 색인되지는 않습니다. 저는 결함이 하나도 없는 상태에서 며칠째 안 가져가는 경우를 겪었고, 그때 사이트맵으로 할 수 있는 일은 없었습니다. 새 도메인이라면 시간과 내부 링크, 그리고 콘텐츠가 실제 변수입니다.

직접 하실 분께

하나. 점검은 위에서부터 순서대로 합니다. 4단계 형식부터 보면 1단계의 Disallow: / 를 놓칩니다.

둘. 보류 중 을 며칠 만에 판단하지 않습니다. 새 사이트는 2주도 걸립니다. 그동안 사이트맵을 지웠다 다시 내는 건 도움이 되지 않습니다.

셋. 점검 스크립트는 배포할 때마다 돌립니다. 사람이 눈으로 보면 슬래시 하나 차이를 놓칩니다.

다음에는 같은 내용을 자체 도메인에 올려서, 무료 공용 주소가 실제로 영향을 주는지 비교해보려고 합니다. 결과가 나오면 이어서 적겠습니다.

#사이트맵 #서치콘솔 #색인생성 #크롤링