Commencer par les pages et l’offre vérifiable
Recensez catégories, services, agences, guides et pages d’aide. Pour chaque URL, notez le public, la tâche résolue et l’action suivante. Si deux pages reçoivent la même description, clarifiez leur rôle avant d’ajouter des requêtes : le conflit existe déjà dans l’architecture.
Confirmez aussi la zone servie, les conditions et la langue. Une requête contenant Bruxelles, Genève ou Monaco ne justifie pas une page locale si l’entreprise n’y propose rien. La carte décrit l’offre actuelle ; elle ne transforme pas une ambition commerciale en disponibilité publique.
Grouper par tâche plutôt que par vocabulaire commun
« Livraison de fleurs entreprise », « tarif livraison fleurs » et « conserver un bouquet » partagent un thème, mais demandent respectivement une offre, des conditions tarifaires et un conseil. Une page peut couvrir plusieurs formulations seulement si elle accomplit la même tâche sans changer de fonction.
Pour un cas ambigu, comparez les types de pages visibles dans le même marché et sur le même appareil. Conservez la date. Un recouvrement de résultats constitue un indice pour la revue humaine, pas une règle automatique ni une preuve durable que deux requêtes exigent la même page.
Attribuer un statut qui conduit à une action
Utilisez un petit nombre de statuts : attribuée, page à améliorer, lacune à étudier, fusion à examiner, ne pas couvrir. Ajoutez justification, responsable et date de revue. La carte devient ainsi une file de travail limitée, pas un calendrier automatique de publication.
Une vraie lacune suppose une offre disponible et aucune page capable de répondre. Si la bonne URL manque seulement de prix, de conditions, d’un tableau de choix ou d’un prochain pas, améliorez-la plutôt que de créer une page concurrente.
Exemple synthétique : fleuriste pour entreprises
Un fleuriste fictif possède une page de livraison professionnelle, une page tarifs et des conseils d’entretien. Les requêtes de commande sont affectées au service, les questions de coût aux tarifs et la conservation au guide. Les formulations locales restent enregistrées avec leur marché.
L’équipe ajoute les seuils de commande, jours de livraison et zones réellement couvertes. Elle ne crée pas une page par ville. Après publication, elle vérifie sous le même contexte quelle URL apparaît. Cet exemple est inventé et ne représente ni client ni promesse de classement.
Traiter une URL observée différente de l’URL attendue
Si une autre page apparaît, examinez sa tâche, son indexabilité, ses liens internes et son contenu. Un seul changement ne prouve pas une cannibalisation. Cherchez un motif répété dans des contrôles comparables et distinguez observation et hypothèse.
Décidez ensuite de renforcer la page attendue, de séparer les rôles ou d’examiner une fusion en cas de redondance réelle. Chaque option doit avoir un propriétaire, une raison et une prochaine date de contrôle ; une redirection n’est jamais déduite d’une seule mesure.
Produire une ligne réutilisable
Chaque ligne finale contient requête, marché, intention, groupe, URL attendue, URL observée, statut, preuve, responsable et révision. Un champ inconnu reste inconnu ; il ne doit pas être rempli par une supposition.
Dans SEODatum, sauvegardez la liste originale, les groupes et les observations disponibles. Le produit ne remplace pas l’arbitrage humain et ne promet pas de clustering automatique. Son interface est disponible en anglais.
Requête | Marché | Intention | Groupe | URL attendue | URL observée | Statut | Preuve | Responsable | Date de revue