HTTP 200인데 구글에 본문이 안 보이나요? 서버 응답·렌더링·색인을 나누는 6단계

핵심만 먼저

브라우저에서 페이지가 열리고 HTTP 상태가 200이라고 해서 Google이 본문을 바로 색인할 수 있다는 뜻은 아닙니다. 200은 요청이 성공했다는 신호일 뿐입니다. 초기 HTML에 내용이 없고 JavaScript 실행 뒤에만 본문이 생기거나, 중요한 스크립트가 robots.txt에 막혀 있거나, 로그인·클릭 뒤에 내용을 불러오면 Google이 기대한 내용을 보지 못할 수 있습니다.

진단할 때는 `서버가 보낸 HTML`, `브라우저가 렌더한 DOM`, `Google URL 검사에서 본 HTML`, `색인 결과`를 한 묶음으로 보지 말아야 합니다. 네 단계가 어디서 갈라졌는지 찾으면 “색인 요청을 다시 누르기”보다 빠르게 원인을 좁힐 수 있습니다.

HTTP 200과 색인은 무엇이 다른가요

HTTP 200은 서버가 정상 응답을 반환했다는 뜻입니다. 그러나 정상 응답 안에 빈 앱 껍데기만 있을 수도 있고, 오류 메시지를 200으로 반환하는 소프트 404일 수도 있습니다. Google은 페이지가 작동하고, 색인 가능한 텍스트가 있으며, 정책과 robots 지시를 충족하는지 추가로 판단합니다.

JavaScript 사이트에서는 Googlebot이 URL을 가져온 뒤 렌더링 대기열에 넣고 Chromium으로 스크립트를 실행할 수 있습니다. 이 과정이 즉시 끝난다고 보장되지 않으며, 필요한 JS·API·CSS가 차단되거나 오류가 나면 사용자가 보는 화면과 Google이 보는 화면이 달라집니다.

오늘 이슈와 공식 근거

Google 검색 기술 요구사항은 색인 대상 페이지가 HTTP 200 성공 상태를 반환하고 색인 가능한 콘텐츠를 제공해야 한다고 설명합니다. Page Indexing 보고서와 Crawl Stats 보고서가 서로 다른 문제를 보여줄 수 있으므로 두 보고서를 함께 보라고 권장하며, 특정 URL은 URL 검사 도구로 확인하라고 안내합니다.

Google JavaScript SEO 문서는 200 응답 페이지가 렌더링 대기열로 들어갈 수 있지만 실제 색인은 렌더된 HTML을 바탕으로 진행된다고 설명합니다. robots.txt로 페이지나 필수 리소스를 막으면 Google Search가 해당 JavaScript를 렌더하지 못할 수 있습니다. 또한 클릭·스와이프·입력 같은 사용자 상호작용 뒤에만 본문을 불러오는 방식은 크롤러가 내용을 놓칠 위험이 있습니다.

사장님 실무 적용 6단계

1. 응답 코드를 확인합니다. 상세 URL이 200인지, 리디렉션이 반복되지 않는지, 오류 화면을 200으로 돌려주는 소프트 404가 아닌지 봅니다.
2. 초기 HTML을 확인합니다. 페이지 소스에 제목, 핵심 요약, 본문 일부, 내부링크가 들어 있는지 확인합니다. 빈 `div`와 스크립트만 있다면 렌더 의존도가 높습니다.
3. 실제 렌더 화면과 비교합니다. 브라우저 개발자 도구에서 JavaScript 오류와 실패한 네트워크 요청을 봅니다. 사용자 화면에 본문이 있어도 API가 간헐적으로 실패하면 크롤러 재현성이 떨어집니다.
4. robots와 메타 지시를 검사합니다. 페이지, JS, API 경로가 robots.txt에 막히지 않았는지, `noindex` 또는 잘못된 canonical이 없는지 확인합니다.
5. URL 검사 렌더 결과를 봅니다. Google이 마지막으로 본 HTML과 스크린샷에서 핵심 본문·제목·이미지가 보이는지 확인합니다. 라이브 테스트와 색인본의 차이도 기록합니다.
6. 수정 후 재수집을 요청합니다. 원인을 고친 다음 sitemap·내부링크·URL 검사로 발견 신호를 보냅니다. 수정 없이 요청만 반복하지 않습니다.

점검표는 `URL / HTTP / 초기 HTML 글자 수 / 렌더 HTML 글자 수 / JS 오류 / robots / canonical / URL 검사 본문 / 조치` 아홉 칸으로 만드세요. 글자 수는 순위 지표가 아니라 본문이 사라지는 지점을 찾는 진단값입니다.

흔한 실수

• 브라우저에서 열리니 Google도 같은 화면을 본다고 가정합니다.
• 200 응답만 확인하고 오류 문구나 빈 앱 껍데기를 놓칩니다.
• JavaScript 파일과 API 경로를 robots.txt로 막습니다.
• 본문을 버튼 클릭이나 무한 스크롤 뒤에만 불러옵니다.
• URL 검사에서 라이브 테스트만 보고 마지막 색인본을 확인하지 않습니다.
• 코드 수정 없이 색인 생성 요청만 반복합니다.
• canonical이 다른 URL을 가리키는데 현재 URL의 색인만 기다립니다.

제스토코스트의 판단

JavaScript SEO는 “Google이 JS를 읽을 수 있느냐”라는 예·아니오 문제가 아닙니다. 읽을 수 있어도 늦게 읽거나, 일부 리소스를 놓치거나, 오류가 발생한 시점의 빈 화면을 볼 수 있습니다. 그래서 핵심 본문과 링크를 서버 HTML에 포함하고 나머지 상호작용만 JavaScript에 맡기는 구조가 운영상 유리합니다.

또한 색인 요청은 수리 도구가 아니라 재확인 요청입니다. 200, 본문, robots, canonical, 렌더 결과가 먼저 정상이어야 합니다. 이 순서를 지키면 요청 할당량을 같은 오류에 낭비하지 않고, 문제를 개발자에게도 정확한 증거로 전달할 수 있습니다.

자주 묻는 질문

HTTP 200이면 색인 조건을 충족한 것 아닌가요?

필수 조건 중 하나일 뿐입니다. 페이지에 색인 가능한 내용이 있어야 하고, robots·noindex·canonical·정책 문제도 없어야 합니다.

Google은 JavaScript를 실행하나요?

공식 문서는 Googlebot이 200 페이지를 렌더링 대기열에 넣고 Chromium으로 렌더할 수 있다고 설명합니다. 다만 시점과 성공을 보장하지 않으며 차단된 리소스나 오류는 그대로 문제가 됩니다.

본문이 클릭 뒤에 나타나면 안 되나요?

핵심 콘텐츠는 사용자 상호작용 없이 로드되는 편이 안전합니다. Google은 클릭·입력 같은 행동을 전제로 본문을 불러오지 않을 수 있으므로 중요한 텍스트와 링크를 초기 또는 자동 렌더 결과에 포함하세요.

출처

• Google Search Central: Google 검색 기술 요구사항
• Google Search Central: JavaScript SEO 기본사항
• Google Search Central: 검색 관련 JavaScript 문제 해결

내부링크 제안

• Search Console의 URL 등록 문구와 실제 노출을 구분하는 법
• 내부링크 앵커 텍스트를 구글이 이해하게 만드는 5단계

CTA

색인이 늦은 URL 하나를 골라 200 여부만 보지 말고 초기 HTML과 렌더 HTML의 핵심 본문을 나란히 비교하세요. 둘이 다르면 색인 요청 전에 그 차이가 생긴 리소스와 오류부터 고치시기 바랍니다.

편집 고지: 이 글은 공식 자료 조사와 초안 정리에 자동화 도구를 활용했으며, 공개 전 출처·표현·실무 적합성을 검수합니다.