사이트맵(sitemap.xml)이란? 만드는 법 총정리

사이트맵(sitemap.xml)은 "우리 사이트에 이런 페이지들이 있다"고 검색엔진에 알려주는 목록 파일이다. 특별히 어려운 기술이 아니라, 페이지 주소를 한 줄씩 나열한 간단한 XML 문서다.

결론부터 말하면 이렇다. 사이트맵을 만들고 구글 서치 콘솔에 제출하면, 구글이 내 사이트의 페이지를 더 빠르고 빠짐없이 찾아낼 확률이 올라간다. 필수는 아니지만, 안 할 이유가 없는 기본 세팅이다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 사이트맵의 정의: 페이지 주소(URL)를 나열한 XML 파일, 검색엔진에게 건네는 "우리 사이트 지도"
• 꼭 필요한 경우: 신규 사이트, 페이지 수가 많은 사이트, 내부 링크가 약한 사이트, 이미지·동영상이 많은 사이트
• 만드는 법: 직접 작성하는 법과 Next.js·워드프레스 같은 도구로 자동 생성하는 법
• 제출 법: 구글 서치 콘솔 3단계, robots.txt에 위치 적어두기
• 규모 관리: URL 50,000개 또는 50MB를 넘으면 나누는 법, 흔한 오류(가져올 수 없음) 해결법

조금 더 풀어 말하면, 검색엔진은 사람이 아니라 로봇(크롤러)이 사이트를 돌아다니며 페이지를 수집한다. 사이트가 작고 내부 링크가 촘촘하면 로봇이 링크를 타고 알아서 다 찾아간다.

하지만 사이트가 크거나, 새로 생긴 지 얼마 안 됐거나, 어떤 페이지가 다른 페이지에서 잘 연결되지 않는 구조라면 로봇이 그 페이지를 놓칠 수 있다. 사이트맵은 이런 사각지대를 없애는 안전망이다.

무인도에 아무리 좋은 호텔을 지어도 손님이 존재를 모르면 소용없듯, 아무리 좋은 페이지를 만들어도 구글이 그 페이지의 존재를 모르면 검색에 뜰 수 없다. 사이트맵은 그 존재를 가장 확실하게 알리는 방법 중 하나다.

이 글은 SEO를 처음 접하는 사람도 오늘 바로 따라 만들 수 있도록, 정의부터 작성법, 제출법, 규모별 대응, 흔한 오류 해결까지 예시 중심으로 쉽게 정리한다. 어려운 용어가 나오면 그 자리에서 한 문장으로 풀어 쓴다.

사이트맵(sitemap.xml)이란 무엇인가?

사이트맵은 내 사이트에 있는 페이지 주소(URL)를 정해진 형식으로 나열한 파일이다. 대부분 sitemap.xml이라는 이름으로 만들어지며, 내도메인.com/sitemap.xml 주소에서 누구나 열어볼 수 있다.

여기서 XML이란 컴퓨터끼리 정보를 주고받기 위해 정해 둔 문서 형식을 말한다. 사람이 읽는 블로그 글과 달리, 검색엔진 로봇이 기계적으로 읽기 좋도록 태그(꺾쇠괄호로 감싼 이름표) 구조로 되어 있다.

비유하자면 사이트맵은 건물의 층별 안내도와 비슷하다. 방문객이 안내도를 보고 "3층에 이런 매장이 있구나"를 한눈에 알 수 있듯, 검색엔진 로봇은 사이트맵을 보고 "이 사이트에 이런 페이지들이 있구나"를 한 번에 파악한다.

혼동하기 쉬운 개념부터 정리한다. 사람이 보는 "사이트맵 페이지"(예: /sitemap이라는 메뉴 안내 페이지)와, 검색엔진이 읽는 sitemap.xml 파일은 다른 것이다. 이 글에서 다루는 것은 후자, 즉 검색엔진용 XML 사이트맵이다.

사이트맵은 사람에게 보여주는 콘텐츠가 아니라, 검색엔진 로봇에게 건네는 "안내 문서"다.

사이트맵의 가장 단순한 형태는 이렇다.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://iruweb.com/</loc>
  </url>
  <url>
    <loc>https://iruweb.com/blog/what-is-sitemap-xml</loc>
    <lastmod>2026-07-23</lastmod>
  </url>
</urlset>

<urlset>은 "여기부터 URL 목록 시작"을 알리는 껍데기이고, <url> 하나가 페이지 하나를 뜻한다. 그 안의 <loc>이 실제 주소다. 구조는 이게 전부다. 어렵게 느껴진다면 겉모습 때문이지, 실제 내용은 단순한 표에 가깝다.

엑셀로 비유하면 더 쉽다. 첫 번째 열에 페이지 주소를, 두 번째 열에 마지막 수정일을 적어 둔 표라고 생각하면 된다. 다만 이 표를 사람이 아니라 로봇이 읽기 편하도록 XML이라는 형식의 옷을 입혀 놓은 것뿐이다.

여기까지 이해했다면 사이트맵의 기술적인 문턱은 사실상 넘은 셈이다. 나머지는 이 표에 무엇을 담고, 어떻게 최신 상태로 유지하며, 어떻게 검색엔진에게 전달할지의 문제로 좁혀진다.

사이트맵은 어떤 태그로 이루어지나?

사이트맵 안에는 보통 네 가지 태그가 들어가지만, 구글이 실제로 참고하는 태그는 두 개뿐이다. 나머지 두 개는 넣어도 무시된다는 점을 먼저 알아두면 시간을 아낄 수 있다.

loc(주소)은 유일한 필수 태그다. 이 페이지의 실제 주소를 그대로 적는다. http인지 https인지, www가 붙는지 안 붙는지까지 실제 사이트 주소와 정확히 일치해야 한다.

lastmod(최종 수정일)은 이 페이지가 마지막으로 바뀐 날짜다. 구글은 이 값이 "지속적이고 검증 가능하게 정확"할 때 참고한다고 공식 문서에서 밝히고 있다. 즉 아무렇게나 오늘 날짜로 채워 넣으면 오히려 신뢰를 잃는다.

changefreq(변경 빈도)는 "이 페이지가 얼마나 자주 바뀌는지"를 daily, weekly처럼 적어두는 태그다. 예전에는 크롤링 우선순위를 정하는 데 쓰인다고 여겨졌지만, 지금 구글은 이 값을 사실상 사용하지 않는다.

priority(우선순위)도 마찬가지다. 0부터 1 사이 숫자로 "이 페이지가 사이트 내에서 얼마나 중요한지"를 표시하지만, 구글은 이 값도 무시한다. 정성껏 숫자를 매겨도 결과에 영향을 주지 못한다.

결론적으로 신경 써야 할 태그는 loc과 lastmod 둘뿐이다. changefreq와 priority는 넣어도, 안 넣어도 결과가 같다.

이 사실을 모른 채 모든 페이지의 priority를 1.0으로 맞추거나 changefreq를 손수 관리하는 데 시간을 쓰는 경우를 종종 본다. 그 시간에 lastmod를 정확히 유지하는 편이 훨씬 이득이다.

사이트맵과 크롤 예산은 무슨 관계인가?

결론부터 말하면, 크롤 예산이 넉넉한 작은 사이트에서는 큰 의미가 없지만, 페이지가 많은 대형 사이트에서는 사이트맵이 이 예산을 아껴주는 역할을 한다.

여기서 크롤 예산(crawl budget)이란, 구글 로봇이 한 사이트를 방문했을 때 일정 기간 안에 둘러볼 수 있는 페이지 수의 한도를 말한다. 로봇도 시간과 자원이 무한하지 않으므로, 사이트마다 "이 정도까지만 돌아보겠다"는 암묵적인 예산을 두고 움직인다.

작은 사이트(페이지 수백 개 이하)라면 이 예산은 사실상 문제가 되지 않는다. 로봇이 하루 만에도 사이트 전체를 다 돌아볼 수 있기 때문이다. 크롤 예산은 페이지 수가 수만, 수십만 개를 넘어가는 대형 쇼핑몰이나 아카이브에서만 실질적인 변수가 된다.

이런 대형 사이트에서 사이트맵이 하는 역할은, 로봇에게 "이 페이지들이 중요하니 우선 확인해 달라"는 지도를 건네는 것이다. 지도가 없으면 로봇은 링크를 하나씩 따라가며 비효율적으로 탐색해야 하고, 그 과정에서 정작 중요한 페이지를 늦게 만나거나 예산을 다 쓰고도 못 찾는 페이지가 생길 수 있다.

크롤 예산은 일반 소개 사이트나 중소형 블로그가 걱정할 개념이 아니다. 페이지 수가 급격히 늘어나는 시점부터 신경 쓰면 된다.

반대로 죽은 링크나 리다이렉트가 사이트맵에 잔뜩 섞여 있으면, 로봇이 그 페이지들을 확인하는 데 예산을 낭비하게 된다. 앞서 "좋은 예·나쁜 예" 절에서 오래된 페이지를 방치하지 말라고 강조한 이유가 바로 여기에 있다. 깨끗한 사이트맵은 곧 효율적인 크롤 예산 사용으로 이어진다.

사이트맵이 왜 필요한가?

사이트맵의 역할은 한 문장으로 요약된다. 구글이 페이지를 더 빠르고, 더 빠짐없이 찾아내도록 돕는 것. 순위를 직접 올려주는 장치는 아니지만, "애초에 검색 후보에 오르는 것"을 도와준다.

검색에 뜨려면 먼저 크롤링(구글 로봇이 페이지를 방문해 읽어가는 과정)과 색인(읽어간 내용을 구글의 검색 목록에 등록하는 과정)을 거쳐야 한다. 사이트맵은 이 중 크롤링 단계에서 힘을 발휘한다.

사이트맵이 특히 힘을 발휘하는 상황과, 없어도 큰 문제가 없는 상황을 표로 정리했다.

상황	사이트맵의 효과
새로 만든 사이트	외부에서 연결된 링크(백링크)가 거의 없어 로봇이 찾아오기 어렵다 — 효과 큼
페이지 수가 많은 쇼핑몰·아카이브	내부 링크만으로는 깊은 곳의 상품 페이지가 묻히기 쉽다 — 효과 큼
페이지끼리 링크가 약한 구조	로봇이 링크를 타고 오지 못해 존재 자체를 모를 수 있다 — 효과 큼
이미지·동영상 콘텐츠가 많은 사이트	일반 크롤링만으로는 놓치기 쉬운 미디어 자산을 알릴 수 있다 — 효과 큼
페이지 10개 안팎의 단순한 소개 사이트	내부 링크만으로도 로봇이 다 찾아간다 — 효과 작음(그래도 있으면 좋음)

표를 조금 더 풀어 설명하면 이렇다. 새로 만든 사이트는 아직 어디서도 링크를 받지 못한 "섬"과 같다. 구글 로봇은 대개 기존에 알고 있던 페이지의 링크를 따라 새 페이지를 발견하는데, 갓 만든 사이트는 이 연결고리 자체가 없다. 사이트맵은 이 연결고리를 대신하는 지름길 역할을 한다.

페이지 수가 많은 쇼핑몰이나 아카이브는 다른 이유로 사이트맵이 중요하다. 메인 화면에서 클릭을 세 번, 네 번 거쳐야 도달하는 깊숙한 상품 페이지는, 내부 링크만으로는 로봇이 거기까지 가지 않고 포기하는 경우가 생긴다. 사이트맵은 이런 깊은 페이지도 목록 한 줄로 곧장 알려준다.

페이지끼리 링크가 약한 구조는 흔히 랜딩페이지를 여러 개 따로 만들어 운영하는 사이트에서 나타난다. 광고 캠페인용으로 만든 페이지가 메뉴 어디에도 연결되어 있지 않다면, 사이트맵에 그 주소를 추가하는 것이 사실상 유일한 발견 경로가 된다.

이미지·동영상이 많은 사이트는 텍스트 위주 크롤링만으로는 미디어 자산의 존재를 놓치기 쉽다. 특히 자바스크립트로 이미지를 늦게 불러오는 구조라면, 사이트맵에 이미지 정보를 별도로 명시해 두는 것이 발견 확률을 높인다.

이루웹이 SEO를 내장해 홈페이지를 만들 때도 사이트맵은 기본값으로 챙기는 항목이다. 직접 손대지 않아도 자동으로 갱신되는 사이트맵을 갖춘 사이트와, 아예 사이트맵이 없는 사이트는 새 글을 올렸을 때 구글이 알아차리는 속도부터 다르다.

여기서 흔한 오해 하나를 짚는다. "사이트맵을 제출하면 순위가 오른다"는 말은 사실이 아니다. 사이트맵은 발견을 돕는 지도일 뿐, 콘텐츠의 품질까지 대신 증명해 주지는 않는다. 순위를 올리는 것은 여전히 콘텐츠의 질과 관련성이다.

사이트맵은 어떻게 만드나?

사이트맵을 만드는 방법은 두 가지다. 직접 XML 파일을 작성하는 방법과, 도구나 프레임워크가 자동으로 생성하게 하는 방법. 결론부터 말하면, 페이지가 몇 개 안 되는 아주 작은 사이트가 아니라면 자동 생성 쪽을 강력히 권한다.

직접 작성하는 경우

페이지가 몇 개뿐인 작은 사이트라면 메모장으로도 충분하다. 아래는 세 페이지짜리 최소 예시다.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://내도메인.com/</loc>
    <lastmod>2026-07-20</lastmod>
  </url>
  <url>
    <loc>https://내도메인.com/about</loc>
    <lastmod>2026-07-10</lastmod>
  </url>
  <url>
    <loc>https://내도메인.com/contact</loc>
    <lastmod>2026-06-30</lastmod>
  </url>
</urlset>

이 파일을 sitemap.xml이라는 이름으로 저장해, 사이트 최상위 경로(루트)에 업로드하면 끝이다. 다만 페이지가 늘어날 때마다 손으로 계속 고쳐야 한다는 것이 이 방식의 한계다.

도구·프레임워크로 자동 생성하는 경우

업종·플랫폼별로 자동 생성 방법을 정리했다.

• 워드프레스: Yoast SEO, RankMath 같은 SEO 플러그인을 설치하면 글을 쓸 때마다 사이트맵이 자동으로 갱신된다. 별도 코드 작업이 필요 없다.
• Next.js(이 사이트가 쓰는 방식): app/sitemap.ts 파일 하나로 사이트 전체 URL 목록을 코드에서 동적으로 생성한다. 새 블로그 글을 추가하면 배포와 동시에 사이트맵도 자동으로 갱신된다.
• 카페24·고도몰 등 쇼핑몰 솔루션: 대부분 관리자 화면에 사이트맵 자동 생성 기능이 내장되어 있다. 설정 메뉴에서 켜기만 하면 된다.
• Shopify, 웹플로우 등 해외 빌더: 별도 설정 없이도 기본으로 sitemap.xml을 제공하는 경우가 많다. 도메인 뒤에 /sitemap.xml을 붙여 실제로 열리는지 확인만 하면 된다.

필자가 실무에서 겪은 경험을 보태면, 자동 생성 사이트맵의 최대 장점은 "빠뜨림이 없다"는 것이다. 사람이 손으로 관리하면 새 페이지를 깜빡 빠뜨리거나, 삭제한 페이지 주소를 지우지 않고 남겨두는 실수가 반드시 생긴다. 코드가 자동으로 목록을 만들면 이런 실수 자체가 구조적으로 사라진다.

실제 코드로 보는 자동 생성 사례

이해를 돕기 위해, 이 글을 담고 있는 이루웹 사이트가 실제로 쓰는 방식을 단순화해 소개한다. Next.js라는 프레임워크는 app/sitemap.ts라는 파일 하나만 만들어 두면, 접속이 들어올 때마다 그 시점의 페이지 목록으로 사이트맵을 새로 만들어 준다.

export default function sitemap() {
  const staticPages = ["/", "/services", "/blog", "/contact"];
  const blogPosts = getAllPostsMeta(); // 발행된 블로그 글 목록을 불러온다

  return [
    ...staticPages.map((path) => ({ url: `https://iruweb.com${path}` })),
    ...blogPosts.map((post) => ({
      url: `https://iruweb.com/blog/${post.slug}`,
      lastModified: post.date,
    })),
  ];
}

이 코드의 핵심은 글 목록(getAllPostsMeta)을 사이트맵이 직접 물어본다는 점이다. 새 블로그 글을 발행하면 이 목록에 자동으로 포함되고, 글을 지우면 자동으로 빠진다. 사람이 사이트맵 파일을 별도로 열어 손댈 일이 아예 없다.

작은 소개 사이트에는 과한 방식처럼 보일 수 있지만, 블로그처럼 콘텐츠가 계속 늘어나는 사이트라면 이 구조 하나로 "사이트맵을 깜빡 잊는" 실수 자체가 원천적으로 사라진다. 워드프레스의 SEO 플러그인도 내부적으로는 비슷한 원리로, 글을 저장하는 순간 목록을 다시 계산해 사이트맵에 반영한다.

사이트맵은 얼마나 자주 갱신해야 하나?

자동 생성 구조라면 신경 쓸 필요가 없다. 콘텐츠가 바뀔 때마다 사이트맵도 즉시 같이 바뀌기 때문이다. 갱신 주기를 따로 정할 필요조차 없다.

수동으로 관리하는 소규모 사이트라면 이야기가 다르다. 새 페이지를 만들거나 기존 페이지를 지울 때마다 그때그때 반영하는 것이 원칙이지만, 현실적으로 매번 챙기기 어렵다면 최소 한 달에 한 번은 사이트맵을 열어 최신 상태와 맞는지 점검하는 것을 권한다.

갱신을 미루는 사이는 그만큼 구글이 옛날 지도를 들고 사이트를 찾아온다는 뜻이다. 지도가 오래될수록 새로 생긴 길(페이지)을 놓칠 확률이 올라간다.

나쁜 예와 좋은 예를 비교하면 이렇다.

나쁜 예: 6개월 전에 손으로 만든 사이트맵을 그대로 방치. 그사이 새로 올린 글 40개는 빠져 있고, 삭제한 이벤트 페이지 3개는 여전히 남아 있다.

좋은 예: 콘텐츠 관리 시스템(CMS)이나 프레임워크가 배포할 때마다 사이트맵을 다시 만들어, 항상 현재 상태와 100% 일치한다.

작은 소개 페이지 몇 장짜리 사이트가 아니라면, 처음부터 자동 생성 구조를 갖추는 것이 장기적으로 시간을 아끼는 길이다. 홈페이지를 새로 만드는 단계라면 이 부분을 제작사에 반드시 확인하자.

사이트맵은 어떻게 제출하나?

사이트맵 파일을 사이트에 올려두는 것만으로는 부족하다. 구글에게 "여기 사이트맵이 있다"고 직접 알려줘야 효과가 확실해진다. 제출은 아래 세 단계로 진행한다.

첫째, 사이트맵 파일을 만들어 실제로 열리는 주소에 올려둔다. 내도메인.com/sitemap.xml을 브라우저 주소창에 직접 쳐서, XML 코드가 화면에 뜨는지 먼저 확인한다. 404 오류가 뜬다면 다음 단계로 넘어가기 전에 이 부분부터 고쳐야 한다.

둘째, robots.txt 파일에 사이트맵 위치를 한 줄 적어둔다. robots.txt는 검색엔진 로봇에게 "이 사이트에서 무엇을 봐도 되는지"를 안내하는 또 다른 파일인데, 여기에 아래처럼 한 줄만 추가하면 로봇이 스스로 사이트맵을 찾아올 수 있다.

Sitemap: https://내도메인.com/sitemap.xml

이 한 줄은 robots.txt 파일 어디에 넣어도 상관없다. 대소문자는 Sitemap:으로 시작하는 것이 관례지만, 대부분의 검색엔진은 소문자로 써도 인식한다.

셋째, 구글 서치 콘솔에 직접 제출한다. 구글 서치 콘솔 등록 방법을 이미 마쳤다면, 좌측 메뉴에서 "Sitemaps"를 클릭하고 사이트맵 파일 이름(예: sitemap.xml)만 입력한 뒤 제출을 누르면 된다.

세 단계 중 가장 확실한 효과를 보려면 셋째 단계까지 반드시 마쳐야 한다. robots.txt에만 적어두고 서치 콘솔에는 제출하지 않는 경우가 많은데, 서치 콘솔에서 직접 제출하면 처리 상태(성공/실패)를 눈으로 확인할 수 있어 훨씬 안전하다.

robots.txt에 적어두는 것과 서치 콘솔에 제출하는 것은 서로 대체재가 아니라 보완재다. 둘 다 해두면 가장 안전하다.

제출 후에는 상태가 바로 "성공"으로 뜨지 않을 수 있다. 구글이 실제로 사이트맵을 읽어가는 데 시간이 걸리기 때문에, 몇 시간에서 하루 정도 지난 뒤 다시 확인하는 것이 정확하다.

사이트맵 크기와 URL 개수 제한은 어떻게 관리하나?

사이트맵 하나에는 한도가 있다. 이 한도를 모르고 페이지가 많은 사이트를 운영하면, 일부 URL이 사이트맵에서 누락되는 문제가 생길 수 있다.

구글 공식 문서에 따르면 단일 사이트맵 파일은 URL 50,000개 또는 50MB(비압축 기준) 중 어느 하나만 넘어도 규격을 벗어난다. 두 조건 모두를 만족해야 하는 것이 아니라, 둘 중 하나만 초과해도 문제가 된다는 점에 주의해야 한다.

블로그 글 몇백 개 수준의 사이트라면 이 한도에 걸릴 일이 거의 없다. 하지만 상품 페이지가 수만 개인 대형 쇼핑몰, 게시글이 누적되는 커뮤니티, 뉴스 아카이브 같은 사이트라면 이야기가 다르다.

이럴 때 쓰는 해법이 사이트맵 인덱스(sitemap index)다. 원리는 간단하다. URL 목록을 여러 개의 사이트맵 파일로 나눈 뒤(예: sitemap-1.xml, sitemap-2.xml…), 이 파일들의 목록만 담은 "사이트맵들의 사이트맵" 하나를 따로 만드는 것이다.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://내도메인.com/sitemap-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://내도메인.com/sitemap-2.xml</loc>
  </sitemap>
</sitemapindex>

이렇게 만든 인덱스 파일 하나만 서치 콘솔에 제출하면, 구글이 알아서 안에 연결된 개별 사이트맵을 모두 찾아가 읽는다. 개별 사이트맵을 하나하나 따로 제출할 필요가 없다.

대형 쇼핑몰이나 CMS 플랫폼은 대부분 이 사이트맵 인덱스 구조를 자동으로 만들어 준다. 워드프레스의 Yoast SEO도 글이 많아지면 자동으로 사이트맵을 여러 개로 쪼개 인덱스로 관리한다.

페이지가 수천 개를 넘어가는 사이트를 운영한다면, "사이트맵이 자동으로 분할되는지"를 반드시 확인해야 한다. 수동 관리로는 한계에 부딪히기 쉽다.

참고로 이미지·동영상·뉴스처럼 특수한 콘텐츠를 위한 전용 사이트맵 형식도 별도로 존재한다. 일반 페이지 사이트맵과 형식이 조금 다르므로, 이런 콘텐츠 비중이 큰 사이트라면 별도로 챙기는 것이 좋다. 이 부분은 이어지는 절에서 다시 다룬다.

사이트맵 오류는 어떻게 해결하나?

서치 콘솔의 Sitemaps 보고서에서 "가져올 수 없음" 같은 오류를 마주치는 경우가 흔하다. 대부분은 아래 네 가지 원인 중 하나다. 순서대로 점검하면 대개 해결된다.

첫째, robots.txt가 사이트맵 자체를 막고 있는 경우다. Disallow: /처럼 사이트 전체를 막아두면, 사이트맵 파일도 로봇이 읽을 수 없게 막힌다. robots.txt를 열어 사이트맵 경로가 차단 목록에 걸려 있지 않은지 확인한다.

둘째, 사이트맵 주소가 실제로 존재하지 않는 경우다. 파일 이름을 잘못 적었거나, 개발 서버 주소로 잘못 등록한 경우가 흔하다. 브라우저에서 직접 그 주소를 열어 XML 내용이 뜨는지 먼저 확인해야 한다.

셋째, 사이트맵이 XML이 아니라 HTML을 반환하는 경우다. 서버 설정 오류로 사이트맵 요청에 "페이지를 찾을 수 없습니다"라는 일반 HTML 오류 페이지가 대신 뜨는 사례다. 이 경우 겉보기엔 페이지가 열리는 것 같아도, 실제 내용은 사이트맵이 아니다.

넷째, URL이 사이트의 실제 도메인과 일치하지 않는 경우다. 예를 들어 사이트맵 안의 주소는 www.내도메인.com인데, 실제 서치 콘솔에 등록한 속성은 내도메인.com(www 없이)이라면 불일치로 처리될 수 있다. 사이트맵 안의 도메인과 서치 콘솔 속성의 도메인은 정확히 같아야 한다.

오류 메시지가 뜬다고 당황할 필요는 없다. 위 네 가지를 순서대로 점검하면 대부분 원인을 찾을 수 있다. 원인을 고친 뒤에는 서치 콘솔에서 사이트맵을 다시 제출하면 된다.

한 가지 덧붙이면, 사이트맵 상태가 "성공"이라고 해서 그 안의 URL이 전부 색인되었다는 뜻은 아니다. 사이트맵은 "발견"을 돕는 것이고, 색인 여부는 페이지 품질과 별개로 판단된다. 색인 상태까지 세세히 점검하려면 서치 콘솔의 URL 검사 기능을 함께 활용하는 것이 좋다.

제출 후에는 무엇을 더 확인해야 하나?

사이트맵 상태가 "성공"으로 뜬 뒤에도 할 일이 하나 더 남아 있다. 제출된 URL 수와 실제 색인된 URL 수를 비교하는 것이다. 서치 콘솔의 Sitemaps 보고서에는 이 두 숫자가 나란히 표시된다.

예를 들어 사이트맵에 URL 200개를 제출했는데 색인된 페이지가 120개뿐이라면, 나머지 80개는 구글이 존재는 확인했지만 아직(또는 영영) 검색 목록에 올리지 않았다는 뜻이다. 이 격차 자체는 이상한 일이 아니며, 사이트 대부분에서 어느 정도 나타난다.

다만 격차가 유난히 크다면 아래를 의심해 볼 수 있다.

• 콘텐츠가 비슷비슷한 페이지가 많은 경우: 구글이 "이미 비슷한 내용이 있다"고 판단해 중복으로 취급했을 수 있다.
• 품질이 낮거나 너무 짧은 페이지가 많은 경우: 구글이 검색 결과로 보여줄 만한 가치가 낮다고 판단했을 수 있다.
• 아직 크롤링 자체가 안 된 경우: 시간이 더 필요한 상태로, 재확인하며 기다리면 된다.

더 정확히 확인하려면 서치 콘솔의 "페이지" 보고서(페이지 색인 생성 보고서)를 함께 열어보면 좋다. 여기서는 색인되지 않은 페이지마다 구체적인 사유가 표시되는데, 자주 보이는 항목은 다음과 같다.

• "크롤됨 – 현재 색인이 생성되지 않음": 구글이 페이지를 읽어는 갔지만, 아직 검색 목록에 올릴지 판단하지 못한 상태다. 대개는 시간이 지나면 자연히 해소된다.
• "발견됨 – 현재 색인이 생성되지 않음": 사이트맵을 통해 주소는 알았지만 아직 방문(크롤링) 전인 상태다. 사이트 전체의 크롤 예산이 부족하거나, 페이지 품질에 대한 신뢰가 아직 부족할 때 자주 나타난다.
• "사용자가 선택한 표준이 없는 중복 페이지": 앞서 다룬 정규 URL(canonical) 문제와 정확히 같은 원인이다. 같은 내용의 주소가 여러 개라 구글이 대표를 스스로 골라야 했다는 뜻이다.
• "URL이 'noindex'로 표시됨": 페이지 안에 색인을 원치 않는다는 표시가 있다는 뜻이다. 의도한 설정이 아니라면, 그 페이지의 noindex 태그를 실수로 넣지 않았는지 확인해야 한다.

이 사유들을 하나씩 눈으로 확인하면, "왜 이 페이지가 검색에 안 뜨는지" 막연히 추측하는 대신 정확한 원인부터 짚고 대응할 수 있다.

사이트맵 제출은 "발견"까지만 책임진다. 제출된 URL이 모두 색인되도록 만드는 것은 콘텐츠 품질의 몫이다.

이 비교 작업은 한 번으로 끝내지 말고, 사이트맵을 갱신하거나 새 콘텐츠를 대량으로 올린 뒤 몇 주 간격으로 다시 확인하는 습관을 들이면 좋다. 숫자가 꾸준히 개선되는지 지켜보는 것만으로도 사이트 전체의 콘텐츠 품질을 가늠하는 지표가 된다.

자바스크립트로 만든 사이트는 사이트맵이 더 중요한가?

결론부터 말하면, 그렇다. 리액트(React)나 뷰(Vue) 같은 도구로 만들어, 화면 대부분을 자바스크립트가 그려내는 사이트(흔히 SPA라고 부른다)는 일반 사이트보다 사이트맵의 역할이 조금 더 커진다.

일반적인 페이지는 서버가 처음부터 완성된 HTML을 내려주지만, SPA 방식은 처음에는 거의 빈 화면만 내려주고 자바스크립트가 실행된 뒤에야 실제 내용이 채워지는 경우가 많다. 구글 로봇도 이 자바스크립트를 실행해 내용을 읽어내긴 하지만, 일반 HTML 페이지보다 처리에 더 많은 시간과 자원이 든다.

이런 구조에서는 로봇이 링크를 하나씩 따라가며 페이지를 탐색하는 과정 자체가 더 무겁다. 사이트맵으로 주요 페이지 주소를 미리 명확하게 알려주면, 로봇이 자바스크립트를 굳이 다 실행해 링크를 찾아내지 않아도 곧바로 각 페이지에 접근할 수 있어 부담을 크게 줄여준다.

이루웹이 홈페이지를 만들 때 서버에서 미리 완성된 화면을 내려주는 방식(SSR)을 기본으로 택하는 이유도 이와 맞닿아 있다. 방문자에게 더 빠른 화면을 보여주는 방식이 동시에 검색엔진에게도 더 친절한 구조가 되는 경우가 많다.

사이트를 SPA 방식으로 이미 만들었다고 해서 검색에 불리한 것은 아니다. 다만 이런 구조일수록 사이트맵을 정확하고 빠짐없이 관리하는 일의 중요도가 한 단계 더 올라간다는 점을 기억하면 된다.

사이트맵 제출과 개별 URL 색인 요청은 언제 각각 써야 하나?

결론부터 말하면, 여러 페이지를 한 번에 알리고 싶으면 사이트맵을, 특정 페이지 하나를 지금 당장 확인하고 싶으면 URL 검사 도구를 쓴다. 두 방식은 경쟁 관계가 아니라 서로 다른 상황에 쓰는 도구다.

서치 콘솔에는 "URL 검사"라는 별도 기능이 있다. 주소창에 특정 페이지 주소를 붙여넣으면 그 페이지의 현재 색인 상태를 보여주고, 하단의 "색인 생성 요청" 버튼으로 즉시 크롤링을 요청할 수 있다.

이 기능은 새 글을 하나 발행했을 때, 또는 중요한 페이지 내용을 크게 수정했을 때 "이 페이지만큼은 빨리 확인해 달라"고 콕 집어 요청하는 용도에 알맞다. 구글 공식 문서에도 "하루에 제출할 수 있는 색인 요청 수에는 제한이 있다"고 안내되어 있어, 수십 개, 수백 개 페이지를 한꺼번에 이 방법으로 요청하기는 어렵다.

반대로 페이지 수가 많거나, 사이트 전체를 한꺼번에 알리고 싶을 때는 사이트맵이 정답이다. 구글 공식 문서도 "많은 페이지의 색인을 생성하려면 사이트맵을 제출하라"고 명확히 안내한다. 사이트맵은 개수 제한 없이 URL 목록 전체를 한 번에 전달할 수 있고, lastmod로 변경 이력까지 함께 추적된다.

새 블로그 글 하나를 빨리 알리고 싶다면 URL 검사로 개별 요청, 사이트 구조를 새로 개편했거나 페이지 수십 개를 한꺼번에 올렸다면 사이트맵 갱신과 재제출. 이렇게 상황별로 나눠 쓰면 된다.

사이트맵과 robots.txt는 어떻게 다른가?

이름이 비슷하게 들려서인지 두 파일을 헷갈리는 경우가 많은데, 역할이 정반대에 가깝다.

구분	사이트맵(sitemap.xml)	robots.txt
역할	"이 페이지들을 봐 달라"고 초대하는 목록	"여기는 보지 말아 달라"고 제한하는 규칙
형식	XML	일반 텍스트
위치	보통 /sitemap.xml	반드시 /robots.txt(루트)
필수 여부	권장(필수 아님)	없어도 동작하지만 있는 것이 안전
잘못 쓰면	일부 페이지가 늦게 발견될 뿐	사이트 전체가 크롤링에서 차단될 수 있음

쉽게 말해 사이트맵은 "와서 봐주세요" 초대장이고, robots.txt는 "여긴 오지 마세요" 출입 규칙이다. 사이트맵에 넣은 페이지라도 robots.txt에서 막아버리면 로봇은 그 페이지에 들어가지 못한다.

그래서 두 파일은 항상 서로 충돌하지 않는지 함께 점검해야 한다. 앞서 다룬 "사이트맵 오류"의 첫 번째 원인이 바로 이 충돌이었다는 점을 떠올리면 이해가 쉽다.

서브도메인이나 여러 도메인을 쓰는 사이트는 어떻게 하나?

결론부터 말하면, 사이트맵은 원칙적으로 자기 자신이 속한 도메인(또는 서브도메인)의 주소만 담을 수 있다. 예를 들어 blog.내도메인.com에 있는 사이트맵은 blog.내도메인.com으로 시작하는 주소만 넣을 수 있고, shop.내도메인.com 같은 다른 서브도메인 주소는 원칙적으로 넣을 수 없다.

이는 검색엔진이 사이트맵의 신뢰도를 확인하는 방식과 관련이 있다. 사이트맵이 자기 영역 밖의 주소까지 마음대로 담을 수 있다면, 악의적으로 남의 사이트 주소를 잔뜩 밀어 넣는 악용이 가능해지기 때문이다.

그래서 메인 사이트(내도메인.com)와 블로그 서브도메인(blog.내도메인.com), 쇼핑몰 서브도메인(shop.내도메인.com)을 함께 운영한다면, 각 서브도메인마다 별도의 사이트맵을 만들고 각각 서치 콘솔에 등록해야 한다.

다만 예외가 있다. 서치 콘솔에서 메인 도메인과 서브도메인 각각의 소유권을 모두 확인해 두었다면, 하나의 사이트맵 안에 여러 서브도메인의 주소를 함께 담아 제출할 수도 있다. 다만 이는 다소 고급 설정에 속하므로, 대부분의 사업자는 서브도메인별로 사이트맵을 나누는 기본 방식을 따르는 것이 간단하고 안전하다.

서브디렉토리(내도메인.com/blog처럼 경로로 나누는 방식)는 이런 제약이 없다. 하나의 사이트맵 안에 모든 경로를 자유롭게 함께 담을 수 있다. 이런 이유로 블로그를 별도 서비스로 운영할 때, 서브도메인보다 서브디렉토리 구조가 사이트맵과 SEO 관리 양쪽에서 더 단순하다는 의견도 많다.

이미지·동영상·뉴스 사이트맵도 따로 만들어야 하나?

결론부터 말하면, 대부분의 일반 사업자 사이트는 신경 쓰지 않아도 된다. 이미지나 동영상도 페이지 사이트맵 안에 확장 태그로 함께 담을 수 있고, 일반 크롤링만으로도 대부분 발견된다.

다만 아래 경우라면 별도로 챙기는 것이 유리하다.

• 쇼핑몰처럼 상품 이미지가 검색 결과의 이미지 탭에 자주 노출되길 원하는 경우: 이미지 사이트맵 태그를 추가하면 발견 속도가 빨라진다.
• 강의 영상, 제품 소개 영상 등 동영상 콘텐츠가 핵심 자산인 경우: 동영상 사이트맵을 통해 재생 시간·썸네일 같은 정보를 함께 알릴 수 있다.
• 속보성 뉴스를 발행하는 언론·매체 사이트: 뉴스 사이트맵은 발행 후 매우 짧은 시간 안에 노출되어야 하므로 형식이 따로 있다.

일반적인 홈페이지·블로그·서비스 소개 사이트라면, 기본 페이지 사이트맵 하나만 잘 관리해도 충분하다. 특수 사이트맵은 콘텐츠의 성격이 뚜렷할 때 추가하는 선택 사항으로 생각하면 된다.

업종별로 사이트맵 전략은 어떻게 다른가?

사이트맵을 만드는 기본 원리는 같지만, 업종에 따라 무엇을 우선순위로 담을지는 조금씩 달라진다. 몇 가지 대표 업종으로 살펴본다.

쇼핑몰(원두 판매 등 이커머스)

쇼핑몰은 상품 페이지 수가 많고, 품절이나 시즌 종료로 페이지가 자주 사라진다는 특징이 있다. 그래서 상품 등록·품절·재입고를 사이트맵에 실시간으로 반영하는 자동화가 특히 중요하다.

품절된 상품을 사이트맵에서 즉시 빼지 않으면, 손님이 검색을 통해 들어왔다가 "품절"이라는 문구만 보고 이탈하는 일이 반복된다. 상품이 수백 개를 넘어가면 이 절에서 다룬 사이트맵 인덱스 구조도 함께 준비해야 한다.

블로그·정보성 콘텐츠 사이트

블로그는 페이지 수 자체보다 lastmod의 정확성이 더 중요하다. 오래된 글을 최신 정보로 업데이트했다면, 그 수정 시점을 사이트맵의 lastmod에도 정확히 반영해야 구글이 "이 글이 최근에 갱신됐다"는 신호를 받는다.

반대로 내용은 그대로인데 사소한 오타만 고치고도 lastmod를 매번 오늘 날짜로 바꾸는 것은 피해야 한다. 실질적인 내용 변경이 없는데 날짜만 자주 바뀌면, 이 글 초반에 설명한 "지속적이고 검증 가능하게 정확한 lastmod"라는 신뢰 조건에서 오히려 멀어진다.

병원·법률·학원 등 지역 서비스업

이런 업종은 페이지 수가 많지 않은 대신(진료 안내, 의료진 소개, 오시는 길, 블로그 정도), 한 페이지 한 페이지의 중요도가 매우 높다. 페이지 수가 적으니 사이트맵의 효과가 상대적으로 작다고 여길 수 있지만, 실제로는 그렇지 않다.

지역 서비스업은 대개 사이트 나이가 젊고 백링크가 적어 로봇이 자연스럽게 찾아오기 어렵다. 이런 사이트일수록 사이트맵이 초반 발견 속도를 앞당기는 효과가 크다.

부동산·중개업

매물 페이지가 수시로 등록되고 계약 완료 시 바로 사라지는 것이 특징이다. 이런 사이트는 사이트맵 갱신 주기가 사실상 "매일 여러 번"에 가까워야 한다. 사람이 수동으로 관리하기에는 무리가 있으므로, 매물 관리 시스템과 사이트맵이 자동으로 연동되는 구조가 필수에 가깝다.

제조업·B2B 기업 사이트

이런 사이트는 페이지 수는 적지만, 제품 카탈로그나 기술 자료(PDF)처럼 문서 형태의 콘텐츠가 많다는 특징이 있다. PDF 파일도 URL 하나로 취급되므로, 중요한 자료라면 사이트맵에 함께 포함해 발견 확률을 높일 수 있다.

다만 로그인이 필요하거나 다운로드 신청 양식을 거쳐야만 열리는 자료라면, 애초에 검색 로봇이 접근할 수 없으므로 사이트맵에 넣어도 의미가 없다. 로봇이 실제로 열람 가능한 자료인지부터 확인하는 것이 먼저다.

이처럼 업종은 달라도 원칙은 하나로 모인다. 사이트맵은 "지금 이 순간 실제로 존재하는 페이지"를 정확히 비추는 거울이어야 한다. 업종별 특성에 맞춰 그 거울을 얼마나 자주, 얼마나 세밀하게 닦을지만 다르게 정하면 된다.

사이트맵 좋은 예와 나쁜 예는 무엇인가?

지금까지 배운 내용을 실전 감각으로 정리하기 위해, 자주 보는 나쁜 사례와 좋은 사례를 나란히 비교한다.

첫 번째, 오래된 페이지 방치

나쁜 예: 3년 전에 폐업한 이벤트 페이지, 이미 삭제된 상품 상세 페이지가 여전히 사이트맵에 남아 있다.

좋은 예: 페이지를 삭제하거나 비공개로 전환하면 사이트맵에서도 자동으로 함께 빠진다.

죽은 링크가 사이트맵에 계속 남아 있으면, 구글이 계속 그 페이지를 확인하러 왔다가 헛걸음을 반복한다. 이런 낭비가 쌓이면 정작 중요한 새 페이지를 확인할 여력이 줄어들 수 있다.

두 번째, noindex 페이지 포함

나쁜 예: "검색에 노출하지 않음(noindex)"으로 설정한 관리자 페이지, 장바구니 페이지까지 사이트맵에 그대로 들어 있다.

좋은 예: noindex로 설정한 페이지는 애초에 사이트맵 목록에서 제외한다.

이 둘은 서로 모순된 신호를 구글에게 보내는 셈이다. "검색에 넣지 말라"고 해놓고 "봐 달라"고 목록에 올리는 것이니, 혼란만 줄 뿐 도움이 되지 않는다.

세 번째, 중복 URL 나열

나쁜 예: 내도메인.com/page와 내도메인.com/page?ref=email처럼, 같은 내용인데 뒤에 추적 파라미터만 다른 주소가 각각 사이트맵에 들어 있다.

좋은 예: 대표 주소(canonical, 정규 URL) 하나만 사이트맵에 담는다.

중복 주소가 섞이면 구글이 "어느 쪽이 진짜 페이지인지" 판단하는 데 불필요한 부담을 준다. 정규 URL이라는 개념은 여러 주소 중 대표로 삼을 하나를 지정하는 방법인데, 사이트맵은 이 정규 URL만 담는 것이 원칙이다.

부실한 사이트맵을 함께 고쳐 볼까?

이해를 굳히기 위해, 실제로 흔한 사례 하나를 단계별로 고쳐 보자. 3년째 방치된 어느 학원 홈페이지의 사이트맵이라고 가정한다.

처음 상태는 이랬다. 사이트맵 안에 URL이 총 42개 있었는데, 살펴보니 문제가 한둘이 아니었다.

• 2년 전 종료된 "여름방학 특강" 이벤트 페이지가 3개나 남아 있다(404 오류).
• 관리자만 쓰는 /admin/login 페이지가 실수로 포함되어 있다.
• 같은 수업 소개 페이지가 /class/english와 /class/english/(슬래시 유무 차이)로 중복 등록되어 있다.
• 모든 페이지의 lastmod가 사이트맵을 처음 만든 3년 전 날짜 그대로다.
• robots.txt에는 사이트맵 위치가 아예 적혀 있지 않다.

이제 앞서 배운 원칙대로 하나씩 고쳐본다.

1. 죽은 URL부터 제거한다. 404가 뜨는 이벤트 페이지 3개를 사이트맵에서 뺀다. 이것만으로도 로봇이 헛걸음하는 횟수가 줄어든다.
2. 노출되면 안 되는 페이지를 뺀다. /admin/login처럼 사람이나 검색엔진이 볼 필요가 없는 페이지는 애초에 사이트맵에 넣을 대상이 아니다.
3. 중복 URL을 정규 URL 하나로 합친다. /class/english/(슬래시 있는 쪽)를 대표 주소로 정하고, 다른 쪽은 사이트맵에서 제외한다.
4. lastmod를 실제 수정일로 갱신한다. 최근에 내용을 고친 페이지는 그 날짜로, 오래전부터 안 바뀐 페이지는 실제 마지막 수정일 그대로 둔다. 전부 오늘 날짜로 일괄 변경하는 것은 오히려 신뢰를 깎는 행동이므로 피한다.
5. robots.txt에 사이트맵 위치를 추가한다. Sitemap: https://academy-example.com/sitemap.xml 한 줄을 넣는다.

이렇게 정리하고 나니 42개였던 URL이 실제 유효 페이지 36개로 줄었다. 숫자는 줄었지만, 로봇이 신뢰하고 참고할 수 있는 지도는 오히려 훨씬 정확해졌다.

사이트맵은 "많이 담을수록 좋은 목록"이 아니라 "정확할수록 좋은 목록"이다. 죽은 페이지 100개보다 살아 있는 페이지 10개가 낫다.

이 사례처럼 오래 방치된 사이트맵은 대부분 비슷한 문제를 안고 있다. 지금 운영 중인 사이트맵이 있다면, 이 다섯 단계를 그대로 자신의 사이트에 적용해 점검해 보는 것을 권한다.

다국어 사이트를 운영한다면 한 가지를 더 챙겨야 한다. 언어별 페이지가 서로 다른 언어의 대응 페이지를 가리키는 hreflang 속성을 사이트맵에 추가해 둘 수 있는데, 이는 "이 페이지의 한국어판은 여기, 영어판은 저기"라고 검색엔진에게 알려주는 역할을 한다. 다국어 사이트가 아니라면 신경 쓰지 않아도 된다.

사이트맵을 만들 때 흔히 하는 기술적 실수는 무엇인가?

지금까지 다룬 내용 외에도, 사이트맵을 처음 만드는 사람들이 자주 걸려 넘어지는 기술적인 함정이 몇 가지 있다. 미리 알아두면 시행착오를 줄일 수 있다.

첫째, 상대 경로로 주소를 적는 실수다. <loc>/blog/example</loc>처럼 도메인 없이 경로만 적으면 규격에 어긋난다. <loc>에는 반드시 https://내도메인.com/blog/example처럼 처음부터 끝까지 완전한 주소(절대 경로)를 적어야 한다.

둘째, 인코딩 선언을 빠뜨리는 실수다. 사이트맵 첫 줄의 <?xml version="1.0" encoding="UTF-8"?>는 "이 파일은 UTF-8이라는 방식으로 글자를 저장했다"고 알리는 선언이다. 이 줄이 없거나 다른 인코딩으로 잘못 저장되면, 한글 주소나 한글이 포함된 페이지 제목 정보가 깨져 보일 수 있다.

셋째, http와 https, www 유무를 뒤섞어 쓰는 실수다. 사이트가 실제로는 https://내도메인.com으로 운영되는데 사이트맵에는 http://www.내도메인.com이 섞여 있으면, 구글이 이를 서로 다른 주소로 인식해 혼란을 준다. 사이트맵 전체에서 주소 형식을 하나로 통일해야 한다.

넷째, 태그를 제대로 닫지 않는 실수다. <url>을 열었으면 반드시 </url>로 닫아야 하는데, 수작업으로 사이트맵을 편집하다 태그 하나를 빠뜨리면 파일 전체가 깨진 것으로 처리된다. 자동 생성 도구를 쓰면 이런 실수 자체가 생기지 않는다는 것도 자동화를 권하는 이유 중 하나다.

다섯째, 한글이 포함된 주소를 인코딩하지 않는 실수다. 상품명이나 카테고리명이 한글로 된 URL을 쓰는 사이트라면, 그 주소를 사이트맵에 넣을 때 URL 인코딩(퍼센트 기호로 문자를 표현하는 방식)이 되어 있어야 한다. 대부분의 자동 생성 도구는 이 처리를 알아서 해주지만, 손으로 직접 작성한다면 놓치기 쉬운 부분이다.

이 다섯 가지 실수의 공통점은 하나다. 손으로 직접 사이트맵을 관리할수록 발생 확률이 높아진다. 자동 생성 구조를 권하는 이유가 여기에도 있다.

구글 말고 다른 검색엔진에도 사이트맵을 제출해야 하나?

결론부터 말하면, 주요 검색엔진마다 별도의 도구에 각각 등록해야 한다. 사이트맵 파일 자체는 하나만 만들어 두고, 그 파일의 위치를 여러 검색엔진 도구에 나눠 알려주는 방식이다.

• 네이버: 네이버 서치어드바이저에 사이트를 등록하고 사이트맵을 제출한다. 국내 방문자 비중이 높다면 구글 서치 콘솔만큼이나 챙겨야 할 필수 절차다.
• 빙(Bing): 빙 웹마스터 도구(Bing Webmaster Tools)에서 별도로 제출한다. 참고로 빙은 구글 서치 콘솔에서 제출한 정보를 가져올 수 있는 연동 기능도 제공하고 있어, 아예 처음부터 다시 입력하지 않아도 되는 경우가 많다.
• 다음(카카오): 다음 검색등록 페이지를 통해 사이트를 등록할 수 있다. 국내 트래픽 비중에 따라 우선순위를 정하면 된다.

이 도구들은 저마다 이름과 화면 구성이 다르지만, "사이트맵 위치를 알려준다"는 절차의 본질은 동일하다. 사이트맵 파일 하나를 잘 만들어 두면, 어느 검색엔진에 제출하든 재사용할 수 있다.

방문자의 대부분이 구글에서 유입되는 사업이라면 구글 서치 콘솔 하나만 챙겨도 충분한 경우가 많지만, 네이버 SEO와 구글 SEO의 차이에서 다뤘듯 국내 소비자를 대상으로 한다면 네이버 등록도 함께 진행하는 것이 안전하다.

사이트맵 발행 전 무엇을 점검해야 하나?

지금까지 다룬 내용을 실전에서 바로 쓸 수 있도록 체크리스트로 정리했다. 새 사이트맵을 올리기 전, 혹은 기존 사이트맵을 점검할 때 이 순서대로 확인하면 된다.

1. 실제 접속 가능한 페이지만 담았는가 — 404나 리다이렉트로 연결되는 죽은 URL은 제외한다.
2. 정규 URL(canonical)만 담았는가 — 같은 내용의 중복 주소 대신 대표 주소만 넣는다.
3. noindex 페이지는 제외했는가 — 검색 노출을 원치 않는 페이지는 사이트맵에도 넣지 않는다.
4. robots.txt와 충돌하지 않는가 — 사이트맵에 넣은 경로를 robots.txt가 막고 있지 않은지 확인한다.
5. lastmod가 정확한가 — 실제 수정일과 다르게 표시되면 오히려 신뢰를 잃는다.
6. URL 50,000개·50MB 한도를 지켰는가 — 넘는다면 사이트맵 인덱스로 나눈다.
7. 서치 콘솔에 제출하고 상태를 확인했는가 — 제출만 하고 끝내지 말고, "성공" 상태까지 확인한다.

이 일곱 가지를 한 번에 완벽히 지키기보다, 정기적으로(예: 분기마다) 다시 점검하는 습관이 더 중요하다. 사이트는 계속 바뀌기 때문에, 사이트맵도 살아 있는 문서처럼 관리해야 한다.

사이트 전반의 기술적 SEO 요소까지 폭넓게 점검하고 싶다면 홈페이지 제작 전 SEO 체크리스트를 함께 참고하면 좋다. 사이트맵은 그 체크리스트의 한 조각일 뿐, 검색 노출을 완성하려면 스키마 마크업(JSON-LD) 같은 다른 요소도 함께 갖춰야 한다.

자주 묻는 질문

사이트맵은 필수인가요?

법적·기술적으로 필수는 아니지만, 만들지 않을 이유가 없다. 특히 새로 만든 사이트나 페이지 수가 많은 사이트라면 효과가 뚜렷하다.

작은 사이트도 사이트맵을 만드는 데 드는 노력은 매우 적은 반면, 얻는 이득(빠른 발견, 누락 방지)은 꾸준하다. 손해 볼 일이 없는 기본 세팅이라고 생각하면 된다.

사이트맵을 제출하면 얼마나 빨리 색인되나요?

정해진 시간은 없다. 사이트맵 제출은 발견을 도울 뿐, 색인 속도를 보장하지는 않는다. 보통 며칠에서 몇 주가 걸리며, 사이트의 신뢰도와 콘텐츠 품질에 따라 차이가 크다.

급하게 특정 페이지를 색인시키고 싶다면, 서치 콘솔의 URL 검사 도구로 개별 페이지 색인을 요청하는 방법도 있다. 다만 이 역시 즉시 반영을 보장하지는 않는다.

사이트맵이 없으면 검색에 아예 안 뜨나요?

아니다. 사이트맵이 없어도 다른 사이트에서 걸어준 링크(백링크)나 내부 링크를 따라 구글이 페이지를 찾아낼 수 있다. 사이트맵은 이 과정을 더 확실하고 빠르게 만들어 주는 보조 수단이다.

다만 새로 만든 사이트처럼 외부 링크가 거의 없는 상태라면, 사이트맵이 없을 때 발견 자체가 크게 늦어질 수 있다.

네이버에도 사이트맵을 제출해야 하나요?

네, 별도로 등록하는 것이 좋다. 네이버는 자체 도구인 네이버 서치어드바이저를 통해 사이트맵을 등록받는다. 구글 서치 콘솔에 제출했다고 네이버에도 자동으로 반영되지는 않는다.

파일 형식(XML)은 동일하게 쓸 수 있으므로, 만들어 둔 사이트맵 하나를 구글과 네이버 양쪽에 각각 등록하면 된다.

robots.txt 없이 사이트맵만 있어도 되나요?

가능은 하지만, 둘 다 갖추는 것이 안전하다. robots.txt에 사이트맵 위치를 적어두지 않아도 서치 콘솔에 직접 제출하면 구글은 사이트맵을 인식한다.

다만 robots.txt는 구글 외의 다른 검색엔진 로봇도 참고하는 표준적인 경로이므로, 위치를 함께 적어두면 더 많은 검색엔진이 자동으로 사이트맵을 찾아갈 수 있다.

사이트맵을 수정하면 다시 제출해야 하나요?

자동 생성 구조라면 다시 제출할 필요가 없다. 파일 내용이 갱신되면 구글이 주기적으로 다시 읽어가기 때문이다. 서치 콘솔에 이미 등록해 둔 사이트맵은 계속 유효하다.

다만 사이트맵 파일 이름 자체를 바꾸거나 새로운 사이트맵을 추가로 만든 경우에는, 그 새 파일을 서치 콘솔에 별도로 제출해야 한다.

priority 값을 낮게 매기면 그 페이지가 검색에서 불리해지나요?

아니다. 앞서 설명했듯 구글은 priority 값 자체를 사실상 사용하지 않는다. 0.1로 낮게 적든 1.0으로 높게 적든, 그 페이지의 실제 검색 노출이나 순위에는 영향을 주지 않는다.

이 값 때문에 불이익을 걱정할 필요는 없다. 페이지의 중요도를 검색엔진에게 인정받고 싶다면, priority 숫자가 아니라 그 페이지로 연결되는 내부 링크의 양과 콘텐츠 자체의 품질을 신경 쓰는 것이 실질적인 방법이다.

사이트맵을 만들었는데 순위가 오르지 않아요. 정상인가요?

정상이다. 이 글 전체에서 반복해 강조했듯, 사이트맵은 발견을 돕는 도구이지 순위를 올려주는 도구가 아니다. 사이트맵을 만든 뒤 기대할 수 있는 변화는 "새 페이지가 더 빨리 발견되는 것"이지 "순위가 저절로 오르는 것"이 아니다.

순위를 실제로 움직이는 요소는 콘텐츠의 품질과 관련성, 사용자 경험, 신뢰를 쌓는 백링크 같은 다른 요인들이다. 사이트맵은 이런 요소들이 검색 결과에 반영될 기회를 놓치지 않도록 돕는 기초 공사에 가깝다고 이해하면 정확하다.

HTML 사이트맵과 XML 사이트맵은 같은 건가요?

다르다. 이 글에서 다룬 XML 사이트맵은 검색엔진 로봇을 위한 것이고, 흔히 웹사이트 하단에 있는 "사이트맵" 링크를 눌러 보이는 페이지는 사람을 위한 HTML 사이트맵이다.

HTML 사이트맵은 사람이 페이지를 찾기 쉽게 만든 안내 페이지로, 부가적으로 내부 링크를 늘리는 효과는 있지만 검색엔진 제출용 사이트맵과는 형식과 목적이 다르다.

사이트맵에 이미 색인된 페이지도 계속 남겨둬야 하나요?

그렇다. 색인이 되었다고 사이트맵에서 빼야 하는 것은 아니다. 사이트맵은 "현재 존재하는 페이지 목록"을 보여주는 것이지, "아직 색인 안 된 페이지만 담는 신청서"가 아니다.

오히려 이미 색인된 페이지를 빼버리면, 다음번에 그 페이지가 수정되었을 때 구글에게 변경 사실을 알릴 통로가 사라진다. 살아 있는 페이지라면 색인 여부와 관계없이 사이트맵에 계속 두는 것이 맞다.

사이트맵을 gzip으로 압축해서 올려도 되나요?

가능하다. sitemap.xml.gz처럼 압축한 형태로 제출해도 구글은 문제없이 읽는다. 앞서 설명한 50MB 한도는 압축 전(비압축) 기준이므로, 압축했다고 해서 더 많은 URL을 담을 수 있는 것은 아니라는 점만 주의하면 된다.

페이지 수가 아주 많아 파일 용량이 큰 사이트라면, 전송 속도를 위해 압축본을 함께 제공하는 것도 방법이다. 다만 소규모 사이트라면 굳이 압축까지 신경 쓸 필요는 없다.

게시글 목록의 2페이지, 3페이지도 사이트맵에 넣어야 하나요?

넣지 않는 것을 권한다. /blog?page=2, /blog?page=3처럼 목록을 여러 쪽으로 나눈 페이지네이션 주소는, 대부분 독립된 콘텐츠라기보다 같은 목록의 다른 조각일 뿐이다.

이런 주소를 사이트맵에 잔뜩 넣으면 정작 중요한 개별 글 페이지의 비중이 상대적으로 흐려진다. 사이트맵에는 실제로 검색 결과에 뜨길 원하는, 콘텐츠 자체가 있는 페이지 위주로 담는 것이 원칙이다.

예전에 쓰던 사이트맵 파일이 남아 있는데 지워도 되나요?

더 이상 쓰지 않는다면 지우는 것이 낫다. 예를 들어 sitemap-old.xml처럼 과거에 만들었다가 방치한 파일이 여전히 서치 콘솔에 등록되어 있다면, 그 안의 오래된 URL이 계속 참고되어 혼란을 줄 수 있다.

서치 콘솔의 Sitemaps 보고서에서 더 이상 쓰지 않는 사이트맵을 목록에서 제거하고, 현재 실제로 갱신되는 사이트맵 하나만 깔끔하게 남겨두는 것이 관리하기에도 편하다.

마무리: 지도 한 장으로 발견을 앞당기자

사이트맵은 복잡한 기술이 아니라, 검색엔진에게 건네는 정직한 지도 한 장이다. 만드는 데 드는 노력은 적지만, 신규 사이트나 대형 사이트일수록 그 효과는 분명하다.

오늘 배운 것을 실행 순서로 정리하면 이렇다.

1. 내도메인.com/sitemap.xml이 실제로 열리는지 확인한다. 없다면 워드프레스 플러그인이나 프레임워크 기능으로 자동 생성부터 갖춘다.
2. robots.txt에 사이트맵 위치를 한 줄 적는다. Sitemap: https://내도메인.com/sitemap.xml 형태로.
3. 구글 서치 콘솔의 Sitemaps 메뉴에서 제출하고, 하루 뒤 상태를 확인한다. "성공"이 뜨는지 반드시 점검한다.
4. 페이지가 많다면 50,000개·50MB 한도를 넘지 않는지 확인하고, 넘으면 사이트맵 인덱스로 나눈다.
5. 분기에 한 번씩 죽은 링크·noindex 페이지가 섞여 있지 않은지 재점검한다.

이 다섯 단계만 지켜도, 새로 올린 콘텐츠가 구글의 눈에 띄지 않아 답답해하는 일이 크게 줄어든다. 사이트맵은 검색 노출이라는 큰 그림의 가장 기초적인 첫 장이다.

특히 사업을 처음 시작해 홈페이지를 새로 여는 단계라면, 사이트맵은 "언젠가 챙기면 되는 일"이 아니라 오픈과 동시에 갖춰야 하는 기본값으로 여기는 것이 맞다. 초반에 발견이 늦어진 시간은 나중에 콘텐츠를 아무리 잘 만들어도 온전히 되돌리기 어렵다.

지금 사이트맵이 없다면, 이 글을 덮기 전에 내도메인.com/sitemap.xml을 주소창에 직접 쳐보는 것부터 시작하길 권한다. 열리지 않는다면 그것이 오늘 가장 먼저 해결해야 할 일이다.

물론 사이트맵 하나로 모든 SEO가 완성되지는 않는다. 사이트맵이 지도라면, 그 지도 위의 각 장소(페이지)가 실제로 좋은 콘텐츠와 구조를 갖추고 있어야 진짜 힘을 발휘한다. 더 넓은 관점에서 검색 노출을 준비하고 싶다면 구글 SEO 상위노출을 위한 온페이지 최적화도 함께 읽어보길 권한다.

이루웹은 SEO를 처음부터 설계에 넣어 홈페이지를 만드는 웹 에이전시입니다. 사이트맵·스키마 마크업·robots.txt 같은 기술적 기본기부터, 콘텐츠 구조와 신뢰를 쌓는 백링크까지 검색에 강한 사이트를 함께 만들어 드리고 있습니다. 직접 관리하기 번거롭거나 우리 사이트가 왜 검색에 잘 안 잡히는지 궁금하시다면 SEO 홈페이지 제작 서비스와 전체 서비스를 살펴보시고, 무료 상담으로 현재 사이트 상태를 진단받아 보시길 권해 드립니다. 손님이 찾아오도록, 지도부터 제대로 그려 드리겠습니다.