SEOLZ

Server version

Moderate effort

Found on 17% of audited stores.

Remove or suppress the Server version header so your web server software and version number are no longer exposed in every HTTP response.

What it is

Every time a visitor's browser (or a bot) loads a page on your store, your web server sends back a set of invisible "response headers." One of these is the `Server` header, and by default most web servers announce themselves with their exact name and version number — for example, `Server: Microsoft-IIS/10.0` or `Server: Apache/2.4.51`. A related header, `X-Powered-By`, can also reveal the scripting language or framework version (e.g., `X-Powered-By: PHP/8.1.2`). Together these are called "server version disclosure" or "banner grabbing." Neither header has any meaningful purpose for shoppers — they exist purely as leftover defaults.

Why it matters

Advertising your exact server software and version is like posting a sign on your shop door listing every lock brand and model you use. Automated attack tools (bots) continuously scan the internet for sites running specific software versions with known vulnerabilities. When your version is visible, your store becomes an easy target: attackers can instantly match your version against published vulnerability databases (CVE lists) and launch targeted exploits — without any guesswork. Suppressing these headers does not make your server invulnerable, but it removes you from the easiest tier of automated attack campaigns. It also demonstrates security hygiene to enterprise buyers and payment-card auditors (PCI DSS Requirement 2.2.7 addresses unnecessary information disclosure), reducing compliance friction.

How to fix it

  1. Identify which web server software your store runs on (Apache, Nginx, Microsoft IIS, LiteSpeed, etc.) — your hosting provider or control panel (cPanel, Plesk) can confirm this.
  2. Edit the server's configuration file to suppress or genericise the Server header (e.g., set `ServerTokens Prod` in Apache's httpd.conf, `server_tokens off` in Nginx's nginx.conf, or configure 'Remove Server Header' in IIS via URL Rewrite or the requestFiltering element).
  3. Also remove or blank the `X-Powered-By` header if present (e.g., `Header unset X-Powered-By` in Apache, `more_clear_headers 'X-Powered-By'` in Nginx, or disable it in your language/framework config such as `expose_php = Off` in PHP's php.ini).
  4. Save the configuration and reload/restart the web server service so changes take effect.
  5. Verify the fix by opening your browser's DevTools (F12 → Network tab), reloading a store page, clicking the main document request, and checking the Response Headers panel — the Server header should now show a generic value (e.g., just 'Apache' or nothing) and X-Powered-By should be absent.
  6. Re-run your security scanner or use a free header-check tool (e.g., securityheaders.com) to confirm the version string is no longer disclosed.
# Apache (httpd.conf or .htaccess)
ServerTokens Prod
ServerSignature Off
Header unset X-Powered-By

# Nginx (nginx.conf — inside http{} or server{} block)
server_tokens off;
# (requires headers_more module for full removal:)
more_clear_headers 'Server';
more_clear_headers 'X-Powered-By';

# PHP (php.ini)
expose_php = Off

# Next.js (next.config.js)
module.exports = { poweredByHeader: false }

Fix it on your platform

Pick your platform for the exact steps.

How to fix server version on Shopify
  1. Shopify is a fully hosted SaaS platform — you do not have access to the underlying web server configuration files.
  2. Shopify manages all server headers centrally. The `Server` header on Shopify storefronts is already genericised (it does not expose a version number); no action is needed or possible from the theme or admin.
  3. If a scanner flags a version header on a Shopify store, confirm the request is hitting your Shopify domain (*.myshopify.com or your custom domain pointed to Shopify) and not a third-party app proxy or custom server you separately manage.
  4. For any custom storefronts built with the Shopify Storefront API hosted on your own server, apply the server-level fix appropriate for that server (Nginx, Apache, etc.) as described in the generic steps above.
Full Shopify guide →Official Shopify docs ↗
How to fix server version on Shopify Plus
  1. Same as Shopify: the core Shopify Plus infrastructure suppresses server version details centrally.
  2. If your Plus store uses a headless/custom front-end (e.g., Next.js on Vercel or a Node server), suppress the header in that layer: in Next.js, add a `headers()` config in next.config.js to remove the `X-Powered-By` header (Next.js already removes it by default via `poweredByHeader: false`). For the underlying host (Vercel, AWS, etc.), use platform-level header rules.
  3. Contact your Shopify Plus launch engineer if server headers appear on your custom checkout subdomain.
Full Shopify Plus guide →Official Shopify Plus docs ↗
How to fix server version on WooCommerce
  1. WooCommerce runs on WordPress, which runs on a server you (or your host) control — the fix is applied at the server or hosting level, not inside WordPress itself.
  2. For Apache hosting (most shared hosts): access your hosting control panel (cPanel → File Manager, or SSH), open or create a `.htaccess` file in your site root, and add: `ServerSignature Off` and `Header unset X-Powered-By`. Also ask your host to set `ServerTokens Prod` in the main Apache config (httpd.conf) if you don't have root access.
  3. For Nginx hosting: edit your server block config (typically in /etc/nginx/sites-available/yoursite or /etc/nginx/nginx.conf) and add `server_tokens off;` inside the `http {}` or `server {}` block. Add `more_clear_headers 'Server'; more_clear_headers 'X-Powered-By';` if the headers_more module is available.
  4. For managed WordPress hosts (WP Engine, Kinsta, Flywheel, SiteGround, etc.): open a support ticket — these hosts typically handle header suppression on request or by policy, as you don't have access to the server config directly.
  5. Alternatively, install the free plugin 'Security Headers' or 'HTTP Headers' from the WordPress plugin repository: Dashboard → Plugins → Add New → search 'HTTP Headers' → Install & Activate → configure to remove Server and X-Powered-By headers.
  6. Verify with browser DevTools (F12 → Network → reload page → click document request → Response Headers).
Full WooCommerce guide →Official WooCommerce docs ↗
How to fix server version on WordPress.org
  1. The fix is identical to WooCommerce above — WordPress.org (self-hosted) shares the same Apache/Nginx server layer.
  2. Via .htaccess (Apache): add `Header unset Server` and `Header unset X-Powered-By` and `ServerSignature Off` to your root .htaccess.
  3. Via plugin: install 'HTTP Headers' or 'Security Headers' plugin (Dashboard → Plugins → Add New), activate, and configure removal of Server and X-Powered-By headers.
  4. For PHP specifically: in wp-config.php or a must-use plugin, you can add `header_remove('X-Powered-By');` before any output is sent. To suppress PHP version exposure also set `expose_php = Off` in php.ini if your host allows it.
  5. Contact your host for server-level (ServerTokens) changes if you are on shared hosting without root access.
Full WordPress.org guide →Official WordPress.org docs ↗
How to fix server version on BigCommerce
  1. BigCommerce is a fully hosted SaaS platform — you do not control the web server configuration.
  2. BigCommerce already manages and genericises server response headers centrally; no version strings are typically exposed.
  3. If a scanner flags a version header, verify the request is truly hitting BigCommerce infrastructure and not a custom middleware, reverse proxy, or headless front-end you have separately deployed.
  4. For headless BigCommerce storefronts (e.g., Next.js / Gatsby hosted on your own infrastructure), apply the fix at the Node.js / Nginx / CDN layer: in Next.js set `poweredByHeader: false` in next.config.js; configure your CDN (Fastly, Cloudflare) to strip the Server header via response header rules.
Full BigCommerce guide →Official BigCommerce docs ↗
How to fix server version on Wix
  1. Wix is a fully hosted platform — you have no access to server configuration files.
  2. Wix centrally manages all HTTP response headers; you cannot set or remove them from the Wix dashboard.
  3. If a scanner reports a version header on a Wix site, report it to Wix Support (support.wix.com) as a security concern — Wix's infrastructure team is responsible for this configuration.
  4. No action is required or possible from the site owner's side.
Full Wix guide →Official Wix docs ↗
How to fix server version on Squarespace
  1. Squarespace is a fully hosted SaaS platform — server header configuration is entirely managed by Squarespace.
  2. You cannot modify response headers such as `Server` or `X-Powered-By` from the Squarespace dashboard or any template setting.
  3. If version disclosure is detected, contact Squarespace Support to flag it. No owner-side action is possible.
  4. If you use Squarespace with a custom CDN or reverse proxy in front (non-standard), suppress the header at that CDN/proxy layer instead.
Full Squarespace guide →Official Squarespace docs ↗
How to fix server version on Webflow
  1. Webflow is a fully hosted platform — you do not control the underlying server configuration.
  2. Webflow manages HTTP response headers centrally; owners cannot modify the `Server` header from the Designer or dashboard.
  3. If you are running Webflow behind a custom reverse proxy or CDN (e.g., Cloudflare), you can add a 'Transform Rule' or 'Response Header' rule in Cloudflare to remove the Server header: Cloudflare Dashboard → your domain → Rules → Transform Rules → Modify Response Header → Add rule to remove 'Server' and 'X-Powered-By'.
  4. Otherwise, contact Webflow Support to report the finding.
Full Webflow guide →Official Webflow docs ↗
How to fix server version on Adobe Commerce (Magento)
  1. Adobe Commerce (cloud) uses Fastly as its CDN/edge layer. Log into the Magento Cloud Admin or Fastly control panel and configure a 'Response Header' VCL snippet to unset the Server header: in the Fastly VCL, add `unset beresp.http.Server; unset beresp.http.X-Powered-By;` in the `vcl_fetch` subroutine.
  2. For Adobe Commerce (on-premises) on Nginx: edit /etc/nginx/nginx.conf or the site vhost config, add `server_tokens off;` in the `http {}` block, and use the headers_more module to fully remove the header: `more_clear_headers 'Server';`.
  3. For on-premises Apache: edit httpd.conf (or the vhost config), set `ServerTokens Prod` and `ServerSignature Off`, and add `Header unset X-Powered-By`.
  4. For PHP version exposure: in php.ini (or via .htaccess on Apache with `php_flag expose_php Off`), set `expose_php = Off`.
  5. Reload/restart Nginx or Apache: `sudo systemctl reload nginx` or `sudo systemctl reload apache2`.
  6. Verify with browser DevTools or `curl -I https://yourstore.com` and confirm no version string is present in the Server header.
Full Adobe Commerce (Magento) guide →Official Adobe Commerce (Magento) docs ↗
How to fix server version on Magento Open Source
  1. Same server-level steps as Adobe Commerce (on-premises) above apply directly to Magento Open Source.
  2. On Nginx: add `server_tokens off;` to nginx.conf and use headers_more module to fully strip the Server header.
  3. On Apache: set `ServerTokens Prod` and `ServerSignature Off` in httpd.conf; add `Header unset X-Powered-By` in the vhost or .htaccess.
  4. Set `expose_php = Off` in php.ini to prevent PHP version disclosure via X-Powered-By.
  5. Restart the web server after changes and verify with `curl -I https://yourstore.com`.
Full Magento Open Source guide →Official Magento Open Source docs ↗
How to fix server version on PrestaShop
  1. PrestaShop is self-hosted, so the fix is applied at the server level.
  2. On Apache: open .htaccess in your PrestaShop root (or the server's httpd.conf/vhost config) and add `Header unset Server` and `Header unset X-Powered-By`. Ask your host to set `ServerTokens Prod` in the main config.
  3. On Nginx: add `server_tokens off;` in nginx.conf or the site server block; use headers_more to fully clear the header.
  4. In PrestaShop's back office, there is no built-in setting for this — it must be done at the server/host level.
  5. Set `expose_php = Off` in php.ini if your host allows it.
  6. Use a hosting control panel (cPanel, Plesk) if available to modify PHP settings and .htaccess.
Full PrestaShop guide →Official PrestaShop docs ↗
How to fix server version on OpenCart
  1. OpenCart is self-hosted; apply the fix at the web server and PHP layer.
  2. On Apache: edit .htaccess in the OpenCart root — add `Header unset X-Powered-By` and `ServerSignature Off`. Request `ServerTokens Prod` from your host.
  3. On Nginx: add `server_tokens off;` in nginx.conf or site block.
  4. Set `expose_php = Off` in php.ini.
  5. Verify the change with browser DevTools after restarting the server.
Full OpenCart guide →Official OpenCart docs ↗

Does your site have this issue?

Run a free SEOLZ audit to find server version — and every other issue — across your whole site in minutes.

Scan my site free

Frequently asked questions

What is Server version?

Every time a visitor's browser (or a bot) loads a page on your store, your web server sends back a set of invisible "response headers." One of these is the `Server` header, and by default most web servers announce themselves with their exact name and version number — for example, `Server: Microsoft-IIS/10.0` or `Server: Apache/2.4.51`. A related header, `X-Powered-By`, can also reveal the scripting language or framework version (e.g., `X-Powered-By: PHP/8.1.2`). Together these are called "server version disclosure" or "banner grabbing." Neither header has any meaningful purpose for shoppers — they exist purely as leftover defaults.

Why does server version matter?

Advertising your exact server software and version is like posting a sign on your shop door listing every lock brand and model you use. Automated attack tools (bots) continuously scan the internet for sites running specific software versions with known vulnerabilities. When your version is visible, your store becomes an easy target: attackers can instantly match your version against published vulnerability databases (CVE lists) and launch targeted exploits — without any guesswork. Suppressing these headers does not make your server invulnerable, but it removes you from the easiest tier of automated attack campaigns. It also demonstrates security hygiene to enterprise buyers and payment-card auditors (PCI DSS Requirement 2.2.7 addresses unnecessary information disclosure), reducing compliance friction.

How do I fix server version?

Remove or suppress the Server version header so your web server software and version number are no longer exposed in every HTTP response.

Related Site Lifecycle issues