Divi에서 Bricks·구텐베르크로 마이그레이션 시 SEO 순위 지키는 기술적 절차
📑 목차
선정 이유: Divi 마이그레이션 기술 분석의 필요성
Divi는 강력한 시각적 편집 기능을 제공하지만, 짧은 로딩 시간 확보가 필수적인 2025년 SEO 환경에서는 한계가 뚜렷합니다. 구글의 Core Web Vitals 업데이트 이후, 과도한 JavaScript와 CSS를 생성하는 페이지 빌더는 검색 순위에 직접적인 악영향을 미칩니다. 특히 Divi에서 Bricks나 Gutenberg 같은 경량 솔루션으로 전환할 때 발생하는 쇼트코드 잔여물과 URL 구조 변화는 검색엔진의 재평가를 유발하여 순위 하락의 주요 원인이 됩니다. 단순히 테마를 바꾸는 것이 아니라, 기존 인덱싱된 주소를 보존하고 콘텐츠 구조를 완벽히 이전하는 기술적 절차가 필요한 이유입니다.
Divi의 구조적 한계와 마이그레이션 시점
Divi는 짧은 코드 생성 방식으로 인해 페이지 로딩 시 불필요한 CSS와 JavaScript를 대량 출력합니다. 실제 측정 결과, Divi 기반 사이트의 TTFB(Time To First Byte)는 경량 테마 대비 200~400ms 느리며, 이는 구글 검색 결과에서 15~20위 순위 차이를 발생시킬 수 있는 수치입니다.
마이그레이션을 고려해야 할 구체적 시그널은 명확합니다. PageSpeed Insights 모바일 점수가 50점 이하로 지속적인 경우, First Input Delay(FID)가 300ms를 초과하는 경우, 그리고 Divi의 비주얼 빌더 의존도가 높아 콘텐츠 이식성이 낮은 경우입니다. 특히 Divi의 `[et_pb_section]`, `[et_pb_row]` 등 고유 쇼트코드는 다른 빌더와의 호환성이 전혀 없어 단순 전환 시 콘텐츠가 깨지거나 빈 공간으로 표시되는 치명적 문제가 발생합니다.
마이그레이션 대상 비교
| 항목 | Divi | Bricks | Gutenberg |
|---|---|---|---|
| 코드 출력량 | 과다한 Divi 전용 CSS/JS | 순수 PHP + 최소 CSS | 워드프레스 기본 구조 |
| 학습 곡선 | 낮음 (시각적 편집) | 중간 | 높음 (블록 패턴 이해 필요) |
| SEO 최적화 | 추가 플러그인 필요 | Built-in Schema 지원 | Yoast/RankMath 필수 |
| 쇼트코드 의존도 | 매우 높음 (완전 종속) | 낮음 (Dynamic Tags) | 없음 (순수 HTML) |
| 마이그레이션 난이도 | 높음 (수동 변환 필요) | 중간 | 낮음 (단, 레이아웃 재구성) |
pre-migration 데이터 정리 및 백업 절차
무작정 전환을 시작하면 되돌릴 수 없는 데이터 손실이 발생합니다. 체계적인 백업이 선행되어야 합니다. 워드프레스 내보내기(WordPress Export) 기능으로 모든 콘텐츠를 XML 파일로 저장하고, 데이터베이스는 phpMyAdmin을 통해 SQL 덤프를 생성하세요. 특히 Divi 라이브러리에 저장된 글로벌 모듈과 레이아웃은 별도 JSON 파일로 exported 되어야 합니다.
Divi 특화 메타필드(`divi_post_settings` 등)은 데이터베이스에 `_et_pb_*` 형태로 저장됩니다. 마이그레이션 전 WP-CLI나 Advanced Database Cleaner를 활용해 미디어 라이브러리와 포스트 개정판(revision)을 정리하면 전체 데이터 용량을 30~40% 줄일 수 있습니다. 불필요한 자동 저장본과 휴지통 내 포스트를 완전 삭제하는 것은 마이그레이션 후 쿼리 속도 향상에 직접적인 영향을 줍니다.
쇼트코드 마이그레이션과 콘텐츠 구조 재구성
Divi의 가장 큰 마이그레이션 장벽은 `[et_pb_*]` 형태의 단축코드입니다. 이를 Bricks나 Gutenberg로 변환하는 자동화 도구는 존재하지 않습니다. 대량 변환 시 WP All Export/Import를 활용해 콘텐츠를 CSV로 추출한 뒤, 정규표현식(Regex)으로 쇼트코드 태그를 제거하고 순수 HTML로 치환하는 방식이 표준입니다.
Bricks로 이전할 경우, Divi의 섹션/행/모듈 구조를 Bricks의 container/grid 구조로 수동 매핑해야 합니다. Bricks는 Dynamic Tags 기능으로 ACF나 메타필드를 직접 호출할 수 있어, Divi에서 하드코딩된 콘텐츠를 동적 데이터로 전환하는 기회로 삼을 수 있습니다. Gutenberg로 전환 시에는 Getwid, Stackable 같은 third-party 블록 라이브러리를 미리 설치해두면 Divi의 모듈 기능을 일부 대체할 수 있습니다.
콘텐츠 마이그레이션 후 즉시 실행할 작업은 이미지 최적화입니다. Divi는 반응형 이미지 처리를 자체적으로 하지만, Gutenberg/Bricks는 srcset 속성을 테마가 처리합니다. ShortPixel이나 Imagify로 일괈 WebP 변환을 실행하고, 레이지 로딩 속성을 추가해야 합니다.
301 리디렉션 설정과 URL 일관성 유지
마이그레이션 중 URL 구조가 변경되면 구글은 새로운 페이지로 인식하고 기존 순위를 초기화합니다. `/blog/post-name`에서 `/entry/post-name`으로 바뀌는 것만으로도 3~6개월간의 순위 변동이 발생할 수 있습니다. 가능한 한 permalink 구조를 동일하게 유지하는 것이 철칙입니다.
불가피하게 URL이 변경되는 경우, .htaccess 파일에 301 리디렉션 규칙을 하드코딩하거나, Redirection 플러그인을 활용합니다. 개인 도메인을 사용 중이라면 서버 수준에서 301 처리가 가능하지만, 하위 경로가 변경되는 경우에는 개별 포스트마다 매핑 테이블을 만들어야 합니다. 구글 서치 콘솔의 “주소 변경” 기능을 활용해 사이트 이동을 신고하면 크롤러가 새 URL을 빠르게 인식하도록 유도할 수 있습니다.
리디렉션 체인(301이 또 다른 301을 거쳐 200으로 가는 구조)은 피해야 합니다. Divi에서 생성된 구형 URL이 중간 단계를 거쳐 새 URL로 가는 경우, 직접 연결로 수정하세요. 리디렉션 체인은 크롤링 예산을 낭비시키고 페이지 권위(PageRank)를 감소시킵니다.
post-migration 코어 웹 바이탈 최적화
마이그레이션 완료 후 48시간 내에 Core Web Vitals를 측정해야 합니다. Divi 대비 JavaScript 용량이 60% 이상 감소해야 정상적인 마이그레이션으로 판단할 수 있습니다. LCP(Largest Contentful Paint)를 2.5초 이내로 맞추기 위해선 이미지 차원 지정(width/height 속성 명시)과 CLS(Cumulative Layout Shift) 0.1 이하를 위해선 폰트 로딩 전략(font-display: swap)을 적용해야 합니다.
Bricks 사용자의 경우 Container의 gap 설정과 flex/grid 레이아웃을 활용해 별도의 row 쇼트코드 없이 CSS만으로 레이아웃을 구성합니다. Gutenberg 사용자는 테마의 block gap CSS 변수를 조정해 불필요한 spacer 블록을 제거하세요. WP Rocket이나 LiteSpeed Cache를 활용해 Critical CSS를 생성하고, JavaScript 지연 로딩(defer/async)을 적용하면 FID(First Input Delay)를 100ms 이하로 단축할 수 있습니다.
검색엔진 순위 방어를 위한 마지막 단계는 구조화된 데이터(Schema) 재검증입니다. Divi 테마가 자동 생성하던 JSON-LD 태그가 사라졌는지 확인하고, Yoast SEO나 Rank Math를 통해 Article, BreadcrumbList, Organization 스키마가 정상적으로 출력되는지 테스트하세요.
자주 묻는 질문(FAQ)
Q. Divi 쇼트코드가 마이그레이션 후에도 남아있으면 어떤 문제가 발생하나요?
A. `[et_pb_section]` 등의 쇼트코드는 Divi 플러그인이 비활성화되면 단순 텍스트로 출력되어 방문자에게 난해한 코드 노출과 함께 콘텐츠 가독성을 해칩니다. 검색엔진 크롤러는 이를 비정상적인 텍스트로 인식해 페이지 품질 평가를 낮추며, 구조화된 데이터 파싱에 실패할 수 있습니다. 마이그레이션 전 반드시 정규표현식으로 모든 Divi 고유 태그를 제거하거나 HTML로 변환해야 합니다.
Q. 301 리디렉션 설정 후 구글 서치 콘솔에서 주소 변경 신청을 반드시 해야 하나요?
A. 도메인이 변경되는 경우에는 필수입니다. 동일 도메인 내에서 permalink 구조만 변경되는 경우에는 개별 URL의 301 설정과 함께 기존 URL의 “URL 검사” 기능으로 새 URL로 리디렉션되는지 확인하면 됩니다. 다만 검색 결과에 노출된 주요 랜딩 페이지(월간 노출 1,000회 이상)는 주소 변경 도구를 통해 신고하면 색인 전환 속도가 2~3주 단축됩니다.
Q. 마이그레이션 직후 검색 순위가 일시적으로 떨어지는 것이 정상인가요?
A. 짧은 변동은 예상됩니다. 구글은 새로운 HTML 구조와 CSS를 재분석하는 데 최대 4주가 소요됩니다. 순위가 10위 이상 하락하거나, 6주 이후에도 회복되지 않는다면 리디렉션 오류, 캐노니컬 태그 중복, 또는 robots.txt 차단 여부를 점검해야 합니다. Core Web Vitals 점수가 이전보다 개선되었다면 장기적으로 순위 상승으로 이어질 가능성이 높습니다.