도메인 포워딩에서 경로와 UTM 파라미터 유지하기

도메인을 리디렉션하면서 path와 query string을 유지하려면 리디렉션 계층이 hostname만이 아니라 전체 request URI를 전달해야 합니다. 예를 들어:

old-brand.example/pricing?plan=pro&utm_source=email

은 다음으로 도착해야 합니다.

new-brand.example/pricing?plan=pro&utm_source=email

설정이 bare domain만 forwarding한다면 사용자가 요청한 정확한 path를 잃습니다. 그러면 campaign link, deep link, 문서 페이지, SEO 이전 가치가 함께 깨질 수 있습니다.

더 큰 사이트 이전의 일부라면 먼저 웹사이트 이전 리디렉션 체크리스트를 보고, 이 글로 구현 세부사항을 정리하세요.

“path와 query string 보존”의 의미

도메인 포워딩이라고 말해도 실제 의미는 다를 수 있습니다.

Host-only forwarding

모든 요청이 새 홈페이지로 갑니다.

old-brand.example/* -> new-brand.example/

간단하지만 context를 버립니다.

Path-preserving forwarding

도메인 뒤의 path가 유지됩니다.

old-brand.example/blog/post-1 -> new-brand.example/blog/post-1

대부분의 사이트 이전에서 필요한 방식입니다.

Query-preserving forwarding

캠페인과 추적 파라미터가 유지됩니다.

old-brand.example/pricing?utm_source=kakao -> new-brand.example/pricing?utm_source=kakao

이것이 없으면 GA4, 광고 리포트, 제휴 성과 측정이 갑자기 불안정해질 수 있습니다.

DNS만으로는 부족한 이유

CNAME이나 A record 같은 DNS 레코드는 인터넷에 트래픽을 어디로 보낼지 알려줍니다. 하지만 그것만으로 브라우저에 HTTP 301 또는 302 리디렉션을 반환하지는 않습니다.

사용자와 crawler가 다른 URL에 도착하게 하려면 HTTP redirect layer가 필요합니다.

올바른 상태 코드
올바른 목적지
path forwarding
query parameter handling

그래서 도메인 포워딩은 단순 DNS 작업이 아니라 routing 작업입니다.

영구/임시 intent가 아직 정해지지 않았다면 규칙을 live로 내기 전에 301 vs 302 vs 307 vs 308 redirects를 읽어보세요.

실제 도메인 이전의 안전한 baseline

대부분의 migration에서는 다음이 기본입니다.

최종 canonical hostname을 정합니다.
HTTPS를 강제합니다.
의미 있는 old path를 새 equivalent path로 보냅니다.
중요한 query parameter를 보존합니다.
hop 수를 가능하면 하나로 유지합니다.

예:

http://old-brand.example/docs/api?ref=partner
  -> https://new-brand.example/docs/api?ref=partner

다음보다 훨씬 낫습니다.

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

path 보존이 특히 중요한 경우

사이트 이전

새 도메인이나 새 platform으로 이동할 때 old backlink와 indexed URL을 계속 쓸 수 있게 합니다.

문서와 고객센터

문서 사용자는 홈페이지가 아니라 특정 글로 들어옵니다. 모든 요청을 /로 보내면 경험이 크게 나빠집니다.

유료 캠페인

광고 링크의 tracking parameter가 사라지면 SEO와 별개로 attribution data가 바로 흔들립니다.

소셜 bio와 짧은 링크

브랜드 링크는 사실 작은 routing rule입니다. target path가 사라지면 링크 전략도 흐려집니다.

깔끔한 wildcard forwarding 모델

가장 단순한 모델은 다음과 같습니다.

source:      old-brand.example/*
destination: new-brand.example/$1

의미는 이렇습니다.

slash 뒤의 값을 가져옵니다.
destination path에 삽입합니다.
요청 구조를 유지합니다.

요청	목적지
`/about`	`/about`
`/blog/post-1`	`/blog/post-1`
`/pricing/enterprise`	`/pricing/enterprise`

query string도 보존하면:

/pricing/enterprise?utm_source=partner

는 그대로:

/pricing/enterprise?utm_source=partner

가 됩니다.

현재 포워딩 계획이 최종 페이지까지 두세 hop을 만든다면 출시 전에 고쳐야 합니다. 리디렉션 체인과 루프 가이드에서 확인 방법을 볼 수 있습니다.

포워딩 실수를 줄이는 네 가지 점검

1. 최종 hostname을 먼저 확정

둘 중 하나를 고르세요.

new-brand.example
www.new-brand.example

migration 중간에 결정하지 마세요. 그 방식이 chain을 만듭니다.

2. 상태 코드 결정

영구 이전이면 301 같은 permanent code를 사용합니다. 임시라면 302 같은 temporary code를 사용합니다.

3. query handling을 명시

모든 provider가 query string을 자동 보존한다고 가정하지 마세요. 실제 예시로 테스트해야 합니다.

curl -I 'https://old-brand.example/pricing?plan=pro&utm_source=email'

Location header에 기대한 path와 parameter가 들어 있는지 확인합니다.

4. root와 deep URL 모두 테스트

/만 테스트하면 부족합니다.

/docs/api
/blog/post-slug
/pricing/enterprise
/old-category/product-123

같은 깊은 URL을 확인하세요.

HTTPS와 SSL도 redirect의 일부

좋지 않은 migration 결과 중 하나는 이렇습니다.

redirect rule은 맞음
하지만 old domain의 HTTPS가 깨짐
사용자는 redirect 전에 인증서 오류를 봄

자동 SSL이 중요한 이유입니다. redirect flow는 routing logic 뒤가 아니라 첫 요청에서 시작합니다.

UrlEdge 무료 리디렉션 서비스는 자동 HTTPS와 wildcard forwarding을 포함합니다.

흔한 실수

홈페이지만 리디렉션

“홈페이지는 잘 열리는데요”는 출시 실수의 전형입니다. 실제 사용자는 /만 방문하지 않습니다.

non-www와 root-domain을 놓침

old-brand.example, www.old-brand.example, scope에 포함된 subdomain을 함께 설계해야 합니다.

campaign parameter를 삭제

SEO가 괜찮아 보여도 attribution data는 하루아침에 신뢰하기 어려워질 수 있습니다.

여러 hop 생성

path forwarding은 final page까지 bounce가 많으면 가치가 줄어듭니다.

UrlEdge setup pattern

일반적인 영구 이전은 이렇게 시작합니다.

old domain 연결
HTTPS 활성화
wildcard redirect rule 생성
path 보존
필요한 query parameter 보존
리디렉션 검사기로 상위 페이지 테스트

Nginx, Apache, app middleware를 다시 배포하지 않고 이전을 처리하려는 팀에 특히 유용합니다.

FAQ

Naked domain도 path를 유지하며 redirect할 수 있나요?

예. redirect layer가 root-domain forwarding과 path preservation을 지원하면 가능합니다.

query string은 항상 보존해야 하나요?

항상은 아닙니다. 하지만 tracking, campaign, 기능상 필요한 parameter는 의도적으로 보존하세요. junk parameter는 확신이 있을 때만 제거하세요.

wildcard forwarding이면 모든 이전에 충분한가요?

아닙니다. path 구조가 크게 바뀐 이전은 고가치 URL에 1:1 mapping이 필요합니다.

DNS를 전체 전환하기 전에 테스트할 수 있나요?

예. staging이나 controlled host에서 먼저 테스트한 뒤 실제 path 샘플을 검증하세요.

무료로 시작하기

문서