robots.txt를 수정하고도 검색 노출이 그대로였던 실수들

바로 반영될 거라고 착각했다

검색에 노출되면 안 되는 테스트 경로가 보여서 robots.txt를 수정한 적이 있다. 파일을 바꾸고 배포까지 했는데 검색 결과는 그대로였다. 그때는 설정이 틀렸다고만 생각했지만, 실제로는 여러 가지를 한꺼번에 오해하고 있었다.

실수 1: 브라우저 캐시만 보고 있었다

서버에서는 새 파일이 나가는데 내 브라우저는 예전 응답을 보여 주고 있었다. 확인은 브라우저보다 curl이 빨랐다.

curl -i https://example.com/robots.txt
curl -i https://example.com/sitemap.xml

응답 헤더의 cache-control도 같이 봤다. 정적 파일 캐시를 길게 잡아 둔 상태라면 배포 후에도 중간 캐시가 남아 있을 수 있다.

실수 2: robots.txt를 삭제 요청으로 생각했다

robots.txt는 크롤링 규칙에 가깝고, 이미 검색엔진이 알고 있는 URL을 즉시 지워 주는 버튼은 아니다. 급하게 내려야 하는 페이지라면 페이지 자체에 noindex를 넣거나 검색 콘솔의 삭제 도구를 함께 봐야 한다.

예를 들어 Next.js에서 특정 페이지를 색인 제외하려면 메타데이터를 명확히 둔다.

export const metadata = {
  robots: {
    index: false,
    follow: false,
  },
}

실수 3: sitemap에 계속 넣어 두었다

막고 싶은 URL을 robots.txt에서는 막아 놓고, sitemap.xml에는 그대로 넣어 둔 적도 있었다. 신호가 서로 다르면 디버깅이 어려워진다.

내 기준은 이렇게 정했다.

• 공개해야 하는 URL만 sitemap에 넣는다.
• 검색에서 빼야 하는 페이지는 noindex를 우선 확인한다.
• robots 규칙은 크롤러 접근을 줄이는 용도로 본다.
• 배포 후에는 실제 URL 응답을 curl로 확인한다.

마무리 체크리스트

• https://example.com/robots.txt가 200으로 열리는가
• 수정한 규칙이 운영 도메인에 배포됐는가
• sitemap에 제외할 URL이 남아 있지 않은가
• 페이지 HTML에 의도한 robots 메타가 들어갔는가
• 검색 결과 반영에는 시간이 걸린다는 점을 기록했는가

검색 노출 문제는 버튼 하나로 끝나지 않았다. 파일, 메타 태그, sitemap, 캐시를 나눠서 봐야 원인을 빨리 좁힐 수 있었다.