확정 오류와 확인 후보의 차이
링크 점검 도구로 깨진 링크를 찾을 때는 결과를 확정 오류 목록이 아닌 확인 후보로 사용합니다. 실제 주소가 아닌 링크 값, 잘못 풀린 상대 주소, 리디렉션을 구분하고 실제 연결 실패 여부를 확인합니다. 도구가 오류로 표시했다는 이유만으로 해당 페이지를 삭제하거나 링크를 일괄 변경하지 않습니다.
판단할 대상은 보고서에 표시된 주소만이 아닙니다. 링크를 포함한 원래 페이지, 그 페이지에 입력된 링크 값, 도구가 요청한 주소를 함께 읽어야 합니다. 입력값부터 잘못된 항목과 요청한 서버에서 문제가 발생한 항목은 수정할 담당자와 작업이 다릅니다. 마케팅 담당자는 후보를 모으고, 개발 담당자는 링크 구현과 서버 응답을 조사하는 방식으로 업무를 나눌 수 있습니다.
| 점검 결과의 단서 | 확인할 항목 | 단정하지 말아야 할 것 |
|---|---|---|
| 주소처럼 읽히지 않는 링크 값 | 페이지의 href 속성과 클릭 동작 | 연결 대상 페이지가 삭제되었다는 판단 |
| 경로가 반복되거나 어긋난 주소 | 출발 페이지와 상대 주소의 해석 | 보고서의 주소가 의도한 목적지라는 판단 |
| 리디렉션 응답 | 이동 대상과 최종 연결 결과 | 이동 응답 자체가 연결 실패라는 판단 |
| 요청 오류나 서버 오류 | 오류 종류와 실제 접근 조건 | 모든 오류가 영구적인 페이지 삭제라는 판단 |
이 표는 후보를 추리는 기준이며 수정 완료를 판정하는 기록은 아닙니다. 결과를 읽는 담당자는 오류 표시와 함께 그 판단을 뒷받침한 단서를 남깁니다. 주소나 응답 정보가 빠진 항목은 추측으로 채우지 않고 조사할 자료를 지정합니다.
실제 주소가 아닌 링크 값
네이버 서치어드바이저는 검색로봇이 링크 요소의 href 속성에서 다른 페이지 주소를 발견한다고 설명합니다. 이 속성에 자바스크립트 호출을 입력하면 정상적인 링크로 구성되지 않아 새로운 페이지 주소를 발견하지 못할 수 있다고 안내합니다. 운영자는 도구가 읽은 값이 이동할 주소인지, 클릭 동작을 실행하는 값인지 먼저 가립니다.
화면에서 클릭이 작동한다는 사실만으로 이 차이가 해소되지는 않습니다. 버튼을 누른 뒤 별도의 동작으로 이동한다면 개발 담당자는 화면 동작과 링크 속성을 따로 조사합니다. 실제 주소가 없는데도 도구가 그 값을 경로처럼 처리했다면, 존재하지 않는 도착 페이지를 복구할 일이 생긴 것으로 판단하지 않습니다. 우선 수정할 대상은 링크를 만드는 방식입니다.
반대로 주소가 정상적으로 입력되어 있다면 그다음 단계에서 요청 결과를 읽습니다. 링크 문구가 자연스럽거나 페이지 디자인에 문제가 없다는 사실은 주소 판정의 근거가 되지 않습니다. 링크 문구는 사용자가 기대하는 목적지를 설명하는 자료로만 기록하고, 기술 판단에는 실제 입력값을 사용합니다.
후보를 좁히는 실행 순서
담당자는 결과 파일과 함께 링크가 있는 출발 페이지, 원래 링크 값, 도구가 해석한 요청 주소를 준비합니다. 상대 주소를 조사하려면 출발 페이지의 위치가 필요하므로 도착 주소만 따로 전달하지 않습니다. 보고서에 없는 항목은 페이지에서 수집하고, 직접 읽지 못한 값에는 미확인 상태를 표시합니다.
- 링크 값을 읽습니다. 개발 담당자가 href 속성에 실제 이동 주소가 있는지 판독하고, 주소가 아닌 호출 값은 링크 구현 수정 항목으로 분류합니다.
- 상대 주소의 해석을 대조합니다. 출발 페이지를 기준으로 생성된 요청 주소와 담당자가 의도한 목적지가 일치하는지 가립니다.
- 응답과 이동을 나누어 기록합니다. 최초 응답만으로 종료하지 않고 리디렉션이 있으면 최종 목적지에서 발생한 결과를 별도로 기재합니다.
- 남은 연결 실패 후보를 직접 엽니다. 출발 페이지의 링크를 사용한 결과와 후보 주소를 직접 연 결과를 기록하고, 실패를 재현하지 못한 항목은 보류합니다.
구글의 URL 구조 권장사항은 잘못된 상위 상대 링크와 존재하지 않는 페이지의 부적절한 서버 응답이 함께 작용하면 잘못된 주소가 계속 생성될 수 있다고 설명합니다. 이 문제에는 상위 상대 주소 대신 루트 상대 주소를 사용하도록 안내합니다. 경로가 반복되는 후보를 받은 담당자는 도착 페이지를 새로 만들기 전에 링크를 계산한 출발 위치부터 조사합니다.
상대 주소가 포함되어 있다는 사실만으로 수정 대상이 되지는 않습니다. 의도한 목적지와 해석 결과가 어긋난 항목에 대해서만 링크 값 변경을 요청합니다. 동일한 링크가 여러 페이지에서 사용된다면 개발 담당자는 공통 구성 요소에서 생성되는 값인지도 조사합니다.
직접 연결한 결과의 기록
아래 표는 운영자가 후보를 직접 열었을 때 채울 기록 양식입니다. 실제 결과를 얻기 전에는 정상이나 실패를 미리 기재하지 않습니다. 후보 주소란에는 내부 업무 문서에서 해당 주소를 기록하고, 출발 페이지 정보는 그 기록과 연결합니다.
| 확인 후보 주소 | 직접 확인한 연결 결과 | 추가 확인할 사항 |
|---|---|---|
| 원래 링크 값에서 얻은 주소 | 출발 페이지에서 클릭한 결과 기재 | 도구가 요청한 주소와의 일치 여부 |
| 상대 주소를 해석한 요청 주소 | 해당 주소를 직접 연 결과 기재 | 의도한 목적지와 출발 위치 |
| 리디렉션의 최종 목적지 주소 | 이동 완료 또는 중단 상태 기재 | 중단된 단계와 해당 응답 |
| 오류 응답을 받은 후보 주소 | 실패 재현 또는 재현되지 않음 기재 | 접근 조건과 추가 조사 담당자 |
한 후보에서 결과가 여러 개 나오면 최종 상태만 남기지 않습니다. 담당자는 클릭 결과, 직접 접근 결과, 수정 요청을 각각 기재해 후속 작업의 근거를 남깁니다. 완료 표시는 수정한 링크를 다시 사용한 결과를 받은 뒤 처리합니다.
응답 종류에 따른 오류 판단
리디렉션은 다른 주소로 이동하라는 응답이므로 그 자체를 연결 실패로 처리하지 않습니다. 구글은 리디렉션이 발생하면 이동 대상의 콘텐츠를 처리하며, 제품에 따라 리디렉션을 따르는 방식이 다를 수 있다고 설명합니다. 특히 구글 검사 도구는 리디렉션을 따르지 않는다고 안내합니다. 담당자는 이동 응답만 남은 결과와 최종 목적지에서 실패한 결과를 서로 다른 상태로 기록합니다.
접근 거부, 페이지 없음, 서버 오류도 같은 수정 요청으로 묶지 않습니다. 접근 거부라면 권한이나 접근 조건을 조사하고, 페이지 없음이라면 링크 대상이 유지되어야 하는지 콘텐츠 담당자에게 묻습니다. 서버 오류가 발생했다면 링크 문구를 고치는 대신 요청을 처리한 서버의 상태를 개발 담당자에게 전달합니다. 오류 종류가 불명확한 항목은 페이지 삭제로 확정하지 않습니다.
구글은 요청 제한을 나타내는 응답을 서버 과부하 신호로 취급한다고 설명합니다. 따라서 이 응답을 받은 후보를 곧바로 사라진 페이지 목록에 넣지 않습니다. 담당자는 요청이 제한된 상황을 기록하고, 접근이 가능한 조건에서 연결 결과를 다시 얻도록 작업을 요청합니다.
성공 응답과 사용 가능한 도착 화면
성공 응답을 받았다고 해서 사용자가 필요한 내용을 받았다고 단정할 수는 없습니다. 구글은 성공 응답이어도 빈 페이지나 오류 메시지가 전달되면 서치 콘솔에 soft 404 오류가 표시될 수 있다고 설명합니다. 운영자는 서버 응답 기록과 함께 도착 화면이 비어 있는지, 오류 안내만 있는지를 기재합니다.
연결 자체는 완료되었지만 오류 안내가 나온 항목은 연결 실패 기록과 콘텐츠 조사 기록을 함께 남길 수 있습니다. 이때 마케팅 담당자는 기대한 페이지의 용도를 설명하고, 개발 담당자는 실제 전달된 내용을 조사합니다. 정상 응답이라는 이유로 후보를 자동 종료하지 않되, 화면의 문구만으로 서버 응답을 추정하지도 않습니다.
수정 요청에는 판단한 문제와 수정할 대상을 연결합니다. 링크 값 오류는 출발 페이지의 링크에, 서버 처리 오류는 요청 대상에, 빈 응답은 전달된 내용에 관한 작업으로 기록합니다. 원인이 아직 밝혀지지 않았다면 완료 여부보다 다음 조사 담당자와 필요한 자료를 먼저 지정합니다.
자동 이동으로 감춰진 입력 오류
브라우저에서 목적지에 도착했더라도 원래 링크 값이 의도한 주소와 같은지는 별도의 판단입니다. 잘못 입력한 주소를 서버가 다른 주소로 이동시키는 경우에는 연결 성공과 입력 오류가 함께 존재할 수 있습니다. 담당자는 최종 화면만 기록하지 않고 출발 페이지의 입력값과 이동한 주소를 함께 남깁니다.
이 경우 연결이 실패했다고 보고할 필요는 없지만 링크 값의 정비 여부는 결정해야 합니다. 콘텐츠 담당자가 의도한 목적지를 정하고 개발 담당자가 해당 링크를 어디에서 생성하는지 조사합니다. 공통 구성 요소에서 생성된다면 개별 페이지마다 수정 요청을 복제하지 않고 같은 원인을 가진 작업으로 묶습니다. 수정 범위는 최종 도착 화면이 아니라 링크를 생성하는 위치를 기준으로 정합니다.
자주 묻는 질문
같은 주소가 여러 번 보고되면 하나만 처리해도 되나요?
요청 대상이 같더라도 출발 페이지와 링크 생성 위치가 다르면 수정 작업은 달라질 수 있습니다. 대상 주소별로 조사 결과를 묶되, 그 주소를 사용하는 위치 목록은 유지합니다. 공통 원인을 수정한 뒤에도 각 위치에 변경이 적용되었는지 대조합니다.
이메일이나 전화 연결도 깨진 페이지로 기록해야 하나요?
웹 페이지 이동과 다른 동작을 의도한 링크라면 별도의 유형으로 기록하는 편이 적절합니다. 페이지 응답만 읽는 기준으로 정상 여부를 판정하지 않습니다. 해당 동작이 의도대로 실행되는지를 담당자가 시험하고 웹 페이지 후보 목록과 따로 관리합니다.
페이지 안의 특정 위치로 이동하지 않으면 오류인가요?
문서가 열리는 문제와 문서 안의 지정 위치로 이동하는 문제를 나누어 기록합니다. 목적지 페이지가 정상적으로 열려도 지정한 위치가 없어졌다면 내부 이동 기능을 수정할 수 있습니다. 개발 담당자에게 해당 링크 값과 기대한 이동 위치를 전달합니다.
외부 사이트의 링크가 실패하면 삭제부터 해야 하나요?
콘텐츠 담당자가 그 링크를 유지해야 하는 이유와 대체할 자료의 유무를 먼저 판단합니다. 외부 서버를 직접 수정할 수 없으므로 대상 운영자에게 장애 여부를 묻거나 대체 자료를 검토할 수 있습니다. 처리 방향이 정해지기 전에는 기술 오류 표시만으로 연결된 설명까지 삭제하지 않습니다.
오류 후보가 없으면 링크 조사를 종료해도 되나요?
결과에 후보가 없다는 사실은 도구가 읽은 대상에서 오류를 표시하지 않았다는 뜻으로 기록합니다. 특정 도구가 모든 형태의 연결 문제를 발견했다고 확대 해석하지 않습니다. 중요한 이용 동작이 조사 대상에 포함되었는지 운영자가 판단하고, 빠진 동작은 별도 시험 항목으로 남깁니다.
