Test the deployed behavior, not just the design
A new website can look correct while serving the wrong indexing controls, broken destinations or incomplete measurement. Technical acceptance should cover the actual environment in which the page will run. A local hash-based preview is useful for design review, but it is not proof that production URLs work correctly. Keep staging protected and excluded from indexing. Before launch, prepare a separate production checklist that verifies the intended public behavior. Do not remove staging safeguards simply to run a search test.
A practical acceptance checklist
| Area | Evidence to collect |
|---|---|
| Access | Intended public pages return successful responses and render useful content |
| Indexing controls | Production robots directives allow intended pages; private pages remain protected |
| URL ownership | Each important intent has a clear destination and consistent canonical |
| Migration | Old-to-new URL decisions are reviewed and redirects tested |
| Navigation | Header, footer, contextual links and pagination reach the intended pages |
| Sitemaps and structured data | Published URLs and factual markup match the actual site |
| Experience | Mobile layouts, image dimensions, forms and keyboard operation are checked |
| Measurement | Successful inquiry and booking behavior is verified without counting tests as real demand |
Download the worksheet and record the URL, expected behavior, observed result and owner for each failed check. A checklist is complete when the result is demonstrated, not when every box has been marked optimistically.
Interpret performance evidence correctly
The demo report includes field LCP, INP and CLS measurements alongside crawl findings. Field evidence and a laboratory test serve different purposes. A successful lab run does not establish that every visitor receives the same experience, and missing field evidence should remain identified as unavailable. Google’s Core Web Vitals guidance defines the measures and their thresholds. The purpose of checking them is to identify user-experience problems, not to describe a passing metric as a ranking guarantee.
Separate launch blockers from improvement work
A broken primary inquiry path, an unintended noindex directive or an incorrect destination for an important migrated URL can warrant immediate attention. A minor issue on a low-priority archive page may belong in the subsequent repair queue. Decide in relation to affected users and intended discovery, not the number of warnings in a tool. For each issue, save the source observation and a repeatable retest. Avoid fixing an indexability warning by exposing a page that was intentionally private.
Recheck after the actual launch
Validate the public domain, redirects, canonical URLs, sitemap contents, forms and analytics in the production context. Then monitor collection and indexing evidence over time. Search systems are not required to index every eligible page immediately. SharkBlade can support ongoing Site Health review, while the deployment team owns the migration and acceptance process. The audit checklist covers what can be learned from public evidence; this acceptance guide addresses the implementation checks needed for a new website.
Explore the next step
Supporting documentation
Google: Search technical requirements ↗Google: Core Web Vitals definitions ↗