HTTPS로 바꾸면 검색 순위가 오르나요?

HTTPS는 구글이 쓰는 순위 신호지만 비중이 크지 않아 그것만으로 순위가 크게 오르지는 않습니다. 대신 브라우저의 「주의 요함」 경고와 이탈을 막고, 다른 SEO 작업의 전제 조건이 됩니다.

무료 인증서(Let's Encrypt)를 쓰면 SEO에 불리한가요?

불리하지 않습니다. 구글은 인증서 종류(DV·OV·EV)에 따라 순위를 달리하지 않으며, 인증서가 유효하고 제때 갱신되는지가 중요합니다.

보안 헤더가 없으면 순위가 떨어지나요?

보안 헤더 자체는 순위 요소가 아닙니다. 다만 해킹으로 스팸 페이지나 악성 코드가 심기면 검색 결과 경고와 수동 조치로 유입이 급감할 수 있어, 예방 차원에서 기본 헤더를 설정해 두는 것이 좋습니다.

HSTS preload는 꼭 신청해야 하나요?

필수는 아닙니다. preload 목록에 오르면 모든 하위 도메인이 HTTPS로만 열리고 목록에서 빠지는 데도 오래 걸리므로, 모든 하위 도메인이 HTTPS로 운영되는지 확인한 뒤 신청하세요.

인증서가 만료되면 어떻게 되나요?

브라우저가 「연결이 비공개로 설정되어 있지 않습니다」 경고를 띄워 방문자 대부분이 떠나고, 검색 결과에서 클릭한 사람도 같은 경고를 보게 됩니다. 자동 갱신과 만료 모니터링을 함께 설정해 두세요.

HTTPS·보안 헤더와 SEO — SSL 자동 갱신·HSTS·혼합 콘텐츠·Nginx 설정 가이드

HTTPS는 구글이 2014년부터 순위 신호로 쓰는 기본 요건이며, 크롬은 HTTP 페이지에 「주의 요함」을 표시합니다. 제대로 갖추려면 자동 갱신되는 인증서, 모든 HTTP 요청을 HTTPS로 보내는 301, HSTS, 혼합 콘텐츠 제거, 기본 보안 헤더, 서버 버전 숨기기까지 챙겨야 합니다. 대부분은 서버 설정 몇 줄로 끝납니다.

HTTPS와 보안 헤더는 SEO에 얼마나 중요한가요?

HTTPS 자체의 순위 가산점은 크지 않습니다. 그러나 HTTP 사이트는 방문자에게 경고가 보이고, 크롬은 2026년 10월 크롬 154부터 공개 HTTP 사이트에 접속하기 전 경고를 띄우는 「항상 보안 연결 사용」을 기본으로 켜겠다고 2025년에 발표했습니다. 경고 화면은 곧 이탈입니다.

보안 헤더는 순위 요소가 아니지만 해킹을 막는 방어선입니다. 해킹된 사이트에 스팸 페이지가 대량으로 생기거나 악성 코드가 심기면 서치 콘솔 「보안 문제」 보고서에 기록되고, 검색 결과와 브라우저에 위험 경고가 붙어 유입이 급감합니다.

SSL 인증서는 어떻게 발급하고 자동 갱신하나요?

Let's Encrypt 같은 무료 인증서로 충분합니다. 중요한 것은 갱신 자동화입니다. CA/브라우저 포럼 결정에 따라 공인 인증서의 최대 유효기간은 2026년 3월부터 200일로 줄었고, 2029년에는 47일까지 단계적으로 짧아집니다. 사람이 달력을 보고 갱신하는 방식은 더 이상 버티기 어렵습니다.

# 인증서 발급과 Nginx 설정 반영
sudo certbot --nginx -d example.com -d www.example.com

# 자동 갱신이 제대로 동작하는지 모의 테스트
sudo certbot renew --dry-run

# 패키지 설치 시 등록되는 갱신 타이머 확인
systemctl list-timers | grep certbot

Let's Encrypt는 2025년에 만료 안내 이메일을 중단했으므로 만료일은 따로 모니터링해야 합니다. Cloudflare를 쓴다면 SSL/TLS 암호화 설정을 Full (strict) 모드로 두고 원본 서버에도 유효한 인증서를 설치하세요. Flexible 모드는 방문자와 Cloudflare 사이만 암호화하고 리디렉션 루프의 원인이 되기도 합니다.

HTTP를 HTTPS로 어떻게 옮기나요?

모든 HTTP 요청을 한 번의 301로 최종 HTTPS 주소에 보내고, 사이트 안의 주소도 모두 HTTPS로 바꿉니다.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

canonical, 내부 링크, 사이트맵, hreflang의 주소를 https://로 바꿨다
서치 콘솔은 http·https·www를 모두 포함하는 도메인 속성으로 등록했다
네이버 서치어드바이저에 https 주소로 사이트맵을 다시 제출했다
리디렉션이 302가 아닌 301이며 체인 없이 1단계로 끝난다

리디렉션 체인과 루프 점검은 크롤링 오류·리디렉션 가이드를, 대표 주소 지정은 canonical 가이드를 참고하세요.

HSTS는 어떻게 설정하나요?

HSTS(Strict-Transport-Security)는 브라우저에게 「이 사이트는 앞으로 HTTPS로만 접속하라」고 알리는 헤더입니다. 사용자가 http://로 입력해도 브라우저가 서버에 묻기 전에 HTTPS로 바꾸므로 첫 요청을 가로채는 공격을 막고 리디렉션 한 번도 줄입니다.

max-age는 최소 6개월(15768000초) 이상, 일반적으로 1년(31536000초)을 씁니다.
처음 도입할 때는 max-age=300처럼 짧게 시작해 문제가 없으면 늘립니다. 한 번 받은 브라우저는 기간 동안 HTTP 접속을 허용하지 않기 때문입니다.
includeSubDomains는 모든 하위 도메인이 HTTPS일 때만 붙입니다. 사내 시스템이나 오래된 서브도메인이 HTTP라면 접속이 막힙니다.
HSTS 헤더는 HTTPS 응답에서만 효력이 있습니다.

혼합 콘텐츠는 어떻게 찾고 고치나요?

혼합 콘텐츠는 HTTPS 페이지가 http://로 시작하는 이미지·스크립트·CSS를 불러오는 상태입니다. 최신 브라우저는 이미지 같은 리소스를 HTTPS로 자동 전환해 보고, 실패하면 차단합니다. 스크립트·iframe은 곧바로 차단되어 기능이 깨지고 자물쇠 표시도 사라집니다.

크롬 개발자 도구(F12) 콘솔에서 「Mixed Content」 경고를 확인합니다.
템플릿, 게시판 에디터 본문, DB에 저장된 http:// 주소를 https://나 상대 경로로 바꿉니다. 워드프레스는 WP-CLI의 search-replace 명령으로 DB 주소를 한 번에 바꿀 수 있습니다.
HTTPS를 지원하지 않는 외부 위젯은 교체합니다.

임시 방편으로 Content-Security-Policy: upgrade-insecure-requests 헤더나 Cloudflare의 Automatic HTTPS Rewrites를 쓸 수 있지만, 원본 주소를 고치는 것이 근본 해결입니다.

보안 헤더는 무엇을 어떻게 넣나요?

헤더	역할	권장 값
Content-Security-Policy	허용한 출처의 스크립트·리소스만 실행 (XSS 완화)	사이트별 맞춤
X-Content-Type-Options	파일 형식 추측(MIME 스니핑) 금지	`nosniff`
X-Frame-Options	다른 사이트가 iframe으로 감싸는 클릭재킹 방지	`SAMEORIGIN`
Referrer-Policy	다른 사이트로 넘기는 주소 정보 제한	`strict-origin-when-cross-origin`
Permissions-Policy	카메라·마이크·위치 등 브라우저 기능 사용 제한	쓰지 않는 기능만 차단

Nginx에서는 공통 파일로 만들어 server 블록에 include합니다.

# /etc/nginx/snippets/security-headers.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
# CSP는 Report-Only로 먼저 위반 내역만 확인한 뒤 적용
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; frame-ancestors 'self'" always;

CSP는 분석 도구, 광고 픽셀, 지도, 결제 모듈 등 외부 도메인을 빠뜨리면 기능이 깨집니다. 브라우저 콘솔의 위반 내역을 보며 목록을 채운 뒤 Content-Security-Policy로 전환합니다.
지도에서 「내 위치」를 쓴다면 Permissions-Policy에서 geolocation을 차단하지 마세요.
X-XSS-Protection은 폐기된 헤더이므로 새로 넣지 않습니다.
Nginx는 location 블록 안에 add_header가 하나라도 있으면 상위 블록의 헤더를 물려받지 않습니다. 캐시 헤더를 추가한 location에도 include를 다시 넣으세요.

서버 버전 노출은 왜 숨겨야 하나요?

응답 헤더에 Server: nginx/1.24.0이나 X-Powered-By: PHP/8.2.12처럼 버전이 보이면, 공격자가 해당 버전의 알려진 취약점을 골라 시도하기 쉬워집니다. 숨긴다고 취약점이 사라지지는 않으므로 업데이트가 우선이지만, 불필요한 정보는 내보내지 않는 것이 기본입니다.

Nginx: http 블록에 server_tokens off;
PHP: php.ini에 expose_php = Off
Apache: ServerTokens Prod와 ServerSignature Off

설정 후 curl -sI https://www.example.com으로 응답 헤더에 버전 숫자가 남아 있지 않은지 확인합니다.

SEO Check에서는 이렇게 점검합니다

무료 SEO 진단은 HTTPS 접속, http://의 301 이동, www와 non-www 주소 통일, 리디렉션 단계(1단계 이내)를 확인합니다.

정밀진단 리포트는 보안 항목을 더 깊게 봅니다.

인증서: 만료일까지 남은 기간과 TLS 버전(1.2 이상)
HSTS: 헤더 존재와 max-age 6개월 이상 여부
보안 헤더: CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy 설정 여부
혼합 콘텐츠: HTTPS 페이지 안의 http:// 리소스
버전 노출: Server·X-Powered-By 헤더의 버전 정보

서버·보안 설정 전반은 전자책 PART 5. 기술적 SEO에서 더 자세히 다룹니다.