[구글 SEO 09] 사이트맵 제대로 만들기, 글·이미지·영상

사이트맵은 구글에게 건네는 사이트 지도다. 여기 이런 URL들이 있으니 참고하라는 목록이다. 신생 도메인일수록 이 지도를 깔끔하게 관리하는 게 중요하다. 크롤 예산이 빠듯한 상태에서 지도가 지저분하면, 봇이 엉뚱한 곳을 헤매다 정작 새 글을 못 본다.

사이트맵을 그냥 자동 생성 플러그인 켜두고 잊는 사람이 많은데, 신생 사이트에선 이 지도의 정밀도가 색인 속도를 눈에 띄게 좌우한다. 지도는 자동으로 만들되, 그 안에 무엇이 담기고 무엇이 빠지는지는 반드시 사람이 통제해야 한다. 자동이라는 말과 방치라는 말은 다르다. 이번 편은 사이트맵을 어떻게 구성해야 크롤 예산을 아끼는지에 대한 실전 정리다.

1. 사이트맵의 역할과 한계

먼저 흔한 오해부터 풀자. 사이트맵에 URL을 넣는다고 색인이 보장되는 건 절대 아니다. 사이트맵은 발견을 돕는 보조 장치일 뿐이고, 색인 여부는 구글이 실제 콘텐츠를 보고 완전히 별개로 판단한다. 지도에 있다고 다 방문받는 것도, 방문받았다고 다 색인되는 것도 아니다.

그래서 사이트맵의 진짜 가치는 크롤 예산 절약에 있다. 봇이 링크를 일일이 따라다니며 URL을 찾아 헤매는 수고를 덜어주고, 여기 중요한 URL이 이만큼 정리돼 있다고 한 번에 알려주는 것이다. 이 관점에서 보면 사이트맵에 무엇을 넣고 빼는지가 곧 크롤 예산을 어디에 쓸지 배분하는 일이 된다. 쓸데없는 URL로 지도를 채우는 건, 예산이 빠듯한 봇에게 여길 먼저 봐 하고 엉뚱한 곳을 가리키는 것과 같다.

사이트맵을 크롤 예산의 관점에서 보기 시작하면 관리 기준이 명확해진다. 이 URL을 봇이 굳이 지금 봐야 하는가라는 질문 하나로 넣고 뺄지가 갈린다. 답이 아니오인 URL은 아무리 많아도 지도에서 빼는 게 맞다. 지도는 전부를 담는 백과사전이 아니라, 중요한 곳만 가리키는 안내판이어야 한다.

2. 글과 미디어를 한 지도에 섞지 마라

내가 초기에 저지른 실수. 사이트맵에 글 URL만이 아니라 이미지와 영상 URL까지 죄다 밀어 넣었다. 글이 1천여 개인데 이미지가 1천여 개, 영상이 2백여 개가 함께 들어 있으니, 신생 도메인의 적은 예산에서 봇이 미디어를 확인하느라 정작 새 글을 못 보는 상황이 벌어졌다.

이미지는 글을 크롤할 때 그 안에서 자연히 함께 발견되므로 굳이 사이트맵으로 또 안내할 필요가 적다. 결론적으로 나는 글 사이트맵만 남기고 미디어는 뺐다. 특별히 이미지나 영상 검색이 핵심 트래픽인 사이트가 아니라면, 신생 단계에선 글 중심으로 지도를 단순화하는 게 유리하다. 나중에 도메인 신뢰가 쌓이고 크롤 예산이 넉넉해지면 그때 이미지 사이트맵을 별도 파일로 분리해서 추가하면 된다. 순서의 문제지 영원히 안 한다는 얘기가 아니다.

미디어를 뺀다고 이미지가 검색에서 완전히 사라지는 건 아니다. 글이 크롤될 때 본문 안의 이미지가 함께 발견되기 때문이다. 다만 alt 텍스트와 주변 문맥이 충실해야 이미지도 제대로 색인된다. 그래서 이미지 사이트맵에 힘을 쏟기보다, 글 안에서 이미지에 설명을 잘 달아주는 쪽이 신생 단계에선 투자 대비 효과가 크다.

글 사이트맵만 남긴다고 해서 영상까지 무조건 빼라는 건 아니다. 영상이 핵심 콘텐츠이고 영상 검색 유입을 노린다면 영상 사이트맵은 오히려 썸네일과 재생 정보를 구글에 정확히 전달하는 통로가 된다. 요는 섞지 말고 목적에 맞게 분리하라는 것이다. 글, 이미지, 영상은 각자 다른 파일로 두고 필요한 것만 취사선택하는 게 관리와 예산 양쪽에 유리하다.

3. 사이트맵 인덱스로 분할한다

사이트맵 하나에는 URL 5만 개, 파일 크기 50MB(압축 전)라는 상한이 있다. 글이 많아지면 사이트맵을 여러 개로 쪼개고, 그 사이트맵들을 가리키는 사이트맵 인덱스(sitemap of sitemaps)를 최상위에 둔다. 구글에는 이 인덱스 하나만 제출하면 하위를 알아서 따라간다.

이때 각 하위 사이트맵과 그 안의 URL에는 마지막 수정 시각을 뜻하는 lastmod를 붙이는데, 이 값을 어떻게 다루느냐가 은근히 중요하다. lastmod가 정확하면 구글은 실제로 바뀐 사이트맵만 골라 효율적으로 다시 읽는다. 안 바뀐 건 건너뛰니 예산이 절약된다. 반대로 이 값을 엉터리로 두면 구글이 지도 전체를 불신하게 되는데, 하필 이게 실제 사고로 이어졌다. 다음 편에서 글 439개가 사라졌던 사건으로 자세히 복기한다.

분할할 때는 기준을 명확히 잡는 게 좋다. 게시판별이든 날짜별이든 규칙적으로 쪼개두면, 나중에 특정 구간에 문제가 생겼을 때 어느 하위 사이트맵을 다시 제출해야 하는지 바로 안다. 무질서하게 쪼개면 439개가 사라졌던 것 같은 사고가 났을 때 어느 파일이 범인인지 찾는 데만 한참 걸린다.

분할 개수도 무작정 잘게 쪼갤 필요는 없다. 하위 사이트맵이 너무 많으면 관리와 재읽기 추적이 번거로워진다. 상한인 5만 개에 여유를 두되 게시판이나 기간 같은 의미 있는 단위로 몇 개만 나누는 게 실무적으로 편하다. 나는 하위를 소수로 유지하면서 각각이 무엇을 담는지 이름만 봐도 알게 지었다.

4. 살아 있는 URL만 넣는다

사이트맵의 신뢰도를 지키는 철칙 하나. 죽은 URL, 301로 넘어가는 URL, noindex가 걸린 URL, canonical에서 대표가 아닌 URL은 사이트맵에 절대 넣지 않는다. 지도에 있는 주소는 전부 정식 목적지여야 한다.

사이트맵은 여기는 색인해도 좋은 정식 URL이라고 구글에게 보증하는 목록인데, 여기에 상태가 어긋나는 URL이 섞이면 구글은 이 사이트의 지도는 못 믿겠다고 판단한다. 한두 개면 몰라도 비율이 높아지면 지도 전체의 신뢰가 깎인다. 그래서 사이트맵에 넣은 URL은 전부 200 OK에 색인 가능해야 한다. 이상적으로는 글을 지우거나 비공개로 돌리는 순간 사이트맵에서도 자동으로 빠지도록, 사이트맵 생성 쿼리 자체가 공개·정상 상태의 글만 뽑게 짜는 것이다. 그러면 사람이 신경 쓰지 않아도 지도와 실제 상태가 늘 일치한다.

살아 있는 URL만 넣는 원칙은 사이트맵을 데이터베이스의 뷰처럼 다루면 자동으로 지켜진다. 공개 상태이고 삭제되지 않은 글만 뽑는 쿼리로 사이트맵을 매번 생성하면, 글의 상태가 바뀌는 순간 지도에도 자동 반영된다. 사이트맵을 손으로 관리하는 파일이 아니라 현재 상태의 반영으로 설계하는 것이 핵심이다.

사이트맵에 넣지 말아야 할 것 중 자주 놓치는 게 파라미터가 붙은 URL이다. 클린 URL 대신 정렬이나 필터가 붙은 주소를 사이트맵에 넣으면 앞서 애써 정리한 중복 URL을 스스로 다시 구글에 소개하는 꼴이 된다. 사이트맵에 들어가는 주소는 예외 없이 정규화된 클린 URL이어야 한다. 지도와 정리 정책이 어긋나면 정리가 무효가 된다.

5. robots.txt 등록과 GSC 제출

다 만든 사이트맵은 두 군데에 알린다. 하나는 robots.txt에 Sitemap 지시문으로 절대 경로를 적어두는 것이고, 다른 하나는 GSC의 사이트맵 메뉴에 직접 제출하는 것이다. 둘 다 해두면 구글이 발견할 확률이 올라간다.

제출하면 구글이 발견한 URL 수를 보여주는데, 이 숫자를 내가 실제로 넣은 글 수와 주기적으로 대조하는 습관이 정말 중요하다. 두 숫자가 조용히 벌어지는 순간이 바로 문제의 시작이기 때문이다. 이 대조는 한 달에 한 번이라도 캘린더에 박아두고 하는 걸 권한다. 아무 경고 없이 벌어지다가 수백 개가 누락된 걸 뒤늦게 발견하면 회복이 그만큼 늦어진다. 다음 편에서는 내가 이 대조를 소홀히 했다가 글 439개가 통째로 구글에서 사라졌던 사건을 그대로 복기한다.

제출한 뒤에도 사이트맵 상태는 계속 지켜봐야 한다. GSC 사이트맵 화면의 상태가 성공을 유지하는지, 발견 URL 수가 실제와 맞는지를 정기적으로 확인한다. 어느 날 상태가 오류로 바뀌거나 숫자가 급변하면 그게 신호다. 지도를 한 번 잘 그려두는 것만큼, 그 지도가 계속 정확한지 감시하는 것도 중요하다.