Nuxt

`/_nuxt/` in the served markup, the path Nuxt's build output is served from — weight 85.

`__NUXT__` in the markup, the global state object Nuxt serialises into the page — weight 85.

Either signal alone clears the reporting threshold of 40, and both together report with high confidence.

Nuxt is a separate rule from Vue: a Vue application not built with Nuxt is not reported as Nuxt, and Vue itself has no page because its only marker is a weak one.

It proves the assets come from a Nuxt build.

It does not say whether pages are server-rendered, prerendered or rendered only in the browser. Nuxt supports all three, and with server rendering turned off the build produces a static single-page application.

It does not identify the server. A generated Nuxt site ships no server runtime at all and can be served by any static host.

It carries no version, and none is inferred.

Nuxt's runtime config separates private keys from a `public` namespace. The documentation states that public keys are exposed to the client, while the others are only accessible on the server side.

Anything placed under `public` is therefore delivered to every visitor with the page state, whatever its name suggests.

Runtime config values are overridden at run time by environment variables whose names start with `NUXT_` and mirror the config structure. A public value can change between environments without a rebuild.

The audit question for each public value is the same as for any front-end key: was it meant to be public.

A server-rendered or prerendered Nuxt page delivers its content in the HTML, which crawlers read directly.

A page rendered only in the browser delivers an application shell, and its content depends on the crawler executing JavaScript.

The same Nuxt site can mix both modes by route, so one sampled page does not settle the question for the whole site.

Comparing the served HTML with the rendered page for a few representative routes is the honest way to find out.

`technology.inventory` lists the detection with the matched markers.

`exposure.secrets.public_keys` and `exposure.secrets.private` report keys present in the served page and scripts, which is where public runtime config ends up.

`exposure.sourcemap.public` reports source maps served next to the build output.

`seo.title`, `seo.meta_description` and `seo.canonical` read the served HTML, which is what shows whether a route's metadata is rendered on the server.

Nuxt's runtime-config documentation warns that the built server does not read the `.env` file: the CLI reads it during development, build and generate, and in production the values must come from the real environment.

Only an uppercase environment variable starting with `NUXT_`, following the structure of the config keys, overrides a runtime config value at run time.

The documentation also warns that pointing a runtime-config default at a differently named variable only works at build time, which is how a value from a build machine ends up frozen into a deployed site.

A private root secret, `runtimeConfig.appSecret`, is available only on the server; the documentation says builds never generate one, so it has to be set in every deployed environment where a module needs it.

None of these settings is visible from outside. What an audit can see is the public half, in the page.