발행 버튼을 누르고 성공 응답을 받으면 그날 할 일은 끝났다고 여기기 쉬운데요, 필자는 그렇게 올린 글 열 편 넘게가 검색엔진이 들여다보는 목록에서 통째로 빠져 있었다는 사실을 한참 뒤에야 알게 됐습니다.
정리하는 개발자 워니즈입니다. 이번 시간에는 사이트맵 누락을 어떤 방법으로 발견했고 무엇을 원인에서 지워나갔는지, 그리고 손실 범위를 어디까지로 봤는지를 순서대로 적어보려고 합니다.
발행이 성공했다는 응답은 검색엔진이 그 글을 찾을 수 있다는 뜻이 전혀 아닙니다. 발행한 글의 총 편수와 사이트맵에 실린 주소 개수를 각각 세어서 그 차이가 0인지 매회 확인하시면 됩니다.
발행 성공과 발견 가능은 서로 다른 단계입니다
워드프레스에서 글을 올리면 응답 코드가 돌아오고 목록에도 바로 뜨니까 필자는 오랫동안 그 지점에서 확인을 멈췄는데요, 검색엔진이 새 글의 존재를 알게 되는 경로는 그것과 별개로 사이트맵이라는 목록 파일에서 열립니다. 글이 사이트에는 멀쩡히 올라가 있는데 그 목록 파일에만 이름이 없는 상태가 될 수 있고 이때 사람은 주소를 알면 볼 수 있지만 검색엔진은 그 글의 존재 자체를 모르는 상황이 됩니다.
사이트맵 누락이 무서운 건 어디에서도 에러가 나지 않는다는 점입니다. 발행은 성공이고 글도 보이고 관리 화면에도 경고가 없어서 확인하지 않으면 몇 주가 지나도 모른 채로 계속 새 글만 쌓게 되는 것 같습니다.
세는 방법은 두 줄이면 끝납니다
필자가 쓰는 방법은 숫자 두 개를 각각 다른 경로에서 가져와 맞춰보는 것뿐입니다. 하나는 워드프레스가 알려주는 발행 글의 총 편수인데요, 글 목록을 한 건만 요청해도 응답 헤더에 전체 개수가 함께 들어오기 때문에 본문을 내려받지 않고도 확인할 수 있습니다. 다른 하나는 사이트맵 파일을 그대로 받아서 주소를 감싸는 태그가 몇 번 나오는지 세는 것입니다.
사이트맵은 글이 많아지면 여러 개 파일로 쪼개지니까 번호가 붙은 파일을 없다고 나올 때까지 차례로 받아서 합산해야 하는데, 이 지점을 놓치면 파일 하나만 세고 절반이 빠졌다고 오판하게 됩니다. 두 숫자를 나란히 놓고 차이가 0이면 정상이고 0이 아니면 그 순간부터 원인을 찾으면 되는 구조라서, 판정 자체는 애매할 여지가 없다는 점이 마음에 들었습니다.
사이트맵 누락은 시점 기준으로 딱 갈렸습니다
실제로 세어보니 발행한 글보다 사이트맵에 실린 주소가 열한 개 적었습니다. 처음에는 어느 글이 랜덤하게 빠진 건가 싶었는데 누락 목록을 발행일 역순으로 늘어놓고 보니 규칙이 아주 뚜렷했습니다. 특정 시각 이전에 올린 글은 전부 들어가 있고 그 뒤에 올린 글은 전부 없었는데요, 같은 날 발행분 안에서도 그 시각 앞뒤로 정확하게 갈렸습니다.
사이트맵 목록 파일에 적혀 있는 마지막 갱신 시각도 나흘 전 특정 시점에 멈춰 있었습니다. 그러니까 이건 글이 하나씩 새어 나간 문제가 아니라 그 시각에 만들어진 목록이 그대로 굳어서 이후 갱신이 한 번도 일어나지 않은 상태였던 것입니다. 누락이 시점 기준으로 딱 갈린다면 개별 글의 설정을 뒤질 필요가 없다는 신호로 보시면 될 것 같습니다.
캐시부터 의심했는데 전부 아니었습니다
사이트맵 누락을 발견하고 처음 떠오른 원인은 당연히 캐시였습니다. 새 글이 홈에만 안 보이는 증상을 겪은 적이 있어서 그때와 같은 계열이라고 짐작했는데요, 그 사례는 워드프레스 캐시 때문에 새 글이 홈에만 안 보일 때에 따로 정리해두었습니다. 그래서 캐시를 전부 비우고 주소에 의미 없는 값을 붙여 우회 요청까지 보내봤는데 결과가 한 글자도 달라지지 않았습니다.
그다음으로 SEO 플러그인이 들고 있는 임시 저장값을 지웠고, 사이트맵 설정 화면에서 저장을 다시 눌러 강제로 다시 만들게 해봤고, 글 자체를 여러 번 저장해서 갱신 훅이 걸리게도 해봤습니다. 응답 헤더를 열어보니 캐시하지 말라는 지시가 이미 붙어 있어서 앞단에서 붙잡고 있는 것도 아니었고, 정적 파일이 대신 서빙되는 경우도 아니었습니다. 결국 관리 화면에서 누를 수 있는 버튼은 전부 눌러봤고 전부 아무 변화가 없었습니다.
손실 범위는 생각보다 좁았습니다
당황해서 최악을 가정했는데 범위를 따로 재보니 훨씬 좁았습니다. 필자 블로그는 새 글이 올라갈 때 검색엔진에 직접 알려주는 방식을 함께 쓰고 있는데요, 그쪽 전송 내역을 열어보니 누락된 글들이 전부 정상 응답으로 찍혀 있었습니다. 즉 그 방식을 지원하는 검색엔진들은 새 글을 이미 알고 있었던 셈입니다.
문제는 구글이 그 방식을 쓰지 않는다는 점입니다. 구글은 사이트맵과 크롤링으로 새 글을 찾으니까, 사이트맵을 만드는 방법에 나온 대로 목록이 갱신되지 않으면 발견 경로가 그만큼 닫히게 됩니다. 그래서 이번 손실은 전 범위가 아니라 구글 한정으로 정리됐고, 대응의 급한 정도도 그 판정 뒤에 달라졌습니다. 색인이 안 될 때 확인하는 순서는 글이 구글에 색인되지 않을 때 확인한 순서에 적어두었으니 함께 보시면 도움이 될 것 같습니다.
관리자 화면에서 안 되는 일은 기록으로 남깁니다
같은 버튼을 다시 누르고 싶어지는 순간이 계속 오는데요, 필자는 이미 실패한 경로를 두 번 세 번 반복하는 데 시간을 쓰는 게 가장 아까운 낭비라고 보고 있습니다. 그래서 무엇을 시도했고 결과가 어땠는지를 표로 남겨두고, 남은 조치는 서버 접근이 필요하다는 결론까지 적어놓은 뒤 그날 작업은 접었습니다.
대신 확인 절차 자체는 자동화된 점검 항목으로 옮겼습니다. 발행 총계와 사이트맵 수록 개수를 매번 세어 차이가 0이 아니면 알려주도록 해두면, 다음에 같은 일이 생겼을 때 나흘이 아니라 그날 안에 알게 되는 것 같습니다.
사이트맵 누락, 많이 묻는 것들
Q. 사이트맵에 글이 빠져 있으면 검색에서 완전히 사라지나요.
이미 색인된 글은 그대로 남아 있고 문제가 되는 건 새 글의 발견입니다. 다만 발견이 늦어지면 그동안 노출 기회를 잃는 것이라 방치할 이유는 없다고 봅니다.
Q. 플러그인을 다시 설치하면 해결되나요.
필자는 아직 시도하지 않았습니다. 원인이 확정되지 않은 상태에서 설정을 갈아버리면 재현 경로까지 사라져서 다음에 같은 일이 나도 원인을 못 찾게 되기 때문인데요, 확인할 수 있는 것을 다 확인한 뒤에 손대는 편이 안전할 것 같습니다.
Q. 얼마나 자주 확인해야 하나요.
글을 올리는 날마다 확인하시면 충분합니다. 숫자 두 개를 세는 일이라 몇 초면 끝나고, 이번처럼 목록이 굳는 종류의 고장은 발행일 기준으로 갈리니까 발행 직후가 가장 잘 잡히는 시점입니다.
정리
발행 성공 응답은 글이 올라갔다는 뜻이지 검색엔진이 그 글을 찾을 수 있다는 뜻이 아니었습니다. 필자는 발행 총계와 사이트맵 수록 개수의 차이를 세어보고서야 사이트맵 누락이 열한 편이라는 것을 알았고 누락이 시점 기준으로 갈린 덕분에 개별 글 설정이 아니라 목록 생성이 굳었다는 쪽으로 방향을 잡을 수 있었습니다. 캐시와 임시 저장값을 비롯해 관리 화면에서 할 수 있는 무효화는 전부 통하지 않았고, 대신 손실 범위가 구글 한정이라는 점을 확인해서 급한 정도를 정리했습니다. 오늘 글을 올리셨다면 발행 편수와 사이트맵 주소 개수를 한 번 세어보시고 그 차이가 0인지만 확인해보시길 권합니다.