메뉴·URL·브레드크럼의 역할을 구분한다
브레드크럼은 현재 페이지가 사이트 계층에서 어디에 있는지 보여주는 이동 경로다. 상단 메뉴가 주요 영역으로 들어가는 입구라면 브레드크럼은 ‘홈 › 서비스 › 상세 서비스’처럼 현재 위치와 상위 단계를 연결한다. URL 폴더 구조와 비슷해 보일 수 있지만 반드시 주소를 그대로 잘라 만들 필요는 없다. Google도 일반 사용자가 해당 페이지에 도달하는 대표 경로를 제공하고 URL 구조를 단순히 복제하지 말 것을 권장한다. 먼저 메뉴, URL, 브레드크럼을 각각 적어 서로 다른 역할이 섞이지 않았는지 확인한다.
사용자가 이해하는 대표 경로를 정한다
경로는 운영자의 내부 분류가 아니라 고객이 이해할 말로 구성한다. 예를 들어 ‘상품관리 › B형’보다 ‘원두 › 디카페인 원두’가 페이지 관계를 더 분명하게 전달할 수 있다. 한 페이지에 여러 접근 경로가 있다면 가장 흔하고 의미가 선명한 경로를 우선 정한다. 단계마다 상위와 하위의 포함 관계가 성립하는지, 같은 수준에서 이름의 범위가 비슷한지 점검한다. 지나치게 긴 경로는 중간 분류를 합칠 수 있는 신호다. 다만 카테고리 이름을 줄일 때 실제 페이지 제목과 완전히 다른 표현으로 바꾸지는 않는다.
각 단계가 실제 페이지로 연결되는지 확인한다
현재 페이지를 제외한 각 단계는 사용자가 클릭해 이동할 수 있는 정상 URL로 연결한다. 링크가 404를 반환하거나 로그인 화면으로 보내지는지, 모바일에서도 눌리는지 직접 확인한다. 상위 카테고리 페이지가 없다면 이름만 임시로 넣기보다 먼저 고객에게 유용한 분류 페이지를 만들지 판단한다. 화면에 보이는 경로의 이름과 연결되는 페이지의 주제가 어긋나면 내부 링크 구조도 함께 정리해야 한다. 같은 유형의 상세 페이지는 동일한 순서와 명명 규칙을 적용해 페이지마다 경로가 달라지는 문제를 줄인다.
BreadcrumbList 구조화 데이터를 맞춘다
구조화 데이터에는 BreadcrumbList와 순서대로 나열한 itemListElement를 사용한다. Google 지침상 브레드크럼 표시 대상이 되려면 최소 두 개의 ListItem이 필요하며, 각 단계에는 position과 name, 연결 URL에 해당하는 item을 구성한다. 마지막 단계는 item을 생략할 수 있고 이 경우 현재 페이지 URL이 사용된다. 화면에는 ‘서비스 › 상세 서비스’라고 보이는데 구조화 데이터에는 다른 분류를 넣는 식의 불일치를 피한다. JSON-LD를 사용한다면 페이지별 값이 템플릿에서 올바르게 바뀌는지도 여러 URL로 확인한다.
테스트 후 소수 페이지부터 배포한다
구현을 마치면 리치 결과 테스트에서 필수 속성 오류를 먼저 수정하고, 경고도 실제 데이터 누락인지 살펴본다. 그다음 대표 상품·서비스 페이지 몇 개에 먼저 적용해 화면 링크와 구조화 데이터가 같은 순서인지 확인한다. URL 검사 도구에서는 Google이 페이지에 접근할 수 있는지 점검한다. robots.txt, noindex, 로그인 요구로 차단된 페이지는 마크업이 있어도 수집될 수 없다. 테스트가 끝나면 배포하고 필요할 때 재수집을 요청하며, 새 URL이 사이트맵에 포함되는지도 함께 확인한다.
배포 후 6항목을 정기적으로 점검한다
최종 점검표는 ① 실제 사용자 경로를 반영했는가 ② 단계 이름이 화면과 구조화 데이터에서 같은가 ③ 상위 링크가 정상 응답하는가 ④ ListItem의 name·position·item이 순서에 맞는가 ⑤ 리치 결과 테스트의 필수 오류가 없는가 ⑥ 페이지가 크롤링 가능하고 사이트맵에 포함됐는가이다. 카테고리 이름이나 URL을 바꿀 때는 브레드크럼 템플릿도 같은 작업에 포함한다. Search Console에서 유효 항목 감소나 오류 증가가 보이면 대표 URL 하나만 보지 말고 같은 템플릿을 쓰는 페이지 묶음을 함께 점검한다.