기술적 차이를 기준으로 정하는 표본
점검 대상 페이지 표본은 인기 페이지에만 한정하지 않고, 구현 방식·주소 관계·변경 여부가 다른 묶음에서 대표 URL과 예외 URL을 함께 선정합니다. 사이트 운영자는 개발 담당에게 공통 구현과 예외를 확인한 뒤, 각 묶음을 대표하는 주소와 다른 조건이 적용된 주소를 점검 대상으로 정합니다.
방문이 많은 페이지 목록은 업무상 중요한 주소를 찾는 자료로 사용합니다. 방문량이 비슷해도 본문을 불러오는 코드나 모바일 제공 방식이 다르면 같은 표본으로 대신할 수 없습니다. 반대로 서로 다른 메뉴에 있어도 같은 화면 틀과 본문 제공 코드를 사용한다면 하나의 묶음으로 정리할 수 있습니다.
대표 URL은 해당 묶음의 공통 구현을 사용하는 주소입니다. 예외 URL은 별도 코드, 기기별 응답, 주소 이동 등 공통 조건에서 벗어난 주소입니다. 개발 담당이 공통 범위를 설명할 수 없는 경우에는 메뉴 이름만으로 대표성을 정하지 않고, 구현이 같은지부터 가립니다.
| 페이지 묶음 | 구현·주소·변경 차이 | 대표 URL | 예외 URL |
|---|---|---|---|
| 공통 화면 틀 | 같은 틀과 본문 제공 코드 사용 여부 | 공통 구현을 사용하는 주소 | 개별 코드가 추가된 주소 |
| 모바일 제공 | 기기별 HTML 또는 주소 차이 | 기본 제공 방식을 사용하는 주소 | 기기별 처리가 다른 주소 |
| 본문 표시 | 초기 표시·스크립트 처리·사용자 조작 차이 | 공통 본문 표시 방식의 주소 | 별도 표시 조건이 있는 주소 |
| 주소 관계 | 중복·대체·리디렉션 관계 | 내용을 제공하는 기준 주소 | 중복 주소 또는 이동 전 주소 |
| 최근 변경 | 공통 코드 변경과 개별 변경의 범위 | 변경이 적용된 공통 주소 | 적용 범위나 코드가 다른 주소 |
이 분류는 운영자가 표본을 선정하기 위한 실무 기준이며, 구글이 정한 공식 표본 선정 규정은 아닙니다. 같은 주소가 여러 조건에 해당하면 선정 이유를 함께 기재합니다. 조건마다 같은 주소를 목록에 반복해서 추가할 필요는 없습니다.
분류를 뒷받침하는 기술적 조건
구글 검색 센터는 반응형 웹 디자인이 기기와 관계없이 같은 주소와 HTML을 사용하며, 화면 크기에 따라 표시를 달리할 수 있다고 설명합니다. 동적 게재는 같은 주소에서 기기에 따라 다른 HTML을 제공하고, 별도 URL 구성은 기기별 주소와 HTML을 사용합니다. 운영자는 화면 크기에 따른 외형 차이와 실제 제공 방식의 차이를 따로 정리합니다.
구글 검색 센터는 클릭이나 입력 같은 사용자 조작이 필요한 콘텐츠를 구글이 로드하지 않는다고 설명합니다. 웹 구성요소의 콘텐츠도 렌더링된 HTML에 나타나지 않으면 색인을 생성할 수 없다고 안내합니다. 개발 담당에게 본문이 언제 어떤 처리로 나타나는지 물으면 외형이 비슷한 페이지 안에서도 별도 표본이 필요한 조건을 찾을 수 있습니다.
선정 전에 준비할 자료
사이트 운영자는 메뉴별 페이지 목록, 업무상 중요한 주소, 이미 알려진 접근 문제를 준비합니다. 개발 담당은 공통 화면 틀의 적용 범위, 모바일 제공 방식, 본문 표시 코드, 주소 이동 설정, 최근 배포의 적용 대상을 정리합니다. 완성된 기술 문서가 없다면 주소 목록 옆에 공통 구현 이름과 예외 사유를 기재하는 방식으로 시작합니다.
운영자는 겉으로 같은 페이지라는 이유만으로 묶음을 확정하지 않습니다. 개발 담당에게 본문을 제공하는 코드까지 같은지, 특정 페이지에만 별도 처리가 있는지 묻습니다. 답변이 불분명한 주소에는 미확정 사유를 남기고, 선정 단계에서 이를 제외한 것으로 오해하지 않도록 표시합니다.
- 페이지 목록에 공통 구현과 차이 조건을 표시하고, 같은 구현을 사용하는 주소를 묶습니다.
- 각 묶음에서 공통 조건의 대표 URL을 선정한 뒤, 다른 조건이 적용된 예외 URL을 추가합니다.
- 자료에는 있지만 선정 목록에는 없는 유형을 대조하고, 표본으로 판단할 수 없는 범위를 기재합니다.
선정 이유와 관련 주소의 정리
선정 목록에는 주소만 기재하지 않고 그 주소를 선택한 이유를 함께 남깁니다. 대표 URL에 문제가 나타났을 때 같은 구현을 사용하는 어느 범위까지 추가 판단이 필요한지 알 수 있어야 합니다. 다음 표의 주소 설명은 기재 항목을 설명하는 표현이며, 실제 업무에서는 담당자가 사이트의 해당 주소로 채웁니다.
| 선정 URL | 선정 이유 | 함께 확인할 관련 URL | 표본으로 확인하지 못하는 범위 |
|---|---|---|---|
| 공통 화면 틀의 대표 주소 | 공통 본문 제공 코드 점검 | 같은 틀을 사용하는 주소 | 개별 콘텐츠와 별도 코드 |
| 기기별 처리가 다른 주소 | 모바일 제공 조건 점검 | 대응하는 데스크톱·모바일 주소 | 다른 기기별 처리 유형 |
| 중복 또는 이동 전 주소 | 주소 관계 점검 | 표준 후보 또는 이동 대상 주소 | 다른 중복·이동 설정 |
| 최근 변경된 주소 | 변경된 구현의 적용 상태 점검 | 같은 변경이 적용된 주소 | 변경 대상 밖의 구현 |
관련 URL은 선정 URL과 기술적으로 연결된 주소를 기재하는 칸입니다. 같은 메뉴라는 이유로 무관한 주소를 모두 추가하지 않습니다. 운영자는 이 목록과 전체 분류 목록을 대조해 누락된 조건을 찾고, 개발 담당은 함께 묶은 범위에 다른 구현이 섞이지 않았는지 검토합니다.
주소의 역할을 혼동하는 선정 오류
중복 주소와 이동 전 주소는 내용을 직접 제공하는 주소와 역할이 다르므로, 목적 없이 서로 대신 사용하지 않습니다. 구글의 페이지 색인 생성 보고서 도움말은 중복 사본을 색인 생성하지 않으며, 리디렉션 주소 대신 이동 대상 주소의 색인을 생성한다고 설명합니다. 주소 관계를 점검하려는 표본에는 관계를 이루는 주소를 함께 기재하고, 본문 표시를 점검하려는 표본에는 실제 내용을 제공하는 주소를 선정합니다.
운영자가 표준 주소로 예상한 대상과 구글이 인식한 대상이 항상 같다고 전제해서도 안 됩니다. 구글의 URL 검사 도구 도움말은 소유한 속성에 표준 버전이 포함되어 있으면 대체·중복 버전의 표준 정보도 얻을 수 있다고 설명합니다. 선정 목록에는 운영자가 의도한 관계와 아직 확인하지 못한 관계를 따로 표시합니다.
이동 전 주소만 목록에 있으면 도착한 페이지의 공통 구현을 대표하는 표본이 빠질 수 있습니다. 반대로 이동 대상만 선정하면 이전 주소의 이동 관계는 점검 범위에서 제외됩니다. 담당자는 두 주소의 목적을 명시한 뒤 각각을 표본으로 사용할지 결정합니다.
최근 변경 표본의 해석 범위
최근 변경 페이지를 선정할 때는 현재 제공 상태와 검색엔진이 이미 수집한 상태를 같은 것으로 취급하지 않습니다. 구글의 URL 검사 도구 도움말은 색인이 생성된 URL 정보가 실시간 결과가 아닌, 최근 색인 버전을 기준으로 한다고 설명합니다. 운영자는 변경된 구현을 다루는 표본에 변경 내용을 기재해, 담당자가 어떤 상태를 판단하려는지 알 수 있게 합니다.
선정이 끝나면 아직 대표 주소를 정하지 못한 묶음과 예외 여부가 미확정인 주소를 별도로 정리합니다. 이를 정상으로 처리하지 않고, 자료 부족으로 판단을 유보한 범위라고 표시합니다. 일부 표본의 정상 결과만으로 사이트 전체의 정상 상태나 AI 검색 노출·인용을 보장할 수는 없습니다.
콘텐츠 조건이 만드는 구현 예외
같은 화면 틀을 사용하더라도 콘텐츠 조건에 따라 다른 코드가 실행된다면 예외 표본이 필요합니다. 개발 담당은 본문이 비어 있을 때, 첨부 요소가 있을 때, 특정 표시 항목을 사용할 때 공통 처리와 다른 경로가 작동하는지 설명합니다. 운영자는 단순히 문구가 다른 주소를 추가하기보다 코드의 처리 조건이 달라지는 주소를 요청합니다.
모든 콘텐츠 차이를 기술적 예외로 취급할 필요는 없습니다. 문구나 이미지가 달라도 제공 코드와 접근 조건이 같다면 기존 묶음에 포함할 수 있습니다. 콘텐츠 담당은 사용 중인 표시 항목을 전달하고, 개발 담당은 그 항목이 별도 구현을 사용하는지 가립니다.
자주 묻는 질문
페이지 표본 수를 미리 정해 놓아도 되나요?
업무량을 조정하기 위한 임시 목표는 정할 수 있지만, 목표 수에 맞추려고 다른 구현 유형을 제외하지는 않습니다. 먼저 묶음과 예외 목록을 완성하고 실제로 점검할 수 있는 범위를 정합니다. 범위가 제한되면 포함하지 못한 유형을 담당자에게 명시합니다.
로그인이 필요한 페이지도 표본에 포함해야 하나요?
외부 검색을 위한 공개 페이지와 로그인 이후의 페이지는 점검 목적에 따라 목록을 나누는 편이 좋습니다. 로그인 페이지까지 업무 범위에 포함한다면 필요한 접근 조건과 담당 권한을 먼저 정합니다. 공개 페이지의 표본 결과를 로그인 이후 화면에 그대로 적용하지 않습니다.
개발 담당이 바뀌어 구현 자료가 없으면 어떻게 하나요?
운영자는 현재 접근 가능한 페이지 목록과 변경을 요청했던 내역부터 모읍니다. 새 개발 담당에게는 전체 구조를 추측해 분류하도록 요구하지 않고, 선정 후보가 같은 코드를 사용하는지부터 답변을 요청합니다. 근거를 얻지 못한 묶음은 임시 분류로 표시합니다.
오래된 페이지를 표본에서 제외해도 되나요?
오래되었다는 이유만으로 제외하기보다는 현재도 사용하는 구현인지 판단합니다. 이전 화면 틀이 남아 있거나 새 페이지와 다른 제공 코드를 사용한다면 점검 대상이 될 수 있습니다. 운영 종료가 확정된 페이지는 공개 운영 페이지와 다른 목적으로 목록에 기재합니다.
검사 권한이 없는 관련 주소는 어떻게 처리하나요?
관련 주소를 목록에서 삭제하지 말고 권한 부족으로 검사하지 못한다고 표시합니다. 구글의 URL 검사 도구는 검사할 주소가 현재 속성에 포함되어 있어야 한다고 안내합니다. 운영자는 해당 주소의 관리 담당에게 필요한 정보를 요청하고, 응답 전에는 관계가 검증된 것으로 처리하지 않습니다.