무한 스크롤 대신 페이지 번호를 둘 때의 장점

페이지 번호의 장점과 주소 연결

방문자가 번호를 눌렀을 때 목록이 변경되는 동작과 검색로봇이 이동 주소를 추출하는 과정은 같지 않습니다. 번호를 누르는 동작에만 프로그램을 연결해도 화면은 변경될 수 있지만, 그 동작만으로 검색로봇이 읽을 링크가 마련됐다고 판단할 수는 없습니다. 페이지 번호 방식의 기술적 장점은 이동 대상을 링크의 주소로 명시할 수 있다는 데 있습니다.

표는 페이지 번호의 모양이 아니라 이동 주소가 표현되는 방식을 판단하기 위한 기준입니다. 운영자는 개편 전후의 숫자 표시를 비교하기보다, 이동 대상을 주소로 설명할 수 있는 설계인지 개발 담당자에게 요청해야 합니다. 무한 스크롤이라는 화면 방식만을 이유로 기존 목록이 검색에 불리하다고 결론 내릴 필요는 없습니다.

구글과 네이버의 링크 처리 조건

구글은 링크를 통해 새 페이지를 찾으며, 일반적으로 href 속성이 있는 앵커 요소에서 링크를 수집할 수 있다고 설명합니다. href가 없는 앵커 요소나 이벤트로만 링크처럼 작동하는 다른 요소에서는 주소를 안정적으로 추출하지 못한다고 안내합니다. 번호를 이동 수단으로 설계할 때는 이 조건에 맞는 링크인지 개발 담당자가 확인해야 합니다.

구글 안내에는 실제 주소가 있는 링크에 클릭 이벤트를 함께 사용하는 형태도 파싱 가능한 예로 포함되어 있습니다. 또한 링크의 주소는 크롤러가 요청할 수 있는 실제 웹 주소로 해석되어야 한다고 설명합니다. 따라서 동작을 추가했다는 이유만으로 문제라고 판단하지 말고, 주소가 없는 구현과 실제 주소를 유지한 구현을 따로 판단해야 합니다.

네이버는 앵커 요소의 href에서 다른 페이지 주소를 발견해 수집 범위를 넓힌다고 설명합니다. href에 자바스크립트 호출을 기재하면 정상적인 링크를 구성하지 못해 새 페이지 주소를 발견할 수 없다고 안내합니다. 두 서비스의 근거로 설명할 수 있는 것은 실제 주소를 명시하는 링크의 조건이며, 모든 AI 검색 서비스가 같은 방식으로 처리한다는 결론은 포함되지 않습니다.

번호별 이동 대상의 설계 순서

운영자는 목록 구간과 번호의 이동 대상을 함께 정한 뒤 개발 담당자에게 구현 조건을 전달해야 합니다. 화면 시안에 숫자만 표시한 상태에서는 어떤 주소를 연결해야 하는지 결정되지 않을 수 있습니다. 마케팅 담당자는 목록의 사용 목적과 이동 후 표시할 내용을 준비하고, 개발 담당자는 그 내용을 연결할 주소와 요소의 형태를 설명해야 합니다.

1. 번호의 이동 대상을 정합니다. 각 번호를 선택했을 때 표시할 목록 구간을 문서에 기재하고, 같은 번호를 서로 다른 의미로 사용한 곳이 있는지 가립니다.
2. 링크에 실제 주소가 담기는지 확인합니다. 개발 담당자는 번호 요소가 앵커 요소인지, href에 이동 주소가 있는지, 그 주소가 요청 가능한 대상으로 해석되는지를 설명합니다.
3. 번호 표시와 주소 연결을 따로 판단합니다. 운영자는 화면에서 이동이 되는 결과와 링크 조건을 충족한 결과를 각각 기록하고, 하나의 완료 항목으로 합치지 않습니다.

담당자가 준비할 자료는 번호가 포함된 화면 시안, 번호별 이동 대상 설명, 구현된 요소의 형태입니다. 개발 요청서에는 주소 자체를 기재할 공간과 이동 후 내용을 설명할 공간을 따로 마련합니다. 화면 시안과 구현 설명이 서로 다른 대상을 가리키면 번호 디자인을 확정하기 전에 이동 대상을 정정해야 합니다.

개발 요청 조건과 판단 한계

개발 담당자의 설명은 번호를 눌렀다는 결과만으로 끝나지 않아야 합니다. 사용한 요소의 종류, href에 담긴 값의 성격, 이동 대상의 설명을 함께 받아야 앞에서 정한 기준으로 판단할 수 있습니다. 기술 용어가 포함된 설명은 화면 시안의 해당 번호와 연결해 기록합니다.

요청서의 완료 조건은 링크 구현에 관한 항목으로 한정합니다. 수집량이나 검색 노출의 변화를 같은 완료 조건에 넣으면 구현 결과와 서비스별 처리 결과가 섞입니다. 운영자는 링크 조건을 충족한 사실과 아직 측정하지 않은 결과를 서로 다른 기록 항목으로 관리해야 합니다.

화면 이동과 링크 대상의 불일치

실제 주소가 있는 번호 링크라도 누르는 동작이 다른 목록 구간을 표시하면 운영자가 의도한 연결과 구현 결과가 어긋납니다. 개발 담당자는 이벤트가 처리한 이동 대상과 href에 기재한 이동 대상을 대조해야 합니다. 운영자는 두 결과 중 하나만 정상이라는 설명으로 변경 작업을 완료하지 않아야 합니다.

불일치가 항상 발생하는지 특정 조작 뒤에만 발생하는지에 따라 개발 담당자가 재현할 조건이 달라집니다. 마케팅 담당자는 문제가 발생한 시작 화면과 선택한 번호, 그 전에 수행한 조작을 함께 기록합니다. 같은 번호에서도 결과가 달라지면 정상적으로 이동한 조건도 함께 전달해 수정 대상을 좁히도록 요청합니다.

번호에 실제 주소를 넣었다는 개발 답변도 주소의 존재와 대상의 일치 여부로 나누어 받아야 합니다. 주소가 있다는 설명은 링크 구현의 일부를 설명하지만, 담당자가 지정한 목록으로 연결된다는 뜻까지 포함하지는 않습니다. 수정 기록에는 어떤 대상이 잘못 연결됐고 어느 항목을 정정했는지 기재합니다.

페이지 번호 도입의 판단 범위

페이지 번호 도입 여부는 현재 목록에서 어떤 이동을 주소로 표현하려는지에 따라 결정해야 합니다. 기존 방식의 이름만으로 개편을 결정하면 번호를 추가한 뒤에도 이동 대상이 불명확할 수 있습니다. 운영자는 목록 구간을 지정해 이동하는 기능이 필요한지 정하고, 필요한 연결을 구현할 수 있는 설계를 선택합니다.

구글과 네이버의 안내는 링크 처리 조건에 관한 근거이며, 화면 방식의 우열을 일괄적으로 정하는 자료는 아닙니다. 운영자는 번호 방식의 장점을 설명할 때 주소 연결을 명시할 수 있다는 범위까지만 기술적 근거로 사용해야 합니다. 방문자가 이동하기 편한지는 별도의 사용성 판단으로 다룹니다.

또한 링크 주소를 마련했다는 사실과 연결된 페이지의 내용을 읽었다는 결과는 같지 않습니다. 네이버는 콘텐츠 구성에 필요한 리소스에 접근하지 못하면 페이지가 불완전하게 해석될 수 있다고 설명합니다. 번호 링크 조건을 충족했더라도 목적지의 콘텐츠 해석까지 완료됐다고 기록해서는 안 됩니다.

반복되는 번호 영역의 변경 관리

같은 목록에 번호 영역이 여러 곳 있으면 변경 요청의 적용 범위를 명확히 기재해야 합니다. 한 영역만 수정한 상태에서 목록 전체의 작업이 끝났다고 처리하면 다른 번호 영역에는 이전 구현이 남을 수 있습니다. 운영자는 번호 영역의 위치와 사용 화면을 함께 정리해 개발 담당자에게 전달합니다.

공통 구성요소를 사용한다는 설명만으로 모든 화면에 변경이 반영됐다고 판단하지 않습니다. 개발 담당자에게 공통 구성요소를 사용하는 화면과 개별 구현된 화면을 따로 설명하도록 요청합니다. 변경 기록에는 수정된 구성요소뿐 아니라 실제 반영 대상도 포함하고, 적용 대상에서 제외한 화면은 제외한 이유를 남깁니다.

이어서 읽을 주제

병원 홈페이지 리뉴얼은 목록 이동 기능을 개편할 때 화면 설계와 개발 요청에 필요한 자료를 함께 정리하려는 경우 이어 읽을 주제입니다. 병원 광고 연결페이지는 검색 목록에서 이동하는 페이지와 광고를 통해 도착하는 페이지의 목적을 각각 정하려는 경우 이어 읽을 주제입니다.