-
[AdSense][수익화] ads.txt를 올렸는데 찾을 수 없음이 남을 때 루트 경로와 publisher ID와 반영 대기를 어떤 순서로 확인하나기타개발지식/풀스택개발 2026. 7. 17. 09:34
[AdSense][수익화] ads.txt를 올렸는데 찾을 수 없음이 남을 때 루트 경로와 publisher ID와 반영 대기를 어떤 순서로 확인하나 :: FullStack Lab -
[AdSense][수익화] ads.txt를 올렸는데 찾을 수 없음이 남을 때 루트 경로와 publisher ID와 반영 대기를 어떤 순서로 확인하나기타개발지식/풀스택개발 2026. 7. 17. 09:34반응형
IT 리서치 노트
[AdSense][수익화] ads.txt를 올렸는데 찾을 수 없음이 남을 때 루트 경로와 publisher ID와 반영 대기를 어떤 순서로 확인하나
AdSense에서 ads.txt를 올렸는데도 계속 찾을 수 없음이 남으면 많은 사람이 파일 업로드 자체만 다시 본다. 하지만 2026년 7월 17일 기준 Google AdSense 도움말을 다시 보면 루트 경로, HTTP 200 상태, `www` 리다이렉트, publisher ID 문자열, 반영 대기 시간이 서로 다른 층위다. 이 글은 그 다섯 가지를 어떤 순서로 나눠 봐야 시간을 덜 쓰는지 정리한 것이다.
1. 개요
결론부터 말하면 ads.txt 찾을 수 없음은 업로드 여부 하나로 끝나는 문제가 아니다. 먼저 루트 도메인
/ads.txt가 열리는지 보고, 그다음 응답 헤더가 200인지 확인하고, publisher ID 문자열이 정확한지 본 뒤, 마지막에 반영 대기를 판단해야 한다.특히 브라우저에 뭔가 보인다고 통과가 아니다. Google 도움말은 본문이 보여도 응답 헤더가 404면 파일이 없는 것으로 보고, 200 HTML soft 404도 문제로 설명한다.
2. 어디서 실제로 막히는가
실무에서 가장 많이 섞이는 실패는 세 가지다. 첫째, CMS에 ads.txt 내용을 넣었지만 실제 루트 도메인 경로에 노출되지 않는다. 둘째, 브라우저에서 HTML 페이지가 떠서 사람 눈에는 정상처럼 보이지만 응답은 404 또는 soft 404다. 셋째, publisher ID가 잘못됐거나 맞게 고쳤는데 반영 대기 시간을 안 기다리고 계속 파일을 바꾼다.
AdSense guide는 루트 디렉터리에 ads.txt를 올리고 브라우저에서 URL을 직접 열어 보라고 안내한다. crawler 문서는 HTTP 200 OK가 아니면 본문이 보여도 무시될 수 있다고 설명하고, FAQ는 루트 도메인에서
www또는 서브도메인 ads.txt로 갈 때 redirect 규칙이 중요하다고 적는다.- 증상: ads.txt를 넣었다고 생각하는데 AdSense는 Not found를 유지한다.
- 실패: 관리 화면에서 추가했다는 사실만 보고 실제 URL을 안 연다.
- 막힘: 200 HTML soft 404와 진짜 text/plain 응답을 구분하지 않는다.
- 누락: publisher ID와 반영 대기 시간을 같은 문제로 섞는다.
신호 먼저 볼 곳 의미 브라우저에서 안 열린다 루트 경로 업로드 또는 redirect 문제 본문은 보이는데 상태가 이상하다 HTTP 헤더 soft 404 또는 잘못된 응답일 수 있다 수정 후 바로 안 바뀐다 반영 대기 며칠에서 최대 한 달까지 걸릴 수 있다 3. 실무에서 적용하는 순서
실무 순서는 다섯 단계가 가장 짧다. 먼저 루트 도메인
/ads.txt를 직접 연다. 두 번째로curl -I같은 방법으로 HTTP 200 OK인지 확인한다. 세 번째로 본문이 plain text인지, publisher ID 줄이 정확한지 본다. 네 번째로www, 서브도메인, HTTP/HTTPS 리다이렉트를 점검한다. 마지막으로 수정 후에는 충분히 기다리고 AdSense의 Check for updates를 쓴다.- 루트 도메인
/ads.txt를 직접 연다. - 상태 코드가 200 OK인지 확인한다.
- publisher ID 줄이 계정 값과 완전히 같은지 본다.
www와 루트 도메인 redirect를 점검한다.- 며칠 이상 기다린 뒤 Check for updates를 누른다.
이 순서가 좋은 이유는 파일 부재, 응답 오류, 반영 지연을 서로 다른 문제로 나누기 때문이다. 특히 low-traffic 사이트는 반영이 최대 한 달까지 걸릴 수 있으므로, 파일이 맞다면 자꾸 다시 저장해 검토 시간을 리셋하는 실수를 피해야 한다.
curl -I https://example.com/ads.txt curl -L https://example.com/ads.txt # 확인 포인트 status_code=200 content_type=text/plain body_contains=google.com,pub-...,DIRECT여기까지 확인한 뒤에도 AdSense가 바로 안 바뀐다면 그때는 대기 문제일 가능성이 커진다. 반대로 루트 URL이 404이거나 200 HTML soft 404면 기다릴 이유가 없다. 바로 배포 경로와 redirect를 고쳐야 한다. 이처럼 상태 코드와 본문을 먼저 확보해 두면 CMS 설정 화면만 반복해서 열어 보는 시간을 크게 줄일 수 있다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 AdSense ads.txt guide의 핵심 구간이다. 여기서는 ads.txt를 사이트 루트 디렉터리에 올리고 브라우저에서 직접 열어 확인하라고 설명한다.
즉 CMS 설정 화면에서 파일을 넣었다는 사실만으로 끝나지 않는다. 최종적으로 `도메인/ads.txt`가 열려야 한다.
두 번째 자료는 crawler 문제 문서의 HTTP 상태 코드 구간이다. 여기서는 응답 본문에 내용이 보여도 헤더가 404면 무시된다고 분명히 적고 있다.
이 부분이 중요하다. 200 HTML soft 404나 잘못된 리다이렉트가 있으면 사람 눈에는 보여도 크롤러 기준에서는 실패할 수 있다.
세 번째 자료는 ads.txt FAQ의 리다이렉트와 서브도메인 설명이다. 루트 도메인에서 시작해 `www` 또는 서브도메인 ads.txt로 가는 규칙을 여기서 확인할 수 있다.
그래서 `www`에서만 열리고 루트 도메인에서는 안 열리는 구조라면 찾을 수 없음이 계속 남을 수 있다.
실무에서는 파일 생성 여부보다 확인 순서가 중요하다. 루트 경로, HTTP 상태, publisher ID, 반영 대기를 순서대로 보면 대부분 바로 잘린다.
광고 코드 삽입 단계로 가기 전에 이 표를 먼저 끝내는 편이 낫다.
헤더와 본문을 같이 보는 습관이 있으면 soft 404를 빨리 잡을 수 있다. 브라우저에 보인다고 끝내지 말고 상태 코드와 Location 헤더를 함께 확인하는 편이 좋다.
이런 식으로 보면 200 HTML인지, 404인지, `www` 리다이렉트인지가 한 번에 드러난다.
마지막 자료는 흔한 실패를 세 갈래로 나눈 표다. 업로드 안 됨, 잘못된 응답, 반영 대기 문제를 섞으면 며칠씩 헛돌기 쉽다.
앱 출시 준비 관점에서는 Google Play Data Safety 글과 iOS privacy manifest 글처럼 광고 외 개인정보 표기도 함께 정리해 두는 편이 안전하다.
5. 주의사항과 리스크
첫 번째 리스크는 루트 도메인보다
www경로만 확인하는 것이다. 두 번째는 text/plain이 아니라 HTML fallback 페이지를 200으로 반환하는 것이다. 세 번째는 rich text 편집기에서 복사한 보이지 않는 문자나 잘못된 공백 때문에 crawler가 파싱을 실패하는 것이다.또 반영 지연과 파일 오류를 섞으면 문제를 더 오래 끈다. 파일이 맞다면 기다려야 하고, 파일이 틀리면 바로 고쳐야 한다. 둘을 구분하는 기준이 HTTP 상태와 실제 본문이다.
- 루트 도메인과
www경로를 따로 확인한다. - 본문이 아니라 응답 헤더 200 OK를 본다.
- publisher ID와 서식 오류를 plain text 기준으로 다시 본다.
6. 결론
AdSense ads.txt 찾을 수 없음은 보통 루트 경로, 응답 상태, publisher ID, 리다이렉트, 반영 대기 중 하나에서 갈린다. 이 순서대로 자르면 불필요한 재업로드와 대기 시간을 크게 줄일 수 있다.
수익화 준비 흐름으로는 Google Play Data Safety 글과 iOS privacy manifest 글도 같이 보면 광고 수익화와 개인정보 표기 준비를 한 번에 정리하기 좋다.
최근에는 Sites 화면에서 ownership verified, ads.txt not found, Requires review 같은 상태가 한 번에 섞여 보이는 경우가 많다. 이런 상태표를 먼저 읽고 싶다면 AdSense Sites 페이지 상태표를 ownership, ads.txt, review 신호로 같이 읽는 글을 이어서 보면 업로드 문제와 심사 상태 문제를 더 빨리 분리할 수 있다.
ads.txt가 이미 Authorized인데도 검토가 남아 있으면 Authorized인데 Requires review가 남을 때 ownership과 crawler 접근을 다시 보는 순서 글을 이어서 보면 된다. 업로드 문제와 심사 상태 문제를 분리하는 데 도움이 된다.
7. 참고 링크
반응형'기타개발지식 > 풀스택개발' 카테고리의 다른 글
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
-
