CMS detected - MetricSpot docs

Q: Can I hide what CMS I'm on?

Partly. You can remove the tag and rewrite obvious paths, but JS globals, response-header quirks, and asset-host signatures still leak. Most detection tools (Wappalyzer, BuiltWith, MetricSpot) cross-check multiple signals — hiding one doesn't hide the rest, and the effort rarely earns its keep.

What this check does

Identifies the CMS or hosted site builder serving the page from a layered set of fingerprints:

Generator meta tag — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x, etc. The first thing we read.
Response headers — Shopify ships x-shopify-stage, Wix sends x-wix-request-id, Squarespace sends x-served-by with edge identifiers.
HTML signatures — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
JavaScript globals when JS execution is enabled — window.Shopify, window.Wix, window.Static, window.Squarespace.
DOM patterns — class prefixes (elementor-, wp-block-, wf-, sqs-), data attributes, and known root selectors.

The first reliable signal wins. The result is informational — this rule never fails an audit. It’s there so the rest of the report can tailor its recommendations.

Why it matters

The CMS is the single most useful piece of context for the rest of the audit, because fix paths diverge wildly:

A failing HTTPS check on Shopify is a domain-config issue (rare); on WordPress it’s usually a Really Simple SSL plugin missing or an Apache config not redirecting.
A missing XML sitemap on Webflow is fixed in Project Settings → SEO; on Ghost it’s auto-generated and the fix is “stop blocking it in robots.txt”; on WordPress it’s a Yoast / Rank Math toggle.
A missing canonical tag on Squarespace is a per-page setting; on Next.js it’s a <link> in your layout.

Knowing the CMS also tells you what’s out of your control. Wix and Squarespace lock down response headers — you cannot add a custom HSTS or Referrer-Policy header. Shopify lets you edit theme.liquid but not the server config. WordPress lets you do anything, which is both the gift and the curse.

It also helps you reason about performance: WordPress + Elementor pages routinely fail Largest Contentful Paint because of the page-builder’s CSS payload; Ghost and Next.js sites rarely do. Same content, very different ceilings.

How to fix it

This is an informational rule — there’s nothing to “fix.” What changes is which recipe applies elsewhere in your audit.

If you’re on WordPress, your most common levers are:

A caching plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache) to hit decent Lighthouse performance.
An SEO plugin (Yoast, Rank Math, SEOPress) for XML sitemap, canonical tags, and Open Graph tags.
A headers plugin (HTTP Headers, Really Simple SSL) or .htaccess edits for HSTS, Referrer-Policy, and clickjacking protection.

If you’re on Shopify, edit theme.liquid to add Open Graph and structured data; everything header-level is controlled by Shopify. Apple touch icon and favicon go through Theme Settings → Favicon.

If you’re on Webflow, Project Settings → SEO covers metadata, sitemaps, and robots.txt; structured data goes inside Project Settings → Custom Code → Head Code.

If you’re on Squarespace, most SEO controls are in the page’s SEO panel (title, description, OG image). Some headers can be added in Code Injection but most security headers are not customisable.

If you’re on Ghost, most rules pass by default — Ghost ships modern structured data, sitemaps, OG tags, and a reasonable Lighthouse performance baseline out of the box.

If MetricSpot detected nothing — your stack is either bespoke, headless, or strips its generator signatures. The audit falls back to “no CMS detected” and treats you as having full server control.

Tighten or remove the generator string if you want to. Some teams hide <meta name="generator"> to make fingerprinting marginally harder for vulnerability scanners. It’s security theatre — the rest of the fingerprints still give you away — but it doesn’t hurt:

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

Frequently asked questions

MetricSpot detected the wrong CMS. Why?

Two common reasons: (1) your CMS-of-record has been wrapped by a headless renderer (Next.js fetching content from Contentful or WordPress as an API) — we see the front-end framework, not the source; (2) the page is heavily customised and the usual signatures have been stripped. The rule is informational, so this won’t affect your score either way.

Does the detected CMS affect my audit score?

No. This rule is purely informational. It does, however, influence the recipes you see — failures elsewhere in the report try to recommend a fix path appropriate to your detected stack.

Can I hide what CMS I’m on?

Partly. You can remove the <meta name="generator"> tag and rewrite obvious paths, but JS globals, response-header quirks, and asset-host signatures still leak. Most detection tools (Wappalyzer, BuiltWith, MetricSpot) cross-check multiple signals — hiding one doesn’t hide the rest, and the effort rarely earns its keep.