서버 점검으로 사이트를 몇 시간 닫을 때 503으로 지키는 검색엔진최적화

서버 점검으로 사이트를 몇 시간 닫는다면 일반 페이지에는 503(일시적 서비스 불가) 응답과 Retry-After 헤더를 보냅니다. robots.txt만은 정상 응답(200)으로 유지하는 것이 검색엔진최적화 손실을 줄이는 기본 방법입니다.

404·403으로 막거나 robots.txt까지 503으로 내보내면 URL 삭제나 사이트 전체 크롤링 중단으로 이어질 수 있습니다. 503으로 사이트를 닫는 기간은 하루나 이틀 안으로 끝내야 합니다.

몇 시간 점검에는 어떤 응답 코드를 보내야 하나요?

점검 중 검색엔진이 받는 신호는 화면 문구가 아니라 HTTP 상태 코드입니다. 같은 점검 화면이라도 어떤 코드와 함께 나가는지에 따라 검색엔진의 해석이 달라집니다.

Google 문서는 5xx 서버 오류를 받으면 크롤러가 일시적으로 크롤링 속도를 낮춘다고 설명합니다. 속도를 낮추는 정도는 서버 오류를 돌려주는 URL 수에 비례합니다. 이미 색인된 URL은 색인에 남지만, 오류가 이어지면 결국 제외됩니다.

표의 아래쪽 방식은 「잠시 닫는다」가 아니라 「페이지가 없다」 또는 「수집하지 말라」는 뜻으로 읽힙니다. 몇 시간만 닫는 상황과 맞지 않는 신호입니다.

점검 전날까지 무엇을 정해야 하나요?

1단계는 사이트 전체를 닫아야 하는지부터 정하는 일입니다. Google의 사이트 일시 중단 문서는 사이트를 온라인 상태로 유지하고 기능만 제한하는 방식을 먼저 권합니다. 사이트를 색인에서 완전히 없애는 것은 회복에 꽤 오랜 시간이 걸릴 수 있는 큰 변화라는 이유입니다.

예를 들어 가상의 쇼핑몰 기업이 결제 시스템만 교체한다면, 장바구니와 결제만 멈추고 상품 페이지는 그대로 열 수 있습니다. 이때는 모든 페이지 상단에 점검 안내 배너를 붙입니다. 같은 문서에 따르면 배너에 data-nosnippet 속성을 지정해 검색 결과 요약문에 배너 문구가 나오지 않게 할 수 있습니다.

데이터베이스 이전처럼 페이지 자체를 보여 줄 수 없을 때만 503 전체 차단으로 넘어갑니다. 결정 전에 아래 항목을 담당자와 함께 확인합니다.

1. 점검 범위: 전체 차단인지, 결제·회원 등 일부 기능 제한으로 충분한지 정합니다.
2. 예상 시간: 시작·종료 시각과 지연 시 최대 허용 시간을 정합니다. 이틀을 넘길 가능성이 있으면 4단계의 전환 방식(200 홈페이지 안내)을 함께 준비합니다.
3. 예외 경로: robots.txt는 503 대상에서 빼고, 점검 페이지가 쓰는 파일 경로도 정합니다.
4. 캐시 계층: 콘텐츠 전송 네트워크(CDN)나 프록시가 503 화면을 저장하지 않게 설정할 위치를 확인합니다.
5. 공유 대상: 실무에서는 광고·고객센터 담당자에게도 점검 시간을 미리 알리는 방법을 권합니다. 점검 중 광고 유입과 문의 대응을 조정할 수 있기 때문입니다.

완료 기준: 차단 방식, 시작·종료 시각, robots.txt 예외 여부, 캐시 설정 위치가 한 문서에 적혀 있고 개발·광고 담당자가 확인했으면 1단계가 끝난 것입니다.

점검 페이지와 503 응답은 어떻게 설정하나요?

2단계는 점검 중 나갈 응답을 실제로 만드는 일입니다. 사이트 일시 중단 문서는 503 점검 페이지에 대해 다음 사항을 안내합니다.

• Retry-After 헤더에 최선의 추정으로 복구 날짜나 기간을 넣습니다.
• 점검 페이지는 정적 HTML로 만들고, 스타일은 페이지 안에 직접 쓰며, 이미지는 base64(문자열로 바꾼 이미지)로 넣습니다.
• 사용자에게 다음에 할 일을 페이지 안에서 분명히 알립니다.

점검 페이지를 가볍게 만드는 이유는 점검 중 서버가 다른 파일을 내줄 수 없을 수 있어서입니다. 외부 글꼴이나 별도 이미지 파일에 기대면 안내 화면마저 깨질 수 있습니다.

MDN 문서에 따르면 Retry-After에는 날짜 또는 초 단위 숫자를 넣을 수 있고, Googlebot 같은 일부 크롤러가 이 헤더를 따릅니다. 세 시간 점검이라면 응답 헤더는 다음과 같이 구성합니다.

• 상태: HTTP 503 Service Unavailable
• Retry-After: 10800 (10,800초, 3시간)
• Cache-Control: no-store (점검 화면을 저장하지 않게 하는 설정)

503 응답은 대개 캐시하지 않아야 한다는 것이 MDN의 설명입니다. 캐시된 점검 화면이 남으면 점검을 마친 뒤에도 방문자가 예전 오류 화면을 받을 수 있기 때문입니다.

점검 페이지 문안은 다음처럼 짧게 씁니다. 날짜와 연락처만 바꿔 그대로 쓸 수 있습니다.

• 제목: 서비스 점검 중입니다
• 본문: 더 안정적인 서비스를 위해 11월 5일 오전 2시부터 5시까지 시스템을 점검합니다. 점검 중에는 사이트 이용이 잠시 중단됩니다.
• 안내: 점검이 끝나면 별도 조치 없이 정상 이용하실 수 있습니다. 급한 문의는 고객센터 대표 전화로 연락해 주시기 바랍니다.

완료 기준: 점검 환경에서 curl -I 명령으로 대표 페이지를 요청했을 때 503, Retry-After, no-store 세 가지가 함께 보이면 2단계가 끝난 것입니다. 사이트 일시 중단 문서도 curl 같은 도구로 503 응답을 직접 확인하라고 적습니다.

robots.txt는 왜 점검 대상에서 빼야 하나요?

3단계는 robots.txt를 정상 응답으로 지키는 일입니다. 서버 설정에서 「모든 요청에 503」으로 한 번에 묶으면 robots.txt도 함께 503이 됩니다. 설정을 한 번에 묶을 때 함께 막히기 쉬운 부분입니다.

Google의 robots.txt 사양 문서에 따르면 robots.txt가 서버 오류를 돌려주면 처음 12시간 동안 사이트 크롤링을 멈추고 robots.txt만 계속 요청합니다. 그 뒤 30일 동안은 마지막으로 정상 수신한 버전을 쓰면서 새 버전을 계속 가져오려 합니다.

몇 시간 점검이라면 이 12시간은 점검 시간보다 깁니다. 점검을 마치고 페이지가 정상으로 돌아와도, 그 사이 robots.txt 오류를 받았다면 크롤링이 늦게 재개될 수 있습니다. 사이트 일시 중단 문서도 robots.txt에 503을 돌려주면 모든 크롤링이 막힌다며 이를 금지합니다.

robots.txt 내용을 「Disallow: /」로 바꿔 전체를 막는 방법도 쓰지 않습니다. 같은 문서는 모든 크롤링을 막는 robots.txt가 사이트 콘텐츠를 검색에서 삭제할 수 있다고 경고합니다. 점검 중 robots.txt는 평소 내용 그대로, 평소처럼 200으로 나가야 합니다.

완료 기준: 503 적용 직후 robots.txt 주소를 curl -I로 요청해 200이 나오고, 내용이 평소 파일과 같으면 3단계가 끝난 것입니다.

점검이 길어질 때는 어떤 순서로 바꾸나요?

4단계는 예정 시간을 넘길 때의 전환 기준을 지키는 일입니다. Google의 크롤링 속도 조절 문서는 오류 응답을 몇 시간에서 하루나 이틀 정도의 짧은 기간에만 쓰도록 안내합니다. 하루나 이틀보다 오래 쓰는 것은 권하지 않습니다.

같은 문서는 Googlebot이 같은 URL에서 여러 날 이런 상태 코드를 받으면 그 URL이 색인에서 빠질 수 있다고 경고합니다. 크롤링 속도가 낮아지면 새 페이지를 덜 발견하고 기존 페이지 갱신도 줄며, 가격과 재고 정보가 검색에 늦게 반영될 수 있다는 설명도 덧붙입니다.

점검 중에는 검색 결과의 표시 정보도 바뀌지 않습니다. 사이트 일시 중단 문서에 따르면 503을 돌려주는 동안 Google 시스템은 제목, 설명, 메타데이터, 구조화된 데이터를 새로 고칠 수 없습니다.

점검이 늦어지면 Retry-After 값부터 남은 시간에 맞게 고칩니다. 하루를 넘길 것으로 보이면 전체 차단을 이어 가기보다 일부 페이지라도 정상 응답으로 여는 방안을 검토합니다.

완료 기준: 예정 종료 시각이 지났을 때 Retry-After 수정 여부와 전환 여부를 정하고, 그 결정을 기록에 남겼으면 4단계가 끝난 것입니다.

점검을 마친 뒤 무엇으로 회복을 확인하나요?

5단계는 정상 응답 복구와 검색엔진 쪽 반응을 확인하는 일입니다. 점검 종료 직후에는 서버 설정을 원래대로 돌리고 CDN·프록시 캐시를 비웁니다. 그다음 대표 페이지, 카테고리 페이지, 상세 페이지를 하나씩 curl -I로 요청해 200이 나오는지 확인합니다.

다음 날에는 Search Console의 설정 메뉴에서 크롤링 통계 보고서를 엽니다. 이 보고서는 루트 수준 속성에서만 볼 수 있습니다. Search Console 도움말에 따르면 호스트 상태는 robots.txt 가져오기, DNS 변환, 서버 연결 세 가지로 평가되고, 응답 유형별 크롤링 요청 비율도 함께 나옵니다.

점검 시간대에 서버 오류가 잠시 늘었다가 이후 정상 응답 비율이 돌아왔는지 확인합니다. 점검 시간대에 robots.txt 가져오기 실패가 보이면 3단계 예외 설정이 제대로 걸리지 않았던 것입니다.

사이트 일시 중단 문서는 다시 열 때 확인할 페이지가 적으면 Search Console에서 재크롤링을 요청하고, 많으면 사이트맵을 제출하도록 안내합니다. 네이버 노출도 관리하는 사이트라면 실무에서는 네이버 서치어드바이저의 수집 현황도 함께 확인하는 방법을 권합니다. 점검 시간대에 수집 오류가 늘었는지, 이후 줄었는지 확인합니다.

점검마다 아래 양식으로 기록을 남기면 다음 점검의 시간 추정과 원인 확인이 빨라집니다. 예시 값은 가상의 3시간 점검을 가정한 것입니다.

완료 기준: 주요 페이지가 200으로 응답하고, 크롤링 통계에 robots.txt 가져오기 실패가 없으며, 서버 오류 응답이 점검 시간대 밖으로 이어지지 않으면 5단계가 끝난 것입니다.

정리

몇 시간 점검의 핵심은 일반 페이지에 일시적이라는 신호(503)를 보내는 것입니다. robots.txt는 평소처럼 200으로 유지하고, 503 기간은 하루나 이틀 안으로 끝냅니다. 다음 점검 일정이 잡혀 있다면 아래 순서로 준비합니다.

1. 기능 제한만으로 점검할 수 있는지 먼저 판단하고, 전체 차단이 필요할 때만 503을 쓰기로 정합니다.
2. 정적 점검 페이지를 만들고 503, Retry-After, no-store 세 가지 응답을 설정합니다.
3. robots.txt를 503 대상에서 빼고, 점검 시작 직후 robots.txt가 200으로 나가는지 curl로 확인합니다.
4. 예정 시간을 넘기면 Retry-After를 고치고, 하루나 이틀을 넘길 것 같으면 200 홈페이지 안내로 전환합니다.
5. 종료 다음 날 크롤링 통계 보고서와 서치어드바이저 수집 현황을 확인하고 기록 양식에 결과를 적습니다.

참고 자료

• Pause or disable a website (Google Search Central, 확인일 2026-10-22)
• How HTTP status codes, and network and DNS errors affect Google Search (Google Search Central, 확인일 2026-10-22)
• How Google interprets the robots.txt specification (Google Search Central, 확인일 2026-10-22)
• Reduce the Google crawl rate (Google Search Central, 확인일 2026-10-22)
• 크롤링 통계 보고서 (Search Console 고객센터, 확인일 2026-10-22)
• 503 Service Unavailable (MDN Web Docs, 확인일 2026-10-22)
• Retry-After header (MDN Web Docs, 확인일 2026-10-22)