모든 대시보드가 정상으로 보이는 스토어를 상상해 보세요. 홈페이지는 색인되어 있고, Lighthouse는 초록색이며, 구조화 데이터 검증기는 오류를 표시하지 않습니다. 하지만 바로 그 순간에도 Google Shopping의 가격은 장바구니의 가격과 일치하지 않고, 모바일 필터 드로어는 키보드 사용자를 가두며, 모든 구매는 두 번 기록됩니다.
이 중 어느 것도 간단한 상태 점검에서는 드러나지 않습니다. 온라인 스토어는 단순한 페이지 모음이 아니라 서로 연결된 시스템이기 때문입니다. 상품 데이터는 페이지, 구조화 데이터, 쇼핑 피드로 흘러갑니다. 스크립트와 서드파티 태그가 전체 로딩 속도를 좌우합니다. 결제는 관심을 매출로 바꾸고, 애널리틱스는 전체 여정을 정확히 기록해야 합니다. 한 부분이 고장 나면 다른 모든 것을 조용히 왜곡할 수 있습니다.
그래서 유용한 이커머스 감사는 사이트맵이 아니라 쇼핑객을 따라갑니다. 아래 체크리스트는 스토어를 발견하는 단계에서 시작해 주문 완료로 끝납니다. 이를 통해 실제 문제들을 우선순위대로 정리한 목록을 얻게 되며, 각 문제에는 증거, 담당자, 수정 완료를 확인할 테스트가 함께 붙습니다.
이 감사를 언제 실행해야 하며, 왜 순서가 중요한가
새 이커머스 클라이언트를 맡았을 때, 리디자인이나 플랫폼 마이그레이션 이후, 대규모 성장 추진을 앞두고, 또는 일상 점검에서 사이트 전반의 퇴행이 발견되었을 때 전체 감사를 실행하세요. 가벼운 점검이면 36시간, 중요한 모든 템플릿을 제대로 테스트하는 표준 감사라면 12일을 확보하세요. 로그, 피드, 애널리틱스를 깊이 파고드는 조사에는 보통 별도의 시간이 필요합니다.
순서는 의도적입니다. Google이 카테고리 페이지를 색인할 수 없다면 전환 마찰을 평가할 의미가 없고, 구매 태그가 두 번 발생한다면 퍼널 보고서를 신뢰할 의미가 없습니다.
중복된 구매 이벤트는 더 많은 판매의 증거가 아니며, Google이 보는 가격이 장바구니의 가격과 다르다면 빠른 상품 페이지도 건강한 것이 아닙니다. 그래서 감사는 단계별로 진행됩니다. 먼저 발견 가능성에서 시작해, 상품 데이터의 진실성, 속도, 구매 자체로 넘어가고, 그 다음에야 측정으로 이동합니다.
시작하기 전에 필요한 것을 준비하세요. 즉, 다음에 대한 접근 권한입니다:
- Search Console,
- 애널리틱스,
- 태그 관리자,
- 카탈로그 또는 피드 소스,
- Merchant Center,
- 최근 사이트 변경 내역 목록.
1단계: 검색 엔진이 카탈로그를 찾을 수 있는가?
1. 스토어 전체를 대표하는 표본을 구성하세요
대부분의 이커머스 버그는 공유 템플릿과 특이한 상품 상태에 숨어 있습니다. 깔끔한 홈페이지는 필터된 카테고리, 옵션 로직, 품절, 결제에 대해 아무것도 알려주지 않습니다. 그래서 먼저 올바른 마켓, 통화, 언어의 실제 운영 사이트를 테스트하고 있는지 확인하는 것부터 시작해야 합니다. 그런 다음 다음 각 항목에서 최소 하나의 URL을 고르세요:
- 홈페이지
- 우선순위 카테고리
- 더 깊은 카테고리 또는 승인된 필터 페이지
- 일반적인 상품
- 옵션이 있는 상품
- 품절 또는 단종된 상품
- 내부 검색 결과 페이지(결과가 없는 경우 포함)
- 장바구니, 결제, 주문 확인 페이지
위험해 보이는 템플릿마다 까다롭거나 특이한 예시를 추가하세요. 애널리틱스의 방문 페이지 보고서와 카탈로그 내보내기가 선택에 도움이 됩니다.
모든 중요한 템플릿과 결제 상태에 이름이 붙은 테스트 URL이 있고, 테스트할 수 없었던 항목은 “테스트하지 않음"으로 표시되면 완료입니다.
2. 크롤링 가능성, 색인, 캐노니컬, 사이트맵을 점검하세요
크롤 경로가 끊겨 있으면 상품을 더 많이 게시할수록 영향을 받는 URL의 수만 늘어납니다. 서로 상충하는 신호는 문제 진단을 더 어렵게 만듭니다. robots 규칙은 한 가지를 말하는데, 캐노니컬 태그와 사이트맵은 전혀 다른 것을 말할 수 있습니다.
robots.txt, XML 사이트맵, 응답 코드, robots 메타 태그와 헤더, 캐노니컬 태그, 페이지네이션, 내부 링크를 검토하세요. Search Console의 URL 검사를 사용해 Google이 표본 페이지에 대해 실제로 어떤 캐노니컬을 선택했는지 확인하세요. 그런 다음 사이트맵을 현실과 비교하세요. 사이트맵에는 리디렉션, 오류, noindex 페이지, 중복이 아니라 200 상태를 반환하는 실제 색인 가능한 페이지가 나열되어야 합니다.
의도한 방문 페이지가 200을 반환하고, 크롤링 가능하며, 일관된 캐노니컬과 색인 정책을 따르고, 사이트맵에 포함되면 완료입니다. 중요한 제외 항목마다 설명이나 담당자가 있어야 합니다.
3. 링크를 따라가세요: 리디렉션, 오류, 자바스크립트
스토어가 브라우저에서는 완전해 보여도 크롤러와 보조 기술에는 훨씬 빈약한 버전으로 보일 수 있습니다. 크롤러를 실행해 깨진 내부 링크, 리디렉션 체인, 루프, 소프트 404를 찾으세요. 그런 다음 렌더링된 페이지를 원시 HTML과 비교하세요. 상품 카드, 페이지네이션, 브레드크럼, 카테고리 링크는 실제로 존재하고 크롤링 가능해야 하며, 중요한 콘텐츠가 자바스크립트에만 의존해서는 안 됩니다.
내부 링크가 최종 목적지로 곧바로 연결되고, 오류 페이지가 올바른 상태 코드를 반환하며, 무한 스크롤에 의존하지 않고도 우선순위 상품을 찾을 수 있으면 완료입니다.
4. 카테고리, 필터, 페이지네이션, 사이트 검색을 테스트하세요
카테고리와 필터 시스템은 검색 엔진에는 크롤 트랩을, 쇼핑객에게는 불편을 동시에 만들 수 있습니다. 페이지가 기술적으로 색인 가능하더라도 그 안의 상품 절반이 관련성이 없다면 약한 방문 페이지입니다.
데스크톱과 모바일에서 필터를 사용해 보세요. 다중 선택, “전체 지우기”, 결과 개수, 정렬, 페이지네이션 또는 “더 보기”, 결과가 없는 필터 조합을 확인하세요. 필터가 생성하는 URL을 살펴보고 스토어의 색인 정책과 비교하세요. 긴 카테고리 설명 텍스트가 상품 그리드를 스크롤 아래로 밀어내는지도 주의 깊게 보세요.
컨트롤이 일관되게 동작하고, 임의의 필터 조합이 의도치 않은 방문 페이지로 바뀌지 않으며, 쇼핑객이 보던 위치를 잃지 않고 필터를 되돌릴 수 있으면 완료입니다.
2단계: 상품 데이터가 진실을 말하고 있는가?
5. 상품 식별 정보, 가격, 재고, 옵션을 대조하세요
잘못된 필드 하나는 쇼핑객을 오도할 뿐 아니라 결제 단계의 불일치까지 초래할 수 있습니다. 한편 데이터는 형식이 완벽하면서도 여전히 틀릴 수 있습니다.
대표성 있는 상품 몇 개를 골라 이름, 브랜드, SKU, GTIN 또는 EAN, 선택된 옵션, 가격, 통화, 재고 상태, 이미지, 주요 사양을 그것이 나타나는 모든 곳에서 비교하세요. 페이지에 표시되는 내용, 구조화 데이터, 판매자 피드, 장바구니, 결제 단계에서 확인하세요. 할인 상품, 옵션 상품, 품절 상품, 예약 판매 상품, 단종 상품도 포함하세요.
표본으로 삼은 사실이 모든 접점에서 일치하고, 브랜드와 제조사의 차이처럼 의도적인 차이가 있다면 데이터 모델에 명시되어 있으면 완료입니다.
6. 구조화 데이터를 쇼핑객이 보는 내용과 대조해 검증하세요
구조화 데이터는 페이지를 정확히 설명할 때만 도움이 됩니다. 검증기는 페이지와 결제 단계가 모두 해당 상품을 구매 불가라고 말하는 동안에도 “InStock"을 문제없이 통과시킵니다. 그래서 각 상품 상태를 Google 리치 결과 테스트나 Schema.org 검증기로 실행해야 합니다. 그런 다음 마크업된 값과 실제 화면에 보이는 콘텐츠, 소스 피드를 비교하세요. 옵션이 있는 상품의 경우, 마크업 방식과 캐노니컬 설정이 실제 페이지 구성 방식과 일치하는지 확인하세요.
표본으로 삼은 대상 페이지에 필수 속성이 빠져 있지 않고, 마크업이 화면에 보이는 내용과 일치하며, 리뷰와 평점이 쇼핑객이 해당 상품에서 볼 수 있을 때만 마크업되어 있으면 완료입니다.
3단계: 실제 쇼핑객에게 스토어가 빠른가?
7. 먼저 필드 데이터로 Core Web Vitals를 측정하세요
실제 사용자 데이터와 Lighthouse 한 번의 실행은 서로 다른 질문에 답합니다. Lighthouse는 문제를 재현하는 데 도움이 되지만, 실제 쇼핑객이 통과하는지 실패하는지는 알려주지 못합니다.
PageSpeed Insights와 Search Console의 Core Web Vitals 보고서로 시작하세요. 필드 데이터가 정확히 해당 URL에 대한 것인지, 아니면 사이트 전체에 대한 것인지 확인하세요. 75번째 백분위수에서 측정되는 Google의 “좋음” 기준은 다음과 같습니다:
- LCP(로딩): 2.5초 이하
- INP(반응성): 200밀리초 이하
- CLS(시각적 안정성): 0.1 이하
모바일과 데스크톱을 각각 따로 보세요. 필드 데이터가 없다면 결과를 알 수 없음으로 기록하고 랩 결과는 잠정적인 것으로 취급하세요. 알 수 없음은 초록색과 같지 않습니다.
각 우선순위 템플릿에 기기별 필드 판정이 있거나 데이터 부족이 명확히 기재되어 있고, 출처와 기간이 기록되어 있으면 완료입니다.
8. 점수가 아니라 원인을 찾으세요
“이미지를 압축하세요"나 “자바스크립트를 줄이세요” 같은 일반적인 조언은 실제 병목을 놓치고 실패한 지표를 개선하지 못하는 작업만 만들어 내는 경우가 많습니다. 책임이 있는 특정 요소, 요청, 스크립트를 찾으세요.
LCP 요소가 무엇이고 무엇이 이를 지연시키는지 파악하세요. 그런 다음 이미지 크기, 스크롤 위 이미지의 지연 로딩, 렌더링 차단 CSS, 폰트 로딩, 서드파티 스크립트, 긴 작업, 캐싱, 서버 응답 시간, 레이아웃 이동 원인, 두 번 로드되는 태그 등 흔한 용의자들을 확인하세요.
동일한 조건에서 테스트를 반복하고, 최고 기록이 아니라 일관된 통계값을 비교하세요. Total Blocking Time은 유용한 랩 신호이지만 INP는 아니라는 점을 기억하세요.
중요한 모든 성능 발견 사항에 실패한 지표, 영향을 받는 템플릿, 재현 가능한 원인, 담당자가 명시되면 완료입니다.
뉴스레터 가입
최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.
4단계: 사람들이 실제로 구매할 수 있는가?
9. 실제 쇼핑 컨트롤에서 모바일 사용성과 접근성을 테스트하세요
자동화 점수는 모든 상호작용을 포괄하지 못합니다. 필터 드로어가 키보드 포커스를 가두거나, 쿠키 배너가 장바구니 담기 버튼을 가리거나, 사이즈 선택기에 접근 가능한 레이블이 없어도 스토어는 스캔을 통과할 수 있습니다.
360~390픽셀의 휴대폰 너비에서 테스트하고, 텍스트를 확대하고, 키보드만으로 전체 여정을 시도해 보세요. 메뉴, 드로어, 대화 상자에서 포커스 순서와 가시성을 확인하세요. 레이블, 버튼, 양식 오류, 터치 대상이 여전히 이해 가능한지 점검하세요.
쇼핑객이 숨겨진 컨트롤이나 포커스 트랩 없이 주요 여정을 통과할 수 있고, 모바일에서 가격, 재고 상태, 옵션 선택, 장바구니 담기 버튼, 결제를 가리는 것이 없으면 완료입니다.
10. 장바구니와 결제를 통제된 테스트로 실행하세요
결제 버튼이 보인다고 해서 결제가 작동한다는 증거는 아닙니다. 결제 버그는 상업적 사고이며, 애널리틱스까지 훼손합니다.
이를 테스트하려면 일반 상품과 옵션 상품을 장바구니에 담으세요. 수량을 변경하고, 항목을 제거하고, 쿠폰(또는 의도적으로 잘못된 쿠폰)이 있다면 적용해 보세요. 그런 다음 비회원 결제와 회원 결제, 배송 옵션, 결제 수단 선택, 유효성 검사 오류, 뒤로 가기 버튼, 모바일 레이아웃을 테스트하세요. 테스트 주문이나 승인된 비청구 경로를 사용하세요. 허가 없이 실제 주문을 절대 넣지 마세요.
구매가 완료되거나 합의된 테스트 경계에 도달하고, 합계가 정확하게 유지되며, 오류 메시지가 사용자에게 무엇을 해야 하는지 알려주고, 차단된 경로가 있다면 증거와 비즈니스 영향을 포함해 문서화되면 완료입니다.
5단계: 여정을 올바르게 측정하고 있는가?
11. 애널리틱스, 중복 태그, 동의를 검증하세요
중복 태그는 페이지뷰, 장바구니 담기 이벤트, 구매 수치를 부풀립니다. 누락되거나 잘못된 값은 매출 보고서를 의사 결정의 근거로 쓰기 어렵게 만듭니다. 목표는 단순합니다. 쇼핑객의 한 행동은 올바른 상품, 금액, 통화, 거래 ID, 동의 상태를 담은 하나의 이벤트를 만들어야 합니다.
모든 태그 관리자 컨테이너, Google 태그, 광고 픽셀, 제휴 스크립트, 서버 측 연동을 나열하세요. 그런 다음 통제된 세션에서 view_item, add_to_cart, begin_checkout, purchase를 추적하세요. 브라우저가 전송하는 내용을 GA4 DebugView와 백엔드의 주문 기록과 비교하세요. 쇼핑객이 동의를 선택하기 전과 후를 모두 테스트하세요.
각 행동이 해당 이벤트를 정확히 한 번 발생시키고, 구매에 안정적인 거래 ID가 있으며, 금액과 통화가 백엔드와 일치하고, 필수가 아닌 태그가 동의 정책을 준수하면 완료입니다.
12. Search Console과 Merchant Center를 발견한 내용과 대조하세요
로컬 페이지 테스트만으로는 모든 색인된 캐노니컬, 사이트맵 경고, 상품 비승인, 유실된 검색어를 보여줄 수 없습니다. 반대로 대시보드 알림은 이미 해결된 문제를 설명하고 있을 수도 있습니다.
Search Console에서 우선순위 URL을 검사하고, 상품 및 판매자 목록 보고서를 검토하고, Merchant Center 진단 결과를 실제 사이트에서 본 내용과 비교하세요. 재크롤링과 피드 처리는 배포보다 늦기 때문에 날짜를 기록해 두세요.
중요한 모든 대시보드 문제가 실제 증거와 일치하거나 전파 대기 중으로 표시되고, 열려 있는 각 문제에 담당자가 있으면 완료입니다.
6단계: 쇼핑객이 이 스토어를 신뢰할까?
13. 신뢰 신호, 연락처, 배송, 반품을 확인하세요
숨겨져 있거나 상충하는 상거래 정보는 쇼핑객의 망설임을 키우고 지원 문의를 늘립니다. 헤더와 푸터, 연락처 페이지, 결제, 정책 페이지를 비교하세요.
비즈니스 정체성이 명확하고, 배송·반품·결제 관련 안내가 여정 전반에서 일치하며, 검증할 수 없는 신뢰 배지가 없으면 완료입니다.
14. HTTPS, 혼합 콘텐츠, 프런트엔드 위생을 확인하세요
이것은 침투 테스트가 아니라 기본적인 데이터 위생의 문제입니다. HTTP가 한 번의 홉으로 HTTPS로 리디렉션되는지, 인증서가 유효한지, 혼합 콘텐츠가 없는지, 양식이 올바르게 제출되는지 확인하세요. 콘솔에서 심각한 오류를 확인하세요. 실제 보안 취약점으로 보이는 것이 있다면 일반적인 경고만으로 진단하지 말고 전문가에게 넘기세요.
우선순위 페이지와 결제가 안전하게 로드되고, 리디렉션이 한 번의 홉으로 처리되며, 양식이 예상대로 동작하면 완료입니다.
발견에서 수정으로
15. 발견 사항을 담당자가 지정된 개선 대기열로 바꾸세요
스크린샷이나 점수로 끝나는 감사는 위험을 줄이지 못합니다. 고장 난 템플릿 하나 때문에 생긴 증상 50개가 서로 무관한 티켓 50개가 되어서는 안 됩니다. 발견 사항을 근본 원인별로 묶으세요. 그것이 컴포넌트인지, 템플릿인지, 피드 규칙인지, 트래킹 설정인지 기록하세요. 영향을 받는 URL은 증거로 남겨 두세요. 그런 다음 우선순위를 정하세요:
- P0: 비즈니스를 막는 진행 중인 장애 또는 사이트 전반의 치명적 문제
- P1: 확신할 수 있는 중대한 결함
- P2: 범위가 제한적인 중요한 문제
- P3: 모니터링할 개선 사항
중요한 모든 발견 사항에 하나의 담당자, 마감일, “수정됨"을 판정할 테스트, 릴리스 후 다시 확인할 날짜가 있으면 완료입니다.
산출물
발견 사항별로 한 행씩 구성되고 상단에 짧은 요약이 있는 버전 관리되는 문서나 스프레드시트를 전달하세요. 각 행에는 다음이 포함되어야 합니다:
- 동작,
- 기대 동작,
- 영향을 받는 URL,
- 증거와 수집 시점,
- 심각도와 확신도,
- 추정 원인,
- 권장 수정 사항,
- 담당자와 완료를 입증하는 테스트.
하지만 누군가 티켓을 닫았다고 해서 문제를 수정됨으로 표시해서는 안 된다는 점을 기억하세요. 프로덕션에서 테스트가 통과할 때 검증됨으로 표시하세요.
작업에 필요한 도구
탄탄한 첫 점검을 성공적으로 수행하는 데 어떤 유료 구독도 필요하지 않습니다. 다음 무료 도구만 있으면 됩니다:
- Google PageSpeed Insights — 필드 데이터(있는 경우)와 Lighthouse 진단용
- Google Search Console — 색인, 사이트맵, URL 검사, Core Web Vitals, 구조화 데이터 보고서용
- Google 리치 결과 테스트 와 Schema.org 검증기 — 구조화 데이터용
- Chrome DevTools와 Lighthouse — 네트워크, 성능, 레이아웃 이동, 접근성, 콘솔 점검용
- Google Tag Assistant 와 GA4 DebugView — 이벤트 트래킹용
- SSL Labs Server Test — TLS 설정용
지름길을 원한다면 AmICited 에서 이 모든 증거를 한데 모으고 기준선을 나중을 위해 보관할 수 있습니다. 성능 영향 보기는 LCP, INP, CLS, 서버 응답 시간으로 템플릿을 비교합니다. URL 검사 와 사이트맵 및 색인 는 우선순위 URL의 색인 상태를 추적합니다. 상품 과 구색 은 카탈로그의 어느 부분이 상업적으로 가장 중요한지 보여줍니다. 보고서 허브의 주석 은 각 릴리스를 그 이후에 일어난 일과 연결해 줍니다. 도구는 증거를 제공합니다. 무엇이 올바른지, 어떤 트레이드오프가 허용 가능한지는 여전히 스토어 오너, 개발자 또는 분석가가 결정합니다.
감사 이후
확인된 각 문제를 그것을 해결할 수 있는 전문 워크플로로 보내세요: 크롤링 및 렌더링 문제는 기술 SEO 감사 로, 필드 성능 실패는 Core Web Vitals 개선 으로, 패싯과 재고 상태 문제는 카테고리 및 상품 검토 로, 트래킹 문제는 애널리틱스를 담당하는 사람에게 보내세요.
모든 수정 후에 전체 감사를 다시 실행할 필요는 없습니다. 영향을 받은 영역을 재테스트하고, 릴리스에 주석을 달아 이후 무엇이 바뀌었는지 확인할 수 있게 하고, 다음 퇴행은 정기 상태 점검이 잡아내도록 하세요.
모든 것이 정상으로 보였던 스토어로 돌아가서
처음의 그 스토어를 기억하시나요? 홈페이지는 색인되어 있었고, Lighthouse는 초록색이었으며, 검증기는 깨끗했습니다. 그런데도 Google Shopping은 잘못된 가격을 보여주었고, 필터 드로어는 키보드 사용자를 가두었으며, 모든 판매는 두 번 집계되었습니다.
어떤 대시보드도 이를 알려주지 않았습니다. 이 체크리스트였다면 세 가지 모두를 잡아냈을 것입니다: 5단계의 가격 불일치, 9단계의 포커스 트랩, 11단계의 이중 집계된 구매입니다. 각각은 쇼핑객의 경로 어딘가에서 깨지며, 바로 그 지점을 감사가 들여다봅니다.
이것이 사이트맵 대신 쇼핑객을 따라갈 때 얻는 결과입니다. “사이트가 건강해 보이는가?“라는 질문을 멈추고, 더 어려운 네 가지 질문을 던지기 시작합니다. 사람들이 상품을 찾을 수 있는가? 스토어가 상품에 대해 말하는 것이 사실인가? 실제로 구매할 수 있는가? 그리고 그들이 구매했음을 확인할 수 있는가? 이 네 가지에 모두 “예"라고 답할 수 있는 스토어는 완벽한 점수를 받은 스토어보다 더 나은 상태입니다.
그러니 표본 URL을 고르고, 시간을 확보하고, 1단계부터 시작하세요. 첫 점검이 가장 느립니다. 그 이후의 작업은 대부분 고친 것이 고쳐진 상태로 유지되도록 확인하는 일입니다.
