O que sitemaps faz?
Um sitemap decide o que existe, onde cada coisa vive e quantas decisões separam uma pessoa do conteúdo. Menus, URLs, templates e redirecionamentos são todos derivados desta decisão, então uma árvore errada sobrecarrega tudo a jusante.
O que você precisa primeiro
| Entrada | De onde vem | Se estiver faltando |
|---|---|---|
| A estrutura atual | Em uma base de código, leia as rotas, componentes de navegação, sitemap.xml, schema do CMS e tabelas de categorias primeiro. Nunca redesenhe apenas a partir da página inicial. | Peça uma lista de URLs ou uma exportação. Sem nada para ler, rotule a árvore como um rascunho em branco. |
| Tamanho do conteúdo, agora e em dois anos | Conte itens por seção. Seções vazias e sobrecarregadas são descobertas. | Peça um número aproximado. Se não for possível, mostre qual forma cada tamanho provável exigiria. |
| Públicos e tarefas principais | O usuário, análises, logs de busca, perguntas que o suporte continua respondendo | Pergunte, ou escreva sua suposição no topo do entregável. |
| Para onde a organização está indo | O usuário | Pergunte. Um briefing genérico produz uma árvore genérica. |
Uma pasta de conteúdo: examine todo o conjunto antes de agrupar, depois diga o que é e para quem parece servir, para que o usuário possa corrigi-lo. Um banco de dados ou CMS dinâmico: exporte títulos, tipos, tags e datas primeiro. PDFs e outros binários: converta para texto e diga quão boa foi a conversão. Um conjunto muito grande: examine por tipo, amostre dentro de cada tipo e diga o que você amostrou.
Se você não conseguir nada disso, diga o que precisaria e entregue o formato da árvore em references/tree-format.md com tipos de nós sugeridos para este tipo de site.
Método
-
Desenhe o que existe. A árvore atual, uma contagem de cada seção e seus problemas: sobreposições, vazios, órfãos, qualquer coisa arquivada por departamento.
-
Dimensione. Use o total em dois anos, não o de hoje.
Itens Estrutura Abaixo de 50 Plana, 1 a 2 níveis 50 a 500 2 a 3 níveis 500 a 5.000 3 a 4 níveis mais facetas Acima de 5.000 Navegação, busca e facetas juntos -
Escolha a forma a partir do conteúdo, nunca do organograma.
O conteúdo Forma O que custa Algumas ofertas distintas, com menos de cerca de 50 páginas Hub e raios: algumas seções largas e rasas, cada uma a um clique da página inicial. O padrão para sites de marketing. A página inicial faz todo o roteamento. Pouco espaço para crescer antes de um novo corte. Verdadeiramente categórico, como um grande catálogo ou indústria por indústria Hierarquia profunda Cada nível custa um clique e um pouco de cheiro. Um palpite inicial errado deixa as pessoas perdidas. Principalmente raso, com uma ou duas áreas densas, como documentação ou uma biblioteca Híbrido: hub e raios no topo, uma hierarquia estreita dentro dessas seções. A resposta usual para sites maiores. Dois modelos de navegação para construir e explicar. Itens que as pessoas fatiem de várias maneiras, ou uma categoria que vai superar uma lista Facetado: dimensões independentes que se combinam como filtros Metadados limpos em cada item, e alguém para mantê-los. -
Elabore duas ou três alternativas, cortadas ao longo de eixos diferentes (por tarefa, por público, por tipo de conteúdo), em vez de três versões de uma ideia. Para cada uma, diga a quem serve, o que custa e onde tensiona. Recomende uma e diga por quê. Uma única resposta esconde a decisão.
-
Dê a cada item um lar canônico. Ele pode ser vinculado de outros lugares, mas vive em um lugar, onde as pessoas esperam. Dois lares dividem resultados de busca, links e manutenção.
Um item parece pertencer a dois lugares Decisão Alguns poucos autênticos transversais Um lar, links cruzados dos outros Muitos itens pertencem a vários lugares A árvore está cortada ao longo do eixo errado. Use facetas. Você não consegue dizer onde as pessoas procurariam Escolha o lar mais provável e marque para o teste de árvore -
Anote cada nó. Cada um recebe um tipo de template; um nó sem template geralmente significa que a ideia não está finalizada. Marque nós novos, movidos e retirados. Use um nó padrão como
/guides/<slug>para páginas repetidas e coloquefacets:eitems:nos nós que os possuem. -
Estresse-o. Com dez vezes o conteúdo, uma seção se tornaria uma lista que ninguém consegue escanear? Projete sub-seções ou facetas agora, não depois. A árvore serve ao próximo contexto maior, o produto ou negócio ao redor? Alguma seção mapeia para um departamento em vez de uma tarefa? Mais de 9 por nível ou 4 de profundidade precisa de uma razão, e "a regra dos três cliques diz isso" não é uma, já que essa regra é um mito: as pessoas clicam mais enquanto cada passo cheira claramente ao seu objetivo. Leia
references/depth-and-shape.mdquando profundidade e largura forem contestadas, ou ao revisar a árvore de outra pessoa.
Entregável
Escreva sitemap-tree.txt, a árvore proposta e nada mais, porque a verificação a lê:
/ 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)
Em seguida, escreva sitemap.md, nesta ordem:
- Recomendação: duas ou três frases e o motivo principal.
- O que existe agora: a árvore atual e seus problemas, com contagens.
- Opções: uma linha por estrutura, com colunas organizado por, serve, custa, tensiona quando.
- Árvore proposta: o texto exato de
sitemap-tree.txtem um bloco de código. - Posicionamentos: item, lar, nota. Somente quando perguntado onde as coisas vão.
- Suposições e perguntas em aberto: tudo que você adivinhou, acima de tudo público e direção.
- Como validar: os posicionamentos mais arriscados, entregues para testes de árvore.
Reduza a escala. Um site de 12 páginas precisa da recomendação, da árvore e de uma tabela de opções de três linhas. Um documento mais longo não é um mais completo. Um pedido para posicionar cada item significa que cada item recebe um lar: dê a um desajustado seu lar menos ruim, sinalize-o e argumente separadamente para mover, mesclar ou retirar.
Verifique
node "${CLAUDE_SKILL_DIR}/scripts/tree-check.mjs" sitemap-tree.txt
Ele relata profundidade e largura por ramo, rótulos que aparecem duas vezes, nós sem template, nós Outro ou Diversos e itens por seção. Use seu resultado, não sua leitura da árvore. Exit 1 significa avisos: corrija cada um, ou escreva uma linha em sitemap.md dizendo por que a exceção se mantém. Passe --items N quando a árvore não tiver contagens.
Depois, manualmente: reconte os posicionamentos contra os totais, trace qualquer afirmação sobre comprimento do caminho pela árvore e confirme que o bloco de código em sitemap.md corresponde ao arquivo.
O que Claude não pode fazer aqui
- Saber a estratégia ou política da organização, a menos que seja informado. A árvore é um rascunho para reagir, e o humano possui a decisão.
- Inventar tráfego, uso ou pesquisa. Isso inclui palavras de frequência declaradas como fato, como "usado todos os dias". Diga "provavelmente" e liste como suposição.
- Executar um teste de árvore ou classificação de cartões com pessoas reais. Projete-os e analise os resultados que o usuário trouxer de volta.
- Prometer o que um CMS pode fazer. Diga o que você esperaria, como rotas aninhadas ou filtragem por facetas, e peça ao usuário para confirmar, porque o que uma plataforma suporta varia.
Onde isso passa adiante
Um sitemap sozinho é decoração: ninguém pode construir a partir dele sem regras de URL, uma especificação de navegação, um modelo de conteúdo e, para uma reconstrução, um plano de redirecionamento.
information-architecture: a porta da frente, quando o trabalho abrange vários destes.content-inventory: quando ninguém sabe o que existe ainda.card-sort: quando os agrupamentos devem vir dos usuários.taxonomies: quando a árvore precisa de facetas ou tags projetadas.labeling: para nomear os nós.navigation,url-structureecontent-models: para transformar nós em menus, endereços e templates.redirect-maps: quando algo se move.tree-tests: para validar a árvore antes de construir.findability: para medir depois.design-os:create-sitemap: para escrever a árvore acordada como o arquivo vinculado que as fases posteriores de design leem.