주소창에 자물쇠가 보이면 안심이 됩니다. 그런데 그 자물쇠 뒤에서 일부 파일이 몰래 예전 방식으로 배달되고 있다면 어떨까요?
이것이 바로 혼합 콘텐츠 문제입니다. 겉으로는 안전한 HTTPS 사이트처럼 보이지만, 이미지 하나나 글꼴 하나가 HTTP로 불리면 웹페이지 안에 작은 열린 창문이 생깁니다.
자물쇠가 있다고 모두 안전한 것은 아닙니다
HTTPS는 웹사이트와 방문자 사이의 통신을 암호화하는 방식입니다. 누군가 중간에서 내용을 훔쳐보거나 바꾸기 어렵게 만드는 일종의 봉인된 택배 상자입니다.
문제는 상자 안에 HTTP로 가져온 자료가 섞일 때 생깁니다. 페이지 본문은 HTTPS로 열렸는데, 사진은 HTTP 주소에서 가져왔다면 한 페이지 안에 안전한 통로와 낡은 통로가 함께 놓인 셈입니다.
이 상태를 혼합 콘텐츠라고 부릅니다. MDN에 따르면 공격자는 HTTP로 전달되는 자료를 엿보거나 바꿀 수 있고, 특히 실행 파일은 페이지의 동작 자체를 바꿀 위험이 있습니다.
예를 들어 로그인 화면의 모양을 만드는 파일이 HTTP로 불리면, 단순히 디자인이 깨지는 데서 끝나지 않을 수 있습니다. 나쁜 사람이 그 파일을 바꾸어 가짜 로그인 창을 끼워 넣을 가능성도 생깁니다.
사진 하나는 괜찮고, 프로그램 하나는 왜 다를까요?
브라우저는 모든 HTTP 자료를 똑같이 다루지 않습니다. 이미지나 영상처럼 비교적 수동적인 자료는 HTTPS로 자동 변경해 불러오기도 합니다.
반면 자바스크립트, 스타일 파일, 글꼴, 프레임, 일부 요청처럼 페이지를 움직이거나 내용을 바꿀 수 있는 자료는 대개 차단됩니다. 브라우저가 웹사이트의 경비원처럼 “이건 들여보내면 곤란하겠는데요”라고 판단하는 것입니다.
자동 변경이 된다고 해서 문제를 방치해도 된다는 뜻은 아닙니다. 원래 HTTPS로 제공되어야 할 자료가 HTTP에 남아 있다는 사실 자체가 사이트 관리가 덜 끝났다는 신호이기 때문입니다.
서치콘솔의 HTTPS 보고서는 무엇을 검사할까요?
구글 서치콘솔의 HTTPS 보고서는 사이트에서 색인된 주소 가운데 HTTP와 HTTPS가 각각 얼마나 있는지 보여줍니다. 여기서 중요한 점은 모든 문제를 낱낱이 보여주는 검사표가 아니라, 상태를 판단하는 표본 보고서라는 점입니다.
구글은 HTTP 주소를 하나씩 살펴본 뒤, 같은 구조의 HTTPS 주소가 있는지 확인합니다. 그 HTTPS 주소가 색인될 수 없는 이유가 있으면 보고서에 문제 유형을 표시합니다.
따라서 HTTP 주소가 보고서에 보인다고 해서 곧바로 “이 페이지는 검색에서 사라졌다”는 뜻은 아닙니다. 다만 구글이 HTTPS 버전을 제대로 찾거나 믿지 못하고 있다는 뜻일 수 있어, 중요한 페이지부터 확인해야 합니다.
보고서에 자주 나오는 경고의 뜻
- 인증서 문제: HTTPS 인증서가 만료됐거나 주소와 맞지 않습니다.
- 사이트맵이 HTTP를 가리킴: 검색 로봇에게 옛 주소를 계속 안내하고 있습니다.
- HTTPS가 HTTP로 되돌아감: 안전한 주소로 갔는데 다시 불안전한 주소로 이동합니다.
- 로봇 차단: robots.txt가 HTTPS 페이지의 접근을 막고 있습니다.
- HTTPS 확인 안 됨: 페이지가 없거나 오류가 많아 아직 판단하지 못한 상태입니다.
구글은 다른 문제가 먼저 해결되면 ‘HTTPS 확인 안 됨’ 상태도 자연스럽게 풀릴 수 있다고 안내합니다. 그래서 숫자 하나를 보고 무작정 기다리기보다, 인증서와 오류 응답, 리디렉션부터 살피는 편이 빠릅니다.
실제로 사이트 운영자가 막히는 지점은 따로 있습니다
혼합 콘텐츠 문제는 대개 홈페이지 첫 화면에서 발견되지 않습니다. 오래된 글 속 이미지, 예전에 넣은 동영상, 외부 광고, 배경 그림, 댓글에 들어간 링크처럼 구석구석 숨어 있습니다.
관리자가 주소창만 보고 “자물쇠가 있네”라고 안심하는 동안, 방문자의 브라우저는 파일 몇 개를 조용히 차단할 수 있습니다. 결과적으로 버튼이 작동하지 않거나, 글꼴이 달라지거나, 사진 일부가 빈칸으로 보일 수 있습니다.
더 골치 아픈 경우도 있습니다. 화면에는 멀쩡해 보여도 브라우저 개발자 도구에는 HTTP 요청 경고가 남아 있을 수 있습니다. 방문자의 브라우저 종류나 인터넷 환경에 따라 문제가 다르게 나타나기 때문에, 운영자 컴퓨터에서는 정상인데 다른 사람에게만 고장 나는 일이 생깁니다.
직접 고칠 때 생기는 한계
가장 흔한 방법은 사이트 안의 찾아 바꾸는 것입니다. 하지만 단순 검색만으로는 데이터베이스에 저장된 주소, CSS 안의 주소, 자바스크립트가 조립하는 주소, 외부 서비스의 설정까지 모두 잡아내기 어렵습니다.
또한 모든 HTTP 주소를 기계적으로 HTTPS로 바꾸면 안 됩니다. 상대 사이트가 HTTPS를 지원하지 않거나, 주소를 바꾼 뒤 파일이 없어질 수도 있습니다. 낡은 주소를 새 주소로 바꾸는 일은 이사와 비슷해서, 상자에 이름표만 새로 붙인다고 물건이 제자리에 도착하지는 않습니다.
사이트 규모가 커질수록 사람이 하나씩 확인하는 방식은 빠르게 한계에 부딪힙니다. 수십 개 페이지는 가능하지만, 수백 개의 글과 수천 개의 이미지가 있다면 누락 여부를 기억하는 것만으로도 머리가 작은 서버처럼 과열됩니다.
페이지와 자료를 사람이 계속 훑어야 하는 사이트라면, 먼저 주소 오류와 검색 관련 관리 항목을 한곳에서 좁혀 보는 편이 현실적입니다. SOHO SEO의 Redirects는 404 발생을 기록하고 301, 302, 410 연결과 주소 패턴, 방문 횟수를 관리합니다.
Site Error Check를 켜 두면 robots.txt와 이 플러그인이 제공하는 사이트맵을 확인하고 문제가 있을 때 이메일을 보냅니다. 다만 혼합 콘텐츠의 모든 HTTP 자료를 대신 고치는 기능은 아니므로, 브라우저 콘솔과 소스 확인은 별도로 남습니다.
문제를 찾고 고치는 순서는 이렇게 잡아보세요
먼저 HTTPS 보고서에서 HTTP 주소가 실제로 색인된 페이지인지 확인합니다. 방문자가 많이 들어오는 페이지, 상품이나 문의 페이지, 검색 유입이 중요한 글부터 순서를 정하면 시간을 아낄 수 있습니다.
- HTTPS 인증서가 만료되지 않았는지 확인합니다.
- HTTP 주소가 HTTPS로 제대로 이동하는지 확인합니다.
- 페이지 소스와 브라우저 경고에서 HTTP 자료를 찾습니다.
- 내부 링크와 사이트맵을 HTTPS 주소로 바꿉니다.
- 대표 주소 표시와 외부 서비스 설정을 확인합니다.
- 수정 뒤 주요 페이지를 다시 검사합니다.
구글은 HTTPS 버전을 대표 주소로 명확히 알려야 한다고 설명합니다. 내부 링크, 사이트맵, 다른 사이트에서 연결된 주소가 모두 HTTPS를 가리키면 검색 로봇이 어느 주소를 우선해야 할지 덜 고민합니다.
수정이 끝났다면 브라우저 개발자 도구의 콘솔에서 혼합 콘텐츠 경고가 사라졌는지 봅니다. 이미지가 보이는지만 확인하지 말고, 버튼과 결제창, 로그인, 동영상, 다운로드까지 직접 눌러야 합니다.
자동 변경 기능은 만능 소화기가 아닙니다
서버의 보안 정책에는 HTTP 요청을 HTTPS로 바꾸도록 돕는 설정이 있습니다. 과거 자료가 너무 많아 당장 모든 주소를 고치기 어려울 때 임시 안전망으로 활용할 수 있습니다.
하지만 이 기능은 HTTPS 주소가 실제로 존재하고 정상 작동할 때 의미가 있습니다. 없는 파일을 HTTPS로 바꾸어 부른다고 갑자기 파일이 생기지는 않습니다. 마법 주문을 외웠는데 냉장고에서 피자가 나오지는 않는 것과 같습니다.
궁극적인 해결책은 모든 자료를 HTTPS로 제공하고, 오래된 주소를 새 주소로 정리하는 것입니다. 자동 변경은 정리 작업을 대신하는 기능이 아니라, 정리하는 동안 사고를 줄이는 보조 장치에 가깝습니다.
워드프레스에서 이어서 점검하기: SOHO SEO
HTTPS 보고서에서 확인한 내용을 워드프레스 내부의 관리 항목으로 이어서 살필 때 SOHO SEO를 사용할 수 있습니다. 게시물 편집기 사이드바와 Settings의 Page experience는 HTTPS 상태와 선택적으로 등록한 PageSpeed Insights 키를 이용한 모바일 성능 점수를 확인합니다. 이는 혼합 콘텐츠의 원인을 자동으로 고친다는 뜻이 아니라, HTTPS 관련 상태를 점검하는 보조 지점입니다.
사이트맵과 오류 흐름도 따로 관리할 수 있습니다. Sitemap에서는 일반 XML 사이트맵과 최근 게시물만 담는 Google News 사이트맵을 켜거나 끌 수 있고, Site Error Check에서는 robots.txt와 이 플러그인이 제공하는 사이트맵을 확인합니다. 주소가 바뀌었거나 404가 발생한 뒤에는 Redirects에서 301, 302, 410 연결을 만들고 관련 기록을 관리할 수 있습니다.
HTTPS 보고서는 검색 노출을 위한 건강검진입니다
HTTPS 보고서의 목적은 단순히 초록색 자물쇠를 자랑하게 만드는 데 있지 않습니다. 구글이 페이지를 안정적으로 읽고, 방문자가 중간에 막히지 않도록 주소와 자료의 흐름을 정리하는 데 있습니다.
HTTPS 문제가 해결되면 검색 순위가 반드시 크게 오른다고 단정할 수는 없습니다. 그러나 오류가 줄고 페이지가 제대로 열리면 방문자가 머무르고, 중요한 기능을 사용할 가능성이 높아집니다.
결국 HTTPS는 검색 노출의 만능 치트키가 아니라 기본 체력에 가깝습니다. 운동화 끈이 풀린 채 달리면서 기록 향상을 바라는 것보다, 먼저 끈을 묶는 편이 현명한 이유입니다.
한 달에 한 번이라도 HTTPS 보고서와 주요 페이지를 함께 살펴보세요. 새 글을 올리거나 외부 서비스를 붙인 뒤에는 특히 확인하는 습관이 좋습니다.
자주 묻는 질문
Q. 혼합 콘텐츠가 있으면 페이지가 구글 검색에서 바로 제외되나요?
A. 혼합 콘텐츠 하나만으로 페이지가 즉시 제외된다고 단정할 수는 없습니다. 다만 필요한 자료가 차단되거나 HTTPS 버전을 제대로 확인하지 못하면 사용자 경험과 색인 과정에 문제가 생길 수 있으므로 고치는 편이 안전합니다.
Q. 이미지가 HTTP로 불리는데 화면에 보이면 그냥 둬도 되나요?
A. 브라우저가 이미지를 HTTPS로 자동 변경했을 가능성이 있습니다. 그래도 원본 주소를 HTTPS로 바꾸고 콘솔 경고를 확인해야 하며, 자동 변경에 기대면 나중에 이미지나 환경이 바뀔 때 문제가 다시 나타날 수 있습니다.
Q. HTTPS 보고서의 ‘확인 안 됨’은 얼마나 기다려야 하나요?
A. 새로 발견된 주소라면 구글이 다시 확인하는 데 시간이 걸릴 수 있습니다. 그러나 인증서 오류, 서버 오류, 404 응답, robots.txt 차단이 함께 있다면 기다리기보다 원인부터 해결해야 합니다.
Q. 내 사이트에서 어떤 페이지부터 점검해야 하나요?
A. 검색 유입이 많고 문의나 결제가 일어나는 페이지부터 확인하세요. 이후 오래된 글, 외부 동영상이 있는 글, 템플릿을 여러 페이지가 함께 쓰는 구간을 점검하면 효율적입니다.
Q. 이 문제를 도구로 쉽게 해결할 수 있나요? 어떤 도구를 쓰면 되나요?
A. 사이트 전체 주소를 찾아주는 검사 도구, 브라우저 개발자 도구, 서버 로그, 서치콘솔을 함께 쓰면 빠르게 범위를 좁힐 수 있습니다. 다만 자동으로 주소를 바꾸기 전에 HTTPS로 실제 제공되는 자료인지 사람이 확인해야 합니다.
Q. HTTPS 보고서를 확인한 뒤 워드프레스에서 함께 점검할 항목은 무엇인가요?
A. SOHO SEO의 Page experience에서 HTTPS 상태를 확인하고, Sitemap과 Site Error Check에서 사이트맵과 robots.txt 상태를 이어서 살필 수 있습니다.
주소 오류가 발견되면 Redirects에서 404 기록을 확인하고 301, 302, 410 연결을 관리할 수 있습니다. 혼합 콘텐츠 자체는 브라우저 개발자 도구와 소스 확인으로 별도 점검해야 합니다.
워드프레스 관련 플러그인
