여정, 페이지 역할, 우선순위에서 시작하세요
오류로 인해 실제 비용이 발생할 수 있는 페이지를 선택하세요: 서비스·제품, 카테고리, 문의 또는 전환(컨버전), 지원, 계정 작업, 복구 지침 등입니다. 각 항목에 대해서 예상 진입 페이지, 방문자의 질문, 도움이 되는 다음 페이지, 수행할 행동, 그리고 부모나 허브로 돌아가는 경로를 기록하세요. 허브 페이지는 주제를 조직하고, 상세 페이지는 더 좁은 질문에 답하며, 내비게이션 및 브레드크럼은 방향을 제공합니다. 사람을 인위적 실로(artificial silo)로 막아 다른 진정한 유용한 섹션으로 가는 것을 방지하지 마세요. 딥 페이지에 대한 직접 랜딩과 홈페이지에서 시작하는 여정 둘 다 테스트하세요.
편의 링크보다 수익, 계정, 지원, 안전, 법률, 복구 경로의 경로를 먼저 고치세요.
각 중요한 페이지에 적절한 인바운드 경로와 관련 또는 상위 콘텐츠로의 명확한 경로를 제공하세요.
목적지를 설명하는 앵커를 쓰세요
앵커 텍스트는 보이는 클릭 가능한 문구입니다. Google은 설명적이고 적당히 간결하며 현재 페이지와 목적지 페이지 모두에 관련된 텍스트를 권장합니다. W3C는 링크 목적이 텍스트 단독으로 또는 WCAG 2.4.4에 따라 프로그램적으로 결정 가능한 문맥에서 판단 가능해야 한다고 말합니다. 단순한 “여기를 클릭”이나 반복된 “자세히 알아보기” 같은 레이블을, 목적지를 정확히 설명하는 “연간 요금제와 월간 요금제 비교” 같은 문구로 바꾸세요. 동일한 목적에는 동일한 문구를 유지하고, 다른 목적지에는 다른 문구를 사용하며, 앵커를 강제된 키워드 목록으로 만들지 마세요. 이미지 전용 링크에는 설명적인 대체 텍스트(alt)를 제공하세요.
링크를 해당 문장과 함께 또는 단독으로 읽어 보세요. 독자가 목적지를 예측할 수 있어야 합니다.
목적지의 제목, 헤딩, 시작 내용이 앵커가 약속한 내용을 충족하는지 확인하세요.
모든 중요한 경로를 크롤러가 접근하고 사용 가능하게 만드세요
클릭 가능해 보이는 제어 요소가 반드시 신뢰할 수 있는 내비게이션 링크인 것은 아닙니다. 중요한 경로에는 실제 URL로 해석되는 href를 가진 HTML a 요소를 사용하세요. Google은 렌더된 마크업이 해당 형태일 경우 동적으로 삽입된 링크도 크롤러가 접근 가능할 수 있다고 말하지만, 이벤트 전용 제어에서 목적지를 신뢰성 있게 추출할 수는 없다고 합니다. JavaScript, 동의(consent), CDN, 개인화 계층이 실행된 후 렌더된 페이지를 검사하세요. 별도로 응답 상태, 리디렉션, 표준화(정규화), noindex 지시, 인증, robots 제어도 확인하세요; 한 번의 성공적 클릭이 모든 검색 조건을 증명하지는 않습니다. MDN은 또한 href가 있는 앵커가 하이퍼링크를 생성하고 키보드로 활동 가능하다고 언급합니다.
페이지 이동에는 링크를 사용하고, 인플레이스 동작에는 버튼을 사용하세요; 디자인 목적만으로 버튼을 선택하지 마세요.
공유 내비게이션이나 라우팅 변경 후에는 대표 템플릿과 필수 경로를 테스트하세요.
고아 페이지를 방지하고 변경된 경로를 정리하세요
고아 페이지는 내부에서 그 페이지를 가리키는 링크가 없는 페이지입니다. Google의 지침은 관리하고자 하는 모든 페이지는 적어도 한 개의 다른 페이지에서 링크가 있어야 한다고 말합니다. 이것은 많은 링크를 요구하는 기준이 아니라 기초선입니다: 비공개, 중복, 만료되었거나 유틸리티 URL은 의도적으로 링크되지 않을 수 있습니다. 예외 레지스터를 소유자와 검토 날짜와 함께 보관하세요. CMS 인벤토리, 사이트맵, 크롤 결과, 랜딩 페이지 데이터를 비교하여 인바운드 링크가 없는 페이지, 깨진 소스 페이지, 풋터나 사이트맵에만 나타나는 URL을 찾으세요. 퍼블리시 시에는 허브, 상위, 기존 콘텐츠에서 관련 링크를 추가하고, 사용 중단 시에는 소스를 업데이트하고 리디렉트가 실질적으로 적절한 대체인지 검증하세요.
인바운드 및 복귀 경로가 검토될 때까지 중요한 색인 가능 페이지를 공개하지 마세요.
리디렉션뿐 아니라 문맥 내 참조도 업데이트하여 방문자가 오래된 선택지에 마주치지 않게 하세요.
링크 수 목표가 아닌 증거 기반으로 감사하세요
Google은 페이지당 이상적인 링크 수라는 마법 같은 숫자는 없다고 말합니다. 작업을 영향도에 따라 순위화하세요: 결제, 비밀번호 재설정, 또는 핵심 지원 실패는 저가치 관련 기사보다 우선순위가 높습니다. 내부 HTML 링크를 크롤링하고 소스, 대상, 앵커 또는 접근 가능한 이름, 위치, 최종 상태, 리디렉션 대상, 우선순위, 소유자, 검증을 기록하세요. Search Console(검색 콘솔)의 링크 보고서는 방향성 발견 신호로 사용하세요; Google은 이 보고서가 샘플링되고, 정규화된 URL을 그룹화하며, 중복을 결합하고, 테이블을 제한한다고 명시합니다. 자체 크롤과 CMS 목록과 비교하세요. 데스크탑과 모바일에서 주요 플로우를 실제로 수행해보고, 템플릿 변경 전후에 키보드 사용까지 포함해 점검하세요.
중요한 수리 후에는 라이브 소스와 의도된 최종 목적지를 재검증하세요.
템플릿 수준 결함은 개별 페이지를 반복적으로 편집하기보다 엔지니어링 백로그에 등록하세요.
경로 무결성을 릴리스 준비의 일부로 만드세요
내비게이션 또는 템플릿 배포는 한 번에 많은 경로를 변경할 수 있습니다. 서버 자체가 정상이어도 중요한 링크는 릴리스 리스크로 취급하세요: 방문자가 중요한 경로로 목적지에 도달할 수 없다면 해당 페이지가 사용 가능하더라도 아무 소용이 없습니다. Status Is UP은 이를 다운타임 모니터링이 아니라 적극적 최적화와 복구로 적용합니다: 우선순위 공개 여정을 사전 점검하고 예상되는 목적지와 소유자를 기록하며, 회피 가능한 마찰이 발생하기 전에 경로 실패를 수정하세요. 게시 속도에 맞춘 검토 주기를 설정하고, 마이그레이션, 내비게이션 재설계, 라우팅 변경, 콘텐츠 폐기 시에는 집중 감사 절차를 추가하세요.
수익, 계정, 지원, 복구, 안전, 법률, 그리고 높은 의도의 카테고리 경로를 사전 점검하세요.
소스, 예상 대상, 최종 결과, 검토자, 복구 책임자를 포함한 날짜가 기재된 테스트 기록을 보관하세요.