CMS detetado - Docs do MetricSpot

Q: Posso esconder em que CMS estou?

Em parte. Podes remover a tag e reescrever caminhos óbvios, mas globais de JS, peculiaridades de cabeçalhos de resposta e assinaturas de hosts de ativos continuam a vazar. A maioria das ferramentas de deteção (Wappalyzer, BuiltWith, MetricSpot) cruza vários sinais — esconder um não esconde o resto, e o esforço raramente compensa.

O que esta verificação faz

Identifica o CMS ou construtor de sites alojado que serve a página a partir de um conjunto em camadas de fingerprints:

Meta tag generator — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x, etc. A primeira coisa que lemos.
Cabeçalhos de resposta — o Shopify envia x-shopify-stage, o Wix envia x-wix-request-id, o Squarespace envia x-served-by com identificadores de edge.
Assinaturas HTML — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
Globais de JavaScript quando a execução de JS está ligada — window.Shopify, window.Wix, window.Static, window.Squarespace.
Padrões no DOM — prefixos de classe (elementor-, wp-block-, wf-, sqs-), atributos data e seletores de raiz conhecidos.

O primeiro sinal fiável ganha. O resultado é informativo — esta regra nunca faz falhar uma auditoria. Está cá para que o resto do relatório possa adaptar as recomendações.

Porque é importante

O CMS é a peça de contexto mais útil para o resto da auditoria, porque os caminhos de correção divergem muito:

Uma verificação de HTTPS falhada no Shopify é um problema de configuração de domínio (raro); no WordPress costuma ser um plugin Really Simple SSL em falta ou uma configuração Apache que não redireciona.
Um sitemap XML em falta no Webflow corrige-se em Project Settings → SEO; no Ghost é gerado automaticamente e a correção é “deixa de o bloquear no robots.txt”; no WordPress é um toggle do Yoast / Rank Math.
Uma tag canonical em falta no Squarespace é uma definição por página; em Next.js é uma <link> no teu layout.

Saber o CMS também te diz o que está fora do teu controlo. Wix e Squarespace bloqueiam cabeçalhos de resposta — não podes adicionar um cabeçalho HSTS ou Referrer-Policy personalizado. O Shopify deixa-te editar theme.liquid mas não a configuração do servidor. O WordPress deixa-te fazer tudo, o que é simultaneamente a bênção e a maldição.

Também ajuda a raciocinar sobre desempenho: páginas WordPress + Elementor falham rotineiramente o Largest Contentful Paint por causa do payload de CSS do construtor de páginas; sites Ghost e Next.js raramente falham. Mesmo conteúdo, tetos muito diferentes.

Como corrigir

Esta é uma regra informativa — não há nada a “corrigir”. O que muda é qual receita se aplica noutras partes da tua auditoria.

Se estás em WordPress, as tuas alavancas mais comuns são:

Um plugin de cache (LiteSpeed Cache, WP Rocket, W3 Total Cache) para atingir uma pontuação de desempenho Lighthouse decente.
Um plugin de SEO (Yoast, Rank Math, SEOPress) para sitemap XML, tags canonical e tags Open Graph.
Um plugin de cabeçalhos (HTTP Headers, Really Simple SSL) ou edições no .htaccess para HSTS, Referrer-Policy e proteção contra clickjacking.

Se estás em Shopify, edita theme.liquid para adicionar Open Graph e dados estruturados; tudo ao nível de cabeçalhos é controlado pelo Shopify. O Apple touch icon e o favicon passam por Theme Settings → Favicon.

Se estás em Webflow, Project Settings → SEO cobre metadata, sitemaps e robots.txt; os dados estruturados vão em Project Settings → Custom Code → Head Code.

Se estás em Squarespace, a maioria dos controlos de SEO está no painel de SEO da página (title, description, OG image). Alguns cabeçalhos podem ser adicionados em Code Injection mas a maioria dos cabeçalhos de segurança não é personalizável.

Se estás em Ghost, a maior parte das regras passa por defeito — o Ghost envia dados estruturados modernos, sitemaps, tags OG e uma base razoável de Lighthouse performance de fábrica.

Se o MetricSpot não detetou nada — a tua stack é à medida, headless, ou retira as suas assinaturas de generator. A auditoria recorre a “nenhum CMS detetado” e trata-te como tendo controlo total sobre o servidor.

Aperta ou remove a string de generator se quiseres. Algumas equipas escondem <meta name="generator"> para tornar marginalmente mais difícil o fingerprinting por scanners de vulnerabilidades. É teatro de segurança — as outras fingerprints denunciam-te na mesma — mas não faz mal:

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

Perguntas frequentes

O MetricSpot detetou o CMS errado. Porquê?

Duas razões comuns: (1) o teu CMS de referência foi envolto por um renderizador headless (Next.js a ir buscar conteúdo ao Contentful ou WordPress como API) — vemos a framework de frontend, não a fonte; (2) a página está fortemente personalizada e as assinaturas habituais foram retiradas. A regra é informativa, por isso isto não vai afetar a tua pontuação de qualquer forma.

O CMS detetado afeta a minha pontuação de auditoria?

Não. Esta regra é puramente informativa. Influencia, no entanto, as receitas que vês — falhas noutras partes do relatório tentam recomendar um caminho de correção adequado à stack detetada.

Posso esconder em que CMS estou?

Em parte. Podes remover a tag <meta name="generator"> e reescrever caminhos óbvios, mas globais de JS, peculiaridades de cabeçalhos de resposta e assinaturas de hosts de ativos continuam a vazar. A maioria das ferramentas de deteção (Wappalyzer, BuiltWith, MetricSpot) cruza vários sinais — esconder um não esconde o resto, e o esforço raramente compensa.