SEO QA · Verification process
SEO acceptance criteria are the conditions a ticket must meet before an SEO-related change counts as done. They turn advice such as "make sure titles are good" into a statement that a crawl can mark as passed or failed, which is what lets SEO become part of a development team's normal definition of done.
Definition
An acceptance criterion is testable when two people, checking independently, would reach the same verdict. Most SEO requests fail this test because they describe a goal rather than an observable result. Acceptance criteria fix that by naming the URLs in scope, the exact value expected, and the evidence that proves it.
| Part | Question it answers | Example |
|---|---|---|
| Requirement | What must be true? | Each article has exactly one H1 |
| Scope | Which URLs or templates? | All URLs under /blog/ using the article template |
| Pass condition | What value counts as correct? | H1 count equals 1, text not empty |
| Failure condition | What value blocks the ticket? | H1 count is 0 or 2+ |
| Verification | What evidence closes the ticket? | Staging crawl export, then production crawl after release |
From vague request to testable criterion
| Vague request | Testable acceptance criterion |
|---|---|
| Pages should be SEO friendly | Every indexable template returns 200, has one title, one H1 and a self-referencing canonical |
| Don't break the redirects | Every URL in redirect-map.csv returns one 301 hop to its mapped URL, which returns 200 |
| Make the new filters crawl-safe | Filtered listing URLs canonicalize to the unfiltered listing and are excluded from the XML sitemap |
| Add schema to products | Product URLs output valid Product structured data with name, offers.price and offers.availability |
| Keep the site indexable | No template in scope outputs noindex in HTML or the X-Robots-Tag header in production |
| Links should work | No internal link on templates in scope points to a 3xx, 4xx or 5xx URL |
Notice that none of the rewrites explain why the rule exists. The ticket links to the explanation instead, for example the Academy lessons on H1s or canonicals. That keeps tickets short and the reasoning in one maintained place.
Given, When, Then format
Teams that already write behavior-driven tests can express SEO criteria in the same format, so they sit next to functional tests in the backlog.
When the product page is requested by a crawler without JavaScript
Then the HTML contains one canonical pointing to the product URL
And the Product structured data includes offers.price matching the sale price
And the response status is 200 with no noindex directive
The "without JavaScript" clause matters. If a criterion only holds after rendering, say so explicitly and test it with JavaScript rendering enabled.
Criteria library by template element
Copy these into tickets and adjust the scope. Each row is one criterion.
| Element | Pass condition | Failure condition |
|---|---|---|
| Status | Indexable URLs in scope return 200 | Any 3xx, 4xx or 5xx |
| Title | 1 title, 30 to 60 characters, unique within the template | 0 or 2+, empty, or duplicated |
| Meta description | 1 description, unique within the template | Missing or duplicated across the template |
| H1 | Exactly 1, not empty | 0 or 2+ |
| Canonical | 1 absolute canonical, target returns 200 and is indexable | Missing, multiple, relative, or redirected target |
| Robots | index, follow in HTML and headers | noindex or nofollow anywhere |
| Structured data | Required type present and valid | Missing or invalid |
| Internal links | Links resolve to 200 URLs, no nofollow on internal links | Links to redirects or errors |
| Rendering | Main content and links present in raw HTML | Content only after JavaScript |
Where SEO acceptance criteria live
- In the ticketAdd an "SEO acceptance criteria" block to any story touching templates, routing, the head component or URLs.
- In the definition of doneAdd one line: "SEO acceptance criteria verified on staging and production" so tickets cannot close on code review alone.
- In the pull request templateA checkbox asking whether the change affects rendered HTML, headers or URLs prompts authors to request SEO review early.
- In the release notesList every intended SEO change. Post-deployment testing uses this list to separate expected changes from regressions.
How each criterion is verified
A criterion is only verified when production passes. Staging evidence approves the release, production evidence closes the ticket. Failed criteria can be sent back to the team as Linear SEO tickets with the affected URLs attached. The staging half of this loop is covered in pre-deployment SEO testing.