사이트맵은 “우리 사이트에서 색인할 가치가 있는 주소 목록” 이라는 약속입니다. 그 목록에 404 나 301 이 섞여 있으면 약속을 어기는 문서를 검색엔진에 정기 제출하는 셈이 됩니다. 문제는 사이트맵이 자동 생성이라는 점 — 화면에서 은퇴시킨 주소를 생성기는 모릅니다.
실제로 겪은 세 가지 유형
저희 사이트 개편 과정에서 사이트맵 감사로 잡아낸 실물 사례입니다.
- 301 로 은퇴한 구조 — CPT 아카이브를 정적 페이지로 옮기고 옛 주소를 301 처리했는데, 사이트맵에는 옛 주소가 남아 있었습니다.
- noindex 처리된 글 — 런타임 필터로 noindex 를 건 글을 생성기는 그대로 실었습니다. 생성기는 그 판정을 모릅니다.
- 실제 404 — 한글 슬러그가 percent-encoding 으로 저장된 기본 페이지가 사이트맵에는 실려 있는데 열면 404 였습니다.
점검 루프 — 그냥 전부 요청한다
# 인덱스에서 하위 사이트맵을 모으고, 전 URL 의 상태 코드를 찍는다
for u in $(curl -s https://example.com/sitemap_index.xml | grep -o '[^<]*' | sed 's///'); do
for p in $(curl -s "$u" | grep -o '[^<]*' | sed 's///'); do
printf '%s %sn' "$(curl -s -o /dev/null -w '%{http_code}' "$p")" "$p"
done
done | grep -v '^200' 출력이 비어 있으면 통과입니다. 무엇이든 나오면 그 줄이 곧 작업 목록입니다 — 301 은 생성기에서 제외 처리하고, 404 는 원인(슬러그 · rewrite)을 고치고, noindex 글은 사이트맵 제외 필터에 같은 판정을 연결합니다.
언제 돌리는가
주소 구조를 바꾼 직후가 필수 시점이고, 그 외에는 배포 체크리스트에 넣어 정기화하는 것이 이상적입니다. 감사보다 좋은 것은 애초에 어긋나지 않게 만드는 것 — noindex 판정과 사이트맵 제외가 같은 코드를 쓰도록 묶어 두면 한쪽만 고치는 사고가 구조적으로 없어집니다.
중복 선언 정리는 SEO 플러그인은 하나만에서 다뤘습니다. 색인 상태 전반의 진단은 최적화 지원 사업의 SEO 항목으로 제공합니다.