Un réseau d’agences immobilières pose un problème d’architecture que ne connaît pas une agence isolée : plusieurs agences du même réseau peuvent légitimement afficher la même annonce, lorsque le bien est en portefeuille croisé entre deux agences voisines. Sans structure d’URL réfléchie, cette situation banale dans le métier se transforme en duplicate content aux yeux d’un moteur de recherche.
Le réseau étudié ici compte quarante-deux agences réparties sur une trentaine de villes, chacune avec son propre sous-répertoire sur le site principal. La question centrale n’était pas de savoir comment afficher les annonces, mais comment les rattacher à une seule URL canonique tout en conservant une navigation cohérente par ville et par agence.
Choisir l’ordre des segments d’URL
Le premier arbitrage a porté sur l’ordre des segments : fallait-il structurer les URL par agence puis par ville, ou par ville puis par agence ? Le choix s’est porté sur la ville en premier segment, pour deux raisons pratiques. D’abord, un visiteur qui cherche un bien pense en ville avant de penser en agence ; ensuite, cet ordre regroupe naturellement toutes les annonces d’une même zone géographique sous un même chemin, ce qui facilite la construction d’une page ville riche en liens internes.
/annonces/lyon/agence-part-dieu/appartement-3-pieces-12345
/annonces/lyon/agence-croix-rousse/maison-t4-67890
/annonces/villeurbanne/agence-gratte-ciel/studio-98765
Cette arborescence place la ville en autorité de premier niveau, chaque agence devenant un sous-ensemble de cette autorité plutôt que l’inverse.
Gérer le cas des annonces en portefeuille croisé
Reste le cœur du problème : que faire quand une même annonce appartient au portefeuille de deux agences du réseau ? La tentation naturelle serait de générer une URL par agence détentrice, ce qui créerait mécaniquement deux pages quasi identiques. La règle retenue a été stricte : une annonce, une seule URL canonique, rattachée à l’agence historiquement responsable du mandat, quelle que soit l’agence qui la met également en avant dans ses propres listings.
function immo_canonical_annonce() {
if ( is_singular( 'annonce' ) ) {
$agence_mandataire = get_post_meta( get_the_ID(), 'agence_mandataire', true );
$url_canonique = home_url( '/annonces/' . get_post_meta( get_the_ID(), 'ville_slug', true ) . '/' . $agence_mandataire . '/' . get_post_field( 'post_name', get_the_ID() ) . '-' . get_the_ID() );
echo '<link rel="canonical" href="' . esc_url( $url_canonique ) . '">' . "\n";
}
}
add_action( 'wp_head', 'immo_canonical_annonce' );Les autres agences peuvent toujours afficher l’annonce dans leur propre listing, à une URL secondaire qui existe bien pour la navigation, mais qui pointe systématiquement, via ce canonical, vers l’URL de l’agence mandataire.
Construire des pages ville qui agrègent sans dupliquer
Une page ville comme /annonces/lyon/ agrège les annonces de toutes les agences du réseau présentes sur cette commune. Le piège classique consiste à répéter, pour chaque annonce listée, la description longue complète : sur une ville avec plusieurs centaines d’annonces, cela produit une page extrêmement lourde et largement redondante avec les pages individuelles.
- La page ville n’affiche qu’un résumé court et des critères structurés (prix, surface, type de bien)
- Chaque vignette pointe vers l’URL canonique de l’annonce, jamais vers une URL secondaire d’agence
- Un lien de filtre par agence reste disponible, mais génère un paramètre d’URL, pas un nouveau chemin indexable
Arborescence complète retenue
L’arborescence finale distingue clairement trois niveaux, chacun avec un rôle éditorial différent :
/
├── annonces/
│ ├── lyon/ (page ville, agrégation)
│ │ ├── agence-part-dieu/ (page agence, présentation + listing filtré)
│ │ └── appartement-3-pieces-12345 (annonce, URL canonique unique)
│ └── villeurbanne/
│ └── ...
└── agences/
└── agence-part-dieu/ (page vitrine de l'agence, équipe, avis)
La distinction entre le sous-répertoire /annonces/lyon/agence-part-dieu/ et la page vitrine /agences/agence-part-dieu/ répond à des intentions de recherche différentes : la première sert un visiteur qui cherche un bien à Lyon, la seconde un visiteur qui cherche spécifiquement cette agence, quelle que soit la ville de son prochain projet.
Ce que cette architecture ne traite pas
Le réseau opère uniquement en France et n’a, à ce stade, aucun besoin de gestion multilingue : cette architecture ne prévoit donc aucun mécanisme de préfixe de langue ni de balise hreflang, qui resteraient à ajouter séparément si le réseau venait à s’étendre au-delà de ses frontières actuelles.
Une bonne architecture d’URL immobilière ne cherche pas à représenter l’organisation interne du réseau, mais l’intention de recherche du visiteur. La ville d’abord, l’agence ensuite, jamais l’inverse.
En résumé
Face à un réseau d’agences partageant parfois les mêmes biens, la clé n’est pas de multiplier les URL mais de désigner sans ambiguïté une agence mandataire par annonce et de faire porter le canonical sur ce choix. Combinée à une hiérarchie ville puis agence, cette règle simple élimine la quasi-totalité du duplicate content interne au réseau sans sacrifier la navigation par agence.
