모바일 햄버거 메뉴 속 링크의 검색 인식 여부

메뉴 배치와 링크 생성 조건

화면에서 접힌 메뉴는 시각적 상태입니다. 링크가 문서 안에 이미 존재하지만 패널이 가려진 경우와 패널을 여는 동작이 있어야 링크 데이터를 가져오는 경우는 다른 구현입니다. 메뉴가 닫힌 화면의 사진만으로 두 상태를 구별할 수는 없습니다. 클릭 전 문서의 DOM과 클릭 후 DOM을 대조하면 항목이 원래 있었는지 새로 추가됐는지를 조사할 자료가 생깁니다.

Google은 일반적으로 href 속성이 있는 a 요소의 링크를 크롤링할 수 있다고 안내합니다. 메뉴 항목에 이름이 표시되고 누르면 이동하더라도 다른 요소의 스크립트 이벤트만 사용하는 방식은 이 조건과 다릅니다. 실제 링크를 읽을 때는 클릭 가능 여부와 함께 요소 종류 및 href 값을 조사합니다. 디자인상 같은 모양의 항목도 문서 안에서 제공하는 정보는 다를 수 있습니다.

햄버거 아이콘은 패널을 여는 제어이고 패널 안의 문서 링크는 목적지로 이어지는 연결입니다. 아이콘이 눌린다는 결과를 개별 항목의 URL이 제공된다는 증거로 사용하지 않습니다. 이동할 주소를 가진 항목과 현재 화면의 표시 상태만 바꾸는 제어를 분리하면 무엇을 검색 링크로 조사할지 명확해집니다. 모든 버튼이 검색 링크가 되어야 한다는 규칙을 만드는 뜻은 아닙니다.

모바일 중심 색인 문서는 사용자 상호작용에 의존한 주 콘텐츠 지연 로드를 피하라고 안내하며, Google은 로드에 스와이프·클릭·입력이 필요한 콘텐츠를 로드하지 않는다고 설명합니다. 이 조건을 메뉴 시험에 적용하면 사용자에게 열린 화면만 제시하는 것으로는 부족합니다. 일반 방문자의 조작 뒤에만 제공되는 자료가 있다면 그 로딩 조건이 검색 렌더링에서 어떻게 다뤄지는지를 별도로 조사해야 합니다.

HTML과 검색 렌더링의 대조

메뉴 항목을 받아 오는 연결 방식도 조사 조건입니다. 문제 해결 원문은 Googlebot이 HTTP 요청으로 콘텐츠를 가져오며 WebSockets나 WebRTC 같은 다른 연결 유형을 지원하지 않는다고 설명합니다. 해당 연결로만 항목을 제공하는 구조라면 HTTP 대체 제공과 오류 처리를 검토할 수 있습니다. 실제 메뉴가 어느 연결 방식을 쓰는지 조사하기 전에 특정 통신 기술이 원인이라고 추측하지 않습니다.

href는 크롤러가 요청할 수 있는 실제 웹 주소여야 한다고 링크 문서가 설명합니다. 상대 주소도 사용 가능한 형식에 포함됩니다. 링크의 문구를 누른 뒤 이동한 화면만 기록하는 대신 항목에 들어 있는 값을 그대로 읽으면, 페이지 주소와 자바스크립트 실행 표현을 구별할 수 있습니다. 상대 주소는 원래 문서와의 관계를 잃지 않도록 출발 페이지 주소와 함께 대조하는 편이 좋습니다.

자바스크립트로 앵커 텍스트를 삽입하는 경우 Google은 URL 검사 도구에서 그 텍스트가 렌더링된 HTML에 있는지 조사하라고 안내합니다. 메뉴 항목의 목적지만 읽고 문구가 빠졌는지를 놓치지 않습니다. 이름이 없는 링크와 목적지를 설명하는 이름이 있는 링크는 독자에게 제공하는 맥락이 다릅니다. 검사의 직접 대상은 해당 항목의 출력이며 사이트 전체 메뉴가 모두 같은 상태라는 추정은 아닙니다.

Google의 자바스크립트 문제 해결 문서는 URL 검사나 리치 결과 테스트에서 이런 자료를 읽을 수 있다고 설명합니다. 콘솔에 오류가 하나 있다는 이유만으로 모든 메뉴 링크가 검색에 읽히지 않는다고 판정하지 않습니다. 오류가 일어난 코드와 사라진 항목의 관계가 필요한 판단입니다. 반대로 화면이 열렸다는 한 가지 결과로 모든 리소스가 정상이라고 단정하는 것도 자료가 부족합니다.

모바일 문서는 Google이 리소스를 크롤링할 수 있도록 하라고 안내합니다. 모바일과 데스크톱에서 리소스 URL이 다른 경우도 있으며 필요한 URL이 disallow 규칙으로 차단됐는지를 조사해야 합니다. 메뉴 생성에 사용되는 파일을 찾았다면 페이지 주소만 시험하는 데서 끝내지 않고 그 파일이 요청 가능한지도 연결해 읽을 수 있습니다. 차단 자료가 메뉴와 무관한 자원인지 역시 구별할 항목입니다.

문구·리소스·기능의 고유 조건

메뉴 이름은 실제 이동할 문서에 대한 기대를 형성합니다. 링크 권장사항은 앵커 텍스트가 구체적이고 간결하며 출발 페이지와 도착 페이지에 관련돼야 한다고 설명합니다. 목적지 주소가 제공되는 항목이라도 문구가 다른 안내를 기대하게 만든다면 이름과 목적지의 대응을 다시 읽어야 합니다. 검색 인식을 조사하는 단계에서 클릭 구조와 의미 전달의 문제를 같은 결함으로 섞지 않습니다.

텍스트가 없는 링크에는 title 속성을 앵커 텍스트의 대안으로 사용할 수 있다고 공식 문서가 안내합니다. 이 조건은 모든 메뉴 텍스트를 title로 대체하라는 권장이 아닙니다. 항목 이름이 어느 방식으로 제공되는지를 조사할 때 실제 텍스트와 속성의 정보를 구별할 수 있다는 의미입니다. 화면에 보이는 이름이 있는 상태에서 속성만 읽고 이름이 없다고 기록하지 않습니다.

이미지가 링크인 경우에는 Google이 img 요소의 alt 속성을 앵커 텍스트로 사용한다고 링크 문서가 설명합니다. 메뉴 안에 이미지로 된 이동 항목이 있다면 파일 이름만이 아니라 대체 텍스트와 실제 도착 주소를 대조할 수 있습니다. 패널을 여는 아이콘 자체와 다른 문서로 연결되는 이미지를 구별한 상태에서 적용해야 합니다. 그림이라는 이유로 모든 항목을 동일한 연결 방식으로 분류하지 않습니다.

브라우저에서 정상 동작하는 기능이 검색 렌더링에서도 같은 조건으로 제공된다고 가정하지 않습니다. 문제 해결 문서는 기능 감지를 사용해 지원되지 않는 API를 조사하도록 안내합니다. 메뉴가 특정 기능에 의존한다면 기능 사용 가능 여부와 대체 처리가 항목 출력에 어떤 영향을 주는지를 읽을 수 있습니다. 모바일 기기의 이름만 보고 지원 범위를 추측하는 방식보다 사용된 기능의 조건이 직접적인 자료입니다.

Google의 렌더링 서비스는 필수 콘텐츠에 기여하지 않는 요청을 가져오지 않을 수 있다고 원문이 설명합니다. 분석이나 오류 보고 요청은 메뉴 콘텐츠를 만드는 요청과 역할이 다릅니다. 클라이언트 분석이 Googlebot과 렌더링 서비스 활동을 완전하고 정확하게 나타내지 못할 수 있으므로 분석 도구에 흔적이 없다는 사실만으로 메뉴가 처리되지 않았다고 단정하지 않습니다. 요청의 용도를 구별해야 합니다.

이전 방문에서 저장된 상태에 의존하는 항목도 조사 대상입니다. 공식 문서는 렌더링 서비스가 페이지 로드 사이에 상태를 유지하지 않으며 로컬·세션 스토리지와 HTTP 쿠키가 로드 도중 삭제된다고 설명합니다. 메뉴 항목 제공이 이전 방문의 선택값에 의존한다면 일반 브라우저의 저장된 상태와 검색 시험의 상태가 같은지부터 구별할 수 있습니다.

웹 구성요소로 만든 메뉴는 요소 내부의 콘텐츠가 렌더링 결과에 포함되는지를 읽습니다. 원문은 렌더링 서비스가 light DOM과 shadow DOM을 평면화한다고 설명하며, light DOM 콘텐츠를 위한 slot 메커니즘을 쓰지 않은 구성요소에는 해당 문서 조사나 다른 구성요소 사용을 안내합니다. 사용자 정의 요소 이름이 있다는 이유만으로 항목의 텍스트가 사라졌다고 단정하지 않습니다.

이어서 읽을 주제

관련 안내를 이어 읽으려면: 블로그 상위노출 · 구조화 데이터.