CMS rilevato - Docs di MetricSpot

Q: Posso nascondere su quale CMS sono?

Parzialmente. Puoi rimuovere il tag e riscrivere i path ovvi, ma globali JS, particolarità degli header di risposta e firme degli host asset trapelano comunque. La maggior parte dei tool di detection (Wappalyzer, BuiltWith, MetricSpot) fa cross-check di più segnali — nasconderne uno non nasconde gli altri, e lo sforzo raramente vale.

Cosa verifica questo controllo

Identifica il CMS o il site builder hosted che serve la pagina da un set stratificato di firme:

Meta tag generator — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x, ecc. La prima cosa che leggiamo.
Header di risposta — Shopify spedisce x-shopify-stage, Wix invia x-wix-request-id, Squarespace invia x-served-by con identificatori edge.
Firme HTML — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
Globali JavaScript quando l’esecuzione JS è abilitata — window.Shopify, window.Wix, window.Static, window.Squarespace.
Pattern DOM — prefissi di classe (elementor-, wp-block-, wf-, sqs-), attributi data, e selettori root noti.

Il primo segnale affidabile vince. Il risultato è informativo — questa regola non fa mai fallire un audit. C’è perché il resto del report possa adattare le sue raccomandazioni.

Perché è importante

Il CMS è il singolo pezzo di contesto più utile per il resto dell’audit, perché i percorsi di fix divergono enormemente:

Un controllo HTTPS fallito su Shopify è un problema di config dominio (raro); su WordPress è di solito un plugin Really Simple SSL mancante o una config Apache che non redirige.
Una Sitemap XML mancante su Webflow si sistema in Project Settings → SEO; su Ghost è auto-generata e il fix è “smetti di bloccarla in robots.txt”; su WordPress è un toggle di Yoast / Rank Math.
Un tag canonical mancante su Squarespace è un’impostazione per-page; su Next.js è un <link> nel tuo layout.

Conoscere il CMS ti dice anche cosa è fuori dal tuo controllo. Wix e Squarespace bloccano gli header di risposta — non puoi aggiungere un header HSTS o Referrer-Policy personalizzato. Shopify ti lascia modificare theme.liquid ma non la config del server. WordPress ti permette di fare qualsiasi cosa, che è sia il dono sia la maledizione.

Aiuta anche a ragionare sulla performance: le pagine WordPress + Elementor falliscono routinemente Largest Contentful Paint per via del payload CSS del page-builder; i siti Ghost e Next.js raramente lo fanno. Stesso contenuto, soffitti molto diversi.

Come sistemarlo

Questa è una regola informativa — non c’è niente da “sistemare”. Quello che cambia è quale ricetta si applica altrove nel tuo audit.

Se sei su WordPress, le tue leve più comuni sono:

Un plugin di caching (LiteSpeed Cache, WP Rocket, W3 Total Cache) per raggiungere un decente Punteggio prestazioni Lighthouse.
Un plugin SEO (Yoast, Rank Math, SEOPress) per Sitemap XML, tag canonical e Open Graph.
Un plugin header (HTTP Headers, Really Simple SSL) o modifiche .htaccess per HSTS, Referrer-Policy e protezione clickjacking.

Se sei su Shopify, modifica theme.liquid per aggiungere Open Graph e dati strutturati; tutto a livello header è controllato da Shopify. Apple touch icon e favicon passano da Theme Settings → Favicon.

Se sei su Webflow, Project Settings → SEO copre metadati, sitemap e robots.txt; i dati strutturati vanno dentro Project Settings → Custom Code → Head Code.

Se sei su Squarespace, la maggior parte dei controlli SEO è nel pannello SEO della pagina (titolo, descrizione, immagine OG). Alcuni header possono essere aggiunti in Code Injection ma la maggior parte degli header di sicurezza non è personalizzabile.

Se sei su Ghost, la maggior parte delle regole passa di default — Ghost spedisce dati strutturati moderni, sitemap, tag OG e una baseline ragionevole di Punteggio prestazioni Lighthouse di default.

Se MetricSpot non ha rilevato nulla — il tuo stack è bespoke, headless o spoglia le firme del generator. L’audit ripiega su “no CMS detected” e ti tratta come se avessi il pieno controllo del server.

Stringi o rimuovi la stringa generator se vuoi. Alcuni team nascondono <meta name="generator"> per rendere il fingerprinting marginalmente più difficile per gli scanner di vulnerabilità. È security theatre — il resto delle firme ti tradisce comunque — ma non fa male:

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

Domande frequenti

MetricSpot ha rilevato il CMS sbagliato. Perché?

Due ragioni comuni: (1) il tuo CMS-di-registro è stato avvolto da un renderer headless (Next.js che fetcha contenuto da Contentful o WordPress come API) — vediamo il framework front-end, non la sorgente; (2) la pagina è pesantemente personalizzata e le firme usuali sono state spogliate. La regola è informativa, quindi non influirà sul tuo punteggio in nessun caso.

Il CMS rilevato influisce sul mio punteggio audit?

No. Questa regola è puramente informativa. Influenza, però, le ricette che vedi — i fallimenti altrove nel report cercano di raccomandare un percorso di fix appropriato al tuo stack rilevato.

Posso nascondere su quale CMS sono?

Parzialmente. Puoi rimuovere il tag <meta name="generator"> e riscrivere i path ovvi, ma globali JS, particolarità degli header di risposta e firme degli host asset trapelano comunque. La maggior parte dei tool di detection (Wappalyzer, BuiltWith, MetricSpot) fa cross-check di più segnali — nasconderne uno non nasconde gli altri, e lo sforzo raramente vale.