랜딩페이지 도메인 연결: 광고 전 확인할 4단계 기준

랜딩페이지 도메인 연결은 주소창을 예쁘게 바꾸는 작업이 아닙니다.

광고 매체가 이 페이지를 누구의 것으로 인식할지, 그리고 광고 클릭 데이터가 전환까지 끊기지 않고 이어질지를 정하는 작업입니다.

랜딩페이지 도메인 연결에서 가장 중요한 건 DNS 설정보다 연결 구조를 먼저 정하는 것입니다.

루트 도메인을 쓸지 서브도메인을 쓸지, www를 어느 쪽으로 보낼지부터 정해야 합니다. 그래야 SSL·리다이렉트·광고 측정 설정이 한 번에 맞아떨어집니다.

아래에서 구조 결정 → DNS 레코드 → SSL·리다이렉트 → 광고 측정 재점검까지 4단계로 설명합니다.

1. 랜딩페이지 도메인 연결 전에 정할 것: 루트·서브도메인 구조

랜딩페이지 빌더나 쇼핑몰 솔루션에 도메인을 연결할 때,

대부분은 설정 화면부터 엽니다. 그리고 "어떤 주소를 입력할까요?"라는 칸에서 멈춥니다.

이 칸에 무엇을 넣느냐에 따라 이후 DNS 레코드 종류, SSL 발급 방식, 광고 매체 도메인 인증 범위가 전부 달라집니다.

그래서 연결 작업 전에 구조부터 정해야 합니다.

루트 도메인 vs 서브도메인

랜딩페이지 주소는 크게 두 가지 형태로 나뉩니다.

광고 실무에서 가장 많이 쓰는 형태는 세 번째, 용도별 서브도메인입니다.

메인 사이트는 쇼핑몰 솔루션에 두고, 광고용 랜딩만 별도 빌더로 만들어 lp.brand.com 같은 주소로 붙이는 방식입니다.

이 방식의 장점은 메인 사이트 DNS를 건드리지 않는다는 점입니다.

루트 도메인의 A 레코드를 바꾸면 메인 사이트가 통째로 랜딩페이지로 넘어가는 사고가 생길 수 있습니다. 서브도메인은 레코드 하나만 추가하면 되기 때문에 기존 사이트에 영향이 없습니다.

루트 도메인에 CNAME을 못 거는 이유

자주 막히는 지점이 하나 있습니다.

빌더가 "CNAME으로 연결하세요"라고 안내하는데, 루트 도메인(brand.com)에는 CNAME이 입력되지 않는 경우입니다.

이건 설정 오류가 아니라 DNS 표준 자체의 제약입니다.

루트 도메인에는 이미 NS·SOA 같은 필수 레코드가 있어서, 다른 레코드와 공존할 수 없는 CNAME을 원칙적으로 둘 수 없습니다.

해결 방법은 세 가지입니다.

① 빌더가 안내하는 IP 주소로 A 레코드를 건다

② DNS 업체가 지원하면 ALIAS·ANAME·CNAME 플래트닝 기능을 쓴다

③ 루트는 www로 리다이렉트시키고, 실제 랜딩은 www에 CNAME으로 연결한다

-> 핵심: 광고 랜딩만 분리할 목적이면 처음부터 서브도메인을 쓰는 편이 가장 단순합니다.

www와 non-www, 하나만 정답으로 정하기

brand.com과 www.brand.com은 사람 눈에는 같은 주소지만, 브라우저와 광고 매체에는 다른 주소입니다.

둘 다 열리는 상태로 두면 두 가지 문제가 생깁니다.

첫째, 쿠키가 나뉘어 저장되면서 같은 방문자가 두 명으로 잡힐 수 있습니다.

둘째, 광고 소재에는 www 주소를 넣고 픽셀 이벤트는 non-www에서 발생하는 식으로 주소가 엇갈리면, 매체 쪽 도메인 매칭에서 혼선이 생깁니다.

그래서 둘 중 하나를 대표 주소(정규 주소)로 정하고, 나머지는 301 리다이렉트로 대표 주소로 보내야 합니다.

어느 쪽을 고르든 상관없습니다. 중요한 건 광고 소재·픽셀·GA4·검색 콘솔에 전부 같은 주소를 쓰는 것입니다.

2. DNS 레코드 설정 순서: A·CNAME·TXT 3가지 기준

구조를 정했다면, 이제 도메인을 구매한 곳(또는 네임서버를 옮긴 곳)의 DNS 관리 화면에서 레코드를 추가합니다.

여기서 먼저 확인할 것이 있습니다.

도메인 구매처와 실제 DNS 관리처가 다를 수 있습니다.

도메인을 국내 등록업체에서 샀더라도, 네임서버를 CDN 서비스나 호스팅 업체로 옮겨뒀다면 레코드는 그쪽에서 수정해야 합니다.

구매처 화면에서 아무리 레코드를 추가해도 반영되지 않는 경우, 대부분 이 문제입니다. 네임서버가 어디를 가리키는지부터 확인하면 시간을 크게 줄일 수 있습니다.

A 레코드: 루트 도메인을 IP로 연결

💡

A 레코드는 도메인을 특정 서버 IP 주소에 직접 연결하는 레코드

호스트 칸은 @ 또는 비워두기(루트 의미), 값에는 빌더가 안내한 IP 입력

빌더가 IP를 2개 이상 안내하면 전부 입력해야 함

기존에 같은 호스트로 걸려 있던 A 레코드가 있다면 삭제 후 입력

기존 A 레코드를 지우지 않고 새 레코드를 추가하면, 요청이 두 서버로 번갈아 가면서 "어떤 때는 열리고 어떤 때는 안 열리는" 현상이 생깁니다.

이 증상은 접속하는 위치와 시점마다 결과가 달라서 원인을 찾기가 특히 어렵습니다.

CNAME 레코드: 서브도메인을 빌더 주소로 연결

💡

CNAME은 도메인을 다른 도메인 이름으로 연결하는 레코드

호스트 칸에는 lp, event, www처럼 서브도메인 앞부분만 입력

값에는 빌더가 안내한 주소 입력 (예: xxx.빌더도메인.com)

같은 호스트에 A 레코드나 다른 CNAME이 있으면 충돌하므로 먼저 정리

자주 나오는 실수는 호스트 칸에 lp.brand.com 전체를 입력하는 것입니다.

DNS 관리 화면에 따라 자동으로 뒤에 도메인을 붙이기 때문에, 결과적으로 lp.brand.com.brand.com이라는 엉뚱한 주소가 만들어집니다.

입력 후 화면에 표시되는 최종 주소를 반드시 한 번 더 확인해야 합니다.

TXT 레코드: 소유권 인증용

TXT 레코드는 페이지를 연결하는 레코드가 아니라 "이 도메인의 주인이 맞다"는 것을 증명하는 레코드입니다.

랜딩페이지 빌더, 메타 비즈니스 관리자, 구글 검색 콘솔, 이메일 발송 서비스 등이 모두 TXT 레코드로 소유권을 확인합니다.

TXT 레코드는 같은 호스트에 여러 개를 둘 수 있습니다.

기존 인증용 TXT가 있다고 지우고 새로 넣으면, 이전에 인증해둔 서비스의 인증이 풀립니다. 추가만 하고 삭제는 하지 않는 것이 원칙입니다.

반영 시간: TTL과 전파 대기

레코드를 저장한 직후 접속이 안 되는 건 정상입니다.

DNS 변경은 전 세계 DNS 서버에 퍼지는 시간이 필요하고, 이 시간은 TTL(캐시 유지 시간) 값의 영향을 받습니다.

TTL이 3600초로 걸려 있었다면, 이전 값을 기억하는 서버가 최대 1시간 동안 예전 주소를 안내할 수 있습니다. 네임서버 자체를 변경한 경우에는 업계에서 통상 최대 24~48시간까지 잡습니다.

실무에서 쓰는 요령은 이렇습니다.

연결 작업 하루 전에 기존 레코드의 TTL을 300초 정도로 낮춰둡니다.

그러면 실제 변경 시점에는 캐시가 짧아져 있어서, 반영과 롤백이 모두 빨라집니다. 작업이 끝나고 안정되면 TTL을 다시 올려도 됩니다.

-> 핵심: 광고 집행일 당일에 DNS를 바꾸지 않는 것이 가장 확실한 안전장치입니다.

3. SSL·리다이렉트 점검: 광고 파라미터가 사라지는 지점

DNS가 연결되어 페이지가 열리면 끝났다고 생각하기 쉽습니다.

하지만 광고 랜딩페이지 기준으로는 이제 절반입니다. 남은 절반은 HTTPS가 정상 발급됐는지, 그리고 리다이렉트 과정에서 광고 파라미터가 살아남는지입니다.

SSL 인증서 발급 확인

대부분의 랜딩페이지 빌더는 도메인 연결이 확인되면 SSL 인증서를 자동 발급합니다.

문제는 DNS가 완전히 반영되기 전에 발급을 시도하면 실패하고, 일부 빌더는 실패 후 재시도를 자동으로 하지 않는다는 점입니다.

이 경우 페이지는 http로는 열리는데 https로 접속하면 "안전하지 않음" 경고가 뜹니다.

광고 매체는 대부분 https 랜딩을 기본으로 요구하고, 브라우저 경고 화면이 뜨면 클릭한 사용자 대부분이 그 자리에서 이탈합니다. 광고비는 클릭 시점에 이미 과금된 뒤입니다.

점검 기준은 세 가지입니다.

① https:// 로 직접 접속했을 때 자물쇠 아이콘이 정상 표시되는가

② http:// 로 접속하면 https로 자동 전환되는가

③ www와 non-www 양쪽 모두 인증서가 적용되어 있는가 (한쪽만 발급되는 경우가 흔함)

세 번째가 특히 자주 빠집니다. 인증서가 대표 주소에만 발급되어 있으면, 리다이렉트 대상 주소에서 경고가 먼저 뜨고 리다이렉트까지 가지 못합니다.

리다이렉트 체인과 UTM 유실

광고 클릭 한 번에 리다이렉트가 여러 번 일어나는 구조를 리다이렉트 체인이라고 합니다.

예를 들어 이런 흐름입니다.

http://brand.com → https://brand.com → https://www.brand.com → https://www.brand.com/event

리다이렉트가 한 번 일어날 때마다 두 가지 손실이 생길 수 있습니다.

첫째, 페이지 로딩이 그만큼 늦어집니다. 모바일 환경에서는 체감 차이가 큽니다.

둘째, 리다이렉트 설정이 쿼리스트링을 넘기지 않으면 utm 파라미터, gclid, fbclid가 중간에 잘려 나갑니다.

이렇게 되면 광고 클릭은 매체에 정상 집계되는데, GA4에서는 해당 유입이 다이렉트나 (not set)으로 잡힙니다. 매체 전환과 GA4 전환이 맞지 않는 원인 중 상당수가 이 지점에서 발생합니다.

파라미터가 실제로 어느 구간에서 사라지는지 단계별로 확인하는 방법은 UTM 붙였는데 안잡힘: 파라미터가 사라지는 4구간 진단 순서에서 자세히 다룹니다.

실무 점검 방법

도메인 연결 후에는 광고에 넣을 최종 URL에 테스트용 파라미터를 붙여 직접 접속해봅니다.

💡

테스트 주소 예시: 대표주소/?utm_source=test&utm_medium=test&utm_campaign=domain_check

http, non-www 등 대표 주소가 아닌 변형 주소에도 같은 파라미터를 붙여 각각 접속

도착한 페이지 주소창에 파라미터가 그대로 남아 있는지 확인

GA4 실시간 보고서에서 source가 test로 잡히는지 확인

리다이렉트는 반드시 301(영구 이동)로 설정하고, 체인은 1회 이내로 줄이는 것을 기준으로 잡습니다.

302(임시 이동)는 이벤트 기간 한정 페이지처럼 실제로 임시인 경우에만 씁니다.

실제로 자주 보는 실패 사례

한 브랜드의 경우, 프로모션 시작에 맞춰 기존 랜딩을 새 빌더로 옮기면서 도메인 연결을 집행 당일 오전에 진행했습니다.

페이지는 오전 중에 정상적으로 열렸고, 광고도 예정대로 켜졌습니다.

그런데 이틀 뒤 리포트를 보니 매체 클릭 대비 GA4 광고 유입이 눈에 띄게 적었습니다.

원인은 두 가지가 겹친 것이었습니다.

광고 소재에는 non-www 주소가 들어가 있었고, 새 빌더는 www로 리다이렉트하면서 쿼리스트링을 버리는 기본 설정이었습니다. 동시에 non-www 쪽 SSL은 아직 발급 대기 상태여서, 일부 사용자에게는 경고 화면이 먼저 노출됐습니다.

광고 성과가 떨어진 게 아니라, 클릭 이후 데이터가 끊긴 것이었습니다.

이런 사례에서 공통적으로 확인되는 건 하나입니다. 도메인 연결 확인을 "페이지가 열린다"에서 멈추면 안 된다는 것입니다.

4. 랜딩페이지 도메인 연결 후 광고 측정 재점검 4가지

도메인이 바뀌면 광고 매체 입장에서는 완전히 새로운 웹사이트가 생긴 것과 같습니다.

그래서 도메인 연결 직후, 광고를 켜기 전에 측정 설정을 다시 확인해야 합니다.

① 메타 도메인 인증 범위 확인

메타 비즈니스 관리자의 도메인 인증은 루트 도메인 기준으로 이뤄집니다.

brand.com을 인증해두었다면 lp.brand.com 같은 서브도메인도 같은 소유로 인식됩니다. 반대로 별도 도메인(brand-event.com 등)을 새로 샀다면, 그 도메인은 처음부터 다시 인증해야 합니다.

인증 방식(DNS TXT, 메타 태그, HTML 파일 업로드) 중 랜딩페이지 빌더 환경에서 무엇을 쓸 수 있는지는 빌더마다 다릅니다. 방식별 선택 기준과 실패 원인은 메타 도메인 인증: 방식별 선택 기준과 실패 원인 정리에 정리되어 있습니다.

② 픽셀·태그가 새 도메인에서 발화하는지

빌더를 옮기면서 도메인을 연결한 경우, 기존 사이트에 심어둔 픽셀과 GTM 컨테이너가 새 랜딩에는 없을 수 있습니다.

메타 이벤트 관리자의 테스트 이벤트, GA4 디버그 뷰를 켜고 새 도메인에서 페이지 조회와 전환 이벤트가 실제로 들어오는지 확인합니다.

이벤트가 들어오더라도 "어느 도메인에서 발생했는지"가 대표 주소와 일치하는지까지 봐야 합니다.

③ 광고 소재의 최종 URL·표시 URL 교체

구글 광고는 최종 URL과 표시 URL의 도메인이 일치해야 하고, 도메인이 바뀌면 광고가 다시 검토에 들어갑니다.

기존 광고의 URL만 수정하면 되지만, 광고 단위로 검토가 다시 진행되기 때문에 집행 직전에 바꾸면 노출이 잠시 멈출 수 있습니다.

메타 광고도 마찬가지로 소재의 웹사이트 URL을 대표 주소로 교체해야 합니다. 이때 앞서 정한 대표 주소(www 여부 포함)를 정확히 맞추는 것이 중요합니다.

④ 랜딩과 결제 페이지 도메인이 다를 때

광고 랜딩은 lp.brand.com, 결제는 쇼핑몰 솔루션의 다른 도메인에서 일어나는 구조라면 추가 점검이 필요합니다.

도메인이 완전히 다르면 브라우저 쿠키가 공유되지 않기 때문에, GA4에서는 랜딩 방문과 결제가 서로 다른 세션으로 끊길 수 있습니다. 이 경우 GA4 교차 도메인 설정에 두 도메인을 모두 등록해야 합니다.

반대로 lp.brand.com과 shop.brand.com처럼 같은 루트 도메인 아래 서브도메인끼리라면, 대부분 별도 설정 없이 쿠키가 공유됩니다.

-> 핵심: 가능하면 랜딩과 결제를 같은 루트 도메인 아래에 두는 것이 측정 측면에서 가장 안전합니다.

점검 순서 한눈에 보기

도메인 연결과 별개로, 연결된 랜딩페이지 자체가 소재 메시지와 맞게 설계되어 있는지도 함께 봐야 합니다. 구조 설계 기준은 광고 랜딩페이지 만드는 법: 소재와 맞추는 4단계 설계 기준을 참고하면 됩니다.

자주 묻는 질문

Q. 랜딩페이지 도메인 연결 후 반영까지 얼마나 걸리나요?

레코드 추가만 했다면 기존 TTL 값만큼, 보통 수 분에서 1시간 안에 대부분 반영됩니다. 네임서버 자체를 바꿨다면 통상 최대 24~48시간까지 잡는 것이 안전합니다. 광고 집행 최소 하루 전에 작업을 끝내는 것을 권장합니다.

Q. 루트 도메인에 CNAME이 입력되지 않는 이유는 무엇인가요?

DNS 표준상 루트 도메인에는 NS·SOA 등 필수 레코드가 있어 CNAME과 공존할 수 없기 때문입니다. 빌더가 안내하는 IP로 A 레코드를 걸거나, DNS 업체의 ALIAS 기능을 쓰거나, 서브도메인으로 연결하는 방법 중 하나를 선택하면 됩니다.

Q. 도메인 연결 후 https에서 '안전하지 않음' 경고가 뜨는 이유는?

DNS가 완전히 반영되기 전에 SSL 발급이 시도되어 실패했을 가능성이 높습니다. 빌더 설정에서 인증서를 재발급하고, www와 non-www 양쪽 모두 인증서가 적용됐는지 확인해야 합니다.

Q. 랜딩페이지 도메인을 바꾸면 메타 픽셀을 새로 설치해야 하나요?

픽셀 자체는 같은 것을 써도 되지만, 새 도메인 페이지에 픽셀 코드가 실제로 설치되어 있어야 합니다. 루트 도메인이 바뀌었다면 메타 도메인 인증도 새로 해야 하고, 테스트 이벤트로 수신 여부를 반드시 확인해야 합니다.

Q. 도메인 리다이렉트 후 UTM이 사라지는 이유는?

리다이렉트 설정이 쿼리스트링을 함께 넘기지 않거나, 리다이렉트가 여러 번 연속으로 일어나면서 중간 단계에서 파라미터가 잘리는 경우가 대부분입니다. 광고에는 리다이렉트가 없는 대표 주소를 직접 넣는 것이 가장 확실한 해결책입니다.

마무리

랜딩페이지 도메인 연결은 DNS 설정 화면에서 끝나는 작업이 아닙니다.

구조 결정 → DNS 레코드 → SSL·리다이렉트 → 광고 측정 재점검

이 4단계를 거쳐야 페이지가 열리는 것을 넘어 광고 데이터까지 온전히 이어집니다.

특히 광고 성과가 갑자기 떨어진 것처럼 보이는데 매체 클릭은 정상이라면, 소재를 바꾸기 전에 도메인과 리다이렉트 구간부터 확인해보는 것이 순서입니다.

도메인 작업은 광고 집행일과 분리하고, 테스트 파라미터로 끝까지 따라가 보는 습관 하나만으로도 측정 사고 대부분을 막을 수 있습니다.