구글 서치 콘솔을 워드프레스에 붙인 지 두 달이 지났다. 그동안 사이트맵이 통째로 사라진 적이 두 번 있었고, 색인 요청을 거부당한 적도 있었다. 미색인 페이지가 43건까지 올라갔을 때는 원인을 못 찾아 며칠을 흘려보냈다. 지금은 그 숫자가 17건으로 줄었는데, 남은 17건은 전부 손댈 필요가 없는 항목이었다.
구글 서치 콘솔 사용법을 설명하는 글은 이미 많다. 이 글은 두 달 동안 실제로 막혔던 지점과 그때 확인한 숫자를 그대로 적은 기록이다. 워드프레스와 카페24 호스팅 환경이고, 도구용 서브도메인은 Vercel에 따로 올라가 있다. 같은 구성을 쓰는 분이라면 그대로 적용할 수 있고, 다른 환경이라도 원인을 좁히는 순서는 비슷할 것이다.
서브도메인까지 크롤링 통로를 만든 방법
네이버 정책이 먼저 걸렸다
블로그는 keywordcockpit.com에 있고 도구는 tool.keywordcockpit.com에 있다. 구글 서치 콘솔은 도메인 속성으로 등록하면 서브도메인까지 한 번에 잡히지만, 네이버 서치어드바이저는 서브도메인을 개별 등록해야 한다. 이 절차가 번거로워 다른 길을 찾았다. 구글 서치 콘솔 쪽은 이미 잡혀 있으니 네이버 쪽만 우회하면 되는 상황이었다.
방향은 단순했다. 루트 도메인의 사이트맵 인덱스 안에 서브도메인 사이트맵 주소를 끼워 넣는 것이다. 로봇이 대표 도메인의 사이트맵을 읽는 김에 서브도메인 지도까지 들고 가게 만드는 방식이다.
Vercel 쪽에서 먼저 막혔다
먼저 tool.keywordcockpit.com/sitemap.xml부터 열어봤는데 404가 떴다. public 폴더에 파일은 있었다. vercel.json의 범용 정적 파일 라우팅 규칙이 이 요청을 가로채고 있었다.
routes 배열 최상단에 명시적 예외를 넣어 해결했다. 순서가 중요하다. 아래쪽에 넣으면 앞선 규칙이 먼저 잡아간다. 배포하고 나서 주소를 직접 열어 확인하기 전까지는 고쳐졌는지 알 수 없었다.
"routes": [
{ "src": "/sitemap.xml", "dest": "/public/sitemap.xml" },
{ "src": "/api/keyword", "dest": "/api/keyword.js" },
...
]WPCode 스니펫 하나로 연결했다
워드프레스 쪽은 Rank Math가 사이트맵 인덱스를 출력하는 시점에 필터를 걸었다. WPCode에 PHP 스니펫으로 등록하고 어디서나 실행으로 활성화했다. 코어 파일이나 테마를 건드리지 않으므로 업데이트에도 안전하다. 테마 functions.php에 넣으면 테마를 바꾸는 순간 사라지는데, 스니펫으로 관리하면 그 문제가 없다.
add_filter( 'rank_math/sitemap/index', function( $xml ) {
$xml .= '
<sitemap>
<loc>https://tool.keywordcockpit.com/sitemap.xml</loc>
<lastmod>' . date('c') . '</lastmod>
</sitemap>';
return $xml;
}, 11 );지금 keywordcockpit.com/sitemap_index.xml을 열면 게시물, 페이지, 카테고리, 저자 사이트맵 아래에 서브도메인 주소가 다섯 번째로 붙어 있다. 도구 쪽 페이지를 늘려도 워드프레스가 알아서 최신 시각을 전달하므로 구글 서치 콘솔에서 따로 할 일이 없다. 서브도메인 파일만 갱신하면 나머지는 자동으로 따라온다.
사이트맵이 통째로 404가 된 두 번
증상은 부분 장애처럼 보였다
8월 6일에 sitemap_index.xml이 404를 반환했다. 하위 사이트맵 네 개도 전부 같았다. 구글 서치 콘솔에는 일반 HTTP 오류 404가 세 건 잡혔다.
헷갈렸던 지점은 발견된 페이지 수치가 그대로 정상 표시됐다는 것이다. 이전에 읽어둔 값을 보여주고 있었을 뿐인데, 화면만 보면 일부만 고장 난 것처럼 읽힌다. 캐시된 숫자와 지금 상태를 구분하지 못한 것이다. 사이트맵 URL을 직접 열어보기 전까지는 전체가 죽었다는 걸 몰랐다. 구글 서치 콘솔 화면에 뜬 숫자를 믿고 며칠을 보낸 셈이다.
원인은 리라이트 규칙이었다
워드프레스 사이트맵은 서버에 존재하는 파일이 아니다. 이 구조를 알고 나서야 왜 다섯 개가 한꺼번에 죽었는지 이해가 됐다. sitemap_index.xml 요청이 들어오면 워드프레스가 리라이트 규칙을 보고 이건 Rank Math가 처리할 요청이라고 판단해 PHP로 넘긴다. 규칙 테이블이 어긋나면 워드프레스는 그런 주소를 모르므로 404를 돌려준다. 파일이 지워진 게 아니라 안내판이 없어진 상태다.
복구 방법을 알고 나면 허무하다. 설정 메뉴의 고유주소로 들어가 아무것도 바꾸지 않고 변경 사항 저장을 누르는 것이다. 이 동작이 규칙을 다시 만든다. 플러그인 재설치나 캐시 삭제는 필요 없었고 1분이 안 걸렸다.
두 번째는 원인이 짚였다
8월 11일에 같은 증상이 다시 났다. 그날 카테고리 이름 세 개를 바꾸고, 빈 카테고리를 삭제하고, 기본 카테고리를 변경했다. 텍소노미 구조를 연속으로 세 번 건드린 직후였다.
리라이트 규칙은 플러그인 활성화나 비활성화, 테마 변경, 텍소노미 등록 같은 시점에 재생성된다. 그 과정에서 Rank Math 규칙이 빠진 채로 저장된 것으로 보인다. 다만 이건 정황 판단이고 확인된 사실은 아니다. 확정하려면 일부러 재현해야 하는데 그럴 이유가 없었다.
같은 일이 세 번째 일어나면 자동 복구 코드를 넣을 생각이지만, 아직은 그럴 단계가 아니다. 대신 규칙을 하나 만들었다. 카테고리나 태그 구조를 바꾸거나 플러그인을 건드린 뒤에는 고유주소를 한 번 재저장한다. 부작용이 없는 동작이라 넣어두는 편이 낫다. 사이트맵 주소를 주 1회 직접 열어보는 것도 10초면 끝난다.
색인 요청이 거부되는 경우
사이트맵 주소를 URL 검사에 넣었다가 막혔다
복구 직후 구글 서치 콘솔의 URL 검사에 sitemap_index.xml을 넣고 색인 생성을 요청했다. 사이트맵이 되살아났으니 빨리 읽어가라는 뜻이었다. 색인 생성 요청이 거부됨이라는 안내가 떴다.
실시간 테스트를 열어보니 이유가 나왔다. 크롤링 허용 여부는 예, 페이지 가져오기는 성공인데, 색인 생성 허용 여부에서 X-Robots-Tag http 헤더에서 noindex가 감지됨으로 걸려 있었다.
이건 정상 동작이다
Rank Math는 사이트맵 파일을 내보낼 때 noindex 헤더를 함께 붙인다. 사이트맵은 로봇이 읽는 안내문이지 검색 결과에 노출될 페이지가 아니기 때문이다. 다른 SEO 플러그인도 같은 방식이다.
사이트맵은 URL 검사가 아니라 왼쪽 메뉴의 Sitemaps에서 제출하는 것이다. 나는 이 구분을 몰라서 색인 요청 할당량을 한 번 소모했다. 구글 서치 콘솔의 하루 요청 횟수에는 제한이 있으므로 아까운 낭비였다.
미색인 43건이 17건으로 줄었다
사이트맵을 복구하고 Sitemaps 메뉴에서 재제출한 뒤 구글 서치 콘솔의 숫자가 움직였다. 8월 초에 색인 33건 미색인 43건이었는데, 지금은 색인 51건 미색인 17건이다.
가장 크게 빠진 항목은 발견됨 현재 색인이 생성되지 않음이었다. 27건에서 0건이 됐다. 사이트맵이 죽어 있는 동안 구글이 주소는 알지만 가져가지 못한 상태로 쌓여 있었고, 통로가 열리자 한꺼번에 처리된 것으로 보인다. 이 항목만 그래프가 급락 곡선을 그렸다. 내가 한 일은 고유주소를 재저장하고 사이트맵을 다시 낸 것뿐이다.
남은 17건은 전부 정상이었다
미색인 숫자를 볼 때 봐야 할 것은 총계가 아니라 사유별 내역이다. 43이라는 숫자 하나로는 무엇을 고쳐야 할지 알 수 없다. 현재 남은 17건을 열어보니 이렇게 나뉘어 있었다. 적절한 표준 태그가 포함된 대체 페이지 4건, 리디렉션이 포함된 페이지 2건, NOINDEX 태그로 제외 1건, 크롤링됨 현재 색인 생성 안 됨 10건이다.
가장 많은 크롤링됨 10건의 주소를 확인해봤다. 여덟 개가 RSS 피드 주소였고 나머지 둘은 댓글 피드와 워드프레스 코어 자바스크립트 파일이었다. 워드프레스가 자동으로 만들어내는 주소들이다. 사람이 읽는 페이지가 아니라 구독기가 읽는 XML이므로 색인되지 않는 게 맞다.
리디렉션 2건은 http에서 https로, www에서 www 없는 주소로 넘기는 것이고 NOINDEX 1건은 내가 의도한 설정이다. 즉 미색인 17건 중 손댈 것이 하나도 없었다. 실제 글은 한 편도 들어 있지 않았다. 43건이라는 숫자를 보고 불안했던 것에 비하면 허탈한 결말이었다.
자주 묻는 질문
구글 서치 콘솔에서 미색인이 많으면 문제인가요?
숫자만으로는 알 수 없습니다. 구글 서치 콘솔에서 사유별 내역을 열어봐야 합니다. 제 경우 17건 중 리디렉션과 NOINDEX, RSS 피드처럼 원래 색인되지 않는 항목이 전부였습니다. 실제 글이 미색인 목록에 들어 있는지부터 확인하시면 됩니다.
사이트맵이 404가 나면 무엇부터 봐야 하나요?
설정 메뉴의 고유주소에서 변경 없이 저장 버튼을 눌러보시면 됩니다. 인덱스와 하위 사이트맵이 동시에 죽었다면 개별 파일 문제가 아니라 리라이트 규칙 문제일 가능성이 큽니다. 저는 두 번 다 이 방법으로 1분 안에 복구했습니다.
사이트맵 주소를 URL 검사에 넣어도 되나요?
색인 요청은 거부됩니다. 사이트맵에는 noindex 헤더가 붙어 나가기 때문입니다. 사이트맵은 구글 서치 콘솔 왼쪽 메뉴의 Sitemaps에서 제출하셔야 합니다. 저는 이걸 몰라 요청 한 번을 날렸습니다. 그래도 다행히 Search Console 도움말을 통해 해결은 했습니다.
서브도메인도 따로 등록해야 하나요?
구글 서치 콘솔은 도메인 속성으로 등록하면 서브도메인까지 함께 잡힙니다. 네이버 서치어드바이저는 개별 등록이 필요합니다. 루트 사이트맵 인덱스에 서브도메인 사이트맵 주소를 넣어두면 크롤링 경로가 한 번 더 확보됩니다.
색인이 풀린 뒤 노출이 어떻게 움직였는지는 구글 색인 43건이 풀린 기록에 따로 정리했다.
이 사이트는 같은 기간 애드센스 반려를 두 번 겪었고, 그 기록은 따로 남겨두었습니다. 두 달 동안 구글 서치 콘솔에서 배운 것은 화면에 뜬 숫자를 그대로 믿으면 안 된다는 점이다. 도구가 틀린 값을 주는 게 아니라, 그 값이 언제 기준인지를 내가 확인하지 않았다. 발견된 페이지 수치는 사이트맵이 죽은 뒤에도 한동안 정상으로 표시됐고, 미색인 43건은 대부분 내가 고칠 수 있는 문제가 아니었다. 주소를 직접 열어보고 사유별로 내역을 펼쳐본 뒤에야 실제 상태를 알 수 있었다. 지금은 사이트맵 주소를 주 1회 확인하는 것과 카테고리 구조를 바꾼 뒤 고유주소를 재저장하는 것, 두 가지를 절차로 넣어두었다.