EC-CUBETips

EC-CUBE가 검색에 나오지 않을 때 먼저 볼 5가지

2026년 9월 9일9분 읽기

EC-CUBE 2계열로 10년간 운영해 온 사이트를 4계열로 옮긴 뒤 검색 순위가 전반적으로 떨어졌습니다. EC-CUBE 4로 사이트를 만들고 Search Console에 사이트맵을 등록하려는데 /sitemap.xml 이 404로 나옵니다. SEO 플러그인을 넣어 두었지만 그것으로 충분한지, 구조화 데이터는 직접 구현하는 편이 나은지 알 수 없습니다. 제작사에 SEO도 고려해 달라고 했더니 "대응하겠습니다"라는 답이 돌아왔지만 그 한마디에 무엇이 들어가는지 보이지 않습니다. EC-CUBE를 쓰는 숍에서 들어오는 문의는 이 네 가지에 몰려 있습니다.

공통점은 EC-CUBE가 "직접 준비한다"는 전제의 카트라는 사실입니다. ASP 카트 대부분이 자동으로 만드는 사이트맵도 EC-CUBE 4계열에는 기본으로 없습니다. 구조화 데이터는 플러그인이나 템플릿으로 내보내지만, 그 출력이 올바른지 계속 확인하는 기능은 갖고 있지 않습니다. 이 글에서는 개별 글에서 정리한 내용을 "먼저 볼 5가지" 순서로 다시 묶습니다. 수치와 절차는 각 글의 내용을 그대로 쓰고, 자세한 작업은 글 끝의 링크로 넘깁니다.

1. 2계열에서 4계열로 이전한다면 "사이트 이전"으로 보고 4개 자산의 인계표를 확인한다

2계열에서 4계열로 옮기는 것은 버전 업이 아니라 사이트 이전입니다. URL 구조가 바뀌고 템플릿은 다시 만들어집니다. 2계열에서 쓰던 플러그인과 커스터마이징은 4계열에서 돌아가지 않습니다. 10년치 평가는 옛 URL에 쌓여 있고, 새 URL로 넘겨주지 않으면 그대로 사라집니다. 같은 EC-CUBE이니 넘어간다고 말할 수 있는 것은 상품 데이터뿐입니다. 검색 엔진이 보는 사이트는 URL과 HTML의 묶음이고, 그 묶음은 전부 새로 만들어집니다.

자산	2계열	4계열	인계 방법
URL	파라미터 형식(product_id= 등)	경로 형식	옛 URL → 새 URL 대응표와 301 리다이렉트
메타데이터	2계열의 상품 데이터·템플릿	4계열의 상품 데이터·템플릿	데이터 이전 시 title·description을 포함합니다. 템플릿에서 출력을 다시 구현
구조화 데이터	커스터마이징 또는 플러그인	재구현 필요	2계열에서 출력하던 유형을 기록하고, 4계열의 템플릿 또는 플러그인으로 재현
사이트맵	표준 기능 있음	표준 기능 없음	플러그인 또는 자체 제작으로 준비

인계표가 완성될 때까지 전환은 미룹니다. 이전 전에 검색 유입이 있는 URL 수, 주력 페이지의 순위, 구조화 데이터의 유형을 기록해 둡니다. 이전 1주 후에 옛 URL의 404와 리다이렉트 오류가 거의 없는지, 주력 페이지의 URL 검사에서 새 URL이 색인 완료이고 canonical이 새 URL인지, 1개월 후에 사이트맵의 검출 수가 상품 수와 비슷한지, 1~3개월 후에 검색 유입이 이전 전 수준으로 돌아오는지를 순서대로 봅니다. 이전과 동시에 도메인까지 바꾸면 원인을 가려내기 어려우므로, 버전 이전을 먼저 하고 안정된 뒤에 도메인을 바꿉니다.

2. /sitemap.xml 이 404라면 플러그인·자체 제작·외부 생성 3가지 중에서 고른다

EC-CUBE 4계열은 XML 사이트맵을 기본으로 만들지 않습니다. 2계열에 있던 sitemap.php가 4계열에서 없어졌기 때문에, 이전하면서 "없어졌다"고 느끼는 숍이 많습니다. ASP 카트 대부분이 자동 생성하는 것과 달리 EC-CUBE에서는 직접 준비합니다. 선택지는 플러그인을 넣거나, 직접 만들거나, 외부 도구로 생성하는 3가지이고, 어느 쪽을 고를지는 상품 수, 갱신 빈도, 개발 체제로 정해집니다.

선택지	갱신 추종	분할(5만 URL 초과)	lastmod	개발	판단
플러그인	자동(플러그인 사양에 따름)	플러그인에 따름	플러그인에 따름	불필요	상품 1만 점 미만, 표준적인 구성 ◎
자체 제작	자동(직접 설계)	자유	자유	필요	대규모, 다국어, 독자적인 URL 구성 ◎
외부 도구로 생성해 정적으로 배치	수동(재생성 필요)	도구에 따름	생성 시점의 값	불필요	이전기의 임시 대응 △

상품 1만 점 미만이면 플러그인, 그 이상이거나 요건이 특수하면 자체 제작, 외부 생성은 임시방편입니다. 플러그인을 고른다면 사용 중인 버전(4.0/4.1/4.2/4.3)에 대응하는지와 최종 업데이트일을 확인합니다. 대응 버전이 오래된 플러그인은 EC-CUBE 본체 업데이트로 멈추는 경우가 있습니다. 준비한 뒤에는 URL 수가 공개 중인 상품 수·카테고리 수와 가까운지, 비공개·판매 종료 상품이 들어 있지 않은지, lastmod가 상품마다 다른 값인지, Search Console에서 "성공"으로 표시되는지, robots.txt에 Sitemap: 행이 있는지를 봅니다. 플러그인과 자체 제작을 병용하면 같은 URL을 다른 lastmod로 전달해 모순이 생기므로 하나로 좁힙니다.

3. SEO 플러그인의 구조화 데이터는 출력 여부가 아니라 "오늘도 올바른가"를 본다

EC-CUBE의 SEO 플러그인은 메타 태그·OGP·사이트맵 범위에서는 믿고 맡겨도 됩니다. 구조화 데이터는 사정이 조금 다릅니다. 플러그인은 출력은 하지만, 그 출력이 올바른지 계속 확인하는 기능은 갖고 있지 않습니다. EC-CUBE 본체나 플러그인 업데이트, 템플릿 변경으로 구조화 데이터가 깨져도 아무도 모릅니다. 이것이 가장 흔한 실패입니다. 유효하지 않은 구조화 데이터는 없는 것보다 나쁠 수 있습니다. 오류가 있으면 블록 전체가 무시됩니다.

실패	발생 상황	감지의 어려움
구조화 데이터의 가격이 화면과 다름	세일 가격·규격별 가격	화면상으로는 정상이라 알아차릴 수 없음
재고 있는 상품이 구조화 데이터에서는 재고 없음	규격별 재고, 예약 상품	AI의 추천 후보에서 조용히 빠짐
업데이트 후 구조화 데이터가 출력되지 않음	본체·플러그인·템플릿 업데이트	리치 리절트가 사라지고 나서야 알아차림
같은 상품에 JSON-LD 블록이 여러 개	플러그인과 템플릿의 이중 출력	검증 도구에서 경고가 나옴

플러그인의 출력은 EC-CUBE 표준 템플릿을 따르는 상품 구조를 전제로 만들어졌습니다. 그래서 규격(사이즈·색상)별로 가격이나 재고가 다른 상품, 커스터마이즈한 템플릿, 본체·플러그인 업데이트 세 지점에서 어긋나기 쉽습니다. 표의 실패가 자사 숍에서 일어나고 있지 않은지, 상품 페이지 하나를 리치 리절트 테스트에 넣어 보는 데서 시작합니다.

4. 구조화 데이터를 자체적으로 갖출지는 5가지 조건을 세어 정한다

"플러그인이냐 자체 구현이냐"를 고르기 전에 볼 것은 출력이 올바른지 계속 확인하는 체계가 있느냐입니다. 체계가 없으면 어느 쪽으로 만들어도 같은 실패를 반복합니다. 그 위에서 아래 중 2가지 이상에 해당한다면 구조화 데이터는 템플릿 쪽에서 직접 구현하고 플러그인 출력은 끕니다.

규격별로 가격·재고가 달라지는 상품이 전체의 3할 이상이다
템플릿을 표준에서 크게 커스터마이즈했다
콘텐츠 페이지(특집·읽을거리)가 있고 Article을 출력하고 싶다
본체·플러그인 업데이트를 연 여러 차례 진행한다
과거에 구조화 데이터가 깨진 경험이 있다

해당하는 항목이 1가지 이하라면 플러그인 출력을 계속 써도 됩니다. 다만 어느 쪽을 고르든 검증 체계는 있어야 합니다. 업데이트할 때마다 상품·카테고리·콘텐츠 페이지를 하나씩 리치 리절트 테스트에 넣고, 주간으로 구조화 데이터의 가격·재고와 화면 표시의 일치를 표본 확인하고, 월간으로 Search Console 개선 사항 보고서의 오류·경고 수를 봅니다. 봇이 상품 페이지를 수집할 수 있는지는 서버 로그 또는 봇 로그로 상시 확인합니다. 상품 수가 수백 개까지는 수작업으로도 돌아가지만, 수천 개를 넘고 규격이 많으며 업데이트가 잦은 사이트라면 이 운영 자체가 부담이 됩니다.

5. 제작사에 맡긴다면 6개 영역의 요건서를 구축 전에 넘기고, 납품 시 같은 표로 검수한다

제작사에게 SEO는 범위가 모호한 말이라, title만 바꿀 수 있게 해 두고 "대응 완료"가 되기도 합니다. 항목마다 무엇을, 어디에, 어떻게 확인할지 적은 요건서가 있으면 견적에 들어가는지 분명해지고, 납품 때 같은 표로 검수할 수 있습니다. 적혀 있지 않은 항목은 포함되지 않는다고 보는 것이 전제입니다.

영역	요건 수	검수 도구
URL	5	브라우저, Search Console
메타데이터	5	페이지 소스
구조화 데이터	5	리치 리절트 테스트
사이트맵	4	사이트맵 URL, Search Console
속도	3	PageSpeed Insights
봇 대응	4	robots.txt, 서버 로그

요건 가운데 EC-CUBE에서 특히 빠지기 쉬운 것은 네 가지입니다. XML 사이트맵 자동 생성은 EC-CUBE 4 표준에 없으므로 명기합니다. 구조화 데이터는 플러그인과 템플릿에서 같은 타입을 이중으로 내보내지 않는 것으로 정하고, 소스에서 ld+json 개수를 확인합니다. 상품명·가격·설명·구조화 데이터는 JavaScript 없이 HTML에 포함합니다. robots.txt에서는 관리 화면·장바구니·마이페이지를 Disallow로 두고, AI 크롤러(GPTBot 등)의 처리를 방침으로 정해 기재합니다. 요건서 맨 아래에는 "위 각 항목은 납품 시 오른쪽 열의 방법으로 검수합니다. 대응하지 않는 항목이 있으면 견적 단계에서 명기해 주십시오"라는 한 문장을 붙입니다. 요건서를 넘긴 뒤 견적이 오르는 것은 정상이고, 빠져 있던 항목이 드러났을 뿐입니다.

Search OS는 이전과 납품 뒤에 무너지는 상태를 계속 지켜보는 층입니다

요건서로 지킬 수 있는 것은 납품 시점의 상태까지이고, 인계표로 지킬 수 있는 것은 전환 시점의 상태까지입니다. 그 뒤에 플러그인을 추가하고 본체를 업데이트하고 캠페인 페이지를 늘릴 때마다 리다이렉트 누락, 다시 만든 구조화 데이터의 어긋남, 사이트맵 생성 중단이 나중에 드러납니다. Search OS는 EC-CUBE 본체나 플러그인을 바꾸지 않습니다. 검색 엔진과 AI 크롤러용 메타데이터·구조화 데이터·canonical·사이트맵을 별도 층으로 제공하고, 그 값이 가시 텍스트와 일치하는지 계속 검증합니다. 봇 로그로는 Googlebot이나 GPTBot이 상품 페이지를 실제로 수집하는지 확인하고, 깨진 출력, 빠진 Article, 수집에 실패한 URL, 이전으로 잃은 메타데이터를 수정 대상으로 정리합니다. 이전 작업이나 제작사의 작업을 대신하지는 않으며, 납품 후 놓친 구멍을 계속 찾아내는 층입니다.

담당자가 먼저 볼 질문

2계열에서 4계열로 이전한다면 옛 URL과 새 URL의 1대1 대응표와 301 리다이렉트가 있는가
이전 전 주력 페이지의 title·description·구조화 데이터 유형을 비교할 수 있는 형태로 기록해 두었는가
/sitemap.xml 이 열리는가. URL 수는 공개 중인 상품 수와 가깝고, lastmod는 상품마다 다른 값인가
사이트맵 플러그인은 사용 중인 EC-CUBE 버전에 대응하고, 업데이트가 이어지고 있는가
상품 페이지를 리치 리절트 테스트에 넣었을 때 가격·재고가 화면 표시와 일치하는가
같은 페이지에 같은 타입의 JSON-LD가 두 번 나오고 있지 않은가
제작사와의 유지보수 계약에 "SEO 요건 유지"가 들어 있는가. 납품 후 누가 계속 볼지 정해져 있는가

결론

EC-CUBE 숍이 검색에 나오지 않을 때는 이전·사이트맵·구조화 데이터·요건서라는 네 입구 가운데 어디에서 빠졌는지를 먼저 정합니다. 이전이라면 4개 자산의 인계표, 사이트맵이라면 3가지 선택지 중 하나와 준비한 뒤의 확인, 구조화 데이터라면 "오늘도 올바른가"의 검증, 제작사 의뢰라면 6개 영역의 요건서입니다. 모두 EC-CUBE에서는 "말하지 않으면 들어가지 않고" "준비하지 않으면 없는" 항목이고, 한 번 갖춰도 본체와 플러그인 업데이트로 무너집니다. 여기까지가 설정의 문제이고, 그 다음은 업데이트 때마다 같은 상태를 유지하는 운영의 문제입니다.

EC-CUBE가 검색에 나오지 않을 때 먼저 볼 5가지