Site internet pour barbier avec référencement local

Le problème

Quelqu’un cherche un barbier dans sa ville. Il ouvre Google, il compare trois ou quatre salons sur la carte, il regarde les avis, les horaires, et il réserve chez celui qui lui a rendu la décision facile. Pour un gérant de salon, tout se joue là : être trouvé, être lisible, et laisser prendre rendez-vous sans appel.

Quand il cherche quelqu’un pour faire ce site, il tape « référencement local » et « prise de rendez-vous en ligne », et il tombe sur des offres qui promettent toutes la même combinaison, site plus fiche Google plus réservation, sans jamais montrer un site réel, la façon dont il est construit, ni ce qui se passe le jour où le salon ouvre une deuxième adresse. Sur ce dernier point, je n’ai trouvé aucune agence spécialisée coiffure ou barbier qui en parle. C’est pourtant la question qui change l’architecture du site.

L’approche

Un site de barbier avec une page hub « nos salons » et une page dédiée par établissement. Chaque page porte ses propres horaires, ses avis, son téléphone et son lien de réservation Planity, avec des données structurées qui permettent à Google de distinguer chaque adresse. C’est le site que j’ai construit pour La Barbière, salon style western avec deux adresses, au Mans et à Guécélard, à partir d’un brief posé en janvier 2026.

Le brief

Avant la première ligne de code, le salon a posé ce qui cadre tout le reste. Les services et leurs tarifs, coupe homme entre 21 et 25 €, barbe, coloration, permanente, lissage. Les personnes à qui le site s’adresse, nommées telles quelles : le professionnel pressé, le barbu soigné, le père qui vient avec son fils. Et un objectif principal, un seul : générer des prises de rendez-vous via Planity.

Ce brief comptait déjà deux salons. La page hub et la page par établissement y figurent déjà, avec le mot-clé « barbier Guécélard » noté « à activer à l’ouverture ». Le site a donc été pensé pour deux adresses avant que la seconde n’existe en ligne.

Une fiche structurée par salon

Pour que Google distingue deux adresses d’une même enseigne, chaque salon a son propre nœud de données structurées, typé à la fois BarberShop et HairSalon, avec son adresse postale, sa géolocalisation, ses horaires, son téléphone, sa zone desservie et ses avis. Les deux nœuds sont reliés à une Organization commune, la marque, par parentOrganization et subOrganization. En gros, Google voit une enseigne et deux établissements, pas une fiche diluée entre deux villes.

À côté, chaque page a ses propres titre et description, les pages légales sont en noindex, et le sitemap est généré avec une priorité par page. Tout est en place, et surtout tout est cohérent entre la fiche Google, Planity et le site.

La réservation, sans dépendance à une marketplace

Le lien de réservation appartient à la page du salon, pas l’inverse. Le client arrive sur le site, choisit son salon, et clique vers l’agenda Planity de cet établissement précis. Planity reste l’outil de prise de rendez-vous, un outil que le salon maîtrise déjà, et le site reste le point d’entrée que le salon possède. Le mot « planity » apparaît dans vingt fichiers du dépôt : le bouton est partout où quelqu’un peut avoir envie de réserver.

Ouvrir un deuxième salon sans dupliquer le site

En août 2026, le site est passé en architecture multi-salons : une page dynamique par établissement, un fichier de données propre à chaque salon, un type partagé qui garantit que les deux fiches ont exactement les mêmes champs. L’adresse de Guécélard est arrivée avec ses horaires, ses avis et son lien Planity, sans copier-coller la page du Mans. Si un troisième salon ouvre un jour, c’est un fichier de données de plus, pas un site de plus.

Stack et choix techniques

Un site de salon n’a pas besoin d’un serveur applicatif, il a besoin d’être servi vite. Du coup, c’est Astro 5 en statique pur, sans adapter SSR, avec Tailwind CSS 4. Le site entier ne compte que trois scripts côté client. Les données structurées sont centralisées dans un seul fichier, src/lib/schema.ts, dont la structure ressemble à ceci :

{
  "@type": "Organization",
  "name": "…",
  "subOrganization": [
    { "@type": ["BarberShop", "HairSalon"], "address": { "…": "Le Mans" } },
    { "@type": ["BarberShop", "HairSalon"], "address": { "…": "Guécélard" } }
  ]
}

Les images sont servies en JPEG et en AVIF pour l’affichage, et une version WebP est dérivée au build pour les données structurées. C’est un garde-fou : Google n’accepte dans ses résultats enrichis que jpg, png, webp, gif, bmp et svg, pas l’AVIF. Le format le plus léger sert donc le visiteur, et la version dérivée sert Google.

Deuxième garde-fou, arrivé avec l’architecture multi-salons : le site refuse de se construire si un salon marqué ouvert a une fiche incomplète, adresse, horaires ou lien Planity manquant. Une fiche de salon n’est jamais publiée à moitié remplie. Le déploiement suit ensuite deux workflows GitHub Actions, l’un pour la CI sur chaque pull request, l’autre qui construit l’image Docker, la pousse sur GHCR et la déploie sur un VPS derrière Caddy et Cloudflare en TLS Full strict, à chaque push sur main.

Résultat

Les chiffres de la Search Console, relevés le 20 septembre 2026 sur la recherche Google : 228 clics et 8 940 impressions sur six mois, et une accélération nette sur la fin de période. Les trois derniers mois concentrent 190 de ces clics, cinq fois plus que les trois mois précédents, et les 28 derniers jours à eux seuls en font 105, avec une position moyenne de 6,9. La courbe décolle fin août 2026, dans les jours qui suivent la mise en ligne de l’architecture multi-salons.

Ce qui me plaît le plus dans ces requêtes, c’est qu’elles ne sont pas toutes des recherches de marque. « barbier guecelard », « barber guecelard », « barbier le mans », « coiffeur barbier le mans » amènent déjà des clics : des gens qui ne connaissaient pas le salon et qui l’ont trouvé parce que chaque adresse a sa page. La réputation, elle, appartient au salon, 5,0/5 sur les deux plateformes où ses clients le notent avant même le site. Ma part, c’est qu’elle soit lisible sur chaque page, salon par salon, et que le chemin vers la réservation soit le plus court possible.

Questions fréquentes

Faut-il un site internet pour un barbier qui a déjà une fiche Google Business Profile ?

La fiche te fait apparaître sur la carte, le site est ce que tu possèdes. Sur la fiche, tu es limité au format de Google ; sur ton site, tu montres tes tarifs, ton équipe, ton identité, et tu tiens le lien de réservation. Les deux doivent porter exactement les mêmes nom, adresse et téléphone, c’est la première chose que je vérifie sur un salon.

Comment un site distingue-t-il plusieurs salons d’une même enseigne aux yeux de Google ?

Avec une page par établissement et un nœud de données structurées par salon, chacun avec son adresse, sa géolocalisation et ses horaires, tous reliés à une organisation commune. C’est ce que fait le site décrit ici : une enseigne, deux fiches distinctes, et un mot-clé local propre à chaque ville.

Faut-il intégrer la prise de rendez-vous au site ou renvoyer vers Planity ?

Mon point de vue : si ton salon tourne déjà sur Planity, garde-le pour l’agenda et fais du site le point d’entrée. Un lien par salon, placé partout où un visiteur peut vouloir réserver. Tu gardes ton outil et tu gardes ton audience.

Un site statique est-il assez rapide pour un salon local ?

Oui, et c’est même le meilleur cas pour lui. Un site de salon n’a pas de compte utilisateur ni de contenu qui change à chaque visite. En statique, chaque page est un fichier déjà construit, servi tel quel, avec presque aucun script côté client. Ici, trois scripts sur tout le site.

Si tu gères un salon, ou que tu t’apprêtes à en ouvrir un, et que tu veux un site qui porte ton référencement local et ta prise de rendez-vous sans te lier à une plateforme, c’est ce que je construis en site et application sur mesure.