애드센스 노출수가 페이지뷰보다 적은 이유와 확인 방법
애드센스 광고를 한 페이지에 3개 배치해도 광고 노출수가 페이지뷰의 3배가 되는 것은 아닙니다. 광고가 실제로 요청되고 채워진 뒤 로딩되어야 노출로 집계되므로, 노출수가 페이지뷰보다 적다면 보고서의 비교 범위와 광고 요청·노출 범위·로딩 상태를 차례로 확인해야 합니다.
페이지뷰와 광고 노출수는 무엇이 다를까?
애드센스의 페이지뷰는 Google 광고가 게재된 페이지를 조회한 횟수이며, 페이지 안의 광고 개수와 관계없이 페이지 조회 한 번을 1회로 셉니다. 광고 요청은 사이트가 광고를 요청한 횟수로, 광고를 받지 못한 요청도 포함합니다. 노출수는 광고 로딩 단계의 지표입니다. 이 세 가지를 모두 ‘방문수’로 읽으면 원인을 잘못 판단하기 쉽습니다. 페이지뷰 정의와 광고 요청 정의를 기준으로 구분할 수 있습니다.
| 지표 | 무엇을 보는가? | 해석할 때 주의할 점 |
|---|---|---|
| 페이지뷰 | 광고가 게재된 페이지의 조회 | 광고 단위 3개를 각각 페이지뷰로 세지 않음 |
| 광고 요청 | 광고를 보내 달라는 요청 | 광고가 반환되지 않아도 집계될 수 있음 |
| 노출 범위(Coverage) | 전체 요청 중 광고가 반환된 요청의 비율 | 방문자 중 광고를 본 사람의 비율이 아님 |
| 노출수 | 광고의 로딩에 따른 노출 집계 | 광고 코드를 넣은 자리 수와 다름 |
| 조회 가능 Active View | 측정 가능한 노출 중 조회 가능 조건을 충족한 비율 | 일반 노출수와 구분해서 읽어야 함 |
노출 범위는 흔히 게재율이라고도 부르는 지표입니다. 계산은 ‘광고가 반환된 요청 수 ÷ 전체 광고 요청 수 × 100’입니다. 예를 들어 요청 3회 중 2회에 광고가 반환됐다면 약 66.7%입니다. 방문자 세 명 중 두 명이 광고를 봤다는 뜻은 아닙니다. Google의 Coverage 설명도 광고 요청을 분모로 사용합니다.
집계 시점도 확인해야 합니다. 2026년 10월 현재 배너형 디스플레이 광고는 다운로드가 시작될 때 노출을 세는 기준이 적용됩니다. Google은 2027년 2월 17일부터 광고가 로드되고 렌더링을 시작할 때 세는 기준으로 전환한다고 예고했습니다. 광고 형식에 따라 이미 렌더링 기준을 쓰는 경우도 있으므로, 서로 다른 기간이나 형식을 비교할 때 기준을 확인해야 합니다. 노출수 정의와 집계 기준 변경 안내를 함께 참고하세요.
광고 3개가 항상 노출 3회가 되지 않는 이유
페이지 상단·본문 중간·하단에 광고 영역을 하나씩 넣었다고 가정해 보겠습니다. 세 영역 모두 광고를 요청하고 실제 광고를 로딩했다면 페이지 조회 한 번에 여러 노출이 생길 수 있습니다. 반면 중간·하단 광고를 스크롤 위치에 따라 불러오는 지연 로딩을 사용한다면, 방문자가 그 위치에 다가가기 전에 떠나 요청이 발생하지 않을 수 있습니다. 세 자리 중 한 자리는 요청했어도 광고가 반환되지 않을 수 있습니다.
광고를 못 봤다는 것과 일반 노출이 집계되지 않았다는 것은 다릅니다. 이미 로딩된 하단 광고라면 사용자가 그 위치까지 스크롤하지 않았어도 일반 노출로 집계될 수 있습니다. Active View의 조회 가능 조건은 일반적으로 광고 면적의 50% 이상이 화면에 1초 이상 표시되는 것입니다. 이는 실제로 볼 기회가 있었는지 보는 별도의 기준입니다. Active View 공식 설명에서 이 차이를 확인할 수 있습니다.
따라서 ‘광고가 3개니까 노출수는 무조건 페이지뷰의 3배여야 한다’고 계산하면 안 됩니다. 다만 각 페이지 조회에서 최소 한 개의 광고 노출이 같은 범위로 정상 집계됐다면 노출수는 페이지뷰 이상일 것으로 기대할 수 있습니다. 그보다 작다는 사실은 점검의 출발점이며, 그 숫자만으로 광고가 전혀 나오지 않은 방문의 비율을 계산할 수는 없습니다.
어떤 원인을 먼저 의심해야 할까?
- 비교 범위가 다른 경우: 사이트 전체 페이지뷰와 특정 광고 단위의 노출수, 전체 기기와 모바일만의 지표를 비교하고 있지 않은지 확인합니다. Google Analytics 4(GA4)의 조회수도 애드센스 페이지뷰와 같은 지표가 아니므로 섞어서 비율을 계산하지 않습니다.
- 광고 요청 자체가 적은 경우: 지연 로딩, 모바일에서 숨긴 영역, 스크립트 실행 지연이나 오류가 영향을 줄 수 있습니다. 광고 코드가 소스에 존재하는 것과 브라우저에서 요청이 실제로 실행되는 것은 다릅니다.
- 요청을 보냈지만 광고가 채워지지 않는 경우: 적합한 광고 수요, 광고 크기와 차단 설정, 광고 게재 제한, ads.txt 상태, 정책·크롤러 문제를 확인합니다. ads.txt는 광고 인벤토리의 승인된 판매자를 알리는 파일이며, 경고가 있다면 계정의 안내를 따라 확인합니다.
- 광고 로딩이나 집계에 문제가 있는 경우: 느린 연결, 광고 로딩 전 이탈, 구현 오류 등이 후보입니다. 무효 트래픽 조정과 보고서 반영 지연도 고려하되, 증거 없이 특정 방문자를 봇으로 단정하지 않습니다.
광고 차단 프로그램이나 동의 관리도 광고 요청과 제공에 영향을 줄 수 있지만, 애드센스 페이지뷰까지 함께 달라질 수 있습니다. 따라서 ‘광고 차단 때문’이라는 설명 하나로 애드센스 내부의 두 지표 차이를 확정해서는 안 됩니다. Google은 노출 범위 문제 해결 안내에서 계정 제한, 정책, 크롤러, 차단 설정 등을 나누어 점검하도록 설명합니다.
보고서에서 확인하는 순서
- 기간과 범위를 맞춥니다. 애드센스의 보고서에서 해당 사이트만 선택하고, 기기·광고 단위·형식 필터를 먼저 확인합니다. 당일의 진행 중인 수치만 보지 말고, 오늘을 제외한 최근 7일과 그 이전 7일처럼 같은 길이의 기간을 비교합니다. 내보낸 자료끼리는 시간대도 맞춥니다.
- 페이지뷰·광고 요청·노출 범위·노출수를 함께 봅니다. 광고 요청이나 Coverage가 기본 화면에 없다면 고급 측정항목에서 찾습니다. 보고서의 분류에 따라 일부 지표가 제공되지 않으면 사이트 수준 보고서와 광고 단위 보고서를 구분해 확인합니다.
- 기기별로 나눕니다. 모바일에서만 요청이나 노출이 줄었다면 모바일의 광고 영역 크기, 숨김 조건, 지연 실행을 우선 확인합니다. 국가별 차이가 크면 광고 수요와 동의 적용 조건도 함께 살핍니다.
- 광고 단위별로 나눕니다. 상단은 유지되는데 본문 중간·하단만 줄었는지 확인합니다. 특정 단위의 수치만 전체 페이지뷰와 직접 비교해 전체 사이트의 실패율로 해석하지 않습니다.
- 정책 센터와 사이트 상태를 확인합니다. 광고 게재 제한, 정책·크롤러 안내, ads.txt 알림을 확인하고, 문제가 표시되면 해당 안내에 맞춰 처리합니다. 광고가 비었다는 사실만으로 계정 제재를 추정하지 않습니다.
| 보고서의 신호 | 우선 확인할 곳 |
|---|---|
| 기존 대비 광고 요청부터 감소 | 코드 실행, 모바일 조건, 지연 로딩과 방문 변화 |
| 요청은 유지되지만 Coverage 하락 | 미충족 요청, 차단 설정, 정책·크롤러·사이트 상태 |
| Coverage는 유지되지만 노출 감소 | 광고 로딩, 구현 변경, 이탈과 집계 범위·지연 |
| 일반 노출은 유지되지만 조회 가능 비율 하락 | 광고 위치, 스크롤 도달과 화면에서의 표시 시간 |
이 표는 원인을 좁히는 기준이지 원인을 확정하는 공식은 아닙니다. Google은 노출·클릭 보고서가 보통 15~30분마다 갱신되고 간혹 24시간 이상 지연될 수 있다고 설명합니다. 지연 안내가 있다면 기록해 두고 반영 후 다시 비교하세요. 보고서 업데이트 안내와 노출 문제 해결 안내를 참고할 수 있습니다.
브라우저에서 광고 영역의 상태 확인하기
보고서에서 문제가 의심되는 광고 단위를 찾았다면 해당 공개 페이지를 로그아웃 상태에서도 열어 봅니다. 데스크톱과 실제 모바일에서 비교하고, 광고가 들어갈 위치까지 스크롤합니다. 광고 클릭으로 확인하지 말고, 영역과 요청·로딩 상태를 관찰합니다. 개발자 도구에서는 Console의 스크립트 오류와 Network의 광고 관련 요청을 함께 확인할 수 있습니다.
수동으로 넣은 일반적인 애드센스 광고 영역은 Chrome 개발자 도구의 Console에서 다음 JavaScript 표현식으로 살펴볼 수 있습니다. 해당 페이지에서 실행하며, 페이지나 광고를 수정하지 않고 현재 요소의 속성과 크기만 읽습니다.
Array.from(document.querySelectorAll('ins.adsbygoogle'), (ad, index) => ({
number: index + 1,
slot: ad.getAttribute('data-ad-slot'),
adStatus: ad.getAttribute('data-ad-status'),
processed: ad.getAttribute('data-adsbygoogle-status'),
width: Math.round(ad.getBoundingClientRect().width),
height: Math.round(ad.getBoundingClientRect().height)
}));
결과는 광고 요소별 객체가 담긴 배열입니다. adStatus가 filled이면 광고가 반환된 상태, unfilled이면 반환되지 않은 상태입니다. unfill-optimized는 일반 광고가 반환되지 않은 자리를 애드센스가 다른 방식으로 최적화한 상태입니다. processed는 별도의 처리 상태이므로 이 값만으로 광고가 채워졌다고 판단하면 안 됩니다. data-ad-status 공식 설명에 구분이 나와 있습니다.
속성값이 없거나 배열이 비었다고 곧바로 오류로 보지는 않습니다. 아직 요청 전일 수 있고, 자동 광고의 형식이나 교차 도메인 프레임 안의 광고는 이 조회로 모두 확인되지 않을 수 있습니다. 크기가 0인 영역은 숨김 여부를 살필 단서지만, 한 번의 화면 결과가 전체 방문자의 상황을 대표하지는 않습니다. 또한 filled는 계정 보고서의 노출 집계나 조회 가능 조건 충족을 보증하지 않습니다.
원인을 찾은 뒤 수정하고 다시 확인하는 방법
한 번에 여러 설정을 바꾸지 말고 문제가 나타난 단위·기기부터 하나씩 수정합니다. 스크립트 지연·최적화 설정이 의심된다면 현재 설정과 코드를 백업하고, 해당 광고 실행에 영향을 주는 항목만 조정한 뒤 캐시를 비우고 비교합니다. 기대한 변화가 없거나 레이아웃이 깨지면 저장해 둔 설정으로 되돌립니다. 크기 문제라면 모바일의 실제 사용 가능 너비와 반응형 광고 설정을 함께 확인합니다.
수정 직후에는 요청 발생과 표시 상태를 확인하고, 이후 보고서 반영을 기다려 같은 범위로 비교합니다. 방문량, 국가·기기 비중, 광고 위치도 함께 기록해야 다른 변화와 구분할 수 있습니다. 노출수가 늘었다는 이유만으로 수익 증가나 문제 해결을 보장하지 않으며, 동의 절차를 우회하거나 계정 경고를 숨기는 방식으로 해결하지 않습니다.
문제가 계속되면 발생 기간과 시간대, 공개 URL, 광고 단위, 영향을 받는 기기·국가, 네 가지 지표의 변화, 최근 변경 사항과 재현 조건을 정리해 도움을 요청합니다. 같은 범위의 보고서와 브라우저 관찰이 있으면 ‘광고가 세 개 있는데 왜 적을까?’에서 벗어나 요청·광고 충족·로딩·조회 가능성 중 어느 단계에서 차이가 생기는지 구체적으로 설명할 수 있습니다.

