리디렉션 체인과 루프를 찾아 SEO 이전 리스크 줄이기

리디렉션 체인은 한 URL이 두 번째 URL로 이동하고, 다시 세 번째 URL로 이동한 뒤에야 최종 목적지에 도착하는 상태입니다. 리디렉션 루프는 요청이 최종 목적지에 도착하지 못하고 같은 경로를 반복하는 상태입니다.

둘 다 고칠 수 있습니다. 그리고 생각보다 자주 생깁니다.

특히 호스팅 변경, 도메인 포워딩, CMS 이전, Shopify/headless 이전, 문서 URL 정리 중에 자주 발생합니다. 도메인을 옮기고 있다면 경로와 UTM을 잃지 않는 도메인 포워딩도 함께 보세요.

체인은 보통 이렇게 보입니다.

/old-page -> /legacy-page -> /new-page

루프는 이렇게 보입니다.

/old-page -> /new-page -> /old-page

SEO, 성능, 이전 rollout을 신경 쓴다면 목표는 단순합니다. 한 요청, 한 번의 리디렉션, 하나의 최종 목적지에 최대한 가깝게 만드는 것입니다.

체인과 루프가 나쁜 이유

실제 사용자를 늦춥니다

hop이 하나 늘 때마다 기다림이 늘어납니다. 지연이 작아 보여도 랜딩 페이지, 카카오톡 공유 링크, QR 캠페인에서는 불필요한 대기가 누적됩니다.

migration을 이해하기 어렵게 만듭니다

리디렉션 맵은 이전을 단순하게 만들어야 합니다. 체인은 반대로 최종 canonical URL이 무엇인지 흐립니다.

crawler와 QA 비용을 낭비합니다

검색엔진은 리디렉션을 따라갈 수 있지만, 복잡한 redirect system은 direct mapping보다 crawl, 검증, 유지보수가 어렵습니다.

루프는 요청을 깨뜨립니다

루프는 비효율이 아니라 실패입니다. 브라우저는 안정적인 목적지에 도착하지 못합니다.

체인이 생기는 흔한 원인

체인은 보통 여러 “합리적인” 규칙이 시간차로 쌓일 때 생깁니다.

먼저 HTTP -> HTTPS 규칙이 추가됨
그 다음 non-www -> www 규칙이 추가됨
오래된 slug -> 새 slug 규칙이 추가됨
CMS plugin이 또 다른 redirect를 추가함
마지막에 canonical host가 다시 바뀜

각 규칙은 단독으로 보면 문제없어 보입니다. 합치면 체인이 됩니다.

http://old-brand.example/docs
  -> https://old-brand.example/docs
  -> https://www.old-brand.example/docs
  -> https://new-brand.example/docs

대부분은 이렇게 줄이는 것이 맞습니다.

http://old-brand.example/docs
  -> https://new-brand.example/docs

루프가 생기는 흔한 원인

루프는 보통 서로 충돌하는 로직에서 나옵니다.

host rule이 다른 host로 보내고
두 번째 rule이 다시 원래 host로 보냄
app-level redirect가 edge rule과 충돌함
locale 또는 device rule이 안정적인 최종 목적지를 가지지 않음

여러 layer가 동시에 canonical routing을 소유한다고 생각하면 루프 가능성이 높아집니다. CDN rule, app middleware, reverse proxy, CMS plugin을 동시에 켜둔 migration에서 특히 조심해야 합니다.

체인을 찾는 방법

먼저 비즈니스 가치가 큰 URL부터 확인하세요.

홈페이지
가격 페이지
상위 organic landing page
유료 캠페인 URL
문서와 고객센터 글
이전 migration에서 생긴 backlink

방법 1: curl 사용

curl -I https://old-brand.example/pricing

더 자세히 보려면:

curl -IL https://old-brand.example/pricing

각 단계의 Location header를 볼 수 있습니다.

방법 2: bulk crawl

사이트 이전 중이라면 리디렉션 맵을 내보내고 중요한 URL을 batch로 crawl하세요. 수동 spot check에서는 보이지 않던 숨은 체인을 이 단계에서 찾는 경우가 많습니다.

방법 3: production 분석 확인

라우팅 계층이 traffic과 path behavior를 보여준다면 다음을 봅니다.

오래된 path에서 반복되는 요청
high-volume legacy URL
이상한 status code pattern
예상 최종 목적지에 도달하지 않는 요청

이 때문에 리디렉션을 분석, 깨진 링크 모니터링과 함께 운영하는 팀이 많습니다.

루프를 찾는 방법

루프는 브라우저에서 “too many redirects”로 드러나는 경우가 많지만, 조합별 테스트가 필요합니다.

확인할 항목:

끝나지 않는 URL
같은 두 host 또는 path가 번갈아 나오는 trace
언어, host, protocol rule이 서로를 계속 다시 쓰는 경우
mobile/desktop rule이 서로 다른 canonical로 튀는 경우

locale redirect, canonical-host redirect, app-level auth redirect가 함께 있다면 조합을 의도적으로 테스트하세요.

체인을 고치는 방식

정답은 “아무 redirect나 지워서 페이지가 열리게 하기”가 아닙니다.

정답은 다음 순서입니다.

진짜 최종 URL을 정합니다.
모든 오래된 variant를 그 최종 URL로 직접 보냅니다.
내부 링크를 업데이트해 redirect를 덜 타게 합니다.
오래된 intermediate rule을 제거합니다.

리디렉션 맵은 이전 이력이 아니라 현재 기준을 반영해야 합니다.

루프를 고치는 방식

두 번째 bounce를 만드는 layer를 찾습니다.
routing source of truth를 하나로 정합니다.
충돌하는 규칙을 제거하거나 범위를 좁힙니다.
host, protocol, locale, device 조합을 다시 테스트합니다.

[!WARNING] 루프는 happy path 하나만 테스트하면 살아남습니다. 최종 URL 하나만 보지 말고 variant를 테스트하세요.

migration에서 특히 위험한 곳

Host 통합

http, https, www, root-domain 규칙은 같이 설계하지 않으면 쉽게 체인이 됩니다.

Path rename

오래된 slug가 중간 slug로 가고, 그 중간 slug가 다시 최종 slug로 가는 상황이 흔합니다.

CMS와 app rewrite

CDN rule이 보낸 path를 app이 다시 canonicalize하려고 할 수 있습니다.

Localization rule

언어 선택 로직과 canonical rule이 서로 다르면 bounce가 생깁니다.

도메인 이동을 준비 중이라면 즉흥적으로 규칙을 추가하지 말고 웹사이트 이전 리디렉션 체크리스트대로 진행하세요. 상태 코드 정책이 애매하다면 301, 302, 307, 308 차이도 먼저 정리해야 합니다.

실무 QA 흐름

예정된 리디렉션 맵을 내보냅니다.
비즈니스 중요 URL 50-200개를 고릅니다.
한 hop으로 최종 목적지에 도착하는지 테스트합니다.
root domain, www, HTTPS를 확인합니다.
device rule이 있으면 mobile/desktop을 따로 봅니다.
출시 후 내부 링크를 새 canonical로 업데이트합니다.
첫 7-14일 동안 404와 리디렉션 동작을 모니터링합니다.

UrlEdge가 도움이 되는 부분

UrlEdge는 리디렉션 동작을 app middleware, CMS plugin, server config, DNS-provider forwarding 기능에 흩어두지 않고 하나의 routing layer에 둡니다. 그래서 다음 작업이 쉬워집니다.

체인을 direct mapping으로 줄이기
리디렉션 검사기로 실제 경로 확인
깨진 링크 모니터링으로 실패 경로 감시
분석으로 출시 후 트래픽 검증

FAQ

redirect hop 하나가 항상 큰 문제인가요?

항상 재앙은 아닙니다. 하지만 고가치 URL과 canonicalization path에서는 불필요한 hop을 줄이는 것이 좋습니다.

redirect가 동작하면 내부 링크를 안 바꿔도 되나요?

아니요. redirect는 safety rail입니다. 안정 상태에서는 내부 링크가 최종 목적지를 직접 가리켜야 합니다.

루프는 항상 CDN 때문인가요?

아닙니다. CDN, app, proxy, localization logic, CMS behavior가 서로 다른 결정을 할 때 자주 생깁니다.

paid campaign에도 체인이 영향을 주나요?

그렇습니다. hop이 많아질수록 attribution, preview, timeout 문제가 생길 지점도 늘어납니다.

무료로 시작하기

문서