Treat launch settings as part of the release artifact
A preview can be correct and the published build wrong when the release uses a different configuration. Before promotion, identify the exact artifact being deployed and the environment that produced it. Record a build identifier, configuration version and intended production hostname together. A screenshot of yesterday’s preview cannot approve today’s output.
This procedure prevents development settings from travelling into production. It complements diagnosis of an accidental noindex directive, which belongs in a separate investigation. Start after the team has agreed which routes are public and which remain private; the release process must preserve that distinction.
Create an environment settings matrix
Give each setting a row with its source, preview value, intended production value, application stage and owner. Include public base URLs, indexing settings and sitemap generation scope. Record whether each value is baked into generated files or read when the server handles a request. This determines whether a rebuild is required or a runtime change takes effect.
Keep secrets out of this review document. For access settings, record the intended boundary and responsible owner rather than copying credentials. Mark values that intentionally differ between environments. A blanket copy of preview configuration is not a production plan, and a blanket removal of restrictions is not an acceptable substitute.
Check the output before promotion
Inspect the candidate artifact using the matrix. Confirm that generated page references and the sitemap use the intended public hostname and that development-only exclusions are absent from approved public output. Google documents noindex in both HTML and response headers; generated HTML checks therefore cannot replace later checks of the served response.
For values applied at runtime, record the required deployment setting and a verification step instead of pretending it can be proven from the file archive. Assign unresolved differences to their owners. Preserve the candidate identifier in the evidence so a rebuild invalidates the earlier output checks rather than silently inheriting them.
Example: a rebuild reintroduces preview configuration
Illustrative example: a fictional team corrects a public page manually, then launches a new build generated with the preview configuration. The next deployment restores preview references and exclusions. The underlying fault is the release input, so repeating the manual edit would leave the next build vulnerable to the same mistake.
The team corrects the production configuration source, rebuilds, and checks the replacement artifact against its matrix. After promotion it verifies representative public routes and confirms that the separate preview remains restricted as intended. This hypothetical example is about repeatable delivery, not a recommendation to expose unfinished content.
Include rollback and future builds in acceptance
Save the accepted artifact and configuration relationship with the release record. Before selecting an older artifact for recovery, check whether its environment settings are still appropriate; a previously working build can contain obsolete public addresses or development defaults. Document the recovery choice instead of assuming every older version is interchangeable.
After deployment, compare served responses with the expected production column and retain the result by route type. Repeat these checks when build inputs or deployment templates change. A public-page audit can support verification, while the settings matrix explains provenance. Completion confirms the checked release behavior, not immediate Google indexing or ranking gains.