블로그스팟 맞춤 리디렉션과 자바스크립트 리디렉션

개요: 301 리디렉션의 필요성

흔한 일은 아니지만 글을 쓰다보면 기존의 글을 삭제하고 새 글을 쓰는 경우가 있죠?

대표적으로 여러 개로 나뉘어 있던 글을 하나로 합치는 경우인데, 그냥 삭제하거나 비공개로 놔두긴 아까우니 기존 글이 이동했다고 검색엔진과 방문자 모두에게 알려야 해요.

이럴 때 301 리디렉션을 기본적으로 선택하고, 그게 안 될 경우 차선책으로 meta 리프레쉬나 자바스크립트로 기존 주소로 접속한 사람을 새 주소로 이동시키게 되죠.

다행스럽게도 블로그스팟은 301 리디렉션을 지원하고 있어요. 물론 외부 사이트로 나가는 것은 안 되고요.

현재 블로그의 내부 이동만 지원하기 때문에 블로그 자체를 옮긴다면 티스토리와 마찬가지로 메타 태그 혹은 자바스크립트를 쓰는 수 밖에 없어요.

블로그스팟 맞춤 (301) 리디렉션 설정

관리 페이지
설정
맞춤 리디렉션

맞춤 리디렉션 = 301 리디렉션으로 이름만 다를 뿐 똑같은 거예요.

블로그 설정 화면에서 제일 아래쯤에 있는 맞춤 리디렉션을 클릭하고 기존 글 주소를 새 주소로 넘겨주면 되는데요, 용어랑 주소 자체에 약간 주의가 필요해요.

우선 맞춤 리디렉션은 올린이가 기존 주소, 받는사람이 새로운 주소예요.

실제 주고 받는 글 주소의 경우도 주의점이 있는데요, 블로그 주소를 쓰면 안 된다는 점이에요.

무슨 소리냐면, 전체 URL이 아니라 도메인 이후의 "년도/월/파일명.html" 경로만 적어야 한다는 거예요.

올린이: 2026/06/old.html
받는사람: 2026/06/new.html

이 문제 때문에 다른 사이트로 이전할 때 맞춤 리디렉션을 사용할 수 없어요. 내 계정의 다른 구글 블로그도 안 되고 오직 '이 블로그' 내부에서만 동작하는 거예요.

https부터 시작해서 자기 블로그든 아니면 다른 사이트든 주소를 써 보면 일단 저장은 되는데요, 최종 확인을 할 때 빨간색으로 경고가 뜨며 넘어가지 않아요.

또, 스크린샷에 나와있듯이 확인 버튼 위에 "확정"이라는 버튼이 있는데 그걸 켜야 301 영구 이동으로 적용 돼요. 아니면 302 임시 이동이 되어버려요.

마지막으로 제대로 적용되었는지 확인하기 위해 브라우저 캐시를 비우거나 시크릿 모드에서 확인하면 끝이에요.

간편하지만 제한 있음

작성한 맞춤 리디렉션(301)은 언제든 수정할 수 있고 지우는 것도 자유로워요. 그러니 블로그 내부에서 이동하는 글은 다른 방법 쓰지말고 바로 맞춤 리디렉션을 쓰는게 좋아요.

구글 검색 센터에서도 301 리디렉션은 페이지 랭크 손실이 없다고 하니 다른 걸 쓸 이유가 없죠. 빠른데다 편하기도 하니 더욱 그렇고요.

일괄 처리는 지원하지 않는 것이 흠이긴 한데, 블로그 운영 도중에 그렇게 할 이유는 없을테니 큰 문제는 아닐거예요.

다만 하나의 블로그에 단 한번, 계정당 1년에 몇 번 제한을 두고서라도 블로그 이전 할 때 텍스트 파일 등의 형태로 대량 이동 및 타 사이트로의 리디렉션을 지원해 줬으면 좋겠네요.

방치중인 서비스라도 잡아 놓은 물고기가 도망가기 쉽게 만들 이유는 없겠지만요.

뭐, 정 필요하면 필요하면 ?m=1 제거 글에서 썼던 방법을 이용하여 경로 + 쿼리 + 해시를 추출해서 새 사이트의 호스트 이름과 햄버거처럼 조립하는 방법을 쓰면 되겠죠.

그럼 옮길 글이 몇개나 되든 상관없이 일괄 처리 가능하니까 큰 문제는 아니긴 해요.

맞춤 리디렉션은 몇 개나 설정 가능한가?

또 하나, 맞춤 리디렉션을 몇 개 만들수 있는가? 이건 몰라요. 공식적인 명시가 없는 것으로 알아요. 검색해 봐도 뚜렷한 정보도 나오지 않고요.

확실한 것은 대량 리디렉션 목적은 절대로 아니라는 것이에요. 수작업으로 하나씩 넣게 만든 것을 보면 알 수 있죠.

설정 화면에서 맞춤 리디렉션을 등록 할 때 어떤 요청이 오가는지 체크한 뒤, 자바스크립트로 자동화 된 등록을 해 볼 수도 있겠지만... 까딱하면 계정 전체가 날아갈 수 있으니 무서워서 못 하겠네요. 정상적으로 하나씩 등록해서 테스트하다간 손목이 남아나지 않을 것 같고요.

어차피 평범한 블로거라면 그렇게 많은 리디렉션을 쓰지는 않을 테니, 등록 및 삭제가 불편하다는 것을 빼면 별 문제는 아니라고 봐요.

'도저히 안 되겠다', '불편해서 못 쓰겠다', '좀 더 편하게 구성하고 싶다' 라면, 결국 자기가 직접 자바스크립트로 리디렉션을 구현하는 방법 뿐이겠죠.

이건 흔해빠진 팁이긴 하지만 아래에 구성해 놓을게요. 나중에 저도 필요할 경우 뇌를 비우고 갖다 쓸 수 있도록요.

자바스크립트를 이용한 리디렉션 코드

아래의 코드를 실제 사이트에 적용하기 전에 반드시 테스트 사이트에서 시험한 뒤 적용하세요!

내부 이동용

<script>
// 현재 사이트 유지. 쿼리 등은 떼고 이동함.
const currentSite = location.origin; // 프로토콜+호스트 반환
const currentPath = location.pathname;
const newSite = 'https://www.maidvsai.com';
const urlPair = {
  '/2026/07/old-1.html' : '/2026/07/new-1.html',
  '/2026/07/old-2.html' : '/2026/07/new-2.html',
  '/2026/07/old-3.html' : newSite+'/2026/07/new-3.html'
};
// 실제 이동 명령
if( urlPair[currentPath] && currentSite != newSite ) {
  location.replace(urlPair[currentPath]);
}
// maidvsai
</script>

이 코드는 블로그/사이트 주소는 그대로 두고 글만 옮길 때 사용해요.

각각의 old와 new는 상황에 맞게 바꾸시면 되고요, 3번의 newSite+'/2026/07/new-3.html' 부분은 특정한 글만 다른 블로그/사이트로 내보낼 때 사용하셔요. newSite 내부는 새로운 도메인을 넣으면 돼요.

이 때, 'https://'는 필수예요. 없으면 기존 경로의 끝에 합쳐져요. 그럼 없는 주소를 요청하고, 결국 404 페이지로 이동하게 되죠.

만약의 상황을 대비해서 안전장치도 넣어뒀어요.

현재 접속한 사이트가 newSite면 통과
urlPair 목록에 없는 경로면 통과

이 두가지 안전장치를 넣어뒀으니 무한 루프에 빠지거나 이상한 경로로 리디렉션 될 위험은 없을 거예요.

서버측 리디렉션이 아니라 '페이지 접속 후' 스크립트로 이동시키는 거라, 위치에 따라 반응 속도가 다를 수 있어요. 최대한 빠른 반응을 위해서 head 태그 최상단에 넣으셔요.

Q: 0.1ms라도 더 빠르게 반응했으면 좋겠어요.
A: minify 하셔요.

minify로도 만족 못 하시면 const 선언을 없애버리고 조건문에 직접 넣어버리셔요.

사이트 이전용

<script>
// 새 사이트로 통째로 이전. 쿼리 등은 떼고 이동함.
const currentSite = location.origin;
const currentPath = location.pathname;
const newSite = 'https://www.maidvsai.com';
const exceptionPath = [
  '/',
  '/p/notice.html'
];
// 실제 이동 명령
if ( !exceptionPath.includes(currentPath) && currentSite != newSite ) {
  location.replace(newSite + currentPath);
}
// maidvsai
</script>

요건 사이트 자체를 통째로 옮길 때 쓰시면 되는데요, 안전장치는 'url pair vs 제외목록'일 뿐 위의 코드랑 같아요.

exceptionPath에 들어있는 목록은 리디렉션하지 않을 제외목록이에요. 홈페이지나 공지사항 같은 특정 제외 경로를 입력하시면 돼요.

사이트 유지용이나 사이트 이전용 둘 다 쿼리문 등 복잡한 건 다 떼놓고 이동하는데요, 블로거가 수동으로 입력하는 내용이라 예측 불가능성이 없기 때문에 깔끔하게 이동시키고 있어요.

광고 추적이나 분석용 쿼리문 등을 넘겨주려면 관련글에 있는 ?m=1 제거 글을 살펴 보셔요.

주소 목록이 많아질 경우

Q: 주소가 수백개면 어쩌죠?
A: 상관없어요.

배열이 아니라 key:value 쌍인 객체를 사용했기 때문에 그 정도는 문제없어요. 순차적으로 읽으면서 진행하는 게 아니라 직접 접근이니까요.

단, 천개 이상 ~ 수천개 수준이면 확실히 문제가 있을 거예요. 텍스트 용량이 엄청 커져서 다운로드 및 파싱, 평가 시간 등 속도에 영향을 줄 테니까요.

이런 경우는 일일이 값을 적는게 아니라 정규식이나 공통 문자열을 이용해서 치환해야 해요. 예를 들어 2020년 글을 전부 2026년으로 옮긴다면 아래와 같은 형태의 코드를 쓸 수 있어요.

<script>
// 일정한 규칙이 있을 경우
const currentSite = location.origin;
const currentPath = location.pathname;
const newSite = 'https://www.maidvsai.com';
const yearFrom = '2020';
const yearTo = '2026';
let newPath;
const urlPair = {
  '/2026/07/old-1.html' : '/2026/07/new-1.html',
  '/2026/07/old-2.html' : '/2026/07/new-2.html',
  '/2026/07/old-3.html' : newSite+'/2026/07/new-3.html'
};
// 실제 이동 명령
// 새 사이트가 아닐 때만 동작
if ( currentSite != newSite ) {
  // 특정 년도로 시작할 경우
  if ( currentPath.startsWith( `/${yearFrom}/` ) ) {
    newPath = currentPath.replace(`/${yearFrom}/`, `/${yearTo}/`);
    redirection(newPath); // 필요 시 앞에 newSite 추가
  }
  else { // 일반 리디렉션
    if( urlPair[currentPath] ) {
      redirection(urlPair[currentPath]);
    }
  }
}
// 따로 빼낸 리디렉션 명령
function redirection(url) {
  location.replace(url);
}
// maidvsai
</script>

yearFrom, yearTo 같은 구조는 그저 예시일 뿐이니까 실제로는 블로그/사이트 상황에 맞에 바꿔서 써야 해요. 그러면 대량의 코드를 다운받고 파싱하는 지연 시간은 없어질 거예요.

드문 경우, 이동할 글이 적더라도 개별 경로가 굉장히 길면 금방 용량이 커질 건데요, 이 역시 규칙을 찾아내서 적용해야 할 거예요. 하다못해 년도별로 코드를 분할하는 정도라도 해야겠죠.

그냥 쌩으로 갖다 놓으면... 좀 느려질 거예요. 어쩌면 많이.

참고 자료

구글 검색 센터: 사이트 이동 방법
MDN: JavaScript 객체 기본
MDN: location.replace, History에 저장되지 않습니다.
MDN: elem.startsWith, 문자열이 특정 문자로 시작할 경우.

이 블로그 검색