Describe a testable change before work begins
Fix SEO is not an acceptance criterion. A useful criterion names the affected resource, the current failure, the expected observable behavior and the environment where it must be checked. Record the original evidence before implementation so that the reviewer can distinguish a corrected condition from a page that was never affected.
Choose checks that match the actual defect. A title correction needs an expected title and page scope; a redirect correction needs a source, destination and response behavior. Avoid appending an unrelated universal checklist to every ticket. The implementer and reviewer should agree on what evidence will settle this particular task.
Define the affected scope and the protected scope
List exact URLs for a small repair, or identify the template and representative variants for a broader one. Record how those examples were selected. Include the language, device or account state when it changes the output. A sample passing does not prove that every page using a complex template behaves identically.
State what must remain unchanged. A public-page indexing repair should not accidentally make a private workspace indexable. Choose at least one relevant negative control: a page outside the intended change whose existing behavior should persist. This makes the boundary of the repair visible to both the implementer and the reviewer.
Separate local acceptance from search outcomes
Google documents that noindex may be supplied in HTML or an HTTP response header. For a repair involving that directive, inspecting only the visible page or only one of those locations is incomplete. Save the response and the relevant HTML, including the URL, timestamp and environment, so another reviewer can reproduce the observation.
Google also distinguishes its technical eligibility requirements from a guarantee of indexing. Therefore, deployed without the unintended directive and indexed by Google belong in separate fields. Do not keep a correctly implemented change labelled technically broken simply because Google has not yet processed it, or label it indexed because a local test passed.
Illustrative acceptance for an accidental directive
Imagine a fictional public service page that inherited noindex from a staging configuration. The agreed repair covers two public language URLs. Its pass conditions are that both production URLs return the intended content with HTTP 200 and no applicable noindex rule in the HTML or response headers. The private workspace must retain its existing exclusion.
The reviewer checks both public URLs and the private control after deployment, saving the observed responses. If one language still contains noindex, the repair fails its stated scope even though the other passes. These criteria accept the removal of that specific defect; they do not certify every aspect of crawlability or promise search visibility.
Record an explicit decision and any remaining work
Use pass, fail or unable to verify for each criterion. Explain missing evidence instead of treating a blank result as success. If production access is unavailable, distinguish a successful staging check from outstanding production verification. Attach the release reference and reviewer identity so the decision applies to the delivered version.
If a new issue appears, record whether it contradicts the agreed acceptance or requires a separate action. Do not silently expand or weaken the criteria after delivery. Close the technical repair with its evidence, then schedule any necessary search observation separately. This gives the client a clear account of what changed and what remains unknown.