트래픽 검증: 링크가 올바른 도메인으로 연결되는지 확인하는 방법

올바른 도메인으로의 전환이란 무엇인가

트래픽이 올바른 도메인으로 유입된다는 것은 사용자가 모든 리디렉트를 거친 후 목표 호스트의 페이지를 여는 것을 의미합니다. 스트림 설명, 프로필 또는 광고에 삽입된 주소만 확인하는 것으로는 부족합니다. 링크는 단축 서비스, 트래커, 이전 도메인, 중간 랜딩 페이지 또는 지역 리디렉트를 거칠 수 있습니다.

도메인 이름뿐만 아니라 그 변형도 확인하세요: www와 www 없는 버전, HTTP와 HTTPS, 기본 도메인과 서브도메인. site.example, www.site.example, promo.site.example 주소는 하나의 프로젝트에 속할 수 있지만 브라우저, 분석, 로그에서는 서로 다른 호스트입니다.

오디언스가 링크를 여는 방식대로 링크를 여세요

실제 게시 위치에서 링크를 따라가세요: 방송 설명, 프로필, 고정 메시지, 게시물 또는 광고에서. 페이지가 로드된 후 주소 표시줄을 확인하세요. 중요한 것은 게시물의 원래 주소가 아니라 브라우저에 남은 URL입니다.

• 최종 호스트를 랜딩 페이지의 도메인과 대조하세요.
• 경로를 확인하세요: 링크가 올바른 도메인으로 연결되더라도 오래된 섹션으로 연결될 수 있습니다.
• 모바일 전환이 기술 서브도메인으로 이동하지 않는지 확인하세요.
• UTM 태그가 있는 링크와 없는 링크의 결과를 비교하세요.
• 모든 전환 후 캠페인 파라미터가 유지되었는지 확인하세요.

수동 확인의 단점: 하나의 시나리오만 보여줍니다 — 여러분의 브라우저, 기기, 지역, 쿠키 세트만요. 일부 오디언스에게는 규칙이 다르게 작동할 수 있습니다.

브라우저와 curl을 통해 전체 리디렉트 체인을 확인하세요

기술적 확인을 위해서는 -I와 -L 파라미터를 사용한 curl을 사용하세요: 명령이 응답 헤더를 보여주고 리디렉트를 따라갑니다. 301, 302, 307, 308 상태와 Location 헤더를 찾으세요. 이들은 각 단계에서 서버가 사용자를 어느 주소로 보내는지 보여줍니다.

실제 브라우저에서 확인하려면 개발자 도구를 열고 Network 탭으로 이동하여 Preserve log를 활성화하세요. 그런 다음 원본 링크를 여세요. 요청 목록에서 리디렉트, 최종 문서, 그리고 페이지 로드 후 실행되는 요청들을 볼 수 있습니다.

1. 리디렉트 후 목록이 지워지지 않도록 Preserve log를 활성화하세요.
2. 필요한 경우 브라우저 캐시를 비활성화하세요.
3. 게시물의 원본 링크를 열거나 새 탭에 붙여넣으세요.
4. 3xx 상태의 응답을 찾으세요.
5. 각 단계의 Request URL을 Location 값과 대조하세요.
6. 상태 200인 마지막 문서의 도메인과 URL을 확인하세요.

체인의 이전 도메인이 정상일 때와 오류일 때

체인의 이전 도메인이 항상 문제를 의미하지는 않습니다. 이전 후 old-site.example/stream → site.example/stream 같은 경로는 정상입니다: 이전 주소가 요청을 받아 지속적으로 사용자를 새 사이트의 동등한 페이지로 리디렉트합니다. 최종 도메인은 올바르고 경로는 유지되며 UTM 태그도 사라지지 않습니다.

버그는 old-site.example/stream이 새 사이트의 메인 페이지로, 다른 랜딩 페이지로 연결되거나 사용자를 이전 도메인에 남겨두는 상황입니다. 별도의 문제는 리디렉트 후 물음표 뒤의 문자열이 사라질 때 발생합니다: 사용자는 올바른 페이지에 도달하지만 분석은 utm_source, utm_medium, utm_campaign을 잃습니다.

마지막 도메인뿐만 아니라 파라미터가 있는 경로도 확인하세요. 필요한 페이지나 태그 없이 site.example로 전환되는 것은 다른 호스트로 전환되는 것만큼이나 캠페인 데이터를 왜곡할 수 있습니다.

JavaScript 리디렉트와 링크 파라미터를 고려하세요

curl은 서버 응답에 편리하지만 페이지 로드 후 스크립트로 실행되는 리디렉트를 항상 보지는 못합니다. 브라우저의 DevTools는 이런 시나리오를 발견하는 데 도움이 됩니다: 먼저 중간 페이지가 열리고, 그 다음 스크립트가 주소를 변경하거나 사용자를 다른 도메인으로 보냅니다.

Network에서 기본 문서뿐만 아니라 로드 후 주소가 변경되는 시점도 확인하세요. UTM 태그가 사라졌다면 원본 URL, Location 값, 주소 표시줄의 최종 문자열을 비교하세요. 이렇게 하면 어느 단계에서 리디렉트 규칙이 파라미터를 버렸는지 알 수 있습니다.

확인 없이 모든 파라미터를 전달하는 것의 단점: 목표 도메인에 불필요한 서비스 값이 들어갈 수 있습니다. 중요한 링크의 경우 어떤 태그, 프로모 코드, 제휴 파라미터가 유지되어야 하는지 미리 정의해야 합니다.

앱의 인앱 브라우저를 확인하세요

소셜 네트워크, 메신저, 스트리밍 플랫폼은 종종 기기의 기본 브라우저가 아닌 인앱 브라우저에서 링크를 엽니다. 이러한 브라우저는 다른 user-agent를 전달하거나, 스크립트를 제한하거나, 쿠키를 저장하지 않거나, 리디렉트를 다르게 처리할 수 있습니다.

링크가 게시된 플랫폼의 앱에서 직접 링크를 여세요. 그런 다음 사용 가능한 경우 "브라우저에서 열기" 항목을 통해 테스트를 반복하세요. 최종 도메인, 경로, UTM 태그, 그리고 양식, 결제, 인증의 동작을 비교하세요.

인앱 브라우저에서의 확인 단점: 모든 앱이 기술적 요청 체인을 볼 수 있게 해주지는 않습니다. 그럼에도 중요합니다. 모바일 오디언스가 자주 이렇게 전환하기 때문입니다.

다양한 지역과 조건에서의 전환을 비교하세요

사이트가 지역 리디렉트, CDN 또는 다양한 랜딩 페이지 버전을 사용하는 경우 원하는 지역의 VPN, 프록시 또는 원격 기기를 통해 확인을 반복하세요. 최종 도메인, 경로, URL 파라미터, 랜딩 페이지 콘텐츠를 비교하세요.

국가뿐만 아니라 브라우저 언어, 인증, 쿠키, 기기 유형도 확인하세요. 이러한 조건이 경로에 영향을 미칠 수 있습니다: 예를 들어 한 지역의 사용자는 로컬 서브도메인으로 보내지고 쿠키가 없는 방문자는 공통 랜딩 페이지로 보내질 수 있습니다.

VPN과 프록시의 단점: 실제 시청자의 조건을 항상 완전히 재현하지는 못합니다. 지리적 위치는 여러 신호로 판단될 수 있으므로 이러한 테스트는 가능한 문제를 확인하지만 전체 오디언스를 포괄하지는 않습니다.

Yandex Metrica와 GA4에서 도메인을 확인하세요

Yandex Metrica에서는 진입 페이지 및 페이지 URL 보고서를 확인하세요. 전체 주소 또는 원하는 도메인으로 데이터를 필터링한 다음 UTM 태그, 소스 또는 캠페인별 세그먼트를 추가하세요. 이렇게 하면 특정 게시 후 어느 호스트에서 방문이 시작되었는지 볼 수 있습니다.

GA4에서 이러한 확인을 위해서는 랜딩 페이지, 세션 소스, 캠페인과 함께 Hostname 측정기준을 사용하세요. 기본 도메인, 이전 주소, 중요한 서브도메인에 얼마나 많은 세션이 도달했는지 비교하세요. 태그가 여러 호스트에 설치된 경우 보고서가 트래픽 혼합을 빠르게 보여줍니다.

분석의 단점: 카운터는 차단기, 비활성화된 JavaScript 또는 태그 로드 전 페이지 닫기로 인해 일부 방문을 기록하지 못합니다. 또한 카운터가 전혀 설치되지 않은 도메인에 대해서는 데이터가 도움이 되지 않습니다.

서버 로그에서 요청을 확인하세요

서버 로그는 어떤 요청이 실제로 사이트 인프라에 도달했는지 확인해 줍니다. 확인을 위해서는 시간, Host, URL, 응답 코드, user-agent, 그리고 전달되는 경우 referer 필드가 필요합니다. 링크 실행 기간의 요청을 찾고 이전 도메인과 목표 도메인에 대한 요청을 별도로 확인하세요.

301, 302, 307, 308 응답은 서버가 사용자를 리디렉트했음을 보여줍니다. 목표 호스트에 대한 상태 200 요청은 페이지가 올바른 도메인에서 제공되었음을 확인해 줍니다. 로그에 이전 호스트로의 전환은 있지만 새 호스트에 대한 요청이 없다면 리디렉트 규칙과 가능한 연결 오류를 확인하세요.

로그의 단점: 봇, 스캐너, 기술적 요청이 포함됩니다. Referer는 앱과 메신저에서의 전환 시 종종 없기 때문에 특정 방문의 소스를 항상 복원할 수는 없습니다.

보고서에서 기본 도메인과 서브도메인을 구분하세요

랜딩 페이지, 개인 계정, 결제, 지식 베이스는 서로 다른 서브도메인에 있을 수 있습니다. 세그먼트 없이 하나의 보고서에 이들을 모으면 스트림의 링크가 기본 사이트 대신 promo.site.example로 연결되거나 제안을 알기 전에 checkout.site.example로 연결되는 것을 놓칠 수 있습니다.

목표 호스트에 대한 별도 세그먼트를 만들고 프로젝트의 모든 도메인에 대한 공통 보고서를 남겨두세요. 첫 번째는 랜딩 트래픽을 통제하는 데 도움이 되고, 두 번째는 랜딩 페이지, 결제, 개인 계정 간의 사용자 경로를 볼 수 있게 해줍니다.

너무 엄격한 필터링의 단점: 서브도메인 간의 정상적인 전환이 보고서에서 사라져 퍼널이 끊어진 것처럼 보일 수 있습니다.

게시 전 링크 확인 체크리스트

• 오디언스가 링크를 보게 될 위치에서 링크를 여세요.
• 주소 표시줄에서 최종 도메인, 경로, 파라미터를 확인하세요.
• curl 또는 Network를 통해 3xx 체인과 Location 헤더를 확인하세요.
• 이전 도메인이 리디렉트 시 경로와 UTM 태그를 유지하는지 확인하세요.
• 앱의 인앱 브라우저에서 전환을 반복하세요.
• 지역 규칙이 사용되는 경우 다른 지역을 확인하세요.
• 실행 후 분석에서 Hostname과 랜딩 페이지를 대조하세요.
• 서버 로그로 올바른 호스트에 대한 요청을 확인하세요.

도메인, CDN, 랜딩 페이지 또는 리디렉트 규칙을 변경한 후에는 새 링크와 이전 링크 모두를 확인하세요. 오래된 스트림 설명, 영상, 고정 게시물은 계속해서 오디언스를 구식 경로로 안내할 수 있습니다.