애드센스 승인 전 블로그 색인·신뢰 신호 점검표

애드센스 승인을 준비할 때 제일 먼저 떠오르는 질문은 “글을 몇 개 더 써야 하나”였다. 그런데 실제로 FMNOTE를 점검해보니 글 개수보다 앞에 놓을 일이 있었다. 홈과 글이 제대로 열리는지, 광고 관련 파일이 루트에서 보이는지, 방문자가 사이트를 믿고 다음 글로 넘어갈 만한 구조가 있는지부터 갈라서 봐야 했다.

승인 전 점검은 한 덩어리로 묶으면 금방 헷갈린다. 공개 페이지 신호, Search Console에서 보는 색인 현실, AdSense 계정의 심사 상태는 서로 다른 층이다. 공개 URL이 200으로 열린다고 해서 색인이 끝난 것은 아니고, ads.txt가 열린다고 해서 승인 상태가 확정되는 것도 아니다.

10초 결론: 애드센스 승인 전에는 “홈 200·canonical·noindex 없음·robots/sitemap·정책 링크·ads.txt”를 공개 신호로 먼저 확인한다. 그다음 Search Console이나 Site Kit에서 실제 발견·색인·노출을 따로 보고, 마지막에 AdSense 콘솔 상태를 분리해서 기록해야 한다.

2026-07-17 기준으로 FMNOTE의 공개 신호와 Search Console/Site Kit 읽기 전용 수치를 다시 확인했다. 이 글은 승인 여부를 단정하는 글이 아니라, 승인 전에 헷갈리기 쉬운 신호를 순서대로 분리하는 점검표다.

공개 페이지 신호는 승인 가능성의 입구다

가장 앞단은 브라우저와 HTTP로 바로 확인할 수 있는 공개 신호다. 홈과 주요 글이 200으로 열리고, canonical이 자기 URL을 가리키고, robots meta에 noindex가 없어야 한다. robots.txt가 sitemap을 선언하는지도 같이 본다.

FMNOTE처럼 애드센스 승인을 목표로 둔 블로그라면 정책 페이지도 같은 층에서 본다. 소개, 문의, 개인정보처리방침, 이용약관, 광고·제휴 고지, 편집 정책, 수정 정책이 홈이나 푸터에서 자연스럽게 이어져야 한다. 심사자를 의식한 장식이라기보다, 처음 온 방문자가 “누가 어떤 기준으로 쓰는 사이트인지” 확인할 수 있는 최소 동선이다.

Search Console 현실은 공개 신호와 다르다

공개 페이지가 멀쩡해도 Search Console에서는 다르게 보일 수 있다. 발견은 됐지만 아직 크롤링 전일 수 있고, 크롤링은 됐지만 색인이 보류될 수도 있다. 사이트맵 제출 여부, 마지막 크롤링 날짜, 색인 제외 사유는 공개 HTML만 보고 단정하면 안 된다.

이번 점검에서도 표현을 일부러 나눴다. “공개 페이지 기준으로는 색인 차단이 보이지 않는다”와 “Search Console에서 색인됨으로 확인했다”는 완전히 다른 말이다. 이 구분을 흐리면 새 글을 더 쓰는 문제인지, 내부링크를 고쳐야 하는 문제인지, 색인 상태를 기다려야 하는 문제인지 판단이 흔들린다.

WordPress를 쓴다면 Site Kit의 Search Console 데이터도 읽기 전용 확인 경로가 될 수 있다. 다만 여기서도 클릭수나 노출수는 실제 데이터로만 말해야 한다. 공개 HTML에 내부링크가 많다는 이유만으로 방문자가 늘었다고 쓰면, 운영 판단이 금방 틀어진다.

AdSense 승인은 ads.txt만으로 끝나지 않는다

ads.txt가 루트에서 열리는 것은 필요한 신호지만, 그것만으로 승인 상태를 말할 수는 없다. AdSense 쪽에서는 사이트 상태, 정책센터 알림, 저가치 콘텐츠 위험, 광고 게재 제한 여부를 따로 봐야 한다. 계정 화면에서 보이는 상태와 공개 페이지에서 보이는 상태는 역할이 다르다.

FMNOTE는 AI 도구와 Mac 작업환경을 실제로 운영해본 기록이 있어 고유성은 만들 수 있다. 다만 글이 짧고 내부링크가 약하면 “쌓인 운영 노트”가 아니라 흩어진 메모처럼 보일 수 있다. 승인 전에는 얇은 글을 늘리는 것보다, 이미 있는 글을 문제 해결형으로 고치고 관련 글을 이어 붙이는 편이 더 낫다.

내부링크는 신뢰 신호이면서 방문자 동선이다

관련 글을 서로 연결하지 않으면 검색엔진도 방문자도 사이트의 주제를 파악하기 어렵다. 예를 들어 Gemini CLI 자동 실행 글은 크론 결과 파일 글, AI 에이전트 장기기억 글, Mac AI 작업환경 글과 이어져야 한다. 이렇게 묶이면 FMNOTE가 단순 뉴스 요약이 아니라 실제 AI 자동화 운영 기록이라는 점이 더 분명해진다.

내부링크는 많이 넣는다고 해결되지 않는다. 본문 중간에서 실제로 이어지는 맥락에 넣어야 한다. 승인 전 점검표 글이라면 “검색·색인 확인”, “자동화 결과 기록”, “AI 도구 오류 복구”처럼 독자가 다음에 막힐 지점으로 이어지는 링크가 더 자연스럽다.

승인 전 점검표

• 홈, 대표 글, 정책 페이지가 모두 200으로 열리는지 확인한다.
• 각 글의 robots meta와 canonical이 색인을 막지 않는지 본다.
• robots.txt가 sitemap을 선언하고, 최신 글이 공개 동선에서 발견되는지 확인한다.
• ads.txt가 루트에서 열리는지 확인하되, 이것을 AdSense 승인으로 착각하지 않는다.
• 소개·문의·개인정보처리방침·이용약관·광고 고지·편집 정책·수정 정책을 홈과 푸터에서 찾을 수 있게 둔다.
• 얇은 글은 제목, 본문, 내부링크를 보강해 문제 해결형 글로 바꾼다.
• Search Console과 AdSense 대시보드 결과는 공개 신호와 분리해서 기록한다.

FMNOTE에는 어떤 글이 더 맞는가

승인과 방문자 성장을 같이 보려면 FMNOTE는 일반 IT 뉴스보다 실전 문제 해결 글이 맞다. “Gemini CLI가 크론에서 멈출 때”, “Mac에서 AI 도구 권한을 어떻게 나눌지”, “Antigravity CLI 출력이 비어 있을 때 어디서 로그를 확인할지”처럼 검색자가 실제로 막히는 지점을 제목과 본문에 드러내야 한다.

관련 사례로 Gemini CLI OAuth 크론 오류 체크리스트, AI 에이전트 크론 결과 파일 점검 방식, Antigravity CLI transcript 로그 확인법, 맥 AI 작업환경 세팅 체크리스트를 함께 묶어두면, 애드센스 승인 이후에도 방문자가 이어서 읽을 만한 동선이 생긴다.

내가 다시 점검한다면 글을 더 쓰기 전에 이 순서부터 본다. 공개 신호가 막혔는지, Search Console에서 아직 기다릴 상태인지, 아니면 글 자체가 얇아서 보강해야 하는지부터 나누면 다음 작업이 훨씬 덜 흔들린다.