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

ecbeing 같은 대규모 패키지로 구축한 사이트가 검색이나 AI 검색에 나오지 않을 때, 원인은 콘텐츠보다 구축 시점에 정해진 설계에 있는 경우가 많습니다. URL 설계, 렌더링 방식, 메타데이터 관리 방법은 나중에 바꾸면 사이트 이전만큼 큰 작업이 됩니다. 기간 시스템 연동까지 포함해 리뉴얼하면서 수만 개의 URL이 한 번에 바뀌는 안건에서는, 리다이렉트 설계가 색인과 유입을 좌우합니다.

이 글은 ecbeing에 관해 쓴 2편의 글에서, 담당자가 가장 먼저 확인할 6개 항목을 추린 것입니다. 각 항목의 상세는 말미의 글에 맡깁니다.

1. URL이 경로 형식이고, 상품 ID가 카테고리 변경으로 바뀌지 않는가

RFP에 쓰지 않으면 URL은 패키지의 표준을 따릅니다. 파라미터 형식이거나 ID만 있는 URL인 경우가 있습니다. 구축 후에 URL 설계를 바꾸기는 매우 어렵고, 사이트 이전에 상당하는 작업입니다. 먼저 상품·카테고리·파라미터가 붙은 URL을 브라우저에서 열어 형식과 canonical을 확인합니다.

2. JavaScript를 꺼도 상품 정보가 HTML에 포함되는가

AI 크롤러의 다수는 JavaScript를 실행하지 않습니다. 클라이언트 사이드 렌더링 사이트는 AI에게 빈 페이지로 보입니다. 렌더링 방식은 구축 후에 가장 바꾸기 어려운 항목이고, 바꾸려면 프런트 재구축이 따릅니다. 확인 방법은 어렵지 않습니다. JavaScript를 비활성화하고 상품 페이지를 표시해, 상품명·가격·구조화 데이터가 HTML에 포함되어 있는지 봅니다.

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

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

• 구축 전이라면 제안서에 JavaScript를 비활성화한 상태의 상품 페이지 HTML 샘플을 첨부받는다

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

3. title·canonical·구조화 데이터를 관리 화면에서 바꿀 수 있는가

관리 화면에서 설정할 수 없으면 메타데이터 변경은 매번 개발 의뢰가 됩니다. 구축 후에 관리 화면을 개수하기는 어렵습니다. 관리 화면에서 설정을 바꾸고 페이지에 반영되는지 확인합니다. 구조화 데이터는 리치 리절트 테스트로 유형과 값을 봅니다.

4. WAF와 robots.txt가 크롤러를 막고 있지 않은가

WAF의 표준 설정으로 크롤러가 차단되는 일이 있습니다. 스테이징에서 설정한 noindex 나 Disallow: / 가 운영 환경에 남는 사고는 대규모 리뉴얼에서 가장 흔한 실패 중 하나입니다. robots.txt의 내용과, 서버 로그에서 Googlebot·AI 크롤러의 응답 코드가 200인지 확인합니다.

• WAF·봇 대책·속도 제한의 허용 목록에 검색 엔진 및 AI 크롤러의 정규 IP가 들어 있다. 허용 목록의 갱신 절차가 운영 절차서에 있다

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

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

• 전환 직후 스테이징의 noindex와 Disallow가 운영 환경에 남아 있지 않다

5. 리뉴얼의 리다이렉트가 1회의 301로 신 URL에 닿는가

상품 3만 점, 카테고리 2천 개, 콘텐츠 5천 개 규모의 리뉴얼에서는 URL이 전부 바뀝니다. 전부 손으로 설정하기는 어려우므로, 규칙으로 9할, 대응표로 1할이라는 설계로 갑니다. 다단계 리다이렉트(구 → 중간 → 신)는 평가가 새고 크롤이 낭비됩니다. 전환 전에 스테이징에서 전체 URL을 기계적으로 검증합니다.

검증에서는 구 URL 목록을 스테이징의 신 사이트에 요청하고, 301 이외(404, 다단계 301, 302, 200)를 골라내 수정합니다. "전체 URL이 1회의 301로 200 페이지에 도달한다"가 될 때까지 반복합니다. 전환 당일에는 검색 유입·백링크 상위 50건을 손으로 열고, Search Console에 사이트맵을 다시 등록하고, 주력 페이지의 색인 등록을 요청합니다. 리다이렉트는 전환 당일로 끝나지 않으며, 최소 1년, 백링크가 남아 있는 한 영구적으로 둡니다.

6. 사이트맵과 접근 로그를 발주자가 다룰 수 있는가

봇이 실제로 무엇을 가져가는지는 로그로만 알 수 있습니다. 운영 계약에 따라 로그가 벤더 쪽에만 있어 발주자가 직접 받을 수 없는 경우가 있습니다. 로그가 없으면 AI 검색 대응 상황을 확인할 수단이 사라집니다. 사이트맵은 Search Console에 등록하고, 발견된 URL 수가 공개 페이지 수와 가까운지 확인합니다.

Search OS는 구축 후의 상태를 계속 지켜보는 층입니다

Search OS는 ecbeing 같은 대규모 패키지로 구축한 사이트를 대상으로, 위 6개 항목에 해당하는 상태를 지속적으로 검증합니다. 404·리다이렉트 체인·canonical·색인 수의 변화와, 봇이 가져가는 구 URL과 신 URL의 대응을 봅니다. 구축 시점에서 무너진 항목과 리뉴얼로 사라진 페이지는 수정 대상으로 정리합니다. 구축이나 리뉴얼 작업을 대신하는 것이 아닙니다. 구축 후 요건을 계속 지켜볼 역할은 계약 단계에서 정해 둡니다.

담당자가 먼저 볼 질문

• 상품 URL이 경로 형식이고, 카테고리를 바꿔도 바뀌지 않는 설계인가

• JavaScript를 비활성화한 상태에서 상품명·가격·구조화 데이터가 HTML에 포함되어 있는가

• title, canonical, noindex, 구조화 데이터를 개발 의뢰 없이 관리 화면에서 바꿀 수 있는가

• 서버 로그에서 Googlebot·AI 크롤러의 응답 코드가 200으로 나오는가

• 스테이징의 noindex나 Disallow: / 가 운영 환경에 남아 있지 않은가

• 리뉴얼 후 구 URL이 1회의 301로 신 URL의 200 페이지에 닿는가

• 웹 서버 또는 CDN의 접근 로그를 발주자가 직접 받을 수 있는 계약인가

결론

ecbeing 사이트가 검색·AI 검색에 나오지 않을 때 먼저 볼 것은 콘텐츠가 아니라 구축 시점에 정해진 설계입니다. URL 설계, 렌더링 방식, 메타데이터 관리는 구축 전에만 정할 수 있습니다. 봇의 접근 제어, 리다이렉트, 사이트맵과 로그는 구축 후에도 기능 추가와 WAF 설정 변경으로 계속 무너집니다. RFP로 지킬 수 있는 것은 구축 시점의 상태까지이므로, 유지보수 계약에 "요건의 유지"와 "변경 시의 확인"이 들어 있는지 확인하고, 무너진 곳을 찾아낼 담당을 미리 정해 둡니다.

함께 읽기

• ecbeing의 RFP에 SEO·AI 검색 요건을 어떻게 쓸 것인가: 구축 후에 바꿀 수 없는 항목

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

참고 자료

• Google Search Central: JavaScript SEO basics

• Google Search Central: URL structure best practices

• Google Search Central: Verifying Googlebot and other Google crawlers

• Google Search Central: Site moves with URL changes

• Google Search Central: Redirects and Google Search

• Google Search Central: Large site owner's guide to managing your crawl budget