기술 SEO: 응답 한 번이 페이지의 운명을 정한다

기술 SEO는 서버가 돌려준 응답 하나를 검색엔진이 정상적인 HTML 문서로 받아들일 수 있는가를 확인하는 카테고리입니다. SEO 100점 중 20점을 차지합니다. 검색 접근성이 “크롤러가 페이지에 닿을 수 있는가”를 묻는다면, 기술 SEO는 “닿은 뒤에 받은 것이 제대로 된 문서인가”를 묻습니다. 상태 코드가 200이 아니거나, 리디렉션이 엉켜 있거나, Content-Type이 HTML이 아니면 본문의 품질을 따지기도 전에 처리가 끝납니다.

이 카테고리에 20점을 배정한 이유는 서버 응답과 전송 경로가 문서 처리의 출발점이기 때문입니다. 항목별 배점은 3점부터 1점까지 나누고, 실제 화면 확인이 필요한 이미지 지연 로딩은 0점 진단으로 둡니다. 문제의 영향과 한 번의 요청으로 확인할 수 있는 범위를 함께 반영한 애드브랜치 기준입니다.

검사기는 이 카테고리의 항목들을 서버 응답이 도착하는 순서대로 봅니다. 상태 코드를 먼저 확인하고, 거기까지 오는 경로를 살핀 다음, 마지막으로 문서 자체의 기본 선언을 읽습니다. 아래 설명도 같은 순서를 따릅니다.

1단계, 응답 자체가 정상인가

최종 HTTP 성공 상태

최종 HTTP 성공 상태(2점)는 리디렉션 후 응답이 2xx인지 확인합니다. 검사 API는 대상 페이지의 4xx·5xx 응답을 점수 대신 오류로 돌려주므로, 결과 카드까지 도달한 검사에서는 보통 통과합니다. 이를 반영해 기존 4점 중 2점을 없는 URL 응답 검사로 옮겼습니다. 카테고리 합계는 20점을 유지합니다.

실무에서 이 항목이 틀리는 방식은 두 갈래입니다. 하나는 배포 직후의 일시적 5xx인데, 이것은 다시 검사하면 사라집니다. 다른 하나는 훨씬 조용한 문제로, 봇 차단 규칙이나 WAF가 검사기 같은 자동 요청에만 403을 돌려주는 경우입니다. 브라우저에서는 멀쩡하게 열리기 때문에 운영자는 문제를 모릅니다. 검사 결과가 403인데 브라우저에서 정상이라면 서버 앞단의 차단 정책을 먼저 의심하는 것이 맞습니다.

흔한 오해 하나를 짚어 두겠습니다. 이 항목은 입력 URL의 상태 코드가 아니라 최종 URL의 상태 코드를 봅니다. 입력한 URL이 301을 돌려줘도 그 끝이 200이면 통과이고, 반대로 입력 URL이 200이어도 그 안에서 메타 refresh로 다른 곳으로 보낸 뒤 그곳이 404라면 검사기는 그 부분까지 따라가지 않으므로 통과로 나올 수 있습니다.

soft 404 신호

soft 404 신호(2점)는 상태 코드는 200인데 본문이 “페이지를 찾을 수 없습니다” 같은 안내 문구로만 채워진 경우를 찾습니다. 실제 404 응답과 달리 본문 문구와 길이에서 추정한 결과이므로 오탐 가능성을 함께 살펴야 합니다.

이 문제가 생기는 전형적인 경로는 SPA와 프레임워크의 기본 동작입니다. 클라이언트 라우터가 모든 경로를 받아 처리하면 서버는 존재하지 않는 URL에도 200과 함께 앱 껍데기를 돌려주고, 화면에는 “없는 페이지”가 그려집니다. 사용자는 구별하지 못하지만 검색엔진은 그 URL을 색인 후보로 받아들이고, 이런 URL이 수천 개 쌓이면 크롤 예산이 그쪽으로 새어 나갑니다.

수정할 때 자주 하는 실수는 안내 문구를 더 친절하게 바꾸는 것입니다. 문구는 문제가 아닙니다. 상태 코드가 문제입니다. 존재하지 않는 URL은 404를, 영구히 옮긴 URL은 301을 돌려주도록 서버 쪽 설정을 고쳐야 합니다. 반대로 실제 내용이 있는 짧은 페이지가 이 항목에 걸렸다면 그것은 오탐일 가능성이 있으며, 본문 길이를 늘리거나 안내 문구와 겹치는 표현을 정리하면 판정이 바뀝니다.

없는 URL의 404 응답

없는 URL의 404 응답(2점)은 같은 origin의 /adbranch-404-check-<무작위> 경로에 한 번 요청하고 리디렉션을 따라가지 않습니다. 입력 페이지의 본문을 보는 soft 404 신호와 달리, 사이트가 없는 경로를 어떻게 처리하는지 별도로 관측합니다.

404·410은 통과, 429는 확인 불가, 나머지 4xx는 참고로 표시합니다. 2xx·5xx와 홈 또는 현재 페이지로 보내는 리디렉션은 개선 권장입니다. 다른 리디렉션은 최종 응답을 확인하지 않았다는 참고로 남기며, 요청 한도를 소진했거나 응답이 없으면 확인 불가입니다. Google은 429를 제외한 4xx를 없는 문서로 처리하고 404와 410을 동등하게 취급한다고 안내합니다. Google 크롤러는 최대 10개의 리디렉션 홉을 따라갈 수 있지만, 이 진단은 요청 예산과 판정 범위를 제한하려고 첫 3xx에서 멈춥니다. Google HTTP 상태 코드 안내

이 검사 하나로 사이트 전체의 404 처리가 올바르다고 결론 내릴 수는 없습니다. 특정 경로의 인증이나 WAF 규칙, 와일드카드 라우팅이 응답을 바꿀 수 있습니다. 200이나 리디렉션 경고도 Google이 실제로 soft 404로 분류했다는 결과가 아니라 운영자가 확인할 신호입니다.

2단계, 여기까지 오는 길이 깨끗한가

HTTPS 사용

HTTPS 사용(3점)은 최종 URL의 scheme이 https인지 확인합니다. 3점을 준 이유는 이것이 색인을 직접 막는 문제는 아니지만, 브라우저 경고와 혼합 콘텐츠 차단으로 이어져 사용자가 페이지를 아예 보지 못하는 상황을 만들기 때문입니다. 2026년 시점에서 HTTP로만 제공되는 페이지는 검색엔진에게도 사용자에게도 예외적인 존재입니다.

이 항목에서 실무자가 놓치는 부분은 인증서 설치 자체보다 HTTP 요청의 처리입니다. 인증서를 설치했어도 http:// 로 들어온 요청이 그대로 200을 돌려주면 같은 페이지가 두 scheme으로 존재하게 됩니다. 검사기에 http:// 주소를 입력했을 때 HTTPS로 넘어가지 않으면 이 항목은 실패로 나오고, 이것은 인증서 문제가 아니라 리디렉션 설정 문제입니다. HTTP 요청은 HTTPS로 301 리디렉션하고, 가능하면 HSTS 헤더로 브라우저가 처음부터 HTTPS로 접속하게 하는 것이 완성된 형태입니다.

최종 URL 일관성

최종 URL 일관성(2점)은 입력한 URL, 리디렉션 후 도착한 최종 URL, 그리고 그 페이지가 선언한 canonical URL 세 가지가 서로 맞는지 봅니다. 이 세 값이 어긋나면 검색엔진은 어느 것을 대표 URL로 삼을지 스스로 결정하게 되고, 그 결정은 운영자의 의도와 다를 수 있습니다.

배점이 2점인 이유는 이 문제가 색인을 막지는 않되 신호를 분산시키기 때문입니다. www 유무, 끝 슬래시 유무, 대소문자, index.html 같은 파일명, 추적 파라미터가 뒤섞이면 같은 문서가 여러 URL로 발견되고, 각각에 쌓이는 링크 신호가 나뉩니다. 가장 흔한 형태는 https://example.com/page 와 https://www.example.com/page 가 모두 200을 돌려주면서 canonical은 둘 중 하나만 가리키는 경우입니다.

한 가지 오해를 정리해 두겠습니다. canonical을 선언했다고 해서 이 항목이 자동으로 통과되지는 않습니다. canonical은 “이쪽이 대표”라는 힌트이지 리디렉션이 아닙니다. 최종 URL이 canonical과 다르면 검색엔진은 두 URL을 모두 크롤한 뒤에야 힌트를 읽습니다. 정책을 하나로 정하고 나머지 변형은 리디렉션으로 대표 URL에 보내는 것이 canonical 선언보다 먼저 할 일입니다. 자세한 기준은 canonical URL 설정 가이드에 정리돼 있습니다.

redirect 체인 길이

redirect 체인 길이(2점)는 입력 URL에서 최종 URL까지 거친 리디렉션 홉 수를 셉니다. 검사기는 홉이 2개 이상이면 지적하고, 같은 URL을 다시 만나는 순환은 별도로 표시합니다. 임계값을 1홉으로 둔 것은 리디렉션 자체가 문제가 아니라 그 누적이 문제이기 때문입니다. HTTP에서 HTTPS로 한 번 넘어가는 것은 정상입니다. 그런데 그다음에 www 를 붙이려고 한 번, 끝 슬래시를 붙이려고 또 한 번 넘어가면 세 홉이 됩니다.

세 홉이 생기는 방식은 대체로 우연입니다. 서버 설정에서 HTTPS 강제와 호스트 통일을 각각 따로 규칙으로 두면, 규칙 하나마다 리디렉션이 한 번씩 발생합니다. 여기에 프레임워크의 끝 슬래시 정책이 겹치면 홉이 하나 더 늘어납니다. 각 규칙은 혼자서는 옳지만 합쳐지면 체인이 됩니다. 해결은 규칙을 합쳐 첫 번째 응답에서 바로 최종 URL을 가리키게 하는 것입니다.

순환 리디렉션은 홉 수와 무관하게 심각도가 다릅니다. A가 B로, B가 다시 A로 보내면 최종 응답이 존재하지 않으므로 최종 HTTP 성공 상태도 함께 실패합니다. 이 경우 두 항목이 동시에 빨간색으로 나오는데, 원인은 하나이므로 리디렉션 규칙만 고치면 둘 다 해결됩니다.

응답 시간

응답 시간(1점)은 검사기가 요청을 보내고 최종 응답을 받기까지 걸린 시간을 잽니다. 이 카테고리에서 가장 낮은 배점 중 하나이며, 그 이유를 명확히 해 두어야 합니다. 이 값은 검사기가 한 번 관측한 수치입니다. 검사기 서버의 위치, 그 순간의 네트워크 상태, 대상 서버의 캐시 상태에 따라 같은 페이지도 결과가 달라집니다. 한 번의 관측에 높은 점수를 걸면 검사 결과가 운에 따라 흔들리게 됩니다.

이 항목을 Core Web Vitals의 대체값으로 읽지 않으셨으면 합니다. LCP, INP, CLS는 실제 사용자의 브라우저에서 측정되는 값이고, 응답 시간은 서버가 문서를 내놓기 시작한 시점까지만 봅니다. 응답 시간이 짧아도 렌더링이 느릴 수 있고, 응답 시간이 길어도 화면 표시는 빠를 수 있습니다. 다만 응답 시간이 수 초에 이르면 그 뒤의 모든 단계가 늦어지므로, 이 항목은 뒤의 문제를 가리키는 첫 신호로 쓰는 것이 알맞습니다.

느린 응답이 반복된다면 순서대로 확인할 것은 세 가지입니다. 페이지 캐시가 적용되는지, CDN이 이 경로를 캐시하는지, 그리고 서버 사이드 렌더링이 요청마다 무거운 데이터베이스 조회를 하는지입니다. 대부분의 경우 셋 중 하나에서 원인이 나옵니다.

3단계, 받은 문서가 HTML로 읽히는가

HTML Content-Type

HTML Content-Type(2점)은 응답 헤더의 Content-Type 이 text/html 로 시작하는지 봅니다. 배점이 2점인 것은 이 문제가 드물지만 발생하면 결과가 극단적이기 때문입니다. 브라우저와 크롤러는 확장자가 아니라 이 헤더로 문서 종류를 판단합니다. text/plain 으로 응답하면 HTML 태그가 그대로 글자로 표시되고, application/octet-stream 이면 다운로드 파일로 취급됩니다. 어느 쪽이든 문서로 파싱되지 않으므로 나머지 항목들을 검사할 대상 자체가 사라집니다.

실무에서 이 문제가 나타나는 곳은 정적 파일 호스팅과 프록시 설정입니다. 확장자 없는 경로를 정적 파일로 서빙하면 호스팅 서비스가 MIME 타입을 추측하지 못해 기본값을 내보내는 일이 있습니다. 또 한 가지는 이 항목이 헤더의 charset 부분까지 함께 보므로, text/html 은 맞는데 charset 이 빠졌거나 euc-kr 로 남아 있는 경우도 지적 대상이 됩니다. 후자는 다음 항목인 charset 선언과 함께 읽어야 합니다.

viewport 선언

viewport 선언(2점)은 <head> 안에 <meta name="viewport"> 가 있는지 확인합니다. 이 선언이 없으면 모바일 브라우저는 페이지를 데스크톱 폭으로 그린 뒤 축소해서 보여 줍니다. 글자는 작아지고 사용자는 확대와 좌우 스크롤을 반복하게 됩니다. Google이 모바일 버전을 기준으로 색인하는 지금, 이 선언의 부재는 모바일에서 읽을 수 없는 페이지를 대표본으로 제출하는 것과 같습니다.

배점이 2점인 이유는 이 문제가 색인을 막지는 않되 모바일 사용성 판정에 직접 영향을 주기 때문입니다. 반응형 CSS를 아무리 잘 짜도 viewport 선언이 없으면 미디어 쿼리가 의도한 폭에서 동작하지 않습니다. 실무에서 이 항목이 틀리는 경우는 대부분 오래된 템플릿을 그대로 쓰거나, 프레임워크의 기본 레이아웃을 교체하면서 <head> 의 기본 메타를 함께 지운 경우입니다.

검사기는 선언의 존재와 width=device-width 포함 여부를 봅니다. user-scalable=no 나 maximum-scale=1 로 확대를 막는 값은 이 항목의 판정에 포함하지 않지만, 접근성 관점에서는 피하는 것이 좋습니다.

charset 선언

charset 선언(1점)은 <head> 안의 <meta charset> 또는 http-equiv="Content-Type" 선언을 찾고, 응답 헤더의 charset 과 같은지 비교합니다. 1점인 이유는 이 문제가 실제로는 헤더 쪽 charset 으로 대부분 해결되기 때문입니다. 헤더에 charset=utf-8 이 있으면 HTML 안의 선언이 없어도 브라우저는 올바르게 디코딩합니다. 그래서 이 항목은 헤더가 없거나 어긋날 때를 대비한 이중 안전장치의 성격입니다.

다만 한국어 사이트에서는 이 1점의 무게가 다르게 느껴질 수 있습니다. 영문 페이지는 인코딩이 틀려도 대부분 읽히지만, 한글은 인코딩이 어긋나는 순간 전체가 깨집니다. 검색엔진이 텍스트를 잘못 추출하면 제목, 본문, 구조화 데이터의 검사 결과도 모두 엉뚱하게 나옵니다. 오래된 사이트를 UTF-8로 옮기면서 HTML 선언만 바꾸고 서버 헤더는 euc-kr 로 남겨 두는 실수가 가장 흔하며, 이때 헤더와 메타가 충돌하면 브라우저는 헤더를 따릅니다.

선언 위치도 봅니다. <meta charset> 은 <head> 의 첫 1024바이트 안에 있어야 파서가 문서를 다시 읽지 않습니다. <title> 이나 스크립트 뒤에 두면 선언은 있어도 늦은 선언입니다.

html lang 선언

html lang 선언(1점)은 <html> 요소에 lang 속성이 있고 그 값이 BCP 47 형식인지 봅니다. 1점인 이유는 이 선언이 색인이나 순위를 직접 바꾸는 신호가 아니기 때문입니다. Google은 페이지 언어를 본문에서 스스로 판별하며 lang 값을 결정적 근거로 쓰지 않습니다. 그럼에도 이 항목을 둔 것은 스크린 리더의 발음 선택, 브라우저의 번역 제안, 그리고 일부 검색엔진과 AI 크롤러의 언어별 처리에 이 값이 참고되기 때문입니다.

틀리는 방식은 두 가지입니다. 하나는 템플릿 기본값인 lang="en" 이 한국어 페이지에 그대로 남아 있는 경우입니다. 이 경우 스크린 리더가 한국어 본문을 영어 규칙으로 읽으려 합니다. 다른 하나는 lang="kr" 처럼 국가 코드를 언어 코드 자리에 쓰는 경우입니다. 한국어의 언어 코드는 ko 이고, 지역을 붙이려면 ko-KR 입니다. kr 은 어떤 언어도 가리키지 않습니다.

첫 화면 이미지 지연 로딩

첫 화면 이미지 지연 로딩은 점수 미반영 진단입니다. 문서의 첫 <img>에 loading="lazy"가 있으면 개선 권장, 이미지가 없으면 해당 없음, 그 외에는 통과입니다.

문서 순서의 첫 이미지가 실제 첫 화면이나 LCP 이미지라는 뜻은 아닙니다. 로고일 수도 있고 CSS로 아래쪽에 배치된 이미지일 수도 있습니다. web.dev는 첫 화면 이미지, 특히 LCP 이미지의 지연 로딩을 피하라고 안내하지만, 검사기는 브라우저 렌더링이나 LCP를 측정하지 않으므로 이 신호에 점수를 배정하지 않습니다. 브라우저 이미지 지연 로딩 안내

이 진단은 첫 이미지의 loading 속성만 봅니다. 중요 이미지의 우선순위를 높이는 fetchpriority나 레이아웃 이동을 줄이는 width·height는 별도의 성능 수단이지만 판정에는 포함하지 않습니다. 리소스 우선순위 안내, 레이아웃 이동 최적화 안내

이 검사가 확인하지 못하는 것

정직하게 범위를 밝힙니다.

• 페이지 하나와 보조 경로만 확인합니다. 없는 URL 탐침도 무작위 경로 한 개만 보며, 리디렉션을 따라가지 않습니다. robots.txt·sitemap·llms.txt를 포함한 전체 요청은 리디렉션까지 최대 6회입니다. 한도를 소진한 항목은 확인 불가입니다.
• 초기 HTML 기준입니다. JavaScript를 실행하지 않으므로, 스크립트가 나중에 삽입하는 <meta> 태그나 클라이언트에서 수행하는 리디렉션은 보이지 않습니다. 메타 refresh도 따라가지 않습니다.
• 검사기의 관측 조건에 종속됩니다. 응답 시간은 검사기 서버의 위치와 그 순간의 상태에 좌우되며, 봇 차단 정책이 검사기의 요청을 다르게 처리하면 상태 코드도 브라우저와 다를 수 있습니다.
• HTTPS의 품질은 보지 않습니다. scheme이 https 인지만 확인하고, 인증서의 유효 기간, 체인의 완전성, TLS 버전, HSTS 적용 여부는 검사하지 않습니다.
• 모바일 렌더링 결과를 보지 않습니다. viewport 선언의 존재는 확인하지만, 실제 모바일 화면에서 요소가 잘리거나 겹치는지는 알 수 없습니다.
• 판정은 애드브랜치의 우선순위입니다. 배점과 심각도, 임계값은 이 검사기가 정한 기준입니다. Google이나 네이버, AI 검색엔진이 같은 항목을 같은 무게로 보는 것은 아니며, 이 검사를 모두 통과했다고 해서 색인이나 순위가 약속되지는 않습니다.

이어서 읽기

항목별 수정 방법과 코드 예시는 옆의 표에 정리돼 있습니다. 기술 항목을 사이트 전체 관점에서 점검하려면 SEO 체크리스트를, 대표 URL과 리디렉션 정책을 설계하려면 canonical URL 설정 가이드를 함께 읽어 보세요.