웹 서비스 런칭 후 구글 색인 누락(404 에러) 해결하는 3단계 기술 체크리스트

핵심 요약 — 사용자 브라우저에서는 정상적으로 열리는 페이지가 구글 봇에게는 404로 반환되는 이유는 서버 설정 또는 라우팅 구성의 문제입니다. curl -I로 서버 응답을 직접 확인하고, Astro·Next.js·Vercel별 정적 파일 설정을 점검한 뒤 GSC URL 검사로 재요청하면 대부분 해결됩니다.

런칭 직후 구글 서치 콘솔을 확인했더니 “URL이 Google에 등록되어 있지 않음 — 이전에 크롤링되었지만 현재는 색인에 없음”이라는 메시지와 함께 상태가 404로 표시된 경험이 있으신가요? 분명 사이트는 잘 뜨는데, 왜 구글만 없다고 하는 건지 당황스러울 수 있습니다.

이 글에서는 실제 playw.work 런칭 과정에서 겪은 “사용자에겐 보이지만 구글 봇에겐 404인 상황”을 토대로 원인과 3단계 해결 방법을 정리합니다.

왜 내 눈에는 보이고 구글 봇에게는 안 보일까?

브라우저와 구글봇(Googlebot)은 동일한 URL을 요청해도 다른 경로로 접근합니다.

브라우저는 자바스크립트를 실행하고, SPA라면 클라이언트 사이드 라우팅으로 페이지를 그려냅니다. 반면 구글봇은 서버에서 실제로 HTML 파일을 반환받아야 합니다. 서버가 해당 경로에 대한 응답을 제대로 설정하지 않았다면 봇에게는 404가 반환되는 것입니다.

구글봇이 404를 받는 주요 원인:

• 정적 빌드 결과물 미배포: 빌드 폴더(dist/, .next/)가 서버에 제대로 올라가지 않은 경우
• 라우팅 폴백 설정 누락: SPA에서 새로고침 시 404 발생 — Vercel의 rewrites, Nginx의 try_files 미설정
• Trailing Slash 불일치: /about과 /about/을 다른 리소스로 처리하는 경우
• robots.txt 과도한 차단: Disallow: / 설정이 남아있거나, 잘못된 경로 차단
• CORS·인증 레이어: 구글봇 User-Agent를 다르게 처리하는 미들웨어

Step 1: curl 명령어로 서버 응답 1초 만에 진단하기

가장 먼저 해야 할 일은 서버가 실제로 무엇을 반환하는지 직접 확인하는 것입니다. 브라우저를 거치지 않고 HTTP 응답 헤더만 요청합니다.

# 응답 헤더 확인 (리다이렉트 추적 포함)
curl -sIL --max-time 10 "https://your-domain.com/target-page"

정상적인 응답이라면 HTTP/2 200이 반환됩니다. 404나 301/302 루프가 잡힌다면 서버 설정 문제입니다.

curl -sIL --max-time 10 \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://your-domain.com/target-page"

또한 robots.txt도 반드시 확인하세요.

curl -sL "https://your-domain.com/robots.txt"

Disallow: /가 있거나 색인이 필요한 경로가 차단된 경우 즉시 수정해야 합니다.

Step 2: 라우팅 및 정적 파일 설정 점검

Astro (정적 빌드)

Astro는 output: 'static' 모드에서 각 라우트에 대해 index.html 파일을 생성합니다. 이 파일이 서버에 올라가 있지 않으면 404가 발생합니다.

// astro.config.mjs
export default defineConfig({
  output: 'static',
  trailingSlash: 'always', // 또는 'never'로 통일 (혼용 금지)
});

Vercel에 배포한다면 vercel.json에 폴백 설정을 추가합니다.

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

Next.js (App Router)

generateStaticParams가 빠진 동적 라우트는 빌드 시 생성되지 않아 봇에게 404를 반환합니다.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Nginx

SPA나 SSG 사이트에서 직접 URL 접근 시 404가 나온다면 try_files 설정을 추가합니다.

server {
  location / {
    try_files $uri $uri/ /index.html;
  }
}

Step 3: GSC URL 검사로 실제 색인 상태 확인 및 재요청

서버 설정을 수정했다면 구글 서치 콘솔의 URL 검사 도구로 직접 확인합니다.

1. Google Search Console 접속
2. 상단 검색창에 문제가 되는 URL 입력
3. “URL 검사” 실행 → “페이지 크롤링 테스트”로 봇 시점 확인
4. 결과가 정상이면 “색인 생성 요청” 클릭

자주 묻는 질문 (FAQ)

GSC에서 “크롤링됨 - 현재 색인에 없음”과 “404 오류”의 차이는? “크롤링됨 - 현재 색인에 없음(Crawled - currently not indexed)“은 봇이 접근했지만 구글이 색인 가치가 없다고 판단한 것이고, “404”는 봇이 접근 자체를 실패한 것입니다. 이 글에서 다루는 주제는 후자입니다.

sitemap.xml에 URL을 추가하면 바로 해결되나요? sitemap은 크롤링 우선순위에 도움을 주지만, 서버가 실제로 200을 반환하지 않으면 색인이 생성되지 않습니다. 서버 응답 수정이 먼저입니다.

구글봇이 차단된 경우 얼마나 빠르게 복구되나요? 서버 설정 수정 후 GSC URL 검사로 재요청하면 통상 24시간 ~ 72시간 내에 색인 상태가 업데이트됩니다.

기술적 결함 하나가 런칭 초기의 SEO 성과를 통째로 날릴 수 있습니다. 서버 설정 점검 → curl 진단 → GSC 재요청 순서로 체계적으로 접근하면 대부분 해결됩니다.

웹 서비스 구축 및 SEO 기술 컨설팅이 필요하시다면 PLAYW에 문의하세요.