WordPress에 GTM 컨테이너 설치하는 방법

WordPress의 GTM 설치는 코드 조각을 붙이는 것보다 누가 코드를 삽입하는지 한 가지 방식으로 통일하는 것이 우선입니다.

결론: GTM은 <head> 상단과 <body> 직후 두 스니펫을 넣습니다. WordPress에서는 GTM 플러그인 또는 테마 header/footer hook을 쓰고, Site Kit GA와 중복 삽입하지 마세요.

광고 유입부터 전환 분석까지 측정 흐름 (GTM 설치 후 검증)
GTM·GA4 설치 후 광고→랜딩→태그 발화→전환까지 이 흐름이 동작하는지 확인합니다.

준비사항

방법 1: 플러그인 (권장)

  1. 플러그인 → 새로 추가 → “Google Tag Manager” 검색
  2. 신뢰할 만한 플러그인 설치 (설치 수·최근 업데이트 확인)
  3. 설정에 컨테이너 ID (GTM-XXXXXX) 입력
  4. 저장 후 페이지 소스에서 googletagmanager.com/gtm.js 확인

방법 2: 테마 또는 코드 스니펫

테마가 header.php를 직접 수정할 수 있을 때:

  1. GTM 관리자 → 컨테이너 → 설치 안내에서 head·body 코드 복사
  2. <head> 최상단에 첫 번째 스니펫
  3. <body> 시작 직후 <noscript> 스니펫

자식 테마를 쓰지 않으면 테마 업데이트 시 코드가 사라질 수 있습니다. 플러그인이 더 안전합니다.

Site Kit과 함께 쓸 때

방식 설명
GTM만 GA4 Configuration을 GTM 태그로 — 이벤트 확장에 유리
Site Kit만 소규모 블로그, page_view만 — GA4 설치 가이드
둘 다 GA 삽입 비추천 — 데이터 2배 수집

GTM으로 전환할 때는 Site Kit의 Analytics 연결을 끄거나, Site Kit은 Search Console만 사용하세요.

설치 확인

  • 페이지 소스에 GTM- ID 존재
  • GTM 미리보기 연결 시 “컨테이너 연결됨” 표시
  • GA4 DebugView에 page_view (Configuration 태그 배포 후)

다음 단계

참고 출처

GTM WordPress 설치를 확인할 때는 화면에 숫자가 보이는지만 확인하면 부족합니다. 비교 기준, 수집 조건, 계산 방식과 데이터가 설명하지 못하는 범위를 함께 적어야 같은 결과를 다시 확인할 수 있습니다.

WordPress의 GTM 설치는 코드 조각을 붙이는 것보다 누가 코드를 삽입하는지 한 가지 방식으로 통일하는 것이 우선입니다. 이 글은 2026년 8월 1일 기준 공식 공개 문서를 다시 확인해, 처음 보는 사람도 순서대로 점검할 수 있도록 구성했습니다.

GTM WordPress 설치 핵심을 30초 안에 정리하면

VISUAL 1 · 핵심 판단 기준
QUESTION

무엇을 확인하나
GTM WordPress 설치의 상태와 변화 원인을 분리합니다.

COMPARE

무엇과 비교하나
같은 기간·대상·정의를 사용한 기준값과 비교합니다.

ACTION

무엇을 남기나
확인 화면, 설정 시각, 다음 점검 행동을 기록합니다.

가장 먼저 할 일은 문제를 한 문장으로 바꾸는 것입니다. “숫자가 이상하다”가 아니라 “어느 기간의 어떤 대상에서 어떤 값이 기준보다 얼마나 달라졌는가”라고 적으면 확인 범위가 줄어듭니다. 도구의 화면 명칭은 바뀔 수 있어도 이 질문 구조는 그대로 사용할 수 있습니다.

먼저 맞춰야 할 다섯 가지 기준

VISUAL 2 · 점검표
순서 확인 항목 통과 기준
1 컨테이너 ID 확인 화면 또는 기록으로 다시 확인 가능
2 Site Kit 또는 직접 설치 중 하나 선택 화면 또는 기록으로 다시 확인 가능
3 head·body 코드 위치 확인 화면 또는 기록으로 다시 확인 가능
4 캐시 삭제 화면 또는 기록으로 다시 확인 가능
5 Preview 연결 확인 화면 또는 기록으로 다시 확인 가능

표의 항목을 한꺼번에 바꾸지 말고 한 단계씩 확인해야 합니다. 여러 설정을 동시에 수정하면 결과가 정상으로 돌아와도 무엇이 원인이었는지 알 수 없습니다. 특히 날짜 범위, 시간대, 대상 계정처럼 화면 상단에서 정하는 조건은 캡처에 함께 남기는 편이 좋습니다.

실제로 확인하는 네 단계

VISUAL 3 · 확인 흐름
  1. 01기존 코드 중복 여부를 검색한다
  2. 02설치 방식을 하나로 결정한다
  3. 03컨테이너를 연결한다
  4. 04캐시 후 실제 소스와 Preview를 확인한다

이 순서를 따르면 원천 데이터, 설정, 보고 화면의 문제를 섞지 않을 수 있습니다. 첫 단계에서 원천 신호가 없다면 보고서를 고칠 이유가 없고, 원천 신호가 정상이라면 마지막 단계의 필터·처리 시간·집계 방식을 살펴야 합니다.

계산 또는 비교 예시

VISUAL 4 · 예시

예시 상황

테마와 Site Kit가 같은 GTM 컨테이너를 동시에 넣으면 이벤트가 중복될 수 있습니다. 기존 삽입 위치를 먼저 찾은 뒤 한 경로만 남겨야 합니다.

예시는 원리를 이해하기 위한 단순화된 상황입니다. 실제 계정이나 통계에서는 제외 조건, 결측값, 중복 제거, 반올림 방식이 추가될 수 있으므로 최종 판단 전에 원자료와 설정 화면을 함께 확인합니다.

이 숫자만으로 결론 내리면 안 되는 이유

VISUAL 5 · 데이터 한계

테마 교체나 캐시 플러그인 설정 변경 후 코드가 사라질 수 있으므로 배포 직후와 정기 점검 때 컨테이너 존재를 다시 확인합니다.

  • 같은 이름의 지표라도 도구마다 정의가 다를 수 있습니다.
  • 처리 중인 오늘 수치는 나중에 바뀔 수 있습니다.
  • 표본이 작거나 기간이 짧으면 작은 변화가 크게 보입니다.

따라서 결과를 공유할 때는 숫자 옆에 기간, 대상, 출처, 확인일을 적습니다. 사실로 확인된 내용과 작성자의 해석을 문단에서 구분하고, 재현되지 않는 추정은 결론이 아니라 다음 점검 가설로 남깁니다.

공식 출처와 함께 확인하기

제품 화면과 도움말은 업데이트될 수 있습니다. 메뉴 위치가 글과 다르면 위 공식 문서의 최신 안내를 우선하고, 글의 확인일 이후 바뀐 내용은 문의 페이지로 알려주세요.

자주 묻는 질문

한 번 정상으로 보이면 점검을 끝내도 되나요?

아닙니다. 배포, 플러그인 업데이트, 캠페인 변경 뒤 같은 조건으로 다시 확인할 수 있도록 점검일과 결과를 남기는 것이 좋습니다.

숫자가 조금 다르면 모두 오류인가요?

도구별 정의와 처리 시간이 다르면 정상적인 차이가 생길 수 있습니다. 먼저 기간·시간대·대상·집계 기준을 맞춘 뒤 차이를 판단합니다.

가장 먼저 고쳐야 할 것은 무엇인가요?

결과에 가장 가까운 설정이 아니라 원천 신호부터 확인합니다. 원천이 정상이라는 증거가 있어야 다음 단계의 수정이 의미가 있습니다.