사이트 구조와 내부 링크에서 흔한 실수

주소 제공과 내부 연결의 결함

자바스크립트가 생성했다는 사실만으로 링크를 잘못된 형식이라고 분류하지 않습니다. Google은 동적으로 삽입한 연결도 권장한 HTML 마크업을 사용하면 크롤링할 수 있다고 설명합니다. 처음 응답한 코드에 항목이 없다는 자료와 렌더링 후에도 항목이 없다는 자료는 다릅니다. 생성 방식의 이름보다 최종 요소가 제공하는 구조를 기준으로 오류를 정의할 수 있습니다.

중요한 페이지를 다른 문서에서 전혀 연결하지 않는 문제는 링크 요소의 형식과 다른 구조적 결함입니다. Google은 중요한 페이지마다 사이트 안 다른 페이지에서 하나 이상의 링크가 있어야 한다고 안내합니다. 특정 문서가 존재한다는 자료와 다른 문서에서 발견할 경로가 있다는 자료를 구별합니다. 주소를 직접 입력하면 열리는 결과만으로 내부 연결이 마련됐다고 판단하지 않습니다.

어디에서 연결할지는 독자에게 도움이 되는 자료의 관계로 정할 수 있습니다. 공식 링크 문서는 특정 페이지를 이해하는 데 다른 리소스가 도움이 되는지를 생각하고 맥락에 따라 연결하라고 안내합니다. 모든 문서에서 모든 진료 안내를 연결하는 방식으로 이 권장을 확대하지 않습니다. 서로 무관한 문서 사이의 연결을 늘리는 것보다 현재 설명을 보완할 목적지가 무엇인지가 직접적인 판단입니다.

정해진 링크 개수가 없다는 조건도 중요합니다. Google은 특정 페이지에 들어가야 하는 링크 수에 고정된 숫자가 없다고 설명합니다. 항목이 적으면 오류이고 많으면 정상이라는 단순 기준은 이 원문에서 나오지 않습니다. 필요한 연결이 빠졌는지와 이미 있는 연결이 독자의 이해를 방해하는지를 구별해야 수량을 고치는 일과 설명 구조를 고치는 일이 혼동되지 않습니다.

목적지를 설명하는 문구의 결함

목적지 주소가 정상이어도 앵커 문구가 너무 일반적이면 어떤 정보를 기대할지 전달하지 못합니다. Google은 문구만 읽었을 때 구체적인 정보가 제공되고 그 자체로 이해되는지를 시험하는 방법을 제시합니다. 본문 전체를 알고 있는 작성자의 예상 대신 링크 부분에서 독자가 얻을 설명을 읽을 수 있습니다. 실제 목적지의 주제와 문구가 어긋나는 경우에는 코드보다 표현을 수정할 문제입니다.

설명 문장 전체를 길게 링크로 만드는 것도 다른 실수입니다. 링크 권장사항은 구체적이고 간결한 문구를 제시하고 지나치게 긴 연결의 예를 구별합니다. 목적지 식별에 필요한 말과 현재 문장에서 이어질 설명을 나누면 어느 부분이 눌리는지 명확해집니다. 이 기준은 모든 링크에 같은 글자 수를 적용하거나 문서의 제목을 항상 그대로 복사하라는 규칙이 아닙니다.

연결할 페이지의 키워드를 모두 앵커에 넣으려는 방식도 피합니다. 공식 문서는 문구를 자연스럽게 작성하고 관련 키워드를 전부 넣어서는 안 된다고 안내합니다. 다음 페이지를 이해하는 데 그 말이 필요한지가 판단 조건입니다. 진료 안내로 이어지는 문구에 관계없는 검색어를 늘리는 편집을 목적지 설명 개선으로 취급하지 않습니다. 특정 병원이 이런 표현을 사용했다는 사례를 만들지 않습니다.

여러 링크를 연달아 이어 놓으면 독자가 연결을 구분하기 어렵고 각 링크의 주변 텍스트가 사라진다고 Google이 설명합니다. 이때 고칠 것은 링크 숫자만이 아니라 링크 사이에 사라진 맥락입니다. 한 문장의 단어마다 목적지를 배정한 상태와 설명을 나누어 각 자료의 의미를 제시한 상태는 다른 편집입니다. 불필요한 연결을 줄이거나 필요한 문맥을 복원하는 쪽으로 오류를 정의할 수 있습니다.

주소가 없는 요소와 부정확한 문구에는 다른 변경 책임이 필요합니다. 요소와 목적지 값을 바꾸는 일은 구현 수정이고, 어떤 문서를 어떻게 소개할지 고치는 일은 내용 편집입니다. 이는 이 글의 오류 분류를 업무에 적용하는 제안입니다. 문구만 고친 결과를 링크 구조의 해결로 기록하거나 요소만 바꾼 결과를 설명의 적합성까지 해결한 것으로 확대하지 않습니다.

비용을 받은 연결이나 사용자가 삽입한 연결의 속성을 일반 내부 탐색과 섞는 것도 피합니다. Google은 대가를 받은 링크에는 sponsored 또는 nofollow를, 포럼이나 질문 게시판의 사용자 링크에는 ugc 또는 nofollow를 추가하는 조건을 안내합니다. 문서 사이의 내부 연결을 조사하면서 외부 연결의 성격까지 모두 같은 유형으로 분류하면 속성의 적용 이유가 사라집니다.

렌더링 오류와 수정의 대응

렌더링에서 링크가 빠지는 현상은 원본 문구가 부정확한 현상과 구별합니다. 자바스크립트 문제 해결 문서는 URL 검사나 리치 결과 테스트에서 렌더링된 DOM, 로드된 자원, 콘솔 출력과 예외를 읽을 수 있다고 안내합니다. 원본 코드가 의도한 요소와 실제 출력된 요소를 비교하면 어느 단계의 차이를 조사할지 정할 수 있습니다. 화면 디자인만으로 검색의 처리 상태를 확정하는 대신 출력 자료를 근거로 설명합니다.

오류 메시지가 있다는 사실은 영향 범위까지 말해 주지 않습니다. 공식 문서는 콘텐츠 렌더링에 영향을 줄 수 있는 문제를 찾기 위해 자바스크립트 오류를 수집하고 조사하도록 안내합니다. 예외가 발생한 코드와 누락된 연결의 관계가 있어야 해당 수정의 이유를 설명할 수 있습니다. 모든 UI 오류를 전체 페이지의 색인 실패로 이름 붙이는 방식은 필요한 연결 증거를 생략합니다.

오류 수집 방법에도 빈틈이 있습니다. 원문은 전역 onerror 핸들러로 기록하는 방법을 제시하면서 파싱 오류처럼 이 방식으로 기록할 수 없는 종류가 있다고 설명합니다. 기록이 없는 상태를 모든 오류가 없다는 결론으로 바꾸지 않습니다. 특정 자료에서 조사 가능한 오류의 범위를 먼저 이해해야 정상 기록과 자료의 한계를 구별할 수 있습니다.

콘텐츠를 제공하는 연결 방식이 지원되는지도 구현 오류의 조건입니다. 문제 해결 문서는 Googlebot이 HTTP 요청을 사용하고 WebSockets나 WebRTC 같은 연결은 지원하지 않는다고 안내합니다. 해당 방식에 의존하는 자료가 실제로 링크 출력을 만드는지 조사한 뒤 HTTP 대체와 오류 처리 여부를 검토할 수 있습니다. 사용한 기술의 이름만으로 모든 문서의 문제가 같다고 추정하지 않습니다.

사용자 권한이 있어야 제공되는 기능도 일반적인 검색 처리와 다를 수 있습니다. 공식 문서는 카메라 접근을 필수로 하는 기능을 예로 들며 Googlebot은 카메라를 제공할 수 없다고 설명합니다. 사용자가 권한을 허용하지 않아도 콘텐츠에 접근할 방법을 제공해야 한다는 조건이 제시됩니다. 연결 대상이 이런 기능에 의존한다면 문구의 설명력과 별도로 접근 조건을 조사할 수 있습니다.

코드를 고친 뒤에는 페이지를 다시 시험하라고 문제 해결 원문이 안내합니다. 변경된 파일이 있다는 사실보다 해당 오류에 대응하는 출력이 달라졌는지가 필요한 자료입니다. 처음에는 목적지가 빠졌다면 수정 후 목적지 제공을, 특정 요소가 누락됐다면 수정 후 그 요소의 출력을 시험하는 방식으로 연결할 수 있습니다. 이 글은 오류 유형의 구분이며 신규 게시나 삭제에 따른 정기 점검 시점은 별도 주제입니다.

다른 화면의 콘텐츠를 URL 프래그먼트만으로 불러오는 방식도 주소 제공의 오류 유형입니다. 문제 해결 원문은 단일 페이지 앱에서 다른 콘텐츠를 로드하는 데 프래그먼트를 쓰지 말고 URL 기준의 전환에 History API를 쓰는 편이 좋다고 안내합니다. 실제로 별도 콘텐츠를 요청하는 연결인지 같은 문서 안의 위치를 이동하는 연결인지를 구별한 뒤 이 조건을 적용합니다.

이어서 읽을 주제

관련 안내를 이어 읽으려면: 사이트맵과 정규 주소 · 병원 홈페이지 기획.