-
[AdSense][수익화] Sites에서 platform partner 관리 사이트와 직접 root domain entry를 어떤 순서로 다시 구분하나기타개발지식/풀스택개발 2026. 8. 16. 09:20
IT 리서치 노트
[AdSense][수익화] Sites에서 platform partner 관리 사이트와 직접 root domain entry를 어떤 순서로 다시 구분하나
AdSense Sites를 보다 보면 어떤 항목은 내가 직접 root domain을 넣어 관리하는 것 같고, 어떤 항목은 platform partner가 함께 붙은 상태처럼 보일 때가 있다. 2026년 8월 16일 기준 Google AdSense 도움말을 다시 보면 platform partner 연결 사이트는 shared traffic과 platform partner properties라는 별도 개념으로 설명되고, host partner 사이트는 Add a new site 흐름도 직접 root domain entry와 다르다. 이 글은 Sites에서 platform partner 관리 사이트와 직접 root domain entry를 어떤 순서로 다시 구분해야 다음 조치를 덜 헷갈리게 하는지 정리한다.
1. 개요
결론부터 말하면 AdSense Sites에서는 먼저
shared traffic 여부,host partner 경유 여부,unlink 가능성,verify 책임을 나눠야 한다. 같은 Sites 페이지에 보이더라도 platform partner 관리 사이트와 direct root domain entry는 추가 경로와 제어 권한이 다르다.특히 host partner 사이트는 Add site를 AdSense에서 직접 하지 말고 partner 경로를 먼저 보라고 문서가 적고, platform-owned domain은 unlink가 제한될 수 있다. 그래서 root domain을 새로 넣을지, 기존 partner-managed entry를 따라갈지 먼저 분기해야 한다.
2. 어디서 실제로 막히는가
현장에서 많이 꼬이는 패턴은 세 가지다. 첫째, Sites에 항목이 있으니 direct domain과 같은 책임 모델이라고 가정한다. 둘째, platform partner가 붙은 shared traffic 항목인데 ads.txt나 policy 조정을 모두 내가 직접 제어할 수 있다고 생각한다. 셋째, host partner 경로여야 하는 사이트를 Sites에서 root domain으로 다시 add site 하려다가 review 흐름을 섞는다.
Google 도움말은 partner-linked 사이트에서 platform partner properties가 있을 수 있다고 설명하고, shared traffic은 publisher ID와 platform publisher ID가 함께 붙는 요청이라고 정의한다. 또한 Add a new site 문서는 host partner 사이트라면 host partner를 통해 추가해야 한다고 적고, direct domain 연결은 verification 절차를 직접 밟는 흐름으로 안내한다. 이 세 문서를 같이 읽으면 entry 분류부터 잘못 잡으면 다음 모든 작업이 꼬인다는 점이 분명해진다.
이미 Sites 상태표 글이 ownership, ads.txt, requires review를 한 화면으로 묶었다면, 이번 글은 그 다음 단계다. '이 상태를 어디서 풀어야 하나'를 partner-managed와 direct entry로 나눈다.
- 증상: Sites 항목은 있는데 add site와 verify 경로가 이상하게 다르다.
- 실패: partner-managed 항목을 direct root domain처럼 취급한다.
- 막힘: unlink 제한과 platform-owned domain 예외를 기록하지 않는다.
- 누락: shared traffic 여부와 verification 책임자를 분리하지 않는다.
보이는 현상 먼저 볼 곳 판단 기준 Sites에 항목이 있으나 일부 속성이 내 통제 밖이다 platform partner properties shared traffic 또는 partner-managed 가능성을 먼저 둔다 새 사이트를 add하려는데 안내가 host partner를 가리킨다 Add a new site 주석 direct root domain entry가 아닌 host partner 경로인지 본다 unlink 또는 remove 판단이 애매하다 platform-owned domain 제한 platform-owned domain이면 remove/re-add 판단을 다르게 둔다 3. 실무에서 적용하는 순서
실무 순서는 네 단계가 가장 짧다. 먼저 해당 Sites 항목이 shared traffic인지 확인한다. 두 번째로 host partner 경유 사이트인지, direct root domain entry인지 분기한다. 세 번째로 unlink 가능성과 verification 책임자를 적는다. 마지막으로 그 뒤에야 ads.txt, policy, verify, remove/re-add 중 어떤 조치를 할지 결정한다.
- publisher ID와 platform publisher ID가 함께 가는 shared traffic인지 본다.
- host partner 경로인지 direct add site 경로인지 적는다.
- unlink 제한과 verification 책임을 메모한다.
- 그 뒤에만 ads.txt, verify, remove/re-add action을 고른다.
실제 작업은 Sites를 열고, 항목을 선택하고, partner properties를 확인하고, entry 경로를 메모에 입력하고, 필요한 code snippet이나 meta tag를 제거하고, 마지막으로 verify 또는 remove/re-add를 실행하는 순서로 적어 두는 편이 가장 명확하다.
운영 메모에는 어떤 메뉴를 클릭했는지, 어떤 URL을 입력했는지, 어떤 partner 설정을 확인했는지, 어떤 HTML 파일을 저장했는지, 어떤 상태 로그와 review 응답을 조회했는지, 어떤 코드 조각을 복사했는지, 어떤 remove/re-add를 실행했는지까지 남기는 편이 좋다. 그래야 다음 담당자가 같은 Sites 항목을 다시 열고도 처음부터 추측하지 않는다.
여기서 중요한 것은 action보다 entry 분류다. direct root domain entry라면 code snippet과 verify 흐름을 직접 밟는 것이 자연스럽지만, partner-managed 사이트는 platform partner properties와 shared traffic 조건을 먼저 봐야 한다. 이 구분이 없으면 URL channel, custom channel, root domain approval, site ownership 같은 다음 문제도 계속 섞인다.
예를 들어 host partner 경로라면 partner 쪽에서 add site를 진행해야 하므로 AdSense Sites에서 direct root domain처럼 다시 등록하려는 시도 자체가 잘못된 출발일 수 있다. 반대로 custom domain으로 완전히 직접 운영 중이라면 verification 흐름을 직접 밟는 쪽이 맞다. 이미 custom channel과 URL channel 비교 글을 읽었다면, 이번 글은 report 단계보다 더 앞단인 site-entry 책임 분기라고 보면 된다.
이 정도 메모만 있어도 다음 실행에서 '왜 verify 버튼이 direct site와 다르지' 같은 질문을 다시 처음부터 풀지 않게 된다. entry 분류가 맞으면 이후 action도 훨씬 자연스럽다.
4. 공식 문서와 예시 화면으로 확인하기
첫 공식 화면은 'Your site is linked to a platform partner' 도움말의 shared traffic 설명이다. publisher ID와 platform publisher ID가 함께 들어가면 shared traffic으로 본다는 점이 출발점이다.
즉 Sites에서 보이는 항목이 내 direct domain entry인지, host partner가 함께 붙은 관리 사이트인지 먼저 나눠야 한다. 이 구분 없이 ads.txt나 revenue share를 같은 규칙으로 보면 혼선이 커진다.
두 번째 자료는 같은 도움말의 unlink 제한 구간이다. platform-owned domain 예시에서는 unlink가 불가능할 수 있다고 문서가 직접 적고 있다.
이 한 줄이 중요한 이유는 대표적인 host partner 흐름과 custom root domain 흐름이 관리 방식부터 다르기 때문이다. direct domain처럼 단순히 코드와 meta tag만 치우면 끝나는 경우가 아니다.
세 번째 공식 자료는 Add a new site 문서의 host partner 주석이다. host partner 사이트라면 AdSense Sites에서 직접 추가하지 말고 host partner 쪽에서 진행하라고 적는다.
즉 Sites 페이지에 새 root domain entry를 넣을지, 이미 platform partner가 연결된 항목을 따라갈지 판단 기준이 여기서 갈린다. entry 위치부터 다르면 review와 verify 단계도 달라진다.
네 번째 자료는 entry 분기 체크리스트다. direct domain이면 verify 흐름을 직접 밟고, partner-managed면 platform partner properties부터 확인해야 한다.
이 체크리스트를 팀 위키에 붙여 두면 누가 Sites를 열고, 어떤 속성을 확인하고, add site를 어디서 시작하고, meta tag나 code snippet을 어디서 제거하고, remove/re-add를 언제 실행할지를 짧게 정리할 수 있다.
마지막 자료는 platform partner와 direct domain entry를 빠르게 가르는 표다. shared traffic 여부, unlink 가능성, add site 경로, verification 책임을 한 번에 보면 분기점이 짧아진다.
이 표는 Sites 상태표 허브 글과 root domain과 URL channel 분기 글 사이를 잇는 역할을 한다. status table을 본 뒤 next action을 어디서 해야 하는지 정하는 단계다.
5. 주의사항과 리스크
첫 번째 리스크는 partner-managed 사이트를 direct domain처럼 다시 add site 하는 것이다. 두 번째 리스크는 shared traffic인데도 ads.txt나 policy control을 전부 직접 관리한다고 가정하는 것이다. 세 번째 리스크는 unlink 제한을 모르고 remove/re-add만 반복하는 것이다.
- Sites 화면의 항목 존재만으로 direct ownership을 뜻하지 않는다.
- shared traffic이면 platform partner properties를 먼저 본다.
- host partner 사이트는 add site 경로부터 direct domain과 다르다.
6. 결론
AdSense Sites에서 platform partner 관리 사이트와 direct root domain entry를 구분하는 기준은 review 상태보다 더 앞단에 있다. shared traffic, host partner 경로, unlink 가능성, verify 책임을 먼저 적으면 다음 action이 훨씬 짧아진다.
- shared traffic 여부를 먼저 확인한다.
- host partner 경유인지 direct root domain인지 분리한다.
- 그 뒤에만 verify, ads.txt, remove/re-add action을 고른다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글