Payload Extraction Integrity Check Missing for Restored HTML and Payload

Direct answer

Based on the available information for this response, Nuxt/Nitro does not document a built-in checksum, CLI flag, or manifest entry that binds a prerendered HTML file to its extracted payload JSON for restore validation. The experimental.payloadExtraction option controls whether payloads are split into separate files; it is not an integrity feature.

Regarding your three specific questions:

• Should Nuxt emit a payload hash alongside the HTML? It would be a sound design, but it is not a documented feature in the available information.
• Can a restore script compare hashes before serving? Yes, but only if your build pipeline generates and stores those hashes; Nuxt does not create them automatically.
• Is there a recommended CLI flag or manifest entry? No documented flag or manifest entry exists whose purpose is to fail a restore when artifacts come from different builds.

Likely explanation vs. confirmed facts

Likely explanation: Payload extraction is designed as a build-output optimization rather than a restore-integrity mechanism. The emitted HTML references the payload at runtime, but the build system does not cryptographically bind the two artifacts together.

Confirmed facts from available knowledge:

• experimental.payloadExtraction is version-sensitive; output paths and filenames differ across Nuxt 3.x and Nitro releases.
• Runtime hydration warnings are not a reliable integrity gate; a mismatched payload may produce only subtle UI differences rather than a hard failure.
• A content-hashed payload filename can cause some cross-build restores to fail as missing files, but it is not a substitute for a paired integrity manifest.

Steps needed for this case

1. Pin your versions. Record the exact Nuxt and Nitro versions from your lockfile. Because the output layout for experimental.payloadExtraction is version-sensitive, restore logic must be validated against those specific releases.
2. Generate a paired manifest at build time. After nuxt build, compute a SHA-256 hash of each prerendered HTML file and the payload JSON it references. Store the pairs in a manifest keyed by route, including a build identifier. Discover the payload reference from the emitted HTML rather than assuming a fixed filename.
3. Verify before serving. On restore, recompute the hashes and compare them against the manifest. Abort startup if any file is missing, if a hash differs, or if the build identifier does not match.
4. Protect the manifest. Keep the manifest immutable or signed outside the restored tree; otherwise a partial restore can overwrite it.

Practical verification

Build a minimal route with prerendering and payload extraction enabled, then inspect the emitted HTML to locate the payload reference. Confirm that your restore script fails when HTML from one build is paired with payload from another before the server starts.

Missing diagnostic detail

Please confirm your installed Nuxt and Nitro versions. The exact output layout—such as whether payloads are emitted under a dedicated subdirectory or alongside other static assets—varies by release, and that detail changes the file-discovery logic in your restore script.