Audit SEO complet - myluminette.com

Analyse de 11 dimensions (technique, contenu, structured data, sitemap, performance, visuel/mobile, IA/GEO, experience de recherche, e-commerce, clustering semantique, profil de liens) sur un site e-commerce Shopify multi-marches.

Date de l'audit : 24 juillet 2026 · Lunettes et lampes de photobiomodulation (luminotherapie), marque francaise/belge (groupe Lucimed), 24 variantes de marche UE/international, blog actif d'environ 130 articles. Aucun point de vente physique - le SEO local est a juste titre hors perimetre.

57 / 100 Score de sante SEO

Signal YMYL - a lire avant le reste du rapport

La Luminette est un dispositif de luminotherapie a visee bien-etre/medicale, avec des allegations physiologiques et de sante mentale (sommeil, depression saisonniere, energie, humeur). Google applique un niveau de vigilance elargi (E-E-A-T) a ce type de contenu. Les lacunes releves ici - statistiques d'efficacite non sourcees, absence de credentials d'auteur visibles, absence de mention de relecture medicale - sont signalees avec une importance accrue dans tout ce rapport et doivent etre traitees comme prioritaires pour le business, pas comme un detail cosmetique.

Scores par dimension

Moyenne ponderee sur 10 dimensions notees (Technique, Contenu, Schema, Sitemap et Performance ponderes plus fort en tant que fondations SEO ; Visuel, GEO, SXO, E-commerce et Clustering en soutien). Le Profil de liens est exclu de cette moyenne - la quota Ahrefs a ete epuisee en cours d'audit, voir la section dediee.

Technique

74/100

Contenu

58/100

Schema

52/100

Sitemap

66/100

Performance

55/100

Visuel / Mobile

64/100

IA / GEO

58/100

SXO

38/100

E-commerce

58/100

Clustering semantique

32/100

Profil de liens

~30-40*

Non fiable - confiance 0,25

≥70 - solide 50-69 - a ameliorer <50 - critique Non note / donnee insuffisante

Classement des dimensions par score

Technique

Sitemap

Visuel / Mobile

Contenu

E-commerce

IA / GEO

Performance

Schema

SXO

Clustering

Profil de liens*

n/d

*Profil de liens : placeholder ~30-40/100 base uniquement sur Common Crawl (confiance 0,25) apres epuisement du quota Ahrefs en cours d'audit - a ne pas traiter comme un score reel, voir la section dediee pour le detail.

Synthese executive

La tension centrale du site

myluminette.com repose sur une fondation technique et infrastructurelle inhabituellement solide pour un site e-commerce international a 24 locales (hreflang propre, canonicals corrects, traduction reellement localisee par marche, rendu cote serveur, robots.txt globalement coherent, architecture de sitemap valide) - mais cette fondation ne parvient pas a se traduire en visibilite de recherche, car elle repose sur une couche contenu/autorite fragile : un blog fragmente et auto-cannibalise, des donnees structurees Review/Rating manquantes malgre des plateformes d'avis actives, et - point le plus consequent pour une marque a connotation YMYL - une credibilite scientifique reelle (chercheurs universitaires nommes, etudes cliniques reelles) qui n'est visible, citable ni creditee nulle part sur le site de facon exploitable par Google ou par les moteurs IA.

Top 5 des constats critiques (toutes dimensions confondues)

Aucune donnee structuree Review/AggregateRating malgre trois plateformes d'avis actives (Okendo, Trustpilot, Loox) et plus de 1 700 avis visibles. C'est le constat le plus repete de tout l'audit - retrouve independamment dans Schema, E-commerce, GEO et SXO. Les etoiles d'avis sont un levier de confiance/conversion majeur pour un achat de bien-etre reflechi, et elles sont actuellement invisibles pour Google et les moteurs IA.Schema - Critique
Les fiches produit reconditionnees declarent itemCondition: NewCondition dans leur schema alors qu'elles sont commercialisees comme reconditionnees - risque reel de desapprobation ou de suspension de fiche sur Google Merchant Center pour incoherence d'etat produit.E-commerce - Critique
Zero presence de marque dans les SERP sur les requetes informationnelles et comparatives a plus forte intention du site ("luminotherapie depression saisonniere", "meilleure lampe luminotherapie") - les concurrents et domaines purement editoriaux possedent entierement ces requetes.SXO - Critique
Cannibalisation de contenu severe : le blog d'environ 130 articles est reparti sur 4 structures d'URL paralleles et se chevauchant, avec des thematiques comme le "coup de blues hivernal" (8 articles) et la "vitamine D" (6 articles) fragmentees au lieu d'etre consolidees, plus un ancien hub pilier qui renvoie des 404 tout en restant indexe.Clustering semantique - Elevee, niveau architecture
Les allegations sante/efficacite sur du contenu YMYL ne sont pas sourcees et manquent de credentials visibles : des etudes cliniques nommees avec des pourcentages precis ("68% d'amelioration du sommeil") n'ont aucune citation sortante vers PubMed/NCBI, et l'article medical phare du blog cite un auteur sans bio, credentials ni mention de relecture medicale visibles sur la page.Contenu - Elevee ; confirme independamment en GEO - Moyenne-Elevee

Top 5 des victoires rapides (toutes dimensions confondues)

Corriger la fuite du code marche/pays dans les balises <title> et meta description (ex. "...Site officiel\n\n BE") - un bug de template Liquid unique affectant toutes les pages du site ; un seul correctif se propage sur l'ensemble du site.Technique / E-commerce - Severite elevee, effort faible
Remplacer itemCondition de NewCondition par RefurbishedCondition sur le schema des produits reconditionnes - une correction de valeur unique par bloc Offer.E-commerce - Severite critique, effort faible
Ajouter le schema FAQPage au contenu FAQ deja existant sur la fiche Luminette 3 et sur l'article phare "la luminotherapie fonctionne-t-elle" - le contenu Q/R existe deja, il ne manque que le balisage.Contenu / Schema / GEO - Severite moyenne-elevee, effort faible
Corriger la casse invalide de @type: "Website" (doit etre "WebSite") par recherche/remplacement global, et ajouter l'URL du profil Trustpilot au tableau sameAs de l'Organization.Schema - Severite elevee, effort faible
Ajouter des exceptions Allow: dans robots.txt pour /policies/* afin que les robots IA puissent acceder aux pages que llms.txt leur promet explicitement - resout une contradiction directe dans les propres instructions du site pour les robots IA.GEO - Severite elevee, effort faible

Constats transversaux

Plusieurs constats apparaissent independamment dans plusieurs dimensions de l'audit, ce qui renforce la confiance qu'ils partagent une cause racine commune et justifie de les prioriser en consequence.

1. Le bug du code marche dans le titre est le meme bug, trouve deux fois

Technique (constat 1) et E-commerce (constat 2) ont identifie independamment le meme defaut de template Liquid : des codes marche a deux lettres bruts qui fuient dans le <title>/meta description avec des espaces casses, sur tous les types de page, toutes locales confondues. C'est un seul correctif a impact site-wide, pas deux problemes separes.

2. La contradiction d'indexation des collections est un conflit a trois

Technique (constat 2) et Sitemap (constat 1) signalent tous deux que /collections/* est simultanement disallow dans robots.txt, en noindex, et soumis dans le sitemap. GEO (constat 1) ajoute une torsion supplementaire : llms.txt demande explicitement aux agents IA de recuperer /collections/{handle} et /policies/* - des chemins que robots.txt bloque pour tous les robots, y compris les robots IA. Les propres signaux de controle de crawl du site se contredisent entre eux et avec ses propres instructions pour les agents IA.

3. Le schema d'avis/notation est le manque le plus repete de tout l'audit

Schema (constat 1, Critique), E-commerce (constat 3), GEO (constat 5) et SXO (constat 4 - "espace d'avis cede a Trustpilot") convergent tous independamment vers le meme probleme racine : plus de 1 700 avis reels sur trois plateformes actives (Okendo, Trustpilot, Loox) existent mais ne sont exposes nulle part en schema aggregateRating/Review. C'est a la fois le correctif a plus fort effet de levier et le moins couteux de tout l'audit.

4. La complexite multi-locale/hreflang revient dans Technique, Sitemap et Clustering

Technique confirme que le hreflang lui-meme est correct et reciproque. Sitemap signale une question non resolue de duplication /nl/ vs /nl-nl/. Clustering fait remonter independamment une duplication de variante de locale dans son analyse de cannibalisation (ex. doublons /en-ua de contenu anglais). Individuellement aucun n'est severe, mais ensemble ils decrivent une structure a 24 marches qui a besoin d'un proprietaire unique pour confirmer quelles paires de locales sont des marches intentionnels vs des artefacts legacy.

5. Les lacunes E-E-A-T/citation sur le contenu YMYL reviennent dans Contenu, GEO et SXO

Contenu (constat 1) signale des statistiques d'efficacite non liees. GEO (constat 3) signale independamment les credentials d'auteur superficiels du meme article phare. GEO (constat 6) signale l'absence de signaux d'entite YouTube/Wikipedia. SXO (constat 1) signale que la marque a une presence zero sur la requete exactement encadree medicalement ("luminotherapie depression saisonniere") ou cette credibilite compterait le plus. La marque possede les actifs sous-jacents (chercheurs universitaires nommes, donnees d'essais cliniques reelles) - le probleme est systematiquement de les faire ressortir et de les citer, pas d'en manquer.

6. La fragmentation de l'architecture de contenu est une seule cause racine qui porte trois casquettes

Le constat de cannibalisation en 4 silos de Clustering, l'observation SXO que le contenu francais siege sur des slugs d'URL anglais, et le constat Contenu que le blog montre des motifs de risque "ferme a contenu IA" (comparaisons templatisees, bylines sans credentials, articles saisonniers quasi-dupliques) decoulent tous du meme processus de production de contenu indiscipline sur plus de 130 articles et 24 locales, sans taxonomie ni proprietaire de consolidation.

7. Le bug de dimension d'image/CLS apparait a deux granularites

Performance (constat 3 : 291 images sans dimensions sur la fiche produit) et Technique (constat 3 : 26 sur la page d'accueil) sont le meme bug de template systemique, echantillonne sur des types de page differents - confirme qu'il s'agit d'un snippet Liquid d'image partage, pas d'un probleme propre a une page.

1. Fondations techniques

Technique, Sitemap et Schema forment la couche d'infrastructure du site : crawlabilite, indexabilite et donnees structurees. C'est la partie la plus solide de l'audit (Technique 74/100) mais aussi celle qui contient le plus grand nombre de correctifs a faible effort et fort effet de levier.

Technique (74/100)Sitemap (66/100)Schema (52/100)

Technique SEO

74/100

Une fondation technique rare pour un site a 24 locales : hreflang, canonicals et rendu serveur sont tous corrects - les problemes restants sont des bugs de template localises, pas des defauts d'architecture.

Sources verifiees en direct (curl) : accueil + locales par defaut FR/BE, /fr-fr, /de-de, /nl, /en-gb, /en-us, fiche produit luminette-3 sur 3 locales, 2 pages collection, 2 articles de blog, 1 page utilitaire interne, robots.txt, sitemap.xml + sous-sitemaps. Plateforme Shopify (theme derive de Dawn) sur Shopify Markets, devant Cloudflare.

Ce qui fonctionne

robots.txt valide et sain, bloque uniquement checkout/panier/admin/recherche/policies/collections/preview, sans blocage accidentel du site entier ; reference correctement Sitemap: https://myluminette.com/sitemap.xml.
Architecture de sitemap bien structuree : un index qui se ramifie en sous-sitemaps par marche (produits/pages/collections/blogs) pour 24 prefixes de marche/locale distincts, avec lastmod et extensions image.
Implementation hreflang extensive et structurellement correcte : 242 balises hreflang par page, reciprocite et auto-reference verifiees sur toutes les locales echantillonnees.
Balises canoniques correctes et conscientes de la locale partout, y compris la normalisation du slash final sur les fiches produit.
Contenu de locale reellement traduit, pas duplique - verifie sur un article de blog (FR par defaut vs EN-GB), corps de texte distinct et entierement traduit.
Aucune dependance au rendu JavaScript : accueil, fiches produit et blog sont entierement rendus cote serveur par Shopify.
Donnees structurees presentes et syntaxiquement propres (WebSite/Organization sur l'accueil, ProductGroup/BreadcrumbList sur les fiches produit).
Hygiene HTTPS/redirections propre : redirections a un seul saut, aucune chaine de redirection trouvee ; certificat TLS valide.
Headers de securite majoritairement solides (CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, HSTS presents).
Transport favorable a la performance : HTTP/2, compression Brotli, 103 Early Hints avec preconnect/preload pour CSS et polices.
Viewport mobile correctement configure sitewide ; les 404 renvoient de vrais codes 404 (pas de soft-404).
Fichier de decouverte pour robots IA /agents.md (lie depuis sitemap_agentic_discovery.xml) - en avance sur la plupart des concurrents sur ce terrain emergent.

Constats (8)

Le code marche/pays fuit brut dans les balises <title> et meta description, sitewide

Elevee

Chaque page echantillonnee - accueil, toutes les locales, fiches produit, pages collection, articles de blog, meme la page de test interne - a le code marche a deux lettres ajoute a la balise <title> avec des espaces/sauts de ligne casses, par exemple :

<title>
      Luminette(r) : Lunettes et lampes de luminotherapie | Site officiel

      BE
    </title>

Confirme sur plusieurs marches : /fr-fr -> "...| Site officiel\n\n FR", /de-de -> "...Offizielle Webseite\n\n DE", /en-gb -> "...Official website\n\n GB", /en-us -> "...Official website\n\n US". Meme motif sur la meta description de l'accueil. Les titres de page collection sont en plus corrompus par une entite – litterale et un saut de ligne parasite. C'est un bug de template (probablement une variable Liquid non echappee/non nettoyee) et non un choix de branding deliberer - affecte le snippet SERP affiche par Google pour essentiellement chaque URL du site, sur des milliers de combinaisons produit/blog/page/locale.

Recommandation : corriger le template Liquid titre/meta-description du theme pour supprimer ou formater proprement la concatenation du code marche, sans espace parasite. Un seul correctif se propage sur tout le site ; re-crawler un echantillon de pages par locale apres correction pour confirmer.

Les pages collection sont simultanement bloquees dans robots.txt, en noindex, et soumises dans le sitemap XML

Moyenne

robots.txt contient Disallow: */collections, ce qui bloque l'acces crawler a toutes les URL /collections/*. Independamment, les pages collection echantillonnees (/collections/accessories, /collections/refurbished-main-nav) portent aussi <meta name='robots' content='noindex'>. Pourtant les trois URL de collection sont listees dans sitemap_collections_1.xml, repliquees sur les 24 sous-sitemaps de locale, et soumises au crawl. Google ne peut pas voir la balise noindex car robots.txt l'empeche de recuperer la page - cela produit typiquement des avertissements "Indexee bien que bloquee par robots.txt" dans Search Console si des liens pointent vers ces URL, et gaspille le budget de crawl.

Recommandation : choisir un seul mecanisme d'application. Si ces pages ne doivent jamais apparaitre dans les resultats de recherche, les retirer du sitemap XML et s'appuyer sur le blocage robots.txt (ou la balise noindex seule, pas les deux plus une soumission sitemap). Si certaines collections doivent etre indexables (ce qui a souvent une vraie valeur SEO sur un site e-commerce), retirer le noindex et le blocage robots.txt pour cette collection et la garder dans le sitemap.

Images avec width/height vides marquees loading='lazy' sur l'accueil (risque CLS/LCP)

Moyenne

Les trois premieres images du selecteur de produit rendues dans le <body> de l'accueil (miniatures Luminette 3 / Luminette 2 / Drive, probablement proches ou au-dessus de la ligne de flottaison) sont livrees avec des attributs de dimension litteralement vides : width='' height='' et loading='lazy'. Sans hint de ratio d'aspect, l'espace ne peut pas etre reserve avant le chargement de l'image - un risque CLS direct, aggrave par le lazy-loading si l'une de ces images est en realite l'element LCP. Sur l'ensemble de l'accueil, 26 des 354 balises <img> n'ont pas de width/height du tout. Seuls 3 hints fetchpriority existent sur toute la page, aucun <link rel="preload"> ne cible l'image hero probable.

Recommandation : livrer un width/height explicite (ou aspect-ratio en CSS) sur chaque image de selecteur/hero. Identifier l'element LCP reel par template et le marquer loading="eager" fetchpriority="high", en reservant loading="lazy" aux images veritablement sous la ligne de flottaison.

Une page de test interne est publiquement en ligne et indexable

Faible

https://myluminette.com/pages/test-form renvoie un HTTP 200, n'a pas de balise noindex, n'est pas bloquee par robots.txt, et figure dans sitemap_pages_1.xml sur toutes les locales. Son titre "Formulaire de test - Luminette BE" suggere fortement une page QA interne oubliee, jamais destinee a etre publique.

Recommandation : depublier la page dans l'admin Shopify, ou ajouter noindex et la retirer du sitemap si elle doit rester en ligne pour un usage interne. Verifier l'absence d'autres pages /pages/* de test/brouillon similaires.

Politique HSTS de courte duree, sans includeSubDomains/preload

Faible

Strict-Transport-Security: max-age=7889238 (~91 jours) est present mais bien en-dessous du minimum recommande d'un an (31536000s) pour l'eligibilite a la liste de preload HSTS, et n'inclut ni includeSubDomains ni preload.

Recommandation : si les sous-domaines supportent aussi entierement HTTPS, relever max-age a 31536000+ et ajouter includeSubDomains; preload, puis soumettre le domaine a la liste de preload HSTS. Configuration au niveau plateforme (Cloudflare/Shopify), pas dans le theme.

Headers Referrer-Policy et Permissions-Policy manquants

Faible

CSP, X-Frame-Options, X-Content-Type-Options et HSTS sont presents, mais aucun header Referrer-Policy ni Permissions-Policy n'a ete retourne sur les URL echantillonnees.

Recommandation : ajouter Referrer-Policy: strict-origin-when-cross-origin et un Permissions-Policy de base restreignant les fonctionnalites navigateur non utilisees, via les parametres HTTP header de Shopify ou une Transform Rule Cloudflare.

Protocole IndexNow non implemente

Info

Aucune preuve d'integration IndexNow - pas de reference dans le code source, /indexnow.txt renvoie 404. Shopify ne supporte pas IndexNow nativement sans app tierce.

Recommandation : priorite faible car Google ne consomme pas IndexNow ; a considerer si Bing/Yandex comptent pour des marches specifiques (ru-ru, pl-pl).

Note : la marche ru-ru est en ligne et indexable

Info

La locale /ru-ru (marche russophone) est entierement en ligne, renvoie un 200, et figure dans le sitemap et le hreflang aux cotes des autres marches UE. Question business/juridique, pas un defaut technique.

Recommandation : faire confirmer par le client qu'il s'agit d'un marche intentionnel et actuellement desservable, compte tenu du contexte de sanctions UE.

Sitemap

66/100

Une architecture de sitemap mature et bien decoupee par type de contenu et par marche, plombee par la meme contradiction collections que la dimension Technique et par une question de duplication de locale non tranchee.

Ce qui fonctionne

robots.txt reference correctement Sitemap: https://myluminette.com/sitemap.xml, un index valide et joignable.
Index de sitemap valide, decoupe logiquement en sitemap_products, sitemap_pages, sitemap_collections, sitemap_blogs.
Couverture multi-marche extensive : 24 marches/locales (nl, nl-nl, fr-fr, en-gb, en-us, en-au, en-ca, en-eu, en-nz, en-ua, de-de, de-ch, fr-ch, fr-ca, it-it, es-es, pl-pl, cs-cz, da-dk, fi-fi, no-no, sv-se, ru-ru, uk-ua) plus le domaine racine.
Tres en-dessous de la limite de 50 000 URL/fichier, avec pagination automatique disponible.
Extension sitemap image utilisee sur les URL produit ; lastmod present sur la plupart des entrees ; aucune balise priority obsolete trouvee.

Constats (7)

Le sitemap inclut des URL bloquees par robots.txt (collections)

Elevee

sitemap_collections_1.xml (et variantes de locale) liste des URL live comme /collections/accessories, /collections/refurbished-main, /collections/refurbished-main-nav, alors que robots.txt les disallow explicitement. Contradiction directe qui peut declencher des avertissements "URL soumise bloquee par robots.txt" dans le rapport de couverture Search Console, supprimant le signal de sante global du sitemap.

Recommandation : retirer /collections du Disallow robots.txt si ces pages doivent etre indexees (probablement correct pour un site e-commerce - les pages categorie ont generalement une vraie valeur SEO), ou retirer sitemap_collections_*.xml de l'index soumis si elles sont intentionnellement exclues. Shopify genere ce sitemap nativement et non editable manuellement - la solution pratique est d'autoriser /collections dans le robots.txt.liquid du theme.

Aucune annotation hreflang dans les fichiers sitemap

Moyenne

Aucun des sous-sitemaps echantillonnes ne contient d'entrees <xhtml:link rel="alternate" hreflang="...">. Chaque sitemap de locale est une liste plate independante, sans reference croisee vers son equivalent dans les autres locales.

Recommandation : acceptable si le hreflang du <head> HTML est correct (confirme correct par la dimension Technique) - Google accepte l'une ou l'autre methode, pas necessairement les deux a la fois. Verification croisee effectuee, aucune action requise si le hreflang HTML reste fiable.

Chemins de locale quasi-dupliques qui se chevauchent : /nl/ vs /nl-nl/

Moyenne

L'index de sitemap liste deux jeux de sitemap neerlandais separes avec une structure d'URL quasi identique : https://myluminette.com/nl/products/luminette-3 et https://myluminette.com/nl-nl/products/luminette-3 - potentiellement deux marches distinctes (Belgique-NL vs Pays-Bas) ou un doublon legacy.

Recommandation : confirmer dans les parametres Shopify Markets si /nl/ et /nl-nl/ sont des marches intentionnellement distincts avec devise/contenu differents, ou si /nl/ est une locale legacy a consolider/rediriger vers /nl-nl/ pour eviter une dilution de contenu duplique.

Les valeurs lastmod semblent etre l'horodatage de la requete, pas une vraie date de modification

Faible

Dans sitemap_products_1.xml, des produits sans rapport (luminette-3, drive, garantie-4-ans, luminette-2, plusieurs accessoires) partagent tous la meme valeur lastmod a la seconde pres, ce qui suggere une generation dynamique au moment de la requete plutot qu'un reflet de l'historique reel des modifications.

Recommandation : comportement natif standard de Shopify, non corrigible via edition du sitemap. Ne pas s'appuyer sur lastmod comme signal de fraicheur dans le suivi Search Console.

L'entree de la page d'accueil n'a pas de lastmod

Faible

L'entree racine dans sitemap_products_1.xml n'a pas de balise <lastmod>, alors que presque toutes les autres entrees en ont une.

Recommandation : mineur/cosmetique, non actionnable manuellement puisque le sitemap est natif Shopify - a surveiller si le motif se repete sur les accueils de locale.

Entree sitemap_agentic_discovery.xml non standard

Info

L'index inclut https://myluminette.com/sitemap_agentic_discovery.xml, qui contient une seule URL : https://myluminette.com/agents.md. Fonctionnalite Shopify recente visant la decouverte par agents/robots IA.

Recommandation : aucune action requise - ajout inoffensif et tourne vers l'avenir. Confirmer que /agents.md renvoie bien un 200 si la decouvrabilite par agents IA compte pour la marque.

changefreq present mais fonctionnellement inerte

Info

Toutes les URL echantillonnees utilisent <changefreq>daily</changefreq> quelle que soit la cadence de mise a jour reelle ; Google ignore officiellement ce champ.

Recommandation : aucun correctif requis, pas la peine d'y consacrer d'effort d'ingenierie puisque Shopify controle ce champ nativement.

Schema & donnees structurees

52/100

Une base JSON-LD propre et complete sur le plan commercial (Product/Offer), plombee par un manque unique et massif - l'absence totale de schema d'avis - et une poignee de bugs de formatage repetes sur tout le site.

Pages echantillonnees (HTML brut via curl - Playwright indisponible pour ce passage, voir constat #1 sur le rendu client possible d'Okendo/Loox) : accueil, ProductGroup (Luminette 3, avec variantes), Product simple (Drive, Luminette 2), BlogPosting (2 articles). Format utilise sitewide : JSON-LD exclusivement, aucune Microdata/RDFa legacy detectee.

Ce qui fonctionne

JSON-LD exclusivement, rien a nettoyer cote Microdata/RDFa legacy.
Organization sur l'accueil complet : nom, logo, image, email, url, telephone, PostalAddress complet, sameAs (Facebook, Instagram, LinkedIn).
Product/Offer sur chaque fiche produit inclut le trio requis pour les rich results (price, priceCurrency, availability) plus des champs bonus (gtin13/14, mpn, itemCondition, sku, seller, priceValidUntil).
BreadcrumbList implemente de facon coherente sur les fiches produit et les articles de blog.
BlogPosting/Article a une bonne completude de proprietes (headline, image, author, datePublished/dateModified, articleBody, mainEntityOfPage).
Toutes les URL observees sont en https:// et @context est systematiquement https://schema.org, sans mesusage de types deprecies.

Constats (8)

Aucun Review/AggregateRating sur les produits malgre des apps d'avis actives - la plus grande opportunite manquee

Critique

Le JSON-LD produit (Luminette 3, Drive, Luminette 2) n'a aucune propriete review ou aggregateRating. Pourtant le HTML brut charge trois plateformes d'avis : Okendo (17 references), Trustpilot (23 references, y compris un profil https://www.trustpilot.com/review/myluminette.com lie dans le <head> mais absent du tableau sameAs de l'Organization), et Loox. Le copy de l'accueil revendique meme "300 000 utilisateurs" comme preuve sociale, mais rien de ce signal de confiance n'est lisible par une machine. Impossible de confirmer avec certitude si Okendo/Loox injectent du JSON-LD Review/AggregateRating cote client apres chargement (Playwright non disponible dans cet environnement) - a verifier via un fetch rendu.

Recommandation : confirmer si Okendo emet du schema ; sinon, activer la sortie schema native d'Okendo/Loox (bascule generalement disponible), ou ajouter manuellement aggregateRating + quelques entrees review, issues du volume/note reel (ne jamais fabriquer de chiffres). Ajouter aussi l'URL du profil Trustpilot business au tableau sameAs de l'Organization (gain rapide, sans risque dev).

@type: "Website" invalide utilise sitewide (violation de casse schema.org)

Elevee

Les types schema.org sont sensibles a la casse. La valeur correcte est WebSite (S majuscule), pas Website. Tel qu'ecrit, c'est silencieusement traite comme un type inconnu/personnalise - sur le schema racine de l'accueil et sur le ListItem "Home" de chaque BreadcrumbList (fiches produit, articles de blog). L'eligibilite sitelinks-searchbox de l'accueil et le type du noeud racine de chaque fil d'Ariane sont invalides.

Recommandation : recherche/remplacement global "@type": "Website" -> "@type": "WebSite" sur les templates de schema du theme (probablement un seul snippet Liquid partage, vu le bug identique sur chaque page echantillonnee).

Les dates d'article ne sont pas au format ISO 8601 - malformees sur chaque article de blog

Elevee

Exemple sur "do-light-therapy-glasses-work" : "dateModified": "2025-12-16 10:13:43 +0100", "datePublished": "2022-11-16 00:00:00 +0100". ISO 8601 exige un separateur T entre date et heure, pas un espace - c'est le format datetime par defaut de Rails/Ruby qui fuit directement dans le JSON-LD. Le parseur de donnees structurees de Google est tolerant sur certaines dates malformees, mais cela ne devrait pas etre suppose acquis - risque de voir les proprietes de date exclues de l'eligibilite aux rich results de fraicheur.

Recommandation : reformater toute sortie de date au format ISO 8601 strict, ex. 2025-12-16T10:13:43+01:00.

ProductGroup.variesBy est un tableau vide (Luminette 3)

Moyenne

variesBy est une propriete requise pour ProductGroup et doit lister l'axe de variante reel (couleur, dans ce cas). Un tableau vide signifie que Google ne peut pas determiner ce qui differencie les variantes, pouvant causer le rejet du ProductGroup ou traiter les variantes comme des produits dupliques non lies dans Merchant Center / rich results Produit.

Recommandation : definir variesBy: ["https://schema.org/color"].

URL d'image cassee/non-absolue dans le noeud Article imbrique du BreadcrumbList

Moyenne

Sur les deux articles de blog echantillonnes, a l'interieur du noeud Article imbrique dans BreadcrumbList : "url": "https:articles/img-1718977024200.png" - une URL malformee (segments de chemin/domaine CDN manquants), ni URL absolue valide ni chemin relatif fonctionnel. Le bloc Article de premier niveau sur la meme page a la bonne URL CDN complete - c'est specifiquement un bug dans les donnees Article dupliquees a l'interieur du fil d'Ariane.

Recommandation : corriger la construction de l'URL dans image.url du noeud Article imbrique, ou - mieux - arreter de dupliquer les proprietes Article completes a l'interieur de BreadcrumbList. Selon la specification de Google, chaque ListItem.item n'a besoin que de @id et name.

Entites HTML non decodees qui fuient dans les champs texte JSON-LD

Faible

Les chaines description/articleBody de produits et articles contiennent l'entite litterale ' au lieu d'une vraie apostrophe, ex. "...Profitez d'une exposition lumineuse efficace...". Syntaxiquement valide en JSON, mais tout systeme consommant cette description (snippets Google, assistants vocaux, AI Overviews) affichera les caracteres litteraux.

Recommandation : decoder les entites HTML avant d'injecter le texte dans le JSON-LD - le template Liquid applique probablement un filtre d'echappement HTML destine au rendu HTML, pas au JSON-LD.

FAQPage non implemente - aucun impact SERP, ajout optionnel pour l'IA/GEO

Info

Aucun balisage FAQPage trouve sur l'accueil, les fiches produit ou le blog. Google a retire les rich results FAQ pour tous les sites (7 mai 2026), donc aucune feature SERP a gagner. Etant donne qu'il s'agit d'un produit a connotation sante avec des questions d'acheteur frequentes (securite medicale, duree d'usage quotidien, compatibilite lunettes de vue, effets secondaires), un ajout de FAQPage reste pertinent pour la visibilite aupres des moteurs IA/LLM.

Recommandation : ajout a faible cout pour le GEO si du contenu FAQ genuin existe deja (c'est le cas, voir Contenu constat #4). Si une page ajoute plus tard de la Q/R soumise par les utilisateurs (pas editoriale), utiliser QAPage, pas FAQPage.

Casse non standard productId sur ProductGroup (probablement ignoree par les parseurs)

Faible

Exemple : "productId": "0745844429340". La propriete reelle de schema.org est productID (ID en majuscules). Telle qu'ecrite, c'est une propriete personnalisee non reconnue, ignoree silencieusement par les parseurs - sans perte fonctionnelle puisque le meme GTIN est deja correctement present via gtin13, mais c'est une donnee redondante/morte.

Recommandation : renommer en productID, ou supprimer puisque gtin13/mpn identifient deja correctement le produit.

2. Contenu et autorite

Contenu, Clustering semantique, IA/GEO et SXO forment la couche la plus faible de l'audit et celle ou se concentre le plus de valeur a debloquer : la marque possede une credibilite scientifique reelle et un volume de contenu consequent, mais aucun des deux n'est structure de facon a se convertir en visibilite de recherche.

Contenu (58/100)Clustering (32/100)IA / GEO (58/100)SXO (38/100)

Qualite du contenu

58/100

La marque a une veritable histoire scientifique differenciante - mais elle vit sur des pages secondaires, non liee a des sources verifiables, pendant que l'accueil reste une grille de prix et qu'une bonne part du blog montre des motifs de ferme a contenu generique.

Perimetre : accueil, 3 fiches produit (Luminette 3, Luminette 2, Drive), pages hub clinical-study/new-research/light-therapy, la FAQ, et 3 articles de blog echantillonnes sur ~140 publies. Passage volontairement raccourci par l'orchestrateur pour eviter un timeout - la duplication de variante de locale a ete identifiee structurellement mais pas comparee ligne a ligne, a prevoir en suivi.

Ce qui fonctionne

Veritable histoire d'origine scientifique avec des experts nommes et credibles : /pages/clinical-study et /pages/new-research citent Robert Poirrier (neurologue, directeur du laboratoire du sommeil du CHU Liege), Yvon Renotte (physicien PhD, ex-directeur du laboratoire d'optique de l'ULiege), Vincent Moreau (PhD, physique optique/aerospatiale) et Daniel Neu (medecine du sommeil, CHU Brugmann) comme co-inventeurs/conseillers scientifiques, avec "4 annees de recherche a l'Universite de Liege" (2006).
Resumes d'etudes precis, pas vagues : annee, taille d'echantillon, methodologie, population (ex. "84 infirmieres de bloc operatoire", "21 personnes travaillant de nuit", "114 femmes en postpartum sur six semaines") - bien plus credible que des allegations generiques "cliniquement prouve".
Langage de precaution medicale present dans la FAQ produit (cataractes/chirurgie oculaire, conformite securite oculaire IEC 62471, allegation de securite "300 000 unites vendues sans aucun incident signale").
Signaux de fraicheur presents en schema (datePublished/dateModified) sur les articles echantillonnes.
Les fiches produit franchissent les seuils de profondeur topicale (Luminette 3 ~1 086 mots, Drive ~1 042, Luminette 2 ~855) avec instructions d'usage et bloc FAQ.

Constats (4)

Les allegations sante/efficacite ne sont liees a aucune source verifiable - lacune de confiance et de citabilite IA

Elevee

La page clinical-study et la page new-research citent des etudes nommees et referencent meme "Publications fournies par le National Center for Biotechnology Information" et des chaines d'auteurs comme "Glickman G & al. Biol Psychiatry 2006", mais aucun lien sortant vers NCBI, PubMed ou un DOI n'existe nulle part sur les deux pages (verifie par extraction de href contre ncbi|pubmed|doi - 0 correspondance). Des chiffres d'efficacite precis ("68% des utilisateurs ont ameliore leur qualite de sommeil", "58% ... augmentation de leur niveau d'energie") sont enonces comme des faits bruts sans citation qu'un lecteur ou un LLM puisse suivre pour verifier.

Pourquoi c'est important : pour un dispositif sante a connotation YMYL, des statistiques d'efficacite non liees sont un signal de confiance classique defavorable selon les QRG. Cela plafonne aussi la citabilite IA - les LLM privilegient les allegations qu'ils peuvent tracer vers une source primaire.

Recommandation : lier chaque reference d'etude a sa source PubMed/revue (ou une page de resultats publics/PDF). Ajouter une liste de citations numerotees en bas des deux pages - correctif unique a plus fort effet de levier a la fois pour l'E-E-A-T et la citabilite IA.

L'accueil est fonctionnellement une grille produit/prix avec presque aucun copy de marque ou educatif unique

Moyenne-Elevee

Le texte de corps extrait de l'accueil est domine par une liste de prix produit repetee (SKU, prix en euros x3 variantes, "unites") avec seulement environ 2 courts paragraphes de copy descriptif reel ("Essayez Luminette", "60 jours satisfait ou rembourse"). Le narratif de marque exploitable (ce qu'est Luminette, pourquoi c'est different, la science) n'est pas du tout sur l'accueil - il vit sur des pages secondaires (/pages/clinical-study, /products/luminette-3).

Pourquoi c'est important : l'accueil est typiquement l'URL a plus forte autorite d'un domaine ; un accueil catalogue-uniquement sous-utilise cette autorite pour le signal E-E-A-T et ne donne aux utilisateurs comme aux robots IA aucun chemin rapide vers l'histoire de confiance (recherche universitaire, plus de 300 000 utilisateurs, norme de securite).

Recommandation : ajouter une section accueil (200-400 mots) enoncant l'origine de la recherche universitaire, les scientifiques nommes et la certification de securite directement au-dessus/pres de la ligne de flottaison - sans forcer l'utilisateur a cliquer vers /pages/clinical-study pour la trouver.

La page pilier thematique est mince et duplicative du blog ; le corpus du blog montre des motifs de risque "ferme a contenu IA"

Moyenne

/pages/light-therapy - clairement pensee comme le hub/pilier thematique du cluster "luminotherapie" - ne fait qu'environ 215 mots, presque entierement une liste a puces de liens vers des articles de blog, avec un seul court paragraphe d'intro. Separement, le sitemap du blog liste plus de 140 articles, dont beaucoup suivent un motif templatise et generique de type listicle avec un lien limite au produit ("8 exercices oculaires faciles", "explorer les bienfaits de l'aromatherapie", "meilleurs livres sur le sommeil", "ecouter de la musique en dormant") aux cotes de variantes saisonnieres quasi-dupliquees (winter-fatigue, winter-fatigue-symptoms, how-to-beat-winter-blues, how-to-beat-the-winter-blues, light-therapy-summer-blues, seasonal-depression-in-summer, travel-light-therapy / jet-lag-and-its-impact-in-australia / effects-of-jet-lag). Les articles de comparaison echantillonnes (ayo-vs-luminette, retimer-vs-luminette, pegasi-2-vs-luminette) suivent un template identique de fonctionnalites notees, un marqueur de structure repetitive signale par les QRG de septembre 2025.

Pourquoi c'est important : un large corps de contenu generique, templatise et sans credentials, dilue autour d'un petit noyau de contenu scientifique genuinement autoritaire, augmente le risque que les signaux "helpful content" de Google (desormais integres au ranking central) evaluent a la baisse la qualite globale du contenu du domaine, tirant vers le bas les pages solides avec.

Recommandation : (a) reecrire /pages/light-therapy en une vraie page pilier de 800+ mots avec une synthese unique, pas juste une liste de liens ; (b) ajouter une byline d'auteur visible avec credentials courts aux articles de blog (meme "Content Manager, relu par [conseiller scientifique]" renforce l'Expertise) ; (c) consolider/rediriger les articles saisonniers quasi-dupliques.

Schema FAQPage et Review/AggregateRating manquants malgre du contenu sur page qui supporte les deux

Faible-Moyenne

La fiche Luminette 3 affiche un bloc FAQ visible (7 questions/reponses sur securite, cataractes, timing, compatibilite lunettes) et un compteur "1700+ avis", mais le scan JSON-LD trouve Product present tandis que FAQPage et AggregateRating/Review sont absents.

Recommandation : ajouter le schema FAQPage au bloc FAQ existant et le schema AggregateRating lie au volume/source d'avis reel - contenu deja present, il ne manque que le balisage.

Clustering semantique (architecture hub-and-spoke)

32/100

Score le plus bas de tout l'audit : le volume de contenu est la, mais il est reparti sur 4 structures d'URL paralleles qui se font concurrence entre elles - la definition meme de l'auto-cannibalisation.

Methodologie : audit de site en production, pas une construction de cluster sur terrain vierge. Base sur le crawl de l'index du blog (11 pages paginees, ~130 articles publies), l'echantillonnage de motifs de liens internes dans le corps des articles, et des requetes site: utilisees comme proxy de l'auto-concurrence reelle en SERP.

Ce qui fonctionne

Volume et largeur thematique elevee : ~130 articles couvrent presque tous les sujets adjacents qu'un acheteur de luminotherapie pourrait rechercher (SAD/coup de blues hivernal, rythme circadien, decalage horaire, hygiene de sommeil, vitamine D, lumiere bleue, comparaisons d'appareils).
Les articles individuels renvoient generalement vers les fiches produit pertinentes (light-therapy-glasses-guide, pegasi-2-vs-luminette, do-light-therapy-glasses-work lient tous vers /products/luminette-3 et/ou /products/drive).
Le contenu de comparaison concurrentielle existe et est bien cible (Pegasi 2, Re-Timer, Ayo).
Un veritable actif E-E-A-T existe : /pages/new-research agrege 15 etudes cliniques publiees (Universite de Liege, essais randomises sur sommeil/humeur/cognition, populations speciales) - signal d'autorite fort mais actuellement sous-exploite par le blog.

Constats (6)

Auto-cannibalisation severe : les memes sujets centraux couverts sur 4 structures de contenu paralleles

Elevee

Les requetes site:myluminette.com font remonter les propres URL du site en concurrence entre elles dans le meme jeu de resultats. Requete "winter blues" : 5 URL distinctes vivantes (/blogs/light-therapy-applications/winter-blues-light-therapy, /blogs/article/vitamin-d-for-seasonal-depression, /blogs/article/how-to-beat-winter-blues, /blogs/article/how-to-beat-the-winter-blues, /blogs/article/sun-lamps-for-seasonal-depression). Requete "vitamin d light therapy" : 5+ URL distinctes sur trois structures de chemin differentes, plus une variante de locale /en-ua/....

Au moins 4 silos d'URL/contenu distincts existent en parallele, tous live (verifie via curl, 200 OK) : (1) /blogs/article/* - le blog plat principal (~130 articles, celui lie dans la nav), (2) /blogs/light-therapy/* - un sous-hub "science", (3) /blogs/light-therapy-applications/* - un sous-hub "cas d'usage", (4) /light-therapy/* - un hub legacy partiellement vivant, partiellement en 404. A l'interieur du seul silo #1, le chevauchement de mots-cles par nombre d'articles : Vitamine D 6 articles, Coup de blues hivernal / humeur saisonniere 8 articles, Luminotherapie bleue 4 articles, Lampes spectre complet 3 articles a titres quasi identiques, Decalage horaire 5 articles.

Recommandation : choisir une structure d'URL canonique unique (recommande : garder /blogs/article/*, celle presente dans la nav principale) et consolider/rediriger en 301 les trois autres silos vers celle-ci. Au sein de chaque cluster thematique en chevauchement ci-dessus, fusionner en 1 pilier + maximum 2-3 spokes differencies ; canonicaliser ou rediriger le reste. Correctif unique a plus fort impact disponible sur ce site.

Un hub pilier legacy orphelin renvoie des 404 tout en restant indexe

Elevee

Verification curl -I sur des URL remontees en recherche : /light-therapy/light-therapy-all-about-light-therapy = 404, /light-therapy/how-does-light-therapy-work = 404, /light-therapy/3-contraindications = 404, tandis que /light-therapy/light-therapy (page soeur dans le meme dossier) = 200. Ces URL en 404 sont exactement le type de pages pilier fondamentales dont une architecture hub-and-spoke a besoin ("qu'est-ce que la luminotherapie", "comment ca marche", "contre-indications") - construites, indexees, puis cassees, probablement pendant une migration d'URL/plateforme incomplete.

Recommandation : auditer tous les chemins /light-therapy/* dans le rapport de couverture Search Console, rediriger en 301 chaque 404 vers son equivalent live le plus proche (probablement dans /blogs/light-therapy/* ou /pages/light-therapy), et decider d'un seul foyer permanent pour ce contenu.

Le module "Articles lies" n'est pas contextuellement pertinent

Moyenne-Elevee

Trois articles echantillonnes sans rapport entre eux (un guide d'achat, une comparaison concurrentielle, une FAQ d'efficacite produit) affichent tous le meme bloc "Articles lies" de trois articles identiques, suggerant fortement un module statique/epingle manuellement plutot que pilote par le sujet. Separement, l'article does-vitamin-d-give-you-energy ne contient aucun lien vers les 5 autres articles adjacents sur la vitamine D, alors que c'est l'opportunite de maillage interne la plus evidente disponible.

Recommandation : remplacer par un composant de contenu lie pilote par tag/categorie, pour que les spokes se maillent reellement au sein de leur vrai cluster thematique.

Dilution thematique par du contenu bien-etre hors-marque

Moyenne

Une part significative des ~130 articles n'a aucun rapport direct avec la luminotherapie ou la gamme de produits : "Meilleurs livres sur le sommeil", "Entrainement de 7 minutes", "Astuce sante du jour", "Les bienfaits de dormir sans oreiller", "Explorer les bienfaits de l'aromatherapie pour la relaxation", "8 exercices oculaires faciles pour ameliorer la vision", "21 facons de rendre votre espace de travail plus productif". Ces contenus concurrencent le budget de crawl/signal d'autorite thematique du corpus central sur la luminotherapie sans chemin plausible vers du trafic qualifie produit.

Recommandation : deprioriser la production de nouveau contenu dans cette veine ; pour les articles existants, soit les integrer dans un spoke "hygiene de sommeil" plus large avec un vrai lien vers la luminotherapie, soit noindexer/elaguer ceux qui ne peuvent pas etre rattaches au sujet central.

Ecarts de contenu face a l'intention d'achat reelle

Moyenne

"La luminotherapie fonctionne-t-elle pour la depression" : aucune page dediee. L'article le plus proche, do-light-therapy-glasses-work, s'articule autour de l'efficacite/securite generale et ne lie que vers l'accueil et la fiche produit - il ne reference pas les donnees de l'essai clinique MDD (clinicaltrials.gov NCT03685942, essai LUMIDEP) qui existe pourtant en externe et est referencee sur /pages/new-research. "Lunettes de luminotherapie vs lampe SAD" : aucune page de comparaison de format n'existe - le site a trois comparaisons de marque (Pegasi 2, Re-Timer, Ayo) mais rien sur cette question de haut de tunnel plus courante. "Combien de temps utiliser les lunettes de luminotherapie" : fragmente sur au moins 3 articles faibles et concurrents au lieu d'un guide d'usage unique et faisant autorite.

Recommandation : construire/consolider une page faisant autorite par ecart identifie ci-dessus, en liant directement vers la fiche produit pertinente et vers /pages/new-research pour l'appui clinique.

Aucune taxonomie de categorie/tag sur le blog

Faible-Moyenne

/blogs/article est une liste plate unique, paginee chronologiquement (11 pages), sans filtre de categorie ou de tag visible. Les utilisateurs et les robots ne peuvent pas parcourir un cluster thematique comme un ensemble ; la decouverte depend entierement des liens internes, qui sont actuellement non contextuels (voir constat #3).

Recommandation : introduire des pages d'archive categorie/tag pour le blog, qui doublent comme pages hub legeres, chacune renvoyant vers ses articles spokes et vers la fiche produit pertinente.

Visibilite IA (GEO)

58/100

Aucun blocage de robot IA et un llms.txt en avance sur la categorie - mais une contradiction robots.txt/llms.txt, un manque de FAQPage et un signal E-E-A-T superficiel plafonnent la note sur le contenu YMYL.

Ponderation par sous-dimension : Citabilite 25% (score 65) · Lisibilite structurelle 20% (60) · Contenu multi-modal 15% (40) · Autorite et signaux de marque 20% (45) · Accessibilite technique 20% (75). Estimations par plateforme (heuristiques, pas de tracking de citation en direct) : Perplexity ~62, Google AI Overviews ~55, ChatGPT/OAI-SearchBot ~50, Bing Copilot ~55.

Ce qui fonctionne

Aucun blocage de robot IA : GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot sont tous implicitement autorises.
/llms.txt present et inhabituellement sophistique (endpoints UCP, instructions agent-commerce), en avance sur les concurrents de la categorie.
Contenu entierement rendu cote serveur - tous les robots IA recoivent le contenu complet des le premier fetch, sans execution JS requise.
Une page de citabilite genuinement excellente existe (do-light-therapy-glasses-work) : titres en questions, FAQ de cloture, schema Article, byline nommee, 2 citations PubMed.
Le schema Organization inclut des liens sameAs vers Facebook, Instagram, LinkedIn.

Constats (6)

robots.txt bloque /collections et /policies pour tous les robots, y compris IA - en contradiction avec les propres instructions de llms.txt

Elevee

robots.txt contient Disallow: */collections et Disallow: */policies sans exception, applique a User-agent: *. Pourtant /llms.txt demande explicitement aux agents de faire GET /collections/{handle} pour parcourir le catalogue, et lie directement /policies/privacy-policy, /policies/terms-of-service, /policies/refund-policy comme "Store Policies". Les deux classes d'URL renvoient un HTTP 200 en fetch direct - un robot IA conforme suivant robots.txt refusera donc de recuperer des pages que le propre fichier d'instructions du site lui demande de recuperer.

Recommandation : soit ajouter des exceptions Allow: explicites pour /policies/* et /collections/* au niveau categorie pour les robots IA (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended), soit mettre a jour llms.txt/agents.md pour ne plus referencer des chemins bloques. Les pages de politique portent en particulier des signaux de confiance/autorite que les moteurs IA utilisent pour le scoring de confiance e-commerce.

Aucun schema FAQPage malgre du contenu FAQ existant

Moyenne-Elevee

L'article phare /blogs/article/do-light-therapy-glasses-work a une section H2 "FAQ" visible avec trois paires question/reponse directe ("Les lunettes de luminotherapie fonctionnent-elles vraiment ? Oui, les lunettes de luminotherapie sont concues pour imiter la lumiere naturelle du soleil..."). Le JSON-LD de la page ne declare que Article et BreadcrumbList - aucun schema FAQPage n'enveloppe ces paires Q/R, donc le texte de reponse directe n'est pas balise machine comme du Q/R extractible pour les AI Overviews de Google ou des reponses de type SGE.

Recommandation : ajouter le schema FAQPage (paires Question/acceptedAnswer) sur cet article et le repliquer sur les autres articles de blog qui repondent a des questions. Effort faible, impact eleve pour l'eligibilite AI Overview et assistant vocal.

Signal E-E-A-T auteur superficiel sur du contenu sante YMYL

Moyenne-Elevee

Le titre de l'article s'encadre lui-meme comme guidance medicale ("Avis Medical et Efficacite Scientifique"), et le champ JSON-LD author nomme "Eric Delloye" - mais aucune bio d'auteur visible sur page, credentials, ou mention de relecture medicale n'existe nulle part dans le HTML rendu. Le nom n'apparait que dans l'objet JSON-LD author et dans un push analytics dataLayer, tous deux invisibles pour un lecteur typique. Sur les ~2 000 mots de l'article formulant de nombreuses allegations physiologiques (mecanismes serotonine/melatonine, "0,5 a 2 heures de sommeil gagnees", comparaisons de lux), seules 2 citations sortantes vers PubMed/PMC existent, toutes deux ancrees a une seule allegation ("aucune preuve de dommage oculaire").

Recommandation : ajouter un bloc bio d'auteur/relecteur visible (credentials, ex. "relu par [ophtalmologue/specialiste du sommeil]", avec schema Person incluant jobTitle/worksFor) et citer les sources pour les allegations quantitatives specifiques. Correctif a plus fort effet de levier pour la ponderation de confiance IA sur du contenu sante a connotation YMYL - les LLM privilegient les sources avec une attribution d'expertise claire pour les allegations medicales.

L'optimisation GEO est incoherente sur le blog - une page phare, des pages hub de categorie faibles

Moyenne

Comparaison entre do-light-therapy-glasses-work (excellente) et /blogs/light-therapy/light-therapy-principles-and-health-benefits (une page pilier centrale de la categorie de blog "light-therapy"). Cette derniere a des H2 generiques non formules en question ("Principes et bienfaits"), aucun bloc FAQ, aucune citation PubMed, et seulement ~193 mots de corps d'article - bien en-dessous de toute longueur utile d'extraction de passage. 4 hubs de categorie de blog existent (light-therapy, chronobiology, light-therapy-lamps, light-therapy-applications) avec des dizaines d'articles ; un seul article echantillonne comme entierement optimise GEO dans cet audit.

Recommandation : auditer tous les articles des categories light-therapy et light-therapy-applications et reecrire les pages pilier centrales selon le meme motif que l'article phare : titres formules en question, passages de reponse directe d'environ 150 mots, FAQ de cloture avec schema FAQPage, sources citees.

Aucun schema aggregateRating/Review malgre une integration Trustpilot active

Faible-Moyenne

Le HTML de l'accueil inclut un dns-prefetch vers widget.trustpilot.com, indiquant un affichage d'avis en direct, et le copy de fiche produit revendique "Plus de 300 000 utilisateurs nous font confiance depuis 2006". Pourtant le JSON-LD ProductGroup n'a ni aggregateRating ni review, et le schema Organization de l'accueil non plus.

Recommandation : ajouter aggregateRating (issu du score agrege reel de Trustpilot) au schema Product et Organization. Le volume/note d'avis est un signal de confiance courant que les LLM ponderent lors de comparaisons de recommandation produit sur des requetes a intention commerciale.

Aucune chaine YouTube possedee et aucune entite Wikipedia - les deux plus fortes correlations de citation IA sont absentes

Moyenne

Le sameAs de l'Organization sur l'accueil ne liste que Facebook, Instagram et LinkedIn - aucun YouTube, aucun Wikipedia. Une recherche Wikipedia en direct pour "Luminette light therapy glasses"/"Lucimed" ne renvoie aucun article correspondant. Une recherche YouTube fait remonter du contenu tiers ("Luminette 3 Review: Testing the Brightest Light Therapy Glasses!"), confirmant un interet organique de createurs, mais aucune chaine possedee par la marque n'est referencee sur le site. Selon les donnees de correlation de marque du GEO, les mentions YouTube (~0,737) et la presence d'entite Wikipedia sont les deux plus forts predicteurs de citation IA - toutes deux absentes ici.

Recommandation : (a) creer ou lier formellement une chaine YouTube possedee (demos produit, explicatifs "comment fonctionne la luminotherapie") et l'ajouter au sameAs ; (b) viser une entree Wikipedia pour Lucimed/Luminette si les criteres de notoriete peuvent etre remplis (couverture presse, un article de blog reference deja un "prix d'innovation en sante mentale", ce qui pourrait appuyer la notoriete) ; (c) continuer a engager les createurs YouTube tiers existants plutot que de partir de zero.

Experience de recherche (SXO)

38/100

Le score d'alignement SERP le plus critique de l'audit : sur les 4 mots-cles francais analyses, la marque est totalement absente des deux requetes a plus forte intention d'achat/information.

Perimetre : 4 mots-cles francais analyses face aux attentes de type de page SERP (lunettes de luminotherapie, luminotherapie depression saisonniere, meilleure lampe luminotherapie, luminette avis). Passage a perimetre volontairement restreint - un audit SXO complet couvrirait 15-20+ mots-cles sur tout le tunnel.

Ce qui fonctionne

La requete de marque "luminette avis" est bien couverte par une page dediee /pages/customer-reviews.
L'accueil a une forte ADN de landing page pour l'intention de marque/commerciale-de-marque : proposition de valeur unique, garantie 60 jours, preuve sociale "300 000 utilisateurs satisfaits depuis 2006", section "Comment ca marche".
Un veritable article francophone long-format existe (/fr-fr/blogs/article/do-light-therapy-glasses-work, ~4 000 mots, vraie traduction, pas un stub).

Constats (4)

Zero presence de marque sur les mots-cles informationnels et comparatifs a haute intention

Critique

Pour "luminotherapie depression saisonniere", les 5 premiers resultats sont a 100% des domaines d'autorite medicale/sante (sante.fr, vidal.fr, allodocteurs.fr, mesoigner.fr, inicea.fr) - type de page Article de blog/editorial pur. Aucune page myluminette.com n'apparait ; une verification site:myluminette.com pour cette expression exacte ne renvoie rien. Pour "meilleure lampe luminotherapie", le SERP est a 100% de type Page de comparaison (conservation-nature.fr, edp-nutrition.fr, lampeluminotherapie.com "comparatif", maluminotherapie.com "guide d'achat") recommandant des lampes concurrentes (Verilux HappyLight, Beurer TL 30) - la propre "Lampe de luminotherapie 2-en-1" de Luminette n'apparait nulle part, malgre le fait qu'elle soit vendue sur l'accueil.

Recommandation : construire deux types de page dedies qui n'existent pas actuellement sur le site francais : (a) un article encadre medicalement et soutenu E-E-A-T sur "luminotherapie et depression saisonniere" avec un relecteur professionnel de sante credite (Luminette possede deja Prof. Robert Poirrier, specialiste du sommeil, comme actif a citer - actuellement inutilise en contenu francais) ; (b) une veritable page comparaison/guide d'achat ("Meilleure lampe de luminotherapie en 2026") incluant la propre lampe 2-en-1 de Luminette aux cotes des criteres de categorie (lux, surface, minuterie), correspondant a la taxonomie Page de comparaison (tableau, avantages/inconvenients, verdict).

Aucune page categorie commerciale dediee pour le mot-cle produit central

Elevee

/collections/lunettes-de-luminotherapie renvoie une 404. Le sitemap collections ne liste que /collections/accessories, /collections/refurbished-main, /collections/refurbished-main-nav - aucune page collection "lunettes" ou "lampe" principale n'existe. Pour "lunettes de luminotherapie", le SERP melange des pages Produit/Categorie (Medi-Lum, Lux-Therapie, Biron) avec du contenu Guide/Comparaison (lampeluminotherapie.com x3, maluminotherapie.com), une demande hybride commerciale-informationnelle. Myluminette ne repond actuellement qu'avec son accueil generique (qui vend accessoires, vitamine D, coussinets nasaux - pas une landing page "lunettes de luminotherapie" focalisee).

Recommandation : creer une vraie page categorie/landing /collections/lunettes-de-luminotherapie (ou slug similaire aligne sur le mot-cle) focalisee uniquement sur la gamme de lunettes, avec des blocs de contenu guide d'achat (criteres, tableau comparatif vs lampes) integres pour correspondre au motif hybride vu dans le SERP.

Contenu francais enterre sous des slugs d'URL anglais

Moyenne

L'article /fr-fr/ qui correspond le mieux a "lunettes de luminotherapie" siege sur le slug anglais /fr-fr/blogs/article/do-light-therapy-glasses-work. Titre et meta sont bien localises en francais, mais l'URL elle-meme ne porte aucun signal de mot-cle francais, et la structure /blogs/article/ (aucune categorie thematique dans l'URL) est generique. Toutes les entrees du sitemap blog utilisent des slugs anglais, quelle que soit la locale.

Recommandation : localiser les slugs d'URL par marche (Shopify Markets le supporte), ex. /fr-fr/blogs/luminotherapie/lunettes-luminotherapie-avis-medical, ameliorant le signal mot-cle/URL sans toucher au contenu.

Espace d'avis cede a Trustpilot

Moyenne

Pour "luminette avis", 3 des 6 resultats SERP visibles sont des pages Trustpilot (fr et fr-be, plusieurs pages en profondeur) contre une seule page possedee (/pages/customer-reviews). Cela suggere que la page d'avis on-site manque soit de schema de note agregee visible par Google, soit d'un contenu plus frais/mis a jour que le profil Trustpilot.

Recommandation : ajouter le schema AggregateRating/Review a la page d'avis on-site et s'assurer qu'elle affiche des avis frais et dates (pas un bloc statique) pour concurrencer l'espace de snippet d'avis actuellement possede par Trustpilot.

Tableau de correspondance type de page vs SERP

Mot-cle	Type dominant en SERP	Actif myluminette	Severite du decalage
lunettes de luminotherapie	Hybride (Produit/Categorie + Guide)	Accueil generique (hybride Landing/Produit, non focalise)	Elevee
luminotherapie depression saisonniere	Article de blog (autorite medicale)	Aucune presence en SERP	Critique
meilleure lampe luminotherapie	Page de comparaison	Aucune presence en SERP	Critique
luminette avis	Page d'avis/UGC	/pages/customer-reviews (present, partage le SERP avec Trustpilot)	Alignee (faible)

Limites : seuls 4 mots-cles analyses (passage a perimetre restreint) ; resultats SERP issus de WebSearch, pas d'un screenshot SERP rank-tracke en direct - l'ordre exact du top 10 et les features SERP en direct (AI Overview, PAA, ads) n'ont pas ete captures. Aucune confirmation obtenue sur le positionnement reel de myluminette pour le mot-cle 1 (present mais position non confirmee) vs absence totale sur les mots-cles 2-3 - necessite Ahrefs/GSC pour confirmation precise.

3. E-commerce SEO

Une base de schema Produit solide et un fort taux de couverture alt-text, plombes par un bug critique de conformite Merchant Center sur les produits reconditionnes et par le meme bug de titre que la dimension Technique.

E-commerce SEO

58/100

Le schema commercial est globalement bon, mais un seul mismatch d'etat produit (neuf vs reconditionne) expose la marque a un risque reel de suspension de fiche Google Shopping.

Source : analyse on-page statique (curl, sans rendu JS). Pages revues : accueil, /products/luminette-3, /products/luminette-2, /products/refurbished-luminette-3, /products/drive, /fr-fr/products/luminette-3, /collections/all. Plateforme Shopify, Shopify Markets avec 20+ sous-chemins de locale.

Ce qui fonctionne

ProductGroup + Offer schema implemente sur toutes les fiches produit verifiees, incluant gtin13, mpn, brand, sku par variante, Offer.price, priceCurrency, availability, itemCondition, seller, priceValidUntil - bonne base pour Merchant Center / rich results.
BreadcrumbList present sur les fiches produit (bien que peu profond - voir constats).
Couverture alt-text solide : sur 125 balises <img> liees au produit echantillonnees sur la fiche Luminette 3, seulement 2 sans attribut alt ; le texte existant est descriptif, pas des noms de fichier generiques.
Message de confiance/garantie/livraison fortement present dans le copy on-page : "60 jours" (garantie) 13x, "satisfait ou rembourse" 7x, "livraison gratuite" 12x sur la fiche Luminette 3.
Integrations de plateforme d'avis detectees (Loox, Yotpo, Trustpilot, Okendo), indiquant des avis collectes et probablement affiches cote client.
Implementation hreflang extensive : 242 balises hreflang par page, auto-reference correcte verifiee sur la fiche reconditionnee.

Constats (6)

Le schema des produits reconditionnes declare a tort itemCondition: NewCondition

Critique

Sur https://myluminette.com/products/refurbished-luminette-3, les 3 blocs Offer du JSON-LD ProductGroup affichent "itemCondition": "https://schema.org/NewCondition". Le produit est explicitement commercialise et titre comme reconditionne/"reconditionne", mais les donnees structurees disent a Google (et a tout flux Merchant Center puisant dans ce schema) qu'il est neuf.

Impact : Google Shopping / Merchant Center peut desapprouver ou suspendre des fiches pour incoherence d'etat entre le contenu de page et le schema/flux. C'est aussi un echec de signal de confiance pour les rich results, puisqu'un acheteur cherchant un article d'occasion/reconditionne voit un badge "neuf".

Recommandation : changer itemCondition en https://schema.org/RefurbishedCondition (valeur supportee par Google) pour tous les SKU reconditionnes. Auditer le metafield Shopify ou la logique de theme generant ce schema - probablement codee en dur plutot que templatisee par type de produit. A faire aussi pour Refurbished Luminette 2 et Refurbished Drive (non verifies individuellement dans ce passage, mais partageant tres probablement le meme template ProductGroup).

Les balises <title> contiennent un code pays parasite ajoute apres le nom de marque

Elevee

Meme cause racine que le constat #1 de la dimension Technique : chaque page verifiee sans chemin de locale renvoie un titre se terminant par un code brut a deux lettres avec un espacement etrange, ex. Lunettes Luminotherapie - Luminette 3 | Livraison gratuite | Luminette\n\n BE. Le chemin de locale /fr-fr/ renvoie le meme titre avec FR au lieu de BE. Ce motif se repete sur l'accueil, /collections/all, et les 4 fiches produit testees - ressemble a une valeur de selecteur de pays Shopify Markets qui fuit dans le template Liquid du titre plutot que d'etre scopee a un element UI.

Impact : Google reecrit generalement les titres qu'il juge malformes, mais cela gaspille le budget pixel du titre SERP, semble non professionnel si affiche tel quel, et suggere que le marche/pays est resolu par geo-IP au moment du crawl - ce qui signifie que Googlebot pourrait indexer un titre different, dependant de la geo, de celui vu par les utilisateurs francais ou belges.

Recommandation : trouver et retirer la sortie {{ country_code }}/selecteur de marche du template <title>. Verifier que les URL canoniques non prefixees par locale servent un titre stable et independant de la geo plutot qu'un titre qui bascule entre BE/FR/etc selon l'origine de la requete.

Aucun schema aggregateRating/Review malgre des apps d'avis actives (Loox, Yotpo, Trustpilot, Okendo)

Moyenne

Zero occurrence d'aggregateRating ou de "review" dans le JSON-LD ProductGroup statique sur les 4 fiches produit, alors que 4 scripts de plateforme d'avis distincts (Loox, Yotpo, Trustpilot, Okendo) sont charges sur chaque fiche - un nombre de chevauchement inhabituellement eleve, suggerant que les avis existent en volume mais ne sont pas exposes aux robots dans le schema Produit principal. Constat statique-HTML uniquement ; si l'une de ces apps injecte le schema cote client via JavaScript, le pass de rendu de Googlebot pourrait tout de meme le capter - a verifier avec un check DOM rendu avant de traiter comme totalement confirme.

Recommandation : consolider vers la sortie schema d'une seule plateforme d'avis (avoir 4 apps concurrentes est aussi un passif de vitesse de page/maintenance) et s'assurer que aggregateRating est emis cote serveur dans le meme bloc JSON-LD que les donnees Product/ProductGroup, pas uniquement cote client.

Formatage incoherent des valeurs de prix a l'interieur du meme schema ProductGroup

Moyenne

Sur la fiche Luminette 3, les valeurs "price" apparaissent en formats mixtes dans les donnees de page environnantes : certaines en "179", "183", "199", "229" (sans decimales) et d'autres en "229.00" / "183.00" (avec decimales) - certaines pourraient appartenir a des widgets de vente croisee/bundle plutot qu'a l'offre produit principale, mais l'incoherence elle-meme indique une logique de rendu de prix non standardisee.

Recommandation : standardiser toute sortie de prix en schema au format string a deux decimales ("229.00") et confirmer que le flux Merchant Center live est source depuis les donnees produit/variante natives de Shopify plutot que toute valeur scrapee/templatisee.

Le schema BreadcrumbList est peu profond (Home > Produit uniquement, sans niveau categorie)

Faible

Le BreadcrumbList sur /products/luminette-3 n'a que 2 entrees ListItem : "Home" et "Luminette 3". Aucun noeud categorie/collection intermediaire n'existe, alors que /collections/all et vraisemblablement d'autres collections existent.

Recommandation : ajouter la collection pertinente comme noeud de fil d'Ariane intermediaire, correspondant a l'architecture d'information reelle du site (ex. Home > Lunettes > Luminette 3).

La fiche reconditionnee reutilise le template titre/meta du produit neuf quasi mot pour mot

Faible

Le <title> de /products/refurbished-luminette-3 est identique a celui du Luminette 3 neuf, differencie uniquement par le code pays parasite en fin de chaine. La meta description differe (mentionne "Revitalisez vos journees..."), mais le titre ne donne aux utilisateurs/moteurs aucun signal indiquant qu'il s'agit de la variante reconditionnee/moins chere.

Recommandation : ajouter "Reconditionne" au titre de la fiche reconditionnee, distinct du titre du produit neuf, pour clarifier l'intention aux acheteurs et reduire la cannibalisation de requete interne.

Non evalue dans ce passage

Dimensions/format des fichiers image (WebP vs PNG) uniquement echantillonnes, pas mesures systematiquement contre la recommandation Merchant Center de ≥800px. Aucun appel Merchant API DataForSEO effectue (benchmarking de competitivite prix marketplace hors perimetre). Verification d'unicite de copy fabricant non effectuee face aux fiches concurrentes. Refurbished Luminette 2 et Refurbished Drive non recuperees individuellement - le bug NewCondition n'est confirme que sur Refurbished Luminette 3 mais tres probablement templatise a l'identique sur tous les SKU reconditionnes.

4. Visuel et performance

Une base au-dessus de la ligne de flottaison solide et un TTFB excellent, mais un DOM demesurement gonfle et une image hero non preloadee plafonnent le score Performance, tandis qu'un risque de rendu par animation menace potentiellement la visibilite d'un contenu de conversion cle.

Visuel / Mobile (64/100)Performance (55/100)

Rendu visuel / mobile

64/100

Le cluster de confiance au-dessus de la ligne de flottaison est solide sur desktop et mobile - mais 30 a 40% de la hauteur totale de page capture vide lors du scroll complet, un signal a verifier manuellement de toute urgence.

Pages revues : accueil, fiche produit Luminette 3. Viewports : Desktop 1920x1080, Mobile 375x812 (iPhone).

Accueil myluminette.com sur desktop — Accueil desktop : H1, preuve sociale "+300 000 clients", double CTA et badge Trustpilot visibles sans scroller.

Accueil myluminette.com sur mobile — Accueil mobile : meme cluster de confiance condense dans le premier ecran, barre sticky de garantie au-dessus du header.

Fiche produit Luminette 3 sur desktop — Fiche produit desktop : galerie, liste de benefices, prix par lot et badge de livraison tous visibles pres du haut de page.

Fiche produit Luminette 3 sur mobile — Fiche produit mobile : prix (229€) et bouton "Commander" visibles des le premier ecran, sans avoir a chercher.

Ce qui fonctionne

Fort cluster de confiance au-dessus de la ligne de flottaison sur les deux pages : H1 "Retrouvez votre energie en moins de 10 jours", sous-claim "+300 000 clients", double CTA, badge Trustpilot (4,6/5, 1700+ avis) - tout visible sans scroller.
Barre sticky de confiance/urgence au-dessus du header ("60 jours satisfait ou rembourse" / "Payer en 3 fois avec Klarna") reduisant le risque percu avant meme d'atteindre le hero.
Bandeau de benefices sous le hero (Experts depuis 2006 / 20 minutes par jour suffisent / Livraison gratuite / 60 jours pour changer d'avis) renforce le message garantie + facilite d'usage juste a la ligne de flottaison.
Prix et CTA visibles rapidement sur mobile fiche produit, sans avoir a chercher le bouton d'achat.
Fiche produit desktop bien structuree : galerie avec miniatures, liste de benefices, tarification par lot (1/2/3 unites avec remise visible), estimation de livraison, miniatures de temoignages video sous la ligne de flottaison.
Navigation mobile en hamburger standard, header compact. Aucun scroll horizontal, layout casse ou element se chevauchant observe dans les captures.

Constats (3)

De larges sections de la page se rendent vides lors de la capture au scroll - a verifier pour la fiabilite des animations declenchees au scroll

Elevee

Dans les captures pleine page (home_desktop_full, home_mobile_full, product_mobile_full), environ 30 a 40% de la hauteur totale de page est un espace blanc/degrade vide sans contenu visible. Le motif se repete sur l'accueil et la fiche produit, sur desktop et mobile : la section "Vous pensez encore a une light box ?" (probablement un bloc comparaison Luminette vs lampe traditionnelle) se rend avec uniquement le titre visible et environ 2000px d'espace vide en dessous - aucun tableau/graphique/image comparatif n'apparait, ni sur desktop ni sur mobile. La section "La Luminette vous permettra de :" sur la fiche produit mobile montre le meme motif. La hauteur totale capturee est en consequence tres elevee : accueil mobile = 15 518px (~19 hauteurs d'ecran mobile), fiche produit mobile = 12 278px (~15 hauteurs d'ecran), dont une bonne part est vide.

Ce motif est coherent avec un contenu conditionne par des animations de reveal/fade-in declenchees au scroll (GSAP ScrollTrigger, AOS, Intersection Observer) qui ne se seraient pas declenchees pendant la capture automatisee pleine page. Cela compte pour deux raisons : (1) si des utilisateurs reels sur des appareils bas de gamme ou avec JS lent vivent le meme retard/echec de reveal, ils rencontrent de longs vides en scrollant devant du contenu decisif (tableau comparatif, liste de benefices) - un vrai risque UX/conversion pour un achat reflechi ; (2) le renderer de Google est aussi une instance Chromium headless et peut etre sujet a des problemes de timing similaires - si le contenu depend de la position de scroll/du timing JS pour devenir visible/present dans le DOM, il existe un risque qu'il ne soit pas indexe ou credite de facon fiable a la page.

Recommandation : scroller manuellement et lentement sur le site en direct, desktop et mobile, pour confirmer si c'est un vrai retard de rendu ou un artefact pur de capture headless. Si le contenu est conditionne par une animation au scroll, passer a des animations qui revelent du contenu deja present dans le DOM (opacite/transform uniquement, jamais display:none ou contenu injecte au scroll) pour qu'il reste toujours crawlable et independant du declenchement de l'animation. Envisager de reduire la dependance aux reveals au scroll pour le contenu de conversion principal (tableau comparatif, liste de benefices) vu le risque d'echec observe ici.

Longueur de page excessive relativement a la densite de contenu

Moyenne

La capture pleine page mobile de l'accueil fait 15 518px de haut ; la fiche produit mobile fait 12 278px - toutes deux inhabituellement longues par rapport au nombre de sections de contenu distinctes identifiees (hero, "Illuminez votre vie", stats, "Caracteristiques techniques", bloc comparaison, temoignages, footer). Meme en tenant compte du probleme de rendu vide du constat #1, l'espacement entre sections semble genereux (grand padding vertical, transitions en degrade entre blocs).

Recommandation : une fois le constat #1 resolu et la vraie hauteur de contenu confirmee, auditer l'espacement vertical entre sections et le resserrer ou pertinent - un chemin plus court vers la FAQ/les ingredients/les avis ameliore generalement l'engagement mobile pour des produits d'achat reflechi.

La section de comparaison a la lampe traditionnelle manque de contenu visible en capture

Moyenne (conditionnee au constat #1)

La section "Vous pensez encore a une light box ?" - probablement pensee comme un bloc cle de differenciation/traitement des objections (lunettes Luminette vs lampe de luminotherapie traditionnelle) - ne montre aucun contenu comparatif visible dans les captures desktop ni mobile. C'est exactement le type de contenu qui devrait convaincre un acheteur sceptique et procedant a des recherches approfondies (achat de bien-etre reflechi selon le brief), donc si ce contenu echoue reellement a se rendre pour un segment d'utilisateurs reels, c'est un coup direct porte a la conversion des visiteurs a plus forte intention lisant jusque-la.

Recommandation : verifier manuellement le rendu en direct ; si confirme fonctionnel pour de vrais utilisateurs, aucune action au-dela du correctif de fiabilite d'animation du constat #1. Si casse, prioriser un correctif - cette section fait un travail de persuasion en bas de tunnel.

Evaluation au-dessus de la ligne de flottaison et reactivite mobile

Accueil et fiche produit passent tous deux le seuil "au-dessus de la ligne de flottaison" : H1/nom de produit, CTA principal et un signal de confiance en etoiles (Trustpilot) sont tous visibles sans scroller, sur desktop comme sur mobile - bien adapte a un achat reflechi ou la confiance doit s'etablir immediatement. Aucune rupture de layout, chevauchement ou scroll horizontal observe dans l'un ou l'autre jeu de captures mobiles. La question ouverte principale reste le probleme de reveal de contenu au scroll ci-dessus, qui necessite une verification manuelle en direct (pas seulement un outil de capture statique) pour confirmer l'impact reel utilisateur.

Performance

55/100

Le TTFB est excellent et la discipline de chargement des ressources (fonts preloadees, CSS non critique differe, JS deferre) est bonne - mais un DOM 3,6x trop large et une image hero non preloadee neutralisent une bonne partie de cet avantage.

Reserve de methode

L'API PageSpeed Insights a renvoye une erreur de rate-limit 429 sur les deux strategies (mobile et desktop) - aucune donnee CrUX/Lighthouse disponible pour cette session. Cet audit se base donc sur une inspection manuelle via curl du HTML brut/headers de reponse pour l'accueil et une fiche produit, plus une analyse statique des resource hints, de la taille du DOM et du balisage image. Tous les constats ci-dessous sont des estimations issues de preuves statiques/reponse serveur, pas de metriques lab (Lighthouse) ou field (CrUX). A re-executer PSI/CrUX une fois le rate-limit leve pour confirmer.

Metrique (proxy)	Accueil /	Fiche produit /products/luminette-3
TTFB	0,112 s	0,190 s
Temps de reponse total	0,303 s	0,611 s
Taille HTML brut	866 Ko	941 Ko
Nombre d'elements DOM (approx.)	~5 437	~5 603
Balises <img> avec width/height vides	20	291

Serveur : Cloudflare devant Shopify (gcp-europe-west4), cf-cache-status: DYNAMIC. Les deux pages sont rendues cote serveur (Shopify Online Store 2.0), pas une SPA cote client.

Ce qui fonctionne

TTFB excellent sur les deux pages (112ms accueil, 190ms produit), bien en-dessous du seuil recommande de 200ms - le combo edge Cloudflare + cache plateforme Shopify fait bien son travail, une base solide pour le LCP.
Fonts correctement preloadees : les 5 fichiers de poids Gilroy utilisent <link rel='preload' as='font' crossorigin>.
JS principal correctement deferre (bootstrap.bundle.min.js en defer), non bloquant pour le rendu.
CSS non critique differe via l'astuce media='print', un motif legitime pour eviter le CSS bloquant le rendu.
preconnect vers cdn.shopify.com present, rechauffant la connexion CDN.
Script tiers charge en async, non bloquant. Images generalement en srcset responsive multi-largeurs.

Constats (4)

DOM extremement gonfle - environ 5 400 a 5 600 elements par page

Elevee

Nombre de balises accueil ≈5 437 elements, fiche produit ≈5 603 elements - 3,6x au-dessus du seuil de 1 500 elements couramment cite au-dela duquel la taille du DOM commence a couter reellement en cout de recalcul style/layout et en overhead de gestionnaires d'evenements. Le payload HTML brut fait 866-941 Ko avant meme de compter les octets JS/CSS/image.

Impact : augmente directement le risque INP (un DOM large signifie un recalcul de style et un layout couteux a chaque interaction - ex. ouverture du panier, selecteur de variante, filtres) et ralentit le parsing/rendu initial, repoussant indirectement le LCP.

Recommandation : auditer les sections du theme Shopify pour du markup redondant/duplique (ex. versions desktop+mobile du meme hero rendues deux fois, jeux d'icones repetes, slides de carrousel caches tous rendus dans le DOM a la fois). Charger paresseusement les sections hors ecran, utiliser content-visibility: auto en CSS pour les sections sous la ligne de flottaison, et elaguer les blocs SVG/markup dupliques. Cible : <2 000 elements comme premier jalon.

L'image hero (candidate LCP) n'est pas preloadee et est decouverte tres tard dans le document

Elevee

L'image hero de l'accueil (main-pic-L_...webp, classe main-page-hero-bg-desktop) apparait a la ligne ~14 764 d'un document HTML de 18 107 lignes - environ 82% du chemin dans le source. Aucun <link rel='preload' as='image' fetchpriority='high'> n'existe pour elle (seuls les 5 fichiers de police sont preloades). Le bloc preload/preconnect ne couvre que les fonts et la connexion CDN, pas l'image LCP elle-meme.

Impact : le scanner de preload du navigateur ne peut pas decouvrir cette image avant d'avoir parse tres loin dans le HTML, retardant le declenchement de la requete de la ressource LCP - une cause classique de "resource load delay" dans la decomposition LCP. Etant donne que la page est par ailleurs rapide (bon TTFB), c'est probablement le levier unique le plus important pour ameliorer le LCP.

Recommandation : ajouter un <link rel="preload" as="image" href="[hero-desktop-webp]" fetchpriority="high" media="(min-width: 768px)"> explicite (et un equivalent mobile) dans le <head>, et ajouter fetchpriority="high" directement sur la balise <img> du hero. Deplacer le markup du hero plus tot dans le DOM si possible, ou au minimum s'assurer qu'il n'est pas differe derriere des sections sans rapport.

Dimensions d'image manquantes de facon generalisee - risque CLS eleve

Elevee

20 balises <img> sur l'accueil et 291 balises <img> sur la fiche produit ont des attributs width='' et height='' litteralement vides (pas simplement omis - explicitement vides), incluant miniatures produit, images d'accessoires nose-rest, et icones.

Impact : sans width/height (et sans repli aspect-ratio CSS confirme), le navigateur ne peut pas reserver l'espace de layout avant le chargement de l'image, causant un decalage de mise en page a chaque apparition d'image - particulierement dommageable sur la fiche produit ou 291 instances ont ete trouvees (probablement swatches de variante / miniatures de galerie / grilles d'accessoires).

Recommandation : renseigner de vrais attributs width/height (ou aspect-ratio en CSS) sur chaque <img> templatisee, en particulier dans la galerie produit et les grilles d'accessoires/upsell des fiches produit. Correctif a faible effort et fort impact car systemique (probablement le meme snippet Liquid reutilise partout).

Payload accueil lourd : 8 videos integrees + 5 poids de police preloades en concurrence pour la bande passante

Moyenne

8 sources cdn.shopify.com/videos/...mp4 distinctes integrees dans des balises <video> (autoplay/loop/muted, utilisees pour des animations style "comment ca marche"), plus 5 fichiers de police woff2 separes tous marques rel='preload' simultanement.

Impact : les videos utilisent preload='none', ce qui attenue le cout initial, mais 5 preloads de police haute-priorite concurrents plus l'image hero se disputent la bande passante/connexions precoces sur le chemin critique, en particulier sur mobile/conditions 3G-equivalentes utilisees dans le scoring CrUX mobile.

Recommandation : confirmer si les 5 poids Gilroy sont reellement utilises au-dessus de la ligne de flottaison - si seulement 2-3 poids se rendent avant interaction, differer le chargement des autres. Verifier que font-display: swap est bien defini pour eviter un delai de texte invisible.

Recommandations prioritaires (ordre d'impact)

Preloader l'image hero LCP avec fetchpriority="high" - cible directement le "resource load delay" du LCP, probablement le changement au meilleur ROI vu que le TTFB est deja rapide.
Corriger le width/height vide sur toutes les images templatisees, en commencant par la galerie de la fiche produit (291 instances) - cible directement le CLS.
Reduire la taille du DOM sur les templates accueil et fiche produit - cible l'INP et des gains secondaires de LCP/temps de parsing.
Re-executer PSI/CrUX (ou Lighthouse) une fois disponible pour obtenir les vraies valeurs LCP, INP, CLS field/lab et valider ces estimations.

5. Profil de liens (backlinks)

Cette dimension n'a pas pu etre mesuree correctement lors de ce passage - a traiter comme une lacune de donnees a combler en priorite, pas comme un score fiable.

Profil de liens

Non note

A lire avant toute conclusion sur cette dimension

Le quota de l'API Ahrefs Enterprise a ete epuise sur chaque appel pertinent pour les backlinks (domain-rating, metrics) - un echec au niveau du compte, pas du domaine. Aucun repli Moz ou Bing Webmaster n'etait configure. La seule source atteinte a ete Common Crawl (Tier 0), qui confirme que le domaine est indexe et possede une certaine equite de lien entrante mesurable (rang PageRank ~1 494 157) mais a renvoye zero domaine referent echantillonne - un resultat que le specialiste qualifie explicitement de "directionnellement preoccupant mais non concluant", car Common Crawl est connu pour sous-echantillonner les sites e-commerce DTC de taille moyenne. Ne pas traiter le chiffre ~30-40 comme un score reel. Re-executer cette dimension avec Ahrefs des que le quota pay-as-you-go se reinitialise (2026-08-01) avant de tirer une quelconque conclusion sur l'autorite de liens.

Cible testee sous forme nue (myluminette.com) et www (www.myluminette.com), 24 juillet 2026.

Sources tentees

Source	Statut	Note
Verification tier d'acces	Execute	Confirme Tier 0 - aucune cle Moz, aucune cle Bing configuree
Common Crawl (graphe web)	Succes	Niveau domaine uniquement, confiance 0,50, release cc-main-2026-jan-feb-mar
API Ahrefs (domain-rating, metrics)	Echec	"API units limit reached... API units left: 0" sur les deux endpoints, formes bare et www
API Moz (metrics/domains/anchors/pages)	Non tente	Aucune cle MOZ_API_KEY configuree
Bing Webmaster Tools	Non tente	Aucune cle configuree
Crawler de verification de backlinks	Non execute	Aucune liste de backlinks de reference fournie (client nouveau, pas de baseline)

Ce qui fonctionne

Le domaine se resout proprement dans l'index de Common Crawl (in_crawl: true, in_rankings: true) et est reconnu sous 3 hosts (coherent avec racine canonique + www + une variante additionnelle) - aucun signal d'alerte au niveau crawl.
Le domaine a un score PageRank non nul et classe dans le graphe de CC (rang ~1 494 157) - confirme une certaine equite de lien entrante mesurable, pas un noeud completement isole/non lie.
Aucun signe de spam de liens de type action manuelle dans les donnees effectivement recuperees (signal faible a ce Tier 0).

Constats (4)

Donnees de backlinks premium indisponibles ce passage - quota Ahrefs epuise en cours d'audit

Elevee

Les appels directs a site-explorer/domain-rating et site-explorer/metrics pour target=www.myluminette.com ont tous deux renvoye {"error": "API units limit reached. Increase pay-as-you-go limit if you need more API units. Expected usage: 50, API units left: 0."}. Epuisement du quota au niveau compte (0 unite restante sur l'ensemble du token Enterprise), pas un probleme propre au domaine. En consequence, Domain Rating, total de domaines referents, total de backlinks, distribution d'ancres et risque de liens toxiques/spam - les livrables centraux de cette dimension - n'ont pas pu etre mesures et ne sont pas notes.

Recommandation : recharger le solde d'unites pay-as-you-go Ahrefs (ou attendre le prochain cycle de reinitialisation) et re-executer specifiquement cette dimension : domain-rating, backlinks-stats/refdomains, anchors, et backlinks pour target=www.myluminette.com. Jusqu'a ce re-run, ne pas reporter de chiffre d'autorite de liens pour myluminette.com dans le scoring cross-dimension ni dans le resume client-facing - le signaler explicitement comme en attente.

Aucun repli gratuit (Moz/Bing) configure - le Tier 0 n'a aucune redondance quand la source premium echoue

Moyenne

La verification de tier a renvoye tier: 0 avec moz.available: false ("Aucune cle API Moz trouvee") et bing.available: false ("Aucune cle API Bing Webmaster trouvee"). Common Crawl a ete la seule source fonctionnelle une fois Ahrefs en echec, et CC seul plafonne la confiance a 0,50 et ne fournit ni DA/PA, ni ancres, ni scoring de spam.

Recommandation : enregistrer une cle API Moz gratuite (moz.com/products/api, 2 500 lignes/mois, sans cout) et verifier myluminette.com dans Bing Webmaster Tools. Cout nul, donne a ce nouveau client un repli Tier 1/2 fonctionnel a chaque fois que le token Ahrefs est rate-limite ou epuise - comme ce fut le cas ce passage. Tache unique d'environ 15 minutes.

Common Crawl montre zero domaine referent echantillonne - preoccupant mais non concluant

Moyenne (en attente de confirmation par donnee premium)

Les deux appels (myluminette.com et www.myluminette.com) ont renvoye "top_referring_domains": [] et "referring_domains_sample": 0, malgre un domaine in_crawl: true avec un PageRank mesurable (rang ~1 494 157) et un rang de centralite harmonique ~3 376 827. Autrement dit, le graphe de CC reconnait que le site existe et a un certain poids de lien entrant, mais son echantillon public de domaines referents n'en a capture aucun pour cette release.

Reserve importante : le graphe de liens de Common Crawl n'echantillonne qu'environ 25 a 40% des donnees de liens domaine-a-domaine du web reel, et il est connu pour sous-echantillonner les sites DTC/e-commerce de taille moyenne par rapport aux grands editeurs. Un echantillon a zero domaine de CC n'est pas une preuve de zero backlink reel - cela refletela plupart du temps une lacune de couverture de CC pour une marque e-commerce mono-langue en expansion, pas une absence reelle de liens.

Recommandation : traiter comme la priorite de re-verification numero un des que les credits Ahrefs sont restaures - recuperer en premier refdomains et backlinks-stats pour www.myluminette.com, puisque c'est le chiffre non resolu le plus consequent de toute la dimension.

Distribution d'ancres, risque de liens toxiques/spam et visibilite organique via backlinks entierement non evalues

Info - divulgation de lacune de donnee, pas un defaut du site

Aucune des sources disponibles ce passage (Common Crawl) n'expose la distribution d'ancres, le scoring spam/toxique, ou la visibilite organique liee aux backlinks - cela necessite Moz, Bing ou Ahrefs, tous indisponibles ou epuises (voir constats #1-2). Aucune affirmation n'est faite sur le naturel des ancres ou le ratio de liens toxiques dans ce rapport ; presenter une estimation synthetique pour ces metriques violerait la regle "pas d'affirmation numerique trompeuse" au Tier 0.

Recommandation : une fois Ahrefs restaure, recuperer site-explorer/anchors (distribution d'ancres) et croiser les candidats a liens toxiques contre la checklist de motifs standard, en portant une attention particuliere aux mismatches de domaine en langue etrangere (myluminette.com vend sur 20+ marches localises - un sous-produit normal d'une expansion internationale legitime, a ne pas signaler automatiquement comme toxique sans revue manuelle).

Prochaines etapes recommandees (ordre de priorite)

Recharger les unites pay-as-you-go Ahrefs et re-executer domain-rating, refdomains/backlinks-stats, anchors, et backlinks pour www.myluminette.com - resout a lui seul les constats #1, #3 et #4.
Enregistrer une cle API Moz gratuite et verifier Bing Webmaster Tools comme repli Tier 1/2 permanent (constat #2) - a faire independamment du statut Ahrefs, redondance gratuite pour tout audit futur.
Une fois les vrais chiffres de domaines referents et de DR obtenus, re-noter cette dimension proprement et mettre a jour le placeholder dans l'agregation de donnees d'audit.

Plan d'action priorise

Recommandations dedupliquees et priorisees issues des 11 fichiers de constats specialises. Chaque ligne indique quoi faire, pourquoi (en une ligne), de quelle dimension d'audit cela vient, et une estimation d'effort. Cliquer sur un en-tete de colonne trie le tableau.

Phase 1 - Correctifs critiques

Semaine 1

Constats a plus forte severite avec un risque direct sur le revenu, la confiance ou la suspension de plateforme. Majoritairement des correctifs de template ou de valeur unique a impact site-wide/fort effet de levier.

#	Quoi	Pourquoi	Dimension	Effort
1	Changer `itemCondition` de `NewCondition` a `RefurbishedCondition` sur tout le schema des produits reconditionnes (Luminette 3, et auditer Luminette 2 / Drive reconditionnes pour le meme template)	Google Merchant Center peut desapprouver ou suspendre des fiches pour incoherence d'etat produit	E-commerce	Faible
2	Corriger la contradiction robots.txt (Disallow /collections) vs sitemap (sitemap_collections_.xml soumet les memes URL) vs noindex sur les pages collection - choisir un seul mecanisme	Google ne peut pas reconcilier "crawle ceci" (sitemap) avec "ne crawle pas ceci" (robots.txt), gaspille le budget de crawl, risque des avertissements Search Console	Technique, Sitemap	Moyen
3	Corriger la fuite du code marche/pays dans les balises <title> et meta description - un seul bug de template Liquid	Affecte le snippet SERP de chaque URL du site sur les 24 locales ; risque aussi un titre geo-IP-dependant indexe de facon incoherente pour Googlebot	Technique, E-commerce	Faible
4	Confirmer si Okendo/Loox injectent le schema Review/AggregateRating cote client (check DOM rendu) ; sinon, ajouter manuellement aggregateRating + entrees d'avis reelles au schema Produit	Constat le plus repete de l'audit (Schema, E-commerce, GEO, SXO le signalent tous independamment) ; les etoiles d'avis sont un levier de confiance majeur pour un achat de bien-etre reflechi et sont actuellement invisibles pour Google/IA	Schema, E-commerce, GEO, SXO	Moyen
5	Recherche/remplacement global : `"@type": "Website"` -> `"@type": "WebSite"` sur tous les templates de schema	Type schema.org invalide (sensible a la casse) - compromet l'eligibilite sitelinks-searchbox et le noeud home de chaque fil d'Ariane	Schema	Faible

Phase 2 - Ameliorations a fort impact

Semaines 2-3

Correctifs structurels necessitant une coordination theme/template et configuration Shopify Markets, mais sans production de nouveau contenu.

#	Quoi	Pourquoi	Dimension	Effort
6	Ajouter des exceptions robots.txt Allow: pour /policies/* (et reconsiderer /collections) pour les robots IA	llms.txt demande explicitement aux agents de recuperer ces chemins pendant que robots.txt les bloque pour tous - une auto-contradiction	GEO	Faible
7	Ajouter le schema FAQPage au bloc FAQ de la fiche Luminette 3 et a l'article phare "la luminotherapie fonctionne-t-elle"	Le contenu existe deja, il ne manque que le balisage ; gain rapide et de forte valeur pour la citation IA	Contenu, Schema, GEO	Faible
8	Reformater toutes les dates d'article JSON-LD au format ISO 8601 strict (separateur T, pas un espace)	Des dates malformees risquent d'etre exclues de l'eligibilite aux rich results de fraicheur	Schema	Faible
9	Definir ProductGroup.variesBy a ["https://schema.org/color"] (actuellement un tableau vide - propriete requise)	Un variesBy vide peut causer le rejet du ProductGroup ou traiter les variantes comme des doublons non lies	Schema	Faible
10	Corriger l'URL image malformee et non-absolue dans le noeud Article duplique du BreadcrumbList ; idealement arreter de dupliquer les donnees Article completes dans BreadcrumbList	URL cassee, et duplication non standard qui augmente la surface de bug	Schema	Faible
11	Ajouter width/height explicite (ou CSS aspect-ratio) a toutes les images templatisees, en commencant par la galerie fiche produit (291 instances) et les images de selecteur accueil (26 instances)	Risque CLS severe et systemique issu d'un snippet Liquid d'image partage	Performance, Technique	Moyen
12	Preloader l'image hero/LCP de l'accueil (link rel="preload" as="image" fetchpriority="high") et la marquer loading="eager" au lieu de "lazy"	L'image hero est decouverte a ~82% du source HTML sans hint de preload - probablement le plus grand levier LCP unique vu que le TTFB est deja rapide	Performance	Faible
13	Reduire la taille du DOM sur les templates accueil et fiche produit (actuellement ~5 400-5 600 elements, 3,6x au-dessus du seuil de risque de 1 500) - auditer le markup duplique/cache, cibler <2 000	Un DOM large augmente le risque INP (recalcul de style/layout couteux a l'interaction) et ralentit le parsing initial	Performance	Moyen
14	Verifier manuellement le rendu en direct des sections a contenu declenche par le scroll qui capturent vides dans les screenshots (~30-40% de la hauteur de page sur accueil et fiche produit)	Si de vrais utilisateurs ou le renderer headless de Googlebot vivent le meme echec, du contenu decisif (tableau comparatif, liste de benefices) pourrait ne pas etre visible ou indexe de facon fiable	Visuel	Faible
15	Consolider le titre/meta de la fiche reconditionnee pour la differencier clairement de la fiche produit neuf (ajouter "Reconditionne")	Des titres quasi identiques risquent actuellement la cannibalisation de requete interne et un mauvais CTR pour les chercheurs a intention reconditionne	E-commerce	Faible
16	Standardiser le formatage de prix dans le schema ProductGroup en chaines a deux decimales ; confirmer que le flux Merchant Center source depuis l'API produit native Shopify	Un typage de prix incoherent est une cause courante de rejets "price mismatch" en flux	E-commerce	Faible
17	Confirmer avec le client si /nl/ vs /nl-nl/ sont des marches intentionnellement distincts ou un doublon legacy ; consolider/rediriger si ce dernier	Evite une dilution de contenu duplique entre pages neerlandaises quasi identiques	Sitemap	Faible
18	Decoder les entites HTML (' etc.) avant d'injecter le texte dans les champs description/articleBody du JSON-LD	Bug de qualite visible sur toute surface affichant ce texte (snippets Google, AI Overviews)	Schema	Faible
19	Depublier ou noindexer + retirer du sitemap la page QA interne /pages/test-form	Page interne oubliee actuellement indexable publiquement	Technique	Faible
20	Durcir HSTS (max-age a 31536000+, ajouter includeSubDomains; preload) et ajouter les headers Referrer-Policy/Permissions-Policy	Durcissement incremental de securite/confidentialite ; releve de la config Cloudflare/Shopify	Technique	Faible

Phase 3 - Contenu et autorite

Mois 2

Travail de production de contenu et d'architecture de l'information - la couche la plus faible du site. Sequence : consolider d'abord, puis construire les pages a haute intention manquantes, puis superposer les signaux E-E-A-T.

#	Quoi	Pourquoi	Dimension	Effort
21	Consolider les 4 silos d'URL paralleles du blog en une structure canonique unique ; fusionner les clusters thematiques en chevauchement (8 posts "coup de blues hivernal", 6 posts "vitamine D", etc.) en 1 pilier + 2-3 spokes differencies, avec redirections 301 pour le reste	Auto-cannibalisation confirmee via des recherches site: montrant 5+ URL du site en concurrence pour une seule requete - le correctif de contenu a plus fort impact disponible	Clustering	Eleve
22	Rediriger en 301 les 404 orphelines encore indexees sous /light-therapy/* legacy (pages pilier fondamentales)	Gaspille l'equite de lien accumulee et cree des impasses pour les liens externes et les fiches SERP en cache	Clustering	Moyen
23	Construire un article encadre medicalement et credite par un relecteur ciblant "luminotherapie depression saisonniere", citant Prof. Robert Poirrier (deja un actif on-site) et les donnees de l'essai clinique LUMIDEP/MDD	Zero presence de marque actuellement sur cette requete a haute intention ; 100% du SERP est des domaines d'autorite medicale	SXO, Clustering	Moyen
24	Construire une veritable page comparaison/guide d'achat ("Meilleure lampe de luminotherapie en 2026") incluant la propre lampe 2-en-1 de Luminette, selon le motif Page de comparaison (tableau, avantages/inconvenients, verdict, criteres de categorie)	Le SERP pour "meilleure lampe luminotherapie" est a 100% du contenu de comparaison concurrent ; la propre lampe de Luminette n'apparait nulle part	SXO	Moyen
25	Creer une page categorie/landing dediee /collections/lunettes-de-luminotherapie pour la gamme lunettes (actuellement en 404), avec des blocs de contenu guide d'achat integres	Le mot-cle produit central n'est repondu que par l'accueil generique et dilue ; le SERP montre un motif hybride Produit/Categorie + Guide	SXO	Moyen
26	Lier chaque etude clinique nommee sur /pages/clinical-study et /pages/new-research a sa source PubMed/revue ; ajouter une liste de citations numerotees	Des pourcentages d'efficacite precis sont actuellement enonces comme des faits bruts non verifiables - un signal de confiance a surveiller pour du contenu YMYL et un plafond pour la citabilite IA	Contenu	Moyen
27	Ajouter un bloc bio d'auteur/relecteur visible (credentials, ex. "relu par [specialiste]") avec schema Person (jobTitle/worksFor) a l'article de blog medical phare, et le repliquer sur le contenu d'allegation sante	L'auteur nomme n'a actuellement aucun credential visible sur page - correctif a plus fort effet de levier pour la ponderation de confiance IA sur du contenu YMYL	Contenu, GEO	Moyen
28	Ajouter une section accueil de 200-400 mots enoncant l'origine de la recherche universitaire, les scientifiques nommes et la certification de securite	L'accueil est actuellement une grille produit/prix sans narratif de confiance, sous-utilisant l'URL a plus forte autorite du domaine	Contenu	Faible
29	Reecrire /pages/light-therapy d'une liste de liens de ~215 mots en une vraie page pilier de 800+ mots	Actuellement mince et duplicative du contenu du blog ; devrait ancrer le cluster thematique, pas juste y renvoyer	Contenu, Clustering	Moyen
30	Remplacer le module statique "Articles lies" par un composant pilote par tag/categorie pour que les spokes se maillent au sein de leur vrai cluster	Affiche actuellement un contenu identique et non contextuel sur des types d'article sans rapport	Clustering	Moyen
31	Introduire une taxonomie categorie/tag pour le blog (pages d'archive doublant comme hubs legers)	Le blog est une liste plate chronologique unique sans navigation thematique ; la decouverte depend entierement de liens internes actuellement non contextuels	Clustering	Moyen
32	Construire/consolider des pages faisant autorite pour les ecarts d'intention identifies : "lunettes de luminotherapie vs lampe SAD" (comparaison de format, aucune n'existe) et "combien de temps utiliser les lunettes" (actuellement fragmente sur 3 posts faibles)	Ecarts directement actionnables, a forte intention, que la marque a deja le contenu produit/FAQ pour supporter	Clustering	Moyen
33	Deprioriser la nouvelle production de contenu bien-etre hors-marque ("Entrainement de 7 minutes", "Meilleurs livres sur le sommeil", etc.) ; integrer les posts existants a un vrai lien luminotherapie ou elaguer/noindexer	Concurrence pour le budget de crawl/autorite thematique contre le corpus central luminotherapie sans chemin vers du trafic qualifie produit	Clustering	Faible
34	Localiser les slugs d'URL du blog par marche (ex. contenu francais deplace hors du slug anglais /blogs/article/do-light-therapy-glasses-work)	Zero signal de mot-cle francais dans l'URL malgre un titre/meta/contenu entierement localise	SXO	Moyen
35	Appliquer le motif GEO de l'article phare (H2 en question, schema FAQPage, citations) sur les categories de blog light-therapy et light-therapy-applications	Un seul post sur ~130 est entierement optimise GEO ; les pages hub de categorie sont actuellement minces et non structurees en question	GEO	Moyen
36	Creer ou lier formellement une chaine YouTube possedee ; viser une entree Wikipedia pour Lucimed/Luminette si les criteres de notoriete peuvent etre remplis	Les deux plus fortes correlations de mention de marque avec la citation IA sont actuellement absentes	GEO	Eleve
37	Ajouter le schema AggregateRating/Review a la page /pages/customer-reviews on-site et la garder visiblement fraiche/datee	Cede actuellement l'espace de snippet d'avis SERP a Trustpilot (3 des 6 resultats visibles pour "luminette avis")	SXO	Faible

Phase 4 - Suivi et iteration

Continu

#	Quoi	Pourquoi	Dimension	Effort
38	Re-executer l'audit du profil de liens avec Ahrefs (domain-rating, refdomains/backlinks-stats, anchors, backlinks) une fois le quota pay-as-you-go reinitialise (2026-08-01)	Le placeholder actuel (~30-40, confiance 0,25) est base uniquement sur Common Crawl et explicitement signale comme non fiable - c'est le chiffre non resolu le plus consequent de tout l'audit	Backlinks	Faible (recurrent)
39	Enregistrer une cle API Moz gratuite et verifier myluminette.com dans Bing Webmaster Tools	Repli Tier 1/2 sans cout pour tout futur audit ou le token Ahrefs est rate-limite ou epuise, comme ce fut le cas ce passage	Backlinks	Faible (ponctuel)
40	Re-executer PageSpeed Insights / CrUX / Lighthouse une fois le rate-limit leve pour confirmer les vrais percentiles field LCP/INP/CLS	Les constats Performance actuels sont des estimations issues de preuves statiques/reponse serveur uniquement, pas de donnees lab/field en direct	Performance	Faible (recurrent)
41	Une fois l'acces fetch rendu/Playwright disponible, confirmer si Okendo/Loox injectent le schema Review cote client	L'audit HTML statique uniquement n'a pas pu l'exclure ; determine si l'element Phase 1 #4 necessite un ajout schema manuel ou juste une bascule de reglage app	Schema, E-commerce	Faible
42	Effectuer un diff complet crawl-vs-sitemap (ex. Screaming Frog en mode liste contre l'export sitemap complet) sur les 24 sitemaps de locale	Non effectue dans cet audit faute de budget de requetes ; necessaire pour confirmer l'absence de pages orphelines ou extra/a risque au-dela du probleme collections deja trouve	Sitemap	Moyen
43	Etendre l'analyse SXO au tunnel complet de 15-20+ mots-cles (lunettes, lampe, symptomes, comparaisons, marque) avec des SERP rank-trackees en direct	Ce passage n'a couvert que 4 mots-cles dans un passage a perimetre restreint ; necessaire pour confirmer les positions de classement exactes et les features SERP en direct	SXO	Moyen
44	Confirmer avec le client si la marche ru-ru doit rester en ligne compte tenu du contexte general de sanctions UE	Signale comme une question business/juridique, pas un defaut technique	Technique	Faible
45	Revisiter periodiquement /agents.md, llms.txt et sitemap_agentic_discovery.xml a mesure que les standards de commerce agentique IA evoluent	Le site est actuellement en avance sur les concurrents sur ce terrain emergent - avance a proteger	GEO, Sitemap	Faible (recurrent)

Legende d'effort - Faible : correctif de template/valeur unique, quelques heures, sans nouveau contenu. Moyen : travail de template cross-page, configuration Shopify Markets, ou une seule piece de contenu nouvelle/reecrite. Eleve : consolidation de contenu multi-page, reconstruction d'architecture de l'information, ou mise en place d'un nouveau canal (ex. YouTube).