Satoshi (サトシ)
발행한 글 58개
Search OSコンテンツチームでAI検索, GEO, 技術SEO運用を担当しています.
W2가 검색에 나오지 않을 때 먼저 볼 5가지
W2 숍이 검색과 AI 검색에 나오지 않을 때 확인할 순서를 5가지로 정리합니다. WAF·봇 대책의 크롤러 차단을 Search Console과 서버 로그로 확인하는 절차, 정규 크롤러 구분법, AI 크롤러 허용·거부 방침, 멀티브랜드 도메인 구성과 canonical·Organization 설계입니다.
STORES가 검색에 나오지 않을 때 먼저 볼 5가지
STORES 숍이 검색과 AI 검색에 나오지 않을 때 확인할 순서를 5가지로 정리합니다. 설정 문제인지 반영 대기인지 가르는 기준, 기다리는 동안 채울 페이지 내용, Google 비즈니스 프로필과 스토어의 연결, 예약 페이지와 안내 페이지의 역할 분담입니다.
숍서브가 검색에 나오지 않을 때 먼저 볼 5가지
숍서브 숍이 검색과 AI 검색에 나오지 않을 때 확인할 순서를 5가지로 정리합니다. 3초 표시 지연을 봇이 읽지 못하는 문제로 보는 이유, 원인 분해와 대처 순서, 3가지 도구의 역할, 컨설팅 후 월 1회·15분으로 보는 4개 영역, 무너졌을 때 맡길 곳입니다.
Shopify가 검색·AI 검색에 안 나올 때 볼 6가지
Shopify 스토어가 검색이나 AI 검색에 나오지 않을 때 담당자가 확인하는 순서로 6개 항목을 정리합니다. 중복 URL과 canonical, 고정 URL 구조와 계층, 해외 판매의 hreflang, 일본용 앱이 만드는 페이지, 이전 시 리다이렉트, 앱 로드와 속도입니다.
makeshop이 검색·AI 검색에 안 나올 때 볼 4가지
makeshop은 크리에이터 모드의 상품 상세 페이지에서 JSON-LD를 자동 출력합니다. 거기에 독자 구조화 데이터를 더하면 이중 출력이 되고, 블로그의 위치와 사이트맵, 글의 구조에 따라서도 검색과 AI 검색에서 보이는 방식이 달라집니다. 먼저 확인할 4가지를 정리합니다.
futureshop이 검색·AI 검색에 안 나올 때 볼 4가지
futureshop은 구조화 데이터와 XML 사이트맵을 자동 출력하지만, commerce creator의 헤딩 무너짐, 복수 그룹 등록의 중복 URL, Article 누락, WordPress 글의 사이트맵 누락은 운영 쪽 확인이 필요합니다. 검색과 AI 검색에 나오지 않을 때 먼저 볼 4가지를 정리합니다.
ecforce 검색·AI 검색에 안 나올 때 볼 5가지
ecforce로 운영하는 D2C 브랜드가 검색이나 AI 검색에 나오지 않을 때, 원인은 LP의 완성도가 아니라 LP 옆에 무엇이 있는가입니다. 광고 LP의 색인 구분, 질문에 답하는 페이지, 정기구독 조건 페이지, 약기법 안의 사실, 페이지 간 일치와 봇의 수집 5개 항목을 확인 순서대로 정리합니다.
ecbeing 검색·AI 검색에 안 나올 때 볼 6가지
ecbeing으로 구축한 사이트가 검색이나 AI 검색에 나오지 않을 때, 원인은 구축 시점에 정해진 설계에 있는 경우가 많습니다. URL 설계, 렌더링 방식, 메타데이터 관리, WAF와 robots.txt, 리뉴얼의 리다이렉트, 사이트맵과 로그의 6개 항목을 확인 순서대로 정리합니다.
EC-CUBE가 검색에 나오지 않을 때 먼저 볼 5가지
EC-CUBE 숍이 검색과 AI 검색에 나오지 않을 때 확인할 순서를 5가지로 정리합니다. 2계열에서 4계열로 이전할 때 잃는 4개 자산, 기본 제공되지 않는 XML 사이트맵의 3가지 선택지, SEO 플러그인 구조화 데이터의 검증과 자체 구현 판단, 제작사에 넘길 6개 영역 요건서입니다.
ebisumart 검색·AI 검색에 안 나올 때 볼 5가지
ebisumart는 기반이 자동으로 버전업되고, BtoC와 BtoB를 같은 기반에서 운영할 수 있습니다. 이 두 특징이 검색이나 AI 검색에 나오지 않는 원인이 되기도 합니다. 이전 기록, 5개 영역의 차이, 색인 경계, BtoB 가격 유출 경로, 공개 페이지의 5가지를 정리합니다.
컬러미숍이 검색에 나오지 않을 때 먼저 볼 6가지
컬러미숍이 검색과 AI 검색에 나오지 않을 때 세 층의 구분, 관리 화면에서 할 수 있는 대책, 사이트맵, 프리페이지, 템플릿의 구조화 데이터, 관리 화면에서 보이지 않는 범위 6가지를 순서대로 확인합니다. 4편의 글에서 확인 순서를 정리했습니다.
B카트 사이트가 검색에 나오지 않을 때 먼저 볼 6가지
B카트 수주 사이트가 검색과 AI 검색에 나오지 않을 때 공개와 회원 전용의 경계, 회원 전용 URL의 noindex, 신규 거래처용 페이지, 구매 담당자의 질문, 업종별 사입 가이드, 경계 확인 6가지를 순서대로 봅니다. B카트에 관한 3편의 글에서 정리했습니다.
BASE가 검색에 나오지 않을 때 먼저 볼 6가지
BASE 숍이 검색과 AI 검색에 나오지 않을 때 공개 설정, 도메인 혼재, 사이트맵, 상품 텍스트, SEO 설정 App의 범위, 봇의 수집 상태 6가지를 순서대로 확인합니다. BASE에 관한 4편의 글에서 확인 순서와 고치는 법, 반영까지의 기준을 정리했습니다.
Shopify 컬렉션·태그 중복 URL과 크롤
Shopify에서는 같은 상품이 컬렉션 경유 URL과 단독 URL 양쪽에서 열립니다. canonical이 단독 URL을 가리키므로 색인 중복은 막을 수 있지만 크롤 예산은 쓰입니다. 태그 페이지와 필터 URL까지 포함한 영향 범위와 3가지 처리 방침을 정리했습니다.
온라인·매장 재고를 검색과 AI에 읽히는 구조화
온라인과 매장의 재고를 검색 엔진과 AI에 바르게 읽히려면 조건이 있습니다. 채널별로 재고 상태를 나눠 표현하고, 화면 표시와 구조화 데이터가 같은 값을 보이게 유지해야 합니다. 재고가 AI 추천에 주는 영향, 숨겨진 품절 텍스트 사례, 채널별 표현, 매장 정보와의 연결을 정리했습니다.
상품 수만 개 규모의 크롤 예산과 색인 누락 관리
상품이 수만 점을 넘는 몰에서는 크롤러의 처리 상한이 색인 누락의 직접 원인이 됩니다. 사이트맵 분할과 lastmod, 저가치 URL 차단이 둘입니다. 내부 링크의 우선순위와 봇 로그 관측이 나머지 둘입니다. 이 4가지를 한 세트로 운영하는 방법을 정리했습니다.
EC-CUBE SEO 플러그인은 어디까지 믿을 수 있나
EC-CUBE의 SEO 플러그인은 메타 태그와 사이트맵 범위에서는 믿고 맡겨도 됩니다. 구조화 데이터는 상품 데이터와 계속 맞아야 합니다. 플러그인에 다 맡기기보다 출력을 계속 검증하는 체계가 먼저입니다. 플러그인에 맡길 범위, 직접 갖출 범위, 판단 기준을 정리했습니다.
W2의 WAF가 크롤러를 차단하고 있지 않은지 확인
W2처럼 직접 운영하는 기반에서는 WAF나 봇 대책, 속도 제한이 검색 엔진과 AI 크롤러를 잘못 막는 경우가 있습니다. 차단 여부를 Search Console과 서버 로그로 확인하는 절차, 정규 크롤러를 구분하는 법, AI 크롤러를 허용할지 정하는 법을 정리했습니다.
W2 멀티브랜드 구성의 도메인 분리 방법
W2로 여러 브랜드나 스토어를 한 기반에서 운영할 때, 도메인을 나눌지 서브도메인으로 할지 서브디렉터리로 할지에 따라 검색 평가가 쌓이는 곳이 달라집니다. 브랜드의 독립성, 공통 상품의 중복, Organization 구조화 데이터 설계, 스토어를 추가할 때의 절차를 정리했습니다.
STORES 예약 페이지는 검색에 나오는가
STORES 예약으로 만든 예약 페이지는 "예약하는 장소"라서, 검색 엔진과 AI가 "무엇을 하는 가게인지" 알아볼 재료가 적습니다. 예약 페이지에 기대할 수 있는 것과 없는 것, 검색으로 고객을 모으려면 정보를 어디에 둘지 정리했습니다.
STORES와 Google 비즈니스 프로필 연결하기
미용실·카페·교습소처럼 매장이 본업이고 STORES 온라인 스토어를 보조로 쓰는 사업자가 있습니다. 이런 경우 매장은 검색에 나오는데 온라인 숍은 나오지 않기 쉽습니다. Google 비즈니스 프로필과 스토어를 서로 연결해 매장의 검색 평가를 스토어로 흘려보내는 방법을 정리합니다.
숍서브 컨설팅 후의 SEO 자가 점검
숍서브는 컨설팅형 지원이 특징입니다. 다만 제안을 받은 뒤의 유지는 점포 쪽의 일입니다. 컨설팅으로 정비한 상태가 반년 뒤에도 남아 있는지 월 1회·15분으로 확인하는 체크리스트를 정리했습니다. 색인·속도·구조화 데이터·콘텐츠 4개 영역으로 나눴습니다.
ASP→Shopify 이전 URL·구조화 데이터 승계
makeshop·컬러미숍·futureshop에서 Shopify로 옮기면 URL 형태가 반드시 바뀝니다. 검색 평가를 잃지 않으려면 URL 대응표와 리다이렉트부터 챙겨야 합니다. 구조화 데이터 승계와 이전 전후로 확인할 지표를 이전 순서대로 정리했습니다.
Shopify 일본용 앱이 만드는 페이지의 SEO
Shopify를 일본에서 운영하면 노시·배송 일시 지정·편의점 수령 같은 일본용 앱이 필요해집니다. 이 앱들이 만드는 페이지와 파라미터가 붙은 URL은 색인해야 할지 빼야 할지 판단이 필요합니다. 앱별 출력, 색인 판단, AI 검색에 "일본용 대응이 있다"는 것을 전달하는 방법을 정리합니다.
Shopify 고정 URL 구조로 계층을 전달하는 방법
Shopify에서는 URL 계층을 마음대로 설계할 수 없습니다. 상품은 /products/, 컬렉션은 /collections/ 바로 아래에 고정됩니다. 대신 빵부스러기·내부 링크·BreadcrumbList로 계층을 전달하는 방법을 정리했습니다. 일본어 핸들 처리와 바꾸면 안 되는 것도 함께 다룹니다.
Shopify 해외 판매 hreflang과 일영 페이지
Shopify Markets로 일본어와 영어 페이지를 만들면 같은 상품에 언어별 URL이 여러 개 생깁니다. hreflang으로 언어 대응 관계를 알리지 않으면 영어권 검색에 일본어 페이지가 나오거나 중복으로 판단됩니다. Shopify가 자동으로 내보내는 hreflang의 범위, URL 구성(서브폴더·서브도메인·별도 도메인) 고르는 법, 번역 누락이 일으키는 문제를 정리했습니다.
makeshop과 WordPress 블로그를 둘 위치
makeshop 표준 블로그로는 부족해 WordPress로 글을 쓸 때, 블로그를 숍과 같은 도메인 하위에 둘지 별도 도메인에 둘지에 따라 검색 평가가 쌓이는 곳이 달라집니다. 3가지 배치 패턴과 검색·AI 검색에서 보이는 방식, 내부 링크와 사이트맵 처리를 정리했습니다.
makeshop 구조화 데이터 이중 출력 고치기
makeshop은 기본적인 구조화 데이터를 표준으로 내보냅니다. 크리에이터 모드에서 JSON-LD를 따로 더하면 같은 페이지에 같은 유형이 두 번 나와 리치 리절트 테스트에서 오류가 납니다. 이중 출력을 찾는 법, 어느 쪽을 남길지, 더해도 되는 유형을 정리합니다.
futureshop 연동 블로그의 사이트맵 누락
futureshop의 XML 사이트맵은 관리 화면에서 만든 페이지만 담습니다. WordPress 연동으로 쓴 글은 들어가지 않습니다. 글이 발견되기 어려운 이유와 WordPress 쪽 사이트맵의 등록 절차를 정리했습니다. 숍과 블로그를 하나의 사이트로 취급받기 위한 내부 링크와 구조화 데이터 설계도 함께 다룹니다.
futureshop 복수 그룹 중복 URL 정규화
futureshop에서 상품 하나를 여러 그룹에 등록하면 같은 상품에 그룹을 거치는 URL이 여러 개 생길 수 있습니다. 중복 URL이 검색 평가를 나누는 구조와 우리 숍에서 확인하는 법을 정리했습니다. canonical의 올바른 대상과 그룹 설계 규칙도 함께 다룹니다.
futureshop 페이지의 헤딩 구조 고치기
futureshop의 commerce creator는 파츠를 쌓아 페이지를 만듭니다. 그래서 겉보기에는 정돈돼 있어도 HTML 헤딩(h1~h3)이 빠지거나 순서가 건너뛰기 쉽습니다. 검색 엔진과 AI 검색은 헤딩으로 페이지를 읽기 때문에 이 무너짐이 인용되지 않는 원인이 됩니다. 무너짐을 찾는 법, 파츠별 고치는 법, 운영 규칙을 정리합니다.
ecforce 약기법 안에서 AI 인용되는 상품 설명
화장품·건강식품의 상품 설명은 약기법(일본 의약품의료기기법)으로 표현이 제한됩니다. 제한만 피하다 보면 설명이 추상적으로 변해 AI 검색에 인용되지 않습니다. 표현 제한을 지키면서 성분·사용법·대상·비교의 사실로 채우는 방법을 정리했습니다. AI가 인용할 만한 구체성을 갖추는 길입니다.
ecforce 정기구독 페이지, AI에 어떻게 읽히나
ecforce로 정기구독을 판다면 "해지할 수 있나요" "몇 회 의무인가요" "언제까지 연락해야 하나요"가 구매 전 가장 큰 질문입니다. AI 검색은 이 질문에 브랜드 페이지나 후기 사이트 중 하나를 인용해 답합니다. 자사의 정기구독 조건 페이지가 인용되도록 구조, 두는 위치, 쓰는 법, 법령과의 정합성을 정리했습니다.
ecforce 광고 LP를 noindex로 해야 하는가
ecforce에서 광고용 LP를 많이 만들면 같은 상품의 본체 페이지와 여러 LP가 검색 엔진에 함께 보입니다. 전부 noindex로 할지, 하나만 남길지, canonical로 본체에 모을지 정리했습니다. LP 종류별 판단과 설정 위치, 광고 측정에 영향을 주지 않는 방법까지 다룹니다.
ecbeing RFP에 쓸 SEO·AI 검색 요건
ecbeing 같은 대규모 패키지는 RFP 단계에서 쓰지 않은 요건을 구축 후에 바꾸기 어렵습니다. URL 설계, 렌더링 방식, 메타데이터 관리, 구조화 데이터, 봇 접근 제어, 로그 제공의 6개 영역을 바꾸기 어려운 순서로, RFP에 그대로 옮길 수 있는 문장으로 정리했습니다.
EC-CUBE 4 XML 사이트맵 3가지 선택지
EC-CUBE 4 계열은 XML 사이트맵을 기본으로 만들지 않습니다. 선택지는 플러그인, 자체 제작(커맨드나 컨트롤러로 생성), 외부 도구 생성 3가지입니다. 갱신 추종·분할·lastmod·운영 부하로 비교했습니다. 상품 수와 개발 체제에 따라 고르는 방법도 정리했습니다.
EC-CUBE 2→4 이전으로 잃는 SEO 자산
EC-CUBE 2계열에서 4계열로 옮기는 것은 단순한 버전 업이 아닙니다. URL 구조·템플릿·플러그인이 모두 바뀌는 사이트 이전입니다. 잃기 쉬운 URL·메타데이터·구조화 데이터·사이트맵 4개 자산의 인계 절차를 정리했습니다. 이전 후 확인 지표도 함께 다룹니다.
ebisumart BtoC·BtoB 사이트의 색인 경계
ebisumart 한 기반에 BtoC와 BtoB를 함께 올리면 공개와 회원 전용의 경계가 흐려집니다. BtoB 가격이 검색에 뜨거나, 반대로 공개해야 할 상품 정보가 로그인 벽 안에 갇히기도 합니다. 색인 경계 설계, noindex와 로그인 제어의 구분, AI 검색에 보여 주는 법을 정리했습니다.
ebisumart 자동 버전업 후 SEO 확인
ebisumart는 기반이 자동으로 버전업됩니다. 보안과 기능은 늘 최신이지만, 템플릿이나 SEO 출력이 조용히 바뀌기도 합니다. 버전업 후 볼 항목을 메타데이터·구조화 데이터·URL·사이트맵·속도 5개 영역으로 나눴습니다. 30분이면 끝나는 체크리스트입니다.
컬러미숍 템플릿에 구조화 데이터 넣는 법
컬러미숍은 HTML/CSS 템플릿을 편집할 수 있어 구조화 데이터를 직접 넣을 수 있습니다. 다만 표준으로 출력되는 것과 겹치면 역효과입니다. 표준 출력 확인부터 템플릿 변수로 값을 채우는 방법, 하면 안 되는 것까지 정리했습니다.
ecbeing 대규모 리뉴얼의 URL·리다이렉트 설계
ecbeing 같은 대규모 사이트를 리뉴얼하면 수만 개의 URL이 한꺼번에 바뀝니다. 전부 손으로 리다이렉트할 수는 없습니다. 규칙으로 큰 덩어리를 처리하고 예외만 개별로 대응하는 방법을 정리합니다. URL 전수 조사부터 전환 당일 절차, 이전 후 모니터링까지 순서대로 다룹니다.
컬러미숍 사이트맵 등록 절차
컬러미숍의 사이트맵을 찾는 곳부터 등록 후 확인할 지표까지 정리했습니다. Search Console에 등록할 때 쓸 주소, 프리페이지가 빠져 있을 때 보완하는 방법도 함께 다룹니다.
컬러미숍 프리페이지로 만드는 콘텐츠 SEO
컬러미숍에서 상품 고르는 법이나 사용법을 쓰려면 프리페이지를 활용하면 됩니다. 상품명 외의 검색과 AI 검색에서 찾아오는 입구가 됩니다. 글의 구성과 상품 연결 방법, 관리할 때 마주치는 한계를 정리했습니다.
B카트 업종별 가이드로 AI 검색에서 신규 거래처 확보
B카트 수주 사이트에 회사명과 문의처만 공개되어 있으면, 신규 거래처가 AI에 사입처를 물어도 상품을 찾기 어렵습니다. 업종별·용도별 가이드를 공개하고, 가격 대신 규격과 조건을 구체적으로 설명하는 방법을 정리했습니다.
B카트 회원 전용 URL noindex 설계
B카트 수주 사이트에서는 상품·가격·재고 페이지가 회원 전용입니다. 이 페이지가 색인되면 거래처별 가격이 새어 나가고, 반대로 전부 noindex로 막으면 신규 거래처의 입구가 사라집니다. 회원 정보를 보호하면서 공개 페이지는 남기는 방법을 정리합니다.
B카트 공개 페이지가 빈약할 때 무엇을 공개할까
B카트 같은 BtoB EC에서는 가격과 거래 조건을 숨겨야 할 때가 많습니다. 그렇다고 상품 설명까지 감출 필요는 없습니다. 사양·용도·선택 기준·FAQ로 검색과 AI에 상품을 알리는 방법을 정리했습니다.
BASE SEO 설정 App의 가능 범위와 한계
BASE에서 SEO 설정 App을 설치하면 제목과 설명문을 직접 쓸 수 있습니다. 하지만 검색이나 AI 검색에 나오려면 그 밖의 작업도 함께 챙겨야 합니다. App으로 끝나는 일과 운영자가 따로 확인할 일을 나눠 정리했습니다.
BASE 이미지뿐인 상품 페이지에 텍스트 더하기
BASE 상품 페이지를 사진 위주로 꾸미다 보면 설명이 빠지기 쉽습니다. 검색 엔진과 AI는 이미지 속 문자를 안정적으로 읽지 못합니다. 상품 1점당 10분을 들여 사진만으로 전하기 어려운 정보를 텍스트로 더하는 방법을 정리했습니다.
BASE 독자 도메인 전환에서 평가를 지키는 법
BASE에서 독자 도메인으로 바꾸면 주소도 달라집니다. 이전 주소의 검색 평가를 이어받으려면 연결 상태부터 확인해야 합니다. 전환 전 준비와 당일 점검, 이후 2주간 볼 항목까지 정리했습니다.
SI 구축 사이트에 개발 없이 SEO·AI 대응 추가
SI가 만든 EC 사이트에 SEO와 AI 검색 대응을 더할 때, 원본 코드를 고치면 개수 계약과 개발 사이클을 기다려야 합니다. 원본은 그대로 두고 검색 엔진과 AI 크롤러용 별도 렌더링 층을 두는 방법도 있습니다. 두 방식의 차이와 적용 범위, 판단 기준을 정리했습니다.