← Dossiers · Next.js
Quand un dropcatcher force la refonte — architecture SEO pour un hébergement isolé en Casamance
Refonte Astro 5 d'un hébergement isolé en Casamance après perte du domaine historique. Pillar/cluster, LodgingSchema, content collections : SEO longue-traîne sans budget pub.
Publié le
Sommaire
Quand on tient un hébergement isolé au bout d’une île, et que l’essentiel des prospects passe par une recherche Google avant de réserver, le SEO n’est pas un canal d’acquisition parmi d’autres : c’est la condition d’existence économique du lieu. Pas de panneau publicitaire en bord de route, pas d’agence touristique de proximité, pas de spontané sur le passage. Le voyageur tape « hébergement Carabane » ou « bungalow Casamance » depuis Dakar, Paris ou Bruxelles, et soit votre site sort dans les premiers résultats, soit votre saison est compromise.
Casa Casamance regroupe deux hébergements liés dans la même région du sud du Sénégal : Casa Star à Elinkine, sur le continent face à l’archipel, et Casa Crusoë sur la pointe nord de l’île de Carabane — secteur Efrane. Deux lieux, deux ambiances, une logistique commune (le transfert en pirogue est inclus). Le client est propriétaire et gère lui-même les deux structures. Quand il m’a contacté, il sortait d’un événement qui l’avait obligé à revoir toute sa présence en ligne : la perte de son domaine historique à un dropcatcher.
Ce dossier raconte la refonte complète qui a suivi — Astro 5, Cloudflare Pages, content collections typées, architecture SEO industrielle — et pourquoi cette contrainte initiale, qui aurait pu paraître subie, a en réalité débloqué un repositionnement business utile.
Le déclencheur — perte du domaine, opportunité cachée
Le domaine historique, casa-star-elinkine.com, était utilisé depuis plusieurs années par Casa Star. Un oubli de renouvellement, et le domaine est instantanément capté par un drop-catcher — un service automatisé qui surveille les expirations et acquiert les noms libérés dans la seconde, pour les revendre ou pour les exploiter avec du contenu publicitaire low-grade. Reprendre le domaine via une procédure UDRP était théoriquement possible, en pratique long et incertain. Le choix pragmatique : repartir sur un nouveau nom.
Ce qui aurait pu être un coup dur s’est révélé être une bonne occasion de tout repenser. L’ancien domaine portait star-elinkine — autrement dit, il enfermait la marque dans une géographie (Elinkine) et une seule des deux propriétés (Star). Or l’évolution naturelle de l’offre allait dans une autre direction : Casa Crusoë, l’hébergement sur l’île de Carabane, devenait progressivement le produit phare. Casa Star était de plus en plus utilisée comme point de départ avant le transfert pirogue vers Carabane.
casa-casamance.com a été choisi comme nouveau domaine. Plus générique, plus large géographiquement (la Casamance entière, pas une commune), permettant d’accueillir les deux propriétés sous une bannière commune. Le repositionnement business était posé avant même que la première ligne de code ne soit écrite.
Le repositionnement — hiérarchie d’offre claire
L’architecture du nouveau site reflète directement cette hiérarchie. Navigation et footer placent Casa Crusoë en premier. La home s’ouvre sur l’expérience insulaire — la pointe nord de Carabane, la vue ouverte sur l’embouchure du fleuve, le secteur Efrane. Casa Star reste présente, mais positionnée comme « point de départ » et étape complémentaire, plus que comme offre primaire.
Conséquence éditoriale concrète : le contenu sur Carabane prend trois fois plus de place que celui sur Elinkine. Les photographies, les guides, les FAQ — tout pousse vers la même direction. Le voyageur qui arrive sur le site comprend en quinze secondes que la proposition de valeur principale, c’est l’île ; et que Casa Star, c’est le sas logistique pour y accéder.
Un encart de cross-sell combiné est introduit sur les deux fiches d’hébergement, proposant explicitement de séjourner sur les deux pour une expérience plus longue. Le mot-clé critique du site — celui sur lequel le SEO est joué — devient Carabane, pas Elinkine. C’était une décision business à valider avec le client avant tout choix technique, et qui a structuré ensuite tout le reste.
L’architecture SEO — pillar et clusters
Pour un hébergement isolé, la stratégie SEO efficace n’est pas de viser les méga-requêtes commerciales (« hôtel Sénégal »), trop concurrentielles et trop génériques pour convertir. Elle est de construire un maillage informationnel sur la destination, qui répond aux vraies questions des voyageurs en amont de la décision de réservation, et qui ramène ce trafic vers les pages produit via un système de liens internes maîtrisé.
Architecture mise en place : un pillar central, /guide-casamance/, qui présente la région de manière complète et fait office de hub. Et six articles clusters thématiques liés autour de ce pillar :
- Comment se rendre en Casamance (avion, route, ferry)
- L’île de Carabane — histoire, géographie, accès
- Quand venir en Casamance (saisons, climat, événements)
- Activités à faire (excursions, pêche, faune, plages)
- Cuisine et culture diola
- Préparer son séjour (santé, vaccins, monnaie, sécurité)
Chaque cluster pointe vers le pillar et les autres clusters via un composant RelatedContent.astro. Le pillar pointe vers chaque cluster. Et chaque article propose, en fin de page, un appel vers les hébergements concernés (Crusoë ou Star ou le combiné, selon la pertinence). C’est l’architecture classique pillar/cluster popularisée par HubSpot, appliquée ici avec rigueur — pas une vague taxonomie de mots-clés saupoudrés, mais un graphe explicite documenté.
Sur le plan structuré, chaque hébergement est marqué avec un LodgingSchema JSON-LD complet (sous-type de LodgingBusiness), incluant adresse, géolocalisation, équipements, capacité, langues parlées, et priceRange indicatif. Le pillar et les clusters sont marqués en Article, avec author, datePublished, et inLanguage. Les FAQ en bas de chaque page sont marquées en FAQPage — un type qui n’apporte plus de rich results depuis mai 2026, mais qui reste utile pour les agents IA et les answer engines type Perplexity qui scannent activement le balisage sémantique.
Les choix techniques — Astro 5 et Cloudflare Pages
Le choix d’Astro 5 plutôt que WordPress, Next.js ou un CMS traditionnel s’est fait sur trois critères : performance maximale par défaut (HTML statique pré-rendu, aucun JS sur les pages contenu), DX moderne pour itérer vite, et zéro coût d’hébergement via Cloudflare Pages.
Le déploiement sur Cloudflare Pages couvre l’intégralité du besoin : hébergement statique gratuit, CDN mondial, HTTPS automatique, déploiements continus à chaque push GitHub. Pour un site qui ne nécessite ni base de données ni logique serveur lourde (les seules interactions dynamiques sont le formulaire de contact et un sélecteur de dates côté pirogue), c’est l’option économiquement la plus efficace possible.
Content collections typées
Astro 5 propose un système de content collections très adapté à un site éditorial structuré. Chaque article du guide est un fichier Markdown avec un frontmatter typé Zod. Si un fichier ne respecte pas le schéma, le build échoue avec un message d’erreur précis. Plus de dérive silencieuse possible — un auteur qui oublie de remplir le champ cover_image ou qui met une date au mauvais format est rattrapé instantanément.
Pour Casa Casamance, deux collections cohabitent : guides (le pillar et les six clusters) et hebergements (Crusoë, Star, et le combiné). Chacune avec son propre schéma typé, et reliée à l’autre via des referencefields.
Centralisation des routes — routes.ts
Plutôt que de manipuler des chemins en dur dans chaque composant — <a href="/guide-casamance/quand-venir/"> — un fichier src/lib/routes.ts centralise toutes les routes du site sous forme de constantes typées et de fonctions. Une route qui change ne nécessite plus de chercher tous les liens à mettre à jour : un seul changement, propagé partout. C’est un détail d’organisation, mais qui paie chaque fois qu’on touche à l’arborescence.
Composants SEO en bibliothèque
Quatre composants Astro structurent toute la couche SEO du site :
SEO.astro— émet title, description, canonical, OpenGraph, Twitter, et accepte un slotheadpour injection de JSON-LD spécifique à la pageBreadcrumb.astro— fil d’Ariane visuel ET balisageBreadcrumbListJSON-LDLodgingSchema.astro— composant dédié à l’émission du JSON-LDLodgingBusiness, paramétré par les données du frontmatter de l’hébergementFAQ.astro— UI accordéon en plain JS (pas de React) + balisageFAQPageJSON-LD synchronisé
Chaque composant émet son balisage de manière autonome. La page assemble simplement les briques nécessaires à son type. Pas de logique SEO disséminée dans chaque template.
Contact form sans backend
Le formulaire de contact est servi par Web3Forms, un service tiers qui transfère les soumissions de formulaire HTML vers une boîte mail sans nécessiter de backend. C’est une dépendance externe, mais qui évite de monter une fonction serverless pour un cas d’usage trivial. Après soumission, redirection vers une page merci.astro qui confirme et propose de poursuivre la navigation.
Les pièges rencontrés
Trois bugs valent d’être documentés parce qu’ils sont du type qui consomme une après-midi entière sans laisser de trace utile dans les logs.
entry.id ne correspond pas toujours au slug
Astro expose pour chaque entrée d’une content collection deux propriétés proches mais distinctes : entry.slug (le slug utilisé pour les URLs) et entry.id (l’identifiant interne, qui inclut souvent l’extension .md ou .mdx). Une fonction de lookup construite à partir de entry.id ne matche pas avec un slug venant de Astro.params.slug, et le résultat est un 404 silencieux sur des routes pourtant définies en getStaticPaths().
Le fix : normaliser systématiquement en stripper l’extension quand on construit une map de lookup. Une ligne, mais qui demande d’avoir identifié le décalage entre les deux propriétés — et la documentation officielle n’insiste pas sur ce point.
Apostrophes dans JSON-LD
Une FAQ rédigée en français contient inévitablement des apostrophes — l’île, jusqu’à, aujourd’hui. Quand ce texte est interpolé dans un objet JavaScript qui est ensuite JSON.stringify-é pour produire le bloc JSON-LD, tout dépend du type de guillemets utilisés. Avec des single quotes JS, les apostrophes du texte ferment la chaîne prématurément et génèrent un JSON invalide, qui sera ignoré par Google et Schema.org Validator sans afficher d’erreur dans le browser.
La règle posée pour le projet : toujours utiliser des double quotes pour les valeurs string dans les objets JSON-LD avant stringify. C’est une convention d’écriture, pas une feature technique. Une fois posée, plus aucun bug de ce type.
[...slug].astro et paths multiples
Le pillar /guide-casamance/ est une page racine, et chaque cluster est /guide-casamance/[topic]/. Naïvement implémenté en [slug].astro ou [...slug].astro mal paramétré, on tombe sur des conflits de routing où Astro ne sait pas trancher entre la version pillar et les clusters.
Solution : un fichier [...slug].astro unique avec un getStaticPaths() qui retourne explicitement chaque chemin attendu, y compris le pillar lui-même (avec un slug vide). Le composant à l’intérieur branche sur la longueur du slug pour render le bon layout.
Ce que ce projet apprend
L’architecture SEO peut suffire quand le budget pub n’existe pas. Pour un hébergement isolé, la longue-traîne informationnelle (« quand venir en Casamance », « comment se rendre à Carabane ») convertit dix fois mieux que les requêtes commerciales saturées. Construire ce maillage demande de la rigueur et du temps de rédaction, mais le résultat tient dans la durée et continue de capter du trafic sans recharge mensuelle, contrairement à du SEA.
Astro 5 est le bon outil pour les sites informationnels structurés. Pour ce profil de projet — site éditorial avec un peu de marketing, peu d’interactions, beaucoup de contenu textuel — Astro coche toutes les cases : pré-rendu statique, content collections typées, balisage SEO maîtrisé, déploiement gratuit. Choisir Next.js ou Nuxt ici serait sur-dimensionné. Choisir WordPress serait sous-dimensionné côté DX moderne.
Une refonte forcée par un événement extérieur n’est pas une catastrophe. Le dropcatcher a coûté un domaine et obligé à des frais imprévus. Mais sans ce déclencheur, le repositionnement business — Crusoë devant Star, le mot-clé Carabane plutôt qu’Elinkine — ne se serait probablement pas fait avant des années. C’est une généralité utile : les contraintes subies débloquent souvent des décisions qui flottaient dans le « il faudrait qu’on » depuis trop longtemps.
Le site continue d’évoluer — la prochaine itération doit introduire un calendrier de disponibilité auto-renseigné côté admin et un système de paiement direct pour les acomptes. Mais l’architecture posée tient sans modification structurelle : ce qu’on attend d’une fondation bien dimensionnée.