사이트맵 제출 방법 — 오류 메시지별 해결까지

구글 서치콘솔 왼쪽 메뉴에서 색인 생성 > Sitemaps를 열고, 사이트맵 주소를 입력한 뒤 제출 버튼을 누르면 끝난다. 작업 자체는 1분도 걸리지 않는다.

문제는 그 1분 앞뒤다. 내 사이트맵 주소가 무엇인지 모르거나, 제출 후 상태가 '가져올 수 없음'으로 뜨거나, 제출은 됐는데 색인이 늘지 않는다. 아래는 주소 확인 → 제출 → 상태 확인 → 오류 해결 → 네이버 제출 → 제출 후 점검 순서로, 막힌 지점만 골라 읽을 수 있게 정리한 것이다.

사이트맵은 무엇이고 왜 올려야 하나

사이트맵

사이트에 있는 주소 목록을 XML 형식으로 적어 둔 파일. 검색엔진에게 "이 사이트에는 이런 페이지들이 있다"고 알려 주는 안내문이다

사이트맵 인덱스

사이트맵 파일이 여러 개일 때 그 파일들의 주소를 묶어 둔 상위 파일. 서치콘솔에는 이 파일 하나만 제출하면 된다

구글은 사이트맵 제작 및 제출하기 문서에서 사이트맵을 크롤링을 돕는 수단으로 설명한다. 즉 사이트맵은 발견을 돕는 신호이지, 색인이나 순위를 보장하는 장치가 아니다. 이 구분을 처음부터 잡아 두어야 뒤에서 헛된 기대를 하지 않는다.

검색에 글이 나오기까지는 크게 세 단계를 거친다. 구글 크롤러가 주소를 발견하고, 내용을 읽어 색인에 담고, 검색어마다 다른 문서들과 견주어 순위를 매긴다. 사이트맵이 관여하는 구간은 첫 번째뿐이다. 두 번째와 세 번째는 페이지 품질과 사이트 전체의 신뢰도가 좌우한다.

그렇다면 꼭 필요한가. 페이지가 수십 개이고 메뉴에서 모든 글로 이동할 수 있는 사이트라면 사이트맵 없이도 크롤링은 대체로 된다. 다만 아래 경우에는 효과가 분명하다.

• 새로 만든 사이트라 외부에서 들어오는 링크가 거의 없을 때
• 페이지 수가 많고 내부 링크가 얕게 연결돼 있을 때
• 글을 자주 올려 새 주소가 계속 생길 때
• 이미지·동영상처럼 본문 링크만으로는 찾기 어려운 자원이 많을 때

사이트맵은 "이 주소들을 봐 달라"는 요청서다. 요청서를 냈다고 심사가 통과되는 건 아니다. 그래도 요청서가 없으면 심사 대상에 늦게 오른다.

플랫폼별 주소 확인 — 브라우저로 여는 게 가장 빠르다

제출 단계에서 가장 많이 막히는 1차 장벽은 "내 사이트맵 주소가 뭔지 모르겠다"는 것이다. 대부분의 플랫폼은 자동으로 만들어 두고 있으니, 아래 표의 주소를 내 도메인 뒤에 붙여 브라우저 주소창에 그대로 넣어 보면 된다.

좌우로 밀어서 표 전체를 보실 수 있습니다

주소를 열었을 때 XML 목록이나 표 형태의 주소 목록이 보이면 정상이다. 404 페이지가 뜨면 그 경로에는 파일이 없는 것이고, 로그인 화면이 뜨면 공개 접근이 막혀 있는 것이다. 둘 다 그대로 제출하면 오류가 난다.

경로를 못 찾겠다면 순서를 정해 두고 훑는 게 빠르다. ① /sitemap.xml → ② /sitemap_index.xml → ③ /wp-sitemap.xml → ④ /robots.txt 를 차례로 열어 본다. robots.txt 안에 Sitemap 줄이 적혀 있으면 그 주소가 정답이다. 빌더를 쓴다면 관리자 화면의 검색엔진 최적화·검색 노출 설정 항목에 주소가 그대로 표시돼 있는 경우도 많다.

직접 개발한 사이트는 사정이 다르다. 파일이 자동으로 생기지 않으므로 빌드 시 생성 설정을 넣거나, 주소 목록을 XML로 출력하는 경로를 따로 만들어야 한다. 이때 글을 새로 올려도 파일이 갱신되는지를 꼭 확인한다. 배포 시점에 한 번 구워 두고 끝나는 설정이면, 이후 올린 글이 사이트맵에 영영 들어가지 않는다.

확인할 때 주의할 점이 두 가지 있다. 첫째, 로그인한 관리자 계정으로만 열리는 경우가 있으니 시크릿 창에서도 열어 본다. 둘째, 한글이 포함된 주소는 사이트맵 안에서 퍼센트 인코딩으로 적혀 있어야 한다. 한글 그대로 들어가 있으면 일부 도구에서 형식 오류로 읽는다.

규모 감각도 미리 잡아 두면 좋다. 백링크하이 사이트는 2026년 8월 25일 기준으로 사이트맵에 주소 40개가 등록돼 있다. 같은 시점에 발행한 글은 20편, 본문에 쓰는 이미지는 29장, 자주 묻는 질문은 13개다. 소규모 사이트라면 사이트맵 주소가 수십 개 수준인 게 정상이고, 수천 개가 잡힌다면 태그·검색결과 페이지 같은 불필요한 주소가 섞여 있을 가능성이 크다.

구글 서치콘솔 사이트맵 제출 방법

제출에는 선행 조건이 하나 있다. 서치콘솔에 속성이 등록되어 있고 소유권 확인이 끝나 있어야 Sitemaps 메뉴가 열린다. 아직이라면 서치콘솔 속성 등록과 소유권 확인 절차를 먼저 끝내고 돌아오면 된다.

1. 서치콘솔에 접속해 화면 왼쪽 위에서 제출할 속성을 선택한다. 도메인 속성과 URL 접두어 속성 중 어느 쪽인지 확인해 둔다.
2. 왼쪽 메뉴 색인 생성 > Sitemaps를 연다.
3. '새 사이트맵 추가' 입력란에 도메인 뒤 경로만 입력한다. 예를 들어 sitemap_index.xml 또는 wp-sitemap.xml 처럼 적는다.
4. 제출을 누른다.
5. 아래 '제출된 사이트맵' 목록에 줄이 하나 추가되고, 상태 열에 처리 결과가 표시된다.
6. 상태가 '성공'으로 바뀌면 옆의 '발견된 URL' 수를 확인한다. 이 숫자가 내 사이트 페이지 수와 크게 다르면 생성 설정을 다시 본다.
7. 사이트맵 줄을 클릭하면 마지막으로 읽은 날짜와 오류 내역을 볼 수 있다.

처리에는 보통 몇 분에서 하루 이상이 걸린다. 제출 직후 '가져올 수 없음'으로 보이다가 시간이 지나 '성공'으로 바뀌는 경우도 흔하므로, 바로 삭제하고 다시 넣기를 반복하지 않는 편이 낫다. 상태 읽는 법은 구글의 사이트맵 보고서 도움말에 항목별로 정리돼 있다.

속성 종류도 미리 정해 두는 게 좋다. 도메인 속성은 www 유무와 http·https를 모두 한 묶음으로 보고, URL 접두어 속성은 입력한 버전만 본다. 접두어 속성에 https://example.com 을 등록해 두고 사이트맵 안에는 www가 붙은 주소가 들어 있으면, 파일은 정상인데도 '잘못된 URL'로 잡힌다. 어느 쪽이 대표 주소인지 모르겠다면 도메인 속성으로 등록해 두는 편이 사고가 적다.

메뉴 이름은 화면 개편에 따라 바뀔 수 있다. '색인 생성'이 보이지 않으면 좌측 메뉴에서 Sitemaps 또는 사이트맵이라는 단어를 찾으면 된다.

robots.txt에도 한 줄 적어 둔다

서치콘솔 제출과 별개로, robots.txt 파일 안에 사이트맵 위치를 알려 두면 다른 검색엔진도 같은 파일을 찾아간다. 이때 반드시 전체 주소를 적어야 한다.

Sitemap: https://example.com/sitemap.xml → 올바른 표기 Sitemap: /sitemap.xml → 상대경로라 인식되지 않음

이 줄은 robots.txt 어디에 있어도 되고, 사이트맵이 여럿이면 줄을 여러 개 적어도 된다. 작성 규칙은 구글의 robots.txt 소개 문서에 정리돼 있다.

제출 전 자가 점검 체크리스트

오류의 절반은 제출 전에 걸러진다. 아래 네 가지는 눌러 보기 전에 확인한다.

• 시크릿 창에서 사이트맵 전체 주소가 열리는가 (로그인 없이 200으로 응답하는가)
• 파일 안의 주소가 모두 내 속성과 같은 버전인가 (http/https, www 유무)
• 삭제했거나 비공개로 돌린 페이지가 남아 있지 않은가
• 파일 크기가 50MB를 넘거나 주소가 5만 개를 넘지 않는가

파일당 한도는 압축하지 않은 상태로 50MB, 주소 5만 개다. 이를 넘으면 파일을 쪼개고 사이트맵 인덱스로 묶은 뒤, 서치콘솔에는 인덱스 파일 하나만 제출하면 된다. 구글이 인덱스를 열어 하위 파일을 따라가기 때문에 하나씩 넣을 필요가 없다.

인덱스로 묶는 또 하나의 이유는 관리 편의다. 글·상품·이미지처럼 종류별로 파일을 나눠 두면, 나중에 색인이 안 되는 구간이 어느 묶음인지 보고서에서 바로 구분된다. 파일 하나에 전부 몰아넣으면 문제가 생겼을 때 어디서부터 봐야 할지 알기 어렵다.

사이트맵에 넣으면 안 되는 주소

좌우로 밀어서 표 전체를 보실 수 있습니다

대표 주소 문제는 특히 자주 나온다. 구글은 URL 표준화 문서에서 대표 주소 지정의 목적을 검색 결과에 보여줄 URL을 정하는 것과 중복 페이지의 신호를 하나로 합치는 것이라고 설명하고, 지정하지 않으면 구글이 사용자에게 보여 줄 가장 나은 버전을 스스로 판단한다고 밝히고 있다. 지정하지 않으면 어느 주소가 대표가 될지 운영자가 통제할 수 없다는 뜻이다.

여기에 더해 태그 목록, 사이트 내 검색 결과, 페이지 번호가 붙은 목록의 2페이지 이후, 파라미터가 붙은 정렬·필터 주소도 대개 뺀다. 넣는다고 벌점이 있는 건 아니지만, 색인될 가능성이 낮은 주소로 목록을 채우면 발견된 URL 수와 색인 수의 차이만 벌어져 상태를 읽기 어려워진다.

상태 메시지별 원인과 해결

제출 후 뜨는 메시지는 종류가 정해져 있다. 메시지만 보고 원인을 좁히면 대부분 그날 안에 해결된다.

좌우로 밀어서 표 전체를 보실 수 있습니다

입력 실수도 의외로 많다. 입력란에는 이미 내 도메인이 붙어 있는데 전체 주소를 다시 붙여 넣어 https://example.com/https://example.com/sitemap.xml 같은 주소가 만들어지는 경우다. 이러면 어김없이 '가져올 수 없음'이 뜬다.

파싱 오류는 브라우저로 파일을 직접 열면 대개 몇 초 만에 잡힌다. 태그가 닫히지 않았거나 허용되지 않는 문자가 섞여 있으면 브라우저가 몇 번째 줄에서 멈췄는지 알려 준다. 가장 흔한 범인은 파일 첫 줄 앞에 들어간 빈 줄과 공백, 그리고 본문에 섞인 & 기호다. 주소에 쓰이는 & 는 사이트맵 안에서 & 형태로 바꿔 써야 한다.

'가져올 수 없음'이 계속될 때 마지막으로 의심할 곳은 서버다. 보안 플러그인, 호스팅의 봇 차단, CDN의 국가·IP 차단이 구글 크롤러 요청만 막는 경우가 있다. 사람은 열리는데 구글만 못 읽는 상태라, 브라우저 확인만으로는 끝까지 원인을 못 찾는다. 이럴 땐 URL 검사 도구로 사이트맵 주소 자체를 넣어 실제 가져오기 결과를 확인해 보면 된다.

작성 규칙은 두 개만 챙기면 된다

좌우로 밀어서 표 전체를 보실 수 있습니다

changefreq와 priority를 조정하면 크롤링 빈도가 바뀐다는 설명은 오래된 이야기다. 손댈 시간에 lastmod가 거짓말을 하고 있지 않은지 보는 편이 낫다. 모든 페이지의 수정일이 매일 오늘로 바뀌는 사이트맵은 신뢰를 잃는다.

오타 하나 고친 것까지 수정일로 올리는 설정도 같은 문제를 낳는다. lastmod는 본문 내용이 실제로 달라졌을 때만 갱신되게 두는 것이 안전하다.

네이버 서치어드바이저는 따로 올려야 한다

구글에 제출했다고 네이버에 반영되지 않는다. 네이버 서치어드바이저에 사이트를 등록하고 소유권 확인을 마친 뒤, 요청 > 사이트맵 제출 메뉴에서 같은 주소를 넣으면 된다. 이때는 경로만이 아니라 전체 주소를 요구하는 화면이 나오는 경우가 있으니 안내 문구를 그대로 따른다.

네이버에서는 RSS 제출도 함께 해 두는 편이 좋다. 사이트맵이 전체 주소 목록이라면 RSS는 최근 글 목록에 가까워서, 새 글을 빨리 알리는 데 쓰인다. 두 가지를 모두 등록해 두면 역할이 겹치지 않고 보완된다. 워드프레스는 /feed, 티스토리는 /rss 처럼 기본 경로가 정해져 있으니 먼저 열어 확인하면 된다.

등록을 마쳤다면 웹마스터 도구 안의 사이트 진단 항목도 한 번 훑어 두자. 수집 현황과 문서 제외 사유가 함께 표시돼, 사이트맵은 정상인데 개별 글이 빠지는 이유를 구글과 다른 각도에서 확인할 수 있다.

제출했는데 색인이 안 된다면

가장 많이 받는 질문이다. 결론부터 말하면 사이트맵에 올린 주소 수와 실제 색인된 페이지 수는 원래 다르다.

백링크하이가 워드프레스로 사이트를 운영하던 시기의 서치콘솔 '페이지 색인 생성 > 색인이 생성된 페이지' 화면을 보면, 색인된 페이지는 42개였고 화면에 표시된 기간(2026년 5월 30일부터 8월 15일 무렵까지) 내내 42개 안팎에서 거의 평평하게 유지됐다. 색인 수는 사이트에 올린 글 수가 아니라 구글이 실제로 담아 둔 페이지 수다.

그래서 제출 후에는 숫자 두 개를 나눠 봐야 한다. 사이트맵 보고서의 '발견된 URL'은 구글이 내 목록을 읽었다는 뜻이고, 페이지 색인 생성 보고서의 색인 수는 실제로 담긴 수다. 후자가 늘지 않을 때 확인할 것은 다음과 같다.

• 해당 페이지에 noindex나 robots.txt 차단이 걸려 있지 않은가
• 대표 주소가 다른 페이지로 지정돼 있지 않은가
• 내용이 다른 페이지와 거의 같지 않은가
• 어느 메뉴·글에서도 연결되지 않는 고아 페이지가 아닌가

개별 주소는 URL 검사 도구로 상태를 확인하고 색인 생성을 요청할 수 있다. 다만 요청은 우선 검토를 부탁하는 것이지 순번을 사는 것이 아니다. 요청을 반복해서 넣는다고 빨라지지 않는다.

모니터링은 페이지 색인 생성 보고서에서 사이트맵별로 필터를 걸어 보는 방식이 가장 실전적이다. 특정 사이트맵에 속한 주소만 추려서 색인됨과 색인 안 됨을 비교하면, 문제가 글 전체인지 특정 분류인지 금방 드러난다. 색인 안 됨 목록에 붙는 사유 이름도 그대로 단서가 된다. '크롤링됨 - 현재 색인이 생성되지 않음'은 읽었지만 담을 가치를 못 느낀 상태이고, '발견됨 - 현재 색인이 생성되지 않음'은 아직 읽지도 못한 상태라 원인이 전혀 다르다.

백링크하이는 사람이 눈으로 훑는 대신 검사 도구 40종으로 자사 사이트를 반복 점검한다. 깨진 링크, 어디에서도 연결되지 않는 페이지, 구조화 데이터 오류, 글자 대비, 이미지 렌더링, 화면 가로폭, 메뉴 동작, 문의 폼 동작을 항목별로 자동 확인한다. 사람이 하면 빠뜨리고, 빠뜨린 것은 대개 검색 순위에서 먼저 드러나기 때문이다.

사이트맵 재제출과 삭제는 언제 필요한가

글을 올릴 때마다 다시 제출할 필요는 없다. 사이트맵이 자동 생성되는 환경이라면 파일 내용이 갱신되고, 구글은 등록된 주소를 주기적으로 다시 읽는다. 재제출이 실제로 필요한 때는 다음 경우다.

• 사이트맵 파일의 경로 자체가 바뀌었을 때
• 플러그인이나 플랫폼을 교체해 생성 방식이 달라졌을 때
• 도메인이나 프로토콜이 바뀌어 안에 담긴 주소가 전부 달라졌을 때

목록에서 사이트맵을 삭제하면 보고서에서만 사라진다. 이미 색인된 페이지가 즉시 빠지지는 않는다. 페이지를 검색에서 내리고 싶다면 noindex나 삭제 요청 같은 별도 수단을 써야 한다. 쓰지 않는 옛 경로가 목록에 남아 계속 오류를 내고 있다면, 그때는 삭제해 두는 편이 보고서를 읽기 쉽다.

주소 체계를 바꾸는 리뉴얼은 가장 조심할 장면이다. 주소가 바뀌면 기존에 검색에서 쌓은 평가가 끊긴다. 백링크하이는 옛 주소 하나하나에 대응하는 새 주소를 표로 만들어 영구 이전(301)으로 연결하고, 이전이 한 번에 끝나는지, 옛 주소가 404를 내지 않는지를 도구로 전수 확인한다. 자사 사이트를 옮길 때 44건을 이 방식으로 처리했다.

리뉴얼 후 사이트맵에는 새 주소만 넣는다. 옛 주소를 남겨 두면 301 체인을 따라가게 만들어 크롤링만 낭비한다.

이전 순서도 정해 두면 사고가 줄어든다. 301 매핑을 먼저 적용하고, 새 주소만 담긴 사이트맵을 다시 제출한 뒤, 몇 주 동안 서치콘솔에서 옛 주소의 색인 상태가 새 주소로 넘어가는지 지켜본다. 세 가지를 동시에 뒤집으면 어디서 틀어졌는지 알 수 없다.

지금은 쓰지 않는 옛 방법

오래된 블로그 글을 따라 하다 시간을 버리는 경우가 많다. 아래는 현재 기준으로 의미가 없거나 사라진 방법이다.

• 핑(ping) 주소 호출: 사이트맵을 갱신할 때 특정 주소를 호출해 알리던 방식은 지원이 중단됐다. 서치콘솔 제출이나 robots.txt 명시로 충분하다.
• 로그인 없이 URL을 제출하는 공개 양식: 지금은 서치콘솔 속성 안에서만 제출·검사한다.
• changefreq·priority 세밀 조정: 구글이 참고하지 않는다.
• 사이트맵을 여러 검색엔진 등록 사이트에 일괄 제출: 구글·네이버 등 실제 쓰는 검색엔진의 공식 도구에 직접 넣는 것이 정확하다.

자주 묻는 질문

사이트맵이 없으면 검색에 안 나오나요. 아니다. 내부 링크만으로도 크롤링은 된다. 다만 새 사이트나 페이지가 많은 사이트에서는 발견이 늦어질 수 있다.

여러 개를 제출해도 되나요. 된다. 글용·상품용처럼 나눠 제출해도 되고, 인덱스 파일 하나로 묶어도 된다. 보고서에서 나눠 보려면 분리 제출이 편하다.

제출 후 며칠 걸리나요. 상태 확인은 보통 하루 안에 되지만, 색인 여부는 페이지마다 다르다. 며칠에서 몇 주까지 걸릴 수 있고, 모든 주소가 색인되지는 않는다.

글 쓸 때마다 다시 제출해야 하나요. 자동 생성 환경이라면 그럴 필요 없다.

삭제하면 색인에서 빠지나요. 빠지지 않는다. 보고서 목록에서만 사라진다.

읽은 URL 수가 실제보다 적어요. 생성 플러그인의 포함 범위 설정이나 noindex 일괄 적용을 먼저 확인한다.

HTML 사이트맵도 따로 만들어야 하나요. 필수는 아니다. 방문자용 전체 목록 페이지는 내부 링크를 보강하는 효과가 있지만, 검색엔진 제출용은 XML 파일이다.

제출은 시작일 뿐, 그다음이 성과를 만든다

사이트맵을 넣었다고 순위가 오르지는 않는다. 앞서 언급한 워드프레스 운영 시기의 서치콘솔 실적 화면을 보면, 속성 https://backlinkhigh.com 기준 3개월 집계(화면 기준 2026년 5월 26일부터 8월 22일 무렵)는 총 클릭 187, 총 노출 9,640, 평균 CTR 1.9%, 평균 게재순위 16.8이었다. 우리 사이트를 우리가 직접 측정한 값이다.

색인이 되어 노출은 쌓이는데 평균 순위가 두 자릿수에 머문다는 건, 발견 단계는 끝났고 평가 단계가 남았다는 뜻이다. 이 지점부터는 검색 의도에 맞는 콘텐츠, 관련 글끼리 묶는 내부 링크, 그리고 외부에서 들어오는 신뢰 신호가 순위를 움직인다.

기술 쪽을 먼저 정리하고 싶다면 무료 SEO 진단으로 색인·속도·구조 문제를 점검받을 수 있고, 순서를 처음부터 잡고 싶다면 구글 상위노출 7단계 정리를 따라가 보면 된다.

사이트맵 제출까지 끝냈는데 순위가 그대로라면, 발견 다음 단계인 평가를 다루는 구글 상위노출 서비스에서 무엇을 보완해야 할지 확인해 보세요.