How to Write Acceptance Criteria for Technical SEO Fixes

“Fix the canonicals” is not an implementable ticket.

It does not identify which pages are wrong, which URL should become canonical, whether the tag is present in rendered HTML, which other canonical signals must agree, or how anyone will know the production result is correct.

“Add redirects” has the same problem. So do “improve internal linking,” “clean up schema,” “remove these pages from Google,” and “track the form.” Each phrase describes a direction. None defines a finish.

Technical SEO acceptance criteria turn that direction into a testable agreement before development begins. They state what is in scope, what must change, what must remain intact, how the live result will be observed, and who can accept it.

The goal is not to make every ticket longer. The goal is to remove the ambiguity that creates rework, partial fixes, and premature completion.

A Recommendation Is Not A Pass Condition

A recommendation usually explains what should improve and why. Acceptance criteria define the observable state that closes the implementation task.

Compare these two versions.

Recommendation: “Redirect the retired service URLs to the replacement service page.”

Acceptance criteria: “Each URL in the approved source list returns one permanent server-side redirect, resolves directly to its mapped replacement URL without an intermediate hop, preserves no obsolete query parameters, and ends on a 200 indexable page. The global navigation, XML sitemap, and in-content links no longer reference the retired URLs. The mapping owner accepts the live response record.”

The second version creates several useful boundaries:

• The source URL list is controlled.
• Each source has an approved destination rather than a guessed generic page.
• The redirect type and chain length are observable.
• The final destination has its own pass condition.
• Internal references are included instead of left to chance.
• One person owns the acceptance decision.

Google distinguishes permanent redirects from temporary redirects and recommends permanent server-side redirects when a page has permanently moved. That guidance informs the requirement. It does not replace the site-specific mapping and live test.

Use Six Fields For Every Technical SEO Fix

A practical acceptance record can fit in six fields.

1. Affected Surface

Name the URL, template, component, rule, sitemap, feed, tag, or event being changed.

Avoid “the blog” when the actual scope is the article template. Avoid “all location pages” when only locations using one CMS layout are included. If the rule affects a family of URLs, define the family and attach representative examples.

Good scope language looks like this:

• The 42 source URLs in the approved redirect map.
• Product collection pages created by the `collection` template, excluding paginated and filtered variants.
• The rendered canonical element on the five representative URL states in the ticket.
• The `generate_lead` event fired after a successful contact-form submission.

The number is not useful unless it comes from the real scope record. Do not invent a count merely to make a ticket sound precise.

2. Required Change

Describe the behavior that must become true.

Write it in observable terms. “Improve crawlability” is an intention. “Every approved destination is reachable through an HTML anchor with an `href` attribute from its parent service page” is observable. Google's link guidance explains that standard anchor elements with resolvable `href` values are the reliable crawlable form.

Use the actual implementation layer only when it matters. The acceptance criterion usually cares about rendered or returned behavior, not whether a developer chose one internal function name over another.

3. Protected Behavior

State what must not break.

A redirect change must not send unrelated URLs to the same destination. A canonical change must not make valid distinct pages point elsewhere. A schema correction must not introduce content that is absent from the visible page. A tracking change must not fire on validation errors or duplicate successful submissions.

This field prevents a narrow fix from passing while the surrounding customer or crawl path regresses.

4. Observation Method

Name how the result will be tested.

Different changes require different evidence:

• HTTP response inspection for status codes, destinations, and redirect hops.
• Rendered HTML inspection for canonicals, robots directives, links, and structured data.
• Browser testing for visible behavior and customer paths.
• A crawler for representative and full-scope rule checks.
• Rich Results Test or another syntax validator for supported structured data.
• DebugView or Realtime for analytics event names and parameters.
• A receiving system for form delivery, source preservation, or downstream records.

Do not substitute one evidence type for another. A source-code diff does not prove the production response. A green schema validator does not prove visible content matches the markup. A thank-you message does not prove a lead reached the receiving inbox.

5. Representative Cases And Exceptions

Choose test cases that expose the rule, not only the easiest happy path.

For a canonical fix, include the preferred URL, a duplicate variant, a parameter state, and any legitimate exception. For internal links, include desktop and mobile navigation if they render differently. For noindex, include one page that should be excluded and one neighboring page that must remain indexable.

If a rule has approved exceptions, list them. An undocumented exception looks exactly like a defect during QA.

6. Acceptance Owner And Decision

Name one person or role responsible for the final decision.

The delivery owner can document what shipped. The acceptance owner decides whether the evidence satisfies the agreed requirement. In a small team, those may be the same person, but the decision still needs to be explicit.

Use four possible states:

• Pass: every required condition and protected behavior check succeeded.
• Fail: at least one condition produced a reproducible mismatch.
• Blocked: a dependency, access requirement, or unavailable environment prevents the test.
• Inconclusive: the available observation does not distinguish success from failure.

“Deployed” and “merged” are delivery states, not automatic acceptance states.

Example 1: Permanent Redirects

Weak ticket: “301 the old pages.”

Testable version:

Affected surface: every source and destination pair in the approved redirect map.

Required change: each source returns a permanent server-side redirect and reaches its mapped destination in one hop. Each destination returns 200 and presents the intended replacement content.

Protected behavior: URLs outside the approved source list keep their existing response. Query parameters needed for a real customer path are handled according to the mapping, not dropped or copied by default.

Observation method: record the source response, `Location` value, hop sequence, final status, and final canonical for every mapped URL. Open representative destinations in a browser.

Acceptance decision: fail any source that loops, chains, returns the wrong redirect type, lands on an unrelated page, or ends on a non-200 response.

Google describes permanent redirects as a signal that the target should become canonical. That is why the redirect and final canonical should be reviewed together. It is not a promise about when Google will process the change.

Example 2: Canonical Corrections

Weak ticket: “Fix duplicate-page canonicals.”

Testable version:

Affected surface: the rendered canonical on the approved representative URLs plus the template rule that produces it.

Required change: each duplicate page declares the approved absolute canonical URL in the rendered HTML head. The canonical destination returns 200, is indexable, and is the genuinely preferred equivalent page.

Protected behavior: distinct pages with unique buyer value retain self-referencing canonicals. No canonical points to a redirect, error page, blocked URL, or unrelated category.

Observation method: inspect rendered HTML, crawl representative variants, and compare internal links and sitemap entries with the approved destination.

Acceptance decision: pass only when the declared canonical and the site's supporting signals agree for the tested cases.

Google treats canonical methods as signals rather than commands and recommends consistent canonical signals. That makes “the tag exists” too small a definition of done.

Example 3: Noindex And Crawl Access

Weak ticket: “Block the thin pages in robots.txt.”

That instruction may prevent the intended result. Google explains that a crawler must be able to access a page to see a `noindex` directive. If robots.txt blocks the URL, the directive may not be observed.

Testable version:

Affected surface: the approved exclusion set and one protected indexable neighbor from each relevant template.

Required change: each excluded URL remains crawlable and returns a supported `noindex` directive in rendered HTML or the HTTP response. It is removed from the XML sitemap and from indexable navigation where appropriate.

Protected behavior: approved indexable pages do not inherit the directive. Required customer paths continue to work.

Observation method: request the URL as a crawler can, inspect the final robots directive after redirects and rendering, check robots.txt access, and confirm sitemap membership.

Acceptance decision: a directive hidden behind a robots.txt block, emitted only before client-side rendering changes it, or applied to protected pages fails.

Index removal itself may require recrawling and belongs in follow-up monitoring. The implementation can pass before the search result changes, provided the controllable live conditions are correct.

Example 4: Internal Link Repairs

Weak ticket: “Add more internal links to the service pages.”

Testable version:

Affected surface: the named source modules and approved destination pages.

Required change: each destination has at least one relevant, rendered HTML anchor from the specified source page. The `href` resolves directly to the current 200 URL, and the anchor text describes the destination in context.

Protected behavior: the update does not create duplicate blocks, broken mobile navigation, forced keyword repetition, or new links to redirecting legacy routes.

Observation method: inspect the rendered anchor element, request the destination, review the surrounding sentence, and crawl the source-to-destination relationship.

Acceptance decision: a clickable JavaScript element without a resolvable anchor, an empty link, a redirected legacy URL, or an unrelated anchor fails even if a user can sometimes reach the page.

Google recommends crawlable anchors and descriptive, concise anchor text. The ticket should translate that general guidance into the exact source and destination relationship being changed.

Example 5: Structured Data Corrections

Weak ticket: “Add FAQ schema and make it validate.”

Testable version:

Affected surface: the JSON-LD emitted by the named page template and the visible FAQ section it describes.

Required change: the markup parses without syntax errors, uses supported properties for the selected type, and matches the visible questions, answers, author, date, organization, and image facts on the page.

Protected behavior: no hidden FAQ, invented review, unsupported rating, false location, or stale offer is introduced. Existing valid article metadata remains present.

Observation method: compare the rendered JSON-LD with visible page content, run the relevant validator, and inspect the production HTML rather than only a local component.

Acceptance decision: validation is necessary but not sufficient. Google requires structured data to represent visible, truthful page content and does not guarantee a search feature even when markup is valid.

The acceptance record should therefore close the implementation without promising a rich result.

Example 6: Analytics Event Tracking

Weak ticket: “Track contact-form conversions.”

Testable version:

Affected surface: the successful production submission path for the named form and the approved analytics property.

Required change: one `generate_lead` event fires after a confirmed successful submission and includes the approved non-sensitive parameters. It reaches the intended analytics destination.

Protected behavior: the event does not fire on page load, field validation failure, duplicate callback, or failed delivery. No personal information is sent in event names or parameters.

Observation method: perform representative submissions in debug mode, inspect the event and parameters in DebugView, and separately confirm the receiving system got the submission when delivery is part of the scope.

Acceptance decision: a browser console message alone does not pass. Google Analytics documents DebugView and Realtime as ways to verify that events have been collected. If the receiving system cannot be checked, analytics collection may pass while end-to-end delivery remains blocked.

Separate Implementation Acceptance From Outcome Monitoring

Technical SEO tickets should usually be accepted on behavior the team controls.

A redirect returning the correct response can pass. Whether Google has replaced every old search result is a later observation. A canonical implementation can pass. Whether Google selects that canonical across the full index is monitoring. A structured data correction can pass without receiving a rich result. An event can pass collection QA before enough real activity exists for analysis.

Do not attach an invented ranking, traffic, or conversion target to make the acceptance criteria feel commercial. That confuses implementation evidence with business outcome evidence.

Create a separate monitoring record when the downstream state matters. Name the metric or search observation, baseline, review window, owner, and limits. If the data is unavailable, say so.

Write The Ticket Before The Estimate

Acceptance criteria are most valuable before effort is estimated.

Without them, two people can price different jobs under the same sentence. “Fix canonicals” might mean changing one template field to a developer and aligning redirects, sitemaps, internal links, duplicate states, and production evidence to the SEO owner.

Use this order:

1. Define the affected surface and buyer or search risk.

2. Write the required and protected behavior.

3. Select representative cases and known exceptions.

4. Name the production observation method and required access.

5. Assign delivery and acceptance ownership.

6. Estimate the bounded implementation.

This sequence also exposes dependencies early. If production crawling, analytics DebugView, CMS access, or redirect configuration is unavailable, the team can identify the acceptance gap before promising completion.

Build A Small Verification Receipt

Close the ticket with evidence another operator can understand later.

Record:

• Ticket and scope identifier.
• Deployed version or release reference.
• Production URL or representative case.
• Expected behavior.
• Observed response or rendered state.
• Test method and timestamp.
• Protected behavior result.
• Pass, fail, blocked, or inconclusive decision.
• Acceptance owner.
• Follow-up monitoring that remains open.

Keep the receipt proportionate. A single canonical correction does not need a forty-page report. A sitewide redirect migration should not be closed by one screenshot.

The useful standard is reproducibility: can another qualified person repeat the check and understand why the result passed?

Choose A Definition Of Done That Survives Production

A good technical SEO acceptance criterion is specific enough to fail.

It identifies a live condition, a way to observe it, and a boundary around what must remain intact. It does not rely on a meeting memory, a developer's confidence, a merged pull request, or a future search outcome no one controls.

If you already have recommendations but cannot turn them into bounded implementation tickets, an Ashfield [website audit](/audit) can clarify the affected surfaces and evidence. Use the [website cleanup sprint](/sprint) when the work has a defined finish that can be implemented and verified in a focused scope. For recurring technical SEO, content, analytics, and production QA, review [website growth support](/services/growth).

When the scope or acceptance access is uncertain, [contact Ashfield Digital](/contact) before development begins.