Magento and Adobe Commerce

A `/static/version<digits>/` path — weight 70.

`Magento_` module assets or `mage/cookies` scripts — weight 70.

A cookie matching `X-Magento-Vary` or beginning with `mage-` — weight 75.

No single signal is conclusive; together they report with high confidence.

Adobe's static content signing documentation explains that Commerce adds a deployment version to static file URLs so browsers fetch new files after a deployment.

Its example is `pub/static/version1475604434/frontend/Magento/luma/en_US/images/logo.svg`, and the version changes automatically each time static content is deployed.

The number is a deployment marker. It says when static files were last deployed, not which Magento release runs.

The software version is not established by any of these signals.

In developer mode, the documentation says uncaught exceptions display in the browser.

In production mode, errors and exceptions are logged to the file system and are never displayed to the user.

A detailed exception page on a live Magento store therefore suggests the store is not in production mode.

From outside it is visible only when an error occurs during the scan.

Adobe's security best practices recommend a non-default admin URL instead of `admin` or a common term such as `backend`, to reduce exposure to scripts looking for it.

They also recommend two-factor authentication for the admin, and reCAPTCHA against automated attempts.

An external audit does not look for the admin URL and never attempts a login.

These recommendations are listed because they are the ones the store owner has to verify from inside.

`ecommerce.detected` and the commerce checks cover checkout signals, product data and tracking consent.

`api.errors.disclosure` reports detailed error responses when one is met.

`performance.static_cache` reports whether versioned static files carry long cache lifetimes, which signing makes safe.

`cookies.inventory` and `cookies.secure` report the store's cookies and their flags.

Adobe's security best practices call upgrading to the latest release, with security patches and hotfixes, the primary protection against security threats.

They state that Commerce typically releases security updates quarterly, with hotfixes outside that schedule for major threats.

They also recommend Adobe's own Commerce Security Scan service for monitoring known risks and malware — an internal tool, distinct from an external audit.

For crawling, Adobe's launch guidance says `robots.txt` content is managed from the Admin, and the generated file is served at the store's `/robots.txt`.

An audit reads that served file, which is what crawlers see regardless of how it was produced.

Adobe's documentation says Commerce operates in default mode when no other mode is specified, and that default mode is not optimised for production.

In default mode, exceptions are written to log files instead of being displayed, static view files are cached, and custom `X-Magento-*` HTTP headers are hidden.

Custom `X-Magento-*` response headers on a live store are therefore a sign of developer mode, alongside detailed exception pages.

Maintenance mode is separate, and the documentation describes a custom maintenance page and access for authorised addresses while it is on.