병원 사이트 공지·소식 게시판의 위치

최근 소식을 보여 주는 자리와 전체 보관 목록

첫 화면은 지금 읽을 필요가 있는 글의 진입점으로, 게시판 목록은 이전 공지의 제목을 찾고 본문으로 이동하는 자리로 검토합니다. 실제 공지에 없는 기간이나 중요도를 임의로 붙이지 않고 현재 문서에서 알리는 내용을 읽습니다. 제목과 게시 날짜는 어떤 글을 선택할지 판단할 단서가 될 수 있습니다. 병원이 제공하지 않은 작성일이나 갱신일을 만들어 카드에 채우지 않습니다.

Google의 페이지로 나누기 안내는 목록의 일부를 먼저 표시하면 초기 로드와 네트워크·백엔드 부담을 줄일 수 있다고 설명합니다. 게시된 블로그 글이나 뉴스레터 제목도 점진적 로드가 쓰이는 대상으로 소개합니다. 이 원칙을 공지 목록에 적용할 때에는 한 화면에 모든 글을 펼칠지보다 전체 문서에 도달할 길을 함께 검토할 수 있습니다. 실제 속도 개선 폭은 사이트를 측정하지 않고 제시하지 않습니다.

최근 소식과 전체 보관 화면이 서로 다른 페이지라면 첫 화면에서 목록의 존재를 이해할 수 있는 안내가 필요합니다. 전체 목록의 항목은 현재 사이트에 남아 있는 공지의 범위와 맞춰 검토합니다. 리뉴얼하면서 오래된 글의 표시 위치가 달라질 수 있으므로 새 화면의 첫 묶음만으로 이관 범위를 추정하지 않습니다. 보존 여부 자체는 병원의 실제 자료와 운영 목적에 따라 결정할 사항입니다.

뒤쪽 공지가 끊기지 않는 목록 이동

목록을 나누는 방법에는 페이지 번호·다음과 이전 링크, 더 로드하기 버튼, 무한 스크롤이 있습니다. Google은 페이지 나누기가 목록의 크기와 현재 위치 정보를 주지만 이동 제어가 복잡하고 새로 로드해야 한다고 설명합니다. 더 로드하기와 무한 스크롤은 연속 목록을 제공하되 항목이 아주 많을 때 처리 한계가 있습니다. 특히 무한 스크롤은 전체 크기가 명확하지 않아 피로감을 줄 수 있다는 비교를 제시합니다.

병원 공지의 목록 방식은 이 장단점과 실제 글의 양을 함께 읽어 선택할 수 있습니다. Google 문서가 제시한 세 방식을 병원 사이트의 순위 등급처럼 배열하지 않습니다. 목록 전체를 한 번에 표시하는 것이 방문자에게 언제나 편하다고 가정하지도 않습니다. 어느 방식이든 오래된 글의 제목에 도달하고 선택한 본문을 읽을 수 있는지가 탐색의 목적입니다.

검색로봇이 이용하는 경로에는 별도 조건이 있습니다. Google 크롤러는 일반적으로 a 요소의 href에 있는 URL을 따라가며 버튼을 클릭하지 않습니다. 사용자 동작이 있어야 현재 내용을 바꾸는 JavaScript 함수도 일반적으로 실행하지 않습니다. 사람이 더 보기 버튼으로 오래된 글을 읽은 결과만으로 Googlebot도 같은 전체 목록을 발견했다고 보고할 수 없습니다.

페이지 나누기를 구현한다면 Google은 각 페이지를 다음 페이지로 연결하는 a href 링크를 포함하라고 안내합니다. 목록의 개별 페이지에서 첫 페이지로 돌아가는 연결도 권장합니다. 다음 글 묶음으로 나아가는 길과 컬렉션 시작으로 돌아오는 길의 역할이 다릅니다. 실제 href가 어떤 목록 주소를 가리키는지 읽어야 하며 버튼의 외형이나 페이지 번호의 글자만으로 연결 상태를 판정하지 않습니다.

각 목록 페이지에는 고유한 URL을 부여하고 페이지 번호에 따른 쿼리 매개변수를 사용할 수 있습니다. Google은 페이지로 나눈 첫 페이지를 나머지의 표준 페이지로 사용하지 말고 각 페이지에 고유한 표준 URL을 지정하라고 설명합니다. 뒤쪽 공지까지 서로 다른 목록으로 제공하는 구조와 모든 목록을 첫 페이지로 대표시키는 설정은 구별해야 합니다.

페이지 번호를 주소의 # 뒤 프래그먼트로만 바꾸는 방식은 Google의 권장사항과 맞지 않습니다. Google이 프래그먼트를 무시하므로 다른 부분이 같은 다음 주소를 이미 검색한 페이지로 간주해 따라가지 않을 수 있습니다. 화면의 숫자가 달라지고 이전 글이 나타났다는 사실과 크롤러가 별도 URL로 이동할 수 있다는 사실을 나누어 검토합니다.

새 게시판에서 본문과 링크가 제공되는 단계

리뉴얼한 게시판이 JavaScript로 제목 목록을 만드는 경우에는 최초 HTML과 렌더링 후 HTML의 차이가 중요합니다. Google의 JavaScript 안내는 크롤링·렌더링·색인 생성 단계를 설명하며 렌더링한 HTML에서 링크를 다시 추출한다고 밝힙니다. 목록을 구성하는 자료가 서버에서 처음부터 제공되는지, 스크립트를 실행해야 나타나는지에 따라 실제로 읽을 화면이 달라질 수 있습니다.

Google은 검색 크롤러 중 JavaScript를 실행하지 못하는 것도 있기 때문에 서버 측 렌더링이나 사전 렌더링이 사용자와 크롤러 모두에게 좋은 방법이라고 설명합니다. 이것을 병원 게시판이 특정 개발 도구를 반드시 써야 한다는 지시로 바꾸지 않습니다. 현재 구현에서 초기 응답이 무엇을 제공하고 추가로 어떤 자료를 불러오는지 구분하여 필요한 조정을 판단할 수 있습니다.

robots.txt로 차단한 페이지나 JavaScript 파일은 Google이 렌더링하지 않는다고 안내합니다. 공개 공지의 내용을 만드는 스크립트까지 차단했다면 화면을 만드는 데 필요한 리소스와 접근 정책의 관계를 검토해야 합니다. 차단된 자료가 무엇인지 모른 채 모든 제한을 해제하는 작업으로 확대하지 않습니다. 게시판에서 공개하려는 문서와 그 문서를 표시하는 파일이 판단 대상입니다.

개별 공지가 더 이상 존재하지 않는다면 응답 상태도 실제 내용과 맞아야 합니다. Google의 JavaScript 안내는 찾을 수 없는 페이지에 404, 로그인이 필요한 페이지에 401 같은 의미 있는 HTTP 상태 코드를 사용하라고 설명합니다. 공지 목록이 정상적으로 열렸다는 이유로 모든 항목의 본문까지 정상이라고 정하지 않습니다. 공개 목록과 그 안에서 선택하는 각 문서의 응답은 다른 대상입니다.

다음 목록으로 이동할 때의 성능에 관해서 Google은 미리 로드·사전 연결·미리 가져오기를 활용할 것을 권장합니다. 이는 다음 묶음을 요청하는 과정에 적용할 기술적 선택입니다. 앞쪽에 표시할 공지를 선정하는 편집 기준이나 보관 문서를 삭제할 근거와는 다릅니다. 현재 게시판이 무엇을 먼저 가져오는지 읽고 실제 자원 사용과 이동 결과를 측정해야 하며, 모든 문서를 미리 내려받도록 설정하라는 의미로 확대하지 않습니다.

Google은 렌더링 서비스의 캐시가 HTTP 캐시 헤더를 무시할 수 있어 내용이 바뀐 리소스에 콘텐츠 지문을 사용하는 방법을 설명합니다. 사이트 개편 후 예전 스크립트 때문에 목록이 다르게 구성되는 문제가 있다면 현재 배포 파일과 불러온 리소스를 구별할 수 있습니다. 방문자 화면이 옛 형태라는 관찰만으로 공지 데이터가 삭제됐다고 단정하지 않습니다.

이어서 읽을 주제

웹페이지에 어떤 구조화 정보를 제공할지 이어 읽습니다.

구조화 데이터

홈페이지의 정보와 이동 경로를 무엇부터 기획할지 이어 읽습니다.

병원 홈페이지 기획