블로그 분류 체계은(는) 무엇을 하나요?
CMS 플랫폼에서 태그, 카테고리, 주제 클러스터를 관리합니다.
명령
| 명령 | 목적 |
|---|---|
/blog taxonomy suggest <file> | 콘텐츠에서 태그 및 카테고리 후보 추출 |
/blog taxonomy sync <cms> | 인증된 API를 통해 분류 체계를 CMS에 동기화 |
/blog taxonomy audit [directory] | 얇은 태그, 고아 태그, 분류 체계 비대화 확인 |
태그 제안 워크플로
1단계: 콘텐츠 구조 파악
대상 파일을 읽고 다음 항목을 추출합니다:
- 모든 H2 및 H3 헤딩(주요 주제 신호)
- 굵게 및 기울임꼴 구문(강조 신호)
- 이미 존재하는 frontmatter 태그/카테고리(있는 경우)
2단계: 빈도 분석
본문 텍스트를 스캔하여 고빈도 구문을 찾습니다:
- 1단어 용어: 최소 4회 출현(불용어 제외)
- 2단어 구문: 최소 3회 출현
- 3단어 구문: 최소 2회 출현
일반적인 비태그 단어(관사, 전치사, 접속사, 대명사)는 제외합니다.
3단계: 의미 그룹화
관련 후보를 클러스터로 그룹화합니다:
- 단수/복수 변형 병합(더 일반적인 형태 유지)
- 하이픈 및 비하이픈 형태 병합
- 동의어를 최고빈도 용어 아래로 그룹화
4단계: 중복 제거 및 순위 매기기
- slug화된 이름에 대한 퍼지 매칭(Levenshtein 거리 <= 2)
- 각 후보 점수 산정:
(빈도 * 2) + (헤딩_존재 * 5) + (강조 * 1) - 상위 5-10개의 순위가 매겨진 제안 반환
출력 형식
## 태그 제안: [게시물 제목]
| 순위 | 태그 | 점수 | 출처 |
|------|-----|-------|--------|
| 1 | content-marketing | 18 | H2 + 6회 언급 |
| 2 | seo-strategy | 14 | H3 + 4회 언급 |
| 3 | keyword-research | 11 | 5회 언급 + 굵게 |
### 제안된 카테고리
- 기본: [최적 적합 카테고리]
- 보조: [선택적 두 번째 카테고리]
CMS 어댑터
어댑터 개요
| CMS | API 유형 | 인증 방법 | 태그 모델 |
|---|---|---|---|
| WordPress | REST | 애플리케이션 비밀번호(base64) | ID가 있는 최상위 엔티티 |
| Shopify | GraphQL (Admin API) | Admin API 액세스 토큰 | Article의 문자열 배열 |
| Ghost | REST (Admin API) | JWT 서명이 있는 API 키 | 최상위 엔티티 |
| Strapi | REST 또는 GraphQL | API 토큰(Bearer) | 사용자 정의 콘텐츠 유형 |
| Sanity | GROQ / 변형 | 프로젝트 토큰(Bearer) | 문서 유형 |
WordPress 어댑터
태그 목록:
GET {CMS_URL}/wp-json/wp/v2/tags?per_page=100&search={keyword}
Authorization: Basic {base64(사용자이름:앱_비밀번호)}
태그 생성:
POST {CMS_URL}/wp-json/wp/v2/tags
Body: {"name": "태그 이름", "slug": "태그-이름", "description": "선택사항"}
카테고리 목록(계층적, parent 필드 지원):
GET {CMS_URL}/wp-json/wp/v2/categories?per_page=100
카테고리 생성:
POST {CMS_URL}/wp-json/wp/v2/categories
Body: {"name": "카테고리", "slug": "카테고리", "parent": 0}
게시물에 태그 할당:
POST {CMS_URL}/wp-json/wp/v2/posts/{id}
Body: {"tags": [1, 2, 3], "categories": [4]}
페이지 매김: 전체 목록을 보려면 X-WP-TotalPages 헤더를 따르세요.
Shopify 어댑터
Shopify의 태그는 최상위 엔티티가 아니라 Article 객체의 문자열 배열입니다.
게시물 태그 업데이트(GraphQL Admin API):
mutation {
articleUpdate(id: "gid://shopify/Article/123", article: {
tags: ["태그-하나", "태그-둘", "태그-셋"]
}) {
article { id tags }
userErrors { field message }
}
}
사용 중인 모든 태그 목록(GraphQL):
{
articles(first: 250) {
edges {
node { id title tags }
}
}
}
인증 헤더: X-Shopify-Access-Token: {토큰}
참고: REST API는 2024년 10월에 레거시로 표시됨. 2025년 4월부터 새 앱에는 GraphQL이 필요합니다.
Ghost 어댑터
태그 목록:
GET {CMS_URL}/ghost/api/admin/tags/?limit=all
Authorization: Ghost {jwt_token}
태그 생성:
POST {CMS_URL}/ghost/api/admin/tags/
Body: {"tags": [{"name": "태그 이름", "slug": "태그-이름"}]}
JWT 생성: admin API 키(id:secret 형식)로 서명, iat = 현재 시간, exp = 5분,
audience = /admin/.
Strapi 어댑터
엔드포인트는 콘텐츠 유형에서 자동 생성됩니다. 일반적인 설정:
GET {CMS_URL}/api/tags?pagination[pageSize]=100
POST {CMS_URL}/api/tags
Body: {"data": {"name": "태그 이름", "slug": "태그-이름"}}
Authorization: Bearer {api_token}
Strapi v4+는 data 래퍼를 사용합니다. 필드 이름에 대한 콘텐츠 유형 스키마를 확인하세요.
Sanity 어댑터
태그 쿼리(GROQ):
*[_type == "tag"] { _id, name, slug }
태그 생성(Mutations API):
POST https://{project_id}.api.sanity.io/v2024-01-01/data/mutate/{dataset}
Body: {"mutations": [{"create": {"_type": "tag", "name": "태그", "slug": {"current": "태그"}}}]}
Authorization: Bearer {token}
분류 체계 감사 워크플로
1단계: 인벤토리
대상 디렉토리의 모든 게시물 스캔(CMS에서 가져오기). 맵 구축:
- 태그_이름 -> [이 태그를 사용하는 게시물 파일/ID 목록]
- 카테고리_이름 -> [이 카테고리를 사용하는 게시물 파일/ID 목록]
2단계: 상태 점검
| 검사 | 임계값 | 조치 |
|---|---|---|
| 얇은 태그 아카이브 | 태그당 게시물 < 5개 | noindex 또는 병합 권장 |
| 고아 태그 | 게시물 0개 | 삭제 권장 |
| 태그 비대화 | 총 태그 > 50개 | 통합 권장 |
| 카테고리 깊이 | 3단계 초과 | 평탄화 권장 |
| 카테고리 없는 게시물 | 카테고리 할당되지 않음 | 적절한 카테고리 할당 |
| 중복 slug | 같은 slug, 다른 이름 | 정식 버전으로 병합 |
3단계: 권장 사항
우선순위별 결과 그룹화:
- 심각: 빈 아카이브 페이지를 생성하는 고아 태그(크롤 낭비)
- 높음: 게시물이 3개 미만인 얇은 태그(나쁜 사용자 경험, 약한 SEO 신호)
- 중간: 50개 이상의 태그 비대화(분류 체계 분산, 탐색 어려움)
- 낮음: 명명 불일치(대소문자 혼합, 하이픈 vs 공백)
출력 형식
## 분류 체계 감사: [사이트/디렉토리]
**총 태그**: [n] | **총 카테고리**: [n]
**정상**: [n] | **얇음**: [n] | **고아**: [n]
### 심각한 문제
- [고아 태그 목록]
### 권장 사항
1. [태그-a]와 [태그-b] 병합(같은 주제, 합쳐서 [n]개 게시물)
2. 고아 태그 삭제: [목록]
3. 게시물이 5개 미만인 태그 아카이브에 noindex 추가
사이트 전체 지침
- 사이트당 5-10개의 주요 카테고리 지향(광범위한 주제)
- 태그는 아카이브 페이지를 만들기 전에 최소 5개 게시물 필요
- 일관된 slug 형식 사용: 소문자, 하이픈으로 구분
- 모든 게시물은 정확히 1개의 기본 카테고리 필요
- 게시물당 태그: 3-8개 권장, 15개 초과 금지
환경 변수
| 변수 | 목적 | 예시 |
|---|---|---|
| CMS_TYPE | 플랫폼 식별자 | wordpress, shopify, ghost, strapi, sanity |
| CMS_URL | CMS의 기본 URL | https://example.com |
| CMS_API_KEY | 인증 자격 증명 | 애플리케이션 비밀번호, API 토큰 또는 키 |
이 변수들은 셸 환경에 설정되어야 합니다. 자격 증명을 파일에 저장하거나 버전 관리에 커밋하지 마십시오. 스킬은 런타임 시 $CMS_TYPE, $CMS_URL, $CMS_API_KEY를 통해 읽습니다.
오류 처리
- 환경 변수 누락: CMS_TYPE, CMS_URL, 또는 CMS_API_KEY가 설정되지 않은 경우, 누락된 변수를 보고하고 예상 형식을 제공합니다.
- 잘못된 자격 증명: CMS API가 401/403을 반환하는 경우 "인증 실패 - CMS_API_KEY 확인"을 보고하고 재시도하지 않습니다.
- 연결 시간 초과: CMS 엔드포인트에 10초 후에도 연결할 수 없는 경우 시간 초과를 보고하고 CMS_URL 확인을 제안합니다.
- 중복 태그 slug: 태그가 CMS에 이미 존재하는 경우 생성을 건너뛰고 "태그가 이미 존재함: [이름]"을 기록합니다.
- 속도 제한: CMS API가 429를 반환하는 경우 대기 후 한 번 재시도합니다. 제한이 지속되면 보고합니다.
- 지원되지 않는 CMS: CMS_TYPE이 지원되는 5개 플랫폼 중 하나가 아닌 경우 유효한 옵션을 나열하고 종료합니다.