bbulman/sitemaps

사이트맵

사이트맵은 무엇이 존재하는지, 각 항목이 어디에 위치하는지, 그리고 사람이 그 항목에 도달하기까지 얼마나 많은 결정을 내려야 하는지를 결정합니다. 메뉴, URL, 템플릿, 리디렉션은 모두 이 결정에서 비롯되므로, 잘못된 트리는 모든 하위 단계에 부담을 줍니다.

먼저 필요한 정보

입력	출처	누락된 경우
현재 구조	코드베이스에서 먼저 라우트, 탐색 컴포넌트, sitemap.xml, CMS 스키마, 카테고리 테이블을 읽으세요. 홈페이지만 보고 재설계하지 마세요.	URL 목록이나 내보내기를 요청하세요. 읽을 자료가 없으면 트리를 "백지 상태 초안"이라고 표시하세요.
현재 및 2년 후의 콘텐츠 규모	섹션별 항목 수를 세세요. 비어 있거나 과도하게 많은 섹션은 문제점입니다.	대략적인 수치를 요청하세요. 수치를 얻을 수 없으면 각 예상 규모에 적합한 형태를 보여주세요.
사용자 및 주요 작업	사용자, 분석, 검색 로그, 지원팀이 계속 답변하는 질문	질문하거나, 전달 자료 상단에 가정을 작성하세요.
조직의 방향	사용자	질문하세요. 일반적인 브리핑은 일반적인 트리를 만듭니다.

콘텐츠 폴더: 그룹화하기 전에 전체 세트를 조사한 다음, 그것이 무엇이며 누구를 대상으로 하는지 말해 사용자가 수정할 수 있게 하세요. 데이터베이스 또는 동적 CMS: 먼저 제목, 유형, 태그, 날짜를 내보내세요. PDF 및 기타 바이너리: 텍스트로 변환하고 변환 품질을 알려주세요. 매우 큰 세트: 유형별로 조사하고, 각 유형 내에서 샘플링하며, 무엇을 샘플링했는지 알리세요.

이 중 어느 것도 얻을 수 없으면, 필요한 것이 무엇인지 말하고 references/tree-format.md의 트리 형식을 이 사이트 유형에 제안된 노드 유형과 함께 전달하세요.

방법

1. 현재 상태를 그리세요. 현재 트리, 각 섹션의 항목 수, 그리고 문제점(중복, 빈 곳, 고립된 항목, 부서 기준으로 분류된 항목)을 파악하세요.

2. 규모를 산정하세요. 오늘의 규모가 아닌 2년 후의 총 규모를 사용하세요.

   항목 수	구조
   50 미만	평면, 1~2 레벨
   50~500	2~3 레벨
   500~5,000	3~4 레벨 + 패싯
   5,000 초과	브라우징, 검색, 패싯 결합

3. 조직도가 아니라 콘텐츠에서 형태를 선택하세요.

   콘텐츠	형태	비용
   약 50페이지 미만의 몇 가지 뚜렷한 제안	허브 앤 스포크: 홈에서 한 번의 클릭으로 연결되는 몇 개의 넓고 얕은 섹션. 마케팅 사이트의 기본값.	홈이 모든 라우팅을 담당합니다. 재구성 없이 확장할 여지가 거의 없습니다.
   진정한 범주형(예: 대형 카탈로그 또는 산업별)	깊은 계층 구조	각 레벨은 클릭 한 번과 약간의 단서를 소비합니다. 초기에 잘못된 추측은 사람들을 길 잃게 만듭니다.
   대부분 얕지만 문서나 라이브러리 같은 하나 또는 두 개의 밀집된 영역이 있음	하이브리드: 상단은 허브 앤 스포크, 해당 섹션 내부는 좁은 계층 구조. 대규모 사이트의 일반적인 답변.	구축하고 설명할 두 개의 탐색 모델이 필요합니다.
   사람들이 여러 방식으로 분류하는 항목 또는 하나의 목록을 넘어설 범주	패싯: 결합하여 필터 역할을 하는 독립적인 차원	모든 항목에 깨끗한 메타데이터와 이를 유지 관리할 사람이 필요합니다.

4. 두세 가지 대안을 초안으로 작성하되, 하나의 아이디어에 대한 세 가지 버전이 아니라 다른 축(작업별, 사용자별, 콘텐츠 유형별)으로 분할하여 작성하세요. 각각에 대해 누구를 위한 것인지, 비용은 얼마인지, 어디에서 부담이 되는지 설명하세요. 하나를 추천하고 그 이유를 말하세요. 단일 답변은 결정을 숨깁니다.

5. 각 항목에 하나의 정식 위치를 부여하세요. 다른 곳에서 링크될 수는 있지만, 사람들이 예상하는 한 곳에만 존재합니다. 두 개의 위치는 검색 결과, 링크 및 유지 관리를 분산시킵니다.

   항목이 두 곳에 속하는 것처럼 보이는 경우	결정
   소수의 진정한 교차 항목	한 곳에 위치, 다른 곳에서 상호 링크
   많은 항목이 여러 곳에 속함	트리가 잘못된 축으로 분할되었습니다. 패싯을 사용하세요.
   사람들이 어디를 볼지 알 수 없음	가장 가능성 있는 위치를 선택하고 트리 테스트를 위해 표시하세요.

6. 모든 노드에 주석을 추가하세요. 각 노드는 템플릿 유형을 받습니다. 템플릿이 없는 노드는 일반적으로 아이디어가 완성되지 않았음을 의미합니다. 새 노드, 이동된 노드, 폐기된 노드를 표시하세요. 반복되는 페이지에는 /guides/<slug> 같은 패턴 노드를 사용하고, 해당 노드에 facets:와 items:를 넣으세요.

7. 스트레스 테스트를 하세요. 콘텐츠가 열 배가 되었을 때 섹션이 아무도 훑어볼 수 없는 목록이 되지 않나요? 지금 하위 섹션이나 패싯을 설계하세요, 나중이 아니라요. 트리가 더 큰 맥락(제품 또는 비즈니스)에 적합한가요? 어떤 섹션이 작업이 아닌 부서에 매핑되나요? 레벨당 9개 또는 깊이 4를 초과하려면 이유가 필요하며, "세 번 클릭 규칙이 그렇다고 하니까"는 이유가 될 수 없습니다. 그 규칙은 신화이기 때문입니다. 사람들은 각 단계가 목표와 명확하게 연결되어 있다면 계속 클릭합니다. 깊이와 너비에 대한 논쟁이 있거나 다른 사람의 트리를 검토할 때는 references/depth-and-shape.md를 읽으세요.

산출물

sitemap-tree.txt를 작성하세요. 제안된 트리만 포함하며, 검사가 이를 읽기 때문에 다른 것은 포함하지 마세요:

/                          home
├── /guides                section-hub   items: 40
│   └── /guides/<slug>     guide
├── /products              listing       items: 120  facets: use, price
│   └── /products/<slug>   product
├── /pricing               marketing     (new)
└── /about                 marketing     (moved from /company)

그런 다음 sitemap.md를 다음 순서로 작성하세요:

1. 추천: 두세 문장과 주요 이유.
2. 현재 상태: 현재 트리와 문제점, 항목 수 포함.
3. 옵션: 구조당 한 행, 열은 '구성 기준', '대상', '비용', '부담이 되는 시기'.
4. 제안된 트리: sitemap-tree.txt의 정확한 텍스트를 코드 블록으로.
5. 배치: 항목, 위치, 비고. 항목이 어디에 가야 하는지 물을 때만.
6. 가정 및 미해결 질문: 추측한 모든 것, 특히 사용자와 방향.
7. 검증 방법: 가장 위험한 배치를 트리 테스트에 전달.

규모를 줄이세요. 12페이지 사이트에는 추천, 트리, 세 줄 옵션 테이블이 필요합니다. 더 긴 문서가 더 철저한 것은 아닙니다. 모든 항목을 배치하라는 요청은 각 항목이 위치를 갖는다는 것을 의미합니다. 맞지 않는 항목에는 가장 덜 나쁜 위치를 주고, 플래그를 표시한 후 이동, 병합 또는 폐기를 별도로 주장하세요.

검사

node "${CLAUDE_SKILL_DIR}/scripts/tree-check.mjs" sitemap-tree.txt

이 명령은 브랜치별 깊이와 너비, 두 번 나타나는 라벨, 템플릿이 없는 노드, '기타' 또는 '기타' 노드, 섹션별 항목 수를 보고합니다. 트리에 대한 자신의 판단이 아닌 이 결과를 사용하세요. 종료 코드 1은 경고를 의미합니다. 각 경고를 수정하거나 sitemap.md에 한 줄을 작성하여 예외가 유지되는 이유를 설명하세요. 트리에 항목 수가 없으면 --items N을 전달하세요.

그런 다음 수동으로: 배치를 총계와 다시 비교하고, 경로 길이에 대한 주장을 트리에서 추적하며, sitemap.md의 코드 블록이 파일과 일치하는지 확인하세요.

클로드가 여기서 할 수 없는 것

• 조직의 전략이나 정치를 알 수 없습니다(알려주지 않는 한). 트리는 반응할 초안이며, 결정은 사람이 내립니다.
• 트래픽, 사용량 또는 연구를 만들어낼 수 없습니다. 여기에는 "매일 사용됨"과 같은 사실로 명시된 빈도 단어가 포함됩니다. "아마도"라고 말하고 가정으로 나열하세요.
• 실제 사람을 대상으로 트리 테스트나 카드 소팅을 실행할 수 없습니다. 설계하고 사용자가 가져온 결과를 분석할 수 있습니다.
• CMS가 할 수 있는 것을 약속할 수 없습니다. 중첩된 라우트나 패싯 필터링과 같이 기대하는 바를 말하고 사용자가 확인하도록 하세요. 플랫폼이 지원하는 것은 다양하기 때문입니다.

인계 지점

사이트맵만으로는 장식에 불과합니다. URL 규칙, 탐색 사양, 콘텐츠 모델, 재구축의 경우 리디렉션 계획 없이는 아무도 빌드할 수 없습니다.

• information-architecture: 작업이 여러 영역에 걸칠 때의 진입점.
• content-inventory: 아직 무엇이 존재하는지 아무도 모를 때. card-sort: 그룹화가 사용자에게서 나와야 할 때.
• taxonomies: 트리에 패싯이나 태그 설계가 필요할 때. labeling: 노드 이름을 표현할 때.
• navigation, url-structure, content-models: 노드를 메뉴, 주소, 템플릿으로 전환할 때.
• redirect-maps: 어떤 것이 이동할 때.
• tree-tests: 구축 전에 트리를 검증할 때. findability: 구축 후 측정할 때.
• design-os:create-sitemap: 합의된 트리를 이후 디자인 단계에서 읽는 연결된 파일로 작성할 때.