전자상거래 플랫폼 SEO
Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce Cloud, Shopware, OpenCart, Ecwid, Wix, Squarespace, PrestaShop 등 전자상거래 플랫폼의 SEO를 설명합니다. 각 플랫폼이 자동으로 처리하는 작업, 제한하는 설정, 자연 검색 성과에 영향을 주는 고유한 특성을 다룹니다.
이 페이지의 근거 신호 1개
- 관련 라이브 도구 Faceted Navigation Auditor
모든 전자상거래 플랫폼은 상품을 하나도 등록하기 전부터 스토어 SEO에 영향을 주는 결정을 내립니다. Shopify는 URL 구조를 고정하지만 canonical과 사이트맵을 자동 처리합니다. WordPress 기반 WooCommerce는 플러그인으로 모든 설정을 제어합니다. Magento는 유연하지만 대부분의 SEO 설정에 개발 작업이 필요합니다. BigCommerce는 Shopify보다 유연하고 Magento보다 개발 부담이 적은 중간 지점입니다. 어느 플랫폼도 그 자체로 순위에 더 유리하지 않습니다. 스토어의 상품, 카테고리, 변형, 피드, 현지화, 운영 요건에 맞춰 선택한 뒤 실제 구현 결과를 검증해야 합니다. 네 플랫폼 모두 상품 스키마, 패싯 탐색, 변형과 컬렉션에서 생기는 중복 URL, 페이지네이션이라는 전자상거래 고유 문제를 안고 있습니다.
이 주장에 대한 근거 Regardless of platform, Google needs crawlable product links and consistent product data. 범위: Search-engine requirements independent of platform. 신뢰도: 높음 · 검증일: Google Search Central: Ecommerce site structure 이 주장에 대한 근거 Platform automation varies; Shopify, for example, automatically generates canonical tags and sitemap files but still exposes merchant-controlled SEO fields. 범위: Shopify-specific example, not a search-engine rule. 신뢰도: 높음 · 검증일: Shopify Help: SEO overview요약 — 전자상거래 플랫폼은 HTTPS, 사이트맵, canonical 태그 등 일부 SEO 작업을 자동 처리하지만, 각 플랫폼에는 모르면 손해를 볼 수 있는 특성이 있습니다. 가장 흔한 문제는 여러 컬렉션에 나타나는 상품의 중복 URL(Shopify), 내용이 빈약한 카테고리 페이지(모든 플랫폼), 색인할 필요가 없는 수백만 개의 매개변수 URL을 만드는 패싯 탐색입니다. 어느 플랫폼도 본질적으로 순위에 더 유리하지 않습니다. 상품, 카테고리, 변형, 운영 요건에 맞는 플랫폼을 고른 뒤 실제 출력 결과를 확인하세요.
전자상거래 플랫폼 SEO가 다른 이유
일반 웹사이트에는 페이지가 있습니다. 전자상거래 스토어에는 페이지뿐 아니라 상품, 카테고리, 변형, 컬렉션, 필터, 페이지네이션도 있습니다. 각각 URL을 만들며 모든 URL을 색인해야 하는 것은 아닙니다.
여기서 다루는 플랫폼은 이 문제를 처리하는 기본 설정이 서로 다릅니다.
- Shopify — URL 구조(
/products/,/collections/)를 고정하고 중복 컬렉션-상품 URL을 자동으로 canonical 처리하며 사이트맵을 생성합니다. 표준 요금제에서는 robots.txt 편집이 제한됩니다. - WooCommerce — WordPress에서 실행되므로 Yoast, Rank Math 같은 SEO 플러그인의 모든 기능을 제어할 수 있습니다. 더 유연하지만 설정할 것도 많습니다.
- Magento(Adobe Commerce) — 엔터프라이즈급이며 매우 유연하지만 대부분의 SEO 설정에 개발자 참여가 필요합니다.
- BigCommerce — Shopify보다 유연하고 Magento보다 개발 부담이 적습니다. 기본 SEO 설정도 견고합니다.
아래 비교는 이 네 플랫폼에 집중하지만, 페이지 하단의 플랫폼별 심층 글에서는 Salesforce Commerce Cloud, Shopware, OpenCart, Ecwid, Wix eCommerce, Squarespace Commerce, PrestaShop도 다룹니다.
전자상거래 고유의 SEO 문제
플랫폼과 관계없이 모든 전자상거래 스토어는 다음 문제를 마주합니다.
상품 구조화 데이터 — 가격, 재고, 리뷰를 담은 Schema.org Product 마크업은 페이지가 Google의 더 풍부한 표시 형식에 노출될 자격을 갖게 할 수 있지만 표시를 보장하지는 않습니다. 일부 플랫폼은 자동으로 넣고, 다른 플랫폼은 플러그인이나 테마가 필요합니다. 플랫폼의 마케팅 문구가 아니라 실제 페이지 출력을 검사해야 합니다.
패싯 탐색 — 필터 매개변수(?color=red&size=M)는 거의 같은 콘텐츠의 URL을 수천 개 만들 수 있습니다. 대부분은 색인하지 않도록 차단하거나 기본 카테고리 페이지로 canonical 처리해야 합니다.
변형에서 생기는 중복 URL — 크기와 색상 조합이 10개인 상품을 10개 페이지로 색인할 필요는 없습니다. canonical 태그나 매개변수 처리로 이를 막습니다.
품절 및 단종 상품 — 플랫폼이 사라진 상품을 404로 처리할지, 카테고리로 301을 보낼지, 재고 구조화 데이터를 갱신한 채 유지할지는 링크 가치와 사용자 경험에 직접 영향을 줍니다.
페이지네이션 — 카테고리 페이지에는 페이지 구분이 있습니다. /collections/shoes/의 2페이지는 1페이지보다 콘텐츠가 빈약합니다. 처리 방식은 플랫폼마다 다릅니다.
이 주장에 대한 근거 Regardless of platform, Google needs crawlable product links and consistent product data. 범위: Search-engine requirements independent of platform. 신뢰도: 높음 · 검증일: Google Search Central: Ecommerce site structure 이 주장에 대한 근거 Platform automation varies; Shopify, for example, automatically generates canonical tags and sitemap files but still exposes merchant-controlled SEO fields. 범위: Shopify-specific example, not a search-engine rule. 신뢰도: 높음 · 검증일: Shopify Help: SEO overview요약 — 대규모 전자상거래 플랫폼 SEO의 핵심은 대량 URL의 canonical 처리 방식, 자동 또는 수동 구조화 데이터 범위, robots.txt와 사이트맵의 제어 가능성, 패싯 탐색 전략입니다. Shopify는 기본 설정이 가장 강하게 정해져 있어 유연성이 가장 낮고, WooCommerce는 제어권이 가장 크며, Magento는 기능이 가장 강력하지만 설정 비용도 가장 큽니다. 이는 순위상 이점이 아니라 설정 작업의 책임자가 누구인지를 나타냅니다. Google은 어느 CMS로 만들었는지가 아니라 실제 구현이 출력하는 페이지, 링크, 데이터를 평가합니다.
플랫폼 선택 방법
기능 체크리스트나 “SEO에 가장 좋은 플랫폼” 순위가 아니라 스토어의 실제 요건에 맞춰 선택하세요. 어느 상거래 플랫폼도 본질적으로 검색 순위에 우월하지 않습니다. 아키텍처는 만들 수 있는 것을 제한하거나 가능하게 할 뿐, 결과는 구체적인 구현의 크롤링 가능성, 구조화 데이터 정확성, 렌더링 결과, 성능, 콘텐츠, 지속적인 운영이 결정합니다. 공급업체를 비교하기 전에 다음 차원을 검토하세요.
- 상품 데이터 — 상품, 가격, 재고, 리뷰 데이터가 페이지에 도달하는 방식과 자동 처리인지, 테마 의존인지, 플러그인·모듈 기반인지 확인합니다.
- 카테고리 및 패싯 구조 — 플랫폼 템플릿이 탐색 메뉴에서 카테고리, 상품까지 크롤링 가능한 링크를 제공하는지와 필터(패싯) URL 처리 방식을 봅니다.
- 변형 아키텍처 — 상품마다 canonical URL 하나, 변형마다 별도 URL, 또는 둘 다 지원하는지와 카탈로그에 미치는 영향을 확인합니다.
- 현지화와 피드 — 다지역·다국어 지원과 상품 피드가 스토어프런트에 동기화되는 방식을 봅니다.
- 게시 및 출시 과정 — 템플릿, robots.txt, 리디렉션을 누가 얼마나 빨리 바꿀 수 있는지 확인합니다.
- 운영 책임 — 상품 수명주기, 카테고리 관리, 리디렉션, 사이트맵 최신성, 출시 테스트, 장애 대응의 책임자를 정합니다.
이 제어권은 플랫폼마다 다르게 배분됩니다. 호스팅 플랫폼, 플러그인, 테마, 모듈, 맞춤 코드는 설정 권한을 서로 다른 담당자에게 둡니다. 설정 가능성이 높다는 것은 보통 구현과 유지관리 책임이 더 크다는 뜻이지 본질적인 SEO 능력이 더 뛰어나다는 뜻이 아닙니다. 특정 플랫폼의 기능을 주장할 때는 적용되는 공급업체, 에디션, 요금제, 테마, 앱·모듈, 버전, 날짜를 밝혀야 합니다. 기본값은 바뀌고 요금제나 앱이 덮어쓸 수 있습니다.
플랫폼 비교
| 항목 | Shopify | WooCommerce | Magento | BigCommerce |
|---|---|---|---|---|
| URL 구조 | 고정(/products/, /collections/) | WordPress에서 설정 가능 | 매우 유연 | 부분적으로 유연 |
| robots.txt | 잠김(표준 요금제) | 완전 제어 | 완전 제어 | 부분 제어 |
| 사이트맵 | 자동 생성 | 플러그인(Yoast/Rank Math) | 내장 + 설정 가능 | 자동 생성 |
| 상품 스키마 | 테마 의존 | 플러그인 | 모듈 | 기본 기능 내장 |
| 패싯 탐색 | URL 매개변수 사용, 처리 필요 | 플러그인 또는 맞춤 개발 | 내장 계층형 탐색 설정 | 내장 패싯, 설정 가능 |
| canonical 태그 | 자동(컬렉션→상품 URL) | 플러그인 | 내장 | 내장 |
| 리디렉션 관리 | 관리자 내장 | 플러그인(Redirection) | 내장 + 설정 가능 | 내장 |
| 개발자 필요 수준 | 낮음 | 낮음~중간 | 높음 | 중간 |
변형 아키텍처: URL 하나 또는 여러 개
Google의 상품 구조화 데이터 문서는 상품 변형에 한 가지 이상의 지원 방식을 제시합니다. 필요한 URL 개수는 하나로 정해져 있지 않습니다. 모든 색상·크기 조합을 canonical 상품 URL 하나에 두고 ProductGroup 데이터로 변형을 설명할 수도 있고, 각 변형에 별도 URL을 주고 그룹으로 연결할 수도 있습니다. 두 방식 모두 문서화되어 있으며 내부 링크를 받을 URL, 그룹 선언 방식, 각 변형 페이지의 요건이 다릅니다. 플랫폼과 카탈로그 규모가 제대로 지원하는 방식을 선택하고 라이브 마크업이 선택한 설계와 일치하는지 확인하세요. 플랫폼 기본값이 테마나 앱의 실제 출력과 같다고 가정하지 마세요.
컬렉션/상품 중복 URL 문제
가장 흔한 전자상거래 canonical 문제는 상품 하나에 여러 URL로 접근할 수 있다는 것입니다.
-
Shopify:
/products/blue-shirt와/collections/summer/products/blue-shirt— Shopify는 컬렉션 URL의 canonical을/products/로 자동 지정합니다. 기본적으로 올바르게 작동하지만 내부 링크는/products/만 가리켜야 합니다. -
WooCommerce: 카테고리 기반 URL에서도 비슷합니다(예:
/product-category/shirts/blue-shirt와/shop/blue-shirt). Yoast 또는 Rank Math가 canonical 태그를 설정하며 중복을 줄이도록 고유주소 구조를 검토해야 합니다. -
Magento: 계층형 탐색(필터)이 중복 URL의 주된 원인입니다. 필터 페이지에 canonical 태그를 설정하거나 robots.txt에서 매개변수를 차단하세요.
-
BigCommerce: 상품 URL이 여러 카테고리 아래 나타날 수 있습니다. 상품별 “Canonical URL” 설정으로 선호 경로를 제어합니다.
플랫폼별 패싯 탐색 처리
플랫폼 메커니즘보다 검색 의도에서 시작하세요. 독립적으로 색인할 랜딩 페이지가 필요한 필터 조합과 단순한 크롤링 예산 소모 URL을 구분합니다. Google 지침은 패싯 URL의 크롤링을 차단하거나 색인할 가치가 있는 URL을 최적화하는 선택으로 설명합니다. 어느 쪽이든 URL 수가 폭증할 수 있으므로 먼저 전략을 정한 뒤 플랫폼에서 구현 가능한 방식에 연결해야 합니다.
- Shopify: 일부 테마는 쿼리 매개변수(
?filter.p.m.color=red)를 기본적으로 색인합니다. 필터 페이지에 robots metanoindex를 사용하거나 Search Console URL Parameters 도구에 매개변수를 추가하세요. - WooCommerce: WOOCS/필터 플러그인이 매개변수 URL을 만듭니다. 필터 페이지의
noindex와 Rank Math/Yoast URL 매개변수 설정을 함께 사용하세요. - Magento(Adobe Commerce): 표준 “Layered Navigation”은 카탈로그 속성으로 필터 URL을 만듭니다. 카탈로그 권한과 URL 재작성 시스템으로 세밀하게 제어할 수 있고 카테고리 수준에서 canonical 태그를 설정할 수 있습니다. 별도 라이선스 제품인 Adobe Commerce Live Search는 표준 계층형 탐색과 다르게 동작하는 자체 패싯을 사용합니다. 스토어의 패싯 기능을 설명하기 전에 실제 설정된 방식을 확인하세요. 기능은 “Magento”라는 이름만이 아니라 에디션과 부가 기능 설정에 달려 있습니다.
- BigCommerce: Store Settings → Search의 내장 설정으로 패싯 검색 URL의 canonical을 기본 카테고리로 지정할 수 있습니다.
전자상거래 플랫폼 SEO에는 표준 기술 SEO 외에 상품 구조화 데이터, 패싯 탐색 매개변수 처리, 상품 변형과 컬렉션에서 생기는 중복 URL, 품절 상품 전략, 페이지네이션이라는 복잡성이 추가됩니다. 어느 상거래 플랫폼도 본질적으로 순위에 우월하지 않습니다. 스토어의 상품, 카테고리, 변형, 피드, 현지화, 게시, 운영 요건에 따라 선택한 뒤 구체적인 구현(테마, 앱, 모듈, 요금제, 버전)이 실제로 출력하는 내용을 검증하세요. 기본값은 바뀌고 설정이 이를 덮어쓸 수 있습니다.
Shopify: URL 구조(/products/, /collections/, /pages/, /blogs/)가 고정됩니다. 사이트맵과 canonical 태그를 자동 생성합니다. /products/slug와 /collections/name/products/slug로 모두 접근 가능한 컬렉션-상품 중복 문제를 canonical로 자동 처리합니다. 표준 요금제에서 robots.txt는 잠겨 있고 Shopify Plus에서는 맞춤 설정할 수 있습니다. 상품 스키마는 테마에 따라 다릅니다.
WooCommerce: WordPress 기반이므로 SEO 플러그인을 완전히 제어할 수 있습니다. Yoast SEO 또는 Rank Math가 메타데이터, 사이트맵, canonical 태그, 리디렉션, 스키마를 처리합니다. 네 플랫폼 중 가장 유연하지만 설정도 가장 많이 필요합니다. 상품 URL 구조는 WordPress 고유주소 설정에 달려 있습니다.
Magento(Adobe Commerce): 엔터프라이즈급 유연성을 제공합니다. URL 재작성, canonical 태그, 계층형 탐색 설정이 내장됩니다. 대부분의 SEO 설정에 개발자 또는 관리자 작업이 필요합니다. 대규모 운영에 강하지만 초기 설정 부담이 큽니다.
BigCommerce: 간편한 Shopify와 강력한 Magento의 중간에 있습니다. 자동 사이트맵, canonical 태그, 리디렉션 관리자, 기본 구조화 데이터 등 내장 SEO 기본값이 견고합니다. URL 구조에도 어느 정도 유연성이 있습니다. Store Settings에서 패싯 검색 설정을 구성할 수 있습니다.
모든 플랫폼에 공통된 문제는 상품 구조화 데이터(자동 또는 플러그인/테마 기반이며 리치 결과 자격만 제공하고 표시를 보장하지 않음), 필터·변형 URL의 canonical 처리, 사이트맵의 상품·카테고리 포함 범위, 단종 상품 리디렉션 관리입니다. 변형 아키텍처에는 여러 문서화된 방식이 있습니다. ProductGroup 데이터를 사용하는 단일 canonical 상품 URL이나 그룹으로 연결한 변형별 URL 모두 가능하므로 올바른 URL 개수가 하나라고 가정하지 말고 플랫폼과 카탈로그에 맞추세요. 패싯 탐색 전략은 특정 필터 조합에 독립적인 검색 노출 가치가 있는지부터 판단한 뒤 플랫폼 메커니즘에 연결해야 합니다. Adobe Commerce에서는 표준 계층형 탐색과 별도 라이선스의 Live Search 패싯이 다르게 작동하므로 어떤 기능이 설정됐는지 밝혀야 합니다.
전자상거래 플랫폼 SEO 감사 체크리스트
모든 플랫폼
- XML 사이트맵이 모든 상품과 카테고리를 포함하고 필터·매개변수 URL은 제외하는지 확인합니다.
- 모든 상품 및 카테고리 페이지에 canonical 태그가 있는지 확인합니다.
- 패싯 탐색 URL이 차단, noindex, canonical 중 하나로 처리되는지 확인합니다.
- 상품 구조화 데이터(Schema.org Product)에 가격, 재고, 리뷰가 포함되는지 확인합니다.
- 단종이나 슬러그 변경으로 상품 URL이 바뀌면 리디렉션을 설정합니다.
- 페이지네이션을 검토합니다. 2페이지 이후를 색인할 만큼 고유한 콘텐츠가 있는지 확인합니다.
- 품절 상품 처리 방식을 확인합니다. 404, 유지 후 갱신, 리디렉션 중 무엇인지 봅니다.
Shopify 전용
- 내부 상품 링크가
/collections/.../products/가 아니라/products/를 가리키게 합니다. - 테마의 상품 스키마 삽입을 검토하고 Rich Results Test로 시험합니다.
- URL 변경에는 Shopify 리디렉션 관리자를 사용합니다.
- Shopify Plus에서는 robots.txt를 맞춤 설정해 빈약한 URL을 차단합니다.
WooCommerce 전용
- SEO 플러그인은 Yoast 또는 Rank Math 중 하나만 설치하고 둘 다 사용하지 않습니다.
- WooCommerce 상품 고유주소 구조를 설정합니다.
- 플러그인의 상품 스키마 설정을 구성합니다.
- WooCommerce 보관 페이지(shop, product-category)를 처리하고 빈약한 페이지는 noindex로 지정합니다.
Magento 전용
- 계층형 탐색 URL의 canonical 태그를 설정합니다.
- URL 재작성 규칙을 검토하고 불필요한 중복을 제거합니다.
- 크롤링하지 않을 매개변수 URL을 robots.txt에서 차단합니다.
- Magento 내장 HTML 사이트맵과 XML 사이트맵을 활성화합니다.
BigCommerce 전용
- 상품 설정에서 상품별 canonical URL을 지정합니다.
- 패싯 검색 설정(Store Settings → Search)을 검토합니다.
- Search Console의 사이트맵 제출 상태를 확인합니다.
- URL 변경에는 BigCommerce 내장 리디렉션 관리자를 사용합니다.
전자상거래 플랫폼 검사 도구
- Faceted Navigation Auditor — 필터 조합이 크롤링 또는 색인 가능한 URL 목록을 만드는지 검사합니다.
- PDP SEO Checker — 플랫폼의 실제 출력을 사용해 상품 페이지 메타데이터, 구조화 데이터, canonical, 콘텐츠 신호를 검토합니다.
- Sitemap Validator — 공개된 상품과 카테고리 URL이 한 번씩 나타나고 canonical이며 정상 응답하는 목적지를 가리키는지 확인합니다.
- Redirect Chain Mapper — 상품 단종, 카테고리 변경, 이전 과정에 체인이나 관련 없는 목적지가 있는지 시험합니다.
플랫폼별 심층 가이드
- Shopify SEO
- WooCommerce SEO
- Magento SEO
- BigCommerce SEO
- Salesforce Commerce Cloud SEO
- Shopware SEO
- OpenCart SEO
- Ecwid SEO
- Wix eCommerce SEO
- Squarespace Commerce SEO
- PrestaShop SEO (Ecommerce Platforms 클러스터에 속함)
관련 글
이 플랫폼에서 스토어가 실제로 저지르는 실수
Shopify 내부 링크를 컬렉션 접두사가 붙은 상품 URL로 연결하기
내부 링크, 탐색 메뉴, 관련 상품 블록이 /products/blue-shirt 대신 /collections/summer/products/blue-shirt를 가리키는 경우입니다.
잘못된 이유 — Shopify는 컬렉션 접두사 URL의 canonical을 일반 상품 URL로 자동 설정하므로 색인 중복은 보통 생기지 않습니다. 하지만 긴 URL을 향한 모든 내부 링크는 canonical 페이지를 바로 가리키지 않고 신호를 다른 곳으로 넘기는 URL에 크롤링 예산과 링크 가치를 씁니다.
대신 할 일 — 컬렉션 문맥이 아니라 상품 핸들(/products/{{ product.handle }})로 테마 링크를 만들어 canonical URL로 직접 연결하세요.
WooCommerce에서 SEO 플러그인 두 개를 동시에 실행하기
“범위가 더 넓을 것”이라는 생각으로 Yoast SEO와 Rank Math 또는 다른 두 플러그인을 함께 설치하는 경우입니다.
잘못된 이유 — 두 플러그인이 각각 사이트맵, canonical 태그, 메타 출력을 생성합니다. 같은 필드를 두 플러그인이 동시에 담당하면 서로 충돌하는 canonical이나 중복 사이트맵 파일이 생깁니다. 전자상거래 SEO가 막아야 할 중복 문제를 스스로 만드는 셈입니다.
대신 할 일 — 플러그인 하나만 선택하고 다른 플러그인은 완전히 비활성화한 뒤 페이지 소스에서 canonical 태그와 메타 설명이 각각 하나만 출력되는지 확인하세요.
패싯 탐색을 모두 크롤링·색인 가능하게 두기
네 플랫폼 어디서든 필터 조합(?color=red&size=M)에 noindex, canonical, robots.txt 처리를 전혀 하지 않는 경우입니다.
잘못된 이유 — 필터 속성이 많지 않은 스토어도 거의 중복된 매개변수 URL을 수천 개 만들 수 있습니다. 크롤러는 실제 상품과 카테고리 대신 여기에 예산을 쓰며, 이 비교에 포함된 모든 플랫폼에서 가장 흔한 전자상거래 색인 문제입니다.
대신 할 일 — 필터 URL의 canonical을 기본 카테고리로 설정하거나 광고·UX 때문에 크롤링은 허용해야 한다면 noindex를 사용하세요. 차단 대상을 정하기 전에 Search Console에서 실제로 발견한 매개변수를 확인하세요.
리디렉션 계획 없이 상품 단종하기
“이제 품절”이라는 이유로 상품을 삭제하고 URL을 404로 두는 경우입니다.
잘못된 이유 — URL이 쌓은 외부 링크와 순위 이력이 사라집니다. 과거에 순위가 있었던 페이지의 하드 404는 사용자와 링크 가치를 아무 곳에도 보내지 않습니다.
대신 할 일 — 다시 입고될 상품이면 “품절” 구조화 데이터로 페이지를 유지하고, 영구 단종이면 가장 가까운 대체 상품이나 상위 카테고리로 301을 보내며, 더 이상 아무 링크도 없을 때만 404를 사용할지 상품별로 결정하세요.
상품 스키마가 자동으로 있다고 가정하기
“플랫폼이 알아서 한다”는 이유로 Schema.org Product 마크업을 당연한 것으로 보는 경우입니다.
잘못된 이유 — 플랫폼별 지원 범위가 크게 다릅니다. Shopify는 테마에 의존하고, WooCommerce는 플러그인이 필요하며, Magento는 모듈이 필요하고, BigCommerce의 기본값은 기초적인 수준입니다. 존재한다고 가정하고 넘어가면 가격과 재고 데이터가 리치 결과에서 사라져도 알아차리지 못합니다.
대신 할 일 — 플랫폼 홍보 문구를 믿지 말고 실제 상품 페이지를 Rich Results Test로 검사하세요. 페이지마다 고치지 말고 테마·플러그인 수준에서 누락을 해결하세요.
Magento 계층형 탐색을 설정하지 않은 채 두기
색상, 크기, 브랜드 같은 속성의 계층형(패싯) 탐색을 켜면서 생성 URL의 canonical 또는 색인 규칙을 설정하지 않는 경우입니다.
잘못된 이유 — 필터 조합이 빠르게 늘기 때문에 계층형 탐색은 Magento에서 가장 큰 중복 URL 원인입니다. 설정하지 않으면 실제 상품 수보다 훨씬 많은 크롤링 가능 URL이 생길 수 있습니다.
대신 할 일 — 카탈로그가 커져 크롤링 예산 문제가 되기 전에 카테고리 수준에서 canonical 태그를 설정하고 크롤링하지 않을 매개변수 조합을 차단하세요.
변경 내역
2026년 9월 21일에 업데이트됨.
편집 요약 및 기록된 변경 세부 정보입니다.요약
한국어 전체 의미를 원문과 대조 검토하고 컴포넌트 소스 경계, 번역 메모리 상태, 정수형 AI 개정 계보를 복구했습니다.
변경 세부 정보
-
101개 블록의 의미를 검토했으며, 세 개의 대형 컴포넌트 블록은 원문 구조를 그대로 복원하고 55개 한국어 독자용 필드는 기존 사이드카에서 제공하도록 정리했습니다.
-
잘못된 소수형 개정 번호를 정수형 로컬 개정 계보로 교체하고 게시 차단과 한국어 원어민 검토 대기 상태를 유지했습니다.
전체 비교를 사용할 수 없음 — 이 수정에 대한 이전 스냅샷이 보관되지 않았습니다.
2026년 8월 8일에 업데이트됨.
편집 요약 및 기록된 변경 세부 정보입니다.요약
영어 원문에 잠긴 한국어 초안을 만들고 감사 완료 전까지 게시를 차단했습니다.
변경 세부 정보
-
한국어 본문, 번역 메모리, 컴포넌트 사이드카를 생성했습니다.
전체 비교를 사용할 수 없음 — 이 수정에 대한 이전 스냅샷이 보관되지 않았습니다.
2026년 8월 2일에 업데이트됨.
편집 요약 및 기록된 변경 세부 정보입니다.요약
전자상거래 플랫폼 도구 참조를 현재 공개 경로에 맞추고 사용이 중단된 중복 콘텐츠 검사기를 제거했습니다.
변경 세부 정보
-
Redirect Chain Mapper를 HTTP Status Checker로 교체하고 Duplicate Content Checker 권장을 제거했습니다.
전체 비교를 사용할 수 없음 — 이 수정에 대한 이전 스냅샷이 보관되지 않았습니다.
2026년 7월 18일에 업데이트됨.
편집 요약 및 기록된 변경 세부 정보입니다.요약
플랫폼 순위 중심의 암시를 요구사항과 책임 중심의 선택 방법으로 바꾸고, 변형 URL과 패싯 탐색 지침을 Google이 문서화한 여러 지원 방식에 맞게 일반화했습니다.
변경 세부 정보
-
상품, 카테고리, 변형, 피드, 현지화, 게시 및 운영 요구사항을 평가하는 플랫폼 선택 방법을 추가했습니다.
-
ProductGroup을 통해 단일 canonical URL과 변형별 URL 구조를 모두 지원한다는 점을 문서화했습니다.
-
Adobe Commerce의 표준 계층형 탐색과 별도 라이선스인 Live Search 패싯을 구분했습니다.
-
플랫폼 자체가 순위 이점을 주는 것이 아니라 실제 구현과 운영이 결과를 결정한다는 점을 명시했습니다.
전체 비교를 사용할 수 없음 — 이 수정에 대한 이전 스냅샷이 보관되지 않았습니다.