Ce que le référencement
exige réellement

Google traite le JavaScript en trois phases séquentielles : exploration → rendu → indexation. Le point critique est la file d'attente de rendu.

« Googlebot queues all pages with a 200 HTTP status code for rendering […] The page may stay on this queue for a few seconds, but it can take longer than that. » — Google Search Central — JavaScript SEO Basics

Google ne publie aucun chiffre officiel sur la durée de cette file. Méfiez-vous des « 9 jours en moyenne » qui circulent : ce sont des mesures tierces.

Bing est plus restrictif encore : Microsoft écrit qu'il « peut être difficile pour bingbot de traiter le JavaScript à grande échelle » et recommande le prerendering.

Le HTML généré au build n'apporte pas de bonus de classement — il n'en existe pas. Il supprime une phase entière du pipeline et garantit l'accès aux robots sans JS. C'est une condition d'éligibilité, pas un levier.

Votre site

100 % statique, généré au build. Cet avantage est déjà acquis — et c'est le plus structurant de tous.

La citation qui remet tout à sa place :

« Google Search always seeks to show the most relevant content, even if the page experience is sub-par. » — Google — Page Experience

Google confirme que les CWV « sont utilisés par nos systèmes de classement », tout en précisant que de bons scores « ne garantissent pas que vos pages seront classées en tête ». Lecture défendable : un facteur départageur entre contenus de pertinence comparable, jamais un substitut à la pertinence.

Le « SEO score » n'existe pas chez Google

Le score Lighthouse (0-100) est du lab data simulé. Le classement s'appuie sur le field data (CrUX, utilisateurs réels). Un « SEO score 98/100 » affiché par Semrush, Yoast ou Lighthouse n'a aucune existence chez Google. C'est la première chose que votre langage JSON ne doit pas chercher à optimiser.

Point capital, et rarement expliqué. Le classement utilise les données de champ (CrUX), pas le laboratoire. Or CrUX exige qu'une page soit « suffisamment populaire » — seuil non divulgué.

Un site de 13 pages à faible trafic est donc évalué au niveau de l'origine, pas par URL. La conséquence est contre-intuitive et importante :

La page la plus lente contamine les douze autres

Sans cloisonnement par URL, une seule page lourde dégrade l'évaluation du site entier.

Autre exclusion notable : Chrome sur iOS ne contribue pas à CrUX. En Suisse romande, où la part d'iPhone est élevée, le bassin de collecte est encore réduit.

Délai de visibilité d'une correction — fenêtre glissante de 28 jours :

Premier frémissement

J+3

Effet à 50 %

J+16

Fenêtre purgée

J+30

Toute mesure prise à J+7 est du bruit. La parade réelle : collecter vos propres données de champ (bibliothèque web-vitals → Cloudflare Worker), qui n'a pas de seuil minimum et capture Safari/iOS.

Google suit jusqu'à 10 sauts de redirection.

Le soft 404 : le serveur répond 200 mais le contenu indique une erreur. Google l'identifie en analysant le contenu rendu. Nuisible car il consomme du crawl et fait indexer des pages vides sous une infinité d'adresses.

« 410 désindexe plus vite que 404 »

La documentation dit explicitement que 403, 404 et 410 sont traités de la même manière. L'avantage du 410 est une observation de terrain, pas une règle.

Votre site — vérifié en ligne

Les trois versions renvoient un vrai 404 sur une adresse fausse. La version statique renvoyait auparavant 200 avec le HTML de l'accueil : c'était un soft 404, corrigé.

Google délimite précisément qui est concerné — « rough estimates, not exact thresholds » :

1. Plus d'un million de pages uniques, contenu changeant hebdomadairement 2. Plus de 10 000 pages uniques, contenu changeant quotidiennement 3. Une grande part d'URLs en « Découverte, actuellement non indexée »

Conclusion pour un site de 13 pages

Optimiser le budget de crawl ici est du théâtre SEO. Seul le critère 3 mérite une surveillance. N'y consacrez aucune ressource.

Aucune documentation Google n'affirme que <header>, <nav>, <main>, <article> ou <section> influencent le classement.

John Mueller a déclaré à plusieurs reprises qu'<article> n'a pas d'effet direct. Ces propos sont des déclarations d'employé, fiables directionnellement, mais pas de la spécification.

Les vraies raisons de les utiliser : accessibilité (régions ARIA implicites pour les lecteurs d'écran), maintenabilité, extraction par les robots d'IA. Argumentez sur l'accessibilité, jamais sur un gain de classement.

Rupture majeure : les résultats enrichis FAQ sont supprimés

« This feature will no longer appear in Google Search starting May 7, 2026. » — Google — FAQPage structured data (vérifié à la source)

La documentation a été retirée le 15 juin 2026. Le balisage

FAQPage

ne produit

plus aucun résultat enrichi, pour personne

. Il ne nuit pas s'il reste en place, mais en attendre de la visibilité est faux.

Le piège des avis auto-attribués

« If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature. » — Google — Review snippet (vérifié à la source)

Baliser vos propres témoignages en

Review

vous rendrait inéligible et vous exposerait à une action manuelle.

Votre site — audité en ligne

LocalBusiness, WebSite, WebPage, BreadcrumbList et Service présents. Zéro balisage Review sur les 5 témoignages — c'est la bonne décision, et elle vous évite une sanction. Le FAQPage de l'accueil est devenu inerte : sans danger, sans bénéfice.

Formats indexables : BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.

width et height ne sont pas des attributs « SEO » : ils permettent au navigateur de réserver l'espace avant le chargement, éliminant le décalage. C'est la cause n° 1 de CLS évitable.

Ne jamais mettre loading="lazy" sur l'image LCP

Mesures web.dev sur un thème WordPress : retirer le lazy loading au-dessus de la ligne de flottaison améliore le LCP médian de 13 % en desktop (2 029 → 1 759 ms) et 15 % en mobile (1 657 → 1 403 ms).

<!-- Image LCP --> <img src="hero.avif" width="1200" height="675" fetchpriority="high" alt="…"> <!-- Tout le reste --> <img src="x.webp" width="800" height="600" loading="lazy" decoding="async" alt="…">

Google ne fixe aucune limite de caractères. La documentation dit que les titres sont tronqués « typically to fit the device width ». La mesure est en pixels rendus.

Contre-intuitif : le desktop est plus contraignant que le mobile

Le desktop tronque sur une seule ligne ; le mobile passe à la ligne et affiche davantage. Corollaire : un titre en MAJUSCULES est tronqué ~30 % plus tôt à nombre de caractères égal.

Votre site — mesuré sur les 6 pages principales

46 à 57 caractères. Toutes vos pages sont dans la fenêtre optimale.

De même, les crochets sont réécrits à 77,6 % contre 61,9 % pour les parenthèses.

Attention à la lecture

Le pipe n'est pas pénalisé et le tiret n'améliore pas le classement. L'écart porte sur la conservation du titre tel quel, pas sur le rang.

Votre site

Trois pages utilisent le pipe (Pass Découverte — Demi-journée & portraits | Kaina). Votre propre validateur le signalait déjà en avertissement. Correctif trivial, gain mesurable sur la conservation.

La donnée la plus actionnable de cette section :

La leçon générale : Google arbitre entre le title et le H1. Quand les deux concordent, il n'a rien à arbitrer.

La bonne pratique n'est ni « identiques » ni « divergents » mais concordants : même noyau sémantique (mot-clé, chiffres, entité), habillage différent (le title ajoute la marque, le H1 respire).

« You can use H1 tags as often as you want on a page. There's no limit, neither upper nor lower bound. […] Your site is going to rank perfectly fine with no H1 tags or with five H1 tags. » — John Mueller, Google

« From Google Search perspective, it doesn't matter if you're using them out of order. […] H1 is the most important heading for screen readers but it's not the most important for Google. » — Gary Illyes, Google

Illyes ajoute, visant directement les audits qui signalent en rouge un saut H2→H4 : « Just because a non-Google tool tells you something is good or bad, that doesn't make it relevant for Google. »

La formulation juste

Respectez la hiérarchie — pour l'accessibilité, pas pour le SEO. Ne vendez jamais une refonte de hiérarchie Hn comme un levier de positionnement : Google a dit l'inverse.

Votre site — audité en ligne

Un seul H1, hiérarchie h1 h2 h3 h3 h3 h2 h2 h3…sans aucun saut. Irréprochable, et conforme WCAG 1.3.1.

Retirée des signaux de classement en 2009. Son effet est indirect, via le taux de clic.

Le constat qui contredit tous les plugins SEO

Ahrefs (20 000 mots-clés, 192 656 pages) : Google réécrit 62,78 % des meta descriptions. Et surtout — respecter la longueur idéale n'améliore pas le taux de conservation : 63,69 % de réécriture pour les bien dimensionnées contre 61,46 % pour les trop longues. La longueur n'est donc pas le levier anti-réécriture.

Un quart des pages les mieux classées n'a aucune meta description. Écrivez-en sur les pages commerciales, où les 37 % de cas où elle passe comptent le plus.

Liste blanche réelle : description, robots/googlebot, google-site-verification, notranslate, viewport, charset, rating (adult), nopagereadaloud. Tout le reste est décoratif pour Google.

Le 23 janvier 2025, Google a retiré le fil d'Ariane des extraits mobiles

Remplacé par le nom de domaine seul. Il reste affiché sur desktop. L'argument « le fil d'Ariane améliore le CTR mobile » n'est plus valable.

Les bénéfices durables sont ailleurs : maillage interne ascendant, transmission de PageRank vers les pages de catégorie, compréhension de la taxonomie, accessibilité.

<nav aria-label="Fil d'Ariane"> <ol> <li><a href="/">Accueil</a></li> <li aria-current="page">Page actuelle</li> </ol> </nav>

Le dernier élément du JSON-LD n'a pas besoin de item.

« Keyword stuffing refers to the practice of filling a web page with keywords or numbers in an attempt to manipulate rankings. » — Google — Spam Policies

Parmi les exemples explicitement cités par Google : les listes de villes ou régions pour lesquelles une page tente de se positionner. C'est précisément le piège d'un service à Genève et Lausanne.

<!-- ❌ Violation explicite --> <footer>Photographe femme Genève, photographe femme Lausanne, photographe femme Nyon, séance photo Genève, séance photo Lausanne…</footer> <!-- ✅ Mention géographique porteuse de sens --> <p>Les journées ont lieu à Genève et à Lausanne, dans un lieu choisi ensemble.</p>

Le critère opérationnel de Google est simple : le texte sonne-t-il naturellement lu à voix haute ? Pas un pourcentage.

C'est le point que la quasi-totalité des agences présentent de travers.

• Les Search Quality Rater Guidelines précisent aux évaluateurs que leurs notes ne modifient pas les classements.
• Les ~10 000 évaluateurs humains produisent des données servant à entraîner et valider les systèmes, jamais à noter des pages en production.
• Il n'existe aucun « score E-E-A-T » dans l'algorithme.

Formulation correcte : E-E-A-T est le concept que les signaux de Google tentent d'approximer. Ce sont ces signaux (liens, mentions, cohérence d'entité, historique, comportement) qui agissent — pas E-E-A-T lui-même. On n'« optimise » pas pour E-E-A-T : on construit une réputation réelle et on la rend lisible par les machines.

Google donne un cadre : Who / How / Why — qui a écrit, comment le contenu a été produit (y compris l'usage de l'IA), et pourquoi il existe.

« Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't.) » — Google — Creating helpful content

Cette question figure dans la liste des signaux d'alerte de Google — écrire pour un quota est présenté comme un symptôme de contenu conçu pour les moteurs.

Les études de corrélation, lues correctement

Ahrefs (~900 millions de pages) trouve une forte corrélation longueur ↔ domaines référents. Ahrefs eux-mêmes en donnent la lecture juste : c'est un processus en deux étapes — un contenu long obtient plus de liens, et les liens améliorent le classement. La variable causale est le lien, pas le mot. Rallonger un texte sans gain de substance ne produit aucun lien, donc aucun effet.

Contre-preuve décisive : Ahrefs mesure une corrélation quasi nulle (Spearman = 0,04) entre longueur et citation dans les AI Overviews. Si la longueur était causale, elle se serait maintenue.

Google a publié dès 2008 un article intitulé « Demystifying the duplicate content penalty ». Il n'existe aucun seuil de pourcentage de similarité. Les outils affichant « 87 % de similarité — danger » appliquent un modèle qui n'existe pas chez Google.

Ce qui se passe réellement : Google regroupe les pages similaires, choisit une canonique, et consolide les signaux vers elle. Ce n'est pas une sanction, c'est une consolidation. Le problème pratique : Google peut choisir une autre canonique que la vôtre.

Le vrai risque, documenté par un cas réel

Un site avec plus de 3 000 pages de localisation a reçu une action manuelle « thin content ». Le détail décisif : les textes étaient réellement différents, rédigés par des humains. La reformulation ne suffit pas — la différenciation doit porter sur des faits, pas des synonymes.

Google a explicitement neutralisé la question « IA ou humain » en mars 2024, en remplaçant l'ancienne politique sur le contenu automatique par le scaled content abuse :

Cette règle permet à Google d'agir « que le contenu soit produit par automatisation, par des humains, ou par une combinaison des deux ». — Google — March 2024 spam policies

Le critère n'est plus la méthode mais le résultat : production de masse sans valeur ajoutée.

Ce qui vous protège structurellement

Votre proposition de valeur repose sur l'expérience vécue — le pilier « Experience » de E-E-A-T, celui que l'IA ne peut pas fabriquer. « Une cliente est arrivée en larmes à sa séance de janvier » ne peut venir que de vous.

1.4.12 est souvent mal compris

Il n'exige pas que votre design ait un line-height: 1.5. Il exige qu'il ne casse pas si l'utilisateur l'impose. L'échec typique n'est pas typographique mais structurel : hauteurs fixes, overflow: hidden, conteneurs non extensibles.

Safari sur iOS — et tous les navigateurs iOS, contraints d'utiliser WebKit — zoome automatiquement le viewport quand un champ de saisie reçoit le focus et que sa taille calculée est strictement inférieure à 16 px.

• Seuil dur : 16 px ne déclenche pas le zoom, 15,99 px oui.
• C'est la taille calculée et rendue qui compte, pas la valeur déclarée.
• Le zoom n'est pas annulé au blur — c'est le vrai coût : toute la mise en page reste zoomée.

La mauvaise solution

user-scalable=no supprime le zoom auto et interdit le zoom volontaire → échec direct de WCAG 1.4.4. iOS l'ignore d'ailleurs largement depuis la version 10.

input, textarea, select { font-size: max(16px, 1rem); }

max() garantit le plancher tout en laissant la taille croître si l'utilisateur a augmenté sa police racine.

Votre site — mesuré en ligne

Champ e-mail à 17 px. Au-dessus du seuil, pas de zoom iOS. Bouton d'envoi 145 × 60 px, bien au-delà des 44 px AAA.

Le W3C documente formellement cet échec sous la technique F94 : « Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize text ».

Le mécanisme : quand l'utilisateur zoome, les pixels CSS grossissent, donc le viewport mesuré en pixels CSS rétrécit. À 200 %, un écran de 1440 px ne fait plus que 720 px CSS. Or 1vw = 1 % de cette largeur. Les deux effets s'annulent exactement — le texte en vw pur ne grossit pas du tout.

Comportement au zoom 200 %

Taille du H1 mesurée sur votre site, à viewport 1440 px puis 720 px (= zoom 200 %)

clamp(3.5rem, 9vw, 8rem)

sans composante rem — votre code actuel

152 px

79 px — rétrécit de 48 %

clamp(3.5rem, 1.83rem + 6.86vw, 8rem)

avec composante rem — conforme F94

152 px

152 px — conservé

Mesure réelle effectuée sur le site en production, pas une simulation.

La règle : la valeur préférée doit être de la forme Xrem + Yvw, jamais Yvw seul, et MAX ≤ 2,5 × MIN.

Votre site — défaut confirmé par la mesure

35 déclarations clamp() sans composante rem. Vérifié dans le navigateur : à l'équivalent d'un zoom 200 %, le H1 passe de 152 px à 79,2 px — il rétrécit de moitié au lieu de doubler. Échec de WCAG 1.4.4 (AA), qui est une obligation normative. Bonne nouvelle : le corps de texte n'est pas touché (16–18,8 px, il grossit correctement). Tous les ratios sont déjà sous 2,5 — seule la composante rem manque. Le correctif est mécanique et calculable.

Résolutions réelles (StatCounter, juillet 2026) : mobile très fragmenté — 414×896 (13,2 %), 360×800 (9,1 %), 390×844 (6,7 %). Desktop : 1920×1080 domine à 22,4 %, mais 1536×864 à 7,3 % rappelle que beaucoup d'utilisateurs Windows sont à 125 % de mise à l'échelle. Concevoir « pour du 1920 » revient souvent à concevoir pour du 1536 réel.

Longueur de ligne : le seul chiffre opposable est WCAG 1.4.8 (AAA) — ≤ 80 caractères. La fourchette 50–75 très citée relève de la tradition typographique, non d'un essai contrôlé.

Formule officielle : (L1 + 0,05) / (L2 + 0,05), avec L = 0,2126·R + 0,7152·V + 0,0722·B après linéarisation gamma (seuil 0,04045, pente 12,92, exposant 2,4).

APCA n'est pas dans WCAG 3 — contrairement à ce qu'on lit partout

L'AGWG a retiré APCA de la spécification en 2023, faute de soutien. La note d'édition en vigueur est sans ambiguïté : « The contrast algorithm used in WCAG 3 is yet to be determined. » Les obligations légales (EAA, ADA, RGAA, LHand suisse) référencent WCAG 2.x niveau AA, jamais APCA. N'abandonnez jamais les seuils WCAG 2 au prétexte qu'APCA valide une couleur.

J'ai calculé ces ratios moi-même avec la formule officielle, puis un agent les a recalculés indépendamment. Les deux calculs concordent au millième.

Trois constats sur votre site

1. Le socle est excellent : noir/crème, noir/blanc, gris-sur-noir — tous AAA sans réserve. 2.#6e6e6e sur crème passe AA avec 0,06 de marge. C'est une conformité sans filet : le moindre ajustement le fait basculer. Correctif : #5a5a5a (≈ 5,8:1) pour une marge confortable, ou #515151 (7,10:1) pour viser AAA. 3.#a9a9a9 échoue totalement sur fonds clairs (2,10:1). Il est conçu pour le fond noir. Ce jeton doit être verrouillé au thème sombre — sinon c'est un bug d'accessibilité en attente. Le gris clair (1,30:1) sert de fond d'attente derrière les images, jamais de texte — donc conforme, car 1.4.11 ne couvre que les composants d'interface. Une exception vérifiée : le séparateur « / » du fil d'Ariane, purement décoratif.

Formulation honnête : accessibilité et SEO partagent des moyens techniques (HTML sémantique, texte alternatif, liens explicites) parce que les deux servent un agent qui ne voit pas la page. Mais une grande partie de l'accessibilité n'a aucun effet SEO — justifiez-la par la conformité légale.

alt="" et non alt omis

alt="" retire l'image de l'arbre d'accessibilité — correct. Omettre l'attribut fait annoncer le nom de fichier par certains lecteurs d'écran — incorrect. Google interdit explicitement le bourrage : « may cause your site to be seen as spam ».

Votre favicon ne peut pas s'afficher dans Google

Fichier mesuré : logo-88.webp = 88 × 49 px. C'est un rectangle, alors que Google exige un ratio 1:1 strict. Le ratio non carré est la cause n° 1 documentée de non-affichage : Google substitue un globe générique. Second défaut : /favicon.ico renvoie 404 — or Bing va le chercher à la racine en priorité, même sans balise <link>.

Taille réellement affichée : ~16 × 16 px CSS en desktop, soit 32 à 48 px physiques sur écran Retina. D'où la recommandation « > 48×48 » : il faut de la matière pour le redimensionnement. Un favicon 16×16 natif sera flou sur tout écran moderne.

Le jeu de fichiers moderne — l'époque des 20 fichiers est révolue :

<link rel="icon" href="/favicon.ico" sizes="32x32"> <link rel="icon" type="image/png" href="/favicon-96.png" sizes="96x96"> <link rel="icon" href="/icon.svg" type="image/svg+xml"> <link rel="apple-touch-icon" href="/apple-touch-icon.png"><!-- 180×180 -->

Le piège le plus insidieux

Il faut deux autorisations dans robots.txt : Googlebot sur la page d'accueil et Googlebot-Image sur le fichier favicon. Un Disallow: /assets/ tue le favicon silencieusement — le site s'indexe parfaitement, seul le favicon disparaît.

Autres causes fréquentes : URL instable (hash de build changeant à chaque déploiement — excluez le favicon du hashing), data URI (ne fonctionne pas, Googlebot-Image doit crawler une URL réelle), un favicon par hostname uniquement (impossible d'en avoir un propre à /blog).

Ordre de priorité des signaux, vérifié à la source :

1. Données structurées WebSite — le plus fort 2. og:site_name 3. Balise <title> 4. Titres <h1> et texte de la page d'accueil

Placement impératif

Le WebSite schema doit être sur la page d'accueil uniquement, au niveau du domaine ou sous-domaine. Google ne lit ce signal nulle part ailleurs. Une incohérence entre og:site_name, <title> et WebSite.name fait perdre le signal.

Votre site

WebSite avec name: "Kaina Expérience" et og:site_name identique. Cohérent, correctement placé.

Google liste explicitement parmi les abus de type doorway :

« Multiple domain names or pages targeted at specific regions or cities that funnel users » — Google — Spam Policies

Un cas documenté qui change la façon de voir

Un site avec

plus de 3 000 pages de localisation

a reçu une action manuelle « thin content ». Le détail décisif :

le propriétaire avait payé des rédacteurs humains, et les textes étaient réellement différents

.

« The wording on all the pages was actually different. But simply rewording similar content, especially when you have thousands of pages, isn't enough to please Google. » — Sterling Sky

Le test de validation, à faire avant publication : imprimez les deux pages, masquez tous les noms de villes. Si un lecteur ne peut pas dire laquelle est laquelle, la page n'existe pas encore.

Ce qui doit différer substantiellement (au moins 5 éléments sur 7) : le lieu réel décrit et photographié, les témoignages de clientes de cette ville, l'accès concret (TPG vs TL/M2, Cornavin vs Lausanne-Flon), les lieux de prise de vue extérieurs, les modalités propres, les partenaires locaux, l'angle éditorial.

Votre atout non copiable

Vous êtes photographe : vous ne pouvez pas dupliquer des photos entre Genève et Lausanne. Elles sont intrinsèquement locales et uniques. Là où la plupart des sites multi-villes échouent (contenu reformulé), vous disposez d'un différenciateur structurel. C'est simultanément votre protection anti-doorway et votre argument de conversion.

Votre site aujourd'hui

Aucune page ville. Donc aucun risque actuel. Le risque n'apparaîtra que le jour où vous en créerez.

Étude Whitespark 2026 (47 experts). Nature de la donnée : opinions agrégées d'experts, pas une mesure de l'algorithme. C'est la meilleure donnée disponible, pas une expérimentation.

Local Pack vs organique local

Local Pack (carte)

Organique local

Fiche Google

32 %

Contenu on-page

33 %

Avis

20 %

Liens

24 %

Contenu on-page

15 %

Comportemental

10 %

Comportemental

9 %

Personnalisation

8 %

Liens

8 %

Fiche Google

7 %

Genève se gagne par la fiche Google et les avis (52 %).

Lausanne se gagne par le contenu et les liens (57 %).

L'écart entre les deux colonnes est votre feuille de route à deux villes.

Top 5 des facteurs individuels du Local Pack : catégorie principale de la fiche (227 pts), proximité de l'adresse (225), mots-clés dans le titre de la fiche (223), adresse dans la ville recherchée (213), établissement ouvert au moment de la recherche (189).

La conséquence stratégique

Avec une seule adresse réelle, vous ne rankerez pas ou peu dans le Local Pack de Lausanne — la proximité est le facteur n° 2. C'est en organique local que Lausanne se gagne, où le contenu pèse 33 % et la fiche seulement 7 %. La qualité substantielle de votre future page Lausanne est donc votre unique voie d'accès à ce marché.

Une fiche ou deux ? Les règles Google sont explicites : « Service-area businesses […] should have one profile for the central office with a designated service area », et un bureau en coworking ne peut être listé que s'il « maintains clear signage, receives customers […] and is staffed during business hours ». Une seconde fiche sur une adresse non staffée est le scénario de suspension le plus fréquent en SEO local.

Le facteur Whitespark n° 14 est formulé précisément : « sustained influx over time (rather than bursts) » — un flux soutenu, par opposition aux rafales. La rafale est identifiée comme le contre-modèle, et déclenche les filtres anti-spam.

Objectif réaliste pour un service premium

2 à 4 avis par mois, chaque mois, sans interruption. C'est très supérieur, en effet, à 30 avis en deux mois puis plus rien. Notez aussi le facteur n° 9 : avis avec texte — un 5 étoiles sans commentaire pèse beaucoup moins. Votre service génère spontanément des textes longs : encouragez le récit, pas la note.

Politique mise à jour les 16-17 avril 2026 — beaucoup de conseils en circulation sont périmés. Désormais interdits : demander un avis sur place, les bornes et tablettes, les quotas de personnel. Et le review gating : même « Si vous avez aimé, laissez un avis » est considéré comme du filtrage sélectif.

Formulation conforme — les mots qui neutralisent le reproche de sélectivité : « Si vous souhaitez partager votre ressenti sur cette expérience — quel qu'il soit […] Votre retour, positif comme critique, m'aide à faire évoluer l'accompagnement. »

« The concept of toxic links is made up by SEO tools so that you pay them regularly. » — John Mueller, Google

Il a également qualifié le désaveu de liens toxiques de « billable waste of time ».

• Il n'existe aucune métrique Google de « toxicité ». Les « Toxicity Score » et « Spam Score » sont des inventions commerciales.
• Depuis Penguin 4.0 (2016), Google dévalue les liens spam au lieu de pénaliser le site cible.

Un seul cas légitime de désaveu

Une action manuelle pour liens artificiels dans Search Console. Si cet écran est vide, ne touchez jamais au fichier de désaveu. Un cas documenté montre un site ayant dû retirer un fichier de 15 000+ domaines pour retrouver ses positions.

Ce qui marche réellement en Suisse romande : la prescription croisée. Sages-femmes et doulas (post-grossesse), psychologues et coachs de transition (rupture, burn-out), naturopathes (ménopause), salons et boutiques haut de gamme. Proposez un échange de valeur réel, pas un échange de liens. Presse locale avec un angle société — jamais « je fais des photos ».

Ordre de grandeur réaliste : 15 à 25 liens locaux de qualité sur 12 mois. Peu en absolu, amplement suffisant pour une niche où la concurrence directe est quasi inexistante.

Le levier le plus sous-estimé : l'anxiété dominante au moment de cliquer n'est pas « mes données sont-elles en sécurité » mais « que va-t-il se passer maintenant ? ». Annoncez la suite :

Je lis chaque message personnellement et je réponds sous 48 heures. Pas de rappel téléphonique, pas de relance. Juste une réponse.

À éviter absolument : compteurs d'urgence, badges « SSL sécurisé », chiffres de vanité. Ils fonctionnent en e-commerce et se retournent sur un service intime, où ils signalent l'industrialisation.

NN/g documente sept problèmes, dont : charge mémoire (l'indice disparaît à la saisie), vérification impossible avant envoi, correction d'erreur difficile, et un constat d'eye-tracking — « les yeux des utilisateurs sont attirés par les champs vides » : un champ avec placeholder paraît déjà rempli et est sauté.

Placement : le label au-dessus permet la transition œil label→champ en ~50 ms, soit 10× plus rapide que le label aligné à gauche.

Votre formulaire — audité en ligne

Points corrects : autocomplete="email", type="email", taille 17 px (au-dessus du seuil iOS), bouton 145 × 60 px (au-delà des 44 px AAA), et un <label for> présent. Le défaut : ce label est position:absolute; left:-9999px — masqué hors écran. Visuellement, c'est donc un placeholder seul, l'anti-pattern documenté. Il satisfait le lecteur d'écran (WCAG 3.3.2) mais pas l'utilisateur voyant.

Contre-intuitif : sous la nLPD suisse, le traitement de données par un privé ne requiert en principe ni consentement ni motif justificatif, dès lors que les principes de proportionnalité et de finalité sont respectés. C'est l'inverse de la logique RGPD.

Une case à cocher n'est donc pas légalement obligatoire pour un simple formulaire de contact. En ajouter une non requise est une friction pure.

Mais votre cas est différent — attention

Un champ libre où une femme écrit « je sors d'un burn-out » ou « post-partum difficile » fait entrer le traitement dans le champ des données sensibles (LPD art. 5 let. c : santé, sphère intime). Le consentement exprès devient alors requis (art. 6 al. 7). Ce qui est toujours obligatoire : le devoir d'information (art. 19) — identité du responsable, finalité, destinataires. Sanction : amende jusqu'à CHF 250 000, à charge de la personne physique responsable, pas de l'entreprise.

Formulez au positif : « Vos informations restent entre nous » plutôt que « Pas de spam, promis » — l'amorçage plante le mot « spam » dans l'esprit du lecteur.

Synthèse documentaire, pas un avis juridique. Le point « données sensibles » mérite d'être tranché par un juriste suisse.

Étude Advanced Web Ranking (juillet 2026, 265 citations, 112 passages codés — échantillon petit, à traiter comme un signal). Ses résultats contredisent le discours GEO dominant :

Deux mythes tombent : la position du passage dans la page n'a pas de pouvoir prédictif (« répondre dans les 100 premiers mots » n'est pas confirmé), et le format définition n'aide pas — il est même légèrement plus fréquent chez les non-cités.

Ce qui compte : la fraîcheur, le nommage explicite des entités, et l'unicité (chiffres durs, affirmations nouvelles).

Le vrai levier : l'auto-suffisance sémantique

Un passage auto-porteur reste vrai et compréhensible extrait de son contexte. Concrètement : pas de pronom anaphorique en début de section (« Il », « Cela », « Ces »), l'entité et la ville répétées dans chaque section, une date visible, un chiffre dur par section de service.

Les AI Overviews se déclenchent sur ~48-50 % des recherches, et 83 % de ces recherches se terminent sans clic. Mais le taux varie énormément selon l'intention :

Transactionnelle

5 %

Commerciale

8 %

Locale

15 %

Informationnelle

36 %

Mixte + ville

97 %

Lecture stratégique

Zone protégée — « accompagnement Genève », « séance portrait Lausanne », « prix » : 5-15 % de déclenchement, Local Pack présent dans 93 % des cas. Votre trafic commercial est structurellement peu menacé. Zone exposée — « comment reprendre confiance après un burn-out » : 36 %, CTR effondré. Ne construisez pas votre acquisition sur ce trafic. Ces contenus gardent une valeur d'autorité et de citation, mais leur volume de clics baissera.

Trois familles fonctionnelles, et bloquer la mauvaise supprime le site des réponses génératives :

Un mythe répandu à corriger

Beaucoup de blogs affirment que bloquer Google-Extended vous retire des AI Overviews. C'est faux : la doc Google est explicite — « Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal ». Les AI Overviews passent par Googlebot.

⚠️ Le piège Cloudflare, daté

Depuis le 15 septembre 2026, Cloudflare bloque par défaut certaines catégories de bots IA sur les nouveaux sites et le plan gratuit. Le danger réel : les crawlers mixtes (Googlebot, Applebot, BingBot) font à la fois Search et Training — bloquer « Training » peut donc bloquer Googlebot.

Votre site — vérifié via l'API Cloudflare

kaina-experience.chn'est pas une zone Cloudflare : le site tourne sur .workers.dev et .pages.dev. Les réglages « AI bot policies », qui s'appliquent par zone, ne vous concernent donc pas aujourd'hui. Test réel des crawlers : OAI-SearchBot → 200, PerplexityBot → 200, Googlebot → 200. Aucun blocage actif. Cette vérification deviendra nécessaire le jour où vous rattacherez le domaine.

Vous êtes en « May be YMYL », pas en « Clear YMYL » — à condition de ne jamais basculer vers le conseil médical (« comment soigner un burn-out », protocole, dosage, diagnostic).

Contrainte suisse qui redouble la contrainte Google

Les titres de « psychologue » et « psychothérapeute » sont protégés par la LPsy. Usage illicite = amende jusqu'à CHF 10 000. S'y ajoute la LCD art. 3 al. 1 let. c, qui sanctionne l'usage de « titres ou dénominations professionnelles inexacts ». Vocabulaire à proscrire : psychologue, psychothérapeute, thérapeute, thérapie, patiente, consultation, soin, traitement, guérison, diagnostic. Vocabulaire sûr : accompagnement, praticienne, journée, participante, cliente, espace, écoute, cheminement.

Bloc à afficher (page d'accueil, pages de prestation, pages de récit) :

Les journées Kaina ne constituent pas une psychothérapie, un traitement médical ni un suivi psychologique. Elles ne remplacent pas une consultation auprès d'un médecin, d'un psychologue ou d'un psychothérapeute reconnu.

Encart d'urgence auto-inséré sur tout contenu tagué burn-out, post-partum, dépression : le 143 (La Main Tendue, 24h/24), le 144 (urgences), et un lien vers les annuaires FSP et ASP. C'est ce qui, aux yeux d'un évaluateur, distingue un acteur responsable — les guidelines exigent « trustworthy, safe ».

Risque 1 — Balisage. Baliser vos propres témoignages en Review vous rend inéligible et vous expose à une action manuelle. Vous ne le faites pas : c'est la bonne décision.

La solution : requalifier les témoignages en récits d'expérience balisés en Article, avec author = la praticienne (qui a recueilli et publié), et la cliente en about sous forme de Person au prénom seul, sans @id ni sameAs. Aucune note, aucune étoile, nulle part — même en texte brut.

Risque 2 — nLPD : c'est le plus sérieux

Un témoignage sur un burn-out ou un post-partum est par définition une donnée sensible (LPD art. 5 let. c : santé, sphère intime). Publier = communiquer à des tiers, ce qui constitue une atteinte à la personnalité (art. 30 al. 2 let. c). Cette atteinte n'est licite que si justifiée par le consentement (art. 31 al. 1), lequel doit être exprès pour les données sensibles (art. 6 al. 7). Le consentement écrit n'est donc pas une bonne pratique — c'est la condition de licéité. « Le prénom seul, ça anonymise » est faux : « Sophie, 42 ans, Genève » + portrait reconnaissable = personne parfaitement identifiable. La photo annule toute prétention d'anonymisation. Le droit à l'image (art. 28 CC) s'y ajoute, et le consentement est révocable en tout temps.

Conséquence pour le CMS : la dépublication doit être exécutable en heures, pas en semaines — page, images, sitemap, liens internes, cache CDN, et demande de suppression via Search Console.

Votre site

Cinq pages de témoignages avec prénom, âge et portraits. Zéro balisage Review — risque Google écarté. Le point à traiter est le consentement écrit granulaire, à archiver pour chacune des cinq personnes.