서치콘솔에서 처음 본 리디렉션 오류
개인 도메인을 연결한 블로그스팟을 운영하면서 서치콘솔에서 리디렉션 오류라는 항목을 처음 보게 되었습니다. 같은 시기에 티스토리 블로그 두 곳도 함께 운영하고 있었는데, 그중 한 곳은 색인이 여든 개가 넘을 때까지 이 항목이 한 번도 나타나지 않았습니다. 그래서 처음에는 블로그스팟 설정을 제가 잘못한 줄 알았습니다. 이 글에서는 리디렉션 오류가 무엇인지, 왜 블로그스팟에서 자주 보이는지, 제가 직접 해본 ?m=1 색인 요청이 어떤 결과로 이어졌는지 정리했습니다. 이 오류를 봤을 때 확인할 순서도 함께 적었습니다.
티스토리와 블로그스팟의 색인 속도 차이
블로그스팟과 티스토리 블로그 하나를 거의 같은 시기에 시작했고, 글쓰기와 색인 요청도 같은 방식으로 해왔습니다. 그런데 첫 서치콘솔 업데이트에서 티스토리는 열여섯 개가 색인된 반면 블로그스팟은 두 개에 그쳤습니다. 다음 업데이트에서 블로그스팟은 여덟 개로 늘었고, 제 서치콘솔 보고서는 매번 약 2주 간격으로 갱신되었습니다.
같은 방식으로 관리해도 플랫폼과 도메인에 따라 색인 속도는 크게 다를 수 있습니다. 구글은 사이트의 인기도나 글이 얼마나 자주 바뀌는지 등을 보고 크롤링 빈도를 정한다고 안내하고 있습니다. 갓 시작한 블로그는 아직 판단할 정보가 적다 보니 처음에는 색인이 느리게 느껴질 수 있습니다. 그러니 색인 수가 적다고 바로 설정 문제라고 단정하기보다, 아래 순서대로 기술적인 문제가 있는지부터 확인하는 것이 좋습니다.
서치콘솔에서 리디렉션 오류를 확인하는 방법
서치콘솔 왼쪽 메뉴에서 색인 생성 아래의 페이지를 누르면 색인 현황 보고서가 나옵니다. 화면 아래 "페이지가 색인되지 않는 이유" 표에서 리디렉션 오류 항목을 누르면 해당 URL 목록이 보입니다. 각 URL 옆의 돋보기 아이콘을 누르면 바로 URL 검사로 넘어갈 수 있습니다.
저는 목록에 있는 URL을 하나씩 주소창에 직접 넣어봤는데, 모두 정상적으로 열렸습니다. 방문자가 접속하는 데는 문제가 없고, 서치콘솔에서만 오류로 표시되는 상황이었습니다.
리디렉션 오류와 리디렉션이 포함된 페이지의 차이
서치콘솔에는 이름이 비슷한 항목이 두 개 있어서 헷갈리기 쉽습니다. "리디렉션이 포함된 페이지"는 다른 주소로 정상적으로 넘겨주는 페이지를 뜻합니다. 예를 들어 http 주소가 https로 넘어가거나, www가 없는 주소가 www 주소로 넘어가는 경우입니다. 이때 구글은 최종 도착 주소를 색인하므로 따로 조치할 필요가 없습니다.
반면 "리디렉션 오류"는 이동하는 과정에서 문제가 생긴 경우입니다. 구글 도움말에 따르면 리디렉션이 너무 여러 번 이어지거나, 주소끼리 서로를 가리키며 도는 경우, 최종 주소가 너무 긴 경우 등이 해당됩니다. 내 서치콘솔에 뜬 것이 둘 중 어느 항목인지 먼저 구분해 두면 불필요한 걱정을 줄일 수 있습니다.
블로그스팟에서 자주 생기는 이유
블로그스팟은 휴대폰으로 접속하면 주소 끝에 ?m=1을 붙인 모바일용 주소로 보여줍니다. 구글은 주로 모바일 기준으로 사이트를 크롤링하기 때문에, 이렇게 주소가 바뀌는 과정이 리디렉션으로 기록됩니다.
개인 도메인을 연결하면 여기에 단계가 더 붙습니다. http에서 https로, www가 없는 주소에서 www 주소로, 다시 모바일 주소로 넘어가는 과정이 이어지는 것입니다. 이 중 어느 단계에서 구글이 제대로 따라가지 못하면 오류로 기록될 수 있다고 알려져 있습니다. 블로그스팟 운영자들 사이에서 흔히 보고되는 현상이고, 대부분은 방문자 접속에 영향을 주지 않습니다.
블로거 설정에서 먼저 확인할 것
리디렉션 과정이 꼬이지 않도록 블로거 설정 몇 가지를 점검해 보는 것이 좋습니다. 먼저 설정의 게시 항목에서 맞춤 도메인이 www가 붙은 주소로 등록되어 있는지 확인합니다. www가 없는 주소를 www 주소로 넘겨주는 도메인 리디렉션 옵션이 켜져 있는지도 봅니다. 다음으로 HTTPS 항목에서 HTTPS 사용과 HTTPS 리디렉션이 모두 켜져 있는지 확인합니다. 메뉴 이름은 화면에 따라 조금 다를 수 있습니다.
마지막으로 서치콘솔에 등록한 사이트 주소와 제출한 사이트맵 주소가 실제 블로그 주소(https://www. 형태)와 같은지 확인합니다. 등록한 주소와 실제 주소가 다르면 구글이 매번 리디렉션을 거쳐야 하기 때문입니다.
직접 해본 방법: ?m=1 주소로 색인 요청
이 오류의 해결 방법으로 가장 많이 알려진 것은 URL 끝에 ?m=1을 붙여서 모바일 주소로 다시 색인 요청을 하는 것이었습니다. 다만 구글의 공식 해결책이 아니라 블로그스팟 운영자들의 경험에서 나온 방법입니다. 저도 오류가 뜬 URL에 ?m=1을 붙여 URL 검사를 하고 색인 요청을 했습니다.
다음 서치콘솔 업데이트에서 이 주소들은 색인되지 않았습니다. 대신 "적절한 표준 태그가 포함된 대체 페이지"라는 항목으로 분류되어 있었습니다.
대체 페이지로 처리된 결과의 의미
처음에는 이 방법도 실패했다고 생각했습니다. 그런데 이 항목은 문제 상태가 아니었습니다. 블로그스팟의 ?m=1 주소에는 "원래 주소가 대표 페이지"라고 알려주는 표준(canonical) 태그가 들어 있습니다. 그래서 구글이 모바일 주소를 따로 색인하지 않고 원래 주소를 기준으로 처리한 것입니다. 구글 서치콘솔 도움말에서도 이 상태는 따로 조치할 필요가 없다고 안내하고 있습니다.
결국 ?m=1로 요청하는 것은 색인 수를 늘리는 방법이 아니었습니다. 실제로 확인해야 할 것은 ?m=1이 없는 원래 주소의 상태였습니다.
리디렉션 오류와 '발견됨' 상태는 다른 문제
리디렉션 오류를 해결하려고 서치콘솔을 들여다보다가 더 많은 글이 다른 항목에 묶여 있다는 것을 알게 되었습니다. "발견됨 - 현재 색인이 생성되지 않음"이라는 항목에 글이 24개나 있었습니다. 목록을 열어보니 최종 크롤링 날짜가 모두 1970-01-01로 표시되어 있었습니다. 이 날짜는 실제 날짜가 아니라, 구글이 아직 한 번도 이 페이지를 크롤링하지 않았다는 뜻입니다.
이 글들은 전부 실제 URL 테스트를 거쳐 색인 요청을 했고, 그때마다 "URL을 Google에 등록할 수 있음"이 떴던 글이었습니다. 리디렉션 오류는 구글이 페이지를 찾아가다가 이동 과정에서 문제가 생긴 경우입니다. 발견됨 상태는 구글이 주소는 알고 있지만 아직 찾아오지 않은 경우입니다. 구글 도움말에서는 사이트에 부담을 주지 않으려고 크롤링을 미룬 경우가 많다고 설명합니다. 그래서 이 상태는 설정을 고친다고 바로 풀리지 않고, 기다리면서 글의 내용을 채워가는 수밖에 없었습니다. 이 글을 고치는 지금은 색인된 글이 열세 개로 조금씩 늘고 있습니다.
사이트맵으로 구글에 글 목록을 알려주는 방법은 [RSS와 사이트맵의 차이]에, 애드센스 비승인과 연결된 이야기는 [가치가 별로 없는 콘텐츠 판정 기준과 대응 방법]에 정리해두었습니다.
리디렉션 오류를 봤을 때 확인 순서
먼저 오류가 뜬 URL을 PC와 휴대폰에서 직접 열어보고 정상적으로 열리는지 확인합니다. 다음으로 서치콘솔 URL 검사에 ?m=1이 없는 원래 주소를 넣고 실제 URL 테스트를 누릅니다. "URL을 Google에 등록할 수 있음"이 나오면 페이지에 기술적인 문제는 없는 것입니다. 이 경우 원래 주소로 색인 요청을 한 번 하고 기다리면 됩니다. 같은 주소를 여러 번 요청해도 속도가 빨라지지는 않습니다.
URL 검사 결과에서 크롤링 허용 여부가 "아니요"로 나온다면 robots.txt에서 막혀 있는 것은 아닌지도 확인해 봅니다. 블로그스팟 기본 robots.txt는 글 주소를 막지 않는데, 자세한 내용은 [robots.txt란 무엇인가]에 정리해 두었습니다.
테스트에서 오류가 나온다면 앞에서 정리한 블로거 도메인 설정과 HTTPS 설정을 다시 점검합니다. 설정을 고친 뒤에는 리디렉션 오류 보고서 화면의 수정 결과 확인 버튼을 눌러 구글에 다시 확인을 요청할 수 있습니다.
정리
블로그스팟의 리디렉션 오류는 대부분 모바일 주소와 도메인 연결 구조 때문에 생기고, 방문자 접속에는 문제가 없는 경우가 많습니다. ?m=1 주소로 요청하면 대체 페이지로 정리될 뿐 색인 수가 늘지는 않았습니다. 그러니 원래 주소의 실제 URL 테스트 결과를 기준으로 판단하는 것이 가장 확실했습니다.
