Domaines et indexation

Décisions confirmées — 9 octobre 2026

L’opérateur a confirmé le domaine public définitif www.leclosdeseucalyptus.com. leclosdeseucalyptus.com redirigera de façon permanente (301 ou 308) vers la version avec www, en conservant chemin et paramètres. Cette redirection est à configurer dans la couche de routage par un opérateur autorisé ; ce ticket ne l’implémente ni ne modifie Cloudflare.

Le staging actuel est preview.px-playground.fr, puis sera preview.leclosdeseucalyptus.com. Ces deux hôtes restent protégés et non indexables. Toute preview additionnelle doit également rester hors de la liste d’hôtes autorisés. Les anciens hôtes px-playground.fr et www.px-playground.fr ne sont pas des variantes publiques du domaine définitif.

Configuration actuelle et cible

Les valeurs actuelles ci-dessous ont été déclarées par l’opérateur dans Dokploy ; elles n’ont pas été extraites de son panneau d’administration. Ce sont des paramètres non secrets.

Environnement	Hôte	SEO_INDEXING_ENABLED	SEO_INDEXING_ALLOWED_HOSTS	État
Production actuelle, encore limitée par Cloudflare	www.px-playground.fr	true	px-playground.fr,www.px-playground.fr	Confirmé par l’opérateur
Staging actuel	preview.px-playground.fr	false	non renseigné	Confirmé par l’opérateur
Production définitive, après autorisation de mise en ligne	www.leclosdeseucalyptus.com	true	www.leclosdeseucalyptus.com	Cible, non appliquée par ce ticket
Staging définitif	preview.leclosdeseucalyptus.com	false	vide	Cible, non appliquée par ce ticket
Préparation du domaine définitif avant ouverture	nouvel hôte public	false	vide	Politique de préparation, activation publique séparée

La production actuelle est donc configurée pour être indexable malgré la restriction d’accès. Cette observation explique les directives relevées pendant l’audit ; Cloudflare Access ne remplace pas les directives d’indexation de l’application. Pour une instance qui doit rester en préparation, l’opérateur utilise false et une liste vide. Aucune valeur actuelle n’a été modifiée ici.

Le mécanisme existant dans src/lib/server/search-indexing.ts exige à la fois la valeur exacte true et une correspondance exacte du hostname avec la liste CSV. Absence de valeur, liste vide, preview, domaine historique et domaine sans www restent non indexables avec la configuration cible. Il ne faut y mettre ni wildcard, ni URL complète, ni nom de domaine de test. Une préproduction héritant du flag true d’une application partagée reste non indexable tant que son hôte est absent de la liste. Une whitelist manuellement incorrecte doit être détectée par la recette, pas considérée sûre.

Comparaison avec les réponses déployées

Contrôle HTTP non authentifié effectué le 9 octobre 2026 :

Hôte / route	Réponse observée	Révision/version	Portée de la preuve
www.px-playground.fr/	200 ; robots=index,follow, googlebot=index,follow, aucun X-Robots-Tag	/healthz : e12c604e09192dd64096050fc20a31a0f381c16f, 0.1.0	Application actuelle indexable sur cet hôte
preview.px-playground.fr/healthz	200 ; X-Robots-Tag: noindex, nofollow, noarchive, nosnippet	137c723b96ab7a66b5c16ebf0f43619a1a565186, staging	Contrôle du header et de la révision exposée
preview.px-playground.fr/ et /en/	redirection Cloudflare Access	application non lue	Les metas de la page de connexion ne valident pas celles du site
px-playground.fr/ et /healthz	404 Cloudflare, sans directives applicatives	non disponible	Aucun rendu de l’application validé sur le domaine nu actuel

Staging exposait d’abord 9be5a139…, puis 137c723b… au recontrôle pendant le ticket. Le header noindex est resté présent. La recette a détecté l’écart avec l’ancienne révision attendue, confirmant l’intérêt du contrôle du SHA indépendamment des directives SEO.

La recette HTTP ajoutée dans ce ticket a également réussi ses 26 vérifications anonymes sur www.px-playground.fr en mode index, avec la révision attendue e12c604… : le health check et les 25 pages correspondent aux paramètres actuels confirmés. Ce résultat ne valide pas l’activation future sur le nouveau domaine.

Un contrôle complémentaire dans la session navigateur déjà authentifiée a vérifié les cinq pages (accueil, appartements, services, alentours, conditions générales) dans les cinq langues : les 25 documents affichés portent noindex,nofollow,noarchive,nosnippet pour robots et googlebot, avec le bon attribut lang. Les règles Access n’ont pas été modifiées. Cette observation DOM ne constitue pas un relevé des headers ou du statut HTTP de chacun de ces 25 documents ; le header applicatif noindex a été directement relevé sur /healthz.

La révision de production e12c604… contient déjà le même contrôle exact des hôtes, relié dans hooks.server.ts aux deux variables d’exécution. L’écart observé vient donc de la configuration actuelle confirmée, et non d’un mécanisme d’indexation à recréer. Les changements de domaine et de version déployée restent à exécuter dans une opération de mise en ligne distincte.

Recette HTTP

Depuis le dépôt web avec Node 22 :

npm run check:indexing -- https://preview.px-playground.fr noindex
npm run check:indexing -- https://preview.leclosdeseucalyptus.com noindex
npm run check:indexing -- https://www.leclosdeseucalyptus.com index "$WEB_REVISION_ATTENDUE"

La commande effectue uniquement des lectures GET : /healthz, puis accueil, appartements, services, alentours et conditions générales en français, anglais, allemand, espagnol et italien. Elle contrôle le statut 200, le lang du HTML, les deux metas robots/googlebot, le header X-Robots-Tag et la cohérence de la révision de /healthz. L’argument de révision doit être renseigné avec le SHA attendu de l’image autorisée, afin de distinguer une configuration correcte d’un contrôle réalisé sur une ancienne version.

• noindex : header et les deux metas contiennent noindex.
• index : les deux metas contiennent index,follow, aucun header ne contient noindex.
• Code de sortie 0 : toutes les vérifications réussies ; 1 : au moins une réponse incohérente ; 2 : vérification non disponible (arguments, réseau, redirections ou autorisation Access).

Sur les domaines protégés, utiliser un service token déjà autorisé pour cette application via CF_ACCESS_CLIENT_ID et CF_ACCESS_CLIENT_SECRET dans l’environnement local, sans les commiter ni les afficher. La commande ne crée aucun token et n’envoie ces en-têtes qu’au même hôte. Une redirection vers la connexion Access interrompt le contrôle ; elle ne peut pas passer pour un résultat valide. Sans accès autorisé, l’opérateur vérifie les metas dans sa session authentifiée et inscrit ce contrôle séparément. Ne pas ouvrir le domaine ou élargir les règles Access pour cette recette.

Vérifier également la redirection de l’apex, sans suivre automatiquement la réponse :

curl --silent --show-error --dump-header - --output /dev/null \
  'https://leclosdeseucalyptus.com/terms?source=recette-seo'

Attendu après bascule : 301/308, Location: https://www.leclosdeseucalyptus.com/terms?source=recette-seo. Ce contrôle peut actuellement atteindre l’ancien site ; seul l’opérateur déclenche la bascule.

Séquence de bascule opérateur

1. Valider la version web et le routage du nouveau domaine dans un environnement protégé, avec indexation désactivée. Garder staging en false et liste vide.
2. Préparer la redirection de l’apex, puis aligner les domaines Dokploy et les variables GitHub d’URL de déploiement/health check sur www.leclosdeseucalyptus.com.
3. Pour la mise en ligne expressément autorisée, appliquer true et la liste contenant uniquement www.leclosdeseucalyptus.com, puis exécuter le workflow officiel avec l’image validée. Le contrôle de promotion refuse un health check qui expose encore noindex ; ne pas contourner ce contrôle pour déployer une instance préparatoire.
4. Exécuter la matrice HTTP, les contrôles de redirection et ceux des deux previews après bascule. Consigner les statuts, directives et révisions, sans secrets, puis effectuer l’ouverture publique prévue par l’opération autorisée. Vérifier les réponses anonymes après cette ouverture.
5. En cas de report de mise en ligne, laisser l’instance préparatoire en false/liste vide.

Ces étapes sont une procédure ; ce ticket n’effectue ni déploiement, ni modification Dokploy, ni modification Cloudflare, ni ouverture au public. La recette HTTP sur les domaines futurs doit être exécutée par l’opérateur au moment approprié.