EC-CUBE 제작사에 넘길 SEO·AI 검색 요건서
EC-CUBE로 새 사이트를 제작사에 맡길 때 SEO도 고려해 달라고 하면 "대응하겠습니다"라는 답이 돌아오는 경우가 많습니다. 그 한마디에 무엇이 들어가는지, 무엇을 어떻게 전달해야 하는지는 그대로 남습니다.
제작사에게 SEO는 범위가 모호한 말입니다. title만 바꿀 수 있게 해 두고 "대응 완료"가 되기도 합니다. 필요한 것은 항목마다 무엇을, 어디에, 어떻게 확인할지 적은 요건서입니다. 요건서가 있으면 견적에 들어가는지 분명해집니다. 납품 때 같은 표로 검수할 수도 있습니다.
이 글은 URL·메타데이터·구조화 데이터·사이트맵·속도·봇 대응 6개 영역을 다룹니다. 사이트맵은 검색 엔진에 넘기는 페이지 URL 목록입니다. 제작사에 그대로 넘길 수 있는 표로 정리했습니다.
결론: 6개 영역×구체 항목의 요건서를 구축 전에 넘기고, 납품 시 같은 표로 검수한다
영역 | 요건 수 | 검수 도구 |
|---|---|---|
URL | 5 | 브라우저, Search Console |
메타데이터 | 5 | 페이지 소스 |
구조화 데이터 | 5 | 리치 리절트 테스트 |
사이트맵 | 4 | 사이트맵 URL, Search Console |
속도 | 3 | PageSpeed Insights |
봇 대응 | 4 | robots.txt, 서버 로그 |
중요한 관점: 요건서는 제작사를 의심하려고 쓰는 문서가 아닙니다. 무엇이 포함되는지 양쪽이 합의하려고 씁니다. 인테리어 공사 견적서와 같습니다. 적혀 있지 않은 항목은 포함되지 않는다고 보는 편이 전제입니다.
영역 1: URL
항목 | 요건 | 검수 |
|---|---|---|
상품 URL | 상품 ID만이 아니라 의미 있는 문자열을 포함할 수 있다(또는 상품 ID로 통일하고 바꾸지 않는다) | 상품 페이지의 URL을 확인 |
카테고리 URL | 계층을 반영. 카테고리 변경 시 리다이렉트를 관리 화면에서 설정할 수 있다 | 카테고리 페이지의 URL, 리다이렉트 설정 유무 |
파라미터 | 정렬·표시 건수 파라미터가 붙은 URL은 canonical로 원본 URL에 통합 | 파라미터가 붙은 URL의 소스에서 canonical 확인 |
끝 슬래시·대소문자 | 통일하고, 한쪽은 리다이렉트 | 양쪽을 열어 확인 |
리다이렉트 | 구 사이트에서 이전하는 경우, 구 URL → 신 URL 대응표를 바탕으로 301을 설정 | 대응표에서 샘플 확인 |
영역 2: 메타데이터
항목 | 요건 | 검수 |
|---|---|---|
title | 페이지 종류별 템플릿이 있고, 상품·카테고리별로 개별 덮어쓰기가 가능하다 | 소스에서 확인 |
meta description | 위와 같음 | 소스에서 확인 |
canonical | 전체 페이지에서 자기 참조. 파라미터가 붙은 경우는 원본 URL | 소스에서 확인 |
OGP | 상품 이미지·상품명·설명이 나온다 | 소스에서 확인 |
noindex | 관리 화면에서 페이지 단위로 설정할 수 있다. 검색 결과·마이페이지·장바구니는 noindex | 소스에서 확인 |
영역 3: 구조화 데이터
항목 | 요건 | 검수 |
|---|---|---|
Product | 상품 페이지에서 이름·이미지·가격·재고·브랜드를 출력. 값은 상품 데이터에서 동적으로 | 리치 리절트 테스트 |
BreadcrumbList | 상품·카테고리 페이지에서 빵부스러기(브레드크럼) 표시와 일치 | 리치 리절트 테스트 |
Organization | 메인 페이지만 | 리치 리절트 테스트 |
Article | 사용자 정의 페이지(콘텐츠)에서 출력 가능 | 리치 리절트 테스트 |
이중 출력 금지 | 플러그인과 템플릿에서 같은 타입을 이중으로 내보내지 않는다 | 소스에서 |
영역 4: 사이트맵
항목 | 요건 | 검수 |
|---|---|---|
생성 | XML 사이트맵을 자동 생성(플러그인 또는 자체 제작). EC-CUBE 4는 표준에 없으므로 명기 | 사이트맵 URL을 연다 |
범위 | 상품·카테고리·사용자 정의 페이지를 포함. 비공개·판매 종료는 제외 | 내용을 확인 |
lastmod | 상품의 갱신 일시를 반영 | 내용을 확인 |
등록 | robots.txt에 Sitemap 행. Search Console에 등록 | robots.txt, Search Console |
영역 5: 속도
항목 | 요건 | 검수 |
|---|---|---|
Core Web Vitals | 주력 상품 페이지에서 LCP 2.5초 이내, CLS 0.1 이하, INP 200ms 이하 | PageSpeed Insights |
이미지 | 차세대 형식(WebP 등) 대응, 크기 지정, 지연 로딩 | PageSpeed Insights |
캐시 | 페이지 캐시 또는 CDN 설정. 캐시가 canonical이나 hreflang을 깨뜨리지 않을 것 | 소스에서 확인 |
영역 6: 봇 대응
항목 | 요건 | 검수 |
|---|---|---|
robots.txt | 관리 화면·장바구니·마이페이지를 Disallow. 상품·카테고리·콘텐츠는 Allow. AI 크롤러(GPTBot 등)의 처리를 방침으로 정해 기재 | robots.txt를 연다 |
JavaScript 의존 | 상품명·가격·설명·구조화 데이터는 JavaScript 없이 HTML에 포함된다 | JavaScript를 끄고 표시 |
WAF·접근 제한 | 검색 엔진과 AI 크롤러를 차단하지 않는 설정. 차단하는 경우 방침을 명기 | 서버 로그에서 봇의 응답 코드 |
로그 | 봇의 접근 로그를 저장하고 받아볼 수 있다 | 로그 제공 방법을 확인 |
요건서 끝에 덧붙일 한 문장
"위 각 항목은 납품 시 오른쪽 열의 방법으로 검수합니다. 대응하지 않는 항목이 있으면 견적 단계에서 명기해 주십시오". 이 한 문장을 요건서 맨 아래에 붙입니다. 모호한 '대응하겠다'는 답을 미리 막는 잠금장치입니다.
납품 후에 일어나는 일
요건서로 납품 시점의 상태는 지킬 수 있습니다. 문제는 그 뒤입니다. 플러그인을 추가하거나 본체를 업데이트하면 요건서대로였던 상태가 무너집니다. 캠페인 페이지를 늘릴 때도 마찬가지입니다. 유지보수 계약에 "SEO 요건 유지"가 들어 있는지도 확인합니다.
Search OS는 EC-CUBE처럼 제작사가 구축한 사이트를 계속 확인합니다. 이 요건서의 6개 영역에 해당하는 상태를 지속적으로 검증합니다. 납품 시점에서 무너진 항목은 수정 대상으로 정리합니다. 제작사의 작업을 대신하는 층이 아니라, 납품 후 아무도 보지 않게 되는 항목을 지켜보는 층입니다.
자주 묻는 질문
요건서를 넘겼더니 견적이 올랐습니다
오르는 편이 정상입니다. "SEO도 고려"로 나온 견적에는 빠진 항목이 있었고, 그 누락이 표로 드러났을 뿐입니다. 우선순위가 낮은 항목을 덜어내 조정합니다.
제작사가 "EC-CUBE의 표준 기능으로는 대응할 수 없다"고 합니다
EC-CUBE는 템플릿과 플러그인으로 확장할 수 있습니다. 그래서 대부분 대응이 가능합니다. 대응할 수 없는 이유를 구체적으로 묻고, 대안을 함께 받아 둡니다.
유지보수 계약에 SEO 유지가 포함되나요?
계약에 따라 다릅니다. 포함되지 않는다면 요건서의 검수 열을 활용합니다. 분기에 1회 직접 확인하면 됩니다.
함께 읽기
참고 자료
Google Search Central: SEO Starter Guide
Google Search Central: Ecommerce best practices
Google Search Central: Overview of Google crawlers and fetchers
Google Search Central: Understanding Core Web Vitals and Google search results