헤드리스 전자상거래 SEO

TL;DR — 헤드리스 전자상거래는 쇼핑객이 보는 스토어프런트를 Shopify, Commercetools, BigCommerce 같은 커머스 엔진과 분리해 구축하는 방식입니다. SEO에서는 스토어프런트가 페이지를 어떻게 렌더링하는지가 중요합니다. 서버나 배포 시점에 페이지를 만들면 Google은 완성된 HTML을 받습니다. 브라우저에서 만들면 Google이 JavaScript를 기다려야 하며, 가능하더라도 더 느리고 위험합니다.

스토어에서 “헤드리스”가 의미하는 것

전통적인 전자상거래 플랫폼(WooCommerce, 표준 Shopify)은 하나의 시스템에서 제품 저장, 주문 처리, 쇼핑객과 크롤러가 보는 HTML 페이지 렌더링까지 모두 담당합니다. 헤드리스 구성은 이러한 책임을 분리합니다. 커머스 엔진은 제품, 재고, 결제를 관리하고, 보통 Next.js, Nuxt 또는 Astro로 만든 별도의 프런트엔드 프레임워크가 데이터를 가져와 방문자에게 보이는 화면을 렌더링합니다.

이제 커머스 엔진 자체는 검색엔진에 보이지 않습니다. Google이 보는 것은 프런트엔드가 렌더링한 결과입니다.

SEO 결과를 좌우하는 단 하나의 결정

프런트엔드는 각 페이지를 어떻게 만드나요?

• SSR(서버 측 렌더링) — 요청마다 서버가 페이지를 만듭니다. 크롤러는 완전한 HTML을 받으므로 SEO에 안전합니다.
• SSG(정적 사이트 생성) — 배포할 때 페이지를 HTML 파일로 미리 만듭니다. 가장 빠르고 SEO에도 가장 안전합니다.
• CSR(클라이언트 측 렌더링) — 서버는 빈 셸을 보내고 JavaScript가 브라우저에서 페이지를 만듭니다. Google은 렌더링할 수 있지만 지연된 대기열에서 처리하며, 다른 크롤러는 렌더링하지 못하는 경우가 많습니다.

대부분의 헤드리스 스토어프런트는 SSR과 SSG를 모두 지원하는 Next.js, Nuxt 또는 Astro를 사용합니다. 위험은 제품 또는 카테고리 페이지에서 실수로 CSR을 활성화하는 데 있습니다.

이제 직접 책임져야 하는 항목

단일 플랫폼에서는 내장 모듈이나 플러그인이 기본 SEO 작업을 처리합니다. 헤드리스 구성에서는 다음을 모두 직접 구현해야 합니다.

• 제목 태그와 메타 설명(사이트 전체가 아니라 페이지별)
• Canonical 태그(특히 패싯 탐색과 변형 URL에서 중요)
• XML 사이트맵 생성
• JSON-LD 구조화 데이터(Product, BreadcrumbList, Organization)
• robots.txt

이 클러스터에서 다루는 JavaScript SEO, Next.js, React, 헤드리스 CMS는 각각 이 구조의 일부를 설명합니다.

TL;DR — 헤드리스 전자상거래 SEO에는 두 계층이 있습니다. 렌더링 아키텍처는 Googlebot이 HTML을 받는지 빈 셸을 받는지 결정하고, 구조화 데이터와 피드 계층은 리치 결과 및 Google Shopping 무료 제품 등록의 자격을 결정합니다. 렌더링에서는 SSR과 SSG가 안전하며 CSR은 명시적인 검증이 필요합니다. 구조화 데이터에서는 AggregateOffer가 아닌 Offer를 사용한 Product 스키마가 판매자 등록 자격에 필요하고, ProductGroup과 hasVariant가 변형 제품 묶음을 올바르게 표현합니다. Google Merchant Center 피드는 프런트엔드 렌더링과 독립적이며 Shopping 노출에 똑같이 중요합니다. 헤드리스라고 해서 피드 품질 요구사항이 면제되지는 않습니다.

헤드리스 스토어의 렌더링 아키텍처

대표적인 헤드리스 전자상거래 스택은 Next.js(Vercel Commerce)나 Nuxt를 사용합니다. Shopify Hydrogen은 React Router 7에서 실행됩니다. 2024년 말 Remix에서 이전했으며, 2026년 중반 현재 Shopify의 @shopify/remix-oxygen 패키지에는 통합 개발자가 대신 react-router와 @shopify/hydrogen/oxygen을 사용하도록 안내하는 지원 중단 공지가 있습니다. Shopify의 일부 문서 페이지에는 여전히 예전 Remix 방식의 코드 예제가 있으므로, 우연히 도착한 문서 페이지보다 실제 사용 중인 패키지 버전을 확인하세요. 이 프레임워크들은 기본적으로 서버 측 렌더링 또는 정적 생성을 사용하므로 Googlebot은 첫 번째 요청에서 완전한 HTML을 받고 렌더링 대기열을 기다리지 않습니다.

실패 방식은 프레임워크마다 다르지만 공통 패턴이 있습니다.

Next.js: 제품 또는 카테고리 페이지를 Client Component로 바꾸면 렌더링이 브라우저로 이동합니다. App Router 경로는 기본적으로 Server Component이지만, 트래픽이 많은 페이지에 실수로 'use client'를 표시하고도 알아채지 못할 수 있습니다. curl 또는 페이지 소스로 확인하세요. 원시 HTML에 제품 제목과 설명이 없다면 CSR 페이지입니다.

Shopify Hydrogen(React Router): React Router의 프레임워크 모드는 이전의 Remix와 같은 방식으로 기본 서버 측 loader를 사용합니다. 주요 위험은 Shopify 호스팅인 Oxygen의 캐시 설정입니다. 오래된 캐시 응답이 제품 업데이트 후에도 오랫동안 크롤러에 이전 콘텐츠를 제공할 수 있습니다.

사용자 정의 React + Vite: 기본 구성은 순수 CSR입니다. Google이 렌더링할 수는 있지만 가장 위험한 구성입니다. React Server Component를 추가하거나 프레임워크로 전환하세요.

헤드리스 제품 페이지의 구조화 데이터

헤드리스 프런트엔드는 자체 <head>를 관리하므로 구조화 데이터도 전적으로 직접 책임져야 합니다. 전자상거래에서는 세 가지 스키마 유형이 중요합니다.

Product 스키마 — 최소 필수 마크업은 name, image, offers(price, priceCurrency, availability 포함)입니다. 직접 구매 페이지에서 판매자 등록 자격을 얻으려면 Offer를 사용하세요. AggregateOffer를 사용하면 그 자격을 얻을 수 없습니다.

ProductGroup + hasVariant — 2024년 2월 스키마 업데이트입니다. 한 페이지가 크기, 색상, 소재가 다른 여러 변형 제품을 나타낼 때는 변형을 ProductGroup으로 묶고 variesBy(예: https://schema.org/color)를 지정한 뒤 각 변형을 hasVariant로 연결합니다. 그러면 Google이 관계를 이해하고 변형 URL 사이의 중복 콘텐츠 신호를 줄일 수 있습니다.

BreadcrumbList — Google이 사이트 계층을 이해하도록 돕고 탐색경로 리치 결과를 활성화합니다. URL 구조를 직접 설계하는 헤드리스 구성에서 특히 중요합니다.

Google Merchant Center와 헤드리스

프런트엔드 렌더링과 GMC 피드는 서로 독립적입니다. SSR로 완벽하게 렌더링되는 헤드리스 스토어라도 무료 Shopping 제품 등록과 전체 판매자 등록 경험의 자격을 얻으려면 Merchant Center에 제품 피드를 제출해야 합니다. 제목, GTIN, 이미지, 가격 일치 여부 같은 피드 속성의 품질은 온페이지 SEO와 별개로 자연 검색 제품 그리드의 순위 요소입니다. 피드를 광고만의 문제로 보지 마세요. 검색의 문제이기도 합니다.

다음에 살펴볼 내용

이 클러스터에서는 렌더링과 프레임워크 계층을 자세히 다룹니다.

• JavaScript SEO — JavaScript 비중이 큰 모든 스토어프런트에 적용되는 일반적인 실패 방식(동등성, 상호작용, 상태, 타이밍)
• Next.js SEO — 대표적인 헤드리스 커머스 프레임워크의 App Router, Metadata API, sitemap.ts, LCP 이미지, ISR 함정
• React SEO — 기본 렌더링 모델과 Google 웹 렌더링 서비스가 React 페이지를 대기열에 넣고 처리하는 방식
• 헤드리스 CMS SEO — 제품 콘텐츠가 커머스 엔진이 아니라 Contentful, Sanity, Storyblok 같은 CMS에 있을 때의 SEO
• 헤드리스 커머스 플랫폼 — Shopify Hydrogen, BigCommerce, commercetools, Salesforce PWA Kit, Medusa, Saleor, Elastic Path 등 실제 플랫폼과 각 플랫폼에서 직접 구현해야 할 항목 비교
• 컴포저블 커머스 — 헤드리스보다 한 단계 상위인 MACH 아키텍처 패턴과 독립 공급업체의 스택을 조립할 때 생기는 SEO 책임 위험

헤드리스 전자상거래 SEO에는 두 계층이 있습니다.

렌더링 계층(크롤링 가능성 결정):

• SSR과 SSG는 Googlebot이 첫 요청에서 읽을 수 있는 HTML을 생성하므로 안전합니다.
• CSR은 빈 셸을 생성하며 Google이 나중에 렌더링합니다. 대기열 지연이나 시간 초과가 생길 수 있어 위험합니다.
• Next.js, React Router(Hydrogen), Nuxt는 기본적으로 SSR/SSG를 사용합니다. curl 또는 페이지 소스로 제품·카테고리 페이지가 실수로 CSR이 되지 않았는지 확인하세요.

구조화 데이터와 피드 계층(리치 결과 및 Shopping 자격 결정):

• Product 스키마: 직접 구매 페이지의 판매자 등록 자격을 위해 AggregateOffer가 아닌 Offer를 사용합니다.
• ProductGroup + hasVariant(2024년 2월): 변형 제품 묶음을 올바르게 표현합니다.
• GMC 피드 품질(제목, GTIN, 이미지, 가격 일치)은 Shopping 노출의 독립적인 순위 요소이며 헤드리스 구성에서도 선택 사항이 아닙니다.

이제 명시적으로 직접 구현해야 할 항목(플랫폼 플러그인 없음):

• 페이지별 제목과 메타 설명
• Canonical 태그(패싯 탐색과 변형 URL에서 중요)
• XML 사이트맵
• JSON-LD(Product, BreadcrumbList)
• robots.txt

Google Search Central

• 제품 구조화 데이터 — Product, Offer, ProductGroup 스키마 요구사항
• JavaScript SEO 기본사항 이해하기 — Googlebot이 JavaScript 렌더링 콘텐츠를 처리하는 방식
• 지연 로드 콘텐츠 수정 — Intersection Observer와 무한 스크롤
• XML 사이트맵 — 사이트맵 형식과 제출 방법

Google Merchant Center

• 제품 무료 등록 — 자연 검색 Shopping 노출의 자격
• 제품 데이터 사양 — 피드 속성 요구사항

프레임워크 문서

• Next.js Metadata API — App Router 메타데이터와 generateMetadata
• Next.js sitemap.ts — 파일 기반 사이트맵 생성
• React Router: 데이터 로딩 — 서버 측 loader 함수(현재 Shopify Hydrogen이 사용하는 패턴)

“Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates … The page may stay on this queue for a few seconds, but it can take longer than that.” (번역) 「일부 JavaScript 사이트는 초기 HTML에 실제 콘텐츠가 없고 Google이 JavaScript가 생성하는 실제 페이지 콘텐츠를 보기 전에 JavaScript를 실행해야 하는 앱 셸 모델을 사용할 수 있습니다. 페이지는 이 대기열에 몇 초 머물 수 있지만 그보다 더 오래 걸릴 수도 있습니다.」 — Google Search Central, 「JavaScript SEO 기본사항 이해하기」. 인용문으로 이동

“We do an HTTP request, and we get something back … some barebone HTML and all it does is load the JavaScript and run the JavaScript. Then, this HTML … goes into rendering. Rendering runs JavaScript — boom!, a lot of content happens that wasn’t there before.” (번역) 「HTTP 요청을 보내면 기본적인 HTML이 돌아오고, 그 HTML은 JavaScript를 불러와 실행합니다. 그런 다음 HTML이 렌더링으로 넘어가고, 렌더링이 JavaScript를 실행하면 이전에는 없던 많은 콘텐츠가 나타납니다.」 — Google Developer Advocate Martin Splitt, Google Webmaster Central Office Hours 행아웃. [출처: Office Hours 녹화 — 실제 오디오와 대조해 확인 필요]

헤드리스 전자상거래 SEO 체크리스트

렌더링 검증

• curl -s https://yourstore.com/products/[slug] | grep '<title>' — 원시 HTML에 제목이 있는지 확인
• 제품 페이지의 페이지 소스 보기 — JavaScript 없이도 제품 이름과 설명이 표시되는지 확인
• 카테고리·컬렉션 페이지도 서버에서 렌더링되는지 확인(대부분의 CSR 실수는 동적 경로에서 발생)
• 핵심 페이지를 Google Search Console → URL 검사 → “실제 URL 테스트”로 확인

구조화 데이터

• 모든 PDP에 Product 스키마: name, image, offers(price, priceCurrency, availability 포함)
• 직접 구매 페이지에서는 AggregateOffer가 아닌 Offer 사용 — 판매자 등록 자격에 필요
• 변형 제품 묶음(색상, 크기, 소재)에 ProductGroup + hasVariant + variesBy 사용
• 제품 및 카테고리 페이지에 BreadcrumbList 적용
• 리치 결과 테스트로 검증

기술 SEO 책임

• 페이지마다 고유한 <title>과 <meta name="description"> 적용(사이트 전체 템플릿 금지)
• 모든 페이지에 canonical 태그 적용(특히 변형 및 필터 URL)
• 제품 및 카테고리 페이지를 포함한 XML 사이트맵 생성·제출
• robots.txt에 접근할 수 있고 올바르며 JS/CSS를 차단하지 않는지 확인
• 301 리디렉션을 SPA 라우터가 아니라 프레임워크/CDN 계층에서 처리

Google Merchant Center

• 자연 검색 제품 등록만 사용하더라도 GMC에 제품 피드 제출
• 가격 일치: 피드 가격과 방문 페이지 가격이 정확히 같은지 확인
• 브랜드 제품에 GTIN 포함
• GMC → 진단에서 피드 진단 검토

헤드리스 전자상거래 SEO: 의사결정 프레임워크

SEO 위험에 따른 프레임워크 선택

SSG와 SSR 중 무엇을 선택할까

SSG가 적합한 경우:

• 제품 카탈로그가 비교적 안정적임(하루 업데이트 100회 미만)
• 재검증에 ISR 사용(Next.js revalidate, Nuxt useAsyncData의 lazy)
• 성능이 최우선임(CDN 엣지의 정적 HTML)

SSR이 적합한 경우:

• 요청마다 제품 가용성, 가격 또는 개인화가 달라짐
• 실시간 재고가 중요함(품절 상태가 정확해야 함)
• 카탈로그가 너무 커서 배포 시 미리 빌드하기 어려움

CSR을 피해야 하는 대상:

• 제품 페이지
• 카테고리·컬렉션 페이지
• 자연 검색 순위를 얻으려는 모든 페이지

이 헤드리스 경로는 어떻게 렌더링해야 할까?

경로 템플릿 수준에서 선택하세요. 제품 상세 페이지와 카테고리 페이지는 서로 다른 방식을 선택할 수 있습니다.

헤드리스 전자상거래에서 흔한 SEO 실패

브라우저에는 제품 콘텐츠가 보이지만 페이지 소스에는 없음

가능성 높은 원인: 제품 경로나 데이터 가져오기 경로가 상위 수준 Next.js Client Component처럼 클라이언트 측 렌더링으로 이동했습니다.

해결: Server Component, loader 또는 서버 경로에서 데이터를 가져와 색인 가능한 제품 콘텐츠를 초기 HTML에 반환하세요. 수화된 DOM만 보지 말고 curl과 페이지 소스로 확인하세요.

여러 제품이 검색 결과에서 똑같은 일반 제목으로 표시됨

가능성 높은 원인: 경로 메타데이터가 서버 측에서 제품 데이터를 받지 못해 헤드리스 프런트엔드가 사이트 전체 대체값을 사용하고 있습니다.

해결: 경로의 서버 측 제품 응답에서 제목, 설명, canonical을 생성하세요. 여러 제품 및 카테고리 템플릿을 크롤링해 각 원시 응답에 기대한 고유 값이 있는지 확인하세요.

크롤러에 가격이나 재고 상태가 오래된 값으로 표시됨

가능성 높은 원인: SSG/ISR 또는 엣지 캐시가 카탈로그 업데이트보다 오래 유지되는 반면, 클라이언트 요청은 수화 후 쇼핑객에게 더 최신 값을 보여 줍니다.

해결: 커머스 이벤트를 재검증에 연결하거나 가격에 민감한 경로의 캐시 기간을 줄이세요. 같은 SKU에 대해 원시 HTML, 렌더링 페이지, 피드, 결제를 비교해 네 곳의 값이 모두 일치하는지 확인하세요.

JSON-LD가 유효해 보이는데도 제품 리치 결과가 표시되지 않음

가능성 높은 원인: 마크업이 JavaScript 실행 후에만 삽입되거나, 직접 구매 페이지에서 AggregateOffer를 사용하거나, 필수 offer 필드를 누락했거나, 페이지와 일치하지 않는 데이터를 설명하고 있습니다.

해결: 적절한 Offer를 포함한 서버 렌더링 Product 객체 하나를 출력한 뒤 리치 결과 테스트를 실행하고 값이 표시 제품 및 GMC 피드와 일치하는지 비교하세요.

변형 URL이 서로 경쟁하거나 예측할 수 없게 canonical 처리됨

가능성 높은 원인: 프런트엔드가 일관된 canonical 없이 크롤링 가능한 상태 URL을 만들고 제품 그룹과 변형의 관계도 표현하지 않습니다.

해결: 색인할 변형 전략을 정하고 canonical을 그 전략과 일치시키며, 페이지가 변형 묶음을 나타낼 때 ProductGroup과 hasVariant를 구현하세요. 선택 가능한 모든 상태를 크롤링해 출력 URL과 마크업을 검증하세요.

헤드리스 이전 후 제품이 사라짐

가능성 높은 원인: 기존 URL에 서버 측 리디렉션이 없거나 새 사이트맵이 불완전하거나 SPA 탐색이 서버 404를 가리고 있습니다.

해결: 이전 URL을 직접 요청으로 테스트하고 이전 URL과 새 URL의 리디렉션 맵을 검증하며 새 사이트맵과 실제 카탈로그를 비교하세요. 클라이언트 라우터 동작은 HTTP 리디렉션을 대신할 수 없습니다.

헤드리스 렌더링 계층 검증

원시 HTML에서 필수 신호 검사

셸에서 제품 URL 하나와 카테고리 URL 하나를 대상으로 실행하세요. 예시 값은 해당 페이지에 반드시 있어야 하는 용어로 바꾸세요.

url='https://store.example/products/example'
html="$(curl -fsSL "$url")"
printf '%s' "$html" | grep -i '<title'
printf '%s' "$html" | grep -i 'rel="canonical"'
printf '%s' "$html" | grep -F 'Example Product Name'
printf '%s' "$html" | grep -F 'application/ld+json'

브라우저에서 JavaScript를 실행한 후에만 신호가 나타난다면 이 테스트가 원시 응답의 격차를 드러냅니다.

Python으로 URL 목록 일괄 비교

표준 제품·카테고리 URL을 한 줄에 하나씩 urls.txt에 저장하세요. 이 스크립트는 상태 코드, 최종 HTML의 title 및 canonical 포함 여부, Product 스키마 문자열의 개수를 보고합니다.

from urllib.request import Request, urlopen
from urllib.error import HTTPError
import re

for url in open("urls.txt", encoding="utf-8"):
    url = url.strip()
    if not url:
        continue
    try:
        response = urlopen(Request(url, headers={"User-Agent": "HeadlessSEOCheck/1.0"}))
        html = response.read().decode("utf-8", errors="replace")
        print(url, response.status,
              "title=" + str(bool(re.search(r"<title[^>]*>.+?</title>", html, re.I | re.S))),
              "canonical=" + str('rel="canonical"' in html.lower()),
              "product_schema=" + str(len(re.findall(r'"@type"\s*:\s*"Product"', html))))
    except HTTPError as error:
        print(url, error.code, "HTTP error")

Chrome DevTools에서 렌더링된 메타데이터 검사

제품 페이지의 Console에 붙여 넣으세요. 수화된 DOM을 검사하므로, 동등성 문제를 찾으려면 위의 원시 응답 스크립트 결과와 비교하세요.

({
  title: document.title,
  canonical: document.querySelector('link[rel="canonical"]')?.href ?? null,
  productSchemas: [...document.querySelectorAll('script[type="application/ld+json"]')]
    .filter((node) => /"@type"\s*:\s*"Product"/.test(node.textContent)).length,
  productHeading: document.querySelector('h1')?.textContent?.trim() ?? null,
});

업계 자료

• Vercel Commerce(Next.js 스타터) — 오픈 소스 헤드리스 스토어프런트 참조 구현
• Shopify Hydrogen 문서 — Shopify의 공식 헤드리스 프레임워크(2026년 현재 React Router 7 기반. 일부 문서 페이지에는 이전 전환 전 Remix 코드 예제가 남아 있음)
• Google Search Central: JavaScript SEO 기본사항 이해하기 — JS 렌더링에 관한 Google 개발자 안내(web.dev의 JS SEO 문서는 폐기되었으며 현재 안내는 이 페이지에 있음)
• Onely: Google은 JS 콘텐츠를 어떻게 크롤링하는가? 실험 — Googlebot이 JavaScript 렌더링 콘텐츠를 크롤링하고 색인하는 방식을 자세히 설명(이 위치의 이전 링크는 404였고 현재는 이 글이 대응 자료임)
• Google Search Central: 제품 구조화 데이터 — 리치 결과와 판매자 등록의 공식 스키마 요구사항

퀴즈: 헤드리스 전자상거래 SEO

헤드리스 스토어 아키텍처와 SEO에 관한 다섯 문제입니다. 각 문제의 답을 고른 뒤 확인하세요.

변경 내역