주소창에 자물쇠가 보여도 상품 이미지, 예약 위젯, 문의폼, 분석 스크립트가 http://로 불리면 페이지 일부는 보호되지 않거나 브라우저에서 차단될 수 있다. 2026년 9월 9일 web.dev와 Chrome 공식 문서를 확인하면 혼합 콘텐츠는 페이지별로 찾아 원본 주소에서 고쳐야 하며, Security 패널에서 비보안 출처와 인증서를 확인할 수 있다. 광고 심사를 의식해 문구만 늘리기보다 고객이 실제로 이용하는 동선을 안전하게 만드는 것이 먼저다.
핵심 요약: 고객 동선 여섯 곳을 7단계로 점검한다
① 대표 동선을 고른다 ② 비보안 요청을 기록한다 ③ 요청 비율과 위험도를 함께 매긴다 ④ 원본을 HTTPS로 교체한다 ⑤ 주소 체계를 한 번에 통일한다 ⑥ 문의·결제 기능을 실제로 시험한다 ⑦ 배포 후 모바일과 인증서를 재확인한다. 홈페이지 첫 화면만 통과했다고 끝내지 말고 상품·예약·문의·결제·정책 페이지까지 같은 방식으로 본다.
1. 대표 고객 동선과 검사 URL을 먼저 정한다
홈, 인기 상품 또는 서비스, 예약, 문의, 결제 직전, 개인정보처리방침 등 여섯 URL을 검사표에 적는다. 로그인하지 않은 시크릿 창과 실제 휴대전화에서 각 페이지를 열고 이미지·지도·채팅·영상·버튼이 나타나는지 본다. 관리자 화면만 확인하면 일반 고객에게만 적용되는 광고나 외부 위젯을 놓칠 수 있다. 결제 기능이 없다면 매장 위치나 전화 연결처럼 사업의 핵심 완료 행동으로 바꾼다.
2. 비보안 요청을 기능별로 분류한다
Chrome 개발자도구의 개인정보 보호 및 보안 패널에서 비보안 출처를 열고 Network 요청으로 이동한다. 스크립트·스타일·iframe처럼 기능을 실행하는 자원, 이미지·영상 같은 표시 자원, 폼 전송 주소, 일반 외부 링크로 나눈다. 일반 링크의 http://가 항상 혼합 콘텐츠인 것은 아니지만 갤러리 스크립트가 그 주소를 화면 안에 불러오면 문제가 될 수 있다. 발견 페이지, 요청 주소, 자원 유형, 담당자를 한 줄씩 기록한다.
3. 비율과 고객 영향으로 수정 순서를 정한다
내부 점검용으로 ‘HTTP 요청 수 ÷ 전체 자원 요청 수 × 100’을 계산한다. 한 페이지의 140개 요청 중 7개가 HTTP라면 5%다. 이는 Google 점수나 순위 기준이 아니라 재검사 때 누락을 비교하기 위한 수치다. 요청 수가 한 개뿐이어도 결제 iframe, 문의폼 action, 예약 스크립트처럼 고객 행동을 맡으면 최우선으로 고친다. 반대로 사용하지 않는 오래된 장식 이미지는 교체보다 삭제가 빠를 수 있다.
4. 자동 전환에 기대지 말고 원본 주소를 교체한다
브라우저가 일부 요청을 자동으로 HTTPS로 올려 보내더라도 CMS 본문, 테마, 태그 관리자, 외부 위젯 설정에 남은 http://를 직접 바꾼다. 새 주소를 별도 탭에서 열어 200 응답과 올바른 파일인지 확인한다. 제공처가 HTTPS를 지원하지 않으면 신뢰할 수 있는 대체 서비스로 바꾸거나, 저작권과 이용 조건이 허용될 때만 직접 호스팅하거나, 기능을 제거한다. 주소 앞 글자만 바꾼 뒤 깨진 자원을 그대로 공개하지 않는다.
5. 대표주소·내부링크·사이트맵을 HTTPS로 맞춘다
http 주소가 들어오면 같은 경로의 https 주소로 한 번에 이동하도록 영구 리디렉션을 설정한다. canonical, 메뉴와 본문 내부링크, RSS, 사이트맵, 구조화 데이터, 광고·SNS 랜딩 주소도 최종 HTTPS URL로 맞춘다. http→임시주소→https처럼 여러 번 거치면 원인 추적이 어려워진다. 단, 다른 상품이나 홈으로 무조건 보내지 말고 대응 페이지가 없으면 기존 404·삭제 URL 원칙에 따라 처리한다.
6. 문의·예약·결제는 전송까지 직접 시험한다
문의폼의 action, 파일 업로드, 예약 달력, 결제창, 채팅 iframe을 열어 테스트 정보로 완료 직전까지 진행한다. 전송 대상이 HTTPS인지, 차단된 스크립트 때문에 버튼이 멈추지 않는지, 완료·오류 안내가 보이는지 확인한다. 실고객 개인정보나 카드정보로 시험하지 말고 테스트 계정과 비식별 값을 사용한다. 외부 서비스의 인증서 오류나 비보안 전송이 보이면 기능을 임시로 숨기고 제공업체 확인 전에는 공개하지 않는다.
7. 배포 뒤 캐시·모바일·인증서를 다시 본다
수정 후 캐시와 CDN을 갱신하고 여섯 URL을 다시 연다. Console의 mixed content 경고, Security 패널의 출처·인증서, Network의 차단 요청을 확인하고 안드로이드와 iPhone 중 가능한 실제 기기에서도 예약·문의 버튼을 누른다. 인증서의 대상 도메인과 만료일, www 유무, 오래된 하위도메인도 기록한다. 경고가 사라졌더라도 주 1회 자동 점검만 믿지 말고 새 위젯이나 캠페인 랜딩을 추가할 때 검사표를 다시 사용한다.
45분 실행표와 공개 중단 조건
첫 10분은 여섯 URL과 고객 완료 행동을 정하고, 다음 10분은 Security·Network·Console에서 비보안 요청을 기록한다. 이어 15분은 우선순위가 높은 원본 주소와 내부링크를 고치고, 마지막 10분은 시크릿 창과 휴대전화에서 문의·예약 흐름을 재검사한다. 인증서가 만료됐거나, 핵심 스크립트가 차단되거나, 폼이 HTTP로 전송되거나, 대체 자원의 권리를 확인할 수 없거나, 수정 후 버튼이 멈추면 공개를 중단한다. 이 점검은 검색 노출·매출·애드센스 승인을 보장하지 않는다.