콘텐츠로 건너뛰기

🗺️ sitemap.xml 생성기

URL 리스트를 1행 1 URL로 입력하여 sitemap.xml 생성. lastmod / changefreq / priority, hreflang 다국어, 이미지·동영상 확장 지원.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

🔒 개인정보 보호

0 URL

일괄 기본값

hreflang 다국어 (선택)

「lang: URL접두사」 형식으로 1행 1 개.

📄 sitemap.xml


    

📖 자주 걸리는 지점

URL 목록에서 sitemap.xml 을 생성합니다. lastmod · changefreq · priority 의 일괄 지정, hreflang 에 의한 다언어판의 기술, 이미지와 동영상의 확장에 대응하며 처리는 브라우저 안에서 끝납니다. 사이트맵은 인덱스 등록을 보증하는 것이 아닙니다이 페이지가 존재한다고 전할 뿐이며 실을지 여부는 검색 엔진이 내용을 보고 판단합니다. 이 전제를 놓치면 효과 없는 작업에 시간을 쓰게 됩니다.

사례 무슨 일이 일어나는가 어떻게 하면 되는가
사이트맵에 넣었는데 인덱스되지 않는다 사이트맵은 발견을 돕는 것이지 등록을 약속하는 것이 아닙니다. 내용이 얕거나 다른 페이지와 중복되거나 템플릿에서 생성했을 뿐인 페이지는 사이트맵에 들어 있어도 등록되지 않습니다. 나아가 역효과가 되는 경우도 있습니다 — noindex 인 페이지, canonical 이 다른 페이지를 가리키는 페이지, 리다이렉트하는 URL, 404 가 되는 URL 을 사이트맵에 실으면 신호가 모순됩니다. 검색 엔진에서 보면 등록해 달라고 하면서 등록하지 말라고도 하는 상태이며 사이트맵 전체의 신뢰도가 떨어집니다. 사이트맵에 실을 것은 인덱스시키고 싶은 페이지만으로 하세요 — 이는 단순한 규칙이지만 자동 생성하고 있는 사이트에서는 지켜지지 않는 경우가 많습니다(전 페이지를 기계적으로 열거해 버리기 때문). 등록되지 않는 이유는 Search Console 의 페이지 리포트에서 확인할 수 있습니다 — 발견됨 - 색인 생성되지 않음 은 크롤조차 되지 않았다(우선도가 낮다고 판단되었다), 크롤링됨 - 색인 생성되지 않음 은 읽은 뒤에 실을 가치가 없다고 판단되었다는 의미이며 취해야 할 대책이 완전히 다릅니다. 전자는 링크 구조의 문제, 후자는 내용의 문제입니다. 이 둘을 구별하지 않고 사이트맵을 재전송하는 것은 어느 쪽에도 듣지 않습니다.
priority 와 changefreq 설정에 시간을 쓴다 Google 은 prioritychangefreq 를 거의 무시한다고 공식적으로 표명하고 있습니다. 이유는 명백해서 사이트 운영자의 자기 신고이므로 전 페이지를 1.0 · daily 로 하는 사이트가 대량으로 존재해 정보로서 기능하지 않게 되었기 때문입니다. 애초에 priority사이트 내에서의 상대적인 중요도를 나타내는 것이므로 전부 같은 값이면 아무것도 전하지 않습니다. 한편 lastmod 는 지금도 참조됩니다이것도 전 페이지가 오늘 날짜로 되어 있으면 믿지 않게 됩니다 — 정적 사이트 생성기의 기본 설정으로 빌드 일시가 전 페이지의 lastmod 로 되어 있는 사이트가 대단히 많습니다. prioritychangefreq 는 생략해도 상관없습니다 — 쓰지 않는 것에 의한 불이익은 없습니다. 시간을 써야 할 것은 lastmod 를 실제 갱신 일시로 하는 것입니다 — 데이터베이스의 updated_at 이나 Git 의 그 파일의 최종 커밋 일시를 쓰세요. 이것이 정확하면 갱신한 페이지를 검색 엔진이 빠르게 재크롤합니다 — 사이트맵에서 실제로 듣는 몇 안 되는 요소 중 하나입니다. 반대로 내용을 바꾸지 않았는데 lastmod 만 갱신하는 것은 그만두세요 — 일시적으로 크롤을 유발할 수 있어도 갱신했다고 하면서 바뀌지 않은 것이 계속되면 그 신고 자체가 신용되지 않게 됩니다.
50,000 URL / 50MB 의 상한을 넘는다 1 파일당 50,000 URL, 비압축으로 50MB 가 상한이며 Google 과 Bing 에서 공통입니다. 넘은 경우 초과분이 무시되는 것이 아니라 파일 전체가 에러가 됩니다 — 즉 50,001 번째 URL 을 더한 순간에 그때까지 기능하고 있던 50,000 건도 닿지 않게 됩니다. 전자상거래 사이트나 미디어 사이트에서는 상품이나 아카이브가 계속 늘어나므로 어느 날 갑자기 이 선을 넘습니다. 그리고 Search Console 에 에러가 나올 때까지 알아채지 못하는 것이 까다로운 점입니다 — 사이트맵은 일상적으로 보는 것이 아니기 때문입니다. 사이트맵 인덱스로 분할하세요<sitemapindex> 안에 복수의 <sitemap> 을 열거하는 형식으로 인덱스 자체도 50,000 건까지 가질 수 있으므로 실질 25 억 URL 까지 다룰 수 있습니다. 분할의 단위는 갱신 빈도로 나누면 효율이 좋습니다 — 빈번히 바뀌는 페이지(신착 기사 · 재고)만을 작은 한 파일로 모으고 거의 바뀌지 않는 아카이브는 별도 파일로 하면 크롤러는 전자를 빈번히, 후자를 드물게만 보러 오게 되어 크롤 예산이 유효하게 쓰입니다. 상한에 가까워지면 분할하는 것이 아니라 처음부터 분할해 두세요 — 나중에 구성을 바꾸면 일시적으로 전 URL 의 재발견이 필요해집니다.

사이트맵은 robots.txtSitemap: https://example.com/sitemap.xml 한 줄을 쓰는 것만으로 발견됩니다 — Search Console 로의 등록은 필수가 아니지만 에러와 등록 건수가 보이므로 등록을 권장합니다. 쓰는 URL 에는 제약이 있어 절대 URL 일 것, 그리고 사이트맵 자신과 같은 호스트 · 같은 프로토콜일 것이 필요합니다(다른 도메인의 URL 을 포함하려면 Search Console 에서의 소유권 확인이 필요합니다). 그리고 사이트맵은 한 번 만들면 끝이 아닙니다삭제한 페이지의 URL 이 남아 있으면 404 가 늘어서고 Search Console 에 경고가 계속 나옵니다. 이 사이트 자신도 2026 년 7 월에 포르투갈어와 독일어판을 폐지했을 때 사이트맵을 2,016 URL 에서 1,440 URL 로 정리했습니다. URL 을 지울 때는 301 리다이렉트의 설정과 사이트맵에서의 삭제를 같은 작업으로 다루세요 — 한쪽만 하면 반드시 모순이 남습니다.

📖 사용법

  1. 1
    URL 붙여넣기
    한 줄에 하나의 URL.
  2. 2
    옵션 설정
    필요에 따라 lastmod 등 설정.
  3. 3
    다운로드
    사이트 루트에 배치 후 Search Console에 제출.

❓ 자주 묻는 질문

파일당 상한?
Google/Bing 모두 50,000 URL · 50MB. 초과 시 sitemap index 사용.
priority가 SEO에 영향?
Google는 priority/changefreq 무시. lastmod 중시.
hreflang을 sitemap에?
예. 대규모 사이트에서 sitemap 권장.
🐛 이 도구에서 문제가 발생했나요?

무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.

※ 재현을 위해 브라우저 정보 (UA / 화면 / 언어 / URL) 가 자동 전송됩니다