Broken Link Checker
끊긴 링크 검사기는 페이지를 가져와 그 위의 모든 링크와 이미지를 모으고, 방문자가 실제로 무엇을 얻는지 확인하기 위해 하나씩 요청합니다. 아래에 페이지 URL 하나를 붙여넣으세요: 가져올 수 있는 각 링크는 검사되어 정상, 리디렉션, 끊김, 서버 오류, 시간 초과 또는 연결 불가로 분류됩니다; 절대 가져와서는 안 되는 링크 — mailto:, tel:, 페이지 내 프래그먼트 — 는 나열되지만 요청되지 않습니다; 그리고 사설 또는 차단된 주소로 해석되는 것은 건너뜀으로 보고되며 절대 가져오지 않습니다. 실행당 한 페이지, 최대 300개 링크, 그리고 실행이 일찍 멈추면 부분 결과는 부분이라고 명시됩니다 — 완전한 것으로 제시되는 일은 결코 없습니다.
마지막 업데이트:
제한을 솔직히: 실행당 한 페이지(전체 사이트 크롤링이 아닙니다), 실행당 최대 300개의 링크 검사, 링크가 많은 페이지에서는 실행에 약 25초까지 걸릴 수 있습니다. 이 검사기는 주소당 시간당 5회 실행으로 제한됩니다.
링크 결과
검사 사이에 새 끊긴 링크가 계속 나타납니까? myeventwatch로 무료 모니터링 — 만료 및 중단 알림, 카드 불필요.
이 검사기가 하는 일 — 그리고 하지 않는 일
페이지를 제출하면 검사기는 그것을 한 번 가져와 HTML을 파싱하고, <a> 링크와 <img> 이미지의 대상을 수집하며, 상대 URL을 리디렉션 후 페이지의 최종 주소를 기준으로 해석합니다. 각 고유한 웹 주소는 차례로 요청됩니다: 리디렉션은 따라가며 세어지므로, 두 번의 이동 후에야 작동하는 링크는 깨끗한 정상이 아니라 홉 수가 있는 리디렉션으로 보고됩니다. 결과는 최종 HTTP 상태 코드를 갖춘 링크별 판정입니다 — 브라우저, 검색 크롤러 또는 답답한 방문자가 클릭했을 때 만나게 될 바로 그 증거입니다.
세 종류의 링크는 의도적으로 절대 가져오지 않습니다. 웹이 아닌 스킴의 주소 — mailto:, tel:, javascript:와 그 친척들 — 는 애초에 HTTP 요청이 아니므로, 상태를 지어내는 대신 이유와 함께 “가져오지 않음”으로 나열됩니다. #section과 같은 순수 프래그먼트 링크는 검사기가 이미 가진 페이지 내부를 가리키므로 새로 요청할 것이 없습니다. 그리고 호스트가 사설, 루프백 또는 기타 차단된 주소로 해석되는 모든 링크는 건너뜀으로 보고됩니다: 공개 검사기는 누군가의 내부 네트워크로 들어가는 지렛대로 쓰일 수 있어서는 안 되므로, 그 대상들은 이름을 밝히고 세되 엄격히 내버려 둡니다.
판정 읽기와 올바른 순서의 수정
자신의 사이트 내부를 가리키는 끊긴 링크부터 시작하세요: 내부 링크의 404는 당신이 통제하는, 허무로 열리는 문이며, 그것을 고치는 것 — 페이지를 복원하거나, URL을 바로잡거나, 링크를 대체 페이지로 향하게 하는 것 — 은 모든 방문자와 모든 크롤러를 동시에 돕습니다. 다음은 리디렉션 체인입니다: 이전 후 리디렉션 한 번은 정상이지만, 두 번 이상의 홉은 모든 클릭을 늦추고 크롤링 노력을 낭비하므로 링크를 최종 주소로 업데이트하세요; 전체 그림을 봐야 할 때는 HTTP 상태 체인 추적기가 홉별 전체 경로를 보여줍니다. 끊긴 이미지는 세 번째입니다 — 읽기를 막는 경우는 드물지만 건강한 페이지를 버려진 것처럼 보이게 합니다. 시간 초과와 서버 오류는 수술 전에 재검사할 가치가 있습니다: 5xx나 시간 초과는 죽은 페이지가 아니라 바쁜 1분일 수 있는 반면, 계속 연결할 수 없는 호스트는 링크 문제가 아니라 DNS 또는 호스팅 문제입니다.
이 도구는 의도적으로 실행당 한 페이지를 검사합니다. 전체 사이트 크롤링은 다른 도구입니다 — CMS 보고서, 서버 로그 또는 Search Console이 그 자리이며 — 한 페이지 검사가 전체 사이트를 커버하는 척하는 것은 부정직할 것입니다. 이 검사기를 홈페이지, 핵심 랜딩 페이지, 그리고 방금 재설계하거나 이전하거나 가지치기한 모든 페이지에 대해 실행하고, 언제 검사하고 어떤 순서로 고칠지는 동반 가이드 방문자보다 먼저 끊긴 링크 찾기를 읽어보세요. 실행당 최대 300개의 링크가 검사됩니다; 페이지가 그보다 많이 담고 있거나 실행이 시간 제한에 닿으면, 결과는 그 사실을 말하고 조용히 잘라내는 대신 부분이라고 명시됩니다.
각 결과 상태의 의미
| 정상 | 링크를 가져왔고 최종 응답은 리디렉션 없이 성공(2xx)이었습니다 — 방문자는 링크가 가리키는 곳에 정확히 도착합니다. |
| 리디렉션 | 링크는 작동하지만 한 번 이상의 리디렉션(3xx)을 거친 후에만 그렇습니다. 개수는 최종 성공까지 따라간 홉 수를 보여줍니다. |
| 끊김(4xx) | 서버가 클라이언트 오류로 응답했습니다 — 가장 흔한 것은 404 찾을 수 없음 또는 410 사라짐입니다. 링크가 약속하는 페이지는 거기 없습니다. |
| 서버 오류(5xx) | 대상 서버가 제대로 응답하지 못했습니다(500, 502, 503, 504 등). 링크는 멀쩡할 수 있습니다; 서버가 그렇지 않습니다 — 무엇이든 바꾸기 전에 재검사하세요. |
| 시간 초과 | 대상이 검사기의 시간 제한 내에 응답하지 않았습니다. 한 번의 시간 초과는 “느리거나 바쁨”으로, 반복되는 시간 초과는 진짜 문제로 취급하세요. |
| 연결 불가 | 연결 자체를 전혀 맺을 수 없었습니다 — DNS 실패, 연결 거부 또는 죽은 호스트. 그 위의 한 페이지가 아니라 주소 자체가 곤경에 처해 있습니다. |
| 건너뜀(차단됨) | 링크가 사설, 루프백 또는 기타 차단된 주소로 해석되므로 보고는 되었지만 절대 가져오지 않았습니다. 공개 검사기는 내부 네트워크를 탐색해서는 안 됩니다. |
자주 묻는 질문
이 검사기는 제 웹사이트 전체를 크롤링합니까?
아니요. 실행당 정확히 한 페이지 — 당신이 붙여넣은 페이지 — 와 그 페이지의 모든 링크와 이미지를 최대 300개의 검사된 링크까지 검사합니다. 링크를 따라가며 사이트의 나머지를 크롤링하지는 않습니다. 전체 사이트를 보려면 CMS, 서버 로그 또는 Search Console을 사용하고, 이 검사기는 가장 중요한 페이지에 실행하세요: 홈페이지, 핵심 랜딩 페이지, 최근에 재설계하거나 이전한 모든 것입니다.
일부 링크가 나열되어 있는데 “가져오지 않음”으로 표시되는 이유는 무엇입니까?
가져오는 것이 무의미하거나 잘못되기 때문입니다. 웹이 아닌 스킴의 링크 — mailto:, tel:, javascript: 등 — 는 HTTP 요청이 아니므로 보고할 상태가 없습니다; 프래그먼트 링크(#section)는 이미 가져온 페이지 내부를 가리킵니다. 두 종류 모두 이유와 함께 나열되어 셈이 맞습니다: 찾은 링크는 항상 검사된 링크에 나열되었지만 가져오지 않은 링크와 부분 실행이 닿지 못한 나머지를 더한 것과 같습니다.
링크가 건너뜀으로 돌아온 이유는 무엇입니까?
그 호스트가 사설, 루프백 또는 기타 차단된 주소로 해석되기 때문입니다. 그런 대상을 가져오는 공개 링크 검사기는 내부 네트워크 — 라우터, 관리자 패널, 클라우드 메타데이터 엔드포인트 — 를 탐색하는 데 쓰일 수 있으므로, 이 검사기는 그런 링크를 건너뜀으로 보고하고 절대 요청하지 않습니다. 링크가 자신의 페이지에 있고 내부 주소를 가리킨다면, 그것은 보통 그 자체로 고칠 가치가 있는 실수입니다: 방문자도 거기에 닿을 수 없습니다.
결과가 부분이라고 명시되어 있습니다. 무슨 일이 있었습니까?
가져올 수 있는 모든 링크가 검사되기 전에 실행이 멈췄습니다 — 페이지가 300개 링크 상한보다 많이 담고 있었거나 실행이 시간 제한에 닿았습니다. 요약은 항상 가져올 수 있는 링크 중 몇 개가 검사되었는지 보여주며, 표에서 빠진 링크는 건강한 것이 아니라 검사되지 않은 것입니다. 같은 페이지에 대해 검사를 다시 실행하고, 얻은 판정은 유효한 것으로 취급하세요: 부분 실행에서 찾은 끊긴 링크는 여전히 끊긴 링크입니다.
링크가 서버 오류를 보이는데 제게는 잘 열립니다. 왜 그렇습니까?
서버 오류와 시간 초과는 종종 일시적입니다: 대상은 검사 순간에 바빴거나, 재시작 중이었거나, 요청을 제한하고 있었고, 1분 뒤에는 멀쩡합니다. 5xx나 시간 초과를 보고하는 링크를 바꾸기 전에 검사를 다시 실행하세요. 같은 링크가 반복해서 실패하는데 브라우저에서는 잘 열린다면, 그 차이는 종종 대상 쪽의 지역, 캐싱 또는 봇 처리 때문입니다 — HTTP 상태 체인 추적기는 검사기 스타일의 요청이 거치는 정확한 응답 경로를 보여줄 수 있습니다.