UrlEdge
블로그로 돌아가기
2026년 5월 17일 UrlEdge Editorial4 min read

www, apex, wildcard forwarding에서 SEO를 망치지 않는 방법

Host normalization은 작아 보이지만 root, www, subdomain, path, query가 따로 움직이면 redirect chain이 됩니다. canonical host를 먼저 정해야 합니다.

apex, www, wildcard subdomain이 하나의 canonical host로 정리되는 host normalization map

Host normalization은 작은 DNS 작업처럼 보입니다. 하지만 migration이나 rebrand에서 실제 트래픽을 받으면 곧 URL policy 문제가 됩니다.

브랜드는 apex domain을 원합니다. 기존 사이트는 www를 씁니다. docs나 campaign은 subdomain에 있습니다. agency는 wildcard forwarding을 요청합니다. 광고 링크는 path와 UTM을 보존해야 합니다. 이 결정들이 따로 내려지면 redirect chain이 생깁니다.

중요한 질문은 www와 apex 중 무엇이 항상 더 나은가가 아닙니다. 어떤 host를 canonical로 삼고, 나머지 variant를 어떻게 따라오게 할 것인가입니다.

더 큰 migration의 일부라면 먼저 Website Migration Redirect Checklist를 보세요. 이 글은 host layer에 집중합니다.

Host는 URL policy의 일부입니다

example.kr, www.example.kr, *.example.kr는 운영상 같지 않습니다.

  • apex는 marketing에서 더 깔끔해 보일 수 있습니다.
  • www는 오래된 stack에서 자연스러울 수 있습니다.
  • subdomain은 product, docs, support, shop일 수 있습니다.
  • wildcard는 여러 host를 하나의 rule로 다룰 때 좋습니다.

중요한 것은 이 선택을 우연에 맡기지 않는 것입니다.

Host normalization map for apex, www, and wildcard subdomains

launch 전에 canonical host를 정하세요

일찍 정해야 할 것:

질문중요한 이유
공개 사이트는 apex인가 www인가보이는 canonical URL이 결정됨
어떤 subdomain이 alias인가모든 subdomain을 합치면 안 됨
path를 보존할 것인가SEO, bookmark, deep link에 영향
query string을 보존할 것인가UTM, coupon, ID가 사라질 수 있음
temporary exception이 있는가캠페인과 launch는 다른 rule이 필요할 수 있음

이 답이 모호하면 여러 layer가 동시에 redirect를 추가합니다.

DNS만으로는 부족합니다

DNS는 traffic이 어디로 갈지 알려줍니다. 사용자가 보는 URL 변경까지 결정하지는 않습니다.

좋은 흐름:

http://www.old-brand.example/pricing?utm_source=email
  -> https://new-brand.example/pricing?utm_source=email

나쁜 흐름:

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

한 번의 hop이 테스트와 유지보수에 훨씬 좋습니다.

Wildcard forwarding은 구조가 맞을 때 좋습니다

path 구조가 크게 바뀌지 않았다면 wildcard rule이 유용합니다.

old.example.kr/* -> new.example.kr/$1

적합한 경우:

  • 보존해야 할 old URL이 많음
  • path 구조가 거의 같음
  • 페이지마다 rule을 쓰고 싶지 않음
  • old subdomain이 실제 alias임

정보 구조가 많이 바뀌었다면 중요한 URL은 명시적으로 mapping하세요.

path와 query를 유지하세요

host를 바꾸면서 request context를 지우면 안 됩니다.

http://old.example.kr/docs/api?ref=partner&utm_source=newsletter

구조가 맞다면 다음으로 끝나야 합니다.

https://new.example.kr/docs/api?ref=partner&utm_source=newsletter

중요한 대상:

  • SEO page
  • documentation
  • paid campaign
  • affiliate link
  • bookmark

path나 query가 사라지면 redirect는 기술적으로 맞아 보여도 가치가 떨어집니다.

chain을 피하세요

흔한 실패:

  • HTTP to HTTPS가 한 layer
  • www to apex가 다른 layer
  • domain migration이 CDN 또는 hosting
  • app이 canonical rule을 추가

결과는 http -> https -> www -> final입니다.

현재 stack이 이 모양이라면 Redirect Chains and Loops를 같이 보세요.

launch matrix를 테스트하세요

공개 전 실제 variant를 확인합니다.

TestExample
Apex roothttps://example.kr/
www roothttps://www.example.kr/
Deep pathhttps://example.kr/pricing
Deep path with queryhttps://example.kr/pricing?utm_source=email
Old host with pathhttps://old.example.kr/blog/post-1
Wildcard subdomainhttps://docs.example.kr/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

확인할 것:

  • final host가 의도한 host인지
  • path가 유지되는지
  • query가 유지되는지
  • status code가 맞는지
  • extra hop이 없는지

UrlEdge가 맞는 경우

UrlEdge는 host normalization을 server snippet이 아니라 routing policy로 관리하고 싶을 때 맞습니다.

canonical host, variant, path, query, status code를 한 곳에서 관리하는 것이 장점입니다.

FAQ

항상 apex를 써야 하나요?

아닙니다. apex와 www 모두 가능합니다. 중요한 것은 하나를 canonical로 정하고 나머지가 깨끗하게 따르게 하는 것입니다.

wildcard subdomain을 하나의 rule로 처리할 수 있나요?

구조가 맞으면 가능합니다. 크게 바뀌었다면 중요한 URL은 명시적으로 mapping하세요.

DNS만으로 충분한가요?

아닙니다. DNS는 사용자가 보는 HTTP redirect policy를 대체하지 않습니다.

campaign parameter는 유지해야 하나요?

대개 유지해야 합니다. 잃어버린 attribution은 나중에 복구하기 어렵습니다.

참고

Canonical host를 한 번에 정리하세요

root, www, wildcard subdomain을 자동 HTTPS, path preservation, query preservation과 함께 관리합니다.

Free Redirect Service 사용해보기

관련 글

전체 보기