robots.txt 설정을 배포 전에 확인했어야 했던 이유

블로그를 새 도메인으로 옮기고 나서 Google Search Console에서 이상한 걸 발견했다. 색인된 URL 목록에 스테이징 환경에서 넘어온 것들이 섞여 있었고, 그 중 일부는 canonical이 구 도메인을 가리키고 있었다. 원인을 추적해보니 배포 초기에 robots.txt가 아예 없었거나, 모든 경로를 허용하는 빈 상태였다.

robots.txt가 없으면 무슨 일이 생기나

크롤러는 robots.txt가 없으면 사이트 전체를 크롤링 가능으로 간주한다. 개발 중에 공개된 URL이 있다면, 특히 Vercel 프리뷰 URL이나 스테이징 도메인이 외부에 노출된 상태였다면, Googlebot이 먼저 지나가는 경우가 생각보다 많다.

문제는 크롤러가 한 번 방문하고 색인을 만들면, 나중에 robots.txt로 막아도 이미 캐시된 결과는 바로 사라지지 않는다는 점이다. Disallow를 추가해서 접근을 막은 뒤 Search Console에서 "색인 삭제 요청"을 따로 해야 한다.

실제로 확인하는 순서

배포 후 robots.txt 상태를 확인할 때 쓰는 순서다.

# 현재 응답 확인
curl -s https://example.com/robots.txt

# 헤더까지 같이 보기 (캐시 여부 포함)
curl -I https://example.com/robots.txt

Next.js에서는 app/robots.ts 혹은 public/robots.txt로 제공한다. 두 방법을 동시에 쓰면 충돌이 생길 수 있어서 하나로 통일하는 편이 낫다.

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/api/', '/admin/'],
    },
    sitemap: 'https://example.com/sitemap.xml',
  }
}

Search Console에서 빠르게 확인하는 법

Google Search Console의 "URL 검사" 도구에 문제가 된 URL을 붙여넣으면 크롤러가 마지막으로 방문한 시점과 색인 상태를 볼 수 있다. 이미 색인된 URL을 빠르게 제거하려면 "삭제" 탭에서 임시 삭제를 요청할 수 있는데, 효과가 즉시 나타나지는 않는다.

프리뷰 URL이 색인되는 걸 막고 싶다면 Vercel 프로젝트 설정에서 X-Robots-Tag 헤더를 프리뷰 환경에만 적용하는 방법도 있다.

// next.config.ts
const nextConfig = {
  async headers() {
    if (process.env.VERCEL_ENV !== 'production') {
      return [
        {
          source: '/(.*)',
          headers: [{ key: 'X-Robots-Tag', value: 'noindex' }],
        },
      ]
    }
    return []
  },
}

배포 전에 robots.txt가 올바른 도메인에서 올바른 내용으로 나오는지, sitemap URL이 같은 도메인을 가리키는지 확인하는 걸 배포 체크리스트에 넣어두는 게 제일 확실한 방법이다.