UrlEdge
블로그로 돌아가기
2026-03-12 UrlEdge Editorial6 min read

SEO 팀을 위한 사이트 이전 리디렉션 체크리스트

DNS를 전환하기 전에 고가치 URL, 리디렉션 체인, sitemap, canonical, 출시일 모니터링을 점검하는 15개 체크리스트입니다.

웹사이트 이전 체크리스트와 리디렉션 QA를 함께 검토하는 작은 팀

웹사이트 이전은 디자인, 코드, 런칭 메시지보다 리디렉션 운영 원칙에서 성패가 갈리는 경우가 많습니다. DNS를 전환하기 전 가장 중요한 질문은 단순합니다.

중요한 기존 URL이 모두 올바른 새 URL에 한 번의 명확한 hop으로 도착하나요?

이 체크리스트는 다음과 같은 이전을 준비하는 팀을 위한 것입니다.

  • 새 도메인으로 이동
  • 새 CMS로 이동
  • monolith에서 headless로 이동
  • subdomain에서 root domain으로 이동
  • 오래된 docs/blog 구조를 새 URL 체계로 정리

Shopify 사례가 필요하면 Shopify URL을 headless로 이전하는 가이드를 보세요. 이 글은 거의 모든 기술 스택에 적용할 수 있는 넓은 범위의 체크리스트입니다.

도메인 변경과 wildcard forwarding도 포함된다면 경로와 UTM을 잃지 않는 도메인 포워딩을 함께 열어두세요.

절대 놓치면 안 되는 목표

출시 전에 다음 다섯 가지가 모두 맞아야 합니다.

  1. 고가치 기존 URL이 올바른 새 URL로 매핑됩니다.
  2. 영구 이동에는 영구 리디렉션 의도를 사용합니다.
  3. 가능한 한 리디렉션이 한 hop으로 끝납니다.
  4. 내부 링크가 이미 새 canonical URL을 가리킵니다.
  5. 트래픽 전환 전에 출시 후 모니터링이 준비되어 있습니다.

하나라도 빠지면 이전 리스크가 빠르게 올라갑니다.

웹사이트 이전 체크리스트, QA 단계, 출시일 점검을 검토하는 팀

리디렉션 체크리스트

1. 현재 URL 인벤토리 만들기

기억에 의존해 리디렉션을 계획하지 마세요.

다음에서 URL을 뽑습니다.

  • XML sitemap
  • analytics landing page
  • Search Console top pages
  • paid campaign URL
  • email template
  • backlink와 partner docs
  • 오래된 blog/docs archive

검색 트래픽, 전환 트래픽, support traffic을 받는 URL은 inventory에 들어가야 합니다.

2. 최종 canonical hostname을 빨리 결정

리디렉션 규칙을 쓰기 전에 최종 기준을 정하세요.

  • https://new-brand.example
  • 또는 https://www.new-brand.example

host 결정을 모호하게 두면 http -> https -> www -> final chain이 생깁니다.

3. 리디렉션 맵을 sheet 또는 CSV로 관리

최소한 다음 컬럼을 둡니다.

old_url,new_url,status,priority,owner,notes
https://old-brand.example/pricing,https://new-brand.example/pricing,301,high,marketing,core landing page
https://old-brand.example/docs/api,https://new-brand.example/docs/api,301,high,engineering,docs migration

마케팅, SEO, 개발, support가 같은 source of truth를 봐야 합니다.

4. 가장 가치 높은 URL부터 보호

먼저 볼 페이지:

  • 홈페이지
  • pricing
  • docs
  • 상위 organic landing page
  • campaign page
  • support URL linked from email

저트래픽 archive page와 상위 전환 경로를 첫날에 같은 우선순위로 다루지 마세요.

5. 기존 URL을 가장 가까운 새 목적지에 매칭

목표는 항상 path를 그대로 보존하는 것이 아닙니다. 목표는 가장 알맞은 목적지입니다.

좋은 예:

  • old product page -> new product page
  • old docs page -> equivalent docs page
  • removed campaign page -> closest current offer page

나쁜 예:

  • 모든 URL -> 홈페이지
  • 종료된 docs -> 홈페이지
  • broken deep link -> context 없는 category page

6. 영구 이동에는 영구 리디렉션 사용

기존 URL이 돌아오지 않는다면 영구 리디렉션 정책을 사용하세요.

상태 코드가 애매하다면 301, 302, 307, 308 차이를 먼저 보세요.

7. 의미 있는 path 구조는 보존

새 사이트가 비슷한 구조를 유지한다면 path-preserving rule이 수작업을 줄입니다.

  • /docs/* -> /docs/*
  • /blog/* -> /blog/*
  • /features/* -> /features/*

구조가 크게 바뀌었다면 blind wildcard 대신 고가치 path에 명시적인 1:1 mapping을 사용하세요.

8. 중요한 query string 보존

다음에는 query string 보존이 중요합니다.

  • campaign attribution
  • affiliate parameter
  • tracking 및 lifecycle link
  • app이나 page가 사용하는 functional parameter

모든 query string을 영원히 살려야 하는 것은 아니지만 중요한 값은 의도적으로 처리해야 합니다.

9. 출시 전에 리디렉션 체인 제거

PageSpeed나 사용자가 말해줄 때까지 기다리지 마세요.

old-url -> old-intermediate -> final-url

은 출시 전에:

old-url -> final-url

로 줄여야 합니다.

10. staging 또는 controlled host에서 테스트

공개 cutover 전에 다음을 테스트합니다.

  • 홈페이지
  • top landing page
  • docs path
  • blog post
  • parameterized URL
  • mobile-targeted path가 있다면 mobile path

브라우저 확인과 command-line 확인을 함께 하세요.

curl -IL https://old-brand.example/docs/api

11. 내부 링크 업데이트

리디렉션은 safety net입니다. 내부 링크는 새 canonical URL을 직접 가리켜야 합니다.

  • nav link
  • footer link
  • 본문 링크
  • product CTA
  • docs sidebar
  • public URL이 바뀌는 email template

12. sitemap, canonical, navigation 업데이트

리디렉션 맵은 이전 작업의 일부일 뿐입니다. 다음도 함께 바꿔야 합니다.

  • XML sitemap
  • canonical tag
  • hreflang이 있다면 hreflang
  • main navigation
  • structured data URL

리디렉션과 canonical이 서로 다른 말을 하면 출시 뒤 정리 작업이 늘어납니다.

13. 출시 전에 모니터링 준비

첫 7-14일 동안 볼 항목:

  • 404
  • 상위 리디렉션 URL
  • 고가치 페이지 traffic
  • campaign link
  • docs/support link

분석, 리디렉션 검사, 깨진 링크 모니터링은 출시 후에야 진짜 가치가 드러납니다.

14. 이전 리디렉션 계층을 충분히 오래 유지

리디렉션을 1주일짜리 작업으로 취급하지 마세요. 오래된 링크는 몇 달 또는 몇 년 동안 계속 traffic을 받을 수 있습니다.

  • backlink
  • bookmark
  • PDF link
  • partner docs
  • old social post

출시 주간을 버티는 것보다 오래 유지되는 운영을 계획하세요.

15. exception과 edge case 문서화

모든 URL이 리디렉션되어야 하는 것은 아닙니다. 어떤 URL은 404 또는 410이 맞습니다. legal/support page는 별도 처리가 필요할 수 있습니다. 오래된 app route는 plain redirect 대신 device-aware logic이 필요할 수 있습니다.

이런 예외를 명확히 문서화해야 나중에 “왜 이렇게 동작하지?”라는 문제가 줄어듭니다.

실무 rollout 순서

가장 짧은 실행 순서는 다음입니다.

  1. URL export
  2. canonical host 결정
  3. 리디렉션 맵 작성
  4. top URL 테스트
  5. chain 제거
  6. 내부 링크와 sitemap 업데이트
  7. 출시
  8. 404와 리디렉션된 traffic 모니터링

이 순서는 SEO, 개발, 마케팅, support 이해관계자가 같은 흐름으로 움직이게 해줍니다.

UrlEdge가 도움이 되는 부분

UrlEdge는 다음이 필요한 migration에 잘 맞습니다.

  • 대량 리디렉션 가져오기
  • wildcard path forwarding
  • 빠른 글로벌 전파
  • 리디렉션 QA 도구
  • 출시 후 traffic visibility

리디렉션 로직을 app code, reverse proxy, CMS plugin, DNS-provider forwarding 기능에 흩어두고 싶지 않을 때 특히 유용합니다.

FAQ

모든 기존 URL을 어딘가로 리디렉션해야 하나요?

아닙니다. 일부 오래된 URL은 실제 error state가 맞습니다. 하지만 비즈니스 가치나 사용자 기대가 남아 있는 페이지는 관련 있는 목적지로 매핑해야 합니다.

모든 것을 홈페이지로 보내도 되나요?

대부분 좋지 않습니다. 경로 의도를 버리고 사용자와 crawler 모두에게 약한 이전 신호를 줍니다.

이전 리디렉션은 얼마나 오래 유지해야 하나요?

대부분의 팀이 생각하는 것보다 오래 유지해야 합니다. 중요한 리디렉션은 출시 월을 훨씬 넘겨 유지해야 하는 경우가 많습니다.

시간이 부족하면 무엇부터 테스트하나요?

홈페이지, 요금제, 문서, 상위 landing page, campaign link, 과거 트래픽이 가장 강한 URL부터 확인하세요.

관련 UrlEdge 가이드

참고 자료

리디렉션 운영을 정리할 준비가 되었나요?

UrlEdge에서 도메인 이전, 캠페인 링크, 앱 fallback 경로를 edge에서 관리하세요.

시작하기

관련 글

전체 보기