tech stack

CMS détecté

MetricSpot identifie le CMS ou constructeur de site qui propulse la page. Informationnel — mais change la recette de correction recommandée par le reste de l'audit.

Ce que vérifie ce contrôle

Identifie le CMS ou le constructeur de site hébergé qui sert la page à partir d’un jeu d’empreintes en couches :

  • Balise méta generator — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x, etc. C’est la première chose lue.
  • En-têtes de réponse — Shopify expédie x-shopify-stage, Wix envoie x-wix-request-id, Squarespace envoie x-served-by avec des identifiants edge.
  • Signatures HTML — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
  • Globals JavaScript quand l’exécution JS est activée — window.Shopify, window.Wix, window.Static, window.Squarespace.
  • Motifs DOM — préfixes de classe (elementor-, wp-block-, wf-, sqs-), attributs data, et sélecteurs racines connus.

Le premier signal fiable l’emporte. Le résultat est informationnel — cette règle ne fait jamais échouer un audit. Elle existe pour que le reste du rapport puisse adapter ses recommandations.

Pourquoi c’est important

Le CMS est l’élément de contexte le plus utile pour le reste de l’audit, parce que les chemins de correction divergent radicalement :

  • Un échec HTTPS sur Shopify est un problème de configuration de domaine (rare) ; sur WordPress, c’est généralement un plugin Really Simple SSL manquant ou une config Apache qui ne redirige pas.
  • Un sitemap XML manquant sur Webflow se corrige dans Project Settings → SEO ; sur Ghost il est auto-généré et le correctif est « arrêter de le bloquer dans robots.txt » ; sur WordPress c’est un toggle Yoast / Rank Math.
  • Une balise canonical manquante sur Squarespace est un réglage par page ; sur Next.js c’est un <link> dans votre layout.

Connaître le CMS vous dit aussi ce qui est hors de votre contrôle. Wix et Squarespace verrouillent les en-têtes de réponse — vous ne pouvez pas ajouter un en-tête HSTS ou Referrer-Policy personnalisé. Shopify vous laisse éditer theme.liquid mais pas la config serveur. WordPress vous laisse tout faire, ce qui est à la fois le don et la malédiction.

Cela aide aussi à raisonner sur la performance : les pages WordPress + Elementor échouent couramment au Largest Contentful Paint à cause du payload CSS du page builder ; les sites Ghost et Next.js rarement. Même contenu, plafonds très différents.

Comment corriger

C’est une règle informationnelle — il n’y a rien à « corriger ». Ce qui change, c’est quelle recette s’applique ailleurs dans votre audit.

Si vous êtes sur WordPress, vos leviers les plus courants sont :

Si vous êtes sur Shopify, éditez theme.liquid pour ajouter OpenGraph et les données structurées ; tout ce qui est au niveau en-tête est contrôlé par Shopify. Apple touch icon et Favicon passent par Theme Settings → Favicon.

Si vous êtes sur Webflow, Project Settings → SEO couvre les métadonnées, sitemaps et robots.txt ; les données structurées vont dans Project Settings → Custom Code → Head Code.

Si vous êtes sur Squarespace, la plupart des contrôles SEO sont dans le panneau SEO de la page (titre, description, image OG). Certains en-têtes peuvent être ajoutés dans Code Injection mais la plupart des en-têtes de sécurité ne sont pas personnalisables.

Si vous êtes sur Ghost, la plupart des règles passent par défaut — Ghost livre des données structurées modernes, des sitemaps, des balises OG et une base de score Lighthouse performance raisonnable d’origine.

Si MetricSpot n’a rien détecté — votre stack est soit sur mesure, soit headless, soit strippe ses signatures de generator. L’audit retombe sur « aucun CMS détecté » et vous traite comme ayant le contrôle complet du serveur.

Resserrez ou retirez la chaîne generator si vous le voulez. Certaines équipes masquent <meta name="generator"> pour rendre le fingerprinting marginalement plus difficile pour les scanners de vulnérabilités. C’est du théâtre de sécurité — le reste des empreintes vous trahit quand même — mais ça ne fait pas de mal :

// WordPress functions.php
remove_action('wp_head', 'wp_generator');

Questions fréquentes

MetricSpot a détecté le mauvais CMS. Pourquoi ?

Deux raisons courantes : (1) votre CMS de référence a été enveloppé par un rendu headless (Next.js récupérant du contenu depuis Contentful ou WordPress en API) — nous voyons le framework front-end, pas la source ; (2) la page est lourdement personnalisée et les signatures habituelles ont été strippées. La règle est informationnelle, donc cela n’affectera pas votre score d’une façon ou d’une autre.

Le CMS détecté affecte-t-il mon score d’audit ?

Non. Cette règle est purement informationnelle. Elle influence cependant les recettes que vous voyez — les échecs ailleurs dans le rapport essaient de recommander un chemin de correction approprié à votre stack détectée.

Puis-je cacher sur quel CMS je suis ?

Partiellement. Vous pouvez retirer la balise <meta name="generator"> et réécrire les chemins évidents, mais les globals JS, les quirks d’en-têtes de réponse et les signatures d’hôtes d’assets fuient toujours. La plupart des outils de détection (Wappalyzer, BuiltWith, MetricSpot) croisent plusieurs signaux — en cacher un ne cache pas le reste, et l’effort gagne rarement sa place.

Sources

Dernière mise à jour 2026-05-11