병원 홈페이지 칼럼이 늘어날 때, 사이트맵은 URL 수와 용량을 함께 봅니다

칼럼이 많아지면 사이트맵 파일 하나에 모든 주소를 넣는 방식이 한계에 닿을 수 있습니다. URL 개수와 압축을 풀었을 때의 파일 용량을 함께 확인하고, 필요한 만큼 나누어 관리해야 합니다. 파일을 제출했다는 사실과 모든 글이 검색에 색인됐다는 사실도 구분해야 합니다.

단일 사이트맵에는 두 가지 제한이 있습니다

Google 공식 안내는 사이트맵 한 파일의 한도를 압축 해제 기준 50MB 또는 URL 50,000개로 설명합니다. 둘 중 하나를 넘으면 여러 파일로 나누어야 합니다. gzip 파일의 저장 용량만 작다고 조건을 충족하는 것은 아닙니다. Google 사이트맵 작성 안내

문자열 길이와 추가 정보가 달라지면 같은 URL 개수라도 파일 크기가 달라집니다. 따라서 생성 과정에서 URL 수와 실제 비압축 크기를 각각 검사하는 편이 좋습니다. 새 글을 더한 뒤에도 제한이 유지되는지 확인해야 합니다.

분할된 파일을 목록으로 묶는 사이트맵 색인 파일도 사용할 수 있습니다. 이것은 칼럼의 주소를 직접 나열하는 파일과 다른 역할입니다. 사이트맵 색인 파일 관리

칼럼 주소 10만 개를 담는 가정 계산

공개하려는 고유 칼럼 URL이 정확히 100,000개 있다고 가정하겠습니다. URL 수만 보면 100,000 ÷ 50,000 = 2이므로 최소 2개 파일이 필요합니다. 여기에 홈이나 주제 페이지를 같은 묶음에 더한다면 전체 URL 수로 다시 계산해야 합니다.

이 계산만으로 파일 두 개면 충분하다고 확정할 수는 없습니다. 어느 파일이든 압축을 풀었을 때 용량 한도를 넘으면 더 나누어야 하기 때문입니다. 글 수와 사이트맵 URL 수가 늘 같다는 가정도 피해야 합니다. 중복 주소나 제외 대상이 섞여 있을 수 있습니다.

위 10만 개는 분할 설명을 위한 가정이며 현재 이 사이트에 그만큼의 칼럼이 있다는 뜻이 아닙니다. 실제 운영 집계는 저장된 원고 수, 공개 URL 수, 사이트맵에 들어간 고유 URL 수를 각각 확인해야 합니다.

대표 주소와 정상 페이지를 먼저 정리합니다

사이트맵에는 검색 결과에 표시하려는 대표 URL을 넣습니다. 같은 칼럼의 운영 주소와 검수 주소를 모두 넣어 수를 늘리는 것은 콘텐츠 확장이 아닙니다. 주소는 완전한 절대 URL로 기록하고 실제 목적지가 맞는지 확인합니다.

삭제된 글이나 다른 주소로 통합된 글이 남아 있지 않은지도 봅니다. 다만 응답 코드만 200이라고 충분한 것은 아닙니다. 실제 칼럼 본문이 나오는지와 대표 URL 지정이 일관되는지도 함께 확인합니다. 출처 링크 점검에서 다룬 응답과 내용의 차이는 내부 URL 점검에도 참고할 수 있습니다.

수정일을 넣는다면 실제 중요한 변경 시점과 맞춰야 합니다. 매번 파일을 다시 만들었다는 이유로 모든 글의 수정일을 오늘로 바꾸지 않습니다.

제출 완료와 색인 완료를 다른 항목으로 보고합니다

사이트맵은 검색엔진이 페이지를 발견하도록 돕는 자료입니다. 제출했다고 모든 URL의 크롤링이나 색인이 보장되는 것은 아닙니다. Google도 사이트맵이 크롤링을 보장하지 않는다고 안내합니다. 사이트맵의 역할

운영표에는 생성 파일 수, 파일별 URL 수, 비압축 용량, 제출 상태, 이후 확인한 색인 상태를 나누어 적습니다. 제출 오류가 있으면 파일과 URL 형식을, 제출은 됐는데 특정 글이 누락됐다면 그 페이지의 내용과 접근 상태를 따로 조사합니다.

출처 확인일: 2026-10-26. 이 글은 사이트맵 관리 기준이며 대량 발행만으로 검색 노출이나 성과가 보장된다고 설명하지 않습니다.