워드프레스에 SSL 인증서를 설치하고 사이트 주소를 https로 변경했음에도 불구하고, 브라우저 상단에 “안전하지 않은 사이트” 경고가 뜨는 경우가 있습니다. 이는 과거 http 시절에 생성된 이미지, 폰트, 링크 경로가 캐시나 별도 저장소에 남아있기 때문입니다.
이를 Mixed Content(혼합 콘텐츠)라고 합니다. 브라우저는 암호화된 https 페이지 안에서 암호화되지 않은 http 데이터를 불러올 때, 보안 위협이 있다고 판단하여 차단하거나 경고합니다. 오늘은 이 문제를 구조적으로 해결하는 방법을 정리해 드립니다.
⚠️ 작업 전 주의사항: 데이터베이스를 직접 수정하는 작업은 사이트 전체에 영향을 줄 수 있습니다. 반드시 호스팅 관리자 페이지에서 전체 데이터베이스와 파일을 백업한 후 진행하시기 바랍니다. aws의 경우 간편하게 스냅샷을 만들어 놓는 것도 좋습니다.
Mixed Content: 경고(Warning) vs 에러(Error) 간단히 알아보기
Mixed Content는 모두 같은 수준의 문제가 아닙니다.
이미지, 폰트, 배경 이미지처럼 화면 표시와 관련된 리소스는 브라우저가 경고(Warning)만 표시하고 계속 불러오는 경우가 많습니다.
반면 JavaScript, CSS, iframe처럼 페이지 동작에 영향을 주는 리소스는 브라우저가 보안상 위험하다고 판단하여 로드를 차단(Error)할 수 있습니다.
따라서 F12 개발자 도구에서 Mixed Content 메시지가 표시된다면 단순 경고인지, 실제로 차단된 에러인지 먼저 확인하는 것이 중요합니다.
Mixed Display Content (경고 – Warning)
대상: 이미지(img), CSS 배경 이미지, 폰트 파일 등 화면 표시와 관련된 리소스
결과: 브라우저는 대부분 해당 리소스를 계속 불러오지만, 개발자 도구(F12)의 Console 탭에 Mixed Content 경고를 표시합니다.
예를 들어 다음과 같은 메시지가 나타날 수 있습니다.
Mixed Content: The page at 'https://example.com'
was loaded over HTTPS, but requested an insecure image
'http://example.com/image.jpg'최근 브라우저는 일부 리소스에 대해 자동으로 HTTPS 업그레이드를 시도하기도 하지만, HTTP 주소가 남아 있는 상태 자태는 바람직하지 않습니다. 또한 브라우저 종류와 버전에 따라 자물쇠 아이콘 표시나 보안 상태 평가에 영향을 줄 수 있습니다.
대표적인 예:
- 이미지 URL이 HTTP로 남아 있는 경우
- 폰트 파일을 HTTP로 불러오는 경우
- CSS 내부의 배경 이미지 경로가 HTTP인 경우
이 경우 사이트가 정상적으로 표시되는 경우가 많지만, 콘솔에는 경고가 계속 남게 됩니다.
Mixed Active Content (에러 – Error)
대상: JavaScript(.js), CSS 스타일시트(.css), iframe 등 페이지의 동작이나 구조에 영향을 주는 리소스
결과: 브라우저는 보안상 위험하다고 판단하여 해당 리소스의 로드를 차단(Block)할 수 있습니다.
이 경우 단순 경고 수준이 아니라 실제 기능 장애가 발생할 수 있으며, 개발자 도구(F12)의 Console 탭에 빨간색 오류 메시지가 표시됩니다.
대표적인 증상:
- 메뉴가 열리지 않음
- 슬라이더가 동작하지 않음
- 팝업 기능이 작동하지 않음
- 특정 CSS가 적용되지 않아 화면이 깨짐
- 외부 콘텐츠가 표시되지 않음
예를 들어 HTTPS 페이지에서 JavaScript 파일을 HTTP로 불러오려고 하면 브라우저가 해당 파일을 차단하고, 그 결과 사이트의 일부 기능이 정상적으로 동작하지 않을 수 있습니다.
mixed content 문제 1. 워드프레스 기존 콘텐츠 주소가 HTTP로 설정됨

브라우저의 [개발자 도구(F12)] → [Console] 탭을 확인하면 보안 경고와 에러 목록이 나옵니다. 원인은 크게 두 가지입니다. 하나는 워드프레스 설정 메뉴의 주소값이 http인 경우, 다른 하나는 DB 내의 컨텐츠 경로가 http로 저장된 경우입니다.
저의 경우에는 워드프레스를 설치하고 테마를 설치한 다음에 ssl을 설치했고 그래서 데이터베이스에 존재하던 모든 http주소가 https로 바뀌지 않았기 때문에 생긴 문제였습니다.
관리자 설정 및 wp-config.php 수정
1. 관리자 대시보드에서 주소 확인하기
가장 먼저 워드프레스 관리자 메뉴의 [설정] > [일반]으로 이동하여 다음 항목을 확인합니다.
- 워드프레스 주소 (URL):
http://domain.com - 사이트 주소 (URL):
http://domain.com
제 경우, SSL 인증서만 설치하고 이 부분을 https로 변경하는 것을 깜빡했었습니다. 시스템은 여전히 http를 기준으로 내부 링크와 리소스 경로를 생성하고 있었기에, 사이트 전체에서 Mixed Content 경고가 쏟아졌던 것입니다.
2. wp-config.php 설정 우선순위 확인
[설정] 메뉴를 수정했음에도 경고가 계속된다면, wp-config.php 파일에 주소 값이 하드코딩되어 있는지 확인해야 합니다. 워드프레스는 설정 메뉴보다 wp-config.php에 정의된 상수를 우선적으로 인식하기 때문입니다.
워드프레스는 사이트 주소(URL)를 기준으로 내부 링크를 생성합니다. 만약 WordPress 주소(URL) 또는 사이트 주소(URL)가 http로 설정되어 있다면 SSL 인증서를 설치했더라도 일부 리소스가 http로 호출될 수 있습니다.
- 확인 방법: SSH나 FTP를 통해 워드프레스 설치 경로의
wp-config.php파일을 엽니다. - 기술적 이유: 만약 아래와 같이
WP_HOME이나WP_SITEURL이http로 정의되어 있다면, 관리자 대시보드에서 설정을 변경해도 실제 시스템은 이를 무시합니다.
define( 'WP_HOME', 'http://domain.com' );
define( 'WP_SITEURL', 'http://domain.com' );3. 시스템 주소 강제 HTTPS 전환
저는 이 문제를 해결하기 위해 해당 코드를 다음과 같이 수정하였습니다. $_SERVER['HTTP_HOST']를 활용하면 도메인 변경 시에도 별도의 코드 수정 없이 자동으로 대응할 수 있습니다.
define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/' );
define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/' );이 과정을 통해 워드프레스 시스템은 사이트의 진정한 주소가 https임을 명확히 인식하게 되었고, 워드프레스가 새로 생성하는 내부 URL은 HTTPS를 기준으로 생성되게 됩니다.
DB 수정
사이트 주소를 https로 변경했더라도, 과거에 작성한 글 본문에 삽입된 이미지나 내부 링크는 데이터베이스에 http:// 형태의 절대 경로로 그대로 저장되어 있습니다. 이 데이터들을 하나씩 수동으로 수정하는 것은 사실상 불가능합니다.
그렇다고 데이터베이스를 직접 SQL로 수정하는 것은 매우 위험합니다. 워드프레스는 데이터베이스에 저장할 때 배열이나 객체 데이터를 ‘직렬화(Serialized Data)’ 형태로 저장하는 경우가 많습니다. 만약 단순 SQL REPLACE() 명령어를 사용해 치환하면, 데이터 내부의 ‘문자열 길이 값’이 일치하지 않게 되어 해당 데이터 전체가 손상(Unserialization 에러)될 수 있습니다.
따라서 안전성과 효율성을 모두 고려하여, 직렬화 데이터를 완벽하게 처리해 주는 전문 플러그인의 도움을 받는 것이 좋습니다.
Better Search Replace 플러그인을 이용한 DB 변환

- 플러그인 설치: 관리자 페이지 [플러그인] > [플러그인 추가] 에서 [
Better Search Replace]를 검색해 설치하고 활성화합니다. - 설정: [관리자 페이지 도구 > Better Search Replace] 메뉴로 이동합니다.
- 입력:
- 검색하기:
http://당신의도메인.com - 다음으로 교체:
https://당신의도메인.com - 테이블 선택: 모든 테이블을 선택합니다.
- 검색하기:
- 테스트 실행으로 실행 (Dry Run): 바로 실행하지 말고, 아래쪽 ‘테스트 실행으로 실행’ 옵션을 반드시 체크한 상태로 실행합니다. 그러면 실제 데이터를 수정하지 않고, 어떤 데이터가 몇 개나 변경될 예정인지 먼저 보고서로 보여줍니다.
- 실제 실행: 테스트 결과에 문제가 없다면 ‘테스트 실행’ 체크를 해제하고, 실제 변환 작업을 수행합니다.
⚠️ 테스트 실행(Dry Run) 결과, 변경 예정 항목이 지나치게 많거나 의심스러운 테이블(예: 로그성 테이블 등)이 포함되어 있다면 다시 한번 검토하세요. 무엇보다 작업 전 호스팅 서버에서 제공하는 데이터베이스 백업 기능을 통해 반드시 전체 백업을 해놓는 것이 좋습니다.
문제2 워드프레스 테마에서 제공하는 폰트가 http로 되어 mixed content 문제가 생김

wp-config.php와 데이터베이스 전체를 https로 전환했음에도 불구하고, 특정 폰트나 스타일 시트에서 여전히 Mixed Content 경고가 발생하는 경우가 있습니다. 이는 테마가 자체적으로 가진 캐싱 및 설정 저장 메커니즘 때문입니다.
일부 테마는 폰트 설정값이나 생성된 CSS 파일을 캐시 형태로 저장합니다.
GeneratePress 폰트 캐시 초기화 방법
[외모(Appearance) > 사용자 정의(Customize) > 타이포그래피(Typography)] 메뉴로 이동

위의 Mixed Content error에 나왔던 폰트들이 있습니다.
폰트 설정 갱신: 문제가 되는 폰트의 ‘>‘ 버튼을 눌러서 설정으로 이동, 다음 절차를 수행합니다.

- Disabled: 폰트 활성화 옵션을 ‘Disabled’로 변경하고 Save 버튼 눌러서 저장.
- Enabled: 다시 ‘Enabled’로 변경한 후 저장(Save)합니다.
- 다른 폰트도 똑같이 반복
- 일부 테마는 폰트 설정을 저장하는 과정에서 CSS 캐시를 다시 생성합니다. 따라서 비활성화 후 다시 활성화하여 저장하면 기존에 남아 있던 http 경로가 https로 재생성되는 경우가 있습니다.
Better Search Replace로 DB를 수정했지만 해결되지 않는 부분

DB 치환 작업을 마쳤음에도 개발자 도구(F12)의 Element 탭을 확인해 보면, og:image와 같은 메타 태그 일부가 여전히 http 경로로 남아있는 경우가 있습니다.
사실 브라우저 콘솔창에 즉각적인 ‘Mixed Content 에러’가 발생하지 않는다면 사이트 로딩에는 당장 문제가 없을 수도 있습니다. 하지만 SNS 공유 시 잘못된 이미지 URL이 사용되거나, SEO 메타데이터의 일관성이 깨질 수 있습니다. 찝찝함을 없애고 시스템을 깔끔하게 유지하기 위해 이 부분도 반드시 정돈할 필요가 있습니다.
Yoast SEO 플러그인이 가지고 있던 데이터
Yoast SEO의 데이터 관리 방식:
Yoast SEO는 SEO 관련 데이터를 효율적으로 관리하기 위해 Indexables라는 자체 색인 테이블을 사용합니다. 이 과정에서 og:image 등의 정보가 별도로 저장될 수 있기 때문에 데이터베이스를 변경하더라도 Yoast SEO 플러그인이 들고있던 고유 테이블까지 완벽히 갱신해주지 못하는 경우가 있습니다.
Yoast Test Helper 활용:
- 1. Yoast Test Helper 플러그인 설치 후 활성화
- 2. [도구 > Yoast Test]에서 [Yoast SEO] 항목 찾기

- 3. [Reset Indexables tables & migrations] 클릭
Reset Indexables 과정은 Yoast SEO가 생성한 색인(Indexables) 데이터를 삭제한 뒤 현재 사이트 상태를 기준으로 다시 생성하는 과정입니다.
수정 완료됨.
SEO 데이터 최적화 시작하기

yoast 테이블을 초기화 했으니 다시 [Yoast SEO > 도구 > SEO데이터 최적화 시작하기]를 해줘야 합니다.
고유주소 규칙 갱신
설정 – 고유주소 – 변경 사항 저장(다른 것 아무것도 건드릴 필요 없음)
워드프레스의 고유 주소 체계나 플러그인 데이터에 변화가 생기면, 서버의 페이지 경로 안내 역할을 하는 .htaccess 파일이나 주소 규칙 Rewrite Rules가 꼬일 수 있습니다. 실제로 Mixed Content 문제 자체를 해결하는 단계는 아니지만, 대규모 URL 변경 작업 이후에는 함께 수행해 두는 것이 좋습니다. (워드프레스는 내부적으로 Rewrite Rules를 사용해 URL을 처리합니다. 플러그인이나 설정 변경 이후에는 해당 규칙을 다시 생성해야 정상 동작하는 경우가 있습니다.)
아무것도 건드리지 않고 변경 사항 저장만 눌러줘도 워드프레스 시스템에게 고유주소 규칙을 최신 상태로 갱신하라고 명령을 하게 됩니다.




