병원 사이트 빵부스러기 경로 두기

현재 문서에서 상위 분류로 이어지는 경로 설계

병원 문서에 적용하는 설계 방법으로 실제 진료과 안내와 질환 안내를 읽고 그 관계를 대조하는 절차를 제안합니다. 질환 문서가 어떤 분류에서 제공되는지와 그 분류의 안내 문서가 실제 존재하는지 조사합니다. 원래 사이트에 없는 진료과나 질환 관계를 만들어 경로의 빈 단계를 채우지 않습니다. 임상적 분류를 판단하는 단계가 아니라 공개된 문서의 탐색 관계를 표시하는 단계입니다.

Google은 주소 구조를 그대로 복사하기보다 페이지의 일반적인 사용자 경로를 표현하라고 권고합니다. 주소의 폴더 이름과 방문자가 이해하는 분류 이름이 항상 같지는 않을 수 있습니다. 경로를 설계할 때 주소 문자열을 나누기만 하는 방법보다 실제 메뉴에서 어떤 설명을 거쳐 해당 문서에 이르는지 읽을 수 있습니다. 화면 메뉴 전체를 탐색경로로 바꾸는 방식과도 다릅니다.

상위 항목의 링크는 문구에 해당하는 실제 문서로 이동하는지 시험하는 방법을 적용할 수 있습니다. 이름은 넓은 안내를 뜻하지만 목적지는 현재 문서로 다시 돌아오는 상태라면 위로 이동하는 관계가 전달되는지 조사해야 합니다. 링크가 눌리는지와 올바른 상위 설명으로 연결되는지는 서로 다른 질문입니다. 화면에 표시된 각 이름을 도착 문서의 내용과 대조하는 절차입니다.

한 페이지에 이르는 실제 경로가 여러 개라면 여러 탐색경로 트레일을 지정할 수 있다는 설명도 있습니다. 원문의 복수 경로 예는 서로 다른 분류에서 같은 문서로 이어지는 구조를 보여 줍니다. 병원 사이트에서는 존재하는 복수의 탐색 관계가 있는지 읽는 방법으로 적용할 수 있습니다. 검색어를 늘리기 위해 실재하지 않는 경로를 여러 개 생성하라는 권고가 아닙니다.

최상위의 도메인이나 호스트 이름, 페이지 자체를 반드시 ListItem으로 넣을 필요는 없다고 Google은 안내합니다. 모든 경로에 같은 시작 문구와 현재 문서를 강제로 붙이는 규칙과 구별할 수 있습니다. 다만 단계가 생략돼도 사용자에게 제공할 실제 탐색 관계가 무엇인지 판단해야 합니다. 어떤 단계를 넣고 빼는지의 선택을 사이트의 공개 문서 구조와 대조하는 방법입니다.

보이는 안내와 구조화된 값의 대응 읽기

Google의 원문은 시각적인 디자인에 포함된 HTML 탐색경로 블록과 구조화된 데이터의 예를 따로 제공합니다. 구조화된 데이터는 페이지 정보를 제공하고 콘텐츠를 분류하는 표준화된 형식이라는 설명입니다. 따라서 화면의 목록을 작성한 상태와 BreadcrumbList의 값을 제공한 상태는 같은 작업으로 합치지 않습니다. 화면 안내를 읽는 사용자와 기계에 전달되는 자료를 각각 대조할 수 있습니다.

BreadcrumbList는 목록의 모든 요소를 담는 컨테이너이며 itemListElement는 순서대로 나열한 탐색경로 배열입니다. 각 경로는 ListItem으로 지정합니다. Google의 유형 정의는 두 개 이상의 ListItem이 포함된 BreadcrumbList를 요구합니다. 임의의 링크 목록이 존재한다는 사실과 이 형식의 항목 수·순서·속성이 갖춰진 상태는 따로 읽어야 합니다.

position은 트레일 안의 위치이며 1이 시작을 뜻합니다. name은 사용자에게 표시되는 탐색경로의 제목이고 item은 그 단계의 웹페이지 주소입니다. 적용 방법으로 화면에서 읽는 차례와 마크업의 숫자 순서를 나란히 비교하는 절차를 제안합니다. 목록에 저장된 순서와 표시 이름의 의미가 실제 상위·하위 관계에 맞는지를 읽을 수 있습니다.

item을 지정하는 방법에는 URL 자체를 제공하는 방식과 마크업 형식에 맞는 ID로 제공하는 방식이 있습니다. JSON-LD에서는 @id, 마이크로데이터에서는 href 또는 itemid, RDFa에서는 about·href·resource를 사용할 수 있다고 원문은 설명합니다. 서로 다른 형식의 표기 방식을 혼합하는 대신 실제 사용 중인 형식에서 주소가 어디에 들어가는지 읽는 질문을 적용할 수 있습니다.

마지막 항목에는 item이 필수가 아니며 생략하면 Google은 포함된 페이지의 주소를 사용한다고 설명합니다. 이것은 모든 상위 단계의 주소를 빼도 된다는 뜻이 아닙니다. 또한 item을 URL 대신 name을 가진 Thing으로 지정하면 별도의 name은 필수가 아니라는 예외가 있습니다. 개별 속성의 조건을 같은 생략 규칙으로 확대하지 않고 현재 입력 형식에 맞춰 읽어야 합니다.

Google 검색의 이 기능은 데스크톱에서 제공되며 검색이 제공되는 모든 지역에서 해당 언어로 사용할 수 있다고 안내합니다. 병원 화면 자체의 탐색 안내를 설계하는 범위와 검색 기능의 제공 환경은 다릅니다. 휴대전화에서 화면의 경로가 보인다는 사실을 모바일 검색결과에도 동일한 탐색경로 기능이 표시된다는 근거로 쓰지 않습니다.

배포 전 기술 시험과 배포 후 관측 구별

Google은 리치 결과 테스트로 심각한 오류를 수정하고 중요하지 않은 문제도 고치면 품질을 개선하는 데 도움이 된다고 설명합니다. 후자의 수정이 리치 결과 자격을 얻기 위한 필수 사항은 아니라는 안내도 있습니다. 화면의 이동 링크 시험과 형식 검사 결과는 다른 종류의 자료이므로, 링크가 정확한 문서로 가더라도 마크업 오류를 별도로 조사할 수 있습니다.

몇 개의 페이지에 배포한 뒤 URL 검사 도구로 Google에서 인식하는 페이지를 시험하는 절차를 제시합니다. 로봇 규칙, noindex, 로그인 요구 등에 의해 페이지가 차단되지 않아 접근할 수 있어야 한다는 조건입니다. 게시 화면에서 데이터가 보이는 상태와 검색 시스템이 그 페이지에 접근하는 상태를 구별해 시험할 수 있습니다. 이 절차를 실행하지 않은 사이트의 검사 결과를 추정하지 않습니다.

처음 배포한 뒤 Google이 페이지의 색인을 생성하면 관련 리치 결과 상태 보고서를 이용해 문제를 조사할 수 있습니다. 원문은 유효한 항목이 늘고 잘못된 항목은 늘지 않는 상태를 바람직하게 설명합니다. 잘못된 항목 수정, 실제 주소 검사, 상태 보고서의 유효성 검사 요청이라는 절차를 제시합니다. 구조화된 자료의 문제를 공개 링크의 고장과 같은 숫자로 합산하지 않습니다.

새 템플릿이나 코드로 크게 변경한 뒤 잘못된 항목이 증가하면 새 템플릿의 작동이나 기존 템플릿과의 상호작용을 조사할 수 있습니다. 잘못된 항목이 늘지 않았는데 유효한 항목만 감소한다면 구조화된 데이터를 더 이상 삽입하지 않는 것일 수 있다고 안내합니다. 두 관측의 조합이 서로 다른 조사 질문을 제공한다는 설명입니다. 실제 원인은 URL 검사 도구로 조사하도록 권고합니다.

실적 보고서에서는 리치 결과로 표시되는 빈도, 클릭 빈도, 평균 게재순위를 읽을 수 있다고 안내합니다. 이것은 경로를 입력한 목록의 개수와 같은 자료가 아닙니다. 구조와 주소의 기술적 수정, 실제 검색에서 나타난 결과를 구별해 해석하는 질문에 사용할 수 있습니다. 보고서의 값이 없는 상태에서 예상 노출이나 클릭 성과를 숫자로 만들어 붙이지 않습니다.

Google은 가이드라인에 어긋난 문제 중 일부가 구문 문제가 아닐 수 있고, 그런 경우 리치 결과 테스트가 식별하지 못할 수 있다고 설명합니다. 검사 통과와 실제 표시 보장을 같은 결론으로 쓰지 않는 이유입니다. 페이지를 게시한 뒤 찾고 크롤링하기까지 며칠이 걸릴 수 있다는 안내도 있으므로 즉시 표시 여부만으로 모든 구현의 성공이나 실패를 판단하지 않습니다.

이어서 읽을 주제

블로그 문서의 검색 진입 관계를 읽을 때: 블로그 상위노출.

문서의 기계 해석 형식을 이어서 읽을 때: 구조화 데이터.