번호별 글 목록과 주소를 함께 조사하기
게시판의 번호 목록은 다음 페이지에 다른 글이 있는지부터 읽고, 각 목록의 고유 URL과 자체 표준 URL을 대조합니다. 뒤 목록까지 첫 페이지를 canonical로 지정하는 방식은 Google의 페이지 나누기 권장사항과 맞지 않습니다. Google의 전자상거래 가이드는 제품 목록뿐 아니라 블로그 게시물이나 뉴스레터 제목 등 일부 결과를 로드하는 상황을 설명합니다. 그 기술 원칙을 병원 게시판 목록에 적용하는 방법을 제안합니다.
조사할 때에는 번호가 달라졌다는 표시와 실제 글 목록의 변화를 대응시킵니다. 동일한 글을 정렬만 바꿔 표시하는 주소와 새로운 글 묶음을 제공하는 다음 목록은 처리 목적이 다릅니다. 게시판의 사용자 화면을 어떤 형태로 만들지 하나의 정답으로 규정하기보다, 현재 방식에서 Google이 다른 콘텐츠까지 찾아갈 수 있는지를 읽는 질문입니다.
가이드는 페이지로 나누기, 더 로드하기, 무한 스크롤을 구별합니다. 번호와 다음·이전 링크는 페이지 사이 이동에 쓰이고, 더 로드하기는 버튼 동작으로 처음의 결과 집합을 늘립니다. 무한 스크롤은 끝까지 이동하면 새 콘텐츠를 가져오는 방식입니다. 이 차이를 조사하면 화면에 번호가 없어도 콘텐츠가 어떤 방식으로 추가되는지 설명할 수 있습니다.
| 조사할 목록 | 실제 글의 관계 | 주소에서 읽을 질문 | 처리 목적 |
|---|---|---|---|
| 첫 번째 목록 | 컬렉션의 시작 | 시작 주소가 무엇인가 | 방문 출발점 식별 |
| 다음 번호 목록 | 이전 목록과 다른 글 묶음 | 독립 URL이 있는가 | 다음 콘텐츠 발견 |
| 다른 정렬 목록 | 같은 글 집합의 순서 변경 | 불필요한 변형 주소인가 | 중복 변형의 처리 |
| 필터를 적용한 목록 | 선택 조건에 따른 결과 | 공개 목적에 맞는 대상인가 | 색인 대상 정책 판단 |
점진적으로 자료를 가져오는 방식은 처음에 모든 결과를 로드할 때보다 초기 로드와 네트워크 사용을 줄일 수 있다고 가이드는 설명합니다. 데이터베이스에서 가져오는 양을 줄여 백엔드 성능을 개선하고, 지나치게 긴 목록이 리소스 제한에 도달해 오류가 생기는 일을 피하는 이점도 제시합니다. 목록을 나누는 목적 자체를 검색에 불리한 선택이라고 단정하지 않습니다.
번호로 나누면 사용자가 결과의 크기와 현재 위치를 파악하는 데 도움이 되지만, 이동 제어가 복잡하고 항목을 더 보려면 새 페이지를 로드해야 하는 단점이 있다고 안내합니다. 병원 게시판에 적용할 때에는 이 조건을 화면 선택의 참고자료로 사용할 수 있습니다. 게시글의 실제 양이나 이용 행동을 조사하지 않은 상태에서 특정 구성의 편의성이 더 높다고 주장하지 않습니다.
순차 링크와 페이지별 표준 주소를 대조하기
Google은 일반적으로 앵커 요소의 href 속성에 있는 URL을 크롤링하며 버튼을 클릭하지 않는다고 가이드는 설명합니다. 사용자 동작이 필요한 JavaScript 함수를 일반적으로 실행하지도 않습니다. 번호 버튼을 눌렀을 때 화면이 바뀐다는 결과만으로 크롤러가 다음 목록을 찾을 수 있다고 답하지 않습니다. 현재 구현에서 실제 링크 주소가 제공되는지 조사할 수 있습니다.
각 페이지를 다음 페이지로 연결하는 링크를 포함하면 검색엔진이 페이지 간 관계를 이해하고 다음 콘텐츠를 찾는 데 도움이 된다고 안내합니다. 이를 적용하는 절차로 첫 목록부터 순서대로 링크 목적지를 따라가며 각 번호의 주소와 실제 목록을 대조하는 방법을 제안합니다. 잘못된 링크가 모두 같은 목록을 가리키는지와 마지막 목록에서 어떤 이동을 제공하는지 읽을 수 있습니다.
컬렉션의 모든 개별 페이지를 첫 페이지로 다시 연결하는 방법도 권장합니다. 시작 부분을 강조하고 첫 페이지가 다른 목록보다 방문 페이지로 적합하다는 점을 알리는 연결입니다. 이 안내는 뒤 목록을 첫 페이지의 중복으로 선언하라는 뜻이 아닙니다. 첫 목록으로 돌아가는 탐색 링크와 페이지의 표준 주소를 나타내는 설정은 목적이 다릅니다.
| 구현 항목 | 가이드의 조건 | 실제 소스에서 조사할 관계 | 피할 오류 |
|---|---|---|---|
| 다음 목록 링크 | href를 가진 순차 연결 | 다음 번호의 콘텐츠로 도착 | 동작 버튼만 존재 |
| 번호별 URL | 각 페이지의 고유 주소 | 주소와 다른 글 목록의 대응 | 프래그먼트만 변경 |
| canonical | 각 페이지의 고유 표준 URL | 현재 목록의 대표 주소 | 모든 목록을 첫 페이지로 지정 |
| 사이트 내 연결 | 표준 주소에 일관되게 연결 | 탐색 링크와 표준 설정의 일치 | 중복 변형으로 연결 |
번호별 고유 주소는 쿼리 매개변수를 사용하는 형태로도 표현할 수 있다고 가이드는 예를 듭니다. 반면 샵 기호 뒤의 프래그먼트만 달라지는 번호 방식은 피하도록 권고합니다. Google은 프래그먼트 식별자를 무시하므로 이미 가져온 페이지라고 판단해 다음 링크를 따라가지 않을 수 있기 때문입니다. 화면의 번호뿐 아니라 실제 요청 주소의 구별이 필요합니다.
일반적으로 페이지마다 고유한 제목을 권장하지만, 페이지 나누기 순서의 모든 페이지에는 동일한 제목과 설명을 사용할 수 있다고 설명합니다. Google이 순서를 인식하고 그에 따라 색인 생성을 시도하는 상황입니다. 번호별 주소가 다르다는 이유로 제목에 새 키워드를 의무적으로 넣는 기준으로 확대하지 않습니다. 실제로 다른 글 목록을 제공하는 관계를 우선 조사할 수 있습니다.
표준화 가이드는 동일 콘텐츠 또는 매우 비슷한 페이지의 선호 URL을 알리는 방법을 설명합니다. 리디렉션과 canonical은 강력한 신호, 사이트맵 포함은 약한 신호이며 함께 사용할 수 있습니다. 그러나 서로 다른 방법에서 같은 문서의 대표 주소를 다르게 지정해서는 안 됩니다. 게시판의 표준 설정과 사이트맵의 대상 주소가 충돌하는지 읽는 방법을 적용할 수 있습니다.
중복 변형과 실제 다음 목록을 다르게 처리하기
같은 결과 목록을 필터하거나 순서만 바꾼 주소가 원치 않는 색인 변형을 만드는 경우, 페이지 나누기 가이드는 noindex 메타로 색인을 막거나 로봇 규칙 파일로 특정 주소 패턴의 크롤링을 차단하는 방법을 제시합니다. 이 조건은 다른 글을 담은 다음 번호 목록을 무조건 차단하라는 설명이 아닙니다. 주소가 맡는 역할을 구별한 뒤 공개 목적에 맞는 처리 대상을 정할 수 있습니다.
표준화 자체를 목적으로 로봇 규칙 파일을 사용해서는 안 된다고 표준화 가이드는 안내합니다. 차단한 주소도 콘텐츠 없이 색인이 생성될 수 있기 때문입니다. URL 삭제 도구로 표준화를 시도하는 것도 피해야 하며, 그 도구는 Google 검색에서 모든 버전의 URL을 숨긴다고 설명합니다. 크롤링 제한, 색인 제외, 대표 URL 신호를 서로 바꿔 쓰는 문제를 조사할 근거입니다.
표준화 가이드는 canonical에 붙인 lang, media, type 속성이 표준화에 사용되지 않는다고 설명합니다. 언어와 국가의 대체 버전은 적절한 alternate와 hreflang 주석으로 지정하도록 안내합니다. 별도 속성이 있다는 이유로 번호 목록의 대표 주소가 달라졌다고 판단하지 않습니다.
같은 사이트에서 표준 페이지를 선택하기 위해 noindex를 쓰면 페이지가 Google 검색에서 완전히 차단될 수 있어 권장하지 않는다고 안내합니다. 대표 주소를 지정하려는 경우에는 canonical 링크 주석을 사용하도록 설명합니다. 앞의 원치 않는 정렬 변형 제외와는 목적이 다르므로 같은 설정을 일괄 적용하는 방식으로 설명하지 않습니다.
HTML의 canonical 링크 요소는 head 안에 있을 때만 허용된다고 안내합니다. 상대 경로도 지원하지만 장기적으로 의도치 않은 테스트 사이트를 크롤링하게 하는 문제 등이 생길 수 있어 절대 경로를 권장합니다. 실제 목록의 소스에서 요소의 위치와 지정 주소가 올바른지 읽는 절차를 제안합니다. 화면에서 표시되는 번호만으로 해당 설정이 반영됐다고 판정하지 않습니다.
JavaScript로 렌더링하는 경우에는 HTML 소스에서 표준 URL을 정하고 스크립트가 해당 요소를 변경하지 않도록 하는 것이 가장 명확한 방법이라고 설명합니다. 소스에서 지정할 수 없다면 JavaScript만으로 설정하도록 안내합니다. 게시판을 전환한 뒤 번호별 페이지의 설정이 실행 과정에서 달라지는지 조사할 수 있습니다. 서로 다른 두 곳의 설정이 계속 충돌하는 상태를 정상이라고 기재하지 않습니다.
내부 링크는 중복 주소보다 표준 주소에 일관되게 연결하도록 권고합니다. 표준화의 이유에는 관련 신호를 합치고 단일 콘텐츠의 측정항목 추적을 단순화하며 중복 버전을 크롤링하는 데 시간을 낭비하지 않도록 하는 목적이 포함됩니다. 각기 다른 글 묶음을 모두 한 주소의 중복으로 취급하는 일을 이 목적과 혼동하지 않습니다.
번호 목록의 설정 뒤 이어지는 질문
next와 prev 주석만 있으면 Google이 순서를 읽나요?
가이드는 Google이 과거에 사용했던 이 링크 주석을 이제 사용하지 않는다고 설명합니다. 다른 검색엔진은 계속 사용할 수도 있다고 구별합니다.
다음 페이지 이동을 더 빠르게 만들 방법도 있나요?
가이드는 미리 로드, 사전 연결, 미리 가져오기를 성능 최적화의 참고 방법으로 제시합니다. 특정 게시판의 속도 개선 수치는 실제 측정 없이 정하지 않습니다.
HTML 요소와 HTTP 헤더에 다른 대표 주소를 넣어도 되나요?
두 방식의 동시 사용은 지원되지만 오류가 발생하기 쉽다고 표준화 가이드는 안내합니다. 하나를 선택해 지속적으로 쓰는 방법을 권장하며 서로 다른 주소를 제공하는 상태를 오류 예로 듭니다.
PDF 자료의 표준 주소도 HTML 링크 요소로 지정하나요?
HTML 요소는 PDF 같은 파일에 작동하지 않으며 HTTP 응답 헤더로 표준 주소를 표시할 수 있다고 설명합니다. Google은 이 방법을 웹 검색결과에서 지원합니다.
중복 페이지를 계속 제공해야 한다면 영구 이동이 맞나요?
표준화 가이드는 영구 리디렉션을 중복 페이지를 더 이상 사용하지 않는 경우에 쓰도록 안내합니다. 계속 제공할 문서의 목적과 폐기하려는 중복 문서를 먼저 구별합니다.