ecbeing RFP에 쓸 SEO·AI 검색 요건

ecbeing으로 기간계 연동까지 포함한 EC 사이트를 구축할 때, RFP의 SEO 항목이 '대응할 것' 한 줄로 끝나는 경우가 많습니다. 무엇을 더 써야 나중에 곤란하지 않은지가 이 단계의 실제 질문입니다.

구축 후에 바꿀 수 없는 항목부터 씁니다. 렌더링은 브라우저가 화면을 조립하는 과정입니다. 대규모 패키지에서는 URL 설계, 렌더링 방식, 메타데이터 관리 방법이 기초 공사에 해당합니다. 이 셋은 나중에 바꾸면 사이트 이전만큼 큰 작업이 됩니다. 반면 콘텐츠나 개별 메타 태그는 나중에라도 바꿀 수 있습니다. RFP에 써야 할 것은 앞쪽입니다. 쓰지 않으면 "패키지의 표준"이 그대로 적용됩니다. 그 표준이 요건에 맞는다는 보장은 없습니다.

이 글에서는 6개 영역의 요건을 바꾸기 어려운 순서로 정리합니다. RFP에 그대로 옮길 수 있는 문장으로 적었습니다.

결론: 바꿀 수 없는 순서로 6개 영역. 위의 3개는 반드시 씁니다

중요한 관점: RFP는 "무엇을 해 달라"보다 "무엇을 바꿀 수 없게 할 것인가"를 적는 문서입니다. 구축 후에 바꿀 수 없는 항목은 구축 전에만 정할 수 있습니다.

영역 1: URL 설계

RFP에 쓸 요건:

• 상품·카테고리·콘텐츠의 URL은 파라미터가 아닌 경로 형식으로 한다

• 상품 URL은 상품을 고유하게 식별하며, 카테고리 변경으로 바뀌지 않는다

• 카테고리 URL은 계층을 반영하며, 계층 변경 시 리다이렉트를 관리 화면에서 설정할 수 있다

• URL의 끝 슬래시, 대소문자를 통일하고, 비정규형은 리다이렉트한다

• 구 사이트에서 이전할 때, 구 URL에서 신 URL로의 301 리다이렉트를 대응표에 근거하여 일괄 설정할 수 있다

• 파라미터가 붙은 URL(정렬, 필터, 페이지 이동)의 canonical 규칙을 제안서에 명기할 것

영역 2: 렌더링 방식

RFP에 쓸 요건:

데이터 포인트: 연매출 400억 원(약 40억 엔) 규모의 한국 EC 브랜드에서는 원본 코드를 바꾸지 않고 별도 렌더링 층으로 기반을 정비해, 3개월 만에 Organic 구매 매출을 약 9,206만 원에서 약 1억 6,600만 원(+80%)으로 늘렸습니다.(사례 기사)

• 상품명, 가격, 재고, 상품 설명, 빵부스러기(브레드크럼), 구조화 데이터는 JavaScript를 실행하지 않고도 HTML 응답에 포함될 것(서버 사이드 렌더링 또는 정적 생성)

• 클라이언트 사이드 렌더링을 채택하는 경우, 검색 엔진과 AI 크롤러용으로 서버 사이드에서 동등한 HTML을 반환하는 구조를 포함할 것

• 제안서에 JavaScript를 비활성화한 상태의 상품 페이지 HTML 샘플을 첨부할 것

AI 크롤러의 다수는 JavaScript를 실행하지 않습니다. 클라이언트 사이드 렌더링 사이트는 AI에게 빈 페이지로 보입니다. 쇼윈도에 불이 꺼진 가게와 같습니다. 구축 후에 가장 바꾸기 어려운 항목이기도 합니다. 제안서에 JavaScript를 끈 HTML 샘플을 요구해야 합니다.

영역 3: 메타데이터·구조화 데이터 관리

RFP에 쓸 요건:

• title, meta description, canonical, noindex, OGP를 상품·카테고리·콘텐츠마다 관리 화면에서 설정할 수 있을 것

• 설정이 없는 경우의 템플릿(자동 생성 규칙)을 페이지 종류별로 관리 화면에서 변경할 수 있을 것

• Product, BreadcrumbList, Organization, Article 구조화 데이터를 상품 데이터에서 동적으로 출력할 것. 출력하는 속성을 제안서에 명기할 것

• 구조화 데이터의 출력을 개발 없이 관리 화면에서 활성화·비활성화할 수 있을 것

• 동일 페이지에 같은 유형의 구조화 데이터를 이중으로 출력하지 않을 것

영역 4: 봇의 접근 제어

RFP에 쓸 요건:

• WAF·봇 대책·속도 제한은 검색 엔진 및 AI 크롤러의 정규 IP를 허용 목록에 포함할 것. 허용 목록의 갱신 절차를 운영 절차서에 포함할 것

• robots.txt를 관리 화면에서 또는 배포 없이 편집할 수 있을 것

• AI 크롤러(GPTBot, ClaudeBot, PerplexityBot 등)의 허용·거부를 robots.txt에서 크롤러별로 설정할 수 있을 것

영역 5: 사이트맵·canonical

RFP에 쓸 요건:

• XML 사이트맵을 자동 생성하고, 상품·카테고리·콘텐츠를 포함하며, 비공개·판매 종료를 제외할 것. lastmod는 갱신 일시를 반영할 것

• 5만 URL 초과 시 분할하고 사이트맵 인덱스를 출력할 것

• 전체 페이지에 canonical을 출력하고, 파라미터가 붙은 URL은 영역 1의 규칙을 따를 것

영역 6: 로그 제공

RFP에 쓸 요건:

• 웹 서버 또는 CDN의 접근 로그를 User-Agent·응답 코드·URL·타임스탬프를 포함한 형식으로 발주자가 취득할 수 있을 것

• 로그의 보존 기간과 취득 방법을 운영 절차서에 포함할 것

봇이 실제로 무엇을 가져가는지는 로그로만 알 수 있습니다. 방문 기록 없이 손님을 세는 가게와 같습니다. 로그가 없으면 AI 검색 대응 상황을 확인할 수단이 사라집니다. 로그를 누가 어떻게 받을지 RFP에 적어 두어야 합니다.

RFP에 덧붙일 검수 조건

각 영역마다 "납품 시 발주자가 다음 방법으로 확인한다"고 씁니다. 검수 조건이 적혀 있으면 '대응하겠다'는 말의 해석 차이가 줄어듭니다.

구축 후에 벌어지는 일

RFP로 구축 시점의 상태는 지킬 수 있습니다. 다만 그 뒤에 기능 추가, 패키지 버전 업그레이드, WAF 설정 변경이 이어집니다. 그때마다 요건대로였던 상태가 조금씩 무너집니다. 유지보수 계약에 "요건의 유지"와 "변경 시의 확인"이 들어 있는지 확인해야 합니다.

Search OS는 ecbeing 같은 대규모 패키지로 만든 사이트를 계속 살펴봅니다. 이 6개 영역에 해당하는 상태를 지속적으로 검증합니다. 구축 시점에서 무너진 항목과 봇 수집 상황의 변화는 수정 대상으로 정리합니다. 구축을 맡는 층이 아니라, 구축 후 아무도 보지 않게 되는 요건을 지켜보는 층입니다.

자주 묻는 질문

RFP에 이렇게까지 쓰면 제안이 들어오지 않게 되지 않나요?

요건이 명확한 RFP는 벤더 입장에서도 견적을 내기 쉽습니다. 대응이 어려운 항목이 있으면 제안서에 대안이 실립니다. 쓰지 않으면 오히려 나중에 분쟁으로 이어질 수 있습니다.

렌더링 방식은 벤더에게 맡겨도 되나요?

맡기면 벤더가 잘하는 방식으로 정해집니다. AI 검색을 중시한다면 서버 사이드 렌더링을 요건으로 적어 두어야 합니다.

로그 제공은 당연한 것 아닌가요?

운영 계약에 따라 로그가 벤더 쪽에만 있을 수 있습니다. 그러면 발주자가 직접 받을 수 없습니다. RFP에 미리 적어 두어야 합니다.

함께 읽을 글

• ecbeing의 대규모 리뉴얼에서 URL과 리다이렉트를 어떻게 설계할 것인가

• EC-CUBE 제작사에 SEO·AI 검색 요건을 전달하기 위한 요건서 템플릿

• SI가 구축한 사이트의 SEO·AI 대책: 개발 사이클 없이 진행하는 방법

• ecbeing 검색·AI 검색에 안 나올 때 볼 6가지

참고 자료

• Google Search Central: JavaScript SEO basics

• Google Search Central: URL structure best practices

• Google Search Central: Ecommerce best practices

• Google Search Central: Verifying Googlebot and other Google crawlers