결론부터 말씀드리겠습니다. XML 사이트맵의 priority 필드는 검색 순위에 아무런 영향을 주지 않습니다. Google도 이 필드를 읽지 않는다고 공식적으로 밝혔습니다. changefreq 역시 마찬가지입니다. 실제로 읽히며 AI 크롤러의 수집 효율에 직접 영향을 주는 필드는 lastmod뿐입니다. 사이트맵을 생성할 때마다 모든 URL의 lastmod를 당일로 바꾼다면 크롤러를 돕는 것이 아닙니다. 오히려 이 목록을 신뢰하지 않도록 학습시키는 셈입니다. 이 글에서는 XML 사이트맵을 크롤러가 신뢰할 수 있는 변경 내역으로 만드는 방법을 설명합니다. GPTBot, ClaudeBot, PerplexityBot이 최소한의 크롤링으로 최신 페이지를 수집하도록 하는 것이 목표입니다.
사이트맵의 역할은 순위 상승이 아니라 크롤링과 색인의 효율을 높이는 것입니다
사이트맵을 만든다고 특정 페이지의 검색 순위가 올라가지는 않습니다. 사이트맵은 “이 URL들이 존재하며, 이 중 일부가 최근 변경됐다”는 사실을 알려주는 목록입니다. 페이지가 수백 개 미만이고 내부 링크가 잘 정리된 소규모 사이트라면 사이트맵 유무에 따른 차이는 크지 않습니다. Google이 한 번의 크롤링만으로도 모든 페이지를 찾을 수 있기 때문입니다. 사이트맵의 가치가 커지는 경우는 명확합니다. 사이트 규모가 크거나, 내부 링크로 연결되지 않은 깊은 페이지와 고립 페이지가 있거나, 콘텐츠가 자주 업데이트되거나, 특정 변경 사항을 크롤러가 최대한 빨리 발견해야 할 때입니다. AI 크롤러는 Google보다 크롤링 예산이 적고 URL을 제출할 Search Console 같은 백엔드도 없습니다. 따라서 이들이 활용할 수 있는 탐색 신호는 생각보다 훨씬 제한적입니다.
lastmod: 여전히 읽히지만 가장 쉽게 잘못 설정되는 필드
Google의 원칙은 일관됩니다. lastmod를 참고하되, 그 값이 정확할 때만 신뢰합니다. 사이트맵을 다시 생성할 때마다 사이트 전체의 lastmod가 당일로 바뀐다는 사실을 시스템이 감지하면 이 필드의 신뢰도는 사실상 0으로 떨어집니다. 이후 중요한 콘텐츠를 실제로 수정해도 변경 신호가 제대로 전달되지 않습니다. 따라서 lastmod에는 템플릿 수정이나 사이트 전체 재배포 시점이 아니라 콘텐츠가 실질적으로 변경된 시점을 기록해야 합니다. 이 기준에서 보면 대다수 CMS의 기본 설정은 잘못돼 있습니다.
- 시간대가 포함된 W3C Datetime 형식을 사용합니다. 날짜만 적지 말고 2026-07-02T14:30:00+08:00처럼 작성합니다.
- 콘텐츠가 실질적으로 변경됐을 때만 값을 갱신합니다. 오탈자 수정, 장식용 이미지 교체, 미세한 CSS 조정은 해당하지 않습니다.
- 사이트 빌드 시간이나 데이터베이스의 updated_at 값을 lastmod에 그대로 사용하지 않습니다. 그렇게 하면 배포할 때마다 사이트 전체가 업데이트됐다는 잘못된 신호를 보내게 됩니다.
- 사이트맵 인덱스에 포함된 각 하위 파일에도 자체 lastmod를 지정해야 합니다. 해당 그룹에서 마지막으로 실질적인 변경이 발생한 시점을 기록합니다.
- 기술적으로 정확한 lastmod를 제공할 수 없다면 매일 사이트 전체를 “오늘”로 표시하는 것보다 필드 자체를 비워 두는 편이 낫습니다.
priority와 changefreq: 입력해도 아무도 참고하지 않는 필드
Google 엔지니어들은 공식 석상에서 priority와 changefreq를 전혀 고려하지 않는다고 명확히 밝혔습니다. Bing도 입장이 비슷합니다. CMS가 이 두 필드를 자동으로 채운다면 그대로 두어도 괜찮습니다. 다만 어떤 페이지에 0.8을 주고 어떤 페이지에 0.6을 줄지 엔지니어의 시간을 들여 고민할 필요는 없습니다. 이 숫자는 크롤링이나 검색 순위 결과를 바꾸지 않습니다. priority가 굳이 도움이 되는 지점이 있다면 팀 내부에서 어떤 페이지가 가장 중요한지 정리하게 만든다는 정도입니다. 알고리즘이 아니라 운영팀을 위한 값인 셈입니다.
AI 크롤러는 사이트맵을 어떻게 찾고 활용할까요?
GPTBot, ClaudeBot, PerplexityBot, CCBot, Google-Extended 같은 AI 크롤러에는 URL을 제출할 수 있는 Search Console이 없습니다. 가장 안정적인 사이트맵 탐색 경로는 robots.txt의 Sitemap 지시문입니다. 이 줄이 없으면 크롤러가 링크를 따라 유입되기를 기다릴 수밖에 없습니다. 사이트맵을 선언하고 정확한 lastmod를 제공하면 크롤러는 변경되지 않은 페이지를 건너뛰고 제한된 크롤링 횟수를 새 콘텐츠에 집중할 수 있습니다. 이것이 바로 원하는 결과입니다. GEO의 목표는 서버에 크롤러를 많이 유입시키는 것이 아니라 콘텐츠가 인용되도록 만드는 것이기 때문입니다.
대규모 사이트의 색인 효율을 높이는 사이트맵 분할 방법
사이트맵 파일 하나에는 명확한 상한이 있습니다. URL은 최대 50,000개, 압축 전 파일 크기는 최대 50MB이며 둘 중 하나라도 먼저 도달하면 제한이 적용됩니다. 한도를 넘으면 파일을 분할한 뒤 사이트맵 인덱스로 통합해야 합니다. 인덱스 하나에는 최대 50,000개의 하위 사이트맵을 담을 수 있습니다. 실무에서는 파일이 한도에 도달한 뒤 나누기보다 처음부터 콘텐츠 유형별로 분류하는 편이 좋습니다. 그러면 Search Console에서 그룹별 색인 범위를 확인할 수 있어 어떤 콘텐츠 그룹에 색인 문제가 있는지 한눈에 파악할 수 있습니다.
- 콘텐츠 유형별로 그룹을 나눕니다. sitemap-blog.xml, sitemap-docs.xml, sitemap-product.xml처럼 구성하면 각 그룹의 색인 범위를 독립적으로 확인할 수 있습니다.
- 파일 하나당 URL 50,000개 또는 압축 전 50MB라는 상한을 지킵니다. 한도를 넘으면 분할한 뒤 사이트맵 인덱스로 통합합니다.
- 대용량 파일은 gzip으로 압축해 sitemap.xml.gz로 제공합니다. 프로토콜에서 허용하는 방식이며 대역폭도 절감할 수 있습니다.
- 가격, 비교, FAQ, 사례처럼 AI에 인용될 가능성이 높은 고가치 페이지는 별도로 묶어 관리합니다. 이 페이지들은 자주 업데이트되는 만큼 lastmod도 가장 정확하게 유지해야 합니다.
- noindex가 적용된 URL, canonical이 다른 페이지를 가리키는 URL, 4xx/5xx를 반환하는 URL은 포함하지 않습니다. 이런 URL이 섞이면 목록 전체의 신뢰도가 낮아집니다.
핑 전송은 중단: 2023년 이후 변경 알림을 보내는 방법
Google은 2023년에 사이트맵 ping 엔드포인트를 중단했고 Bing도 뒤따랐습니다. 이제 /ping?sitemap=으로 요청을 보내도 아무 효과가 없습니다. 대안은 세 단계로 정리할 수 있습니다. 먼저 정확한 lastmod를 유지해 크롤러가 자체 주기에 따라 다시 방문했을 때 재수집 여부를 판단하게 합니다. 사이트맵은 Search Console에 한 번만 제출하고 반복 전송하지 않습니다. Bing과 Yandex에는 IndexNow를 사용해 URL 단위의 변경 알림을 실시간으로 보냅니다. 단, Google은 IndexNow를 지원하지 않으며 대부분의 AI 크롤러도 자체 재방문 일정과 lastmod에 의존합니다. 결국 모든 크롤러에 동시에 영향을 미치는 핵심 수단은 lastmod를 정확하게 관리하는 운영 원칙입니다.
사이트 공개 전 사이트맵 체크리스트
- robots.txt에 공개적으로 접근 가능한 사이트맵 URL을 가리키는 Sitemap 지시문이 있습니다.
- lastmod가 실제 콘텐츠 변경 시점을 반영하고 시간대까지 포함한 형식으로 작성돼 있습니다. 사이트 전체가 같은 날짜로 표시되지 않습니다.
- 사이트맵에는 HTTP 200 응답을 반환하며 색인 가능한 페이지만 포함돼 있습니다. noindex 및 다른 페이지를 canonical로 지정한 URL은 제외합니다.
- 파일 하나가 URL 50,000개 또는 50MB를 넘지 않습니다. 대규모 사이트는 사이트맵 인덱스를 사용해 콘텐츠 유형별로 분류합니다.
- Search Console에 한 번만 제출하고 “발견됨”으로 표시된 URL 수가 실제 페이지 수와 일치하는지 확인합니다.
이 항목들을 정확히 설정하면 사이트맵은 아무도 신뢰하지 않는 형식적인 파일에서 크롤러와 AI 엔진이 활용할 수 있는 변경 정보로 바뀝니다. 대부분의 팀이 겪는 문제는 페이지 누락이 아닙니다. 사이트 전체의 lastmod가 부정확하고 색인할 수 없는 URL이 사이트맵에 뒤섞여 있다는 점입니다. 외부 도구로 사이트맵을 스캔하면 이런 문제를 확인할 수 있습니다. 사이트맵과 전반적인 테크니컬 AEO 설정에서 무엇이 빠졌는지 알고 싶다면 30분 GEO 진단(/contact)을 예약해 주세요. 우선 수정해야 할 핵심 항목을 바로 짚어드립니다.
