사이트맵 제출 기준 · 제출했는데 색인이 안 될 때

사이트맵을 만들어 제출했다. 오류도 없고 「성공」으로 표시된다. 그런데 색인된 페이지 수는 늘지 않는다.

우리도 그 상태였다. 그리고 확인해 보니 제출된 사이트맵이 네 건이었는데 그중 정식 주소가 하나도 없었다. 몇 달 동안 아무 오류 표시 없이 그랬다.

이 글은 제출하는 방법이 아니라, 제출한 뒤에 무엇이 어긋나는지를 우리 기록과 함께 적는다. 만드는 법은 공식 문서가 더 정확하고, 정작 오래 방치되는 것은 그 뒤쪽이다.

사이트맵이 보장하는 것은 생각보다 적다

먼저 기대를 맞춰야 한다. 사이트맵은 「이런 페이지가 있다」는 통보이고, 읽는 순서나 색인 여부를 정하지 않는다.

우리 글 57편을 검색엔진이 기록한 발견 경로로 나눠 크롤 여부를 맞춰 봤다.

사이트맵에만 올라간 글의 넷 중 셋은 읽히지 않았다. 사이트맵을 내지 말라는 뜻이 아니라, 사이트맵을 냈다고 할 일이 끝난 것이 아니라는 뜻이다. 이 수치가 어떻게 나왔고 색인이 안 될 때 무엇을 먼저 보는지는 구글 색인 안 되는 이유에 정리했다.

그래서 제출한 뒤에도 색인이 늘지 않을 때 볼 것은 사이트맵 자체보다 그 밖에 있는 경우가 많다. 다만 사이트맵 쪽에도 조용히 어긋나는 자리가 몇 군데 있고, 그게 우리가 겪은 것이다.

이 구분이 중요한 이유가 있다. 사이트맵은 눈에 보이고 손댈 수 있어서 계속 만지게 된다. 반면 「이 글로 들어오는 링크가 있는가」는 화면에 나오지 않아서 확인할 생각을 안 하게 된다. 그래서 대개 효과가 작은 쪽에 시간을 더 쓴다.

제출된 주소가 실제 주소와 다를 수 있다

우리 경우가 이것이었다. 제출 목록을 열어 보니 네 건이 들어 있었다.

정식 주소가 빠져 있었다. 네 건 모두 오류 0으로 표시되고 있었기 때문에 화면만 봐서는 문제가 없어 보인다.

특히 세 번째가 눈에 띈다. 다른 사이트의 사이트맵이 이 속성에 제출돼 있었다. 같은 뿌리 도메인의 다른 하위 도메인이라 제출 자체는 거부되지 않은 것이다. 이 상태면 보고 화면의 숫자에 다른 사이트의 페이지가 섞여 들어간다. 우리가 「제출 몇 건, 색인 몇 건」을 볼 때마다 실제로는 두 사이트가 합쳐진 숫자를 보고 있었던 셈이다.

왜 오류가 안 뜨나

리다이렉트되는 주소로 제출해도 사이트맵은 읽힌다. www 주소가 본주소로 넘어가면 검색엔진이 따라가서 내용을 가져간다. 그래서 「오류 0」이 맞는 표시다.

문제는 그 상태가 정상이라는 뜻은 아니라는 것이다. 제출 주소와 사이트맵 안에 적힌 주소가 다르면, 어느 쪽을 기준으로 다루는지가 불분명해진다. 그리고 우리처럼 같은 사이트맵이 두세 개의 다른 주소로 중복 제출되어 있으면 보고 화면이 서로 다른 숫자를 보여준다.

끝에 슬래시가 붙은 주소는 더 헷갈린다. sitemap.xml/ 은 파일 주소가 아닌 형태인데도 리다이렉트를 타고 읽혀서 오류가 안 난다. 우리는 이 주소로 78개 URL이 읽히고 있었다.

무엇을 했나

정식 주소를 새로 제출했다. 기존 세 건은 지우지 않았다. 지우는 것은 되돌리기 어렵고, 누가 왜 넣었는지 모르는 항목을 없애는 것은 위험하다. 제출은 되돌릴 수 있으므로 더하는 쪽만 했다.

하루 뒤에 확인하니 새로 제출한 주소가 정상 다운로드됐다. 제출 자체는 빠르게 처리된다. 그 뒤에 크롤이 늘어나는지는 별개이고 며칠에서 몇 주를 봐야 한다.

그리고 이것을 원인으로 단정하지 않는 편이 좋다. 우리 경우 기형 주소로도 78개 항목이 읽히고 있었으므로, 정식 주소가 없었다는 것만으로 크롤이 멈췄다고 말할 수는 없다. 고칠 값이 있는 것과 그것이 원인인 것은 다른 이야기다. 고쳐 놓고 날짜를 적어 둔 다음, 그날 확인해서 관계를 판단하는 쪽이 정직하다.

보고 화면의 「색인」 숫자를 그대로 믿으면 안 된다

우리 네 건은 전부 색인 0으로 표시돼 있었다. 그런데 검색창에 site: 로 도메인을 넣어 보면 실제로 스무 편 이상이 색인돼 있다.

이 숫자는 더 이상 채워지지 않는 항목이다. 0으로 보인다고 색인이 안 된 것이 아니다.

색인 여부를 확인하려면 두 가지를 쓴다.

• site:도메인 검색 — 지금 실제로 검색에 들어가 있는 문서 목록
• URL 검사 — 개별 주소의 마지막 크롤 시각과 그때의 판정. 서치콘솔 연결이 아직이라면 구글 검색 등록 기준이 먼저다

우리가 「09-12 이후 발행한 글이 한 편도 색인되지 않았다」는 것을 알아낸 것도 사이트맵 화면이 아니라 site: 검색이었다.

재제출은 신호가 아니다

색인이 안 될 때 가장 흔한 조치가 사이트맵 재제출이다. 우리도 했고, 우리 기록에서는 효과가 없었다.

내용이 같은 사이트맵을 다시 내는 것은 새로운 정보가 아니다. 검색엔진이 보는 것은 제출 행위가 아니라 사이트맵 안의 내용이 바뀌었는지다.

의미가 있는 것은 하나다. 각 URL의 갱신 시각(lastmod)이 실제로 움직이는 것. 글을 고쳤으면 그 항목의 갱신 시각이 바뀌어야 하고, 안 바뀌면 다시 읽어 달라는 요청이 나가지 않는다.

우리가 실제로 겪은 일이다. 열다섯 편을 한 달에 걸쳐 고쳤는데 갱신 시각이 그대로였다. 사이트맵은 계속 옛 날짜를 내보내고 있었고, 재크롤 요청이 한 번도 나가지 않았다. 작업은 했는데 그 작업의 효과를 측정할 방법 자체가 없어진 상태였다.

갱신 시각을 확인하는 방법

사이트맵 주소를 브라우저에서 열고 해당 페이지의 항목을 찾아 날짜를 본다. 글을 고친 날짜와 맞는지 보면 된다.

여기서 한 가지 주의할 점이 있다. 사이트맵 파일 하나에 여러 종류의 페이지가 섞여 있으면, 어떤 항목에는 갱신 시각이 있고 어떤 항목에는 없을 수 있다. 우리도 목록 페이지에는 날짜가 있고 일부 정적 페이지에는 없는 상태였다. 날짜가 없는 항목은 재방문 우선순위를 판단할 근거가 없다.

사이트맵에 넣어도 읽히지 않는 항목이 있다

모든 항목이 같게 다뤄지지 않는다. 우리 사이트맵에는 목록 페이지의 두 번째, 세 번째 페이지가 주소 끝에 ?page=2 같은 형태로 들어가 있었다. 갱신 시각까지 붙여서.

그 항목들은 한 번도 읽히지 않았다. 사이트맵에 있고 날짜도 있는데 그렇다.

여기서 나오는 판단은, 이런 형태의 주소를 발견 경로로 계산에 넣지 않는 것이다. 목록 두 번째 페이지 이후에만 걸려 있는 글은 사실상 아무 경로도 없는 것과 같다. 우리 미크롤 글들이 정확히 거기 있었다.

이건 사이트맵을 고쳐서 풀리는 문제가 아니다. 목록 페이지 구조를 바꾸거나, 그 글들에 본문 링크를 따로 주는 쪽으로 가야 한다. 사이트맵에 넣는 것으로 구조 문제를 덮을 수는 없다.

사이트맵은 진단 도구로도 쓸 수 있다

제출 목록을 한 번 읽어 보면 사이트맵 자체보다 더 많은 것이 나온다. 우리가 위의 네 건을 발견한 것도 「사이트맵을 고쳐야겠다」고 생각해서가 아니라, 크롤이 일주일 넘게 없어서 원인을 찾다가 열어 본 것이었다.

읽을 때 같이 보면 좋은 것이 몇 가지 있다.

마지막 다운로드 날짜의 분포. 여러 건이 제출돼 있을 때 어느 것은 어제 읽혔고 어느 것은 몇 달 전이라면, 검색엔진이 실제로 쓰고 있는 것이 무엇인지 알 수 있다. 우리는 기형 주소 쪽이 계속 읽히고 정상에 가까운 쪽은 석 달째 멈춰 있었다.

항목 수의 변화. 글을 계속 내는데 제출 항목 수가 그대로면 사이트맵 생성이 어딘가에서 멈춘 것이다. 반대로 항목 수가 갑자기 뛰었다면 의도하지 않은 주소가 들어갔을 수 있다.

사이트맵 안에 적힌 주소의 형태. 제출 주소와 별개로 내용 안의 주소가 일관되는지 본다. 일부는 www 가 붙고 일부는 안 붙어 있으면 그 자체로 문제다.

이 셋은 색인이 잘 되고 있을 때도 한 번쯤 볼 값이 있다. 문제가 생긴 뒤에 열어 보면 언제부터 그랬는지 알 수 없기 때문이다.

무엇을 어떤 순서로 확인하나

색인이 늘지 않을 때 사이트맵 쪽에서 볼 것을 순서대로 적으면 이렇다.

하나, 제출된 주소가 정식 주소인가. 리다이렉트되는 주소나 끝에 슬래시가 붙은 형태로 제출돼 있어도 오류가 안 뜬다.

둘, 중복 제출이나 남의 사이트가 섞여 있지 않은가. 제출 목록을 한 번은 전부 읽어 봐야 한다. 우리는 다른 사이트의 사이트맵이 섞여 있는 것을 몇 달 뒤에 발견했다.

셋, 마지막 다운로드 날짜가 최근인가. 석 달 전이면 그 항목은 사실상 죽은 것이다.

넷, 각 항목의 갱신 시각이 실제 수정 날짜와 맞는가. 이게 안 맞으면 고친 것이 전달되지 않는다.

다섯, 여기까지 정상인데도 안 되면 사이트맵 문제가 아니다. 그 페이지로 들어오는 링크가 있는지를 본다 — 어디에 걸어야 실제로 전달되는지는 따로 적었다.

다섯 번째가 대부분의 경우다. 우리도 사이트맵을 고친 것과 별개로, 실제로 크롤을 움직인 것은 본문 안의 링크였다. 순서를 지키는 이유는 앞의 넷이 금방 확인되기 때문이다 — 제출 목록을 한 번 읽는 데 몇 분이면 되고, 거기서 걸리면 링크까지 갈 필요가 없다.

정리하면

사이트맵에서 조용히 어긋나는 자리는 네 군데였다.

제출 주소가 정식 주소가 아니다. 리다이렉트되는 주소로 제출해도 읽히므로 오류가 안 뜬다. 우리는 네 건 전부가 그랬다.

보고 화면의 색인 숫자가 값을 채우지 않는다. 0으로 보이는데 실제로는 스무 편 넘게 색인돼 있었다. 색인 확인은 site: 검색과 URL 검사로 한다.

갱신 시각이 움직이지 않으면 고친 것이 전달되지 않는다. 재제출이 아니라 이 값이 신호다.

모든 항목이 같게 다뤄지지 않는다. 쿼리가 붙은 목록 페이지는 넣어도 읽히지 않았다.

그리고 이 넷을 다 고쳐도 사이트맵만으로 크롤이 늘지는 않는다. 우리 기록에서 실제로 크롤을 움직인 것은 다른 글의 본문에서 받은 링크였고, 사이트맵은 그 앞에 놓인 전제 조건에 가깝다.

하지 말아야 할 것

같은 사이트맵을 여러 주소로 제출하는 것. 보고 숫자가 갈라지고 어느 것이 기준인지 알 수 없어진다.

내용이 그대로인 채 재제출하는 것. 하루 한도를 쓰고 아무 신호도 보내지 않는다.

사이트맵을 늘려서 색인을 늘리려는 것. 없는 페이지를 채워 넣는 것이 아니라면 항목 수는 이미 정해져 있다. 색인이 안 되는 이유는 목록에 없어서가 아니다.

사이트맵 화면의 숫자로 색인 상태를 판단하는 것. 위에서 적은 대로 그 항목은 값이 채워지지 않는다.

한 번 맞춰 놓고 다시 보지 않는 것. 우리 네 건 중 셋은 몇 달 전에 제출된 것이고 그 사이 아무도 열어 보지 않았다. 사이트맵 생성 코드를 손볼 때, 도메인이나 주소 구조를 바꿀 때는 제출 목록도 같이 확인해야 한다.

자주 묻는 질문

사이트맵을 제출하면 색인이 보장되나요?

아니다. 사이트맵은 존재를 알리는 것이고 색인 여부는 별개다. 우리 기록에서는 사이트맵에만 올라간 글의 크롤률이 25%였고, 다른 페이지에서 링크를 받은 글은 83%였다.

제출 목록에 오류가 0인데도 문제가 있을 수 있나요?

있다. 오류 0은 「그 주소로 사이트맵을 읽을 수 있었다」는 뜻이다. 정식 주소인지, 중복인지, 다른 사이트인지는 오류로 잡히지 않는다. 우리 네 건이 전부 오류 0이었다.

www 주소로 제출해도 되나요?

읽히기는 한다. 다만 본주소와 다른 주소로 제출한 상태는 정리하는 편이 낫다. 같은 사이트맵이 두 주소로 중복 제출되어 있으면 보고가 갈라진다. 정식 주소를 추가로 제출하는 것은 안전하다.

기존 제출을 지워야 하나요?

급하지 않으면 두는 편이 낫다. 지우는 것은 되돌리기 어렵고, 오래된 항목이 무엇을 위해 들어갔는지 모를 수 있다. 먼저 정식 주소를 추가하고, 정리는 그다음에 판단한다. 우리도 그 순서로 했다.

사이트맵을 몇 번이나 제출해야 하나요?

한 번이면 된다. 그 뒤에는 사이트맵 내용이 바뀌면 검색엔진이 알아서 다시 가져간다. 재제출로 순서가 앞당겨지지 않는다.

사이트맵을 여러 개로 나눠야 하나요?

항목이 매우 많을 때만 필요하다. 수십에서 수백 개 규모라면 하나로 충분하다. 나누면 관리할 것이 늘고, 우리처럼 어느 것이 실제로 읽히는지 헷갈리는 상태가 생길 수 있다.

사이트맵에서 뺀 페이지는 색인에서 빠지나요?

아니다. 사이트맵에 없어도 링크로 발견되면 읽히고 색인될 수 있다. 사이트맵은 색인 대상을 정하는 목록이 아니다. 색인을 막으려면 그 페이지에 색인 제외 표시를 넣어야 한다.

갱신 시각은 어떻게 넣어야 하나요?

각 페이지가 실제로 수정된 시각을 넣는다. 발행일을 고정해 두거나 전체를 같은 날짜로 채우면 신호가 되지 않는다. 자동 생성한다면 그 값이 수정 기록에서 오는지 확인해야 한다 — 우리 경우 한동안 고정된 날짜가 나가고 있었다.

참고 자료

• 사이트맵 제작 및 제출하기 — Google 검색 센터 — 형식과 제출 방법, 사이트맵이 필요한 경우.
• 사이트맵에 대해 알아보기 — Google 검색 센터 — 사이트맵이 보장하는 것과 보장하지 않는 것.
• 페이지 색인 생성 보고서 — Search Console 도움말 — 색인 상태를 확인하는 화면과 상태 문구.