changefreq·priority, 구글은 사실 무시한다
사이트맵 최적화 체크리스트를 보면 여전히 "모든 <url>에 changefreq와 priority를 꼼꼼히 채워라"는 조언이 남아 있습니다. 하지만 이 두 태그는 사이트맵 프로토콜(sitemaps.org) 스펙에는 지금도 정식으로 존재하지만, 구글이 실제 크롤링 우선순위 결정에 사용하는 신호는 아닙니다. 이 가이드는 왜 그렇게 됐는지, 그리고 사이트맵 검증기가 이 태그들을 어떻게 다루는지 정리합니다.
1. changefreq·priority는 원래 무엇을 위한 태그였나
사이트맵 프로토콜 초기 설계(2005년경, 구글·야후·마이크로소프트 공동 제정)에서 <changefreq>는 "이 페이지가 얼마나 자주 바뀌는지"(always/hourly/daily/weekly/monthly/yearly/never)를, <priority>는 "같은 사이트 내 다른 URL 대비 상대적 중요도"(0.0~1.0)를 검색엔진에 알려주기 위한 값이었습니다. 아이디어 자체는 합리적이었습니다 — 매일 바뀌는 뉴스 페이지와 1년에 한 번 바뀌는 회사소개 페이지를 같은 빈도로 재크롤링할 필요는 없으니까요.
2. 왜 신뢰할 수 없는 신호가 됐는가
문제는 이 값을 사이트 운영자가 직접 써넣는다는 점이었습니다. 실제로는 거의 모든 사이트가 자기 사이트의 중요 페이지에 priority 1.0을, 나머지에도 최소 0.8 이상을 매기는 식으로 값을 부풀렸습니다. changefreq도 실제 갱신 빈도와 무관하게 관행적으로 daily를 넣는 사례가 흔했습니다. 자기 신고 데이터가 전부 "나는 중요하고 자주 바뀐다"로 수렴해버리면, 상대적 우선순위를 가려낼 신호로서 가치를 잃습니다. 구글은 2014년경부터 이 두 값을 크롤링 우선순위 산정에 실질적으로 반영하지 않는다고 공식적으로 밝혀왔고, 이후에도 이 입장을 여러 차례 재확인했습니다.
3. 그럼 구글은 크롤링 우선순위를 뭘로 정하나
구글이 실질적으로 참고하는 신호는 changefreq/priority가 아니라 다음과 같은 것들입니다.
- lastmod의 정확성: 실제 콘텐츠 수정 시각과 일치하는
<lastmod>는 재크롤링 시점 판단에 실질적으로 쓰입니다. 매번 오늘 날짜로 갱신하는 식으로 조작하면 오히려 신뢰도가 떨어집니다. - 내부 링크 구조: 사이트 내에서 얼마나 많은 곳에서 링크되는지가 실제 중요도 판단에 훨씬 크게 작용합니다.
- 페이지 자체의 인기·트래픽 신호: 실제 방문·검색 노출 데이터가 자기 신고 값보다 신뢰할 수 있는 신호입니다.
4. 그렇다고 사이트맵을 대충 만들어도 될까
아닙니다. changefreq·priority는 무시되지만 사이트맵 자체의 구조적 제약은 여전히 실질적으로 작동합니다. 가장 중요한 두 가지는 다음과 같습니다.
| 제약 | 기준 | 초과 시 |
|---|---|---|
| URL 개수 | 파일 1개당 최대 50,000개 | 사이트맵 인덱스(<sitemapindex>)로 분할 필요 |
| 파일 크기 | 압축 전 50MB 이내 | 여러 파일로 나눠 인덱스로 묶어야 함 |
예를 들어 상품 페이지가 12만 개인 이커머스 사이트라면, 하나의 sitemap.xml에 전부 넣을 수 없고 3개 이상의 파일로 나눈 뒤 sitemap-index.xml이 이들을 묶어 Search Console에 그 인덱스 파일 하나만 제출하는 구조를 써야 합니다. 이건 자기 신고 값과 달리 검증 가능한 하드 리밋이라 실제로 지켜지지 않으면 파싱 자체가 실패하거나 일부 URL이 누락됩니다.
5. modoohub 사이트맵 검증기는 이 사실을 어떻게 반영하는가
사이트맵 검증기의 sitemap-validator.html 코드를 확인하면, parseSitemap() 함수가 total>50000일 때만 실제 error 등급 이슈(errOver50k)를 발생시킵니다. 반면 changefreq·priority 값 자체는 URL 목록 테이블에 그대로 표시만 될 뿐, 값의 적절성을 채점하거나 경고를 내는 검사 로직이 없습니다. 대신 FAQ 섹션에 "changefreq와 priority는 효과가 있나요?"라는 질문을 명시적으로 넣어 "Google은 changefreq와 priority를 무시하거나 힌트로만 사용합니다. 크롤링 빈도는 Google이 자체적으로 결정합니다. 정확한 lastmod가 더 중요합니다"라고 안내합니다. 즉 도구 설계 자체가 "형식 유효성만 확인하고, 실질적으로 중요한 것은 lastmod와 URL 개수 제한"이라는 원칙을 그대로 반영하고 있습니다.
6. 사이트맵 작업 시 실전 우선순위
- lastmod를 실제 수정일에 맞춰 정확히 채운다 (임의로 오늘 날짜를 넣지 않는다).
- canonical URL만 포함하고 noindex·리디렉션 URL은 제외한다.
- 50,000개/50MB 제한을 넘으면 인덱스 파일로 분할한다.
- changefreq·priority는 스펙 위반이 아니니 넣어도 무방하지만, 값을 정교하게 튜닝하는 데 시간을 쓸 필요는 없다.
자주 묻는 질문
Q. changefreq·priority를 아예 빼도 되나요?
네. 사이트맵 프로토콜에서 이 두 태그는 선택 사항입니다. 구글이 크롤링 우선순위에 반영하지 않으므로 빼도 SEO상 손해는 없습니다.
Q. 다른 검색엔진(Bing 등)도 이 값을 무시하나요?
검색엔진마다 정책이 다를 수 있어 일괄적으로 단언하기는 어렵지만, 구글이 시장 점유율상 가장 큰 비중을 차지하므로 구글 기준으로 우선순위를 정하는 것이 실무적으로 합리적입니다.
Q. lastmod는 정말 효과가 있나요?
네. 실제 콘텐츠 수정 시각과 일치하는 lastmod는 구글이 재크롤링 시점을 판단하는 데 참고하는 신호로 알려져 있습니다. 다만 무조건 최신 날짜로 넣는다고 유리해지는 건 아니며, 실제 수정과 무관하게 남발하면 오히려 신뢰도가 떨어집니다.
Q. URL이 50,000개를 넘으면 사이트맵 제출 자체가 막히나요?
파일 하나가 제한을 넘으면 파싱이 실패하거나 초과분이 무시될 수 있습니다. 이 경우 여러 사이트맵 파일로 나누고 sitemapindex 파일 하나로 묶어 그 인덱스 파일만 Search Console에 제출하면 됩니다.