INDEXING INVESTIGATION · 브라우저가 아닌 HTTP 응답부터 색인 실패 지점을 추적합니다.
누가 읽어야 하나
회사나 서비스 페이지가 구글에 나오지 않아 원인을 찾는 마케팅 담당자와 Next.js 개발팀
어떻게 확인했나
브라우저 화면이 아니라 크롤러가 실제로 받는 응답 계약을 기준으로 HTTP → HTML → 정규화 → 발견 경로를 차례로 검사합니다. 아래 명령과 판정표는 공개 URL에서 그대로 재현할 수 있습니다.
HTTP → HTML → Canonical → Discovery
검증 순서
Indexing investigation
GET /page → ?구글에서 우리 홈페이지가 검색되지 않을 때, 어디부터 확인해야 할까?
브라우저에서 보이는 화면은 조사 시작점이 아닙니다. 검색 로봇이 받은 응답부터 발견 경로까지 한 줄로 추적합니다.
먼저 검색되지 않는 URL이 200 응답을 반환하는지 확인하세요. 다음으로 서버가 보낸 HTML에 제목과 핵심 본문이 있는지, canonical과 robots 설정이 충돌하지 않는지, 메뉴·본문 링크·사이트맵에서 해당 URL을 찾을 수 있는지 봐야 합니다. 메타태그와 JSON-LD 수정은 이 네 조건을 확인한 뒤에 해야 합니다.
Symptom router
지금 보이는 증상을 선택하세요.
Request trace
원인을 네 단계에서 끊어 찾습니다.
Repair order
메타태그는 네 조건이 통과한 뒤에 봅니다.
- 01상태 코드와 리디렉션 체인 정상화
- 02서버 HTML의 핵심 본문 확인
- 03canonical·robots 충돌 제거
- 04메뉴·본문·사이트맵 발견 경로 복구
Follow-up questions
판단 전에 남는 질문
프레임워크 자체보다 렌더링과 배포 결과가 중요합니다. 중요한 본문과 메타데이터가 서버가 반환하는 HTML에 있고 URL·상태 코드·내부 링크가 일관되면 App Router에서도 검색 기반을 안정적으로 만들 수 있습니다.
먼저 해당 URL이 유일한 가치와 명확한 내부 링크를 갖는지 확인하고, canonical·응답·렌더링 오류를 배제합니다. 단일 상태 문구만으로 원인을 단정하지 말고 URL 검사 결과와 서버 로그를 함께 봐야 합니다.
Before you apply
- 모든 기술 조건을 통과해도 검색엔진의 크롤링과 색인은 보장되지 않습니다.
- 로그인, 지역화, 대규모 JavaScript 렌더링처럼 실행 환경에 의존하는 페이지는 서버 로그와 검색엔진 URL 검사 결과를 추가로 확인해야 합니다.
참고 자료
편집·검증 정책- 01Next.js generateMetadata
이 자료에서 확인할 내용: App Router 메타데이터 생성 방식과 서버 렌더링 동작
- 02Google Search 기술 요구사항
이 자료에서 확인할 내용: 색인 자격을 위한 기술적 최소 조건
- 03Google canonical 지정 방법
이 자료에서 확인할 내용: 리디렉션·canonical·사이트맵 신호의 관계
- 04Google 사이트맵 만들기
이 자료에서 확인할 내용: 사이트맵에 대표 URL을 제공하는 기준