📋 이 글의 목차
01 · 리디렉션 오류가 갑자기 쌓이기 시작했다
02 · ?m=1의 정체를 알게 됐다
03 · 사이트맵을 과감하게 정리했다
04 · 색인이 생기기 시작했다
✍ 정리하면서 느낀 것
블로그스팟으로 블로그를 운영하면서 직접 겪은 리디렉션 오류 경험을 정리한 글이다. 네트워크관리사 자격증 공부를 통해 쌓은 네트워크 기초 지식이 원인 파악에 도움이 됐다. 구글 공식 발표나 서치콘솔 데이터를 직접 분석한 내용이며, 모든 블로그에 동일하게 적용되는 정답은 아닐 수 있다.
01 리디렉션 오류가 갑자기 쌓이기 시작했다
3월 24일, 구글 서치콘솔에서 처음 리디렉션 오류 2개를 발견했다. 처음엔 대수롭지 않게 봤다. 근데 다음 날 19개로 늘어있었다. 그 다음 날도 늘었다. 뭔가 잘못되고 있다는 건 알았는데, 원인을 몰랐다.
오류 목록을 보면 URL들이 멀쩡한 글 주소였다. 삭제한 글도 아니고, 주소를 바꾼 것도 없었다. 근데 구글은 "리디렉션 오류"라고 찍어놨다. 더 황당한 건 그 글들은 블로그에서 멀쩡하게 열렸다는 거다.
02 ?m=1의 정체를 알게 됐다
서치콘솔 크롤링 통계를 파고들다가 단서를 찾았다. Googlebot 유형 기준을 보면 스마트폰 봇이 전체의 60% 이상이었다. 그리고 응답 기준에서 302(임시 이전)이 59%를 차지하고 있었다.
성공(200) 항목의 URL 목록을 확인했더니 전부 ?m=1이 붙은 주소였다. 반대로 302 목록은 ?m=1이 없는 정상 URL이었다.
?m=1이 뭔가
정상 URL:
blog.com/2026/04/article.html
모바일 접속 시 자동 생성:
blog.com/2026/04/article.html?m=1
블로그스팟이 스마트폰으로 접속하면 자동으로 ?m=1을 붙여서 모바일 버전으로 리디렉션한다. 구글봇도 스마트폰 에이전트로 크롤링하면 이 302를 맞닥뜨린다. 이게 리디렉션 오류로 잡히는 구조였다.
색인 요청을 하면 구글봇이 해당 URL을 크롤링하러 온다. 그때 스마트폰 에이전트로 오면 블로그스팟이 302로 ?m=1 주소로 넘긴다. 구글 입장에서는 "어? 이 URL이 다른 곳으로 튀네?" 하고 리디렉션 오류로 기록하는 거다. 며칠 지나면 재크롤링해서 정상(200)으로 처리하지만, 그 사이에 오류가 쌓이는 구조다.
블로그스팟 구조상 이 ?m=1 리디렉션을 완전히 없애는 건 어렵다. 커스텀 도메인 + 테마 수정으로 개선은 가능하지만, 그건 나중 얘기다. 일단 이게 "내가 뭔가 잘못해서" 생기는 오류가 아니라는 걸 알게 된 것만으로도 방향이 잡혔다.
03 사이트맵을 과감하게 정리했다
원인 파악과 별개로, 사이트맵 문제도 있었다. 초반에 뭣도 모르고 /sitemap.xml과 /atom 두 개를 동시에 등록해뒀었다. 사이트맵이 두 개면 구글이 "어떤 게 정식이야?" 하고 혼란스러워한다는 걸 나중에 알았다.
4월 8일, 둘 다 삭제하고 /sitemap.xml?max-results=500 하나만 새로 등록했다. 그리고 그 이후 약 이틀간 기존 글 수정·리빌딩을 완전히 멈췄다. 구글이 새 사이트맵을 인식하고 정리하는 시간을 줬다.
04 색인이 생기기 시작했다
사이트맵 재등록 후 3일 뒤, 서치콘솔에 색인된 페이지가 처음으로 생겼다. 또 3일 뒤에 추가로 늘었다. 극적으로 빠른 건 아니었지만, 방향이 맞다는 확인이 됐다.
크롤링 통계에서도 변화가 보였다. 302 비율이 59%에서 58%로 내려갔다. 1%포인트라 작아 보이지만, 그전까지 계속 60% 언저리에서 고정돼있다가 처음으로 내려간 거라 의미가 있었다. 성공(200) 비율은 37%에서 39%로 올라갔다.
✍ 정리하면서 느낀 것
리디렉션 오류를 처음 봤을 때 내가 뭔가 크게 잘못한 줄 알았다. 근데 알고 보니 블로그스팟 구조 자체에서 오는 부분이 컸다. ?m=1은 내가 만든 게 아니라 플랫폼이 자동으로 만드는 거고, 구글봇이 거기서 302를 맞닥뜨리는 건 구조적으로 피하기 어렵다.
그래서 "이걸 완전히 없애야 한다"는 방향보다, "이게 왜 생기는지 알고 불필요한 변수만 줄이자"는 방향으로 접근했다. 사이트맵 이중 등록 같은 명확한 문제만 정리하고, 나머지는 구글이 정리하도록 기다렸다.
지금도 리디렉션 오류가 완전히 사라진 건 아니다. 근데 방향은 맞다고 본다. 조급하게 손대는 것보다 기다리는 게 더 나은 경우가 있다는 걸 이 과정에서 배웠다.
현재는 구조 안정화 단계다. 리디렉션 오류는 아직 있다. 그래도 색인은 된다. 조금씩, 점점 더.
자주 묻는 질문
Q. 블로그스팟 외 다른 플랫폼도 같은 문제가 생기나요?
플랫폼마다 모바일 처리 방식이 달라서 동일하지는 않다. 워드프레스는 플러그인으로 canonical 설정을 강제할 수 있어서 관리가 더 유연하다. 블로그스팟은 구조적으로 ?m=1 리디렉션이 내장돼있어 제거가 까다롭다.
Q. 리디렉션 오류가 생기면 바로 수정해야 하나요?
꼭 그렇지 않다. 오류 원인이 ?m=1 같은 구조적 문제라면, 손댈수록 변수가 늘어서 오히려 악화될 수 있다. 명확한 실수(사이트맵 이중 등록, 구 URL 방치 등)만 정리하고 나머지는 기다리는 게 나을 수 있다.
Q. 색인이 안 되는 건 리디렉션 오류 때문인가요?
리디렉션 오류가 색인을 완전히 막는 건 아니다. 구글봇이 재크롤링하면서 정상 처리하는 경우가 많다. 색인이 느린 건 오류 외에도 콘텐츠 신뢰도, 내부링크 구조, 사이트 전체 크롤링 빈도 등 여러 요인이 복합적으로 작용한다.
댓글 (0)
댓글 쓰기