CMS detectado - Docs de MetricSpot

Q: ¿Puedo esconder en qué CMS estoy?

En parte. Puedes quitar el y reescribir las rutas obvias, pero los globales de JS, los quirks de cabeceras de respuesta y las firmas de hosts de assets siguen filtrándose. La mayoría de herramientas de detección (Wappalyzer, BuiltWith, MetricSpot) cruzan varias señales — esconder una no esconde el resto, y el esfuerzo rara vez vale la pena.

Qué comprueba esta verificación

Identifica el CMS o el constructor de sitios alojado que sirve la página a partir de un conjunto en capas de firmas:

Meta tag generator — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x, etc. Lo primero que leemos.
Cabeceras de respuesta — Shopify envía x-shopify-stage, Wix manda x-wix-request-id, Squarespace manda x-served-by con identificadores de edge.
Firmas HTML — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
Globales de JavaScript cuando se permite ejecución de JS — window.Shopify, window.Wix, window.Static, window.Squarespace.
Patrones del DOM — prefijos de clase (elementor-, wp-block-, wf-, sqs-), atributos data y selectores raíz conocidos.

La primera señal fiable gana. El resultado es informativo — esta regla nunca hace fallar una auditoría. Está ahí para que el resto del informe adapte sus recomendaciones.

Por qué importa

El CMS es la pieza más útil de contexto para el resto de la auditoría, porque las rutas de arreglo divergen radicalmente:

Un fallo en HTTPS en Shopify es un tema de configuración de dominio (raro); en WordPress suele ser un plugin Really Simple SSL ausente o una config de Apache que no redirige.
Un Sitemap XML ausente en Webflow se arregla en Project Settings → SEO; en Ghost se autogenera y el arreglo es “deja de bloquearlo en robots.txt”; en WordPress es un toggle de Yoast / Rank Math.
Una etiqueta canonical ausente en Squarespace es un ajuste por página; en Next.js es un <link> en tu layout.

Conocer el CMS también te dice qué está fuera de tu control. Wix y Squarespace bloquean las cabeceras de respuesta — no puedes añadir HSTS o Referrer-Policy personalizados. Shopify te deja editar theme.liquid pero no la config del servidor. WordPress te deja hacer cualquier cosa, lo cual es la bendición y la maldición.

También ayuda a razonar sobre rendimiento: las páginas de WordPress + Elementor fallan habitualmente el Largest Contentful Paint por el payload de CSS del page builder; los sitios de Ghost y Next.js rara vez. Mismo contenido, techos muy distintos.

Cómo arreglarlo

Es una regla informativa — no hay nada que “arreglar”. Lo que cambia es qué receta aplica en otra parte de tu auditoría.

Si estás en WordPress, tus palancas más habituales son:

Un plugin de caché (LiteSpeed Cache, WP Rocket, W3 Total Cache) para pegar una puntuación Lighthouse decente.
Un plugin SEO (Yoast, Rank Math, SEOPress) para Sitemap XML, etiqueta canonical y etiquetas Open Graph.
Un plugin de cabeceras (HTTP Headers, Really Simple SSL) o ediciones en .htaccess para HSTS, Referrer-Policy y protección clickjacking.

Si estás en Shopify, edita theme.liquid para añadir Open Graph y datos estructurados; todo lo de cabeceras lo controla Shopify. Apple touch icon y favicon van por Theme Settings → Favicon.

Si estás en Webflow, Project Settings → SEO cubre metadata, sitemaps y robots.txt; los datos estructurados van en Project Settings → Custom Code → Head Code.

Si estás en Squarespace, la mayoría de controles SEO están en el panel SEO de la página (título, descripción, imagen OG). Algunas cabeceras se pueden añadir en Code Injection pero la mayoría de cabeceras de seguridad no son personalizables.

Si estás en Ghost, casi todas las reglas pasan por defecto — Ghost envía datos estructurados modernos, sitemaps, etiquetas OG y una base razonable de Lighthouse performance de fábrica.

Si MetricSpot no detectó nada — tu stack es a medida, headless o quita sus firmas de generator. La auditoría cae a “ningún CMS detectado” y te trata como si tuvieras control total del servidor.

Aprieta o quita la cadena de generator si quieres. Algunos equipos esconden <meta name="generator"> para hacer el fingerprinting marginalmente más difícil para los escáneres de vulnerabilidades. Es teatro de seguridad — el resto de las firmas te delatan igual — pero no hace daño:

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

Preguntas frecuentes

MetricSpot detectó el CMS equivocado. ¿Por qué?

Dos razones habituales: (1) tu CMS-de-registro ha sido envuelto por un renderer headless (Next.js tirando contenido desde Contentful o WordPress como API) — vemos el framework de front-end, no la fuente; (2) la página está muy personalizada y las firmas habituales se han quitado. La regla es informativa, así que esto no afecta a tu puntuación en ningún caso.

¿El CMS detectado afecta a mi puntuación de auditoría?

No. Esta regla es puramente informativa. Sí influye en las recetas que ves — los fallos en otra parte del informe intentan recomendar una ruta de arreglo apropiada a tu stack detectado.

¿Puedo esconder en qué CMS estoy?

En parte. Puedes quitar el <meta name="generator"> y reescribir las rutas obvias, pero los globales de JS, los quirks de cabeceras de respuesta y las firmas de hosts de assets siguen filtrándose. La mayoría de herramientas de detección (Wappalyzer, BuiltWith, MetricSpot) cruzan varias señales — esconder una no esconde el resto, y el esfuerzo rara vez vale la pena.