bbulman/sitemaps

Plans de site (Sitemaps)

Un plan de site (sitemap) décide ce qui existe, où chaque chose se trouve et combien de décisions séparent une personne de cette chose. Menus, URLs, modèles et redirections découlent tous de cette décision, donc une arborescence erronée pénalise tout ce qui suit.

Ce dont vous avez besoin d'abord

Entrée	D'où ça vient	Si c'est manquant
La structure actuelle	Dans une base de code, lisez d'abord les routes, les composants de navigation, le sitemap.xml, le schéma du CMS et les tables de catégories. Ne jamais redessiner à partir de la seule page d'accueil.	Demandez une liste d'URL ou une exportation. Sans rien à lire, étiquetez l'arbre comme une ébauche sur une page blanche.
Taille du contenu, maintenant et dans deux ans	Comptez les éléments par section. Les sections vides et surchargées sont des constats.	Demandez un chiffre approximatif. À défaut, montrez quelle forme chaque taille probable appellerait.
Audiences et tâches principales	L'utilisateur, les analyses, les journaux de recherche, les questions que le support reçoit sans cesse	Demandez, ou écrivez votre hypothèse en haut du livrable.
Où va l'organisation	L'utilisateur	Demandez. Un brief générique produit une arborescence générique.

Un dossier de contenu : examinez l'ensemble avant de grouper, puis dites ce que c'est et à qui cela semble servir pour que l'utilisateur puisse vous corriger. Une base de données ou un CMS dynamique : exportez d'abord les titres, types, tags et dates. Les PDF et autres binaires : convertissez en texte et dites à quel point la conversion a été bonne. Un très grand ensemble : examinez par type, échantillonnez dans chaque type, et dites ce que vous avez échantillonné.

Si vous ne pouvez rien obtenir de cela, dites ce dont vous auriez besoin et remettez le format d'arborescence dans references/tree-format.md avec les types de nœuds suggérés pour ce type de site.

Méthode

1. Dessinez ce qui existe. L'arbre actuel, un décompte pour chaque section, et ses problèmes : chevauchements, vides, orphelins, tout ce qui est classé par département.

2. Dimensionnez-le. Utilisez le total dans deux ans, pas celui d'aujourd'hui.

   Éléments	Structure
   Moins de 50	Plate, 1 à 2 niveaux
   50 à 500	2 à 3 niveaux
   500 à 5 000	3 à 4 niveaux plus facettes
   Plus de 5 000	Navigation, recherche et facettes ensemble

3. Choisissez la forme à partir du contenu, jamais de l'organigramme.

   Le contenu	Forme	Ce que ça coûte
   Quelques offres distinctes, moins d'environ 50 pages	Hub and spoke : quelques sections larges et peu profondes, chacune à un clic de l'accueil. Par défaut pour les sites marketing.	L'accueil fait tout le routage. Peu de marge de croissance avant un nouveau découpage.
   Vraiment catégoriel, comme un grand catalogue ou secteur par secteur	Hiérarchie profonde	Chaque niveau coûte un clic et un peu de trace. Une première erreur de devinette égare les gens.
   Principalement plat, avec une ou deux zones denses comme une documentation ou une bibliothèque	Hybride : hub and spoke en haut, une hiérarchie étroite à l'intérieur de ces sections. La réponse habituelle pour les sites plus grands.	Deux modèles de navigation à construire et à expliquer.
   Des éléments que les gens découpent de plusieurs façons, ou une catégorie qui dépassera une seule liste	Facettes : dimensions indépendantes qui se combinent sous forme de filtres	Métadonnées propres sur chaque élément, et quelqu'un pour les maintenir.

4. Rédigez deux ou trois alternatives, découpées selon différents axes (par tâche, par audience, par type de contenu) plutôt que trois versions d'une même idée. Pour chacune, dites qui elle sert, ce qu'elle coûte et où elle s'essouffle. Recommandez-en une et expliquez pourquoi. Une seule réponse cache la décision.

5. Donnez à chaque élément un emplacement canonique. Il peut être lié depuis ailleurs, mais il vit à un seul endroit, là où les gens l'attendent. Deux emplacements divisent les résultats de recherche, les liens et la maintenance.

   Un élément semble appartenir à deux endroits	Décision
   Une poignée de véritables transversaux	Un emplacement, liens croisés depuis les autres
   De nombreux éléments appartiennent à plusieurs endroits	L'arbre est découpé selon le mauvais axe. Utilisez des facettes.
   Vous ne pouvez pas dire où les gens regarderaient	Choisissez l'emplacement le plus probable et marquez-le pour le test de l'arbre

6. Annotez chaque nœud. Chacun reçoit un type de modèle ; un nœud sans modèle signifie généralement que l'idée n'est pas terminée. Marquez les nœuds nouveaux, déplacés et retirés. Utilisez un nœud modèle comme /guides/<slug> pour les pages répétitives, et mettez facets: et items: sur les nœuds qui en ont.

7. Mettez-le à l'épreuve. Avec dix fois le contenu, une section deviendrait-elle une liste que personne ne peut parcourir ? Concevez des sous-sections ou des facettes maintenant, pas après. L'arbre sert-il le contexte plus large suivant, le produit ou l'entreprise qui l'entoure ? Une section correspond-elle à un département plutôt qu'à une tâche ? Plus de 9 à un niveau ou 4 niveaux de profondeur nécessite une raison, et « la règle des trois clics le dit » n'en est pas une, car cette règle est un mythe : les gens cliquent plus loin tant que chaque étape sent clairement leur objectif. Lisez references/depth-and-shape.md lorsque la profondeur et la largeur sont contestées, ou lors de l'examen de l'arbre de quelqu'un d'autre.

Livrable

Écrivez sitemap-tree.txt, l'arbre proposé et rien d'autre, car la vérification le lit :

/                          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)

Puis écrivez sitemap.md, dans cet ordre :

1. Recommandation : deux ou trois phrases et la raison principale.
2. Ce qui existe maintenant : l'arbre actuel et ses problèmes, avec des décomptes.
3. Options : une ligne par structure, avec les colonnes organisées par, sert, coûte, s'essouffle quand.
4. Arbre proposé : le texte exact de sitemap-tree.txt dans un bloc de code.
5. Placements : élément, emplacement, note. Uniquement quand on demande où vont les choses.
6. Hypothèses et questions ouvertes : tout ce que vous avez deviné, surtout l'audience et la direction.
7. Comment valider : les placements les plus risqués, soumis à des tests d'arbre.

Réduisez-le. Un site de 12 pages a besoin de la recommandation, de l'arbre et d'un tableau d'options de trois lignes. Un document plus long n'est pas plus approfondi. Une demande de placer chaque élément signifie que chaque élément reçoit un emplacement : donnez à un élément inadapté son emplacement le moins mauvais, signalez-le et argumentez séparément pour le déplacer, le fusionner ou le retirer.

Vérifiez-le

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

Il rapporte la profondeur et la largeur par branche, les étiquettes apparaissant deux fois, les nœuds sans modèle, les nœuds Autre ou Divers, et les éléments par section. Utilisez son résultat, pas votre lecture de l'arbre. Exit 1 signifie des avertissements : corrigez chacun, ou écrivez une ligne dans sitemap.md expliquant pourquoi l'exception tient. Passez --items N lorsque l'arbre n'a pas de décomptes.

Ensuite, à la main : recomptez les placements par rapport aux totaux, tracez toute affirmation concernant la longueur du chemin dans l'arbre, et confirmez que le bloc de code dans sitemap.md correspond au fichier.

Ce que Claude ne peut pas faire ici

• Connaître la stratégie ou la politique de l'organisation à moins qu'on ne les lui dise. L'arbre est une ébauche à laquelle réagir, et l'humain possède la décision.
• Inventer le trafic, l'utilisation ou la recherche. Cela inclut les mots de fréquence présentés comme des faits, tels que « utilisé tous les jours ». Dites « probablement » et listez-le comme une hypothèse.
• Exécuter un test d'arbre ou un tri de cartes avec de vraies personnes. Concevez-les, et analysez les résultats que l'utilisateur rapporte.
• Promettre ce qu'un CMS peut faire. Dites ce à quoi vous vous attendriez, comme des routes imbriquées ou un filtrage par facettes, et dites à l'utilisateur de le confirmer, car ce qu'une plateforme supporte varie.

Où cela est transmis

Un plan de site seul est une décoration : personne ne peut construire à partir de lui sans règles d'URL, un cahier des charges de navigation, un modèle de contenu et, pour une reconstruction, un plan de redirection.

• information-architecture : la porte d'entrée, lorsque le travail couvre plusieurs de ces domaines.
• content-inventory : quand personne ne sait encore ce qui existe. card-sort : quand les regroupements doivent venir des utilisateurs.
• taxonomies : quand l'arbre a besoin de facettes ou de tags conçus. labeling : pour nommer les nœuds.
• navigation, url-structure et content-models : pour transformer les nœuds en menus, adresses et modèles.
• redirect-maps : quand quelque chose bouge.
• tree-tests : pour valider l'arbre avant la construction. findability : pour le mesurer après.
• design-os:create-sitemap : pour écrire l'arbre convenu comme fichier lié que les étapes de conception ultérieures liront.