XML 사이트맵에는 어떤 URL을 넣고 빼야 할까요? 표준 URL·noindex·리디렉션 기준

사이트맵을 만드는 방법은 플러그인이나 생성기로 금방 해결됩니다. 어려운 것은 그 안에 어떤 주소를 남길지 정하는 일입니다. 이 글은 Google과 네이버 공식 문서를 기준으로 넣을 URL과 뺄 URL을 나눕니다. 넥스트티 사이트맵 1,419개 주소를 직접 점검한 결과도 함께 싣습니다. 사이트맵의 정의와 형식은 XML 사이트맵 용어 설명에서 먼저 볼 수 있습니다.

사이트맵에는 어떤 URL을 넣어야 하나요?

기준은 한 문장입니다. 검색결과에 보이기를 원하는 주소만 넣습니다.

Google 사이트맵 제작 문서는 검색결과에 표시하려는 URL을 넣으라고 안내합니다. Google은 보통 검색결과에 표준 URL을 보여 줍니다. 사이트맵은 이 표준 URL 선택에 영향을 줄 수 있습니다. 그래서 사이트맵의 주소 목록은 곧 「이 주소를 대표로 봐 달라」는 제안이 됩니다.

사이트맵에 넣었다고 모두 색인되지는 않습니다. 사이트맵 개요 문서는 모든 항목의 크롤링과 색인을 보장하지 않는다고 밝힙니다. 사이트맵은 중요한 페이지를 알려 주는 수단이지, 색인을 정하는 장치가 아닙니다.

사이트맵과 canonical이 다르면 어떻게 되나요?

Google은 대표 주소를 정하는 신호를 세 가지로 설명합니다. 강한 것부터 리디렉션, rel="canonical", 사이트맵 포함입니다.

사이트맵은 가장 약한 신호입니다. 그래서 사이트맵만 고쳐서는 대표 주소를 바꾸기 어렵습니다. 반대로 사이트맵이 다른 신호와 어긋나면 Google이 받는 신호가 엇갈립니다.

Google 문서는 이런 혼선을 직접 금지합니다. 한 페이지에 사이트맵은 A 주소, canonical은 B 주소로 지정하지 말라는 것입니다. 세 신호는 모두 같은 주소로 맞춥니다.

주소 끝 슬래시 하나가 달라도 다른 주소입니다. 넥스트티는 메뉴 링크와 사이트맵의 슬래시 형태가 섞인 문제를 끝 슬래시 정리 기록에 남겼습니다.

noindex 페이지는 사이트맵에서 빼야 하나요?

noindex 페이지는 빼는 것이 맞습니다. 검색결과에 표시하지 않기로 한 주소이기 때문입니다.

사이트맵에 넣으면 「검색결과에 보여 달라」는 제안이 됩니다. noindex는 「검색결과에서 빼 달라」는 규칙입니다. 두 신호가 정반대이므로 한쪽을 정리해야 합니다.

Google noindex 문서에는 주의할 점이 하나 더 있습니다. noindex가 작동하려면 크롤러가 그 페이지에 접근할 수 있어야 합니다. robots.txt로 막으면 크롤러가 noindex를 확인하지 못합니다. 이 경우 다른 페이지의 링크로 검색결과에 계속 보일 수 있습니다.

사이트 내 검색결과나 태그 목록이 대표적인 예입니다. 어떤 목록에 noindex를 넣을지는 검색결과·태그 페이지 noindex 판단에서 다룹니다.

리디렉션된 URL은 어떻게 처리하나요?

리디렉션 출발 주소는 빼고, 도착 주소를 넣습니다. 영구 리디렉션의 도착 주소가 표준이 되기 때문입니다.

Google 리디렉션 문서는 영구 리디렉션을 도착 주소가 표준이라는 신호로 봅니다. 301과 308이 여기에 해당합니다. 임시 리디렉션인 302·303·307은 이 신호로 쓰지 않는다고 설명합니다.

임시 리디렉션은 판단이 조금 다릅니다. 임시 이동은 검색결과에 출발 주소를 보여 줍니다. 곧 원래 주소로 돌아올 예정이라면 출발 주소를 그대로 두는 편이 자연스럽습니다.

HTTPS를 쓰는 사이트라면 HTTP 주소를 넣지 않습니다. Google 표준 URL 문서가 이를 명시합니다. 삭제한 페이지의 상태 코드 선택은 삭제 페이지 404·410·301 처리를 참고하세요.

사이트맵 형식에서 지킬 규칙은 무엇인가요?

주소 선택 외에 형식 규칙도 있습니다. 대부분 Google 「사이트맵 제작 및 제출하기」 문서에 나옵니다.

상한을 넘으면 사이트맵을 여러 개로 나눠야 합니다. 나눈 파일은 사이트맵 색인 파일로 묶어 하나만 제출할 수도 있습니다. 색인 파일이 가리키는 사이트맵은 같은 사이트에 있어야 합니다. 같은 디렉터리나 그 하위 디렉터리에 둡니다.

lastmod는 페이지에 중요한 변경이 있었던 날짜를 적습니다. 본문, 구조화 데이터, 링크가 바뀐 경우가 중요한 변경입니다. 저작권 연도만 바꾼 것은 해당하지 않습니다. Google은 이 값이 일관되고 검증 가능할 때 씁니다.

우리 사이트맵은 어떻게 점검하나요?

주소 목록을 뽑아 상태 코드, canonical, 제외 규칙 순서로 대조합니다. 마지막으로 Search Console 보고서를 봅니다. 넥스트티는 2026년 10월 28일 이 순서로 자사 사이트맵을 점검했습니다. 넣지 말아야 할 주소는 나오지 않았습니다.

사이트맵에 든 주소는 1,419개였습니다. 모든 주소를 하나씩 요청해 상태 코드, canonical, noindex를 확인했습니다. 결과는 아래와 같습니다.

남은 과제도 하나 보였습니다. 사이트맵에 priority와 changefreq 값이 들어 있었습니다. Google은 이 값을 무시하므로 지금 고칠 문제는 아닙니다. 다만 lastmod 값이 실제 변경일과 맞는지는 따로 확인해야 합니다.

참고 자료

• Google 검색 센터 — 사이트맵 제작 및 제출하기
• Google 검색 센터 — 사이트맵 알아보기
• Google 검색 센터 — 사이트맵 색인 파일로 사이트맵 관리
• Google 검색 센터 — rel="canonical" 및 다른 메서드로 표준 URL을 지정하는 방법
• Google 검색 센터 — noindex로 검색 색인 생성 차단하기
• Google 검색 센터 — 리디렉션 및 Google 검색
• Google Search Console 고객센터 — 사이트맵 보고서를 사용하여 사이트맵 관리하기
• 네이버 서치어드바이저 — 웹 사이트를 만들 때
• 네이버 서치어드바이저 — 검색엔진 최적화의 목적