생성 전에 포함 기준을 먼저 정하세요
XML 사이트맵은 기계가 읽을 수 있는 URL 목록과 선택적 메타데이터입니다. 크롤러의 익스포트가 아니라 포함 기준(rules)으로 시작하세요: 페이지는 검색을 목적으로 하고 공개적으로 조회 가능하며 그 콘텐츠의 선호 버전(preferred version)일 때만 포함합니다. 퍼시·필터형 카탈로그 URL, 내부 검색 결과, 캠페인 변형, 로그인 목적지, 프리뷰는 의도된 공개 대상이 아닌 한 제외하세요.
검색을 의도한 공개용 유용한 페이지로 하나의 선호 URL이 있는 경우.
리다이렉트, 오류, 중복, noindex 페이지, 비공개 라우트.
발견을 돕는 입력일 뿐, 크롤링이나 색인을 보장하지 않습니다.
접근 가능한 모든 경로가 아니라 대표(canonical) URL을 나열하세요
대표(canonical) URL은 유사한 버전들 가운데 검색엔진이 대표로 취급하길 바라는 버전입니다. 사이트맵 포함은 약한 canonical 신호이므로 리다이렉트, 자기참조(canonical) 태그, 내부 링크와 모순되면 안 됩니다. 하나의 안정적인 HTTPS 형식을 선택해 그 정확한 버전을 발행하세요.
http/https, www/비-www, 슬래시 규칙, 대소문자, 인쇄용 페이지, 필터, 추적 파라미터를 점검하세요. URL이 리다이렉트된다면 최종 canonical 목적지만 나열하세요. 로컬라이즈된 페이지마다 독립적인 대표 URL을 부여하고, 서로 다른 로컬 콘텐츠를 사이트맵으로 병합( collapse )하지 마십시오.
상대 경로가 아니라 스킴과 호스트를 포함한 절대 URL을 작성하세요. Google은 목록에 있는 그대로 URL을 크롤합니다.
사이트맵, canonical 태그, 내부 링크, 리다이렉트 정책이 동일한 페이지를 가리켜야 합니다.
중복을 차단하는 것이 선호 버전을 정립하지 않습니다.
XML은 작고 유효하며 정직하게 만드세요
Sitemap Protocol 구조를 따르세요: UTF-8 인코딩의 XML, urlset과 sitemap 네임스페이스(namespace), 각 URL에 대한 loc 요소를 사용합니다. URL 값에 XML 민감 문자(예: &, <, >)는 이스케이프하세요. 자동화는 문자열 연결으로 XML을 직접 조립하지 말고 직렬화(serialization)를 사용해야 합니다.
각 사이트맵은 최대 50,000개 URL과 비압축 시 50 MB를 초과할 수 없습니다. 이들은 한계(limit)이지 목표(target)가 아닙니다. 상품, 게시물, 로케일, 콘텐츠 유형별로 운영 경계가 유용하면 더 일찍 분할하세요.
lastmod은 페이지의 실제 의미 있는 변경 날짜에만 사용하세요. Google은 일관되고 검증 가능한 경우에 이를 사용합니다; 저작권 연도 업데이트는 해당되지 않습니다. 모든 URL을 생성 시각으로 찍지 마세요. Google은 changefreq와 priority를 무시하므로 생략하세요.
loc는 필수입니다; lastmod는 선택이며 생성 시점이 아니라 페이지를 설명해야 합니다.
Gzip 압축으로 전송 크기를 줄일 수 있지만, 압축을 푼 파일의 비압축 크기는 50 MB를 초과하면 안 됩니다.
XML의 잘형성(well-formedness), 가져오기 가능성(fetchability), 및 나열된 페이지의 동작을 확인하세요.
소유권을 잃지 않고 확장하려면 인덱스를 사용하세요
사이트맵 인덱스는 여러 사이트맵 파일을 나열합니다. 사이트가 단일 파일 한도를 초과하거나 별도의 인벤토리가 필요할 때 사용하세요. 편집, 상품, 헬프센터 소유권별로 그룹화하세요. 인덱스에도 동일한 50,000개 항목 및 50 MB 비압축 한도가 적용됩니다.
하위 파일(child files)은 의도된 사이트에 안정적인 URL로 유지하세요. 프로토콜은 일반적으로 사이트맵의 호스트와 위치에 연결된 URL만 허용하므로 교차 사이트(cross-site) 구성은 소유권 검증이 필요합니다.
테스트 가능한 목적(콘텐츠 유형, 상점, 언어 집합, 배포 경계)으로 분할하세요. 생성기, 소유자, 예상 항목 수를 기록하세요.
대형 사이트는 각 자식 파일을 개별 제출하지 말고 전체 인덱스를 제출하세요.
인덱스의 lastmod는 개별 페이지가 아니라 사이트맵 파일 자체를 설명합니다.
게시·제출·결과 해석을 올바르게 하세요
사이트맵은 루트 근처의 안정적인 공개 HTTPS 주소에 호스팅하고 인증이 필요하지 않게 제공하세요. robots.txt에 절대 URL을 가진 Sitemap 지시문을 추가하세요. Google Search Console과 Bing Webmaster Tools에 사이트맵 또는 인덱스를 제출하면 처리 상세를 확인할 수 있습니다.
Search Console에서 Success(성공)는 사이트맵을 오류 없이 가져와 읽었다는 의미입니다. Has errors(오류 있음)는 읽었지만 오류가 포함된 경우이고 Couldn’t fetch(가져오지 못함)는 사용할 수 없음을 의미합니다. 전달, 인증, DNS, robots, 리다이렉트, XML 문제를 수정하고 재제출하세요.
검색엔진이 발견한 페이지 수는 진단용 입력이지 점수가 아닙니다. 발견된 페이지가 곧바로 크롤되거나 색인되는 것은 아닙니다. 샘플 URL을 canonical URL, 응답, 색인 보고서와 대조하세요.
robots.txt는 발견을 돕고 도구 제출은 처리 보고서를 노출합니다.
Search Console은 보고서나 API로 제출된 파일을 표시하며 robots.txt에서의 모든 발견을 나열하지는 않습니다.
사이트맵을 릴리스 중요 인프라로 운영하세요
CMS 플러그인 변경, 배포로 인한 canonical 호스트 변경, 캐시 규칙이 오래된 출력 제공, 대량 작업이 불완전한 페이지를 발행할 때 사이트맵 품질이 악화될 수 있습니다. 사이트맵 검사를 사전 릴리스와 롤백 절차의 일부로 만드세요. 전체 인벤토리를 빈 파일이나 잘못된 파일로 조용히 대체하지 마십시오.
이전의 정상 작동 사이트맵을 보관하고, 예상치 못한 항목 수 변경을 플래그하며 공개 전에 추가/삭제 샘플을 확인하세요. 경로가 변경되면 리다이렉트, canonical 태그, 내부 링크, 사이트맵을 하나의 변경 세트로 조정하세요. 이는 사전적 가동시간 최적화입니다: 크롤러와 방문자가 깨진 경로를 찾기 전에 공개 가능 표면을 보호하세요.
잘못된, 비어 있는, 호스트가 틀린, 또는 비정상적 canonical 사이트맵 출력에 대해서는 게시를 일시 중단하세요.
이전 아티팩트와 생성기 구성(generator configuration)을 롤백할 수 있도록 준비하세요.