HTTP Status 체커
공개 URL의 상태 코드, redirect 결과, 주요 응답 header, 복사 가능한 점검 보고서를 확인해 배포와 SEO 상태를 점검해요.
서버가 대신 조회입력한 주소를 이 사이트 서버가 대신 조회해요.
입력과 결과
입력한 내용은 이 브라우저에만 저장돼요. 다시 열면 마지막 작업을 불러올 수 있어요.
이럴 때 써요
- 공개 URL의 상태 코드, redirect 결과, 주요 응답 header, 복사 가능한 점검 보고서를 확인해 배포와 SEO 상태를 점검해요.
- 서버 확인 방식으로 입력을 다루며 복사 전 결과를 확인해요.
- HTTP Status 체커와 관련 도구를 이어서 사용해 작업 흐름을 줄여요.
예제
- 일반 입력
https://www.google.com- 공개 URL의 상태, 리다이렉트 진단, 최종 응답 헤더, 붙여넣은 헤더 블록, CSP 초안, 복사 가능한 URL 보고서를 확인해요.
- 일반 출력
200 OK / 최종 URL / 리다이렉트 진단 / 공개 URL 보고서 / 파싱된 헤더 / CSP 헤더- 복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
- 추가 예제
https://bobob.app- 복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
- 추가 예제
https://www.bobob.app/sitemap.xml- 복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
- 추가 예제
https://www.bobob.app/tools/http-status-checker- 복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
- 추가 예제
https://www.bobob.app/- 복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
자주 하는 실수
- 리다이렉트 흐름은 예상과 다른 host, path, protocol, locale에서 끝날 수 있어요.
- 서버는 HEAD, GET, user-agent, cache 상태에 따라 다른 status를 줄 수 있어요.
- 복사한 값에 운영 비밀값, 고객 데이터, 내부 URL이 섞여 있으면 공유 전에 제거해야 해요.
복사하기 전에
- 1status code, final URL, content type, cache header를 함께 확인해요.
- 2apex와 www, http와 https의 canonical redirect를 각각 확인해요.
- 3HTTP Status 체커 결과가 다음 단계에 맞는지 관련 도구로 이어서 검토해요.
참고 자료
301(Moved Permanently)은 과거 관행 때문에 POST 를 GET 으로 바꿔 다시 보내는 것이 허용돼요. 308(Permanent Redirect)은 메서드와 본문을 바꾸지 말라고 못 박아요(RFC 9110). 폼 전송이 리디렉션을 타면 이 차이가 바로 드러나요.
기준 RFC 9110
410(Gone)은 자원이 영구히 사라졌고 돌아올 계획이 없다는 걸 서버가 아는 경우에 쓰도록 정해져 있어요(RFC 9110). 404 는 지금 없다는 뜻이라 크롤러가 한동안 다시 찾아와요.
기준 RFC 9110
200 을 주면서 오류 화면을 보여 주는 게 가장 나빠요
2xx 는 요청이 받아들여지고 성공했다는 뜻으로 정의돼요(RFC 9110). 없는 페이지에 200 을 주면 브라우저와 검색 크롤러 모두 성공으로 받아들여서, 사라진 주소가 색인에 그대로 남아요.
기준 RFC 9110
자주 묻는 질문
HTTP Status 체커 입력값은 어디에서 처리되나요?
공개 URL 또는 호스트 확인처럼 브라우저만으로 할 수 없는 값만 서버 엔드포인트로 보내요.
결과를 그대로 운영에 써도 되나요?
복사하기 전에 대상 런타임, 인코딩, 시간대, 보안 정책처럼 환경별 차이를 한 번 더 확인하세요.