화면과 응답의 차이
사람에게 열리는 페이지를 검색로봇도 읽는지 알려면 같은 URL의 브라우저 화면, HTTP 응답과 본문, 차단 조건을 비교해야 합니다. Google의 URL 검사 도구에서는 실시간 테스트의 렌더링 화면과 리소스·페이지 코드를 조사할 수 있습니다. 화면이 열린다는 사실만으로 수집 성공이나 색인 생성을 판정할 수는 없습니다.
병원 홈페이지의 공개 진료 안내를 검사한다면 제목과 주요 설명이 사람 화면에 나타나는지부터 구분합니다. 이어 서버가 반환한 HTML과 검사 도구가 렌더링한 결과에 해당 내용이 있는지 비교합니다. 원본 HTML에 내용이 없어도 JavaScript 실행 뒤 나타날 수 있으므로 원본만으로 읽기 실패를 단정하지 않습니다.
반대로 브라우저에서 본문이 보여도 로그인 상태나 이전 방문 때 저장된 정보에 의존할 수 있습니다. 같은 주소에 접속했다는 조건과 같은 내용을 받았다는 조건은 다릅니다. 검색로봇의 접근 여부를 판단할 때는 화면 모양보다 필요한 내용이 응답과 렌더링 결과에 실제로 존재하는지가 중요합니다.
이 절차의 대상은 관리 권한이 있는 공개 페이지와 허용된 테스트입니다. 로그인 뒤 제공되는 개인 자료를 시험 목적으로 공개하거나 보안 제한을 임의로 해제하지 않습니다. 공개 진료 안내와 비공개 기능이 함께 있는 주소라면 공개되어야 할 내용의 범위를 먼저 정해야 비교 결과를 해석할 수 있습니다.
같은 주소의 비교 기록
검사할 전체 URL을 하나 정하고 브라우저 접속 시각, 로그인 여부, 이동한 주소를 기록합니다. Search Console에서는 현재 선택한 속성에 포함된 URL을 입력해야 합니다. 다른 속성의 결과나 비슷한 주소의 정상 화면으로 해당 페이지의 접근 상태를 대신 판단하지 않습니다.
| 대상 URL | 브라우저 화면 | HTTP·본문 | 검사 화면 | 차이 기록 |
|---|---|---|---|---|
| 공개 안내 주소 | 제목·주요 설명의 표시 여부 | 상태 코드·반환 HTML의 내용 | 실시간 화면·렌더링 HTML | 빠진 문단과 발생 위치 |
| 이동이 있는 주소 | 접속 뒤 도착한 주소 | 리디렉션 응답과 이동 경로 | 입력 주소의 테스트 결과 | 서로 다른 페이지 비교 여부 |
| 조작이 필요한 주소 | 버튼 조작 전후의 본문 | 첫 응답에 포함된 내용 | 테스트에서 나타난 내용 | 사용자 조작에 의존한 부분 |
이 표는 실측 결과가 아니라 기록 항목입니다. 빈칸에는 실제 응답과 테스트 결과만 입력합니다. 화면 차이가 발견되어도 원인을 바로 JavaScript나 차단 설정으로 정하지 않고, 해당 차이를 설명할 응답·리소스·오류 정보를 함께 모읍니다.
리디렉션이 있으면 주소 기록이 특히 중요합니다. Google의 실시간 테스트는 이동을 따라 대상을 검사하지만, 이동 사실과 최종 테스트 주소를 결과에 표시하지 않습니다. 브라우저가 도착한 주소와 서버의 이동 경로를 별도로 확보해야 서로 다른 페이지를 비교하는 오류를 줄일 수 있습니다.
HTTP·본문·차단 조건의 구분
HTTP 응답은 서버가 요청에 답한 상태를, 본문은 전달한 내용을 나타냅니다. JavaScript 기반 페이지는 오류 화면에도 200 응답을 반환할 수 있으므로 정상 상태 코드만으로 필요한 안내가 전달되었다고 판단하지 않습니다.
페이지 가져오기가 실패했다면 실패 이유부터 파악합니다. 크롤링 허용 여부와 페이지 가져오기 항목을 구분하여 오류 설명을 기록합니다. 크롤링이 허용되어도 서버 연결 등의 문제로 가져오기에 실패할 수 있습니다.
robots.txt의 수집 제한과 noindex의 색인 제한은 역할이 다릅니다. robots.txt로 차단된 페이지에서는 Google이 noindex를 읽지 못해 색인 생성 허용 여부가 '예'로 표시될 수 있습니다. 이 값은 수집 허용 상태와 함께 판단해야 합니다.
공개 안내의 수집을 허용하려는 경우에만 차단 규칙과 적용 대상을 개발 담당자에게 전달합니다. 차단은 기존 색인 삭제나 정보 비공개를 보장하지 않습니다. 공개 범위 결정과 요청 오류 수정을 혼동하면 의도하지 않은 정보 노출로 이어질 수 있습니다.
실시간 화면과 페이지 코드
URL 검사에 처음 표시되는 결과는 가장 최근에 색인이 생성된 버전의 정보입니다. 현재 접근 상태는 '실제 URL 테스트'로 조사합니다. 실시간 테스트를 실행하려면 로그인 요구사항 없이 인터넷으로 페이지에 접근할 수 있어야 합니다.
성공적인 실시간 테스트에서는 '테스트된 페이지 보기'에서 스크린샷을 이용할 수 있습니다. 이는 Google-InspectionTool이 인식한 화면입니다. 병원 안내의 제목과 주요 문단을 비교하되 모든 검색로봇의 결과로 확대하지 않습니다.
추가 응답 데이터에는 반환된 원시 HTML, HTTP 헤더, JavaScript 콘솔 출력, 로드된 페이지 리소스 등이 포함됩니다. 실시간 테스트에서 이 정보는 'URL을 Google에 등록할 수 있음' 또는 'URL을 Google에 등록할 수 있지만 문제가 있음' 상태일 때 사용할 수 있습니다.
첫 응답에 없던 문단이 렌더링 뒤 나타났다면 JavaScript 실행을 거친 결과로 구분합니다. 스크린샷의 글자가 작거나 영역이 잘려 판단이 어려우면 페이지 코드에서 해당 문구를 찾아 보완합니다.
색인된 버전이나 가져오기에 실패한 실시간 테스트에는 스크린샷이 제공되지 않습니다. 화면 부재를 본문 부재로 해석하지 않고 테스트 상태부터 읽어야 합니다. 과거 색인 정보와 현재 테스트 정보는 각각의 시각과 함께 비교합니다.
본문 누락과 리소스의 관계
사람 화면에 있는 문단이 검사 결과에서 빠졌다면 해당 문단을 만드는 리소스와 JavaScript 오류를 조사합니다. Google은 필수 콘텐츠에 기여하지 않는 리소스를 가져오지 않을 수 있으므로 미로드 요청만으로 본문 수집 실패를 단정하지 않습니다.
| 관측 차이 | 추가 조사 대상 | 다음 행동 |
|---|---|---|
| 주요 문단 누락 | 렌더링 HTML·본문 생성 요청·콘솔 오류 | 빠진 내용과 관련된 실패 요청을 개발 담당자에게 전달 |
| 화면 배치만 다름 | 본문 존재 여부·스타일 리소스 | 내용 누락과 표시 차이를 분리하여 수정 범위 결정 |
| 일부 요청 미로드 | 필수 콘텐츠와 해당 요청의 관계 | 본문에 영향을 주는 요청인지부터 판단 |
| 수정 전 내용 표시 | 사용된 JavaScript·CSS 파일 버전 | 오래된 리소스 사용 가능성과 배포 상태 조사 |
저장된 정보에 따라 본문을 만드는 구조도 비교 대상입니다. Google의 렌더링 서비스는 페이지 로드 전체에서 상태를 유지하지 않으며, 로컬·세션 저장소와 HTTP 쿠키 데이터는 로드 도중 삭제됩니다. 이전 방문 정보가 필요한 안내는 새 접속 조건의 화면과 테스트 결과를 비교합니다.
Googlebot은 HTTP 요청으로 콘텐츠를 가져오며 WebSockets나 WebRTC 연결을 지원하지 않습니다. 필요한 안내가 그런 연결에만 의존한다면 HTTP 대체 경로를 개발 담당자와 논의합니다. 화면 차이만으로 추정하지 않고 실제 요청 방식이 해당하는 경우에 한정합니다.
수정 후 재시험과 결론의 범위
누락된 문단이나 실패 요청의 원인에 맞춰 수정하고, 변경 항목을 기록한 뒤 같은 URL로 실시간 테스트를 반복합니다. 주소나 공개 범위까지 달라졌다면 오류 해결만으로 결과를 묶지 않습니다.
재시험에서는 누락 문구가 렌더링된 HTML에 나타나는지, 관련 요청의 실패가 사라졌는지, 가져오기 상태가 달라졌는지 비교합니다. 오류 표시가 없어도 필요한 본문이 빠졌다면 접근 문제가 해결되었다고 판단할 수 없습니다.
결과는 '이 시각의 Google-InspectionTool 테스트에서 해당 공개 본문에 접근 가능했다'처럼 대상과 조건을 붙여 기록할 수 있습니다. 이는 실제 색인 포함이나 검색결과 표시를 보장하지 않습니다. 실시간 테스트는 중복 여부와 표준 선택 등 모든 색인 조건을 다루지 않기 때문입니다.
네이버나 다른 AI 검색로봇의 접근 상태는 해당 서비스의 관측 자료로 별도 판단해야 합니다. Google 테스트 성공을 다른 로봇의 성공으로 일반화할 수 없습니다. 수집 가능성, 색인 상태, 실제 검색 노출을 구분하여 결과의 적용 범위를 명확히 합니다.
자주 묻는 질문
버튼을 눌러야 본문이 나오면 어떻게 하나요?
처음 열린 상태와 버튼 조작 뒤 상태에서 달라지는 문구를 분리합니다. 실시간 결과에 그 문구가 없으면 조작 의존 구간을 개발 담당자에게 전달하고, 공개 안내가 조작 없이 전달될 필요가 있는지 결정합니다. 사람이 눌러 읽었다는 사실로 로봇의 조작 성공을 추정하지 않습니다.
권한 요청 뒤에만 안내가 나오면 어떻게 하나요?
위치나 카메라 등의 권한을 거절해도 공개 안내에 접근할 경로가 있는지 시험합니다. Googlebot은 사용자 권한 요청을 거부할 것으로 예상해야 합니다. 권한이 꼭 필요한 기능과 일반 안내를 나누고, 일반 안내에는 권한 승인에 의존하지 않는 경로를 마련하는 방향으로 협의합니다.
수정했는데 옛 화면이 나오면 어떻게 하나요?
테스트에 사용된 리소스 파일과 배포한 파일의 버전을 비교합니다. Google의 렌더링 서비스는 캐싱 헤더를 무시하고 오래된 JavaScript나 CSS를 사용할 수 있습니다. 실제로 버전 차이가 있다면 파일 내용에 따라 이름이 바뀌는 배포 방식을 논의한 뒤 재시험합니다.
실시간 검사에서 서버 오류가 나면 어떻게 하나요?
오류 시각과 페이지 가져오기 사유를 보존하고, 같은 시각의 서버 응답 기록과 비교합니다. 일시적인 오류는 실시간 검사와 실제 크롤링에서 다르게 나타날 수 있습니다. 재시험이 성공해도 앞선 실패 기록을 삭제하지 않고 반복 여부를 판단할 자료로 남깁니다.
분석 도구에 로봇 방문이 없으면 실패인가요?
클라이언트 측 분석만으로 실패를 판정할 수 없습니다. Googlebot과 렌더링 서비스는 분석 요청을 생략할 수 있어 방문 기록이 활동을 완전히 반영하지 못합니다. 사이트 차원의 활동은 Search Console 크롤링 통계를 참고하고, 해당 URL의 접근은 개별 테스트 결과와 구분합니다.